Today, I fought with (and conquered!) getting third-party cookies enabled in Safari and Internet Explorer. There was a bunch of scattered information about this problem on the Internet, so I will either add to the noise or help someone out with this post.

Both Safari and Internet Explorer have default privacy settings that are quite harsh on third-party cookies, and both browsers need some consideration in order to get them working correctly. With the proliferation of widgets on the internet, third-party cookies are quite common, so I’m surprised there isn’t a more thorough treatment of the issue (though don’t expect one here!).

Internet Explorer

Internet Explorer (I tested with IE7) has a default privacy setting of “Medium”, which requires that sites issuing third-party cookies must have a Compact Privacy Policy (P3P) header. The best documents I’ve found on this subject are here and here. Pay particular attention to the “Unsatisfactory Cookies” section in the first document; use the second document to determine your appropriate P3P header. Once you are correctly serving an appropriate P3P header, third-party cookies should start to work in Internet Explorer.

Safari

Safari (I tested with Safari 4) has a default third-party cookie setting of “Accept cookies: only from sites I visit.” I took this to mean sites that are the topmost frame (e.g., url showing in the address box). A colleague of mine, Dave Mosher, saw me struggling with this and casually mentioned that the user must first interact with the frame in order to set third-party cookies. This is an interesting, Apple-ish approach; I suppose if I interact with the frame, I have explicitly “visited” it. Further, this solution would work out for many third-party cookie scenarios (e.g., a login) because the cookie isn’t set until after some sort of interaction. In our case however, we need to set the cookie on the very first load before the user has a chance to interact. So, to make this work, the best I could come up with was: for Safari, if our cookie wasn’t present, I introduced an interstitial screen that effectively asked the user to click a link, which allowed us to set a third-party cookie. Unfortunately, I could not find anything more elegant, but this is better than many of the other proposed solutions I found (including popping new windows, using HTML5 Local Storage, etc.). Finally, as long as this cookie is present, you are free to read it before the user interacts with your frame; i.e., if it is a permanent cookie, the user will see the interstitial screen only once (of course depending on your particular cookie setting logic).

Caveat: you may also require the P3P header for Safari. I had it in place while I discovered the Safari solution, so I’m not sure if it works without it.