6 ms·

Facebook and many other sites also bypass Internet Explorer privacy controls

177 points by nikcub 15y ago

meow 15y ago
Follow the link that facebook provides in its header: http://www.facebook.com/help/?page=219494461411349 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...
- rbarooah 15y ago
  Is it a joke to expect Google to honor user privacy?
  - tripzilch 15y 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.
  - freehunter 15y ago
    It's a joke for people to expect that P3P is a good privacy model.
    - rbarooah 15y ago
      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.
niksuckspg 15y 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.
- stanleydrew 15y 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.
zerostar07 15y 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 15y 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.
magicalist 15y 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 https://bugs.webkit.org/show_bug.cgi?id=35824
- mayanksinghal 15y 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.
  - magicalist 15y 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.
markokocic 15y 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 15y 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.
  - tripzilch 15y 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.
  - robertc 15y ago
    Where does P3P allow me to manage this trust relationship you say it's based on?
- socialized 15y 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.
- robertc 15y 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.
- dspillett 15y 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.
stiff 15y 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 15y 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 "
tripzilch 15y 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.
- freehunter 15y 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.
  - tripzilch 15y ago
    In that sense NO ENTRY signs are also broken. And so is the robots.txt protocol.
    - stanleydrew 15y ago
      But "No Entry" signs and robots.txt are broken for the same reason. We all know that, so how is it a counterargument?
    - freehunter 15y ago
wccrawford 15y 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 15y ago
  Let's hope the true villains get rightfully punished.
deleted 15y ago
[deleted]
socratic 15y 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.
arscan 15y 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.
- arscan 15y ago
  ...and by "more useful", I mean "more profitable"...
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
deleted 15y ago
[deleted]
gabea 15y 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.

177 points by nikcub 15y ago

meow 15y ago

Follow the link that facebook provides in its header: http://www.facebook.com/help/?page=219494461411349 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...

rbarooah 15y ago
Is it a joke to expect Google to honor user privacy?
- tripzilch 15y 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.
- freehunter 15y ago
  It's a joke for people to expect that P3P is a good privacy model.
  - rbarooah 15y ago
    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.

niksuckspg 15y 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.

stanleydrew 15y 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.

zerostar07 15y 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 15y 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.

magicalist 15y 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 https://bugs.webkit.org/show_bug.cgi?id=35824

mayanksinghal 15y 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.
- magicalist 15y 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.

markokocic 15y 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 15y 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.
- tripzilch 15y 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.
- robertc 15y ago
  Where does P3P allow me to manage this trust relationship you say it's based on?
socialized 15y 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.
robertc 15y 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.
dspillett 15y 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.

stiff 15y 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 15y 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 "

tripzilch 15y 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.

freehunter 15y 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.
- tripzilch 15y ago
  In that sense NO ENTRY signs are also broken. And so is the robots.txt protocol.
  - stanleydrew 15y ago
    But "No Entry" signs and robots.txt are broken for the same reason. We all know that, so how is it a counterargument?
  - freehunter 15y ago

wccrawford 15y 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 15y ago
Let's hope the true villains get rightfully punished.

deleted 15y ago

[deleted]

socratic 15y 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.

arscan 15y 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.

arscan 15y ago
...and by "more useful", I mean "more profitable"...

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

deleted 15y ago

[deleted]

gabea 15y 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.