Why not let incognito mode write to disk, but entirely encrypted and randomly padded (to avoid size memorization attacks), with keys only stored in memory? That way you can use practically the entire storage space and avoid quota mismatches, as well as service attempts to fill the storage for detection. And in the event of a crash or power outage, no data is recoverable.
Bypassing anti-incognito detection in Google Chrome
41–50 of 114 posts
Re: Bypassing anti-incognito detection in Google Chrome
#42I run Chromium with --user-data-dir , the current directory , and the environment variables HOME and XDG_CACHE_HOME all set to directories within a tmpfs (/tmp). It is better than "Incognito mode". https://bbs.archlinux.org/viewtopic.php?pid=1733332
Wonder if it's possible to make something like that on Windows
Re: Bypassing anti-incognito detection in Google Chrome
#43Tracked by https://crbug.com/959839
Re: Bypassing anti-incognito detection in Google Chrome
#44Earlier quoted context omitted.
What if you want both?
Indeed – I have a hard time believing that the vast majority of people who want one of these things wouldn't also want the other.
Hypothetical examples:
I don't want the New York Times to ID me, but I don't care if my wife knows I read it.
I don't want red tube to forget about my all access pass, but I don't want it in my browser history.
Re: Bypassing anti-incognito detection in Google Chrome
#45Why not let incognito mode write to disk, but entirely encrypted and randomly padded (to avoid size memorization attacks), with keys only stored in memory? That way you can use practically the entire storage space and avoid quota mismatches, as well as service attempts to fill the storage for detection. And in the event of a crash or power outage, no data is recoverable.
I've wondered why many things don't do this. Is it because it's difficult to guarantee that writing to memory doesn't eventually get swapped to disk by the OS?
Re: Bypassing anti-incognito detection in Google Chrome
#46Why not let incognito mode write to disk, but entirely encrypted and randomly padded (to avoid size memorization attacks), with keys only stored in memory? That way you can use practically the entire storage space and avoid quota mismatches, as well as service attempts to fill the storage for detection. And in the event of a crash or power outage, no data is recoverable.
I wonder if encryption is even necessary.
Isn't the purpose of Incognito mode to protect against tracking inside the browser? At least I haven't heard so far that its also supposed to shield data from access outside the browser.
So, wouldn't be enough to simply delete the space after closing the tab? (Or use a new, empty storage location for each newly opened tab)
Re: Bypassing anti-incognito detection in Google Chrome
#47Why not let incognito mode write to disk, but entirely encrypted and randomly padded (to avoid size memorization attacks), with keys only stored in memory? That way you can use practically the entire storage space and avoid quota mismatches, as well as service attempts to fill the storage for detection. And in the event of a crash or power outage, no data is recoverable.
I wonder if encryption is even necessary. Isn't the purpose of Incognito mode to protect against tracking inside the browser ? At least I haven't heard so far that its also supposed to shield data from access outside the browser. So, wouldn't be enough to simply delete the space after closing the tab? (Or use a new, empty storage location for each newly opened tab)
Deletion doesn't mean the data is actually gone from disk though, so it would basically leave unencrypted evidence of incognito browsing history. There are multiple use cases for incognito, and tracking inside the browser is only one of them.
Re: Bypassing anti-incognito detection in Google Chrome
#48I run Chromium with --user-data-dir , the current directory , and the environment variables HOME and XDG_CACHE_HOME all set to directories within a tmpfs (/tmp). It is better than "Incognito mode". https://bbs.archlinux.org/viewtopic.php?pid=1733332
Wonder if it's possible to make something like that on Windows
please do realize that using chrome, even in incognito mode, everything you do is sent to google.
Re your question: I use Firefox with 1st party cookies only (and the other associated privacy options) and it works pretty good. Some WebApps break, but very rarely.
Re: Bypassing anti-incognito detection in Google Chrome
#49Why not let incognito mode write to disk, but entirely encrypted and randomly padded (to avoid size memorization attacks), with keys only stored in memory? That way you can use practically the entire storage space and avoid quota mismatches, as well as service attempts to fill the storage for detection. And in the event of a crash or power outage, no data is recoverable.
I've wondered why many things don't do this. Is it because it's difficult to guarantee that writing to memory doesn't eventually get swapped to disk by the OS?
In some OS’s you can specify that certain pages of memory should never be swapped.
Re: Bypassing anti-incognito detection in Google Chrome
#50I run Chromium with --user-data-dir , the current directory , and the environment variables HOME and XDG_CACHE_HOME all set to directories within a tmpfs (/tmp). It is better than "Incognito mode". https://bbs.archlinux.org/viewtopic.php?pid=1733332
Wonder if it's possible to make something like that on Windows
Chrome does have guest profiles: Click your user icon, and there'll be an "Open Guest Window" button.
> "You’re browsing as a Guest"
> "Pages you view in this window won’t appear in the browser history and they won’t leave other traces, like cookies, on the computer after you close all open Guest windows. Any files you download will be preserved, however."
It's kind of like Incognito, except none of your preferences or extensions are there, either, it's just an entirely new profile that self-destructs when you close it.
The OP's detector considers a guest profile not to be Incognito mode.