France might think they have the right to ask for it to be censored in their country, and they might be right about that, but ask for money? What makes them think Yahoo! should pay them? They are under US law. A disturbing trend indeed.
The thing is, there is a Yahoo presence in France (see the links at the bottom of www.yahoo.com). Since Yahoo is operating servers in France, they are within the reach of the French authorities.
there wasn't previously a way for websites to get information about you unless you made an explicit decision to give it to them. (Ways around this, like Doubleclick's ID-matching have been condemned.)
Condemned, but still used. And if the technique were more widely used it would be more trouble to duck. So a mechanism that gives the user more control of such activity is desirable. Whether P3P is the epitome of such mechanisms is debatable, but conceptually such a mechanism has its place.
So at best, the situation is the same as before - the user provides information only when they decide to, and they are always notified.
No, because the P3P mechanism provides not only information about what information is requested, but why. In current practice, the why is generally not readily apparent -- sometimes not available at all. The part of P3P that I find most appealing is the standardization of delivery of policy information to the end user. Once that information can be presented in a consistent, readily available manner, the lack of it would become a highly visible red flag.
Further, once you say yes, the user-agent will store those preferences so that next time you come back to buystuff.com, your info will be sent silently. As a convenience to you, of course.
Silently if I tell it to, I would venture. And presumably, once I say NO, the UA will store that response and silently (if I want) send it, too.
I claim the intent is the opposite because it is. Sorry if that seems like proof by assertion, but I've been watching P3P for some years now. If a bunch of major corporations spend a bunch of time on a protocol designed to transmit your personal information to them - that's what it does, and that's all it does - the intent is not for them to get less information from you. Where's the fiscal motive in getting less information? Okay, now where's the fiscal motive in getting more information?
The amount of data collected is not the issue to me. Your original assertion was that the intent is to collect data secretly. It seems to me that P3P is intended to aid data collection by giving the user more information about and control over the transfer of information. If that aids the collector of data by making it easier for me to decide what data to send, it also aids me by, er, making it easier to decide what data to send.
My impression is that you view any collection of information as being inherently bad. I don't. As long as the organization I'm giving the information to is explicit about the purpose of collecting the information and the manner in which it will be used, I'm satisfied. Mechanisms (P3P or otherwise) that streamline this process while still giving me control of it are welcome.
Think of how many sites you've been required to "register" with to use. Are they all out of business? Why not?
Hard to say. The ones that ask for what I consider to be excessive information don't get a repeat visit from me so I don't know their status. The ones that ask for a reasonable set of required information that they actually need (e.g., slashdot) seem to be doing nicely. The vast majority of Web sites don't ask for such information because they don't need it and they know that people are skittish about sending it. I see no reason to think that P3P changes any of that.
You would if it popped-up a box every time you went to a new website.
Why on earth would it do that? Again, you're arguing a worst-case scenario. And you're not giving much credit to the folks who write browsers. I envision a browser that lets me establish my personal policies: the data that I will allow to be sent with an explicit, silent, "yes" (which might be NO data); the data that will result in an explicit, silent "no"; the data that will be silently supplied on request only if I'm manually submitting a form via a secure server, etc. A broswer that implements my choices, so I can establish my personal trade-off between security and convenience rather than having it decided for me by either the data collectors or the self-described "privacy advocates."
P3P is a mechanism designed to get you to enter all your personal data into your web browser and have your browser give it out, behind the scenes, to any website that asks for it.
That doesn't appear to be the case at all from a closer look at the documentation. It is described as being intended to allow the user to be selectively notified (at the user's option) when information the user considers critical is being requested and to allow the user to make an informed decision whether to allow that information to be sent. You are claiming that the intent is precisely the opposite. I've seen nothing to back that up other than your rather strident assertions of ill intent.
Website X is requesting full access to your personal information. Yes/No?" If you say no, website X won't let you enter.
Their loss, then. In the competitive world of the Web, sites that turn away business by implementing such policies won't be around long. You're positing a worst-case scenario and calling it the norm. That's either paranoid or deliberately misleading. And it displays little understanding of how Web commerce actually works.
Eventually, of course, you'll get tired of seeing those pop-up boxes and will turn them off and forget about it.
God protect me from those who would save me from myself. Thank you, but I don't turn off features that apply security/privacy policies with which I agree.
The protocol is designed to move information from the user to the remote site behind the scenes, in such a way that the user doesn't see it go.
That's not the way it appears to me. It looks to me like it is intended to allow the user to know what information is being requested and to control whether it is sent. If you can provide some explicit evidence that the intent is as you claim, I'd be very interested in seeing it. So far, you've not done so. Your argument seems to rest on the proposition that users will configure their browsers to send their personal information without restriction. I don't think that will be the norm. Now, if browser implementations show up that default to that configuration, I think we should collectively scream loud and long. But if the browsers do their part in keeping the user in the loop when information is requested, the concepts behind P3P seem like a net win to me.
...P3P, a protocol designed to automatically give out your name, address, phone number, credit card information, social security number, and other personal data to websites as you browse...
I'm not intimately familiar with the P3P spec. But according to the P3P guiding principles user agents are supposed to:
Provide mechanisms for displaying a service's information practices to users.
Provide users an option that allows them to easily preview and agree to or reject each transfer of personal information that the user agent facilitates.
Not be configured by default to transfer personal information to a service provider without the user's consent.
Inform users about the privacy-related options offered by the user agent.
On the surface, at least, that looks pretty reasonable. It certainly doesn't sound like the description given above. What am I missing?
Why shouldn't Real know the names of the people using their service? After all they are the ones allowing you to use their software for free... if you don't read the small print then it's your own fault if you get upset about this.
My feeling is that if your product is going to act in ways that you know are distasteful to many potential users you are ethically obligated to point that out in a clear and obvious manner. Saying it in the small-print legalese may satisfy legal requirements but doesn't satisfy ethical ones, IMHO.
And as I understand it, the product in question is installed in the process of installing other products, so the user may not even know that there is a potential issue to consider. That puts using a nonobvious warning even further outside the pale, ethically speaking.
The interviewee is obviously stuck on some lesser platform that isn't able to render points at the proper physical size.
His complaint is based not on platform deficiencies but on browser deficiencies. The two dominant browsers produce different font sizes for the same CSS point size on the same platform. And if you were running a broken browser under XFree86, it might well do the same.
But the more fundamental problem is that few people bother to adjust their systems -- includng X -- to produce the "correct" physical size fonts on the monitor. Most people who bother to adjust physical font size for their display are adjusting to get fonts that are specified as 10 or 12 points or so to look "normal" to them. That's why specifying size in points does make sense; for most displays you're really specifying "size relative to 'normal' size." And that's probably true on your display as well.
Of course, any hard-coded physical font size is going to be broken for some displays no matter what. CSS has it conceptually right in allowing relative font size control by percentage or small/medium/large etc. But of course, those also aren't implemented correctly in some extant versions of the "big 2" browsers.
I must be missing something here... but every time he mentions CSS support, Opera is completely ignored.
I can't speak for Zeldman, of course, but I ignore Opera because practically nobody's using it. (We see Opera showing up about 0.1% of the time in the logs on our site. And yes, the site works fine with Opera so it's not like we're driving Opera users away.) Of course, that's also true of IE5/Mac.
As a practical matter, Web sites that are intended to serve a function other than being a "cool site" must be designed to work with the dominant browsers. They should also also be designed to work with any compliant browser, of course.
A central configuration system would be neat, but on the other hand you would break compatibility with a lot of existing Unix applications which expect/etc,/proc, and so forth.
I was wondering... suppose you had a filesystem front end available for the configuration database (I refuse to call it a registry). You mount the filesystem on/etc and when you read, say,/etc/hosts it appears as a text file but is actually read from the database. (Sort of what/proc does for some kernel data.) Application configuration data would be manipulated via the database front end (whatever that might be -- SQL perhaps) and would be readable that way, but it would also be readable as a text file in the format desired by the application.
This seems to me like an approach that would allow migration of configuration data to a managed system without modifying the applications at all! The only kicker would come from applications that not only read system configuration files but modify them as well. That, I think, is a relatively small number of applications. Most that manage configuration files do so on a per-user basis in files under the user's home directory. There's no particular reason to try to bring those files under central management, so leave well enough alone.
You would also want the filesystem to allow "normal" files for those applications whose configuration wasn't yet merged into the database or that themselves update their configuration file.
I had been thinking about looking into signing up our Company with TRUSTe, but this puts me off the idea altogether.
TRUSTe appears to be a paper tiger whose certification is essentially meaningless. But worse, I suspect that clueful users will now begin to suspect any TRUSTe client as possibly using TRUSTe as a shield for nefarious activities. Why would a site boast about a certification from a powerless certifying group? It's sort of like having a diploma on the wall from a mail-order diploma mill. That doesn't by itself prove sleazy practices, but it's sure a strong indicator.
In short, the TRUSTe symbol may now have more negative connotations for a Web site than positive ones.
My use of Linux distros has gone something like: SLS->Slackware->CND->RH4.2/5.0/5.2/6.0. Along about RH5.0 I decided I was being a freeloader, that RH was putting something valuable back into Linux, and they should be rewarded. So I bought the "official" RH5.0. I never expected to call the RH support line and never have. (I didn't even register the product.)
So, was old PT right? Is there a sucker born every minute, and am I one of them?
I've read plenty of negative Win9x/NT stuff. If you go check the material published in late '95 (when Win95 first came out) and early '96, you'll see the progression from flackery to punditry. I don't have specific references handy, but one writer whose negative comments I recall reading was Walter Mossberg of the NY Times. He's hardly the only one.
I'm not sure I get your point about Slashdot. If there is a link here to an article in a mainstream publication that slaps at M$, does the article not count as negative coverage of M$? And you'll find that many of the recent spate of pro-Linux articles linked to from/. mention Windows disparagingly. When the "next great thing" comes along, the writers will no doubt be mentioning Linux disparagingly, too.
There's nothing surprising about seeing an increase in negative coverage of Linux in the media. This is a standard sequence of events that seems to take place repeatedly: 1) press discovers brand new "next great thing"--years after the clueful first learned of it; 2) press waxes enthusiastic and explains the "new thing" (incorrectly) to the hoi polloi; 3) writers realize they're practicing pack journalism and start to print negative articles about the no-longer-new thing.
This is all aided by the staff curmudgeon. Most every sizeable publication has one, a columnist whose job it is to stir up controversy. (Not that the editors would put it that way. He's just "opinionated.") The first one of these I recall seeing in the computer press was Dvorak, back in the early 80s. Metcalfe seems cut from similar cloth.
So you don't need to assume a vast right wing, er, M$ conspiracy to explain what we're seeing in the press. It's the norm. Expect to see more negative coverage of Linux from the muckraking side of the media in the next few months. Them it'll die down as they move on to goring someone else's ox.
Hot swap per se isn't really an OS issue, or even a software issue. It's a matter of being able to remove and insert the hardware without damaging the drive or the machine.
Of course, for hot swap to be useful the system needs to be able to deal intelligently with failed drives, generally via RAID. I'm running Linux on a hot-swappable Compaq Proliant 1600 using software RAID-1, which works just fine. I've done the pull-a-running-drive test and watched the RAID driver rebuild the RAID system after adding the drive back in. It's pretty cool.
They could move it to the "Other Applications and Demos" disk
That or somthing like it strikes me as a good approach. Placing non-free (speech) software that can be legally distributed into its own "ghetto" serves to deprecate its use while still making it readily available for those who truly need it and lack a free alternative.
Slashdot Mirror
The thing is, there is a Yahoo presence in France (see the links at the bottom of www.yahoo.com). Since Yahoo is operating servers in France, they are within the reach of the French authorities.
Condemned, but still used. And if the technique were more widely used it would be more trouble to duck. So a mechanism that gives the user more control of such activity is desirable. Whether P3P is the epitome of such mechanisms is debatable, but conceptually such a mechanism has its place.
So at best, the situation is the same as before - the user provides information only when they decide to, and they are always notified.
No, because the P3P mechanism provides not only information about what information is requested, but why. In current practice, the why is generally not readily apparent -- sometimes not available at all. The part of P3P that I find most appealing is the standardization of delivery of policy information to the end user. Once that information can be presented in a consistent, readily available manner, the lack of it would become a highly visible red flag.
Further, once you say yes, the user-agent will store those preferences so that next time you come back to buystuff.com, your info will be sent silently. As a convenience to you, of course.
Silently if I tell it to, I would venture. And presumably, once I say NO, the UA will store that response and silently (if I want) send it, too.
I claim the intent is the opposite because it is. Sorry if that seems like proof by assertion, but I've been watching P3P for some years now. If a bunch of major corporations spend a bunch of time on a protocol designed to transmit your personal information to them - that's what it does, and that's all it does - the intent is not for them to get less information from you. Where's the fiscal motive in getting less information? Okay, now where's the fiscal motive in getting more information?
The amount of data collected is not the issue to me. Your original assertion was that the intent is to collect data secretly. It seems to me that P3P is intended to aid data collection by giving the user more information about and control over the transfer of information. If that aids the collector of data by making it easier for me to decide what data to send, it also aids me by, er, making it easier to decide what data to send.
My impression is that you view any collection of information as being inherently bad. I don't. As long as the organization I'm giving the information to is explicit about the purpose of collecting the information and the manner in which it will be used, I'm satisfied. Mechanisms (P3P or otherwise) that streamline this process while still giving me control of it are welcome.
Think of how many sites you've been required to "register" with to use. Are they all out of business? Why not?
Hard to say. The ones that ask for what I consider to be excessive information don't get a repeat visit from me so I don't know their status. The ones that ask for a reasonable set of required information that they actually need (e.g., slashdot) seem to be doing nicely. The vast majority of Web sites don't ask for such information because they don't need it and they know that people are skittish about sending it. I see no reason to think that P3P changes any of that.
You would if it popped-up a box every time you went to a new website.
Why on earth would it do that? Again, you're arguing a worst-case scenario. And you're not giving much credit to the folks who write browsers. I envision a browser that lets me establish my personal policies: the data that I will allow to be sent with an explicit, silent, "yes" (which might be NO data); the data that will result in an explicit, silent "no"; the data that will be silently supplied on request only if I'm manually submitting a form via a secure server, etc. A broswer that implements my choices, so I can establish my personal trade-off between security and convenience rather than having it decided for me by either the data collectors or the self-described "privacy advocates."
That doesn't appear to be the case at all from a closer look at the documentation. It is described as being intended to allow the user to be selectively notified (at the user's option) when information the user considers critical is being requested and to allow the user to make an informed decision whether to allow that information to be sent. You are claiming that the intent is precisely the opposite. I've seen nothing to back that up other than your rather strident assertions of ill intent.
Website X is requesting full access to your personal information. Yes/No?" If you say no, website X won't let you enter.
Their loss, then. In the competitive world of the Web, sites that turn away business by implementing such policies won't be around long. You're positing a worst-case scenario and calling it the norm. That's either paranoid or deliberately misleading. And it displays little understanding of how Web commerce actually works.
Eventually, of course, you'll get tired of seeing those pop-up boxes and will turn them off and forget about it.
God protect me from those who would save me from myself. Thank you, but I don't turn off features that apply security/privacy policies with which I agree.
The protocol is designed to move information from the user to the remote site behind the scenes, in such a way that the user doesn't see it go.
That's not the way it appears to me. It looks to me like it is intended to allow the user to know what information is being requested and to control whether it is sent. If you can provide some explicit evidence that the intent is as you claim, I'd be very interested in seeing it. So far, you've not done so. Your argument seems to rest on the proposition that users will configure their browsers to send their personal information without restriction. I don't think that will be the norm. Now, if browser implementations show up that default to that configuration, I think we should collectively scream loud and long. But if the browsers do their part in keeping the user in the loop when information is requested, the concepts behind P3P seem like a net win to me.
I'm not intimately familiar with the P3P spec. But according to the P3P guiding principles user agents are supposed to:
On the surface, at least, that looks pretty reasonable. It certainly doesn't sound like the description given above. What am I missing?
My feeling is that if your product is going to act in ways that you know are distasteful to many potential users you are ethically obligated to point that out in a clear and obvious manner. Saying it in the small-print legalese may satisfy legal requirements but doesn't satisfy ethical ones, IMHO.
And as I understand it, the product in question is installed in the process of installing other products, so the user may not even know that there is a potential issue to consider. That puts using a nonobvious warning even further outside the pale, ethically speaking.
His complaint is based not on platform deficiencies but on browser deficiencies. The two dominant browsers produce different font sizes for the same CSS point size on the same platform. And if you were running a broken browser under XFree86, it might well do the same.
But the more fundamental problem is that few people bother to adjust their systems -- includng X -- to produce the "correct" physical size fonts on the monitor. Most people who bother to adjust physical font size for their display are adjusting to get fonts that are specified as 10 or 12 points or so to look "normal" to them. That's why specifying size in points does make sense; for most displays you're really specifying "size relative to 'normal' size." And that's probably true on your display as well.
Of course, any hard-coded physical font size is going to be broken for some displays no matter what. CSS has it conceptually right in allowing relative font size control by percentage or small/medium/large etc. But of course, those also aren't implemented correctly in some extant versions of the "big 2" browsers.
I can't speak for Zeldman, of course, but I ignore Opera because practically nobody's using it. (We see Opera showing up about 0.1% of the time in the logs on our site. And yes, the site works fine with Opera so it's not like we're driving Opera users away.) Of course, that's also true of IE5/Mac.
As a practical matter, Web sites that are intended to serve a function other than being a "cool site" must be designed to work with the dominant browsers. They should also also be designed to work with any compliant browser, of course.
I was wondering... suppose you had a filesystem front end available for the configuration database (I refuse to call it a registry). You mount the filesystem on /etc and when you read, say, /etc/hosts it appears as a text file but is actually read from the database. (Sort of what /proc does for some kernel data.) Application configuration data would be manipulated via the database front end (whatever that might be -- SQL perhaps) and would be readable that way, but it would also be readable as a text file in the format desired by the application.
This seems to me like an approach that would allow migration of configuration data to a managed system without modifying the applications at all! The only kicker would come from applications that not only read system configuration files but modify them as well. That, I think, is a relatively small number of applications. Most that manage configuration files do so on a per-user basis in files under the user's home directory. There's no particular reason to try to bring those files under central management, so leave well enough alone.
You would also want the filesystem to allow "normal" files for those applications whose configuration wasn't yet merged into the database or that themselves update their configuration file.
Wierd. What kind of corporation devolves the choice of server software to "the highest level"?
They are the same company. The radio stuff is at www.kenwood.net
TRUSTe appears to be a paper tiger whose certification is essentially meaningless. But worse, I suspect that clueful users will now begin to suspect any TRUSTe client as possibly using TRUSTe as a shield for nefarious activities. Why would a site boast about a certification from a powerless certifying group? It's sort of like having a diploma on the wall from a mail-order diploma mill. That doesn't by itself prove sleazy practices, but it's sure a strong indicator.
In short, the TRUSTe symbol may now have more negative connotations for a Web site than positive ones.
Actually, it was 20/20.
Depending on HOW you hold the phone, many phones far exceeded the safety limits.
Their report was based on science that is, at best, dubious. Here are a few URLs you may want to review if you are interested in the topic:
http://www.wow-com.com/respons e/sar/german_intro.cfm .edu/gcrc/cop/cell-phone-health-FAQ/toc.html
http://iago.lib.mcw
http://www.pathfinder. com/time/personal/19991101/health.html
So, was old PT right? Is there a sucker born every minute, and am I one of them?
I'm not sure I get your point about Slashdot. If there is a link here to an article in a mainstream publication that slaps at M$, does the article not count as negative coverage of M$? And you'll find that many of the recent spate of pro-Linux articles linked to from /. mention Windows disparagingly. When the "next great thing" comes along, the writers will no doubt be mentioning Linux disparagingly, too.
This is all aided by the staff curmudgeon. Most every sizeable publication has one, a columnist whose job it is to stir up controversy. (Not that the editors would put it that way. He's just "opinionated.") The first one of these I recall seeing in the computer press was Dvorak, back in the early 80s. Metcalfe seems cut from similar cloth.
So you don't need to assume a vast right wing, er, M$ conspiracy to explain what we're seeing in the press. It's the norm. Expect to see more negative coverage of Linux from the muckraking side of the media in the next few months. Them it'll die down as they move on to goring someone else's ox.
Of course, for hot swap to be useful the system needs to be able to deal intelligently with failed drives, generally via RAID. I'm running Linux on a hot-swappable Compaq Proliant 1600 using software RAID-1, which works just fine. I've done the pull-a-running-drive test and watched the RAID driver rebuild the RAID system after adding the drive back in. It's pretty cool.
That or somthing like it strikes me as a good approach. Placing non-free (speech) software that can be legally distributed into its own "ghetto" serves to deprecate its use while still making it readily available for those who truly need it and lack a free alternative.