4 ms·

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

by q-base 9y ago

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?

jimktrains2 9y ago
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 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.
- twiss 9y ago
  > 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 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_API 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-Apps-using-Service-Worker http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap... for a description of my proposed solution.
  - jimktrains2 9y ago
    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.

by q-base 9y ago

jimktrains2 9y ago

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

twiss 9y ago
> 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 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_API 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-Apps-using-Service-Worker http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap... for a description of my proposed solution.
- jimktrains2 9y ago
  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.