Ask HN: Dealing with IE8's InPrivate Blocking
Has anyone made changes to their site to address IE8's InPrivate Blocking? If so, what did you do?
When enabled InPrivate Blocking will block a resource when a user's browser has seen the resource referenced across 10 different sites. So for example, with InPrivate Blocking on, jQuery sourced from Google will be blocked by IE8 after the browser sees that file sourced by more than 10 sites.
You can read more about it at http://blogs.msdn.com/ie/archive/2008/08/25/ie8-and-privacy.aspx under the "InPrivate Blocking" section.
You could obviously host everything that you need yourself to get around this, if you are pulling things like jQuery from Google.
If you host a file that is sourced by others, with some server side URL rewriting, you could allow for random strings to be added to the URL that would be ignored by your server. This would allow others sourcing from you to create unique URLs for the file so that a user's IE8 browser won't see the same URL sourced across multiple sites.
Any other ideas?
Comments
Do nothing, and let Microsoft and their customers sort it out.
When Microsoft makes a (potential) blunder so many Web developers seem feel it's their responsibility to work around it. It's not. Microsoft and the IE team try hard not to "break the Web". If they missed, chances are very good they'll fix it. If not, it's not your responsibility to work around the breakage.
Has this been a problem for you in practice? Have you had user complaints about it? If not, why are you worried about it? If so, tell your users to work it out with Microsoft or try another browser.
We're serving ads so working across as many browsers as possible is important to us. Also from a customer service perspective, telling a client that ads won't work on their site because of feature X in browser Y isn't always the best option.
IE8 isn't that wide spread yet so it hasn't been a problem in practice, but we are working on a solution to address this in case the inprivate blocking becomes very popular in the wild.
We are handling this problem in exactly the same way that we handle people running no-script and/or super high security settings - ignore them. It's such a minimal problem as to be worthless to resolve.