Googlers hate it! This one weird trick lets websites dodge Chrome 76's defenses, detect you're in Incognito mode A week ago, Google released Chrome 76, which included a change intended to prevent websites from detecting when browser users have activated Incognito mode. Unfortunately, the web giant's fix opened another hole elsewhere. It enabled a timing attack that can be used to infer when people are using Incognito mode. On Sunday, …
"Web publishers with paywalls dislike Incognito mode because it prevents the setting of cookies to limit article consumption among non-paying visitors."
Articles are read not consumed. After an article is read it's still there, after something is consumed the exact same thing is no longer available.
This particular issue affects more than 1 browser. It's like the Spectre bug on CPUs. A general purpose engineering technique used to improve CPU performance adopted by many designers is found to have issues, more or less severe, depending on implementation details.
Therefore a general programming technique to prevent incognito/private browsing from leaving bread-crumbs - not allowing filesystem access - has lead to this issue. Firefox has a similar issue dating back for years (lot of too-ing and fro-ing in the bug report, being closed and then re-opened, assigned, unassigned, forgotten about, found again when it leads to other issues...) that is finally being fixed.
One site I used to read, wral.com (a semi-local news site), now blocks people using adblockers. On the site was an old article about ads tracking users, and contained instructions to install Adblock Pro. I emailed them and pointed out the hypocrisy - having been blocked because I was running Adblock Pro - and their response was to delete the old article.
Time to find a new semi-local news site.
This post has been deleted by its author
IMHO the pay walls are generally on the more trustworthy sources of news, as people are more prepared to pay for properly researched and thought out content, and the people that generate it, are morelikley to wna to be recompensed for their work.
Wheras the trash rags and extremists on both sides want people to read their message, and expand their brand, without forcing people to pay for them. (they usually end up begging a lot like the Guardian does)
But, as stated in the article, this is still open to compromise:
Li however is skeptical that a different strategy would lead to improved privacy. "While it’s resistant to our attacks, it leaves behind metadata: even if the data itself cannot be decrypted, its mere existence provides evidence of incognito usage, and leaks when the user last used incognito mode and the approximate size of the data they wrote to disk," Li's post claims.
Li however is skeptical that a different strategy would lead to improved privacy. "While it’s resistant to our attacks, it leaves behind metadata: even if the data itself cannot be decrypted, its mere existence provides evidence of incognito usage...
However, if normal mode uses exactly the same strategy, then the presence of an (encrypted) page file or virtual disk file does not provide evidence of incognito usage. Basically, Chrome needs to and should treat both modes identically and sandbox etc. sessions, just that with normal mode the sandbox leaks so that stuff can crossover (ie. normal mode is just a less secure incognito mode).
I thought the same.
The article claims that the meta-data and data are stored in memory - hence faster write speed.
A Google engineer proposed keeping the meta in memory and the writing encrypted data to disk. Personally, I think just writing random data of the same size to disk is better.
Jesse Li counters that this still leave meta-data around. I'm not sure what meta-data Li is talking about - that in memory?
I don't see how "evidence" that incognito mode was used is "bad". Is it not better to do sensitive things (like banking) in incognito mode than not? Surely, we haven't yet come to the point where incognito mode has come to be equated with unsavoury behaviour on the net?
Or simply disable the filesystem API in both normal mode and incognito... which the article states is what they intend to do long term.
The detection routines will quickly be dropped when normal users are accused of being in incognito mode, but false readings the other way around would be somewhat acceptable.
>A possible fix would be to keep the data in memory as is the case now, but simultaneously write random data of the same size to the filesystem...
Or turn the flaw in Chrome on its head: In normal mode, why should the (additional) time taken to write data physically to disk be visible to a lowly third-party webpage script? So perhaps the solution is for normal mode to operate mode like incognito mode, only that save also includes the background task action: flush this file to HDD.
However, as the "weird trick" requires some form of calibration to work - does it need to compare normal and incognito mode file saves or can it make its determination from only seeing incognito mode saves?, I suspect we won't being seeing widespread usage of it.
"The only way to prevent this attack is for both Incognito mode and normal mode to use the same storage medium, so that the API runs at the same speed regardless," Li wrote.
if (incognito_mode) { write_to_memory(); wait(10); } else { write_to_disk(); }
I'd write it properly on multiple lines, but the forum separates them into paragraphs.
"I'd write it properly on multiple lines"
No worries. Whitespace should have no syntactical meaning anyway.
Except in Whitespace, of course.
Whitespace is insane.
I'll bet the writers at my alma mater used a macro pre-processor to actually write the programs, though.
Back in my day though, the languages that were taught there were PL/1 and APL (and people learned C of course, as they were a very early Unix adopter).
"Whitespace is insane."
Not really. It's more a parody and/or satire ... but one that works.
Something often missed when it comes to such languages: It made the authors think more about the design and implementation of programming languages than simply learning a handful of languages might. Likewise, anybody learning to use it will have several "ah-hah!" moments that will be usable with more normal languages. These things force the user to think beyond the simplicity of the school chalkboard.
Besides, as any fule no, the definition of insanity is writing a C compiler in Sendmail's configuration language without the help of M4 ...
I was thinking something like this, although a bit more sophisticated.
That is, the browser gathering read/write performance data/metrics of real filesystem read/writes it is doing, and using those metrics to dynamically insert delays of appropriate amounts (size, read or write) based on its own internal metrics when using incognito modes temporary memory store (as opposed to non-incognito's normal disk store).
Just Wonderful. So now, at the behest of advertisers, we are potentially creating a situation where a website will work differently on machines with slow disks than those with faster disks even within the same household or business. "No Madam Librarian, I don't want the new PC. weareslimeballs.com doesn't work there. I'll wait for the old 486 in the corner."
Will advertisers push for this? What do you think?
This has nothing to do with disk performance of different computers.
This is about the differing performance of disk stores vs memory stores on the same computer, whether lightning fast SLC SSD or a 5400rpm slow laptop HDD. The speed of even the fastest SSD available pales in comparison to memory, it is an order of magnitude or more difference, with spinning rust being a further 1 or 2 orders further back.
To avoid leaving 'fingerprints' on the computer, a browser in incognito/private mode will not write to disk, it will use a memory store instead (similar to a ramdisk). A browser not in incognito will write to disk. A smart website, using javascripts, can detect that performance difference irrespective of the actual type of disk (fast SSD, Optane, slow HDD) being used. Therefore the website will know that incognito/private is being used, and tell you to f-off, you aren't allowed to use the site at all.
At least, that is the consequence of Chrome's fix.
However, without the fix it is even easier to detect incognito mode and refuse service. Prior to this fix, the browser simply did not allow any file access at all. So the website (again via javascript) will attempt to read/write a file, and get a "not allowed" error back, therefore it now knows incognito is being used.
Therefore this issue already exists in multiple browsers from multiple vendors (i.e. Chrome, Firefox, probably others). Chrome has attempted to fix it with this fix, but this article is pointing out that this doesn't fix the existing issue. Or rather, it fixes the existing mechanism used to detect incognito, but introduces a new mechanism that is a little harder to use to detect incognito.
This is about the differing performance of disk stores vs memory stores on the same computer, whether lightning fast SLC SSD or a 5400rpm slow laptop HDD. The speed of even the fastest SSD available pales in comparison to memory, it is an order of magnitude or more difference, with spinning rust being a further 1 or 2 orders further back.
For many years now, my SOP has been to symlink browser cache and local store directories to a ramdisk as a part of my .login script. This has the twin benefits of speeding the things up rather considerably, and guaranteeing that the browser won't accidentally-on-purpose forget to purge some of its remotely-set cruft when I restart. The downside (if you want to call it that) is that I have to re-enter my credentials after a reboot, instead of relying on the browser to remember them.
For this setup, the only difference between the incognito and normal mode is the lifetime of the files - not the speed at which they are are accessed (ok, except for the overhead of the filesystem layers - which presumably is small compared to the medium speed, except for the ramdisk).
In any event, like any copy-protection measure, timing-based incognito mode detection will only end up inconveniencing and alienating the users - including those willing to pay. In my particular case, I do subscribe to an electronic version of my local newspaper - even though essentially all content they probide is also available online wihout a paywall. The reasons are simple: I feel the need to support a reliable local news source, and I much prefer news sources which, like the printed or an electronic newspaper, remain immutable once they are punlished. This way I (or my local library) can save them, and refer to them later if needed.
There is absolutely no way I will subscribe to a random site which nags me to give them money because I was curious about a couple of articles linked to from elsewhere; if they become too persistent, and it can't be cured by an adblock or noscript, I simply won't come back, ever.
"This is about the differing performance of disk stores vs memory stores on the same computer, whether lightning fast SLC SSD or a 5400rpm slow laptop HDD. The speed of even the fastest SSD available pales in comparison to memory,"
The performance of disk stores on a computer with lots of spare memory will be just as fast as memory stores, even with spinning rust, due to something called cacheing.
Is this not fales on "write, wait for response, continue" loops? As in, yes, loading from cache is faster, but writing, and then waiting for confirmation (in case of no disk space or needing to verify access rights, or needing to read else where) would be slower on each type of hardware down the chain.
Even multithreaded apps and filesystems, might have the browser window in a single thread with a wait chain.
"Recently, my mom was browsing for a new pair of glasses, and upon visiting marveloptics.com, her antivirus software started flashing alerts over some malicious javascript. Always curious to see how real-world attacks work, I reverse engineered it."
~Jesse Li~
https://blog.jse.li/posts/marveloptics-malware/
(And in case you're wondering, yes, the malware is still being served up)
"... send recursively calls itself every 30 milliseconds (!). They really don’t care about performance. ..." [https://blog.jse.li/posts/marveloptics-malware/] cute
No damn wonder that my Javascript enabled browsers (Firefox, Opera) are prone to lock up occasionally if I browse beyond the Reg, Wikipedia, Phys.org -- despite my blocking most advertisers in the hosts file in a token attempt at self-defense.
It's pretty clear that Javascript (and similar technologies) must die. They are simply way too capable for end user safety. The issue should be how to get rid of them in an orderly fashion not whether they can/should be tolerated.
It doesn't provide full filesystem access - only a cache directory.
We'd be the first people to complain about storing personal data "in the cloud" or on somebody else's server. Storing your data on your computer obviates the whiff of impropriety. (It also saves the bucks on storage and bandwidth.) It's particularly useful for app-like functionality.
That said, the filesystem API is a nightmare; IndexedDB, although itself a pre-Promise PITA, is a better bet.
Are there any legitimate uses for a website to detect how quickly data can be read/write from the browser cache?
Maybe a work around would be to make that function have to be manually given permission by the user for the few sites that require to be able to read and write data at a specific speed?
I try not to use Chromium either. Google is turning on a feature that beacons to Google whatever link you clicked on. They don't need a javascript tracker or some such to make it work. You also won't be able to turn it off. Then theres DNS over https which is an effort to capture all of your dns traffic, too. Google is also turning off the ability to disable it. their implementation sends all of your queries to either Google's or Cloudflare's DNS servers. make centralized tracking of you even easier. Moreover all the browsers use Google's webkit (Safari, Brave, Vivaldi for example) except for Firefox.
Even Firefox is putting in DNS over https, but you can disable it or change where it sends queries.
Punting chrome and chromium
Just put a delay after the write to memory. If you can't tell if it's a fast SSD or memory with a delay, then it has to be permitted.
That also implies that at some point crappily written websites will fail because storage is too fast for it - memory disk anyone?
"The only way to prevent this attack is for both Incognito mode and normal mode to use the same storage medium, so that the API runs at the same speed regardless,"
How about just fixed write throughput regardless of storage media? How fast does a browser really need to write things to disk / RAM?
Li's statement doesn't actually follow from the description in the article. The difference between normal mode and incognito mode is in absolute speed and in variability, but unless you can persuade the browser to run your website in both modes (in which case, why are you bothering?) you cannot actually observe the former (*) and so the only evidence of incognito mode is the reduced variability, which should be pretty easy to fix with a random sleep. Even better, since the random sleep only happens in incognito mode, it won't even hurt your main benchmarks.
(* Other commenters have noted that the absolute difference is that of spinning rust versus memory, but still others have noted that any half-decent caching scheme will conceal that.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
