Keep JAVA out of browsers it simply doesn't belong there. I hate when the JVM takes 15 seconds to load up
and 60MB of RAM just to view a f'ing webpage.
Being able to have java applets in web pages is very useful. Did I mention VNC viewer applet? SSH applet?
Java applets (or a similar technology) should used instead of ActiveX controls. Being able to "program" what happens in a remote browser (i.e. viewer) is an important capability.
Flash is the wrong approach to this. SVG and/or applets are better because they can be applied to a wide range of browsers, not just the most proprietary ones.
Nobody is making you load up Java. Nobody is making you go to certian web pages. I'm sure that there can be a choice and variety of browsers. You can even use lynx if you wish. But don't advocate making everyone's browser feature poor. What I am advocating is that we should try to promote open standards as much as is possible in making browsers feature rich. And using the smallest set of technologies that give the biggest set of capabilities. Why have Flash when either SVG or a Java applet could have done the same thing, for instance.
After I posted this, some have already tried the experiment. Some get the same result, others do not. Someone even pointed out that the CD Paranoia FAQ makes it clear that you cannot expect the same results of ripping the same CD even on the same drive!
My point is that I am not making wild assertions.
I think the moon is made of green cheese, but don't ask me to prove it.
Of course, you are entitled to your opinion on this just as you are entitled to believe that ripping the same CD on the same drive with the same software gives the same WAV file.
could just be that you used the same encoder/settings (i.e. iTunes on a default of 128k or 192kbps). Then the content would be exactly the same as someone else who legitimately ripped a copy on their computer in the same way.
Very unlikely. See other posts here. Some have even conducted the experiment I suggested and gotten the results I expected. While the mp3 encoding process may be exact, the cd-ripping process is not. Same CD. Same Drive. Same Softare. Different WAV files resulting.
Let's see, we're going to link a JVM and a media player into a web browser? And people think Mozilla is bloated already.
Who thinks it is bloated? Not I. It is well under 100 MB at present. In fact, only a little over a tenth that. (Compressed install file.)
There are good cases for directly linking in a JVM. It is a general tool that gives web designers all kinds of flexibility. Same type of logic as having other features such as frames, tables, multiple image formats (why should we link in PNG support?). Why should Mozilla have DOM, DHTML?
But I would NOT be in favor of linking Flash, or RealPlayer directly into Mozilla. These are not open source for one. And they are tools to control browser market share for another.
My opinion would be: have DOM, DHTML, CSS, and introduce SVG to replace Flash. Add or keep JVM for applets.
This leaves the problem of just how do you play media files? I would of course like it if somehow the proprietary formats got left out in the cold and only open formats prevailed, such as mpeg, or ogg video somethingorother.
I also ran lame with default settings (makes a 128K CBR) on both WAVs and got different sums there as well.
This part is not at all surprising. Even one single bit difference in two files would give radically different MD5 hashes.
Different drives, with the same disc, and identical software, certainly do give different results. Just tested. Identical versions of cdparanoia live on both systems.
This part is the really interesting result. Two different rips, same software, same CD, give different results on different drives. I think cd paranoia says something about "digital jitter" whatever the heck that means?
I'd say that I'd be amazed if this DIDN'T happen regularly.
I'd be amazed if it DID happen at all.
The mp3 coding process is exact, as you speculate. The CDDB process is probably exact.
I believe that the cdparanoia (i.e. ripping) process is not as exact as you think. An easy way to confirm this is:
1. Rip the same track, same CD, twice into two WAV files.
2. MD5 hash each of the two files.
Do you get the same MD5 hash? If not, then although the two WAV files may sound the same, they aren't actually the same bits.
I think the ripping process has a lot of variability. Sorry I don't have handy any references for this. But I believe I have represented it correctly.
First let's talk about theory. Yes you could. There are an infinite number of mp3 files that will give you the same MD5 checksum. Some of them will be works of genius, and some of them will be absolute crap. Some of them will be appropriate for children, and others will not.
Now let's talk about practice. No you could not. You would need to examine 2^127 files in order to have a 50 % chance of one of those files having a certian predetermined MD5 hash. This is a big number. How many stars are there in the entire universe again? And just how big is 2^127?
Probably because open source people see this as patent abuse. Ten years ago, nobody would think it wise to spend time and money filing for numerous obviously stupid patents. Why would we? Only now is it becomming obvious why you need a large stable of obviously stupid patents. To fight off the same but now grown up bullies that used to stuff you into a locker in high school.
Try the following: Install some CD ripping/encoding software. Leave it at the defaults. Use CDDB to generate the ID3 tags. Unless something gets corrupted, that *will* produce an identical file, down to the last bit.
You may be right. I'm not sure. I have some doubts about the ripping process being as exact as you say. I agree that the mp3 encoding process is exact. Same input file, same settings, ---> same output file.
RIP: we'll use this term to mean running, say, cdparanoia to "rip" the track from a CD into a WAV or AIFF file. (lossless)
Encode: we'll use this term to mean transforming a lossless audio format into an mp3 format.
If everyone had the same WAV file, then you are correct. Same encoder, same settings, same ID3 tags ---> same MD5 hash.
But everyone won't start with the same WAV file. If you run cdparanoia twice to rip the same track you will get different WAV files. This does not seem intuitive, but it is apparently true. There are apparently a bunch of complex factors that affect the ripping process.
I suppose an easy test of this would be to rip the same track twice and compre the MD5 hash of the two WAV files. (Don't bother encoding with mp3.) Then you would prove or disprove what I am saying. Sorry I don't have any references on this.
If you just alter the ID3 tags without altering the mp3 content, then they can nail you. If simply altering id3 tags becomes commonplace because everything thinks it is the easy, trivial implementation, then they will nail you by checking the hash of the content. Identical content with trivially altered ID3 tags is a very good argument that you got this file from the thousands of other people who have the same hashed file with trivially altered ID3 tags.
I'm proposing a non-trivial, but not that conceptually complex alteration to the content that alters it in an imperceptable way. In fact, whether the alteration seems complex to you is irrelevant. After all, it is just a command line tool to you anyway, just like altering ID3 tags. You don't care how it is done. Run this tool on your mp3 file, it randomly affects an imperceptable alteration to one of the gazillions of 11-byte frames in the file.
However I doubt that they will go to such trouble -- if they have access to your files you're pretty much caught red-handed. A different MD5 checksum won't get you off of the hook here.
They might have access to your files if you are sharing them.
I think the original argument is that Jane Doe was sharing files. Jane claims the sharing is unintentional. Jane claims that the mp3's on her hard drive are her own rips of CD's she owns. The MD5 hash proves otherwise. This sub-discussion is about altering mp3's so that hashing is now useless at tracking the source of where you got an mp3 from. In the Jane Doe scenerio, a comples mp3 alteration to foil the MD5 hash would actually be useful.
Merely altering the ID3 tag such that the RIAA can also alter the ID3 tag back to what it is in the wild, and get identical MD5 hashes is a very strong argument against Jane Doe.
Why on earth would you destroy the quality of your mp3 by decoding/re-encoding the music when all you have to do is change something in the IDv.x tags? Someone could, more easily, write a program that adds a random letter to the "Comments" field of IDv3.
I didn't say to destroy the quality of your mp3.
Decode one single 11 byte frame. Alter one bit. Re-encode it. In fact, as I understand things, the sound is stored as the sums of frequencies (FFT) or something like that. (Not an expert on this.) You could probably just alter one bit in the correct frame such that you add a new blip of a frequency at an imperceptably low amplitude.
Another possibilty is that there may be "zero" or "unused" bits in some header fields. Hypothetical example, in some bit field, 3 bits are not yet defined. Simply define tham as RIAA bits. But this gives limited possibilities to obscure the hash.
Another possibility is to alter or add one frame of "silence" at the beginning or end. If there is already a frame of silence, then alter that in an imperceptable way.
There may be other kinds of imperceptable alterations that can be made to mp3's.
Two consecutive frames may indicate the same set of frequencies being played at this moment in time, but at slightly different amplitudes. Swap the two frames. Or alter by one bit the amplitude of one of the frequencies that is least audible, such as deep bass. Or alter the start time of when a particular frequency starts or ends by an iimperceptable amount.
I'm talking about changes such that even if you have a 10th generation copy that has had 10 random alterations done, each by one person in the chain of handoffs from the person who originally ripped it, you have a "perfect" quality mp3, as far as mp3 "quality" goes.
SCO's revenue source is Microsoft making donations to its legal fund, errrrr, licensing Unix and Linux.
True, but... Red Hat and IBM has asked for court to shut SCO's loud mouth until trial in April 2005. The combined effect is that the FUD will stop. SCO can't spread fud, and it is inevitable that SCO will loose in court, which they now can't back out of -- without a settlement being reached. So Microsoft can pay as much as they want, but if SCO can't spread FUD, then what is the point.
hey sign cross licensing agreements with each other stating that they won't sue
This is not what a cross licensing agreement says.
The typical big company cross licensing arrangement goes like this. Okay, we've settled our dispute. Let's not bring patents into the war. (Like nuclear weapons.) So we will cross license eash other with each other's patents. I now have rights to all of your patents, and you have rights to all of my patents. This forecloses the possibility that you will ever sue me over any of your patents. But you still might sue me because I give you defective copies of Windows because I don't like the way you cozy up to Linux.
what's stopping people from simply changing a letter in the mp3 info tag (the trivial approach) or a bit or byte somewhere in the file? Good luck matching my file to anything.
Well there are several things that could stop you. You could get the latest MISD (Microsoft Internet Social Disease), etc.
But if you don't, then short of other things stopping you, such as getting run over by a truck, you merely need to change one single bit in the file to have a very different MD5. That bit does NOT need to be in the ID tag. You could just decode one single mp3 frame, randomly selected from the file, alter one bit of the sound, and then re-code that single mp3 frame.
It is even possible that someone might be inspired to write a tool to do this. It would defeat a lot of the previous Slashdot discussions about using MD5 to indicate "good" downloads before you download them. But maybe trust relationships of the P2P swappers themselves, using private keys, is a better idea than trusting the download file.
What exactly is the thinking behind these juries which award judgements on stupid patents like these?
They could be thinking about their dislike for Microsoft.
"My daugher's computer with Windows ME is less than two years old, and I had to take it to the shop and pay a huge amount to get Windows fixed. And a bunch of my files were lost."
They could also be thinking of negative experiences they might have had related to NOT having the right plug in for some favorite web site.
While I would love to see the demise of Flash in favor of SVG, I would be sad to see Java Applets go away.
It is good to have a way to run open-ended software in the user's browser, in a sandbox. For example, the VNC viewer is a java applet. But this particular application of applets was not necessarily what was envisioned when applets were first added to web browsers. I'm thinking of useful applications of java applets, not the latest flashing, blinking, twitching, scrolling seizure inducing eye candy.
Similarly, I don't want to see media players go away. (But I would like to see the demise of proprietary controlled formats.)
One solution is to link the applet capability and the media player capability directly into the browser. Then you probably don't violate this patent.
With an open enough Java implementation, Mozilla for instance, could just include the ability to run java applets.
With an open enough real-player implementation, Mozilla could probably also directly link that code right into the browser.
In fact, Mozilla, or more generally, Open Source browsers could become the "rich" cousins, while proprietary browsers become the feature poor cousins. This would be very ironic.
My only beef with flash is that (1) it is not a "standard", and (2) implementations are proprietary, and therefore only available or easily available on the right platforms.
Getting rid of Flash plug ins might give SVG a fighting chance to displace it. (Can someone please provide a link to svg?)
This might be a motivation for Microsoft geeks to get excited about building a good SVG implementation into IE. I think other browsers (Mozilla?) already are working on this?
it's impossible for any company to be sure of that
That's the way the big players want it. Do you seriously think that there is any software you could possibly write that doesn't infringe on one or patents from IBM, Microsoft, Lucent, etc.
That way, if you ever sue them, they will countersue for patent infringement. IBM carefully selected four patents that affect all of SCO's products. When IBM gets a preliminary injunction, then SCO will have all of their revenues cut off. Plus expensive patent suits to defend by either (1) proving they don't infringe, or (2) proving the patent is invalid. In either case, IBM could just come up with a fifth or sixth patent infringement to keep the whole expensive patent infringement suits going while keeping SCO's revenue cut off.
So why didn't IBM file 2000 patent suits instead of only four? So that they don't look like they are gaming the system and fall into disfavor with the judge. (Plus the ability to add the fifth or sixth patent suit later to keep them running sequentially instead of concurrently.)
It would still be possible for her to have music with an md5 hash the same as a file on the Napster network. If they were ripped with the same encoder/bitrate/id3 tag as the Napster version, it's possible for md5 to be the same.
It is also possible that, as someone else suggested, the magical mp3 fairy left those files behind on her hard drive. In fact, I would propose that the mp3 fairy theory is even more likely.
The only way that the MD5 hashes could be identical is if the two files are absolutely identical in every single bit.
It is not possible (okay, unlikely, but unlikely enough for me to say not possible) to have two different files with the same MD5 hash. And definitely not likely by accident.
If even one single bit of the file is changed, then approximately 50 % of the bits of the MD5 hash will change. What cryptographers call "good diffusion properties". Good enough to trust for digital signatures, secrets, etc. You sign the MD5 hash of a document, because nobody else will have a document with the same hash.
To preempt one of the inevitible replies let me state: yes I know that you could have two different files, in theory that have the same MD5 hash. After all the files are much larger than the MD5 hash of 128 bits. Multiple files hash to the same value.
But the whole point of the design of MD5 is such that you can never create or discover any two such different files that hash to the same value.
If you were to examine 2^127 different files, then you would have a 50% chance of one of them giving you the desired MD5 hash. Do you know how large 2^127 is?
I would say that there is better than a 2^127 chance that the mp3's were left behind by the magical mp3 fairy.
Slashdot Mirror
Unlike you, now that I see there is room for doubt in my position, instead of simply continuing to assert I intend to actually do some research
You need to seriously lighten up.
I had read my facts somewhere reliable before. I just don't remember where. Now it is clear that it was the cd paranoia faq.
I did express doubt in my original assertion.
Keep JAVA out of browsers it simply doesn't belong there. I hate when the JVM takes 15 seconds to load up and 60MB of RAM just to view a f'ing webpage.
Being able to have java applets in web pages is very useful. Did I mention VNC viewer applet? SSH applet?
Java applets (or a similar technology) should used instead of ActiveX controls. Being able to "program" what happens in a remote browser (i.e. viewer) is an important capability.
Flash is the wrong approach to this. SVG and/or applets are better because they can be applied to a wide range of browsers, not just the most proprietary ones.
Nobody is making you load up Java. Nobody is making you go to certian web pages. I'm sure that there can be a choice and variety of browsers. You can even use lynx if you wish. But don't advocate making everyone's browser feature poor. What I am advocating is that we should try to promote open standards as much as is possible in making browsers feature rich. And using the smallest set of technologies that give the biggest set of capabilities. Why have Flash when either SVG or a Java applet could have done the same thing, for instance.
After I posted this, some have already tried the experiment. Some get the same result, others do not. Someone even pointed out that the CD Paranoia FAQ makes it clear that you cannot expect the same results of ripping the same CD even on the same drive!
My point is that I am not making wild assertions.
I think the moon is made of green cheese, but don't ask me to prove it.
Of course, you are entitled to your opinion on this just as you are entitled to believe that ripping the same CD on the same drive with the same software gives the same WAV file.
could just be that you used the same encoder/settings (i.e. iTunes on a default of 128k or 192kbps). Then the content would be exactly the same as someone else who legitimately ripped a copy on their computer in the same way.
Very unlikely. See other posts here. Some have even conducted the experiment I suggested and gotten the results I expected. While the mp3 encoding process may be exact, the cd-ripping process is not. Same CD. Same Drive. Same Softare. Different WAV files resulting.
Let's see, we're going to link a JVM and a media player into a web browser? And people think Mozilla is bloated already.
Who thinks it is bloated? Not I. It is well under 100 MB at present. In fact, only a little over a tenth that. (Compressed install file.)
There are good cases for directly linking in a JVM. It is a general tool that gives web designers all kinds of flexibility. Same type of logic as having other features such as frames, tables, multiple image formats (why should we link in PNG support?). Why should Mozilla have DOM, DHTML?
But I would NOT be in favor of linking Flash, or RealPlayer directly into Mozilla. These are not open source for one. And they are tools to control browser market share for another.
My opinion would be: have DOM, DHTML, CSS, and introduce SVG to replace Flash. Add or keep JVM for applets.
This leaves the problem of just how do you play media files? I would of course like it if somehow the proprietary formats got left out in the cold and only open formats prevailed, such as mpeg, or ogg video somethingorother.
I also ran lame with default settings (makes a 128K CBR) on both WAVs and got different sums there as well.
This part is not at all surprising. Even one single bit difference in two files would give radically different MD5 hashes.
Different drives, with the same disc, and identical software, certainly do give different results. Just tested. Identical versions of cdparanoia live on both systems.
This part is the really interesting result. Two different rips, same software, same CD, give different results on different drives. I think cd paranoia says something about "digital jitter" whatever the heck that means?
I'd say that I'd be amazed if this DIDN'T happen regularly.
I'd be amazed if it DID happen at all.
The mp3 coding process is exact, as you speculate. The CDDB process is probably exact.
I believe that the cdparanoia (i.e. ripping) process is not as exact as you think. An easy way to confirm this is:
1. Rip the same track, same CD, twice into two WAV files.
2. MD5 hash each of the two files.
Do you get the same MD5 hash? If not, then although the two WAV files may sound the same, they aren't actually the same bits.
I think the ripping process has a lot of variability. Sorry I don't have handy any references for this. But I believe I have represented it correctly.
A single bit difference gives you a vastly different MD5 hash.
Could someone make a MP3 from MD5 generator?
First let's talk about theory. Yes you could. There are an infinite number of mp3 files that will give you the same MD5 checksum. Some of them will be works of genius, and some of them will be absolute crap. Some of them will be appropriate for children, and others will not.
Now let's talk about practice. No you could not. You would need to examine 2^127 files in order to have a 50 % chance of one of those files having a certian predetermined MD5 hash. This is a big number. How many stars are there in the entire universe again? And just how big is 2^127?
Both are equally likely.
Better to say... both are equally unlikely.
Probably because open source people see this as patent abuse. Ten years ago, nobody would think it wise to spend time and money filing for numerous obviously stupid patents. Why would we? Only now is it becomming obvious why you need a large stable of obviously stupid patents. To fight off the same but now grown up bullies that used to stuff you into a locker in high school.
Try the following: Install some CD ripping/encoding software. Leave it at the defaults. Use CDDB to generate the ID3 tags. Unless something gets corrupted, that *will* produce an identical file, down to the last bit.
You may be right. I'm not sure. I have some doubts about the ripping process being as exact as you say. I agree that the mp3 encoding process is exact. Same input file, same settings, ---> same output file.
It depends on what you mean.
Let's clarify terms.
RIP: we'll use this term to mean running, say, cdparanoia to "rip" the track from a CD into a WAV or AIFF file. (lossless)
Encode: we'll use this term to mean transforming a lossless audio format into an mp3 format.
If everyone had the same WAV file, then you are correct. Same encoder, same settings, same ID3 tags ---> same MD5 hash.
But everyone won't start with the same WAV file. If you run cdparanoia twice to rip the same track you will get different WAV files. This does not seem intuitive, but it is apparently true. There are apparently a bunch of complex factors that affect the ripping process.
I suppose an easy test of this would be to rip the same track twice and compre the MD5 hash of the two WAV files. (Don't bother encoding with mp3.) Then you would prove or disprove what I am saying. Sorry I don't have any references on this.
You point out a very real danger.
If you just alter the ID3 tags without altering the mp3 content, then they can nail you. If simply altering id3 tags becomes commonplace because everything thinks it is the easy, trivial implementation, then they will nail you by checking the hash of the content. Identical content with trivially altered ID3 tags is a very good argument that you got this file from the thousands of other people who have the same hashed file with trivially altered ID3 tags.
I'm proposing a non-trivial, but not that conceptually complex alteration to the content that alters it in an imperceptable way. In fact, whether the alteration seems complex to you is irrelevant. After all, it is just a command line tool to you anyway, just like altering ID3 tags. You don't care how it is done. Run this tool on your mp3 file, it randomly affects an imperceptable alteration to one of the gazillions of 11-byte frames in the file.
However I doubt that they will go to such trouble -- if they have access to your files you're pretty much caught red-handed. A different MD5 checksum won't get you off of the hook here.
They might have access to your files if you are sharing them.
I think the original argument is that Jane Doe was sharing files. Jane claims the sharing is unintentional. Jane claims that the mp3's on her hard drive are her own rips of CD's she owns. The MD5 hash proves otherwise. This sub-discussion is about altering mp3's so that hashing is now useless at tracking the source of where you got an mp3 from. In the Jane Doe scenerio, a comples mp3 alteration to foil the MD5 hash would actually be useful.
Merely altering the ID3 tag such that the RIAA can also alter the ID3 tag back to what it is in the wild, and get identical MD5 hashes is a very strong argument against Jane Doe.
KFG (You insensitive clod) :-)
Sorry I missed it the first time. I get it now upon closer inspection.
Why on earth would you destroy the quality of your mp3 by decoding/re-encoding the music when all you have to do is change something in the IDv.x tags? Someone could, more easily, write a program that adds a random letter to the "Comments" field of IDv3.
I didn't say to destroy the quality of your mp3.
Decode one single 11 byte frame. Alter one bit. Re-encode it. In fact, as I understand things, the sound is stored as the sums of frequencies (FFT) or something like that. (Not an expert on this.) You could probably just alter one bit in the correct frame such that you add a new blip of a frequency at an imperceptably low amplitude.
Another possibilty is that there may be "zero" or "unused" bits in some header fields. Hypothetical example, in some bit field, 3 bits are not yet defined. Simply define tham as RIAA bits. But this gives limited possibilities to obscure the hash.
Another possibility is to alter or add one frame of "silence" at the beginning or end. If there is already a frame of silence, then alter that in an imperceptable way.
There may be other kinds of imperceptable alterations that can be made to mp3's.
Two consecutive frames may indicate the same set of frequencies being played at this moment in time, but at slightly different amplitudes. Swap the two frames. Or alter by one bit the amplitude of one of the frequencies that is least audible, such as deep bass. Or alter the start time of when a particular frequency starts or ends by an iimperceptable amount.
I'm talking about changes such that even if you have a 10th generation copy that has had 10 random alterations done, each by one person in the chain of handoffs from the person who originally ripped it, you have a "perfect" quality mp3, as far as mp3 "quality" goes.
SCO's revenue source is Microsoft making donations to its legal fund, errrrr, licensing Unix and Linux.
True, but... Red Hat and IBM has asked for court to shut SCO's loud mouth until trial in April 2005. The combined effect is that the FUD will stop. SCO can't spread fud, and it is inevitable that SCO will loose in court, which they now can't back out of -- without a settlement being reached. So Microsoft can pay as much as they want, but if SCO can't spread FUD, then what is the point.
KFG
You misspelled KFC.
hey sign cross licensing agreements with each other stating that they won't sue
This is not what a cross licensing agreement says.
The typical big company cross licensing arrangement goes like this. Okay, we've settled our dispute. Let's not bring patents into the war. (Like nuclear weapons.) So we will cross license eash other with each other's patents. I now have rights to all of your patents, and you have rights to all of my patents. This forecloses the possibility that you will ever sue me over any of your patents. But you still might sue me because I give you defective copies of Windows because I don't like the way you cozy up to Linux.
what's stopping people from simply changing a letter in the mp3 info tag (the trivial approach) or a bit or byte somewhere in the file? Good luck matching my file to anything.
Well there are several things that could stop you. You could get the latest MISD (Microsoft Internet Social Disease), etc.
But if you don't, then short of other things stopping you, such as getting run over by a truck, you merely need to change one single bit in the file to have a very different MD5. That bit does NOT need to be in the ID tag. You could just decode one single mp3 frame, randomly selected from the file, alter one bit of the sound, and then re-code that single mp3 frame.
It is even possible that someone might be inspired to write a tool to do this. It would defeat a lot of the previous Slashdot discussions about using MD5 to indicate "good" downloads before you download them. But maybe trust relationships of the P2P swappers themselves, using private keys, is a better idea than trusting the download file.
This could actually be good for open source browsers. See two of my previous posts. SVG and especially see Java applets
What exactly is the thinking behind these juries which award judgements on stupid patents like these?
They could be thinking about their dislike for Microsoft.
"My daugher's computer with Windows ME is less than two years old, and I had to take it to the shop and pay a huge amount to get Windows fixed. And a bunch of my files were lost."
They could also be thinking of negative experiences they might have had related to NOT having the right plug in for some favorite web site.
Just a theory. You asked.
While I would love to see the demise of Flash in favor of SVG, I would be sad to see Java Applets go away.
It is good to have a way to run open-ended software in the user's browser, in a sandbox. For example, the VNC viewer is a java applet. But this particular application of applets was not necessarily what was envisioned when applets were first added to web browsers. I'm thinking of useful applications of java applets, not the latest flashing, blinking, twitching, scrolling seizure inducing eye candy.
Similarly, I don't want to see media players go away. (But I would like to see the demise of proprietary controlled formats.)
One solution is to link the applet capability and the media player capability directly into the browser. Then you probably don't violate this patent.
With an open enough Java implementation, Mozilla for instance, could just include the ability to run java applets.
With an open enough real-player implementation, Mozilla could probably also directly link that code right into the browser.
In fact, Mozilla, or more generally, Open Source browsers could become the "rich" cousins, while proprietary browsers become the feature poor cousins. This would be very ironic.
My only beef with flash is that (1) it is not a "standard", and (2) implementations are proprietary, and therefore only available or easily available on the right platforms.
Getting rid of Flash plug ins might give SVG a fighting chance to displace it. (Can someone please provide a link to svg?)
This might be a motivation for Microsoft geeks to get excited about building a good SVG implementation into IE. I think other browsers (Mozilla?) already are working on this?
it's impossible for any company to be sure of that
That's the way the big players want it. Do you seriously think that there is any software you could possibly write that doesn't infringe on one or patents from IBM, Microsoft, Lucent, etc.
That way, if you ever sue them, they will countersue for patent infringement. IBM carefully selected four patents that affect all of SCO's products. When IBM gets a preliminary injunction, then SCO will have all of their revenues cut off. Plus expensive patent suits to defend by either (1) proving they don't infringe, or (2) proving the patent is invalid. In either case, IBM could just come up with a fifth or sixth patent infringement to keep the whole expensive patent infringement suits going while keeping SCO's revenue cut off.
So why didn't IBM file 2000 patent suits instead of only four? So that they don't look like they are gaming the system and fall into disfavor with the judge. (Plus the ability to add the fifth or sixth patent suit later to keep them running sequentially instead of concurrently.)
It would still be possible for her to have music with an md5 hash the same as a file on the Napster network. If they were ripped with the same encoder/bitrate/id3 tag as the Napster version, it's possible for md5 to be the same.
It is also possible that, as someone else suggested, the magical mp3 fairy left those files behind on her hard drive. In fact, I would propose that the mp3 fairy theory is even more likely.
The only way that the MD5 hashes could be identical is if the two files are absolutely identical in every single bit.
It is not possible (okay, unlikely, but unlikely enough for me to say not possible) to have two different files with the same MD5 hash. And definitely not likely by accident.
If even one single bit of the file is changed, then approximately 50 % of the bits of the MD5 hash will change. What cryptographers call "good diffusion properties". Good enough to trust for digital signatures, secrets, etc. You sign the MD5 hash of a document, because nobody else will have a document with the same hash.
To preempt one of the inevitible replies let me state: yes I know that you could have two different files, in theory that have the same MD5 hash. After all the files are much larger than the MD5 hash of 128 bits. Multiple files hash to the same value.
But the whole point of the design of MD5 is such that you can never create or discover any two such different files that hash to the same value.
If you were to examine 2^127 different files, then you would have a 50% chance of one of them giving you the desired MD5 hash. Do you know how large 2^127 is?
I would say that there is better than a 2^127 chance that the mp3's were left behind by the magical mp3 fairy.