The problem here is that there is no redistrubition, per se. Gator is like Proxomitron is like Webwasher, and whatever else: it's running on your machine, changing content for the final client (you).
If your ISP ran a Gator-filter, Proxomitron-filter, or anything like that on their pipes, the key here is that they are *redistributing* the changed content to all of their customers. That is where it becomes illegal (IANAL). It's the difference between you clipping out the ads on a magazine you've purchased versus buying a lot of magazines in bulk, clipping out the ads, and then reselling them (or even giving them away, possibly).
I believe your argument that Gator (et. al.) are redistributing the content is flawed. If you moved "Gator" so that it looked like Web page -> ISP (in) -> Gator filter -> ISP (out) -> computer (...), then I would agree with your argument.
As it stands, however, it smells an awful lot like fair use (the fact that people didn't intentionally install it notwithstanding).
Slightly unrelated, is my using a text browser like W3M to browse ad-laden web pages illegal because I'm not seeing it how the site designer intended? To add to the matter, W3M will let me selectively view the images on a page if it is running on X, so it's almost like image blocking, but in reverse. The answer to my rhetorical question is "no," by the way.
Let me cap this all with the statement that I still think Gator deserves to be punished, but not for reasons that relate to (supposed) copyright infringement.
Here's a tweak that avoids the crontab step. Fetchmail has the built-in ability to run in the background and to check your mail automatically every N seconds (fetchmail -dN, where N is the number of seconds to wait between fetches--I use -d600 for 10 minutes). Just add the following line to ~/.forward
|/usr/bin/procmail
Make sure to check your mail server's docs to verify that is how it likes piping in.forward (I use exim). Then just run fetchmail -d600 from your ~/.bash_profile or so forth (there is a way to run fetchmail as a system service, but it's got some gotchas and isn't as easy).
If I had to guess without consulting documentation, I'd say: :(){ #define function ':' which takes no arguments :|:& # call ':' and pipe its output into # another running copy of itself, running # this in the background }; #end of function : #call our function
More readably: function destroy () { destroy | destroy & }; destroy
Note that each call to : will recursively expand into no fewer than two calls, both which again invoke two new copies, so it expands very quickly. Since you probably have no shell restrictions by default, it did the same thing a fork bomb would: fill your process table instantly and consume all your memory and processor time.
If you use bash (or probably any bash-like shell), you may have ulimit available. With ulimit's -u switch, you can set how many processes you may start and probably avoid the situation you described. I believe there are similar ways to achieve this in the kernel (probably by recompiling), but I'm not familiar enough to tell you how.
As a general rule, don't run suspicious code (e.g., code found in.sigs on slashdot:) that has &'s in it. That function would be easier to stop (using Ctrl-Z or Ctrl-C) if it didn't use & (which disconnects the keyboard from the program's stdin/stdout).
I hope this post has been informative enough to outweigh its off-topic nature.
2>/dev/null redirects error messages from the command (and anything else written to stderr, which is file descriptor 2) to the null device. It keeps error messages from showing up. When > is used alone, it implicitly redirects standard output, which is file descriptor 1 (so it's the same as 1>something).
More interesting (and often obscure to new users) ways to redirect streams can be found here.
For a while I couldn't figure out how to make the paper size for the printer (File, Printer settings) stay at Letter: it would always switch back to A4 after restarting the application.
After some searching, I found the answer: edit file/.../OpenOffice.org641/share/psprint/psprint. conf and change line 45 (PPD_PageSize) to "PPD_PageSize=Letter". As far as I know, there is no way to do this from within the application itself.
Also note that this is regarding the Linux version of the 641D release (though it probably works elsewhere).
I still haven't figured out how to change the default style rules without creating (and always having to instantiate) a custom template. If anyone knows how, would you please share? Searching google, google groups, OO.o's issuezilla, and OO.o's mailing lists didn't turn up any good results for me.
(Do we *really* need to be running our network services as root just so that they can bind to a low-numbered port?)
I suspect you knew this already (and just added that comment for effect), but that problem has been solved at least twice, with the LIDS patch and NSA's SELinux. Both accomplish this by untying capabilities from the user-id (such that, for example, a program can be given permission to bind to low-numbered ports while receiving no other advanced privileges).
It's not just any sponge--it's SpongeBob SquarePants!
[*ducks*]
Well, there's always make -n
on
Linux Virus Alert
·
· Score: 2, Informative
Personally, I always run make -n install just to see what it is going to do (it's easier than opening the file if I think it already has the right paths set). It's one of those extra steps that Just Make Sense (TM), like prepending 'echo' when you rm with -r or with wildcards as root. You'll be glad you did when you look at the output, slap your forehead, and breath a sigh of relief. =)
Extra sidenote: if you're compiling a program that uses GNU autoconf (etc.) to configure the makefile, you might be interested in the --prefix= option (where you can tell most sane programs to install somewhere other than the default). I always install to a test directory in my home directory before going system-wide (so I can, say, test a new version of an app).
I agree with you about the usefulness of TOC for simple needs.
To correct a minor nit, though, the "changing" you refer to was never really a protocol change. It was discovered that AOL had the ability to request the md5 hash of an arbitrary portion of the client: what they would change was the offset/length the server would request.
Specifically, for those who don't wish to click the link:
When the server sends the 0001 001f SNAC, it also sends an offset and a length as the data content. You then read the specified number of bytes from a file (I'll tell you which file later, though you've probably already guessed), starting at the specified offset. It's then run through md5 (which outputs 16 bytes), and is sent back to the server. (4th paragraph down in the link)
Technically, Gaim is still susceptible to attempts at disconnecting it (I think--since it doesn't have the official client to get md5's from), but a solution for that problem already exists in Jabber's aim-transport: you tell it where you have a copy of AIM (a specific version, when I last updated it, which was ages ago), and it will always respond to the server with the right md5 hash (unless they decide to lock out a certain version of their client--unlikely).
Just add --spider to your list of options and it will merely access the specified URLs and not download them (I use it in a script to help me move around my slashboxes when I feel like redecorating without reloading the full front page 20 times).
This is most likely what it is. I've spent time at a nonprofit organization, and client licenses for the software they use (various flavors of windows and office 2000, at least) are often in the below-$30 range (with volume buying and the Open License program). A (possibly significant) part of that discount is due to the fact that it is a nonprofit organization. Chances are that they'll (MS will) make the deal even sweeter if they think the schools are 'in danger of' switching to Free software (or just non-Microsoft software, probably).
Alternatively, you could get StartupCPL, a tool that collects and lists the entries in the appropriate registry locations. You're still left with checking autoexec.bat and win.ini, but this has been very convenient for me on many occassions. It has no cost, but the source isn't available.
If you want to try installing Linux without sacrificing Windows (and you've decided against risking non-destructive repartitioning), RedHat and others (if RH does it, Mandrake surely does; I didn't look to see if Debian will do it as a default installation option) offer the ability to either install as a big FAT file (containing the ext2 filesystem) or as files on an existing FAT partition (a less optimal solution, but available if necessary). I know I've set up more than one dual-boot on computers used by average folk (it defaults to Windows after a few seconds) without any problems (though readjusting the screen when switching OSes is a pain). These ideas may be good compromises that allow you to demonstrate Linux without bringing scary (to more casual users) repartitioning into the question.
You were right up to a month or two ago, but they moved it to shareware (I don't know if they added nags, I haven't upgraded) as of 7.0 (see the FAQ for their words). It was sad, since that was the first (and only) GUI-based archiver that supported my favorite format (bzip2) and was free (gratis) to boot. I guess the dot-com/advertising-revenue fallout hit them as much as everyone else.
I agree with your assessment about them not wanting people to redistribute their SDK (in particular, with Openly/Freely licensed code), but the phrase, "not using Potentially Viral Software (e.g. tools) to develop Recipient software which includes the Software, in whole or in part" (emphasis mine) is what bothers me.
Maybe it means something else in legalese, but the way I read it leads me to believe that you couldn't use, say, Emacs to develope software (they don't specifically mention the developed software's license). Basically, it seems to me like they're trying to force developers under this license to use only non-Free editors.
I hope it's just my lack of understanding regarding legalese at fault here, and I would hope that someone would point it out if my interpretation is way off-base with fact.
I see lots of posts suggesting that the only thing the Indrema had going for it (or the only thing that made it different) was running Linux. I beg to differ.
The reason I was hoping Indrema would make it was because of their licensing policy. As I recall, a game developer could get a FREE (as in beer--I don't remember about speech) SDK for it, AND you could release games that would run on other machines without purchasing a (costly) license from them.
That was supposed to be the revolutionary aspect: you could have small-time artists or game developers releasing non-commercial (potentially high-quality) games without going broke. Parsec (http://www.parsec.org) is an example of a pretty decent non-commercial (gratis, not libre) game for the PC. Had they been trying to produce this for a console, how would they have been able to afford licensing costs?
With Indrema, you (and possibly a group of your friends) could develop and distribute a game (for no charge, if I remember the conditions correctly) that would work on other Indrema consoles with minimal or no (I don't remember) money out-of-pocket.
Somehow, I think the Indrema was infinitely better for this aspect than for "doing a Linux gaming console". I am by no means an expert on console game development licenses, so by all means correct me if I'm wrong.
In the past, it was possible--though not too easy--to simply locate where the XPIs are which the installer downloads (it's on Netscape's FTP site somewhere) and download them into the same directory as the installation program. It seems to be intelligent enough to check the current directory before trying to download the files. So to get it at work, just download all the XPI files and save them with the main installer.
The incomplete URL is ftp://ftp.netscape.com/pub/netscape6/[language]/6. 0/[platform]/[platform2]/xpi
where [language] is one of english, english_uk, french, german, or japanese (some might be incomplete); [platform] is unix, windows, or mac; and [platform2] is linux22, win32, or macos8.5 (respectively). Hope that helps.
Once again, you seem to make a degree of assumptions about how the user agent will operate. Keep in mind that the spec is presumably open, which means any and all Free (note the capitalization) browsers can implement it. I thought the whole reason (well, one reason) we had Free software was because users were tired of subjecting themselves to companies' desires and assumptions. Just like there is a way around cookies, there will probably be a way around P3P (yes, I leave the cookie notification on, but I also filter cookies out at a proxy, so I still confirm the few cookies I opt to receive [which pass through the proxy]). It seems to me that you ignore the existance of Free browsers (which, even if they don't do things as you would want them done, give you the ability to tweak and recompile).
Note that my primary reason for supporting P3P is because W3C is a primary supporter (and if the support of major companies precludes a protocol being Good, than you might as well paint HTTP as satanic). I've never seen the W3C act blatantly in contempt of people's rights and personal choices (please note that I don't closely monitor everything they do, so if you have a link that demonstrates the opposite, please provide it).
One might construe that I'm in support of P3P by my constant defenses of it, but this is not entirely so. I doubt I will ever use it personally--and if I do, it will likely be with falsified data. I just don't like to see a seemingly well-intentioned protocol bashed for potential abuses (I've seen/. defend cookies before, though they played a primary role in DoubleClick's fallacy and I still deny 99% of them). I know I used the 'I' word, but if you must reply with clichés, just don't reply.
Finally, a note to michael: I keep see you opposing this protocol, so I suspect you have good reasons for doing so. You could get your point across much more effectively if you provided pertinent links, IMO.
I certainly agree that it would be a grim day when your example situation became true, but nowhere in the specs did I see it mention denying entry based on not offering information (point me to a link if you disagree). I would imagine the server decides (or specifies in the policy) what happens if you refuse one of its requests, but it doesn't have to be complete denial of entry.
As I stated elsewhere, though, I would hope to be able to have domain-specific user policies (in Mozilla, I expect it the most:). One might specify one or two domains and leave the rest as deny-all, if one was so inclined.
Again, I agree that if denial-upon-refusal becomes the norm, there is potential for privacy degradation, but why would a site designer block out all hits from privacy-minded people? (for background, I block all cookies not comming from specifically-allowed sites, and almost never provide correct email addresses where I don't desire to establish long-term communication)
If it won't work without entering all the information, I doubt it will catch on (or will be rethought and reimplemented), but that is an implementation detail (if they specify that compliant UAs require that, please cite where!), and thus all but moot.
Having skimmed through those same specifications, I must agree with you. P3P doesn't seem to resemble cookies very much (since when did cookies let you selectively decide what to give out?). On the side of 'universal cookie', it does allow any conforming sites access to prescribed information, but they put users in control (which is always a good thing, as long as there aren't stupid defaults in UAs [user agents])--you first have to *specify* the data and your *policy* regarding that data. If you don't want sites to get certain personal information (Social Security number?? you've got to be kidding!), just don't enter it in the first place (granted, this assumes the UA would explicitly ask the user for it, instead of trying to glean it from other sources)!
Any further pontification is moot without an implementation on which to base it. For starters, I would hope a sane UA would allow you to store per-domain policies--I can think of several I'd certainly like to deny. The implementation of these specifications are the only places I could see justifiable complaints (I could imagine that IE, as integrated as it already is with the OS and with all the details you give it, could have toe potential to be a security-conscious person's nightmare, for example). Just don't jump to rash conclusions before.
Of course, if michael is reading this and can back up his assertion with proof, I would appreciate it.
For starters, I'm not a regular c't reader, but I stumbled across this page a week ago which seems to be by the people researching/designing the exploding CD. I could be incorrect, and this could be completely unrelated to the c't article, but these people talked about selling to the US, so it's either the same people or a striking coincidence.
A snippet:
For the past two years, deep in the heart of Switzerland, a small team of engineers and chemists have been working on the development and fine tuning of the ultimate CD destruction device.
I make no judgements on the truthfulness of the originally-mentioned article.
Slashdot Mirror
Who needs to read the article? If you wait long enough, it's already reproduced in a +4 or +5 comment. =)
The problem here is that there is no redistrubition, per se. Gator is like Proxomitron is like Webwasher, and whatever else: it's running on your machine, changing content for the final client (you).
If your ISP ran a Gator-filter, Proxomitron-filter, or anything like that on their pipes, the key here is that they are *redistributing* the changed content to all of their customers. That is where it becomes illegal (IANAL). It's the difference between you clipping out the ads on a magazine you've purchased versus buying a lot of magazines in bulk, clipping out the ads, and then reselling them (or even giving them away, possibly).
I believe your argument that Gator (et. al.) are redistributing the content is flawed. If you moved "Gator" so that it looked like Web page -> ISP (in) -> Gator filter -> ISP (out) -> computer (...), then I would agree with your argument.
As it stands, however, it smells an awful lot like fair use (the fact that people didn't intentionally install it notwithstanding).
Slightly unrelated, is my using a text browser like W3M to browse ad-laden web pages illegal because I'm not seeing it how the site designer intended? To add to the matter, W3M will let me selectively view the images on a page if it is running on X, so it's almost like image blocking, but in reverse. The answer to my rhetorical question is "no," by the way.
Let me cap this all with the statement that I still think Gator deserves to be punished, but not for reasons that relate to (supposed) copyright infringement.
Here's a tweak that avoids the crontab step. Fetchmail has the built-in ability to run in the background and to check your mail automatically every N seconds (fetchmail -dN, where N is the number of seconds to wait between fetches--I use -d600 for 10 minutes). Just add the following line to ~/.forward
Make sure to check your mail server's docs to verify that is how it likes piping in .forward (I use exim). Then just run fetchmail -d600 from your ~/.bash_profile or so forth (there is a way to run fetchmail as a system service, but it's got some gotchas and isn't as easy).
If I had to guess without consulting documentation, I'd say:
:(){ #define function ':' which takes no arguments
:|:& # call ':' and pipe its output into
.sigs on slashdot :) that has &'s in it. That function would be easier to stop (using Ctrl-Z or Ctrl-C) if it didn't use & (which disconnects the keyboard from the program's stdin/stdout).
# another running copy of itself, running
# this in the background
}; #end of function
: #call our function
More readably: function destroy () { destroy | destroy & }; destroy
Note that each call to : will recursively expand into no fewer than two calls, both which again invoke two new copies, so it expands very quickly. Since you probably have no shell restrictions by default, it did the same thing a fork bomb would: fill your process table instantly and consume all your memory and processor time.
If you use bash (or probably any bash-like shell), you may have ulimit available. With ulimit's -u switch, you can set how many processes you may start and probably avoid the situation you described. I believe there are similar ways to achieve this in the kernel (probably by recompiling), but I'm not familiar enough to tell you how.
As a general rule, don't run suspicious code (e.g., code found in
I hope this post has been informative enough to outweigh its off-topic nature.
2>/dev/null redirects error messages from the command (and anything else written to stderr, which is file descriptor 2) to the null device. It keeps error messages from showing up. When > is used alone, it implicitly redirects standard output, which is file descriptor 1 (so it's the same as 1>something).
More interesting (and often obscure to new users) ways to redirect streams can be found here.
For a while I couldn't figure out how to make the paper size for the printer (File, Printer settings) stay at Letter: it would always switch back to A4 after restarting the application.
/.../OpenOffice.org641/share/psprint/psprint. conf and change line 45 (PPD_PageSize) to "PPD_PageSize=Letter". As far as I know, there is no way to do this from within the application itself.
After some searching, I found the answer: edit file
Also note that this is regarding the Linux version of the 641D release (though it probably works elsewhere).
I still haven't figured out how to change the default style rules without creating (and always having to instantiate) a custom template. If anyone knows how, would you please share? Searching google, google groups, OO.o's issuezilla, and OO.o's mailing lists didn't turn up any good results for me.
No, real men use cat <<EOF | as > application . Why would you ever want to save your code? If it doesn't compile, you obviously need to rewrite it. :-)
Or you could send him a post-card.
. co m&server=magic
:)
http://samspade.org/t/whois?a=shifmanconsulting
(not linked to conceal link's origin
Got to love Whois.
I suspect you knew this already (and just added that comment for effect), but that problem has been solved at least twice, with the LIDS patch and NSA's SELinux. Both accomplish this by untying capabilities from the user-id (such that, for example, a program can be given permission to bind to low-numbered ports while receiving no other advanced privileges).
A whitepaper can be found for the NSA's solution, and reasonable documentation can be found for the LIDS project.
It's not just any sponge--it's SpongeBob SquarePants!
[*ducks*]
Personally, I always run make -n install just to see what it is going to do (it's easier than opening the file if I think it already has the right paths set). It's one of those extra steps that Just Make Sense (TM), like prepending 'echo' when you rm with -r or with wildcards as root. You'll be glad you did when you look at the output, slap your forehead, and breath a sigh of relief. =)
Extra sidenote: if you're compiling a program that uses GNU autoconf (etc.) to configure the makefile, you might be interested in the --prefix= option (where you can tell most sane programs to install somewhere other than the default). I always install to a test directory in my home directory before going system-wide (so I can, say, test a new version of an app).
I agree with you about the usefulness of TOC for simple needs.
To correct a minor nit, though, the "changing" you refer to was never really a protocol change. It was discovered that AOL had the ability to request the md5 hash of an arbitrary portion of the client: what they would change was the offset/length the server would request.
See the gaim explanation for details.
Specifically, for those who don't wish to click the link:
Technically, Gaim is still susceptible to attempts at disconnecting it (I think--since it doesn't have the official client to get md5's from), but a solution for that problem already exists in Jabber's aim-transport: you tell it where you have a copy of AIM (a specific version, when I last updated it, which was ages ago), and it will always respond to the server with the right md5 hash (unless they decide to lock out a certain version of their client--unlikely).
Just add --spider to your list of options and it will merely access the specified URLs and not download them (I use it in a script to help me move around my slashboxes when I feel like redecorating without reloading the full front page 20 times).
This is most likely what it is. I've spent time at a nonprofit organization, and client licenses for the software they use (various flavors of windows and office 2000, at least) are often in the below-$30 range (with volume buying and the Open License program). A (possibly significant) part of that discount is due to the fact that it is a nonprofit organization. Chances are that they'll (MS will) make the deal even sweeter if they think the schools are 'in danger of' switching to Free software (or just non-Microsoft software, probably).
Alternatively, you could get StartupCPL, a tool that collects and lists the entries in the appropriate registry locations. You're still left with checking autoexec.bat and win.ini, but this has been very convenient for me on many occassions. It has no cost, but the source isn't available.
If you want to try installing Linux without sacrificing Windows (and you've decided against risking non-destructive repartitioning), RedHat and others (if RH does it, Mandrake surely does; I didn't look to see if Debian will do it as a default installation option) offer the ability to either install as a big FAT file (containing the ext2 filesystem) or as files on an existing FAT partition (a less optimal solution, but available if necessary). I know I've set up more than one dual-boot on computers used by average folk (it defaults to Windows after a few seconds) without any problems (though readjusting the screen when switching OSes is a pain). These ideas may be good compromises that allow you to demonstrate Linux without bringing scary (to more casual users) repartitioning into the question.
You were right up to a month or two ago, but they moved it to shareware (I don't know if they added nags, I haven't upgraded) as of 7.0 (see the FAQ for their words). It was sad, since that was the first (and only) GUI-based archiver that supported my favorite format (bzip2) and was free (gratis) to boot. I guess the dot-com/advertising-revenue fallout hit them as much as everyone else.
Maybe it means something else in legalese, but the way I read it leads me to believe that you couldn't use, say, Emacs to develope software (they don't specifically mention the developed software's license). Basically, it seems to me like they're trying to force developers under this license to use only non-Free editors.
I hope it's just my lack of understanding regarding legalese at fault here, and I would hope that someone would point it out if my interpretation is way off-base with fact.
I see lots of posts suggesting that the only thing the Indrema had going for it (or the only thing that made it different) was running Linux. I beg to differ.
The reason I was hoping Indrema would make it was because of their licensing policy. As I recall, a game developer could get a FREE (as in beer--I don't remember about speech) SDK for it, AND you could release games that would run on other machines without purchasing a (costly) license from them.
That was supposed to be the revolutionary aspect: you could have small-time artists or game developers releasing non-commercial (potentially high-quality) games without going broke. Parsec (http://www.parsec.org) is an example of a pretty decent non-commercial (gratis, not libre) game for the PC. Had they been trying to produce this for a console, how would they have been able to afford licensing costs?
With Indrema, you (and possibly a group of your friends) could develop and distribute a game (for no charge, if I remember the conditions correctly) that would work on other Indrema consoles with minimal or no (I don't remember) money out-of-pocket.
Somehow, I think the Indrema was infinitely better for this aspect than for "doing a Linux gaming console". I am by no means an expert on console game development licenses, so by all means correct me if I'm wrong.
In the past, it was possible--though not too easy--to simply locate where the XPIs are which the installer downloads (it's on Netscape's FTP site somewhere) and download them into the same directory as the installation program. It seems to be intelligent enough to check the current directory before trying to download the files. So to get it at work, just download all the XPI files and save them with the main installer. The incomplete URL is ftp://ftp.netscape.com/pub/netscape6/[language]/6. 0/[platform]/[platform2]/xpi
where [language] is one of english, english_uk, french, german, or japanese (some might be incomplete); [platform] is unix, windows, or mac; and [platform2] is linux22, win32, or macos8.5 (respectively). Hope that helps.
Once again, you seem to make a degree of assumptions about how the user agent will operate. Keep in mind that the spec is presumably open, which means any and all Free (note the capitalization) browsers can implement it. I thought the whole reason (well, one reason) we had Free software was because users were tired of subjecting themselves to companies' desires and assumptions. Just like there is a way around cookies, there will probably be a way around P3P (yes, I leave the cookie notification on, but I also filter cookies out at a proxy, so I still confirm the few cookies I opt to receive [which pass through the proxy]). It seems to me that you ignore the existance of Free browsers (which, even if they don't do things as you would want them done, give you the ability to tweak and recompile).
Note that my primary reason for supporting P3P is because W3C is a primary supporter (and if the support of major companies precludes a protocol being Good, than you might as well paint HTTP as satanic). I've never seen the W3C act blatantly in contempt of people's rights and personal choices (please note that I don't closely monitor everything they do, so if you have a link that demonstrates the opposite, please provide it).
One might construe that I'm in support of P3P by my constant defenses of it, but this is not entirely so. I doubt I will ever use it personally--and if I do, it will likely be with falsified data. I just don't like to see a seemingly well-intentioned protocol bashed for potential abuses (I've seen /. defend cookies before, though they played a primary role in DoubleClick's fallacy and I still deny 99% of them). I know I used the 'I' word, but if you must reply with clichés, just don't reply.
Finally, a note to michael: I keep see you opposing this protocol, so I suspect you have good reasons for doing so. You could get your point across much more effectively if you provided pertinent links, IMO.
I certainly agree that it would be a grim day when your example situation became true, but nowhere in the specs did I see it mention denying entry based on not offering information (point me to a link if you disagree). I would imagine the server decides (or specifies in the policy) what happens if you refuse one of its requests, but it doesn't have to be complete denial of entry.
As I stated elsewhere, though, I would hope to be able to have domain-specific user policies (in Mozilla, I expect it the most :). One might specify one or two domains and leave the rest as deny-all, if one was so inclined.
Again, I agree that if denial-upon-refusal becomes the norm, there is potential for privacy degradation, but why would a site designer block out all hits from privacy-minded people? (for background, I block all cookies not comming from specifically-allowed sites, and almost never provide correct email addresses where I don't desire to establish long-term communication)
If it won't work without entering all the information, I doubt it will catch on (or will be rethought and reimplemented), but that is an implementation detail (if they specify that compliant UAs require that, please cite where!), and thus all but moot.
Having skimmed through those same specifications, I must agree with you. P3P doesn't seem to resemble cookies very much (since when did cookies let you selectively decide what to give out?). On the side of 'universal cookie', it does allow any conforming sites access to prescribed information, but they put users in control (which is always a good thing, as long as there aren't stupid defaults in UAs [user agents])--you first have to *specify* the data and your *policy* regarding that data. If you don't want sites to get certain personal information (Social Security number?? you've got to be kidding!), just don't enter it in the first place (granted, this assumes the UA would explicitly ask the user for it, instead of trying to glean it from other sources)!
Any further pontification is moot without an implementation on which to base it. For starters, I would hope a sane UA would allow you to store per-domain policies--I can think of several I'd certainly like to deny. The implementation of these specifications are the only places I could see justifiable complaints (I could imagine that IE, as integrated as it already is with the OS and with all the details you give it, could have toe potential to be a security-conscious person's nightmare, for example). Just don't jump to rash conclusions before.
Of course, if michael is reading this and can back up his assertion with proof, I would appreciate it.
For starters, I'm not a regular c't reader, but I stumbled across this page a week ago which seems to be by the people researching/designing the exploding CD. I could be incorrect, and this could be completely unrelated to the c't article, but these people talked about selling to the US, so it's either the same people or a striking coincidence.
A snippet:
I make no judgements on the truthfulness of the originally-mentioned article.