Facebook and many other sites also bypass Internet Explorer privacy controls(nikcub.appspot.com)
nikcub.appspot.com
Facebook and many other sites also bypass Internet Explorer privacy controls
http://nikcub.appspot.com/posts/facebook-also-doesnt-honor-p3p
62 comments
I doubt Facebook shares have anything to do with it. Microsoft wanted to embarrass Google, but the alleged crime is very common because IE's implementation of privacy controls is flawed.
IE's implementation of privacy controls is flawed.
It really doesn't matter what MS does; they get bashed either way.
In this case, their implementation is perfect: afaik, they're the only browser that actually follows the spec. FF, Chrome, etc., are just ignoring the standard. The problem here is that it's a really stupid standard, so that implementing it correctly results in brain-dead "protection". But Microsoft played by the rules, and now gets grief for it.
It really doesn't matter what MS does; they get bashed either way.
In this case, their implementation is perfect: afaik, they're the only browser that actually follows the spec. FF, Chrome, etc., are just ignoring the standard. The problem here is that it's a really stupid standard, so that implementing it correctly results in brain-dead "protection". But Microsoft played by the rules, and now gets grief for it.
They played by nonsensical rules and got grief for it. It's kind of fair, actually.
Yet, I refrain from criticizing them - P3P is a broken standard, but Microsoft followed it. I'm criticizing them for singling out Google when, in fact, ignoring P3P or actively disabling it is widespread practice.
I'm surprised live.com doesn't do it.
Yet, I refrain from criticizing them - P3P is a broken standard, but Microsoft followed it. I'm criticizing them for singling out Google when, in fact, ignoring P3P or actively disabling it is widespread practice.
I'm surprised live.com doesn't do it.
I think live.com does (or did) do it. See page 8, second column of the CMU paper in this reddit comment: http://www.reddit.com/r/technology/comments/py9h5/now_google...
It's really unbelievable how this paper keeps getting cited as proof Microsoft is doing this too. Page 7 was cited on the other thread; you can read my response here: http://news.ycombinator.com/item?id=3615267
Re: Live doing it too. No, that is not what the paper says. From page 8:
"Only one of these websites, microsoft.com, displayed a full P3P policy."
"Websites under the msn:com domain exhibited a CP that includes the invalid CUSo token. Two other Microsoft owned sites, microsoft:com and windows:com use the same CP. These websites display the TRUSTe EU Safe Harbor Privacy seal. We believe that these websites are likely attempting to comply with P3P; however, they are not using P3P properly."
"The live.com CP does not include any ACCESS tokens. This CP suggests collection of PII, but does not provide any information about whether users can access their personal information."
Microsoft does not always fully comply with the letter of the law, but based on everything that I have read in that paper, they sure seem to be trying to comply with the spirit. It's ridiculous to claim that sending a deliberately misleading P3P header is the same as sending a P3P header that suggests PII is used but does not provide the access policy. One is designed to exploit a weakness in P3P and avoid blatantly lying to browsers in order to track users. The other indicates that PII is used, but does not fully specify how this is used. It seems fairly clear that one company is at least trying to support P3P, even if they are unable to completely reflect their privacy policy with these tokens. To claim these situations is analogous is fairly dishonest IMO.
(NOTE: Page numbers are based on the PDF document for quick access. Subtract 1 for the number printed on the bottom of the page.)
Re: Live doing it too. No, that is not what the paper says. From page 8:
"Only one of these websites, microsoft.com, displayed a full P3P policy."
"Websites under the msn:com domain exhibited a CP that includes the invalid CUSo token. Two other Microsoft owned sites, microsoft:com and windows:com use the same CP. These websites display the TRUSTe EU Safe Harbor Privacy seal. We believe that these websites are likely attempting to comply with P3P; however, they are not using P3P properly."
"The live.com CP does not include any ACCESS tokens. This CP suggests collection of PII, but does not provide any information about whether users can access their personal information."
Microsoft does not always fully comply with the letter of the law, but based on everything that I have read in that paper, they sure seem to be trying to comply with the spirit. It's ridiculous to claim that sending a deliberately misleading P3P header is the same as sending a P3P header that suggests PII is used but does not provide the access policy. One is designed to exploit a weakness in P3P and avoid blatantly lying to browsers in order to track users. The other indicates that PII is used, but does not fully specify how this is used. It seems fairly clear that one company is at least trying to support P3P, even if they are unable to completely reflect their privacy policy with these tokens. To claim these situations is analogous is fairly dishonest IMO.
(NOTE: Page numbers are based on the PDF document for quick access. Subtract 1 for the number printed on the bottom of the page.)
It's really unbelievable...
It's not really that unbelievable: Microsoft is berating Google for sending invalid P3P headers and this paper describes that Microsoft is sending invalid P3P headers.
Microsoft does not always fully comply with the letter of the law...
In this case what constitutes the letter of the law isn't really clear. As far as I can tell this is the latest specification for the P3P header:
http://tools.ietf.org/html/draft-marchiori-w3c-p3p-header-01
I'm going to quote a small portion:
This Internet-Draft will expire on August 6, 2002.
So it's at least arguable that there isn't a standard for the P3P header, and whatever anyone wants to put in it is just whatever they put in it, nothing is invalid and everyone is fine.
Only IE supports it anyway, and it's not like it prevents websites from doing things they've said in their P3P headers that they're not going to do. And the header is required to make IE accept 3rd party cookies (which are needed for lots of quite normal stuff on the web) you need to send it one of these headers.
RFC 6462 also has some interesting comments:
http://tools.ietf.org/html/rfc6462#section-4.3.2
It's not really that unbelievable: Microsoft is berating Google for sending invalid P3P headers and this paper describes that Microsoft is sending invalid P3P headers.
Microsoft does not always fully comply with the letter of the law...
In this case what constitutes the letter of the law isn't really clear. As far as I can tell this is the latest specification for the P3P header:
http://tools.ietf.org/html/draft-marchiori-w3c-p3p-header-01
I'm going to quote a small portion:
This Internet-Draft will expire on August 6, 2002.
So it's at least arguable that there isn't a standard for the P3P header, and whatever anyone wants to put in it is just whatever they put in it, nothing is invalid and everyone is fine.
Only IE supports it anyway, and it's not like it prevents websites from doing things they've said in their P3P headers that they're not going to do. And the header is required to make IE accept 3rd party cookies (which are needed for lots of quite normal stuff on the web) you need to send it one of these headers.
RFC 6462 also has some interesting comments:
http://tools.ietf.org/html/rfc6462#section-4.3.2
It really doesn't matter what MS does; they get bashed either way.
Then probably best not to draw attention to yourself by, for example, having a VP make a blog post about it.
Then probably best not to draw attention to yourself by, for example, having a VP make a blog post about it.
The stupid thing about IE's implementation is that, while it is supposed to restrict third-party cookies unless sites have an acceptable privacy policy, it treats an invalid P3P header as if it were an acceptable privacy policy, rather than treating it as if there were no privacy policy. I don't see anything in the spec which mandates that.
How is it flawed? According to the original report IE's handling is correct, it's the spec that's flawed.
OK, the spec is flawed. Other browser makers have solved that problem quite neatly by not implementing it.
It's also my opinion that while the implementation is strictly speaking correct, IE's default settings are too conservative and it is not at all an easy option for the user to change.
It's also my opinion that while the implementation is strictly speaking correct, IE's default settings are too conservative and it is not at all an easy option for the user to change.
Firefox dropped support for P3P in Firefox 3 because "p3p isn't an effective way to establish trust with a site. it's a one-way system; anyone can say they're the good guy." See item b: https://bugzilla.mozilla.org/show_bug.cgi?id=417800#c11
> but the alleged crime is very common because IE's implementation of privacy controls is flawed
By my understanding (caveat: I've not read through the standards in any detail) IE's implementation is fine by the standard and the standard itself has problems which other browsers get around by breaking the standard.
I'm not usually one to give MS the benefit of the doubt but in this case Google does look to be the one at fault so while calling them out specifically and not mentioning Facebook and others my be disingenuous, it would appear that Google (and others) are using the loophole to perform tracking against the spirit of the standard.
By my understanding (caveat: I've not read through the standards in any detail) IE's implementation is fine by the standard and the standard itself has problems which other browsers get around by breaking the standard.
I'm not usually one to give MS the benefit of the doubt but in this case Google does look to be the one at fault so while calling them out specifically and not mentioning Facebook and others my be disingenuous, it would appear that Google (and others) are using the loophole to perform tracking against the spirit of the standard.
On the other hand, given that for a large set of content publishers Adwords provides a substantial revenue stream that will suddenly deplete. And given that this would probably be a larger hit to their pockets, the number of people who are actually in trouble would be larger in case Google cookies are blocked. I think # of support tickets, if that is a parameter we are judging the effect with, would be larger for this case.
ah, I was thinking more about pitchfork wielding users deciding whether or not to switch browsers (depending on how hard Microsoft pushed the blacklist additions, that could lose a few market share percentage points in a day or two), but based on the support ticket metric, that's a really good point.
[deleted]
The article makes it sound a bit like the big companies are doing something very evil to the users data just because they are evil and greedy. I encountered this problem in my development work, and in reality it's much more complicated, while some companies might well be evil and greedy, the real problem is that the means available in the browser for doing cross-domain integration of web services while controlling privacy are really poor.
The P3P header is just a formal way of describing the companies privacy policy. Now, the problems is that when targeting MSIE, there is no way for a company to make their P3P header honestly reflect their existing privacy policy and still do integration with a third-party vendor on their page, because if the privacy policy described in the P3P is not restrictive enough IE blocks the cookies and there is nothing you can do about it, there will not even be a popup window for the user to decide what he wants do about it, it simply won't work.
Example: let's say you want to embed a facebook widget or whatever in your page and you have to do it via an iframe because that's the way facebook supplies it (and it might well be that for technical reasons no other way would work OK for both facebook and you). Then, after the user does something with the widget, you want your page to be called again, while maintaining the users identity (with the user still being logged-in in your page). This works well by default in all browsers, except for IE, which without the privacy policy being restrictive enough (as described in the P3P header sent by your page), will simply ignore the session-id cookie and log the user out in the iframe.
I don't think with a well thought out security model companies should have to make such a choice between functionality vs. having a specific privacy policy, those things should be completely independent. If the user actually wants to use third-party integration on a page supplied by a company with a not very restrictive privacy policy, why should the browser prohibit it? This is commonly needed, and currently the only way in MSIE to fix it other then sending an adequate P3P is AFAIR to lower the security settings, which most common users don't know how to do, and of course as a company you wouldn't like to recommend your users to lower their security level anyway. The browser should make sure the user knows what is going to happen, but then give him a choice and stay out of the way if that's the user wish.
The P3P header is just a formal way of describing the companies privacy policy. Now, the problems is that when targeting MSIE, there is no way for a company to make their P3P header honestly reflect their existing privacy policy and still do integration with a third-party vendor on their page, because if the privacy policy described in the P3P is not restrictive enough IE blocks the cookies and there is nothing you can do about it, there will not even be a popup window for the user to decide what he wants do about it, it simply won't work.
Example: let's say you want to embed a facebook widget or whatever in your page and you have to do it via an iframe because that's the way facebook supplies it (and it might well be that for technical reasons no other way would work OK for both facebook and you). Then, after the user does something with the widget, you want your page to be called again, while maintaining the users identity (with the user still being logged-in in your page). This works well by default in all browsers, except for IE, which without the privacy policy being restrictive enough (as described in the P3P header sent by your page), will simply ignore the session-id cookie and log the user out in the iframe.
I don't think with a well thought out security model companies should have to make such a choice between functionality vs. having a specific privacy policy, those things should be completely independent. If the user actually wants to use third-party integration on a page supplied by a company with a not very restrictive privacy policy, why should the browser prohibit it? This is commonly needed, and currently the only way in MSIE to fix it other then sending an adequate P3P is AFAIR to lower the security settings, which most common users don't know how to do, and of course as a company you wouldn't like to recommend your users to lower their security level anyway. The browser should make sure the user knows what is going to happen, but then give him a choice and stay out of the way if that's the user wish.
Google could display a message in page, like they do when first party cookies are disabled or when firebug is running. Instead, they chose to "jailbreak" themselves and not even tell the user what they are doing. Google makes a tickertape parade of yellow see sticky notes every time they change the shade of grey in a form button, it is quite telling that they are ashamed of admitting "
They in fact cannot even display a message, there is no way AFAIK to distinguish between this situation and someone simply not being logged-in. Even if they could, they would still leave IE users without some functionality. Again, I do not want to be Google's advocate and I do not know their specific use cases, I am just saying they are legitimate use cases for both not having the privacy policy that restrictive (eg. when processing and passing over the users data is actually part of the buisness model) and for doing third party integration, which the security model as implemented by MSIE makes impossible to handle.
This makes no sense. The breaking behavior that Google is trying to avoid does not occur on Google properties. First-party cookies are not the problem. The breaking behavior occurs on third-party sites trying to include +1 buttons and the like. Your solution is to display a wall of text or a dialog on someone else's site when visitors have the default security settings in IE? Somehow I don't think anybody would be happy with that.
Microsoft is in a bind, now. If they fix their security hole, the Like and +1 buttons will stop working on IE9, and only IE9. The solution to fixing them will be 'use another browser'. The only solution.
So faced with losing market share, they instead chose to turn it around and say that other companies are doing unethical things. When those companies stop doing them, IE9 will stop working, but now it looks like those websites are at fault, and not IE9.
The obvious solution is simply to explain why (and G and FB have already done so) and let MS hang themselves with their own rope. MS's gambit won't pay off, and they'll lose worse for having tried it.
So faced with losing market share, they instead chose to turn it around and say that other companies are doing unethical things. When those companies stop doing them, IE9 will stop working, but now it looks like those websites are at fault, and not IE9.
The obvious solution is simply to explain why (and G and FB have already done so) and let MS hang themselves with their own rope. MS's gambit won't pay off, and they'll lose worse for having tried it.
Let's hope the true villains get rightfully punished.
So Facebook uses the exact same trick. They could have just omitted the P3P header completely, but no they must and shall have 3rd party cookies so they respond with an invalid P3P header, just like Google.
The fact that the invalid P3P header contains the string "We don't support P3P and here's why" is a red herring:
The only reason why they would place a statement regarding their non-support in the very header that they claim not to support, is to circumvent IE-users' privacy policy. It's very disingenuous.
If you don't support it, leave out the header, if you want to make a statement that says "We don't support the P3P header", don't put it in a place that really says
It's a bit like placing a sticker "WE DONT SUPPORT READING THE LEFT HALF OF A SIGNPOST" over the left half of a "NO ENTRY" sign. Childish.
It would be interesting if we could see that list of other 500 companies. Because "there's 498 others that do it too" has a very different implication depending on what sort of company Google and Facebook find themselves in by acting in such a childish manner.
The fact that the invalid P3P header contains the string "We don't support P3P and here's why" is a red herring:
The only reason why they would place a statement regarding their non-support in the very header that they claim not to support, is to circumvent IE-users' privacy policy. It's very disingenuous.
If you don't support it, leave out the header, if you want to make a statement that says "We don't support the P3P header", don't put it in a place that really says
"We disagree with the P3P header and believe in circumventing it.
Read why here: http://xyz"
It's a bit like placing a sticker "WE DONT SUPPORT READING THE LEFT HALF OF A SIGNPOST" over the left half of a "NO ENTRY" sign. Childish.
It would be interesting if we could see that list of other 500 companies. Because "there's 498 others that do it too" has a very different implication depending on what sort of company Google and Facebook find themselves in by acting in such a childish manner.
If it's broken to begin with, it's not really "breaking the users security settings". Specifically if it can be broken just by saying "break it", then it's broken from the start.
In that sense NO ENTRY signs are also broken. And so is the robots.txt protocol.
But "No Entry" signs and robots.txt are broken for the same reason. We all know that, so how is it a counterargument?
No one trusts their security to a sign or a robots.txt. Get a security guard and an encrypted directory, and get a better way to manage your cookies.
Even from your description, P3P does not work; IE is equally dishonest imho for claiming that P3P provides any kind of privacy.
It's a crappy protocol, I agree. I don't see how that's relevant though.
So it appears the problem has more to do P3P rather than anyone else. I wonder how many other websites out there just send out the "required for cookies to work" P3P headers regardless of what they do with the data they collect (i 've blindly copy-pasted such headers in the past, but then again i don't abuse or pass along any private information to third parties). Of course, relying on websites' good faith to report what they plan to do with your data was a false assumption to begin with.
So you feel that it's kind of like asking a used-car salesman if it's a good car?
Most people trust Google and Facebook. They don't really care about cookies so long as it works. The trust has already been established by the brand.
Most people trust Google and Facebook. They don't really care about cookies so long as it works. The trust has already been established by the brand.
Follow the link that facebook provides in its header:
http://www.facebook.com/help/?page=219494461411349
It's very interesting. They straight out say P3P is a dead protocol. And from the explanation of how it works, it does seem to be a joke - trusting third party websites to honor user privacy ? seriously ? I think Microsoft is simply trying to raise a shit storm over nothing... at least Safari one is a real screw-up on Google's part...
It's very interesting. They straight out say P3P is a dead protocol. And from the explanation of how it works, it does seem to be a joke - trusting third party websites to honor user privacy ? seriously ? I think Microsoft is simply trying to raise a shit storm over nothing... at least Safari one is a real screw-up on Google's part...
Is it a joke to expect Google to honor user privacy?
It's a joke for people to expect that P3P is a good privacy model.
From the parent: "trusting third party websites to honor user privacy ? seriously"
That's what I was responding to. They seem to be suggesting that the idea of trusting Google is absurd on the face of it.
That's what I was responding to. They seem to be suggesting that the idea of trusting Google is absurd on the face of it.
It is. FB too. They've done it to themselves (in more important cases than this P3P stuff btw). And that doesn't make it right, at all.
[deleted]
[deleted]
I do not see anything wrong with Facebook or Google for setting false P3P policies. As a developer of Facebook applications, and user of Google Analytics the reality is that without this P3P headers hack in place, you will A.) eliminate a gigantic portion of your IE users from using your site, and B.) eliminate a gigantic portion of metrics data for those users.
In the case of A, I utilize the Facebook SDK which relies on the Third-Party Facebook cookie passed into my application when it is loaded in a Facebook.com iframe. Could I build my application a little different to not need this? Yes, but this way is a little more reliable and secure. B.) Google Analytics breaks for IE users when your application lives within any iframe. It relies on Third-Party cookies to correctly track the users actions, and browser information.
I am a big user advocate when it comes to protection of personal information, but I really believe that unless users stop using IE (which is not going to happen any time soon), or P3P is depreciated by Microsoft then for now it is a useful hack to get around yet another IE pitfall.
In the case of A, I utilize the Facebook SDK which relies on the Third-Party Facebook cookie passed into my application when it is loaded in a Facebook.com iframe. Could I build my application a little different to not need this? Yes, but this way is a little more reliable and secure. B.) Google Analytics breaks for IE users when your application lives within any iframe. It relies on Third-Party cookies to correctly track the users actions, and browser information.
I am a big user advocate when it comes to protection of personal information, but I really believe that unless users stop using IE (which is not going to happen any time soon), or P3P is depreciated by Microsoft then for now it is a useful hack to get around yet another IE pitfall.
[deleted]
Does anybody here know when Firefox (and other major browsers besides IE) dropped the P3P standard? I certainly recall having to deal with this on most (all?) popular browsers ~6 years ago. I'm curious if they silently dropped it (because it does make the internet more useful, but more dangerous), or if they actually gave rationale for discontinuing its use.
...and by "more useful", I mean "more profitable"...
What is the preferred way to handle P3P for a young startup or a small (possibly academic) project?
As I see it, there are seven relevant facts:
1. The intent of P3P is to make it so that you are personally, legally bound to enforce particular privacy guarantees.
2. The attempt to make a P3P standard has been abandoned for half a decade, and only one browser maker supports it, largely for historical reasons. Documentation and tooling for P3P is by-and-large about a decade old, and advocacy seems to have dwindled down to a few people at CMU.
3. Unless you send a P3P header with the right string of (potentially legally binding) guarantees, it is not possible to use third party cookies with Internet Explorer.
4. P3P was intended for exactly the case of tracking cookies.
5. Using a third party tracking cookie is often the best design decision for a particular problem, even though other mechanisms could completely avoid the need to handle P3P.
6. Almost no one has actually changed their P3P settings from the default set by their browser vendor.
7. Users only care if functionality they want exists, whether or not there is some esoteric "standards" reason why it does not exist.
So let's say you've got a new compelling piece of functionality you want to offer. You're a startup or small project. You want to make it as easy as possible for people to include your functionality with a single javascript include. (Maybe you're Disqus? Maybe you're a new advertising platform? Maybe you're a +1 button?)
Do you ask all of your users to include a piece of PHP code on their site so that you can send data while having it appear to be first-party? Do you put up a P3P policy that matches your intentions for the data? What are your intentions for the data? If your intentions change, do you change your data model to include what P3P policy the data was captured under? What is personally identifiable information? Isn't pretty much everything personally identifiable once you have enough experience with the user? If you even have lawyers, do they have any experience with P3P, or do they just want you to point to their extremely precisely written English document instead?
So I guess the six options are:
A. Implement your functionality in a way that is inconvenient for your users, but completely avoids P3P. For example, ask them to install a PHP script where you set first-party cookies for them.
B. Use third-party cookies and set a bogus P3P policy in your headers. Maybe you copy it from the Internet.
C. Use third-party cookies and set an intentionally, obviously broken P3P policy (just a link, as Google and Facebook do) pretending that you don't understand P3P or linking to your real, English language policy.
D. Do the same as C, but actually include privacy controls on your site for users who are willing to state them and log in.
E. Have an engineer spend a day guessing what P3P policy is most similar to what you want to do at the moment and in the future, and then write the P3P policy header files and XML and forget about it.
F. Get a lawyer and engineer to team up to implement P3P throughout your site. Determine what each of the P3P options legally means in your context, figure out which ones apply, and then ensure that every part of your infrastructure handles the policy correctly.
As I see it, there are seven relevant facts:
1. The intent of P3P is to make it so that you are personally, legally bound to enforce particular privacy guarantees.
2. The attempt to make a P3P standard has been abandoned for half a decade, and only one browser maker supports it, largely for historical reasons. Documentation and tooling for P3P is by-and-large about a decade old, and advocacy seems to have dwindled down to a few people at CMU.
3. Unless you send a P3P header with the right string of (potentially legally binding) guarantees, it is not possible to use third party cookies with Internet Explorer.
4. P3P was intended for exactly the case of tracking cookies.
5. Using a third party tracking cookie is often the best design decision for a particular problem, even though other mechanisms could completely avoid the need to handle P3P.
6. Almost no one has actually changed their P3P settings from the default set by their browser vendor.
7. Users only care if functionality they want exists, whether or not there is some esoteric "standards" reason why it does not exist.
So let's say you've got a new compelling piece of functionality you want to offer. You're a startup or small project. You want to make it as easy as possible for people to include your functionality with a single javascript include. (Maybe you're Disqus? Maybe you're a new advertising platform? Maybe you're a +1 button?)
Do you ask all of your users to include a piece of PHP code on their site so that you can send data while having it appear to be first-party? Do you put up a P3P policy that matches your intentions for the data? What are your intentions for the data? If your intentions change, do you change your data model to include what P3P policy the data was captured under? What is personally identifiable information? Isn't pretty much everything personally identifiable once you have enough experience with the user? If you even have lawyers, do they have any experience with P3P, or do they just want you to point to their extremely precisely written English document instead?
So I guess the six options are:
A. Implement your functionality in a way that is inconvenient for your users, but completely avoids P3P. For example, ask them to install a PHP script where you set first-party cookies for them.
B. Use third-party cookies and set a bogus P3P policy in your headers. Maybe you copy it from the Internet.
C. Use third-party cookies and set an intentionally, obviously broken P3P policy (just a link, as Google and Facebook do) pretending that you don't understand P3P or linking to your real, English language policy.
D. Do the same as C, but actually include privacy controls on your site for users who are willing to state them and log in.
E. Have an engineer spend a day guessing what P3P policy is most similar to what you want to do at the moment and in the future, and then write the P3P policy header files and XML and forget about it.
F. Get a lawyer and engineer to team up to implement P3P throughout your site. Determine what each of the P3P options legally means in your context, figure out which ones apply, and then ensure that every part of your infrastructure handles the policy correctly.
You miss two things here I guess:
1. If your P3P policy is not restrictive enough IE will still refuse to accept cookies. Just having any P3P policy is not enough, so in E and F you have no way to implement the functionality.
2. If there would be a reasonable and easy to invent way to avoid the technical problems with the P3P policy, I'm pretty sure Google and Facebook would use it. The problem is that there are integration patterns where there is really hard to come up with a strategy that avoids the P3P problem completely. If you want some third-party page appear as part of your page, the natural way is to use an iframe, but then your session-id cookie will be ignored in the iframe in IE unless you have the appropriate P3P policy set, so the iframe will have no possiblity to redirect you back to a logged-in section of your page. I cannot think of a way of circumventing this without crippling functionality.
1. If your P3P policy is not restrictive enough IE will still refuse to accept cookies. Just having any P3P policy is not enough, so in E and F you have no way to implement the functionality.
2. If there would be a reasonable and easy to invent way to avoid the technical problems with the P3P policy, I'm pretty sure Google and Facebook would use it. The problem is that there are integration patterns where there is really hard to come up with a strategy that avoids the P3P problem completely. If you want some third-party page appear as part of your page, the natural way is to use an iframe, but then your session-id cookie will be ignored in the iframe in IE unless you have the appropriate P3P policy set, so the iframe will have no possiblity to redirect you back to a logged-in section of your page. I cannot think of a way of circumventing this without crippling functionality.
If you're operating in the EU, you should have all of F. apart from the P3P anyway, or else you're in breach of whatever the local version of the Data Protection Act is. As those acts require you to also have a "data controller" to ensure compliance, it's not a hell of a stretch to add this to their job description.
And both Google and Facebook fall under the Irish Data Protection Act. Hmm...
Good question. But purely from a practical perspective, the risk this presents to an average web startup is completely negligible compared to other risks... like not finding a solid product-market fit. Personally, I'd go with C and spend my time working on the product or landing customers.
If I read correctly, the article says that of the top 10000 sites 95% do have a valid P3P header. Does that make a decision any simpler for an aspiring startup?
This is actually a good answer, in that it suggests that norms might be important in answering the question. However, this [1] paper by some of the authorities on P3P suggests that the answer might be less clear than you are suggesting.
Specifically, these are the headline stats:
1. 34% of websites have errors in their P3P compact header in that they contain invalid, missing, or conflicting tokens.
2. 79% of websites with P3P compact headers are missing full policy files, which is required to be compliant.
3. Among the top 100 websites, only 48 have P3P compact policies, and of those, 41 have no full policy file, and 21 have errors making the header invalid.
4. 97% of invalid compact policies bypass Internet Explorer's default filters.
5. Vast numbers (thousands) of the valid compact policies are duplicates. In fact, a little under 5000 of the approximately 20,000 compact policies that are valid are the same policy (NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM) which coincidentally is listed all over the web as a bug fix for IE's cookie handling.
Reading between the lines, the norm here seems to be to either (a) not include P3P (52% of top websites) or (b) include it as a bug fix in an invalid, non-compliant way (21--41% of top websites). Is an invalid P3P header likely to be legally binding if the overwhelming majority of websites of all sizes implement it incorrectly, both intentionally and unintentionally? Is it worth the time, expense, and potential legal risk for a small startup to try to use it correctly?
[1] http://repository.cmu.edu/cylab/73/
Specifically, these are the headline stats:
1. 34% of websites have errors in their P3P compact header in that they contain invalid, missing, or conflicting tokens.
2. 79% of websites with P3P compact headers are missing full policy files, which is required to be compliant.
3. Among the top 100 websites, only 48 have P3P compact policies, and of those, 41 have no full policy file, and 21 have errors making the header invalid.
4. 97% of invalid compact policies bypass Internet Explorer's default filters.
5. Vast numbers (thousands) of the valid compact policies are duplicates. In fact, a little under 5000 of the approximately 20,000 compact policies that are valid are the same policy (NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM) which coincidentally is listed all over the web as a bug fix for IE's cookie handling.
Reading between the lines, the norm here seems to be to either (a) not include P3P (52% of top websites) or (b) include it as a bug fix in an invalid, non-compliant way (21--41% of top websites). Is an invalid P3P header likely to be legally binding if the overwhelming majority of websites of all sizes implement it incorrectly, both intentionally and unintentionally? Is it worth the time, expense, and potential legal risk for a small startup to try to use it correctly?
[1] http://repository.cmu.edu/cylab/73/
No, he just said 5% had an invalid header, no claims were made about how many had valid headers. And unless he's actually audited any of the websites to see if what they're claiming in their P3P policies corresponds with how they actually use their cookies then how many sites have well formed headers is beside the point.
He is saying 5% have invalid P3P headers. Most of the rest do not have P3P headers at all, see: http://en.wikipedia.org/wiki/P3P#Criticisms
Sorry but this is insane.
The real question is why is IE allowing Facebook, Google and others to bypass its privacy controls? Maybe beacause IE is not that secure. If your software have security problems, please fix those problems instead of complaining that others are exploiting them.
The real question is why is IE allowing Facebook, Google and others to bypass its privacy controls? Maybe beacause IE is not that secure. If your software have security problems, please fix those problems instead of complaining that others are exploiting them.
> The real question is why is IE allowing
Because the standard says that it should. In this circumstance they can legitimately claim "in all good faith". We can't lambaste MS for running roughshod over standards when ever it suits them (and believe me, I do) then turn around and moan because we don't a like the side-effect of them implementing a standard correctly (correctness here being defined by the standard, not any other measure of desirability) - that would be somewhat hypercritical.
MS are (by my interpretation at any rate) being catty about this and using it as an excuse to get a petty shot out against Google, but that doesn't alter the three facts:
1. The standard has flaws
2. MS has implemented the standard (flaws and all, but that isn't the point)
3. Google (and others, though Google is the one MS are calling out) appear to be using a loophole in the standard to go against the spirit of the standard. If they don't agree with using that header for its intended purpose then they should just not include it. Including a header that is intended to be machine readable but giving it human readable content is not something that can be easily defended: they could easily include it as "x-P3P" instead which is perfectly valid. Any human that does looking for the P3P header will find a message in a x-P3P header just as readily and it wouldn't confuse the client application into opening greater access because it doesn't understand the "for humans" message
Perhaps, considering the "assume human fallibility over malicious intent unless there is evidence otherwise" maxim, Google (and facebook, and everyone else that does this but isn't being fingered for it right now) did this in all good faith rather than to deliberately make use of a loophole, in which case the right course of action is to encourage them to correct this oversight instead of telling MS to ignore part of the standard.
Because the standard says that it should. In this circumstance they can legitimately claim "in all good faith". We can't lambaste MS for running roughshod over standards when ever it suits them (and believe me, I do) then turn around and moan because we don't a like the side-effect of them implementing a standard correctly (correctness here being defined by the standard, not any other measure of desirability) - that would be somewhat hypercritical.
MS are (by my interpretation at any rate) being catty about this and using it as an excuse to get a petty shot out against Google, but that doesn't alter the three facts:
1. The standard has flaws
2. MS has implemented the standard (flaws and all, but that isn't the point)
3. Google (and others, though Google is the one MS are calling out) appear to be using a loophole in the standard to go against the spirit of the standard. If they don't agree with using that header for its intended purpose then they should just not include it. Including a header that is intended to be machine readable but giving it human readable content is not something that can be easily defended: they could easily include it as "x-P3P" instead which is perfectly valid. Any human that does looking for the P3P header will find a message in a x-P3P header just as readily and it wouldn't confuse the client application into opening greater access because it doesn't understand the "for humans" message
Perhaps, considering the "assume human fallibility over malicious intent unless there is evidence otherwise" maxim, Google (and facebook, and everyone else that does this but isn't being fingered for it right now) did this in all good faith rather than to deliberately make use of a loophole, in which case the right course of action is to encourage them to correct this oversight instead of telling MS to ignore part of the standard.
I agree. It seems to me that it's a browser level problem if Google and Facebook could subvert so could the less "upstanding" websites.
P3P is based on trust. If Facebook and Google don't want to support it then they should ignore it rather than subvert it.
Because if you don't allow people to bypass the privacy controls a significant chunk of the web stops working. For instance there's at least one well known WiFi hotspot service in the UK for which the block 3rd party cookies option in Firefox breaks the logon process for.
[deleted]
I wonder why it is necessary for you riff of every high ranking HN article. Are we to be exposed to your "HN is just another Social Network" article? Or will it be "How my high HN karma bootstrapped my socio-locale-mobile start-up to 28k in the first weekend?"
As if ANYONE (over the age of 16) EVER was impressed by the ability to earn a few thousand dollars in a weekend.
As if ANYONE (over the age of 16) EVER was impressed by the ability to earn a few thousand dollars in a weekend.
Wow. I wish I could down vote this a thousand times. Here we have someone actually contributing useful information in an unbiased way and you create a throwaway account to complain? Shame on you.
I have trouble believing that they didn't check any other websites when they were preparing that blog post (and facebook would be the obvious next choice to test), but another reason not to mention facebook may be that not many people would notice the effect of the doubleclick cookie's absence in the ads that they see, but most people who use Like buttons (and facebook embeds, etc) would notice when they suddenly stopped working.
So if people did use that new IE9 blocking feature with the suggested addition of google, and then facebook and all the sites found here were added too...you'd get the theoretical hit to facebook revenue, yes, but you'd get the definite hit of users all thinking your browser is broken because it won't load Facebook anywhere but facebook.com. Imagine those support tickets.
(I believe this kind of interaction is almost the exact reason Mozilla decided not to block third party cookies by default and why Apple decided to add the exceptions in Safari...someone posted a bug earlier with an Apple engineer arguing for the exceptions specifically because of Facebok and Microsoft Live logins, among other things).
edit: the bug was in comments on the ars coverage: https://bugs.webkit.org/show_bug.cgi?id=35824