Skip to content
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

Allow preventing the update process to finish #761

Open
mitar opened this issue Oct 17, 2015 · 5 comments
Open

Allow preventing the update process to finish #761

mitar opened this issue Oct 17, 2015 · 5 comments
Milestone

Comments

@mitar
Copy link

mitar commented Oct 17, 2015

To allow service worker to verify if new version of the service worker code can be trusted and deny updating, it would be great that when browser decides to update the service worker, it consults existing service worker code to decide if this should be allowed or not (service worker code can verify then the code, signature, etc.). This allows trust on first use security model which then allows controlled updating of the client side code.

(Of course, for this to really work, there should also be a way to really request that all requests go through the service worker code and never bypass it.)

@mitar
Copy link
Author

mitar commented Oct 17, 2015

Maybe preventDefault could be added to the install event?

@annevk annevk added this to the Version 1 milestone Oct 27, 2015
@jakearchibald jakearchibald modified the milestones: Version 2, Version 1 Oct 27, 2015
@jakearchibald
Copy link
Contributor

If we introduce something like this we need to make sure it can't be used by an evil SW to prevent itself being updated.

@mitar
Copy link
Author

mitar commented Oct 27, 2015

Hm, but that evil SW had to come from the server anyway. So if it is evil, then the server can keep sending the evil one. Or are you wondering for the threat when server is compromised temporarily, an evil SW is sent, and from there on even if the server gets fixed, clients still have an evil version?

I would say this is closer to certificate pinning. So as you could pin the server certificate, you could pin server worker code. In the case of the code, it can also verify (because it is the code) the next version of the code as well.

So yea, the same as saying that certificate pinning could be misused by server being attacked and deployed an evil certificate, and then from then on that certificate would be pinned, even if the server is fixed, I do not think this is really a serious case? But yes, browsers could introduce some flag that client and server SW code is not matching anymore and that SW code prevented it from loading with maybe some message from SW why it did that. And then user can decide what to do. In practice, SW code should not be prevented from loading from the server side if user is not under an attack. So if SW detects an attack and prevents loading this is anyway a good moment to start throwing warnings at the user.

@delapuente
Copy link

Although I don't see a clear use case, we could add this unless the server sent the Service-Worker-Force-Update discussed in #839

@MisterTicot
Copy link

This would be solved by this proposal: #822 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants