4 ms·

When it leaves our server, the data is encrypted and not readable. To get your encryption key, they would need to execute code in your browser, and we describe

by twiss 9y ago

When it leaves our server, the data is encrypted and not readable. To get your encryption key, they would need to execute code in your browser, and we describe how we protect against that at https://www.airbornos.com/docs/security https://www.airbornos.com/docs/security. 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.

jimktrains2 9y ago
> 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.
- twiss 9y ago
  > 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
  - jimktrains2 9y ago
    > 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.
    - twiss 9y ago
      > 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.
      - jimktrains2 9y ago

by twiss 9y ago

jimktrains2 9y ago

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

twiss 9y ago
> 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
- jimktrains2 9y ago
  > 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.
  - twiss 9y ago
    > 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.
    - jimktrains2 9y ago