Mixed content policy for predictive actions (like prefetch)
Josh Karlin
Ryan Sleevi
What do you mean "Not any less secure"? It violated the privacy guarantees of HTTPS.
Yes, loading any resource over HTTP from an HTTPS sourced page is meant to cause a UI degredating. Even for things like favicons.
David Benjamin
Prefetch is slightly different in that the source document doesn't actually incorporate the result into anything, so we neither break script nor break the promise that all pixels in the tab are authenticated.
We do, however, break the promise that the page can't compute a URL out of data private to that origin and send it over the network in the clear. Insofar as that was a promise anyway; they could convince the user to click a link or a.click() in JS. User needn't even notice the document changing because the HTTP resource might just return 204.
Unless we plan to tighten that which seems difficult to make sound and compatible, I'd actually lean towards saying mixed content for prefetch is not inherently insane. So it's the question of whether the deprecated use case of optimizing plain HTTP is worth the minor complexity of a mixed content carve out for prefetch.
Chris Palmer
mixed-content, is correct.
* A plaintext request was sent, possibly including cookies or other
authenticators, and leaking information about the person's browsing
habits
* Cybervillains may have injected an eeeeevil response (do we parse
prefetched stuff immediately)?
* If prefetch is useful, and it is, it's because the origin is about
to use that prefeteched resource very soon, in which case mixed
content policy definitely applies
> email to security-dev...@chromium.org.
Ryan Sleevi
Prefetch is slightly different in that the source document doesn't actually incorporate the result into anything, so we neither break script nor break the promise that all pixels in the tab are authenticated.
We do, however, break the promise that the page can't compute a URL out of data private to that origin and send it over the network in the clear. Insofar as that was a promise anyway; they could convince the user to click a link or a.click() in JS. User needn't even notice the document changing because the HTTP resource might just return 204.
Chris Bentzel
I believe the current behavior, of treating prefetched HTTP stuff as
mixed-content, is correct.
* A plaintext request was sent, possibly including cookies or other
authenticators, and leaking information about the person's browsing
habits
* Cybervillains may have injected an eeeeevil response (do we parse
prefetched stuff immediately)?
* If prefetch is useful, and it is, it's because the origin is about
to use that prefeteched resource very soon, in which case mixed
content policy definitely applies
David Benjamin
On Fri, Apr 17, 2015 at 8:36 AM, David Benjamin <davi...@chromium.org> wrote:Prefetch is slightly different in that the source document doesn't actually incorporate the result into anything, so we neither break script nor break the promise that all pixels in the tab are authenticated.
I want to be careful here - it's not simply the promise that all pixels are authenticated, but that confidentiality has been maintained.
Exactly. That's what the paragraph below is for. I think it's useful to separate the two when talking about mixed content, so we know exactly what we're trying to compare. There's integrity of the page (code, images, and data), and there's confidentiality of data the page handles. Integrity is not a concern for prefetch, so we're only concerned about confidentiality.
The confidentiality aspect of mixed content is really quite weak (see below), due to the GIANT surface where data can leak if the author is adversarial.
(Incidentally, this is also why I think the data exfiltration parts of CSP are a waste of time. We should just be focused on the code integrity bits, IMO.)
We do, however, break the promise that the page can't compute a URL out of data private to that origin and send it over the network in the clear. Insofar as that was a promise anyway; they could convince the user to click a link or a.click() in JS. User needn't even notice the document changing because the HTTP resource might just return 204.
I think it's worth distinguishing whether there was a direct user action. prefetch is the author choosing to violate the user's privacy, clicking a link (in as much as we can blame the user) is a choice of the user action.
Most things the user can take action on, JS can trigger, hence the element.click() mention. You could also set location.href.
I don't think this is a case where distinguishing the two makes sense. There's a few things where it makes sense to distinguish user-initiated and JS-initiated versions of the same actions (popup blocking, for instance), but I think it's best applicable for weaker "don't annoy the user" types of security policies.
I don't think user gestures are applicable here. Now we need the user to look at the URL in the status before clicking, but the status bar is not generally part of the trusted UI of a browser. (The author could just as easily swap out the URL on mousedown.)
Regardless, none of these are things we yellow-badge on today. If the argument is we plan to yellow-badge them in the future, how long is that badge going to be shown for? The old page is going to disappear as soon as the new navigation commits. (Instead of doing a 204, serve a redirect back to the previous page. It'll flicker a little, but that's it.) It's also unrealistic. Nearly every non-trivial site incorporates some external content and allows links in that content. Some fraction of those links will be to plain HTTP, and we shouldn't penalize those sites for merely linking there.
Alternatively, since an adversarial author is unrealistic, we can give up on treating the confidentiality aspect as a promise to the user. Instead, it's an attempt to catch common authoring bugs. So now we're less talking about whether <link rel=prefetch> breaks a security policy (because nothing it breaks is a policy we enforce) and more whether this is an acceptable use case or a bug we want to proactively guard against.
If used to predict a navigation, I think this is a perfectly acceptable use case. If used to predict a subresource of the current document, this is clearly a bug. So the question is: is the former use case worth not guarding against the latter bug?
Victor Costan
Alternatively, since an adversarial author is unrealistic, we can give up on treating the confidentiality aspect as a promise to the user. Instead, it's an attempt to catch common authoring bugs. So now we're less talking about whether <link rel=prefetch> breaks a security policy (because nothing it breaks is a policy we enforce) and more whether this is an acceptable use case or a bug we want to proactively guard against.
If used to predict a navigation, I think this is a perfectly acceptable use case. If used to predict a subresource of the current document, this is clearly a bug. So the question is: is the former use case worth not guarding against the latter bug?
David Benjamin
Prefetching https would also leak information about your query. You wouldn't leak the full URL, but you would leak the hostnames over DNS. This is the fundamental privacy/performance tradeoff of these kinds of prediction things.
We do provide a global prefetch toggle in Chrome, which I believe prefetch honors. So if a site uses <link rel=prefetch> rather than sneaking by some other way, it'll honor your choice there. You could also imagine a search engine providing some app-level setting to enable or disable this.
Fundamentally, if you use a search engine (or any other website), you trust it with any queries you type into it. Hopefully your search engine does reasonable things with that query---picking good defaults on privacy/performance tradeoffs, honoring user preferences on such things, etc. Exactly what that means (what defaults, what kinds of preferences to expose, etc.) is an interesting question, but not really relevant here.
With "[s]uppose that Google adds [...] I'd rather not have to rely on Google's code [...]", you're talking about enforcement. If some site actively wants to leak a query you type into it against your wishes, there's nothing a browser can realistically do to stop it, mixed content or otherwise. If you give a website some data, you're relying on that website to do what you expected of it.
David
(To be clear, despite my long-windedness, I don't actually have a strong opinion over whether prefetch should be mixed content or no. I do strongly think the core question should be use case vs. bug prevention because there's no security policy here.)
Josh Karlin
So now we're less talking about whether <link rel=prefetch> breaks a security policy (because nothing it breaks is a policy we enforce) and more whether this is an acceptable use case or a bug we want to proactively guard against.
If used to predict a navigation, I think this is a perfectly acceptable use case. If used to predict a subresource of the current document, this is clearly a bug. So the question is: is the former use case worth not guarding against the latter bug?
Chris Bentzel
Ryan Sleevi
On Apr 27, 2015 6:51 AM, "Chris Bentzel" <cben...@chromium.org> wrote:
>
> Are there any updates on thoughts here? If there is any interest in exempting prefetch from mixed-content it would be great to incorporate the changes. I personally think it should be exempt, but understand reasons for why it is included.
>
> Also - if we decide that prefetch of http resources from https pages is treated as mixed-content, would the same also apply to prefetching of https resources from https pages since passive observers could still view DNS requests and SNI in the https handshake?
>
That latter question comes up every few quarters with respect to prefetch and HTTPS. There's an inherent tension about whether or not it is akin to a "master password" - that is, a change that gives users the appearance of security without actually securing them.
The argument for (restricting) is that it is obviously a privacy leak. The argument against is that other leaks exist for passive attackers that have large scale statistical capabilities, some of which cannot be restricted solely by the UA, ergo in either event, we require the server to cooperate in the privacy preservation.
A server that does not cooperate - that uses prefetch, that doesn't mask traffic analysis, that embeds mixed optionally block able content - is a layer 8 problem, not layer 7.
Chris Bentzel
Chris Palmer
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
Chris Bentzel
On Tue, Apr 28, 2015, 2:51 PM Chris Palmer <pal...@google.com> wrote:
I prefer the latter.
(Did we already talk about the possibility of upgrading HTTP prefetches from HTTTPS contexts to HTTPS?)
Not that I'm aware of - but not really sure this is a great approach particularly if subsequent requests are just to the http origin (and hence won't match what got prefetched).
Ilya Grigorik
- Prefetch is marked as "optionally blockable"
- There is a provision for user/UI override that turns "optionally blockable" into a must block.
- There is a provision for site opt-in ("strict checking") that turns "optionally blockable" into a must block.
Ilya Grigorik
Ilya Grigorik
In related news, took a first run at "Security and Privacy" section for Resource Hints (preconnect, prefetch, prerender):