New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preload and SRI #127

Open
yutakahirano opened this Issue Aug 16, 2018 · 10 comments

Comments

Projects
None yet
6 participants
@yutakahirano
Copy link
Contributor

yutakahirano commented Aug 16, 2018

We, Chrome, have some difficulty to support script preload with SRI. Here is the story:

  1. ScriptResource translates the received raw bytes into text data, and discards the raw bytes to save memory.
  2. A preloaded resource wants to processing the data before matching with the actual request.
    1. We think this is OK because that is not observable from JS, and we can discard the result when it's rejected by SRI.
  3. As the integrity value is provided by the actual request (<script integrity=...>), the above is not possible - the raw bytes needed to compute the hash are already discarded.

We spent months to solve the issue in our codebase, but we've given it up due to complexity the solution would bring.

I think, instead, we could ask web developers to specify the integrity value at the link element. For example,

<link rel="preload" as="script" href="/script.js">

doesn't match

<script src="/script.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"></script>

while

<link rel="preload" as="script" href="/script.js"
      integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC">

does.

What do you think about this idea?

@yutakahirano

This comment has been minimized.

Copy link
Contributor

yutakahirano commented Aug 16, 2018

@mikewest

This comment has been minimized.

Copy link
Member

mikewest commented Aug 16, 2018

As we discussed earlier in the week, I think it's reasonable to allow developers to specify an integrity attribute for preloaded resources. I don't think that absolves us (Chrome) of fixing our implementation's behavior (and we discussed options!), but it's reasonable advice to give developers in the short term, and should be straightforward to define (as we already define integrity on <link> to support stylesheets.

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Aug 16, 2018

I think it's unfortunate to place extra complexity on users, but understand that codebase complexity may not be trivial as well.

Would it be sufficient to include a preload signal that indicates that SRI would be needed, and what hash function would be used? That way the SRI verification can only be done when the <script> is used, but calculating the hash can be done for the preload.

e.g. would <link rel="preload" as="script" href="/script.js" integrity="sha384"> be sufficient for the engine to know which hash to calculate before dropping the raw bytes?

@yutakahirano

This comment has been minimized.

Copy link
Contributor

yutakahirano commented Aug 16, 2018

@yutakahirano

This comment has been minimized.

Copy link
Contributor

yutakahirano commented Aug 16, 2018

@yoavweiss Yes, that's enough. I will be happy with that option as well.

@kinu

This comment has been minimized.

Copy link

kinu commented Aug 16, 2018

(As we discussed internally) I'm very supportive of this idea, and the alternative suggested by @yoavweiss sounds good to me too, especially if it could make the developers' life easier.

@mikewest

This comment has been minimized.

Copy link
Member

mikewest commented Aug 16, 2018

If we're going to specify an integrity attribute, it seems reasonable to use it (and to discard the preloaded resource if it doesn't match). I'm not sure there's much value in hinting at a hashing function alone.

@yoavweiss

This comment has been minimized.

Copy link
Collaborator

yoavweiss commented Aug 16, 2018

The hint will enable the engine to collect the right hash value of the resource without storing its bytes until it is matched with a script/style.
The reason I want to avoid forcing devs to include the hash itself in the preload link, is to avoid adding it twice, which is clumsy and potentially error-prone.

@igrigorik

This comment has been minimized.

Copy link
Member

igrigorik commented Aug 18, 2018

+1 for supporting integrity enforcement on preload.

Related discussion: w3c/webappsec-subresource-integrity#26

Re, function vs value: are there use cases where value would enable enforcement where it's not possible today? E.g. if I preload a response that's later consumed via fetch(), it would be nice to defer to preload to do the validation, albeit there is the wrinkle here that if validation fails than preload can't simply drop the bytes but would instead need to return a failed response to fetch()?

@yoavweiss I understand your motivation, but I'm also a little hesitant of overloading and special casing "integrity" value here with hashes. If we go down this route, perhaps we should consider a different attribute name?

@toddreifsteck

This comment has been minimized.

Copy link
Member

toddreifsteck commented Oct 25, 2018

Per discussion at TPAC 2018 on 10/25/2018:

  • As a first priority, specify the addition of full integrity to link rel preload
  • As a second priority, it makes sense to add integrity attribute (or a new attribute) that allows the hash type to be specified. This could allow perf optimizations to occur on servers.

@yoavweiss , can you please edit the spec or find an editor to make this update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment