Facebook and many other sites also bypass Internet Explorer privacy controls

http://nikcub.appspot.com/posts/facebook-also-doesnt-honor-p3p

by nikcub • 14 years ago

177 57 14 years ago

nikcub.appspot.com

zerostar072• 14 years ago

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.

antonyh• 14 years ago

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.

magicalist2• 14 years ago

> Microsoft explicitly called out Google for their behaviour but either neglected to mention or didn't investigate Facebook (skeptics may believe that this is because of Microsoft's shareholding in Facebook and their partnerships in search and advertising)

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

mayanksinghal• 14 years ago

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.

magicalist2• 14 years ago

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.

eli2• 14 years ago

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.

lstoll• 14 years ago

How is it flawed? According to the original report IE's handling is correct, it's the spec that's flawed.

CWuestefeld• 14 years ago

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.

dspillett2• 14 years ago

> 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.

meow• 14 years ago

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...

rbarooah2• 14 years ago

Is it a joke to expect Google to honor user privacy?

tripzilch6• 14 years ago

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.

freehunter3• 14 years ago

It's a joke for people to expect that P3P is a good privacy model.

markokocic• 14 years ago

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.

uid• 14 years ago

P3P is based on trust. If Facebook and Google don't want to support it then they should ignore it rather than subvert it.

tripzilch6• 14 years ago

True, but apparent "not including the header" gives you strict privacy controls, while "including an invalid header" will set them wide open.

That is a bit strange behaviour on IE's side as well.

robertc7• 14 years ago

Where does P3P allow me to manage this trust relationship you say it's based on?

socialized• 14 years ago

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.

robertc7• 14 years ago

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.

dspillett2• 14 years ago

> 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.

stiff3• 14 years ago

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.

Drbble• 14 years ago

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 "

stanleydrew3• 14 years ago

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.

stiff3• 14 years ago

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.

tripzilch6• 14 years ago

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

    "We disagree with the P3P header and believe in circumventing it. 
    Read why here: http://xyz"

If FB or Google's headers had said that, at least it wouldn't have been as disingenious. Saying you don't support P3P--oops! and by saying that we broke it! whoops!

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.

freehunter3• 14 years ago

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.

tripzilch6• 14 years ago

In that sense NO ENTRY signs are also broken. And so is the robots.txt protocol.

bad_user• 14 years ago

No, they couldn't omit the P3P header.

tripzilch6• 14 years ago

Why, did someone tattoo it onto their servers?

zerostar072• 14 years ago

Even from your description, P3P does not work; IE is equally dishonest imho for claiming that P3P provides any kind of privacy.

tripzilch6• 14 years ago

It's a crappy protocol, I agree. I don't see how that's relevant though.

wccrawford• 14 years ago

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.

jxi• 14 years ago

Let's hope the true villains get rightfully punished.

niksuckspg• 14 years ago

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.

stanleydrew3• 14 years ago

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.

socratic2• 14 years ago

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.

AkThhhpppt• 14 years ago

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...

arscan3• 14 years ago

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.

stiff3• 14 years ago

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.

barista• 14 years ago

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?

d2vid• 14 years ago

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

socratic2• 14 years ago

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/

robertc7• 14 years ago

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.

arscan3• 14 years ago

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.

arscan3• 14 years ago

...and by "more useful", I mean "more profitable"...

gabea• 14 years ago

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.

Facebook and many other sites also bypass Internet Explorer privacy controls

Related Stories