The document is mostly about the Special 301 process, but they've used the opportunity to comment on US law:
on DMCA notice and takedown:
[...] the world in the image of the DMCA, a world in which millions of automated cease-and-desist requests based on computer-generated allegations automatically trigger the blocking and take down of material, including of lawfully posted material, all without any due process or any judicial involvement.
About DRM ("rights against circumventing TPMs"):
[...] the desires of certain rightsholder constituencies which seek to ban activities that are permitted under the copyright laws through the backdoor of a digital technological lock.
wrong-headed policy; [...] cripple their own industries' innovation and damage the welfare of their own consumers.
There is nothing new to the average Slashdot reader in there; it's saying the same as many here have already ranted: DMCA is bad, DRM is not about copyright but a backdoor to gain more control over customers, and it is silly and damaging.
But considering which companies this text comes from, I'd say this is some quite strong language that can not be misunderstood by US law makers.
Which is exactly what *does* happen a lot. This is a "hobby" of many "vigilantes"
Some drones have builtin uninstall commands, others have commands to download and execute programs, so cleaners are written.
But the drones are getting more and more advanced, builtin uninstall commands are getting more rare... it is clearly a battle that can not be won if only fought this way.
Finding them really is not the problem. Opers have nice tools/services for that (at least on some big networks), drone connection/channel detection notices scrolling by as fast as you can read...
It's the dissecting and cleaning part that's hard, and getting harder and harder as kiddies are getting "smarter".
Signing such a non-plaintext file by looking at it in a viewer only (and (a bank) accepting such a signed document) is the mistake. You don't even need MD5 collisions to exploit that.
Suppose you write a HTML file with some java-script embedded that displays one text if the date is before X, and another if it's after. you get someone to sign it before X, and then use it afterwards.
Similar, in general, different viewers interprete (broken) files differently. So if you know which viewer the signer and the bank use, you could probably write a postscript file that displays different text in those viewers.
No checksum or cryptographic mechanism is going to prevent that. Nor is displaying files differently than other viewers a security problem that should be fixed in every viewer.
So the only way to prevent this, is not signing "binary" files (not fully plain text human parsable) written by someone else.
No, I don't think they're important.
Signing such a non-plaintext file by looking at it in a viewer only (and (a bank) accepting such a signed document) is the mistake. You don't even need MD5 collisions to exploit that.
Suppose you write a HTML file with some java-script embedded that displays one text if the date is before X, and another if it's after. you get someone to sign it before X, and then use it afterwards.
Similar, in general, different viewers interprete (broken) files differently. So if you know which viewer the signer and the bank use, you could probably write a postscript file that displays different text in those viewers.
No checksum is going to prevent that. Nor is displaying files differently than other viewers a security problem that should be fixed in every viewer.
So the only way to prevent this, is not signing "binary" (not fully plain text human parsable) files written by someone else.
Actualy reading the announcement would have answered your question:
"In the meantime, we were also asked why we decided to go with KDE 3.2,
and if it would be possible to go with KDE 3.3 instead. The main reason
is that KDE 3.3 in unstable started with some RC bugs, and there was no
proposal from the KDE team how to proceed. The door is only closed, but
not locked for KDE 3.3. We are still open for proposals how to sort the
KDE 3.3 issues out, and there has been some productive discussion of
late about that - but no final decision yet."
Slashdot Mirror
[...] the world in the image of the DMCA, a world in which millions of automated cease-and-desist requests based on computer-generated allegations automatically trigger the blocking and take down of material, including of lawfully posted material, all without any due process or any judicial involvement.
[...] the desires of certain rightsholder constituencies which seek to ban activities that are permitted under the copyright laws through the backdoor of a digital technological lock.
wrong-headed policy; [...] cripple their own industries' innovation and damage the welfare of their own consumers.
There is nothing new to the average Slashdot reader in there; it's saying the same as many here have already ranted: DMCA is bad, DRM is not about copyright but a backdoor to gain more control over customers, and it is silly and damaging. But considering which companies this text comes from, I'd say this is some quite strong language that can not be misunderstood by US law makers.
The name actually used is "drone hunters"
Which is exactly what *does* happen a lot. This is a "hobby" of many "vigilantes"
Some drones have builtin uninstall commands, others have commands to download and execute programs, so cleaners are written.
But the drones are getting more and more advanced, builtin uninstall commands are getting more rare... it is clearly a battle that can not be won if only fought this way.
Finding them really is not the problem. Opers have nice tools/services for that (at least on some big networks), drone connection/channel detection notices scrolling by as fast as you can read...
It's the dissecting and cleaning part that's hard, and getting harder and harder as kiddies are getting "smarter".
Signing such a non-plaintext file by looking at it in a viewer only (and (a bank) accepting such a signed document) is the mistake. You don't even need MD5 collisions to exploit that.
Suppose you write a HTML file with some java-script embedded that displays one text if the date is before X, and another if it's after. you get someone to sign it before X, and then use it afterwards.
Similar, in general, different viewers interprete (broken) files differently. So if you know which viewer the signer and the bank use, you could probably write a postscript file that displays different text in those viewers.
No checksum or cryptographic mechanism is going to prevent that. Nor is displaying files differently than other viewers a security problem that should be fixed in every viewer.
So the only way to prevent this, is not signing "binary" files (not fully plain text human parsable) written by someone else.No, I don't think they're important. Signing such a non-plaintext file by looking at it in a viewer only (and (a bank) accepting such a signed document) is the mistake. You don't even need MD5 collisions to exploit that.
Suppose you write a HTML file with some java-script embedded that displays one text if the date is before X, and another if it's after. you get someone to sign it before X, and then use it afterwards.
Similar, in general, different viewers interprete (broken) files differently. So if you know which viewer the signer and the bank use, you could probably write a postscript file that displays different text in those viewers.
No checksum is going to prevent that. Nor is displaying files differently than other viewers a security problem that should be fixed in every viewer.
So the only way to prevent this, is not signing "binary" (not fully plain text human parsable) files written by someone else.
Similar stuff been covered before in:
Brain Controlled Computing a Reality
Playing Games With One's Brainwaves
Brain Chip Approved For Paralysis Research
Brain Controlled Tightrope Video Game Shown
So "what's new"? Is it a new technique this time, has major progress been made? If so, what's the big difference compared to the previous articles?
Actualy reading the announcement would have answered your question: "In the meantime, we were also asked why we decided to go with KDE 3.2, and if it would be possible to go with KDE 3.3 instead. The main reason is that KDE 3.3 in unstable started with some RC bugs, and there was no proposal from the KDE team how to proceed. The door is only closed, but not locked for KDE 3.3. We are still open for proposals how to sort the KDE 3.3 issues out, and there has been some productive discussion of late about that - but no final decision yet."