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