Facebook and many other sites also bypass Internet Explorer privacy controls
nikcub.appspot.com
nikcub.appspot.com
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
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 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.
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.
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 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:
Then probably best not to draw attention to yourself by, for example, having a VP make a blog post about it.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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?
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.
That is a bit strange behaviour on IE's side as well.
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.
As if ANYONE (over the age of 16) EVER was impressed by the ability to earn a few thousand dollars in a weekend.