1161679 - Privacy concerns with prerendering

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Tanvi Vyas[:tanvi]]

With prerendering, a website can tell the browser to prerender a specific document for performance reasons.  Then, if the user clicks on the document, the prerendered document will load seamlessly for the user.

The problem with this is that we are making network requests without the user's consent.  A user maybe at an airport or a coffee shop using public wifi.  They may be careful to only visit https pages and make sure all mixed content is blocked.  They don't want any of their data in the clear on the public wifi.

If we then prerender an http page, the user's cookies for the http domain are exposed in the clear.  The browser also leaks data about the https page the user is currently on (perhaps the user is visiting https://bank.com and the prerendered page is for http://affiliate-of-bank.com).

One solution is to enforce a mixed content check on prerendered documents.  https pages can only prerender https pages.  http pages can prerender anything.  This solution is unfortunately not great for https search pages that can't fully control whether the most popular search for a keyword is over http or https.

On the other hand, the website can also cause the same data leakage by doing a window.open to the http domain.  But at least that is a little more obvious to the user.  They have to go through a yellow notification bar to allow popups and then they clearly see than an http domain was visited.  With prerendering, they have no visibility into the fact that an http network request was made on their behalf.

Comment 1

[Dave Garrett]

In line with the recent Mozilla policy change to stop supporting new features over insecure HTTP, added with the fact that there are obvious security & privacy concerns here, I don't think it's worth allowing HTTP prerendering at all. Just enforce an HTTPS requirement for all prerendering, with no mixed-content exceptions. I don't see a reason to take any risks making it any more complicated than that.

Comment 2

[Dave Garrett]

(In reply to Tanvi Vyas [:tanvi] from comment #0)
> the website can also cause the same data leakage by doing
> a window.open to the http domain.

On HTTPS pages we really should prohibit all HTTP window.open(), meta refresh, XMLHttpRequest, etc., but that's another topic of discussion.

Comment 3

[Tanvi Vyas[:tanvi]]

(In reply to Dave Garrett from comment #1)
> In line with the recent Mozilla policy change to stop supporting new
> features over insecure HTTP

That's not quite the new policy.  According to [1], the date to stop support new HTTP features hasn't been set yet. 

[1] https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing
https://groups.google.com/forum/#!topic/mozilla.dev.platform/xaGffxAM-hs[1-25]

Comment 4

[Dave Garrett]

(In reply to Tanvi Vyas [:tanvi] from comment #3)
> the date to stop support new HTTP features hasn't been set yet.

I'm aware of that, however the date to implement and release this feature isn't set yet either. I'm saying that this is a feature with security concerns that make sense to make it one of the first new features which should be following this new policy.

Comment 5

[Dave Garrett]

(to be more precise in my wording, the date at which this will be implemented and tested sufficiently to release to the general public in a stable Firefox release)

Comment 6

[Tanvi Vyas[:tanvi]]

Hi Pat,

It's come to my attention that the browser already does some form of preloading webpages on browser startup that may have the same privacy issues that are described here in comment 0.  Does the browser prerenders the top X sites a user visits at startup?  Can you tell us a little more about how that works?  Steve said that that feature went through a sec/privacy review, so information from that review would also be helpful.  Also, is there a pref to turn that feature off?

Thanks!

Comment 7

[Patrick McManus [:mcmanus]]

(In reply to Tanvi Vyas [:tanvi] from comment #6)

> It's come to my attention that the browser already does some form of
> preloading webpages on browser startup that may have the same privacy issues
> that are described here in comment 0.  Does the browser prerenders the top X
> sites a user visits at startup?  

not that I'm aware of (but that wouldn't really be necko code - it would be someone calling necko, so I might not be aware).

Can you tell us a little more about how
> that works?  Steve said that that feature went through a sec/privacy review,
> so information from that review would also be helpful.  Also, is there a
> pref to turn that feature off

I think you are confusing pre-render with the network predictor - try not to use the term pre-render when talking about the predictor as there as nothing is rendered or even downloaded. (separate from what iirc ehsan was working on). The predictor makes connections but not requests based on what it anticpates is happening - e.g. you click on cnn.com and it also opens conns to subdomains in parallel because in the past these things were linked. it also tracks how many cnn.com conns you traditionally used, etc..

nick can provide more details, there certainly are prefs and things are held back in PB mode.

we (in the broader gecko sense - it might not be necko code) will at some point be adding downloads and rendering though - they are important competitive issues. We should apply https restrictions for things that have web-facing markup.. but for what exists so far it can be polyfilled by an attacker (at least from a privacy perspective if not a performance one) mutating the cleartext anyhow, so its not a good candidate to worry about backdating the policy on imo.