EJ is a user on mastodon.me.uk. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

Chrome's private browsing is broken

This defeats the purpose of Incognito. If any website is able to tell you're browsing in private mode, then the browser is leaking data that shows it's not private

@cypnk Unfortunately it's fairly easy to detect private browsing in all major browsers. E.g. here's how the Boston Globe does it: bugzilla.mozilla.org/show_bug.

This is definitely something browsers ought to fix, but it's tricky because of how you need to handle certain types of storage in private mode (localStorage, IndexedDB, etc.).

EJ @ej

@nolan @cypnk Would it not be obvious simply by the 'quietness' of private-browsing? Rather than simply not leaking data, wouldn't a browser have to replace whatever kinds of data it hands out in regular-browsing mode? If this is so, I think it'd probs. be hard to generate convincing spoof data in a manner that wasn't detectable to clever server-side data-gatherers..

@ej @nolan That would also block visitors who are coming from a fresh installation of a browser. I think it's some other combination of data

There is some difference in the header data
E.G. Here are my incognito headers vs regular headers in Chrome (courtesy of DuckDuckGo)

@cypnk @nolan In this particular case, then, wouldn't you either have to stop passing the referrer header field in regular browsing mode too, or else start passing (say) "referrer=fictional-domain.org" in private browsing mode, so's the server can't see the difference between modes?

@ej @nolan It may not be just that. I can confirm that the page loads fine with JS disabled so this is a multi-faceted fingerprint issue