I can't speak for Chromium, but we're dealing with the same thing in Gecko. I am not following the discussions about this super closely, but from what I've gathered just from observing discussions...
I can't speak for Chromium, but we're dealing with the same thing in Gecko. I am not following the discussions about this super closely, but from what I've gathered just from observing discussions involving the developers who are in the know, it's a bit of a conundrum.
Fundamentally the browser has to offer a semblance of the full DOM API in private/incognito contexts. In some cases, these APIs can just be no-ops. Things start to get thorny when you start involving APIs that preserve state or store data. If a site is feature testing for incognito and tries to store some data, you probably can't just send that data to /dev/null, as their feature test will likely then try to retrieve that same data to ensure that it worked. OTOH, you probably don't want that data to make it to disk in any way. Do you store that data in-memory? What if the site attempts to store a lot of data? How much should we care whether or not that data can be swapped to disk?
Unfortunately the implementation of many of these DOM APIs likely did not foresee the necessity of needing to handle cases like this, so they need to go back and add special code paths for the private browsing case.
Thanks for the insight! Just spitballing, but what if the amount of data that could be stored wasn't a constant? If users were allowed to adjust this value (even indirectly, such as through...
Thanks for the insight!
Do you store that data in-memory? What if the site attempts to store a lot of data?
Just spitballing, but what if the amount of data that could be stored wasn't a constant? If users were allowed to adjust this value (even indirectly, such as through security presets), then the website could no longer say for sure if you were using incognito/private browsing.
I don't know if that'd be enough to discourage them. But maybe the warnings would change to "You may not use incognito nor heightened security settings", which would be worse optics for them.
How much should we care whether or not that data can be swapped to disk?
If we're going down the rabbit hole, then even storing in memory could be a tell because it will be faster. Storing to temp (with the browser running sweeps to clean often) makes more sense to me.
Hard to say about the speed thing. We already had to artificially constrain the resolution of performance timers as a Spectre mitigation, so it’s hard to say how useful that would be as an attempt...
Hard to say about the speed thing. We already had to artificially constrain the resolution of performance timers as a Spectre mitigation, so it’s hard to say how useful that would be as an attempt to distinguish between memory and disk.
If it's so difficult to stop from a technical standpoint, perhaps Google, Mozilla, Microsoft and Apple should instead use their market power to force sites to stop trying to detect...
If it's so difficult to stop from a technical standpoint, perhaps Google, Mozilla, Microsoft and Apple should instead use their market power to force sites to stop trying to detect incognito/private windows instead. E.g. Name & shame the sites that do it, block their API access, reduce their PageRank, etc. And surely there are other things that can be done to punish sites that do it, or would that be seen as crossing a line?
That would be very controversial because, for example, it would mean blocking the New York Times and attacking their primary source of revenue. "Google goes to war with the newspapers" isn't a...
That would be very controversial because, for example, it would mean blocking the New York Times and attacking their primary source of revenue. "Google goes to war with the newspapers" isn't a good look. They got plenty of blame already for AMP, and that was supposed to help the newspapers (with more mobile traffic, and without preventing them from running ads, just cleaning up the user experience a bit).
So they are instead trying to make nice where they can, though often their efforts aren't appreciated since it's still the case that most newspapers are losing money fast and going out of business and technical adjustments aren't likely to move the needle there.
I don't see what could improve the economics other than moving to a subsidy model, and having lots of newspapers being essentially paid for by Google wouldn't be good for journalistic independence, to say the least.
(There are ways these subsidies happen anyway. Like for example, when I was there Google was paying for free access to Linux Weekly News for all their employees.)
LOL, true. But is there anything stopping the rest from trying to dissuade sites from doing it? Is it just taboo for browser companies to try to force sites to behave a certain way (or not behave...
LOL, true. But is there anything stopping the rest from trying to dissuade sites from doing it? Is it just taboo for browser companies to try to force sites to behave a certain way (or not behave a certain way, as it were), or is there some legit reasoning or legal ramifications for them not to (other than bad press, as @skybrian mentioned)? Genuinely asking out of curiosity, not trying to shame anyone, BTW.
I think it should be possible to fake it. A workaround is to create another user profile and then delete it when you're done. I had assumed it would take a few rounds to get it right, but it seems...
I think it should be possible to fake it. A workaround is to create another user profile and then delete it when you're done.
I had assumed it would take a few rounds to get it right, but it seems the Chrome team gave up on this project early.
Offtopic, but is it possible to have the URL point to a de-amped version of the URL? i.e. https://www.zdnet.com/article/incognito-mode-detection-still-works-in-chrome-despite-promise-to-fix/
Offtopic, but is it possible to have the URL point to a de-amped version of the URL? i.e.
Without fully exposing the full system API on incognito windows, what fix would be appropriate?
I can't speak for Chromium, but we're dealing with the same thing in Gecko. I am not following the discussions about this super closely, but from what I've gathered just from observing discussions involving the developers who are in the know, it's a bit of a conundrum.
Fundamentally the browser has to offer a semblance of the full DOM API in private/incognito contexts. In some cases, these APIs can just be no-ops. Things start to get thorny when you start involving APIs that preserve state or store data. If a site is feature testing for incognito and tries to store some data, you probably can't just send that data to
/dev/null, as their feature test will likely then try to retrieve that same data to ensure that it worked. OTOH, you probably don't want that data to make it to disk in any way. Do you store that data in-memory? What if the site attempts to store a lot of data? How much should we care whether or not that data can be swapped to disk?Unfortunately the implementation of many of these DOM APIs likely did not foresee the necessity of needing to handle cases like this, so they need to go back and add special code paths for the private browsing case.
Thanks for the insight!
Just spitballing, but what if the amount of data that could be stored wasn't a constant? If users were allowed to adjust this value (even indirectly, such as through security presets), then the website could no longer say for sure if you were using incognito/private browsing.
I don't know if that'd be enough to discourage them. But maybe the warnings would change to "You may not use incognito nor heightened security settings", which would be worse optics for them.
If we're going down the rabbit hole, then even storing in memory could be a tell because it will be faster. Storing to temp (with the browser running sweeps to clean often) makes more sense to me.
Hard to say about the speed thing. We already had to artificially constrain the resolution of performance timers as a Spectre mitigation, so it’s hard to say how useful that would be as an attempt to distinguish between memory and disk.
If it's so difficult to stop from a technical standpoint, perhaps Google, Mozilla, Microsoft and Apple should instead use their market power to force sites to stop trying to detect incognito/private windows instead. E.g. Name & shame the sites that do it, block their API access, reduce their PageRank, etc. And surely there are other things that can be done to punish sites that do it, or would that be seen as crossing a line?
That would be very controversial because, for example, it would mean blocking the New York Times and attacking their primary source of revenue. "Google goes to war with the newspapers" isn't a good look. They got plenty of blame already for AMP, and that was supposed to help the newspapers (with more mobile traffic, and without preventing them from running ads, just cleaning up the user experience a bit).
So they are instead trying to make nice where they can, though often their efforts aren't appreciated since it's still the case that most newspapers are losing money fast and going out of business and technical adjustments aren't likely to move the needle there.
I don't see what could improve the economics other than moving to a subsidy model, and having lots of newspapers being essentially paid for by Google wouldn't be good for journalistic independence, to say the least.
(There are ways these subsidies happen anyway. Like for example, when I was there Google was paying for free access to Linux Weekly News for all their employees.)
I dunno, would Google be willing to do that to sites that also happen to spend big dough on ads?
LOL, true. But is there anything stopping the rest from trying to dissuade sites from doing it? Is it just taboo for browser companies to try to force sites to behave a certain way (or not behave a certain way, as it were), or is there some legit reasoning or legal ramifications for them not to (other than bad press, as @skybrian mentioned)? Genuinely asking out of curiosity, not trying to shame anyone, BTW.
I think it should be possible to fake it. A workaround is to create another user profile and then delete it when you're done.
I had assumed it would take a few rounds to get it right, but it seems the Chrome team gave up on this project early.
Offtopic, but is it possible to have the URL point to a de-amped version of the URL? i.e.
https://www.zdnet.com/article/incognito-mode-detection-still-works-in-chrome-despite-promise-to-fix/
Done.