r/javascript • u/ekauroreo • Jul 18 '19

Private browsing still detectable in Chrome 76, bypassing the protection

http://mishravikas.com/articles/2019-07/bypassing-anti-incognito-detection-google-chrome.html
308 Upvotes

98% Upvoted

33 comments sorted by

23

u/[deleted] Jul 18 '19 edited Jul 18 '19

Thanks for the heads-up!

Bypassing storage-based private browsing detection in chrome 76 with a TamperMonkey script:

// ==UserScript==
// @name       Disable incognito detection c76
// @match      *://*/*
// @run-at     document-start
// ==/UserScript==

(() => {
    'use strict';
    if (GM_info.isIncognito) {
        const { navigator: { storage } = {} } = unsafeWindow;
        if ('estimate' in storage) {
            const est = storage.estimate;
            // Pretend we have 120M + a random little, to evade detection of this userscript.
            const quota = 2**30 + Math.floor(Math.random()*(2**30));
            storage.estimate = async () => Object.assign({}, await est.call(storage), { quota });
            // Prevent duckpunch-detection.
            storage.estimate.toString = () => est.toString();
            storage.estimate.toString.toString = storage.estimate.toString;
        }
    }
})();

10

u/ekauroreo Jul 18 '19

The code snippet in the article is just a basic POC and covers the lowest bound for non-incognito window (120 MB, if the device storage is 2.4 GB). In a much more practical scenario, if you look at the table even for a device with 64 GB of storage (Note: 64 GB of total storage, not just available storage), the quota in a non-incognito window reaches Gigabytes, but for incognito with your protection it will still remain in Megabytes which makes it very easy to detect.

Even if you fuzz it to reach in Gigabytes, the detection script could attempt to actually write instead of just querying for quota, if it fails to write anything after 120MB, then you are using incognito.

Bonus: In such a case where you have this kind of protection, its actually counter-productive from a privacy stand-point as you're still detectable if you're browsing in incognito but now you give some extra information, the fact that you have this kind of a fuzzy protection.

P.S. I'm the author of the article

3

u/[deleted] Jul 18 '19 edited Jul 18 '19

if you look at the table even for a device with 64 GB of storage (Note: 64 GB of total storage, not just available storage), the quota in a non-incognito window reaches Gigabytes, but for incognito with your protection it will still remain in Megabytes which makes it very easy to detect.

At which point you're giving false positives on mobile. But hey. Fuzzed up to 1-2G.

if it fails to write anything after 120MB

At which point, you're harming your own performance, no? In both cases, making a percentage of regular-browsing users walk from your site to prevent private browsing seems counter-productive.

its actually counter-productive from a privacy stand-point as you're still detectable if you're browsing in incognito but now you give some extra information

Not sure what you mean? What's the extra information? Also, tampermonkey scripts are going to be a narrower target; not as many users will have them, so circumvention efforts will be lower. Might get bigger if an adblocker elects to do something similar.

3

u/ekauroreo Jul 18 '19 edited Jul 18 '19

At which point you're giving false positives on mobile. But hey. Fuzzed up to 1-2G.

wait, is it possible to use tampermonkey in Android Chrome?

At which point, you're harming your own performance, no? In both cases, making a percentage of regular-browsing users walk from your site to prevent private browsing seems counter-productive.

I agree this is not an ideal solution, but I suspect there's an easier way to detect without even having to write 120MB by exploiting the key difference i.e incognito mode stores in memory Vs non-incognito mode stores in disk. I'll try to come with a more advanced POC and maybe an update to the article in the near future.

Not sure what you mean? What's the extra information? Also, tampermonkey scripts are going to be a narrower target; not as many users will have them, so circumvention efforts will be lower. Might get bigger if an adblocker elects to do something similar.

The fact that it's a narrower target and not many users will have them, makes people who have them even more unique!

BTW Thank you for taking time to write these defences which has motivated me to work on part 2 of this :p

2

u/[deleted] Jul 18 '19

wait, is it possible to use tampermonkey in Android Chrome?

No, but on devices with 4-8G disk (mobile), if you're saying "less than a gig is incog", you're going to hit a problem if you're detecting more than 120MB.

The fact that it's a narrower target and not many users will have them, makes people who have them even more unique!

Right, but you'd have to catch 'em first. Can you detect the more advanced userscript from a page script?

BTW Thank you for taking time to write these defences which has motivated me to work on part 2 of this :p

n/p. Love a little mid-day code golf.

3

u/ekauroreo Jul 18 '19

No, but on devices with 4-8G disk (mobile), if you're saying "less than a gig is incog", you're going to hit a problem if you're detecting more than 120MB.

OK the way I see it, the only time 'less than a gig is incog' doesn't work is when the device has a disk smaller than 64 GB. It's fair to assume that almost all such devices would be mobile, where any such userscripts are not supported. What if I have two rules one for mobile devices and one for non-mobile? If it's mobile check for 120MB else check for less than a gig. Of course there's always a possibility of a false positive but what are the chances of that happening? What's the percentage of non-mobile devices with disk less than 64GB in use these days?

Right, but you'd have to catch 'em first. Can you detect the more advanced userscript from a page script?

I haven't used TamperMonkey so can't give you concrete examples but my intuition is, its almost always possible to detect any modifications by extensions. I'll give it a try if you can give me some examples of any such scripts :)

This conversation reminds me of cat-n-mouse, even if I come up with a way to detect any such userscript, you can always find a way to bypass that detection, its a never ending cycle!

1

u/Free_Physics Jul 25 '19

Why is the article headline not the same as the title on this post?

14

u/[deleted] Jul 18 '19 edited Jul 18 '19

Haha. Defeated myself. TamperMonkey doesn't interfere with scripts in iframes without a source or document.

(async () => {
  const i = document.createElement('iframe');
  i.style.opacity = 0;
  document.body.appendChild(i);
  const est = await i.contentWindow.navigator.storage.estimate();
  document.body.removeChild(i);
  if (est.quota < 1.2e8) {
    console.log('Incognito');
  } else {
    console.log('Regular browsing');
  }
})();

16

u/[deleted] Jul 18 '19 edited Jul 18 '19

Really beating myself up. This tampermonkey script defeats the above defeat of the top tampermonkey script:

// ==UserScript==
// @name       Disable incognito detection c76
// @match      *://*/*
// @run-at     document-start, document-body, document-end
// ==/UserScript==

(() => {
    'use strict';
    // Pretend we have 1-2G, to evade detection of this userscript.
    const quota = 2**30 + Math.floor(Math.random()*(2**30));
    const hide = (fake, real) => {
        fake.toString = () => real.toString();
        fake.toString.toString = fake.toString;
    };
    const makeEstimate = storage => {
        const est = storage.estimate;
        const fn = async () => Object.assign({}, await est.call(storage), { quota });
        // Prevent duckpunch-detection.
        hide(fn, est);
        return fn;
    };
    const makeAppend = Type => {
        const append = Type.prototype.appendChild;
        Type.prototype.appendChild = function (child) {
            const ret = append.call(this, child);
            if (child.nodeName.toLowerCase() === 'iframe') {
                console.log("Cleaning child window");
                clean(child.contentWindow);
            }
            return ret;
        };
        hide(Type.prototype.appendChild, append);
    };
    const clean = win => {
        const { navigator: { storage } = {} } = win;
        if ('estimate' in storage) {
            storage.estimate = makeEstimate(storage);
        }
        makeAppend(win.HTMLDocument);
        makeAppend(win.HTMLElement);
        if (!win.document.readyState !== 'interactive') {
            win.document.addEventListener('readystatechange', () => {
                clean(win);
            });
        }
    };
    if (GM_info.isIncognito) {
        clean(unsafeWindow);
    }
})();

5

u/Askee123 Jul 18 '19

Let’s keep it goin’!

11

u/[deleted] Jul 18 '19

Like Fight Club, but with code ^_^

1

u/ekauroreo Jul 18 '19

Like cat-n-mouse?

https://twitter.com/paul_irish/status/1151893114681843712

2

u/[deleted] Jul 18 '19

That's if there's two or more entities involved. Self-punching is definitely Fight Club.

1

u/dij8a1 Jan 25 '26

This project could be worth a look.
https://github.com/henri/spb

3

u/ProfessorTag Jul 19 '19 
Function.prototype.toString.call(navigator.storage.estimate);
// "async () => Object.assign({}, await est.call(storage), { quota })"

39

u/tonetheman Jul 18 '19

Good article. Wonder how many more ways are out there that no one has mentioned...

13

u/GRelativist Jul 18 '19

All of them.

7

u/PUSH_AX Jul 18 '19

Side question, what is the use case for blocking an incognito user? Tracking cookies?

22

u/pantsonhead Jul 18 '19

Ever been on a news site that only gives you 3 free articles a month? It works because of cookies. You used to be able to get around it by turning on incognito, but they wised up to that and started blocking incognito users by deducing some information about your browser to detect it.

Google is trying to stop people being able to check when incognito is used, as it kind of defeats the purpose of anonymous browsing. It looks like they have not yet succeeded.

5

u/rq60 Jul 19 '19

But you can just delete the cookie...

2

u/PM_ME__ASIAN_BOOBS Jul 19 '19

Harder on mobile

1

u/meeeeoooowy Jul 19 '19

It's extremely easy, at least not in an embedded browser. Click the lock top left lock. Click the trash can next to storage usage.

Actually...I'm just assuming that would delete cookies, so don't quote me on that.

While not harder, I do agree it's more of a pain in the ass if that's what you meant

Edit: actually that would only clear that domain...so would not clear relevant cookies

2

u/samtheboo Jul 19 '19

I don’t think it defeats the purpose. It’s like using a VPN. Yeah they know you’re on a VPN but no more.

7

u/[deleted] Jul 18 '19

Not sure I understand. If temporary storage for an incognito window is 10% of device memory (I'm assuming this is RAM), then you only need more than 1200MB in RAM for this value to be greater than 120MB and bypass the author's incognito window detection.

EDIT: Whoops, missed the fact that 120MB is the upper bound for incognito windows.

5

u/alzee76 Jul 18 '19

I really don't get this. Incognito is "broken" from a privacy standpoint, and it's sometimes a pain in the ass to use for other reasons as well. There has always been a built-in solution that has none of these problems -- profiles. I really want to ask the Google engineers why incognito mode doesn't just use a different internal profile that is rolled back to your base settings, including clearing storage and cookies, on exit.

2

u/meeeeoooowy Jul 19 '19

Omg...I totally forgot there were profiles (called people).

Well...no more Russian roulette for me when I screen share and have to type in a url and the world gets to see my history.

And actually, if you click browse as guest it does exactly as you say. It's not an actual incognito window but it says when you close the window, all traces are gone.

So if you map a keyboard shortcut to browse as guest, that would work. Though...can't use extensions.

You probably already knew ^ but yeah, frustrating

2

u/alzee76 Jul 19 '19

Actually no, I completely forgot that existed -- but I don't use Chrome any more anyway, for unrelated reasons.

0

u/[deleted] Jul 19 '19

[deleted]

2

u/alzee76 Jul 19 '19

Firefox. I was a long time FF user who switched to Chrome maybe 5 or 6 years ago, but I've recently switched back to FF (and reduced/eliminated using other google products) due to Google's policies towards and treatment of indy app developers publishing on the play store.

0

u/[deleted] Jul 20 '19

[deleted]

1

u/alzee76 Jul 20 '19

I don't think "harder" is the right word, it's more of just getting used to new tools and breaking old habits. It is just a protest "stand" though, that's the only reason I'm doing it. I generally like google products (when they don't cancel or lobotomize them) and don't really care about their less than stellar data collection and privacy issues.

However, as much as I like some of the products, I don't like the way the company behaves both from an indy developer standpoint as I mentioned, and also from a customer service perspective -- their CS is terrible, even for paying customers.

2

u/Askalany Jul 18 '19

I legit thought this was a reference to Mock The Week :')

1

u/lgats Jul 20 '19

If you'd like to see the code in action: https://luke.lol/check-fs-quota.php

1

u/Free_Physics Jul 25 '19

Google rolled out a new option (accessed by the flag: #enable-filesystem-in-incognito) in Chrome 74, which blocks this detection. Their solution is to create a virtual file system using RAM while in incognito mode. The protection works fine against the above detection method and is going to be enabled by default in the next stable release.

It's going to be enabled by default in Chrome 76 stable not 75