search

WICG / nav-speculation

Proposal to enable privacy-enhanced preloading
https://wicg.github.io/nav-speculation/
Other
154 stars 35 forks source link

On abusing cross-origin prerendering to incriminate a user subject to network monitoring #155

Open KenjiBaheux opened 2 years ago

KenjiBaheux commented 2 years ago

From issue #101, there is a question about if/how cross-origin prerendering could be abused to incriminate a user subject to network monitoring.

The following scenario has been proposed as an example:

"A work place looking to discredit an employee who is attempting to unionize workers; or a corrupt government authority set out to "find" evidence that would get the devices of an investigative journalist seized by law enforcement (where said law enforcement may not be well versed in what a prefetch header is).

More concretely for the former scenario (my assumptions):

  1. An unscrupulous website, likely operated by the company, (e.g. an intranet website) visited by this specific employee would trigger prerendering for a page of a will-get-you-in-trouble website (e.g. a website sharing advices to unionize workers).
  2. This prerendering request will get caught by the company's stringent network monitoring infrastructure and get the employee into trouble.

The second scenario appears to be similar enough in principle.

KenjiBaheux commented 2 years ago

I recognise there are existing ways to plant evidence of unwholesome web browsing activity - but that doesn't mean its okay to introduce functionality to the web platform that lowers the bar to doing so.

At face value, the guidance seems to imply that we should never introduce any new mechanism for fetching content. But, getting things from the network is an on-going bread and butter for the web platform: WebTransport, anonymous iframes, JPEG XL decoding, ModuleServiceWorker, to name a few recent examples. This guidance seems highly impractical.

It's easier and more reliable* to fire a request for a will-get-you-into-trouble page with all the various means that already exists than it is to do so via a prerendering request. Furthermore, with the existing means, the response will be stored in the device's cache whereas with prerendering, the user needs to visit the page to leave a mark in the device's storage.

*: existing means are not "up to the browser", not controlled by a setting or user preferences (e.g. save data), or a group policy; unlike prerendering.

know more about how network monitoring systems differentiate between a normal request triggered explicitly by the user in the UA, a prerendered that the UA has decided to do on behalf of a user, and a fetch request made by a site without the users knowledge.

Typically, network monitoring systems only see things like plain text DNS lookups, TLS handshake with SNI if present, connections to specific IP addresses. Higher level things like purpose or the triggering mechanism are not visible by such systems. If such simple signals on the network were enough to get folks in trouble, then it should already be a huge problem today.

In short, prerendering doesn't bring anything interesting/new over existing mechanisms, and is in fact weaker given that it doesn't have unexpected repercussions on the device's storage.