Open Bug 1890906 Opened 1 year ago Updated 1 year ago

pwa permission leak in private mode

Categories

(Firefox for Android :: PWA, enhancement)

Product:
Firefox for Android
Component:
PWA
Version:
Firefox 124
Platform:
All
Android
Type:
enhancement

Tracking

()

People

(Reporter: jacksonwang, Unassigned, NeedInfo)

References

Details

(Keywords: privacy, reporter-external, sec-want)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36

Steps to reproduce:

A similar issue exists at https://bugzilla.mozilla.org/show_bug.cgi?id=1807434. However, this report is different and provides concrete examples. The steps are as follows:

  1. Use normal mode on Android Firefox to visit https://pwa-demo.github.io/plus, allowing geolocation, microphone, and camera permissions with "Remember decision for this site" checked.
  2. Switch to private mode and visit https://pwa-demo.github.io/plus, then download the PWA from private mode.
  3. Open this PWA from the home screen, then click on the microphone, camera, and geolocation. All three permissions inherit from normal mode instead of private mode.

Actual results:

The PWA installed from private mode inherits microphone, camera, and geolocation permissions from normal mode instead of private mode.

Expected results:

It should have the same behavior as private mode in the browser. Browsers should ask for permission every time a user visits that URL, even if the "Remember decision for this site" option is checked.

I think this is exactly the same issue as bug 1890914 in that our UI is very misleading. We don't have private mode installed apps. We should either prevent installation, support that use-case, or put up a confirmation screen notifying people that the saved thing won't be private.

Another complaint people have is that any of these values are shared at all. For some people that's what they want, but others want the installed apps to essentially have their own isolated universe ("profile" in our implementation). We definitely have --that-- on file as a feature request.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(bugzeeeeee)
Keywords: privacy
See Also: → 1890914

Thanks for the explanation; yes, they are basically the same issue.

This bug seems more like bad and misleading user-experience leading to potentially surprised and unhappy users, but not a "vulnerability" that can be weaponized against people and therefore need to be hidden. Un-hiding the bug

Group: mobile-core-security
Keywords: sec-want
Severity: -- → N/A
You need to log in before you can comment on or make changes to this bug.