Intent to Implement and Ship: Resource Hints - preconnect

[Patrick Meenan]

Primary eng/PM emails pme...@chromium.org Spec http://w3c.github.io/resource-hints/ Summary Adds support for <link rel="preconnect" href="..."> (and the equivalent HTTP link header) as a hint that the browser should predictively open a connection to the supplied server/protocol for resources that will be needed later in the loading process. Motivation Provides a mechanism for developers to inform Chrome about connections that will be needed at some point in the near future. This will commonly be used for resources that can not be discovered by the preload scanner. Compatibility Risk Firefox: No public signals Internet Explorer: No public signals Safari: No public signals Web developers: Positive Describe the degree of compatibility risk you believe this change poses This is based on a draft spec with wide agreement and similar existing methods that are already widely used (dns-prefetch and prefetch). Ongoing technical constraints None Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)? Yes or no. Yes OWP launch tracking bug https://code.google.com/p/chromium/issues/detail?id=449620 Entry in Chromium Dashboard https://www.chromestatus.com/features/5560623895150592 Requesting approval to ship? Yes

[Chris Harrelson]

LGTM to implement, but I'd like to see more standardization and vendor public signals before shipping.

Also, please address WebView. The template should have been updated, did you use an old version?

On Fri Jan 16 2015 at 11:48:21 AM Patrick Meenan <pme...@google.com> wrote:

Primary eng/PM emails pme...@chromium.org Spec http://w3c.github.io/resource-hints/ Summary Adds support for <link rel="preconnect" href="..."> (and the equivalent HTTP link header) as a hint that the browser should predictively open a connection to the supplied server/protocol for resources that will be needed later in the loading process. Motivation Provides a mechanism for developers to inform Chrome about connections that will be needed at some point in the near future. This will commonly be used for resources that can not be discovered by the preload scanner. Compatibility Risk Firefox: No public signals Internet Explorer: No public signals Safari: No public signals Web developers: Positive Describe the degree of compatibility risk you believe this change poses This is based on a draft spec with wide agreement and similar existing methods that are already widely used (dns-prefetch and prefetch). Ongoing technical constraints None Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)? Yes or no. Yes OWP launch tracking bug https://code.google.com/p/chromium/issues/detail?id=449620 Entry in Chromium Dashboard https://www.chromestatus.com/features/5560623895150592 Requesting approval to ship? Yes

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Patrick Meenan]

I followed the process here: http://www.chromium.org/blink#launch-process, opened a new launch tracking bug manually (using the launch tracking template) and had the dashboard generate the email template.  Looks like the template that was auto-generated by the dashboard entry was using an older template.

Here is the updated section:

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

[Chris Harrelson]

Thanks.

Does anyone know how to update the auto-generated template?

[Mike West]

While implementing, can you please ensure that optimistic connections are gated on the `connect-src` content security policy directive? That is, before connecting, call `ContentSecurityPolicy::allowConnectToSource` and refuse to connect if it returns `false`.

Thanks!

-mike

-Mike

[Mike West]

+Ilya; perhaps you could update the spec to note the dependency as well? :)

-mike

-Mike

[Patrick Meenan]

Will-do, thanks for the heads up because that impacts how the HTTP header version gets processed (have to do it all in blink instead of running a fast path in the net stack).

[Mike West]

Ideally, we would move CSP (and mixed content (and SRI (and probably other things))) processing up the stack. Until that happens, CSP does live in Blink. Sorry for the added complexity. :/

-mike

--
Mike West <mk...@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

[Yoav Weiss]

Last time we discussed it, it seemed like there may be performance benefits to implementation on the net side, but there are certain hints that will be difficult to implement there and trivial to implement on the Blink side. The CSP dependency also came up.

After talking to Pat about it, I'm convinced the right way to go would be to implement Link header support in Blink, and then move (possibly parts of) it to the net side, once CSP support is there and after PlzNavigate lands and shows it's a clear performance win.

Pat - Awesome that you're taking the charge on 'preconnect'! :) I'd love to collaborate on the Resource Hints effort. I'll know more about my plans soon, but at the very least I can polish up my Link header support patch. 

[Brian Smith]

Mike West <mk...@chromium.org> wrote:
> +Ilya; perhaps you could update the spec to note the dependency as well? :)
>

> On Sat, Jan 17, 2015 at 4:50 PM, Mike West <mk...@chromium.org> wrote:
>> While implementing, can you please ensure that optimistic connections are
>> gated on the `connect-src` content security policy directive? That is,
>> before connecting, call `ContentSecurityPolicy::allowConnectToSource` and
>> refuse to connect if it returns `false`.

Sorry to interrupt here. What do you mean by "optimistic connections,"
a term not defined in the resource hints draft? The reason I ask is
because I want to make sure it doesn't mean "any link with
rel=preconnect," but I cannot see what else it could mean.

Thanks,
Brian

[Mike West]

On Mon, Jan 19, 2015 at 5:53 AM, Brian Smith <br...@briansmith.org> wrote:

Sorry to interrupt here. What do you mean by "optimistic connections,"
a term not defined in the resource hints draft? The reason I ask is
because I want to make sure it doesn't mean "any link with
rel=preconnect," but I cannot see what else it could mean.

That was what I meant. It sounds like you think that's a terrible idea. :)

Can you help me understand why?

-mike

[Brian Smith]

I wouldn't say "terrible idea," but I do think it would be a mistake
to tie rel=preconnect to connect-src.

See section 4.1 [1], which talks about a use case for rel=preconnect
that doesn't have anything to do with XHR or websockets (which is what
connect-src is designed to control). Also note that, according to the
resource hints draft, any preload can be reduced to a preconnect at
the browser's choice (see the note in section 3.1), and it would be
strange to treat explicitly preconnects differently from these
implicit/downgraded preconnects.

Here's a motivating example:

* The user enters in https://footbook.example.com/ into the address
bar to load FootBook.

* The response for that document request comes back with the
boilerplate that will be filled in with dynamically-constructed HTML
generated from XHR requests to https://api.footbook.example.com/. We
know that that dynamically-constructed HTML will contain lots of <img
src=https://cdn.footbook.example.com/????> elements, so we want to
tell the browser to preconnect to both
https://api.footbook.example.com and https://cdn.footbook.example.com.

* The page will never make any XHR or websocket requests to
https://cdn.footbook.example.com so connect-src is not relevant to the
page. But, with the proposed change, the Footbook developers would
have to add cdn.footbook.example.com to their connect-src directives.
This would be unfortunate, because performance is at odds with the
principle of least privilege.

Cheers,
Brian

[1] http://w3c.github.io/resource-hints/#dynamic-request-url-preconnect

[Ilya Grigorik]

On Mon, Jan 19, 2015 at 9:19 AM, Brian Smith <br...@briansmith.org> wrote:

* The page will never make any XHR or websocket requests to
https://cdn.footbook.example.com so connect-src is not relevant to the
page. But, with the proposed change, the Footbook developers would
have to add cdn.footbook.example.com to their connect-src directives.
This would be unfortunate, because performance is at odds with the
principle of least privilege.

That's a good point. Looking at Fetch context > CSP directive mappings [1], some types of fetches (e.g. prefetch, subresource) don't have a defined CSP directive... I'm guessing for the very same reason since both prefetch and subresource can be used to fetch any type of resource? 

For preconnect the problem is that the application can end up fetching many different types of resources from the specified origin - e.g. I'm preconnecting to my CDN which has images, fonts, JS, and other stuff. With that in mind, each of those fetches would be subject to its own CSP policy, so perhaps we can/should leave preconnect out? Relevant CSP policies would be enforced at request-time.

[1] https://fetch.spec.whatwg.org/#concept-request-context

[Philip Jägenstedt]

Non-required LGTM to implement, this seems obviously useful for page
load speeds, and I assume the question of interaction with CSP will
easily be sorted out while implementing. Eventually shipping seems
like a given as well, maybe ping this thread when it's available in a
Chrome Canary build for testing?

It seems unlikely, but verifying that Firefox/Safari/IE developers
have no serious objections would also be nice.

Philip

[Patrick Meenan]

Looking at the specs[1] and use cases for connect-src CSP it doesn't look like it applies to the network layer and is explicitly tied to fetches explicitly for XHR, WebSockets and EventSources (more application-level logical connections than network-level sockets).  It is focused on "loading resources" which is why even though preconnect is new it doesn't really fit.

The one extreme edge case I can think of is where someone might be trying to send information out and by virtue of the host name they connect with they could transmit that information but that would work a lot better as a hack on dns-prefetch (otherwise you'd need to rely on SNI and TLS to get host names across) and as far as I can tell, CSP isn't trying to protect against the transmission of data like that, more about sources of data that are allowed to be pulled in to the context of the page.

I'll work on the blink/parser side of things first where it will be easy to wire in but as best as I can tell we don't really want to wire it into the CSP logic.

[1] http://www.w3.org/TR/CSP/#connect-src

[Brian Smith]

'Patrick Meenan' via blink-dev <blin...@chromium.org> wrote:
> Looking at the specs[1] and use cases for connect-src CSP it doesn't look
> like it applies to the network layer and is explicitly tied to fetches
> explicitly for XHR, WebSockets and EventSources (more application-level
> logical connections than network-level sockets). It is focused on "loading
> resources" which is why even though preconnect is new it doesn't really fit.

I agree that preconnect doesn't fit.

The CSP specifications do not specify the network behavior of CSP
directives. In particular, they leave it unspecified, when a CSP
directive blocks a subresource, whether a browser may make a network
request and then refuse to load the response into the document, or
whether the browser must avoid making the network request in the first
place. I am hoping that issue will be addressed in CSP2

My own opinion is that it is best to avoid making the network request
if the CSP policy is violated, because avoiding the fetch minimizes
what an attacker can accomplish with an XSS attack. But...

> The one extreme edge case I can think of is where someone might be trying to
> send information out and by virtue of the host name they connect with they
> could transmit that information but that would work a lot better as a hack
> on dns-prefetch (otherwise you'd need to rely on SNI and TLS to get host
> names across) and as far as I can tell, CSP isn't trying to protect against
> the transmission of data like that, more about sources of data that are
> allowed to be pulled in to the context of the page.

Right. Even if the browser doesn't load a subresource into the page,
the sending of the request itself has side effects that can
potentially be exploited. The current CSP directive set does not
address these side effects. It's something we need to consider for
CSP3.

> I'll work on the blink/parser side of things first where it will be easy to
> wire in but as best as I can tell we don't really want to wire it into the
> CSP logic.

I think that makes sense for rel=preconnect. However, I think it is
best to have rel=preload prefetching always respect CSP directives and
whatever referrer control mechanisms become standardized. In order for
that to work, the "as" attribute would have to be required, I think.
(FWIW, I had trouble finding a description of the "as" attribute in
the draft spec.)

Cheers,
Brian

[Brian Smith]

Ilya Grigorik <igri...@google.com> wrote:
> Looking at Fetch context > CSP directive mappings [1],
> some types of fetches (e.g. prefetch, subresource) don't have a defined CSP
> directive... I'm guessing for the very same reason since both prefetch and
> subresource can be used to fetch any type of resource?

As I mentioned in my previous message, I think it is worth considering
requiring the "as" attribute to be required for prefetch and
subresource, and that the type used in "as" is matched with the type
of fetch that makes use of the prefetch, so that prefetching works as
well as possible with CSP, referrer control, and maybe other future
mechanisms.

In other words, I believe we should try to make it the case that there
are no "prefetch" or "subresource" fetch contexts, but instead use the
"as" attribute on those links to determine the fetch context.

Cheers,
Brian

[Yoav Weiss]

On Tue, Jan 20, 2015 at 10:37 PM, Brian Smith <br...@briansmith.org> wrote:

In order for that to work, the "as" attribute would have to be required, I think.
(FWIW, I had trouble finding a description of the "as" attribute in
the draft spec.)

`as` is defined as part of the Preload specification. We should probably make that reference more explicit.

[Ilya Grigorik]

On Tue, Jan 20, 2015 at 4:25 AM, Philip Jägenstedt <phi...@opera.com> wrote:

It seems unlikely, but verifying that Firefox/Safari/IE developers
have no serious objections would also be nice.

We've been iterating on the spec on public-web-perf@ where IE/FF/Safari folks are present and there are no objections (that I'm aware of) so far. We also discussed RH at TPAC where feedback was positive from IE+Safari (didn't have anyone from FF in the room).. The outcome of that meeting was guidance to clarify "speculative vs required" semantics, which is why the spec was split into RH [1] and Preload [2]. 

In short, I believe we're in good shape.. and I'll keep pushing to get more feedback from other implementors.

[1] http://w3c.github.io/resource-hints/

[2] http://w3c.github.io/preload/

On Tue, Jan 20, 2015 at 7:42 PM, Brian Smith <br...@briansmith.org> wrote:

Ilya Grigorik <igri...@google.com> wrote:
> Looking at Fetch context > CSP directive mappings [1],
> some types of fetches (e.g. prefetch, subresource) don't have a defined CSP
> directive... I'm guessing for the very same reason since both prefetch and
> subresource can be used to fetch any type of resource?

As I mentioned in my previous message, I think it is worth considering
requiring the "as" attribute to be required for prefetch and
subresource, and that the type used in "as" is matched with the type
of fetch that makes use of the prefetch, so that prefetching works as
well as possible with CSP, referrer control, and maybe other future
mechanisms.

If left unspecified the UA is supposed to assign a "default context", we just haven't defined what that should be: http://w3c.github.io/preload/#fetch-settings

Intuitively, preload is a declarative fetch()... so, "connect-src" as default seems reasonable, since that's what fetch() is subject to [3] -- any objections?

[3] https://fetch.spec.whatwg.org/#concept-request-context

In other words, I believe we should try to make it the case that there
are no "prefetch" or "subresource" fetch contexts, but instead use the
"as" attribute on those links to determine the fetch context.

Yep, that's exactly the intent. We shouldn't need prefetch/subresource contexts at all.

ig

[Philip Jägenstedt]

On Wed, Jan 21, 2015 at 7:06 PM, Ilya Grigorik <igri...@google.com> wrote:
> On Tue, Jan 20, 2015 at 4:25 AM, Philip Jägenstedt <phi...@opera.com>
> wrote:
>>
>> It seems unlikely, but verifying that Firefox/Safari/IE developers
>> have no serious objections would also be nice.
>
>
> We've been iterating on the spec on public-web-perf@ where IE/FF/Safari
> folks are present and there are no objections (that I'm aware of) so far. We
> also discussed RH at TPAC where feedback was positive from IE+Safari (didn't
> have anyone from FF in the room).. The outcome of that meeting was guidance
> to clarify "speculative vs required" semantics, which is why the spec was
> split into RH [1] and Preload [2].
>
> In short, I believe we're in good shape.. and I'll keep pushing to get more
> feedback from other implementors.
>
> [1] http://w3c.github.io/resource-hints/
> [2] http://w3c.github.io/preload/

Thanks Ilya, that sounds good. I took "No public signals" to mean
"haven't asked" but it sounds like other vendors should already be
aware that this is happening.

Philip

[Brian Smith]

Ilya Grigorik <igri...@google.com> wrote:
> On Tue, Jan 20, 2015 at 7:42 PM, Brian Smith <br...@briansmith.org> wrote:
>> As I mentioned in my previous message, I think it is worth considering
>> requiring the "as" attribute to be required for prefetch and
>> subresource, and that the type used in "as" is matched with the type
>> of fetch that makes use of the prefetch, so that prefetching works as
>> well as possible with CSP, referrer control, and maybe other future
>> mechanisms.
>
> If left unspecified the UA is supposed to assign a "default context", we
> just haven't defined what that should be:
> http://w3c.github.io/preload/#fetch-settings
>
> Intuitively, preload is a declarative fetch()... so, "connect-src" as
> default seems reasonable, since that's what fetch() is subject to [3] -- any
> objections?

The fact that preload is declarative, and the fact that a script
cannot observe the response of the declarative preload, are exactly
what make connect-src wrong. connect-src would only be correct if the
preload is for a resource that's going to be fetched with fetch() or
XHR. But, it seems unclear (probably unlikely, IMO) that most preloads
without an "as" are really going to used for fetch() or XHR.

Is it really important to have a default context? If there's no
default context, but instead the UA just logs a warning to the console
saying the prefetch will be ignored due to a missing "as" attribute,
then the developer is likely to notice the message and/or the fact
that the prefetch doesn't happen, and add the (probably) correct "as"
attribute.

I'm a fan of having defaults for making the developer's life easy when
the default is intuitive, but there doesn't seem to be any intuitive
default here. Having the developer explicitly tell us the correct
context is likely going to help us with prioritization and maybe with
applying the correct referrer policy and other security things.
Assuming the wrong context means we'll get those things wrong. So, I
lean towards the behavior I described in the previous paragraph.

Cheers,
Brian

[Brian Smith]

Brian Smith <br...@briansmith.org> wrote:
> Is it really important to have a default context? If there's no
> default context, but instead the UA just logs a warning to the console
> saying the prefetch will be ignored due to a missing "as" attribute,
> then the developer is likely to notice the message and/or the fact
> that the prefetch doesn't happen, and add the (probably) correct "as"
> attribute.

I forgot an important point about this:

Let's say the developer writes:

Content-Security-Policy: default-src 'self' https://cdn.example.com

<link href=//cdn.example.com/10guy.jpg rel=preload>

Then, if the default was connect-src, there would be an error in the
developer console like this:

Refused to load 'https://cdn.example.com/10guy.jpg' because it
violates the following Content Security Policy directive: "default-src
'self'". Note that 'connect-src' was not explicitly set, so
'default-src' is used as a fallback.

I think a lot of developers would react to this message by adding
"connect-src cdn.example.com" to their CSP. But, that is not the best
thing to do. Conversely, if the message was:

Refused to preload 'https://cdn.example.com/10guy.jpg' because there
was no <code>as</code> attribute given.

Then the developer would probably fix the problem by adding the as attribute.

Cheers,
Brian

[Ilya Grigorik]

On Tue, Jan 27, 2015 at 8:13 AM, Brian Smith <br...@briansmith.org> wrote:

Let's say the developer writes:

    Content-Security-Policy: default-src 'self' https://cdn.example.com

    <link href=//cdn.example.com/10guy.jpg rel=preload>

Then, if the default was connect-src, there would be an error in the
developer console like this:

Refused to load 'https://cdn.example.com/10guy.jpg' because it
violates the following Content Security Policy directive: "default-src
'self'". Note that 'connect-src' was not explicitly set, so
'default-src' is used as a fallback.

I think a lot of developers would react to this message by adding
"connect-src cdn.example.com" to their CSP. But, that is not the best
thing to do. Conversely, if the message was:

Refused to preload 'https://cdn.example.com/10guy.jpg' because there
was no <code>as</code> attribute given.

Then the developer would probably fix the problem by adding the as attribute.

Brian, thanks for the great feedback. Given that this thread is focused on rel=preconnect, I've created a GH issue to track the preload discussion @ https://github.com/w3c/preload/issues/2 - let's continue there?

[Yoav Weiss]

Regarding Link header support (which as far as I understand is included in this intent), should it be added behind a flag? (I'm assuming the answer is yes)

Should I send a separate intent if I plan to implement/ship Link header support for existing hints (e.g. dns-prefetch)?