IE, P3P, IFrame and blocked cookies (works until page host page has personal information requested)

Question

My company has a little widget that plugs into shopping carts. We are running into a problem where setting cookies in IE7 is not working. This is happening because we are a 3rd party because we are embedded into the site via an iframe.

I have seen several post that say the way to solve this problem is by putting a P3P compact policy in the header. As mentioned:

Cookie blocked/not saved in IFRAME in Internet Explorer

I have verified that my P3P policy is in my HTTP header. And it actually works for the first page/step of the shopping cart site, but as soon as there is personal information on the page (like name, address, phone, etc), IE blocks my site and my cookie.

I have tried several different P3P policies and they all don't work at the same place. I have also used the IBM P3P tool to generate my own special P3P policy, but it still doesn't work.

I am at a complete loss.

Undertow

Answer 1

This probably won't help anyone else, but I was banging my head against the wall for weeks over this one. It turns out that IE 7 won't allow 3rd-party cookies to be set, even with a valid P3P compact policy if the HTML meta tag for Content-Type has a different character set declaration on the page with the iframe from the page within the iframe.

Pot

It gave me hope for a couple minutes. :D – Oogenesis

Answer 2

I had a similar issue sometime ago myself. Make sure you add the p3p header to all the pages inside the iframe.

Keely

Thank you for the hint. I have verified, though, that the p3p header is there for all of the content I am serving up. (I used ieHTTPHeaders) – Undertow

Ok..Change privacy settings in ie and then test it with low security. If it works then the issue is with your source code. You can also use FF with web security tool bar. Change privacy setting and use Web developer tool bar to see what is happening with the cookie. – Keely

Shobab, thanks for the hints. I lowered my security in IE and it changed my site's cookie status from "blocked" to "restricted". This DID work for me. Restricted is good enough. I'm not sure what the issue could be with my source code -- maybe my p3p policy is not good enough? Where can I find the FF web security toolbar? It would be great to find something that tells me why my p3p policy is not good enough. – Undertow

Search for Webdeveloper tool bar for FF and you will get it. Its a must tool for web developers. Its defenitely the issue with your p3p header. In web developer tool bar there is an option to check p3p headers so use it. That was how I solved my issue. I know how you feel because I was behind this issue for a week ;-) feel free to email me at shobankr[at]gmail.com and i will be glad to help. BTW Shoban is my name not shobab ;-) – Keely

Thank you again, Shoban. I am unable to find a validator for p3p headers. I can use the web developer toolbar (v 1.1.6) to see my p3p header, but I see nothing that validates it. – Undertow

David, email me at shobankr[at]gmail.com .. with sample source code. I will have a look at it (?) – Keely

FYI, IE 7-8(-9?) will hate you if your server sends 304 responses. Those do not (cannot due to RFC) contain P3P header, and IE requires all responses to contain it. https://mcmap.net/q/765067/-ie-p3p-iframe-and-blocked-cookies-works-until-page-host-page-has-personal-information-requested – Cowpuncher

Answer 3

There is a very insidious Internet Explorer 7 bug to be aware of: on a 304 ("Not Modified") request inside an iframe the P3P header will not be sent by the web server as per the RFC (unless you are using IIS, which doesn't care about such things). IE7 will actually delete any cookie set during that specific request.

This will have the effect you describe above so perhaps that's what's going on. IE6 & IE8 (and every other browser) work as expected.

Husch

Looks like it affects IE8 too. – Mores

Answer 4

The Fiddler web debugger (www.fiddler2.com) has a "Privacy" inspector tab on the response which decodes the P3P tokens into their meanings. There's a link at the bottom of the inspector which points to the MSDN article that shows which policies are considered "acceptable" by default.

Note, of course, that P3P policies are a Legal declaration, so you must be sure that your use of cookies matches what you claim in P3P.

Demos

The link at the bottom of Fiddler takes you to this page, which only describes the acceptable policies for IE6: msdn.microsoft.com/en-us/library/… Anyone know of a more recent reference? – Cinnabar

The P3P defaults have not changed since IE6. – Demos

@EricLaw: Yours is an ancient answer, of course, but was the Privacy inspector tab removed from Fiddler? I'm running Fiddler 4 (still labeled fiddler2 - v4.4.2.1 beta) and I don't see it anywhere (nor do I remember seeing it in previous versions) – Dogmatism

Answer 5

We ran into the problem described above, with the 304 requests (cached content). Our load balancer was setting a session cookie, but the Apache web server would not include the P3P header for requests that resulted in the 304 result code. So then the session info would get messed up.

So this is something to be aware of with Load Balancers. When they set a cookie for persistence tracking, make sure it also generates the P3P header, to make sure they are always sent in tandem.

Calcutta

Answer 6

I had the same issue and decided to take the Google/Facebook approach and fake out the P3P header. I did end up having some problems though.

1. First you must make sure that you pass that header with ALL.
2. If you are using the Visual Studio Development Webserver the P3P header will be ignored for some reason. So host your app in IIS.

Problem 1:

To return that header with all of your requested actions add this to your Global.asax, customizing it for your needs of course:

 protected void Application_BeginRequest(Object sender, EventArgs e) {
            //
            HttpContext.Current.Response.AddHeader("P3P", "CP=\"This is not a P3P policy! See http://mydomain.com/privacy-policy for more info.\"");
        }

Problem 2:

Pretty self explanatory. Host your project in IIS.

I made the decision to bypass the P3P when I read that W3C had not worked on or updated the standard since 2006. That to me, means it is dead and we just have a major browser enforcing a dead standard. The project was mine, I was/am the client. So if you plan on taking the same actions and you're not writing something for yourself, check with the powers that be.

Cheers!

Understanding

Answer 7

The cookie should have expires=Fri, 19-Dec-14 18:00:40 GMT and not max-age.

This is controlled in Apache mod_usertrack by the config CookieStyle=Netscape

Cowpuncher