1542898 - W3C Manifest start_url may be a fingerprinting vector

Status: NEW

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

Description

[(no longer active)]

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...

Comment 1

[Lukasz]

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)

Comment 2

[(no longer active)]

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

Comment 3

[Tom Ritter [:tjr]]

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.

Comment 4

[(no longer active)]

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

Comment 5

[Marcos Caceres [:marcosc]]

(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.

Comment 6

[Marcos Caceres [:marcosc]]

Attachment: Passive bookmark where a unique ID is retained from history...

Comment 7

[(no longer active)]

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?

Comment 8

[Marcos Caceres [:marcosc]]

(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.

Comment 9

[Anne (:annevk)]

Lukasz, have you looked into whether there are there ways for other sites to obtain the state from "installed" sites somehow?

If not, then the main thing to do here might be that if the user clears storage for a site, we could also suggest removing any bookmarks and PWAs associated with that site or some such.

Comment 10

[Lukasz]

Other sites? I guess not, unless by this you mean the dedicated API getInstalledRelatedApps, unless other ways is some cache timing based on the icon loading or so but I would not overcomplicate here...

While purging PWA sounds reasonable it should probably be well explained to the user to avoid surprises. It's intriguing you'd kick out the bookmarks too (yes I realize the ways these two may be similar, but how frequently are such specific bookmarks actually used in comparison to PWA use is anyone's guess).