1381841 - Headspace web app fails to load due to subresource integrity checks

Status: RESOLVED DUPLICATE of bug 1393439

(Core :: DOM: Service Workers, defect, P3)

Description

[Ben Francis [:benfrancis]]

I reported this bug to @Headspace on Twitter and after asking me to clear my cache they suggested I trying using Chrome instead! Trying to figure out whether it's a Firefox bug or something they need to fix on their end.


You'll need to sign up for a (free) account at https://www.headspace.com/ to reproduce this bug because the web app at https://my.headspace.com redirects to https://www.headspace.com if you're not logged in.

STR:
* Sign up for a Headspace account and log in
* Load https://my.headspace.com/

Expected:
* See the web app

Actual:
* Blank white screen
* Errors in the console from Service Workers about subresource integrity
* On subsequent loads, one error in the console saying 'None of the “sha512” hashes in the integrity attribute match the content of the subresource.' and a blank white screen.

This works in Chrome. Fails in Firefox on Android, Mac OS and desktop Linux.

Comment 1

[jacoblowe2.0]

Hey there,

I am one of the web developers at Headspace and was looking into this issue. 

It seems that the initial network fetch seems to look fine. All the sub-resources pass the integrity check and the site works normally. One the second load of the page the sub-resources are fetched from the Service Workers cache and that works fine except that it does not pass the integrity check, which causes the files to stop loading. Right now this is happening on the first file being loaded into the page, but I assume this would be the case for the next file as well. The file being requested it an empty file could this be the issue? 

Looking into what we can do to fix this in the mean time.

- remove integrity checks ( not a huge fan of this )
- remove service worker ( we just implemented them and it would be a shame to kill the caching in them because of this issue ) 
- remove references to that one file in hope its the empty file issue

Thanks and let me know if there is anything I can try or any info y'all need from me to resolve this.

Comment 2

[Ben Francis [:benfrancis]]

Thanks for looking at this jacoblowe2.0!

Adding needinfo on Ben Kelly for Service Workers, please feel free to move this bug to the right component. Also CCing Mike Taylor on web compat.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

I'm on PTO right now, so might be slow to respond.

Note that we do have some differences with chrome around SRI.  For example, we expose FetchEvent.request.integrity, but I don't think chrome has implemented that yet.  They are working on it, though.

Can you make a reduced test case for this?  Does it reproduce if you do a single stylesheet or script served from Cache API in a service worker?

Comment 4

[Andrew Overholt [:overholt]]

needinfo for comment 3 in case you didn't see it :)

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

I tried the steps in comment 0, but could not reproduce.  It looks like maybe the SRI properties were removed?

I'm happy to investigate, but I need a reproduce-able test case.  The smaller the better.  Thanks!

Comment 6

[Ben Kelly [:bkelly, not reviewing]]

Note, I made a quick test here:

https://sri-cache.glitch.me/

This registers a service worker that stores the jquery-2.2.1.min.js file in Cache API and serves it from the fetch event.  The index.html verifies the integrity of the script.

I don't see any errors when the SW provides the script from Cache API.

Is it possible your index.html got out of sync with the resources in your Cache storage?

Comment 7

[Andrew Overholt [:overholt]]

Is this still broken for you, Ben?

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

This is probably only addressed in FF57.  That is where bug 1393439 landed.

Comment 9

[Ben Francis [:benfrancis]]

I can confirm that this appears to be working now in Nightly (58.0a1), thanks!