Comment by jimktrains2 | Hacker News Reader

Comment by jimktrains2 | Hacker News Reader

Parent Full thread

> To get your encryption key, they would need to execute code in your browser,

You mean like all the javascript you're sending me?

> To solve this, we're using a relatively new web technology (Service Workers) to install some code which can't be changed without setting off a warning to you. That code then keeps taps on all other code, and checks that it matches the publicly available version on GitHub.

I really think you need to rethink your security here, because this just makes me even more sure that I don't trust you. It's actually a good bit laughable. If an attacker has access to your server, why should I believe that they wouldn't be able to update your github repository? (Why do I know you use different keys, don't put your private key on the server, &c?)

I have to trust you _regardless_ of any of your technology, and that's the problem. If someone has your server, there is very little I won't put past them to also have access too.

In sum, I think you're in for a world of hurt if you expect anyone who actually cares about security to trust you to never, ever make any mistakes.

> Of course, we're only talking about when our server gets hacked. If your computer gets hacked, you have a problem regardless of whether you're using a web app or a native app.

You're obviously just being needlessly argumentative about this. My meaning is obvious because of the context and the situation I described.

> If an attacker has access to your server, why should I believe that they wouldn't be able to update your github repository?

I don't have my GitHub password/keys on the server. Why would I have them there?

> I have to trust you _regardless_ of any of your technology, and that's the problem.

Yes, but it's trust-on-first-use. There's a big difference between

1. Trusting me today when I say that the GitHub keys are not on my server,

2. Trusting me today when I say that I'm not sending your password to the server, and being able to verify that by checking the code on GitHub

and

1. Trusting me every time you open the web app

2. Trusting me and my hosting company that I won't ever get hacked

> I don't have my GitHub password/keys on the server. Why would I have them there?

Because you only need an SSH key to push to github and it's not uncommon for people to leave those laying around (or to forward them with a connection!) on a server.

The better question is not "Why would you have them there?" but "How do I know you don't have them there?"

> Yes, but it's trust-on-first-use. There's a big difference between

You're showing a very fundamental misunderstanding of trust and security. I trust your code every single time I load the application. I don't care what measures you _think_ you've put into place, I will _guarantee_ you they are not fool-proof if you have a compromised system. You're insistance that it is is very disheartening and continues to degrade any trust I would have placed in you.

> 1. Trusting me today when I say that the GitHub keys are not on my server,

No, it's trust that you will never ever ever ever place them on any device you ever own where it is accessible or that said device will never ever ever be hacked.

> 2. Trusting me today when I say that I'm not sending your password to the server, and being able to verify that by checking the code on GitHub

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.

> 1. Trusting me every time you open the web app

I still need to do this.

> 2. Trusting me and my hosting company that I won't ever get hacked

I still need to do this too.

> 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.

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