Just when you think you’ve seen every frustrating browser issue a webmaster can hope to be frustrated by… another is sure to come along.
Recently I got a call from a client that some people were having trouble logging into an alumni database I had built for them. I tested these people’s logins in every browser I had handy and they worked fine. No one else was having problems logging in. So I went to the job site (meatspace, mind you) and sure enough, I couldn’t log in as anyone from two machines, both running IE6. Javascript was enabled. Cookies were enabled. What the heck was going on?
The site uses HTML hosted on a virtual domain at earthlink and database data coming from phpwebhosting.com, all married together in a frameset. Login authentication is handled via PHP sessions.
So why weren’t any logins working from IE6? This one took quite a while to figure out.
First of all, PHP sessions are really just a simplified wrapper for a specialized form of cookie. So start with the realization that cookies aren’t getting planted even though cookies are enabled in the browser.
IE6 has a cookie tolerance slider that defaults to Medium. On the Medium setting,
“Internet Explorer prevents Web sites from storing third-party cookies that do not have a compact privacy policy or that use personally identifiable information without your explicit consent. The browser also prevents Web sites from storing first-party cookies that use personally identifiable information without your implicit consent.”
Compact Privacy Policy? That’s a new one on me. So I look it up. Ah. So now I have to find out how to implement a compact privacy policy. The spec is out there, but I decide not to read the entire thing. CNET has a good overview of what webmasters are going through since IE6 was released.
Finally, I find the deployment answer in a PHP forum. It turns out that this problem affects my site only because it pulls data from two different sources. A user at php.net writes:
“MSIE 6 has an inaccurate definition of third party cookies. If your domain is hosted on one server and your PHP stuff is on another, the IE6 P3P implementation considers any cookies sent from the second machine “third party”. Third party cookies will be blocked automatically in most privacy settings if not accompanied by what MS considers “an appropriate Compact Policy”. In order to make this new piece of tweakable garbage happy I’d suggest you’d par exemple send
header(’P3P: CP=”NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM”‘);
before sending your cookie from your second machine. This header enables your cookie to survive any privacy setting.”
So in the end I went to privacycouncil.com and filled out the wizard, which generated a CPC similar to the one above, and started spitting it back to the browser from the top of the site’s authentication code.
What a huge hassle. And I shudder to think how many sites this going to affect. Mind you, the intention behind it is good. But in practice it’s virtually useless, since you can literally make up the privacy policy - the technology doesn’t have any necessary bearing on ACTUAL company privacy policy. In most cases, the frustrated webmaster is simply going to fill out a wizard like I did and implement a pseudo-accurate privacy policy, rather than taking it to management. So what you’re left with is a lot of hassle and a lot of broken sites, but without any guarantee that user privacy is any better protected than it was.
P3P weirdness continues...
We ran into the same problem. The official "suggestion" from Microsoft was to add the header.
P3P: CP=TST
According to the P3P description, this should mean "Test privacy policy, ignore". But for IE6, it also means third-party cookies are allowed.
Always great to "embrace and extend", isn't it?
G. Wade
P3P weirdness continues...
Ah, good tip, thanks. Again, this points to the fact that the spec is nearly pointless, since the "fix" gets around any actual privacy policy.
bad advice
While I understand why you folks took the approach you did to P3P compact policies, I must caution everyone who reads this that they should not take any of this advice. A P3P privacy policy is similar to a natural language privacy policy, in that it is a commitment from a web site. A web site that makes a false or misleading statement in a privacy policy or a P3P policy (or a P3P compact policy) risks legal action. No web master should post a P3P policy without consulting with people in their organization who are authorized to make policy decisions.
Furthermore, the suggestion of including a P3P compact policy that contains only the TST token, will not solve the problem raised here. Only some vesions of IE6 treat CPs with the test token as valid CPs. My understanding is that later versions of IE6 treat sites with CPs that contain the test token as if there was no CP.
Also be aware that it is improper to post a P3P compact policy without also posting a full P3P policy. While you may be able to post just a compact policy to get around IE6 cookie blocking, this is not valid P3P and, again, might be considered a deceptive practice.
For good information on P3P, please visit p3ptoolbox.org or www.w3.org/p3p/. There are pointers on both of these sites to discussion lists where you can ask questions about P3P-enabling your web site.
I am a co-author of the P3P specification and author of a forthcoming O'Reilly book called "Web Privacy with P3P" that should be out in August.
P3P
this is the bain of my existence
P3P
agreed. im a student using a cookie based forum through a frame and this has just created so many headaches.