Hacker News new | ask | show | jobs
by socratic 5228 days 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.

4 comments

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.

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/

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