Hacker News Reader

Comment by twiss | Hacker News Reader

> And when this changes? Must I audit the code every single time I load the code? Because yes, I need to do that to ensure you havn't changed anything.

No. The whole point of what I've done and made is to make sure you don't have to do this. The Service Worker checks all code that is coming from the server. If you've opened Airborn OS before on a computer, and don't see a notification saying that Airborn OS has been updated, it is guaranteed that it's still the same code. If it did change, you get a notification with a nice link to GitHub, where you can inspect the commits since last time. That code is guaranteed to be identical to the new code that you will be running if you refresh Airborn OS.

View on HN

I'm glad you think that. I still don't trust you, nor do I trust that you will never be breached in such a way that a malicious update will be pushed. Everything you're saying still depends on me trusting you.

What if this is my first time loading? How do I know you're not serving up new files that don't contain checks to be visitors?

Moreover, are you insinuating that you will never update any code and that expect that pop up saying you've updated the code to never appear? Do you expect people to check commits multiple times a week or a day?

So, ok, let's assume you're 100% trustworthy and a malicious actor changes the code and I get an error. Am I now forever unable to access my documents? How can I be sure that the code I'm running is really the code on GitHub after a breach? How does the code prevent changes to the initial code loaded on a request? Which could in theory manipulate the Dom before the service worker could attempt to verify the page, if I'm understanding you correctly.

But again, this all assumes that your 100% trustworthy, and you're not. You're just some person asking me to believe you'll never ever make a mistake or be coerced into a malicious action.

Also I haven't seen a mention of the aes mode you're using. Your security pages is laughably shirt given that it's literally your main selling point.

> What if this is my first time loading?

Like I said, it's trust-on-first-use. This is no different from installing a desktop app.

> How do I know you're not serving up new files that don't contain checks to be visitors?

The Service Worker is installed on your own computer, and is still there the next time you open the web app.

> How does the code prevent changes to the initial code loaded on a request? Which could in theory manipulate the Dom before the service worker could attempt to verify the page, if I'm understanding you correctly.

https://developer.mozilla.org/docs/Web/API/Service_Worker_AP...

You're assuming the old version of the service worker will be there and running. That isn't a good assumption. It will normally be there, but it doesn't have to be. There will always be circumstances where I'm downloading it for the first time, even in the same browser and computer.

Also, step 7 on https://w3c.github.io/ServiceWorker/#update-algorithm says that updating the service worker bypasses the service worker. How do you then validate that new service workers haven't been meddled with?

That's blocked on https://github.com/w3c/ServiceWorker/issues/1208. However, there's also an alternative option to make updating the Service Worker unnecessary, by making a "stub" Service Worker which downloads, validates and executes the rest of the SW code. Then, whenever the "stub" Service Worker updates, it's likely a breach and we can warn the user accordingly.

Code you can't update is normally an expensive liability in the case that it's not perfect. Also, then the stub service worker is subject to the same problem it's attempting to solve.

I'm still left in a situation where I need to trust you don't mess up.

You even say it yourself:

> (Of course, we can't prevent the update, but we can at least try to convince the user to close the web app before it steals their private keys.)

At that point, the game is up.

I have nothing to do with this product, and although you appear a little negative towards the OP, it still seems as though you have quite a lot of knowledge in this area. So you peaked my interest. What what you do to avoid the scenarios you highlight?

Everytime you load a webapp, you are trusting the server. Everytime.

In this case, the author is trying to take steps to make changes more visible, but at the same time they're making their own changes cause alerts as well. However, if the product stops serving such countermeasures for new users at some point, or plays a long con over say a year of really tiny, innocent changes that eventually break the system to check downloaded files, then we're no better than any other web app out there.

So unless you're inspecting and verifying the code you actually download yourself, even with these countermeasures, you're no better than any other webapp with the need to trust the code you download _every_ time.

Now, you're always trusting a lot of things like your hardware, your compiler, your package maintainer's compiler, your package maintainer, &c (http://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html). The difference, however, is that I only need to verify that trust each time I update my code, which I can do when I choose to (baring any incompatible server changes) and after I perform any audit I choose to. (With a web app, there is often no (straighforward) way to audit the code _before_ it's been downloaded and executed.

I know I've been negative about all of this to OP. I'm sure he's done a tremendous amount of work. It just makes me angry when people claim they've solved one of the largest, most important problems in cryptography, when all they did is just ask me to trust them in a different way. It also makes me annoyed that for a security-focused product, there are very few details about architecture and cryptographic choices on the product's security page.

I don't mean to denigrate the work OP has done. I just feel that they're being foolish in their security-related claims.

> With a web app, there is often no (straighforward) way to audit the code _before_ it's been downloaded and executed.

Yes, often, but not in this case. With Service Workers, you can notify the user before the code has been executed, and in most cases prevent or delay the update as well. That's why on https://www.airbornos.com/register, there's a checkbox marked "Notify me before updating Airborn OS." If you check that, Airborn OS will literally ask you whether you want to update.

Obviously, you understand the problem and how web apps usually work, but you still don't seem to understand my proposed solution. I would appreciate it if you attempt to do so before you loudly claim that I am wrong. Please see https://developer.mozilla.org/docs/Web/API/Service_Worker_AP... for a description of Service Workers, and http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap... for a description of my proposed solution.

Service workers don't solve the problem.

First, service workers themselves are updated outside a service worker, so that is code I can't easily intercept before it is executed. (And first page load as always.)

Secondly, I still need to trust you not to make a mistake or not not be malicious over a long period of time making small tweaks that look innocent but over a year cause harm.

Third, users will become fatigued if every update you make causes them to click ok.

Reply on news.ycombinator.com