1366318 - [meta] Prevent websites from detecting private browsing

Status: RESOLVED FIXED

(Firefox :: Private Browsing, task, P3)

Description

[08xjcec48]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170504105526

Steps to reproduce:

Use the private browsing mode to open this: https://www.bostonglobe.com/business/2017/05/16/get-ready-for-even-more-cars-boston-streets/hLt3FFNj0ISHNxFIAdKbEP/story.html


Actual results:

The website identifies that the tab is private, and hides the contents of the article.


Expected results:

Websites shouldn't be able to tell that users are browsing privately and/or force them to use regular tabs.

Comment 1

[Luke Crouch [:groovecoder]]

Marking as P3 [meta] tracking bug. As we discover specific vectors for sites to detect PBM we will file bugs under this one.

Comment 2

[08xjcec48]

The original link now works for me, not sure if because of one of my extensions.

However, this is still able to detect whether the window is private: https://codepen.io/fadupla/pen/EWxKRW

Comment 3

[Mark Baysinger]

The San Diego Union Tribune is doing this now. To reproduce, while private browsing, go to https://www.sandiegouniontribune.com/ and click on any article. I'm not sure what mechanism they are using.

Comment 4

[Thorin [:thorin]]

This is the same issue as Bug 1506680, which has more information

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

Closing as a duplicate of an older bug.

Comment 6

[Simon Giesecke [:sg] [he/him]]

I don't think this is a duplicate of Bug 781982. Bug 781982 is about enabling the use of IndexedDB in private browsing mode. Currently, the unavailability of IndexedDB might be used to identify private browsing mode though, so Bug 781982 might be regarded as blocking this one.

Comment 7

[Kevin Brosnan [Ex-Mozilla]]

There is no reason to have a meta bug with one bug being dependent. It is not a meta in that case it is a direct dupe.

Comment 8

[Simon Giesecke [:sg] [he/him]]

As comment https://bugzilla.mozilla.org/show_bug.cgi?id=1366318#c1 says, specific vectors that allow identification of private browsing mode should be filed under this one. Bug 781982 is one such vector. I am pretty sure it is not we only one, though I don't know if we have more on file.

This is logically a different thing than Bug 781982. If there really were only a single relevant vector, it might make no sense to keep this meta bug open, but it still isn't a duplicate of Bug 781982 in my understanding.

Comment 9

[Johann Hofmann [:johannh]]

I agree with Simon

Comment 11

[Kevin Brosnan [Ex-Mozilla]]

Updating the affected versions is not a useful change. This behavior can be seen on trunk.

Comment 13

[Thorin [:thorin]]

FYI: OPFS/File System API is not available in PB windows

• e.g. promising navigator.storage.getDirectory() will throw a SecurityError
• this does not happen in Incognito Windows on chrome

I'll leave it up to you guys if you want (or have plans) to pursue this.

Comment 14

[08xjcec48]

Andrew, please see #c13. If appropriate, file a new issue and mark it as a dependency of this meta bug.

Comment 15

[Thorin [:thorin]]

Sorry for the noise: this may be out of scope: but there is also GPC which is default disabled (but has a UI setting) but enforced in PB windows. Opt-in doesn't work (only a tiny percentage of users will change the setting), so whilst not 100% accurate, scripts won't care if they seek to punish PB window users. Without getting into why it's not default enabled everywhere - perhaps it can also be enabled with ETP Strict since that implies the user opted in (which is the case with DNT) in e.g. see Bug 1912841 if you want to pursue this. Personally, I think the two signals should be aligned at a minimum - at best, GPC default enabled for all (I still don't fully know why this isn't the case - e.g. Brave does this)

Comment 16

[08xjcec48]

I'm going to close this because there haven't been any replies to the latest comments, and the actual examples we had were addressed by Bug 1639542 and Bug 1959535.

If you come across any website that still prevents Firefox users from accessing it in private windows, please submit a new bug report.

Comment 17

[Thorin [:thorin]]

(In reply to Thorin [:thorin] from comment #13)

FYI: OPFS/File System API is not available in PB windows

• e.g. promising navigator.storage.getDirectory() will throw a SecurityError
• this does not happen in Incognito Windows on chrome

I'll leave it up to you guys if you want (or have plans) to pursue this.

https://github.com/Joe12387/detectIncognito/issues/51 - this is now common knowledge and will be used against PB mode users

Can we at least open an issue to track if we want to match chromium here?

Comment 18

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Thorin [:thorin] from comment #17)

Can we at least open an issue to track if we want to match chromium here?

I've filed bug 1975760 as an enhancement to implement the support. It could also be reasonable to hide the API like it's unsupported rather than throwing (which is something we'd tried for other APIs before we had PBM support, although there were web-compat problems), but that wouldn't do anything for sites that are going out of their way to try and detect PBM since the logic then becomes "check if this is a modern Firefox and it doesn't have BucketFS exposed".

Note that the reporter is the one who closed this bug and I don't have any ownership of this component, so it's not my call to say whether there should be a meta/tracking bug for APIs that differ between PBM and non-PBM. (I personally think it's reasonable; we want our behavior in PBM and non-PBM to be the same for webcompat reasons. Additionally, the priority of constituencies is clear that when there's a conflict between user and site author, user wins.)