Hacker News new | ask | show | jobs
by f- 3077 days ago
(I'm the author of the book.)

Some things have changed for the better. For example, there's been a push to harmonize the behavior of some of the core parsers and APIs. Say, we now have less variability in how HTML is handled across different browsers.

On the flip side, there are also several new APIs and JS features that have some scary security implications. Service Workers come to mind.

The near-complete demise of Java and Flash are the two other major changes since 2011.

Either way, the book should still give you a very robust understanding of the fundamentals (and a mental framework to evaluate the dangers of some of the new stuff).
1 comments
twiss 3077 days ago
Service Workers can be used to increase security as well, though. You can use it to intercept and check requests and responses against any criteria you like. You can reimplement (variations on) CSP or SRI in them [1], or implement signed web apps [2]. There are probably other possibilities.

[1]: https://frederik-braun.com/sw-sri-challenge.html

[2]: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap...

link
jimktrains2 3077 days ago
Last time I discussed this with someone, it appeared impossible for the service worker to handle the update to itself, and as such the service worker itself was not signed. I feel like this defeats the entire idea.
link
twiss 3077 days ago
There is a way to verify the new SW file when it updates and warn the user (but not prevent the update), but for now it's quite hacky.

- There's an "updatefound" event with which you can listen for updates to the Service Worker

- You can request the new SW file from browser cache with: fetch('/serviceworker.js', {cache: 'only-if-cached', credentials: 'same-origin', mode: 'same-origin'})

You would hope that that's all you need (just register for updatefound in the SW file, and when it updates, check the new one, if verifying fails, warn the user). Unfortunately, the new SW can kill the old SW with skipWaiting(). I opened a bug to try and fix that [1].

In the meantime, you could instead listen for the updatefound event in the web application. However, the example fetch() above would go through the new SW, which is no good, but...

- You can bypass the SW from the web app, but only by basically relying on a bug in the spec: if you send a request from an <iframe srcdoc="..."> (or data/object url) it doesn't go through the SW. That will probably be fixed, but a less hacky mechanism will probably replace it [2].

There are some other remaining issues (some of which are discussed in [1]), but given the above the probability of detection of a malicious Service Worker is very high.

[1]: https://github.com/w3c/ServiceWorker/issues/1208

[2]: https://github.com/w3c/ServiceWorker/issues/1026

link