1767407 - web.whatsapp.com does not work in PRIVATE BROWSING Mode due to needing indexedDB support

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Raul Bucata]

Environment:
Operating system: Windows 10 x64
Firefox version: Firefox Nightly 102.0a1 (2022-05-02) (64-bit)

Preconditions:
Private browsing mode enabled
Clean profile

Steps to reproduce:

1. Navigate to: https://www.sbtnews.com.br/
2. Observe the result.

Expected Behavior:
The page loads

Actual Behavior:
The page is stuck in a loading loop.

Notes:

• Reproducible using Firefox Focus Release and Nightly.
• Not reproducible in Normal Browsing Mode regardless of the status of ETP.
• Screenshot attached.
• The "Refresh" button is changing state.

Comment 1

[Raul Bucata]

Attachment: Screenshot_3.png

Comment 2

[Thomas Wisniewski [:twisniewski]]

This is another case of Firebase:

Uncaught (in promise) FirebaseError: Messaging: This browser doesn't support the API's required to use the firebase SDK. (messaging/unsupported-browser).

Edit: that's the problem on the https://www.sbtnews.com.br/ URL, at least.

Comment 3

[Thomas Wisniewski [:twisniewski]]

For whatsapp, if we enable dom.indexedDB.privateBrowsing.enabled in about:config, then the site loads, so this is a case of private browsing not supporting iDB.

Comment 4

[Paul Zühlcke [:pbz]]

Tom, do you think we could add an intervention / shim for this? Or generally, for popular Firebase APIs?

Comment 5

[Thomas Wisniewski [:twisniewski]]

It's unclear at this point, though I'll take a look at it ASAP. If the Firebase APIs don't really need a full iDB implementation, it might be doable (at least as an interim fix before we can get the full implementation done).

Comment 7

[abhinavsecondary]

Hi team

I don't think the issue is fixed yet. As I am able to reproduce same behavior on WhatsApp web that I have reported(duplicated with this issue)

Thanks & Regards
Abhinav

Comment 8

[Thomas Wisniewski [:twisniewski]]

Yes, this is still an issue due to WhatsApps Web using Firebase APIs which apparently require web APIs not available yet in Firefox Private browsing mode. I've taken a look here, and this is the check Firebase is failing to succeed on:

self && 'ServiceWorkerGlobalScope' in self
  ? 'indexedDB' in self &&
     null !== indexedDB &&
     'PushManager' in self &&
     'Notification' in self &&
     ServiceWorkerRegistration.prototype.hasOwnProperty('showNotification') &&
     PushSubscription.prototype.hasOwnProperty('getKey')
  : 'indexedDB' in window &&
     null !== indexedDB &&
     navigator.cookieEnabled &&
    'serviceWorker' in navigator &&
    'PushManager' in window &&
     'Notification' in window &&
    'fetch' in window &&
     ServiceWorkerRegistration.prototype.hasOwnProperty('showNotification') &&
     PushSubscription.prototype.hasOwnProperty('getKey')

So Firebase's messaging module seems to be designed to just assume that sites using it will always require Service Workers and IndexedDB to function.

I'm not sure that's actually the case, though. If I pause https://www.sbtnews.com.br/ while it loads, and define the objects like this, then I don't see any actual breakage on their main page:

window.indexedDB = {
  open: () => Promise.reject({ message:"" });
}
navigator.serviceWorker = {
   addEventListener() {},
   getRegistrations: () => Promise.resolve([]),
   register: () => Promise.reject({ message:"" })
 };

So it seems worth testing this further. With a simple webcompat shim like the above, we may be able to fix at least specific sites.

I'm not at all sure if that will work for WhatsApp Web, though. Their page redirects like crazy, so we'll need to make an actual shim to test it, and odds seem good that they actually would use iDB or serviceworkers (whether or not they actually require them is the question). And if they do, faking them may not be be a viable or useful solution for users.

Comment 10

[Thomas Wisniewski [:twisniewski]]

So it does seem as though they actually do rely on indexedDB (via Dexie.js), to store something related to encryption keys, so I don't think it would be wise to use a "fake" iDB here. That said, we can at least prevent the awful redirection loop and just have the page break while loading by using a shim which just defines a stub for iDB with an open method which always rejects its promise.

Comment 11

[Thomas Wisniewski [:twisniewski]]

A work-around which fixes the ugly redirect loop just landed in https://phabricator.services.mozilla.com/D149711

The page is still broken, however, so I'm leaving this bug open for now.

Comment 13

[Morpheus Ziplon]

Attachment: Browser Console 23.12.2022.jpg

Comment 15

[Daniel Holbert [:dholbert]]

Comment on attachment 9309654 [details]
Browser Console 23.12.2022.jpg

[obsoleting a Browser Console screenshot that was requested over on dupe bug 1806429 but turned out to not have any relevant logging]

Comment 16

[Thomas Wisniewski [:twisniewski]]

I'm not sure what the latest needinfo request was intended to ask here, but the status of this bug is just that we're basically stuck until private browsing mode supports the APIs that WhatsAppWeb requires (indexedDB at least, the work for supporting which is being tracked in bug 1639542).

Comment 17

[Tassilo Horn]

FWIW, I have this issue (web.whatsapp.com loads the QR code indefinitely) not in private mode but when Enhanced Tracking Protection is set to Strict. With the Standard setting, the QR code loads just fine.

I'd prefer to stay in strict mode but unfortunately adding an exception for https://web.whatsapp.com/ didn't help. It seems to be effective, though, at least I see the striked through shield symbol int the address bar.

Comment 18

[Dan Mehic]

With dom.indexedDB.privateBrowsing.enabled being set to true as default, web.whatsapp.com loads as expected in PBM with Firefox Nightly 125.0a1.