Open Bug 1542898 Opened 1 year ago Updated 3 months ago

W3C Manifest start_url may be a fingerprinting vector

Categories

(Core :: DOM: Core & HTML, enhancement, P3)

enhancement

Tracking

()

People

(Reporter: ehsan, Unassigned)

References

Details

Attachments

(1 file)

See https://blog.lukaszolejnik.com/tracking-users-with-rogue-progressive-web-applications/.

We can probably provide some level of protection when resistFingerprinting is turned on, such as fetching the manifest twice (perpahs once without credentials) and compare the two start_urls...

Type: defect → enhancement

My short comment: while it solves part of the problem (and this is good), it is not needed to use cookies when installing the manifest (That's actually the bonus of https://pwapprehension.sensorsprivacy.com, not my main point)

Yes, that's true. :/ There may be better options available for verifying whether different "users" get unique versions of the manifest.

To me, this seems very related to the HSTS supercookie problem.

The arms race for HSTS is:

  • unique subdomains
  • unique top level domains

The arms race for start_url is:

  • unique parameters
  • unique subdomains
  • unique top level domains

If we restricted start_url to be a top level domain (like Bug 1447011), we would push the economic cost for attackers to be too expensive to track everyone.

See Also: → 648186, 1447011

Marcos, do you think such a restriction could fly for start_url?

Flags: needinfo?(mcaceres)

(In reply to Tom Ritter [:tjr] from comment #3)

To me, this seems very related to the HSTS supercookie problem.

I think the attack is different to HSTS: HSTS was a passive attack in which the user had no control or knowledge of what was going on - they also didn't have a means to inspect the requests of an origin.

With manifest, it's different because manifests are literally just a bookmarking mechanism. A presupposition with manifests is that:

  • a web application is installed via a user gesture (same as a bookmark, a user has to access a menu, click on thing, etc.).
  • The start URL should be inspectable and changeable (same as a bookmark).

However, if the browser was to passively install PWAs without user consent, then yes... this would be a problem. However, I don't think we have any plans to do passive installation of web applications (e.g., into the new tab page). But if we do, then this becomes a concern

This is similar to any other passive bookmarking mechanisms, like "top suggestions" from the awesome bar. But if those get cleared when you clear history, so would these. Will add a screenshot.

If we restricted start_url to be a top level domain (like Bug 1447011), we would push the economic cost for attackers to be too expensive to track everyone.(In reply to Ehsan Akhgari (:ehsan) from comment #4)

Marcos, do you think such a restriction could fly for start_url?

Again, because installation requires user interaction (via an installation ceremony of sorts) I think the cost to attackers is already significantly high. Chopping the start_url seems like it would limit the utility of the feature significantly.

Flags: needinfo?(mcaceres)

The article in comment 0 talks about the risk of installing PWAs generated automatically from a manifest from an app store like Android's FWIW. Do you think the bookmarking analogy would apply to such installation mechanisms as well?

(In reply to Ehsan Akhgari (:ehsan) from comment #7)

The article in comment 0 talks about the risk of installing PWAs generated automatically from a manifest from an app store like Android's FWIW. Do you think the bookmarking analogy would apply to such installation mechanisms as well?

I think so... you would still need to go to search-engine.com, it would need to direct the user to app.com?user=id (or use some kind of third party-cookie), and then the user would still need to install or bookmark the application.

The user needs to be on the actual application's website to install it.

You need to log in before you can comment on or make changes to this bug.