Don't update Service Worker after loading in iframe with X-Frame-Options: deny
Reported by
d.huig...@gmail.com,
Oct 10 2017
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/61.0.3163.100 Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. Open https://sw-cache-test-2.glitch.me/. This server registers and responds with a new (slightly different) Service Worker every time you request one. (Mostly ignore the SUCCESS/FAIL in the body, it's not related to this bug report.) 2. Open https://iframe-sw-update-test.glitch.me/ in a second new window. This requests the first URL in an iframe. The first URL responds with X-Frame-Options: deny, so it doesn't load. 3. Observe in the console of the second window that there are no console.log()s from the Service Worker, even though it logs on fetch, updatefound, etc. (That is also a bug, but not the subject of this bug report. When I tried it with two servers on localhost:8000 and localhost:8888, the logs showed up.) 4. Observe in the console of the first window that the updatefound event fired, the new Service Worker ran, etc. You can make this clearer by refreshing the second window and watching the first one. What is the expected behavior? It would be nice if there was a way to prevent a different-origin website from updating the Service Worker on my web app. I'm using Service Workers to improve the security of my web app by checking all code against a public log [1]. However, to make that secure, the Service Worker file also needs to be checked when it updates, to warn the user if it doesn't match. Since the page isn't actually loaded (because of X-Frame-Options: deny), there is no page to receive an updatefound event. In Firefox, the Service Worker isn't updated in this case most of the time -- but occasionally, it is. There seems to be some kind of race condition. [1]: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Apps-using-Service-Worker What went wrong? Any website can update the Service Worker of a third party website by including it in an iframe. Furthermore, there's no way to warn the user if the new Service Worker doesn't match the public log, since the iframed page had X-Frame-Options: deny (and even if it didn't, the frame could be hidden, etc.) Did this work before? No Does this work in other browsers? N/A Chrome version: 61.0.3163.100 Channel: stable OS Version: Flash Version:
,
Oct 16 2017
This seems more like a feature request , hence marking it as untraiged , so that it would get addressed by respective team for further traiging. Please feel free to undo , if this is not the case. Thanks!
,
Oct 16 2017
FWIW I think arguably chrome is more correct here. The spec says to fire the update after a navigation FetchEvent is handled. Even if the resulting page does not load, the update should still be processed. In firefox we probably don't fire the update because we trigger its from the DOMContentLoaded path for navigation updates. We do still, however, trigger our functional event update, though. This only fires if an update has not occurred within a certain time period. (Spec says 24 hours, but we had a bug causing us to use a lower value. Recently fixed.) This is probably why you sometimes see an update in firefox and sometimes not.
,
Oct 16 2017
I filed a bug on the firefox behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=1409007 You should probably file a spec issue if you want this feature: https://github.com/w3c/ServiceWorker/issues
,
Oct 16 2017
> We do still, however, trigger our functional event update, though. This only fires if an update has not occurred within a certain time period. I see. Yeah, the behavior I want is incompatible with the current spec, then. I'll file a spec issue, thanks.
,
Oct 20 2017
(blink-worker triage) Based on c#3-5, I'll close this for now. If the spec is changed, let's reopen this or file a new issue. Thanks.
,
Oct 20 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by ligim...@chromium.org
, Oct 10 2017