4 ms·

> Web browser is a sandbox by default. So I take this is a security concern. How do you feel about the fact that when you open a webapp in your browser, you re

by palata 7mo ago

> Web browser is a sandbox by default. So I take this is a security concern. How do you feel about the fact that when you open a webapp in your browser, you re-download that app code every time? That the server can send you a backdoor every single time, made just for you, and nobody else will ever know? And that you can't check the "hash" of the webapp, like you can with an app? On the other hand, an app is sandboxed, too (on mobile OSes like Android and iOS). When you download it, you can check a hash that you can (if you want to) compare with a friend to see if they got the same app. With an app, there is intermediary (the "app store") that would need to collude with the developers to send a backdoor just for you, and even then you would still have the app binary as proof. That's always a question I have with "secure" web services: if you use ProtonMail, you trust that Proton doesn't send you a web page that leaks your key. But if you trust Proton for that, what's the point of the end-to-end encryption? When you use the Signal app, the whole idea is that you don't have to trust Signal for the end-to-end encryption, at all.

leptons 7mo ago
>That the server can send you a backdoor every single time, made just for you, and nobody else will ever know? There is no "backdoor" when the browser is sandboxed. "backdoor" is a specific thing, I think you need to read up on it before you keep using it incorrectly: https://en.wikipedia.org/wiki/Backdoor_(computing) https://en.wikipedia.org/wiki/Backdoor_(computing) >On the other hand, an app is sandboxed, too (on mobile OSes like Android and iOS). When you download it, you can check a hash that you can (if you want to) compare with a friend to see if they got the same app. That isn't what "sandboxed" means, it has nothing to do with checking hashes. And no, mobile apps are not really sandboxed, they have full access to your mobile device once you install it and give it access - and let's be real, most people are just going to blindly click "allow" for anything the app requests after installing an app. >With an app, there is intermediary (the "app store") that would need to collude with the developers to send a backdoor just for you, and even then you would still have the app binary as proof. You keep referring to "backdoor", and I don't think you really know what that means. >That's always a question I have with "secure" web services: if you use ProtonMail, you trust that Proton doesn't send you a web page that leaks your key. But if you trust Proton for that, what's the point of the end-to-end encryption? When you use the Signal app, the whole idea is that you don't have to trust Signal for the end-to-end encryption, at all. That isn't how any of this works. The main value proposition of Signal is that we do trust its end-to-end encryption. Protonmail sending a "web page" that "leaks your key"? WTF?
- AlBugdy 7mo ago
  It's obvious what GP meant - we can verify that the apps we download are the apps everyone else downloads. We can't do this with Proton where our mail is supposedly end-to-end encrypted. They can easily view our mail if they can send us a different code when we load their site. > That isn't what "sandboxed" means, it has nothing to do with checking hashes. And no, mobile apps are not really sandboxed Apps ARE somewhat sandboxes and GP didn't mean than sandboxing == checking hashes. It was 2 sentences appearing one after the other.
  - asadotzler 7mo ago
    You cannot. An app can update just like a browser tab. In fact, a very many apps are just frickin' webviews.
    - palata 7mo ago
      Well, you can verify that the code that you downloaded is the same that everyone else downloaded. Even if it contains webviews. Now if it contains webviews, it brings the security issue of... the webapps, of course. Personally, I want an open source app. You can audit an open source app and even compile it yourself. You can't really do that with a website. And I don't mean just mobile apps, that applies to desktop apps, too. I wouldn't run a web-based terminal, for instance (do people actually do that?).
      - leptons 7mo ago
        >Well, you can verify that the code that you downloaded is the same that everyone else downloaded. Even if it contains webviews. Not impossible to do with websites, if the need to do it was there. It would take about 15 minutes to create a browser extension that could make a hash of all the files loaded, to compare with other users with the extension installed - but honestly that's just not needed because if you're connecting via HTTPS, then you're getting the files that are intended to be served, presumably not malicious if you trust the source. And if you don't trust the source, then why are you loading it to begin with?? >Now if it contains webviews, it brings the security issue of... the webapps, of course. Web applications are sandboxed in the web browser. Very little issue with that, outside of browser bugs/exploits, but bugs and exploits are found in every system ever. >I wouldn't run a web-based terminal, for instance (do people actually do that?). AWS has a web-based terminal for EC2 instances. It's not a problem, a lot of people use it.
zadikian 7mo ago
Apps can download code too, and often do
- palata 7mo ago
  Well the idea is that the client should be open source, and audited. If you run a proprietary app, you have to blindly trust it (just like if you access a webapp). In terms of security, the best is an open source app, IMO.
  - Zak 7mo ago
    Open source helps, but if you didn't build it yourself, you'll need to trust whoever did. F-Droid reproducible builds help in that you only need to trust either F-Droid or the developer, not both. The browser tends to be safer because it has a stronger sandbox than native apps on a mobile OS. It's meant to be able to run potentially malicious code with a very limited blast radius.
    - zadikian 7mo ago
      Also even obfuscated JS code is easier to understand than machine code, if you're trying to tell what some non-open-source thing is doing
    - palata 7mo ago
      > Open source helps, but if you didn't build it yourself, you'll need to trust whoever did. You need to audit the code. If you are not capable of doing that, you need to trust someone to do it.
    - deleted 7mo ago
      [deleted]
AlBugdy 7mo ago
> And that you can't check the "hash" of the webapp, like you can with an app? Can someone reading this make an addon for this?
- palata 7mo ago
  Meta and Cloudflare did something like that for WhatsApp Web, there is a nice blog post about it here: https://blog.cloudflare.com/key-transparency/ https://blog.cloudflare.com/key-transparency/ Now it only ensures that Cloudflare doesn't tamper with the WhatsApp Web code they serve, you still have to trust Meta. I feel like reaching the same level as "checking the hash for the app" would be very hard in practice. I.e. the web is not built around doing that. Your extension would have to scan all the files you download when you reach a page, somehow make a hash of it, somehow compare it to... something, but then make the difference between "tampered with" and "just a normal update". Also you just can't "download the sources, audit them and compile them yourself" with a webapp. If you do that, it's just "an app built with web tech", like Electron, I guess?
tennysont 7mo ago
I think the question is: where should the information barrier exist? A web browser puts a barrier between your OS and the company, while an app (potentially) puts a barrier between the client and the server. For security minded and source-available apps like Signal, the latter is the right choice. For low trust companies with no expectation of app/server separation, the former seems right.
- palata 7mo ago
  One thing is that on mobile OSes (iOS and Android), the apps are sandboxed. It is wrong to say that they are not, I don't know what people believe. Programs are typically not sandboxed on desktop OSes (though they can be, but the user has to do something about it), but on mobile they most definitely are. That's part of the reason why the security models of iOS and Android are better than desktop OSes. Just like you don't have to give access to your filesystem to a webapp (but you can), you don't have to give this access to an app. The reason to like webapps better than mobile apps is, IMO, not security (again, IMO it's worse in terms of security). The reason could be that they want to rely on an open source tech stack (which iOS does not provide, but Android does!). But really my feeling is that it's often either uninformed or political (i.e. it feels like a strong statement against Google to refuse Android apps?). Which again is weird to me because Google controls the browsers development (via Chromium) just as much as they control the Android core (AOSP). People who are happy with chromium should be happy with GrapheneOS, I would say.

by palata 7mo ago

leptons 7mo ago

>That the server can send you a backdoor every single time, made just for you, and nobody else will ever know? There is no "backdoor" when the browser is sandboxed. "backdoor" is a specific thing, I think you need to read up on it before you keep using it incorrectly: https://en.wikipedia.org/wiki/Backdoor_(computing) https://en.wikipedia.org/wiki/Backdoor_(computing) >On the other hand, an app is sandboxed, too (on mobile OSes like Android and iOS). When you download it, you can check a hash that you can (if you want to) compare with a friend to see if they got the same app. That isn't what "sandboxed" means, it has nothing to do with checking hashes. And no, mobile apps are not really sandboxed, they have full access to your mobile device once you install it and give it access - and let's be real, most people are just going to blindly click "allow" for anything the app requests after installing an app. >With an app, there is intermediary (the "app store") that would need to collude with the developers to send a backdoor just for you, and even then you would still have the app binary as proof. You keep referring to "backdoor", and I don't think you really know what that means. >That's always a question I have with "secure" web services: if you use ProtonMail, you trust that Proton doesn't send you a web page that leaks your key. But if you trust Proton for that, what's the point of the end-to-end encryption? When you use the Signal app, the whole idea is that you don't have to trust Signal for the end-to-end encryption, at all. That isn't how any of this works. The main value proposition of Signal is that we do trust its end-to-end encryption. Protonmail sending a "web page" that "leaks your key"? WTF?

AlBugdy 7mo ago
It's obvious what GP meant - we can verify that the apps we download are the apps everyone else downloads. We can't do this with Proton where our mail is supposedly end-to-end encrypted. They can easily view our mail if they can send us a different code when we load their site. > That isn't what "sandboxed" means, it has nothing to do with checking hashes. And no, mobile apps are not really sandboxed Apps ARE somewhat sandboxes and GP didn't mean than sandboxing == checking hashes. It was 2 sentences appearing one after the other.
- asadotzler 7mo ago
  You cannot. An app can update just like a browser tab. In fact, a very many apps are just frickin' webviews.
  - palata 7mo ago
    Well, you can verify that the code that you downloaded is the same that everyone else downloaded. Even if it contains webviews. Now if it contains webviews, it brings the security issue of... the webapps, of course. Personally, I want an open source app. You can audit an open source app and even compile it yourself. You can't really do that with a website. And I don't mean just mobile apps, that applies to desktop apps, too. I wouldn't run a web-based terminal, for instance (do people actually do that?).
    - leptons 7mo ago
      >Well, you can verify that the code that you downloaded is the same that everyone else downloaded. Even if it contains webviews. Not impossible to do with websites, if the need to do it was there. It would take about 15 minutes to create a browser extension that could make a hash of all the files loaded, to compare with other users with the extension installed - but honestly that's just not needed because if you're connecting via HTTPS, then you're getting the files that are intended to be served, presumably not malicious if you trust the source. And if you don't trust the source, then why are you loading it to begin with?? >Now if it contains webviews, it brings the security issue of... the webapps, of course. Web applications are sandboxed in the web browser. Very little issue with that, outside of browser bugs/exploits, but bugs and exploits are found in every system ever. >I wouldn't run a web-based terminal, for instance (do people actually do that?). AWS has a web-based terminal for EC2 instances. It's not a problem, a lot of people use it.

zadikian 7mo ago

Apps can download code too, and often do

palata 7mo ago
Well the idea is that the client should be open source, and audited. If you run a proprietary app, you have to blindly trust it (just like if you access a webapp). In terms of security, the best is an open source app, IMO.
- Zak 7mo ago
  Open source helps, but if you didn't build it yourself, you'll need to trust whoever did. F-Droid reproducible builds help in that you only need to trust either F-Droid or the developer, not both. The browser tends to be safer because it has a stronger sandbox than native apps on a mobile OS. It's meant to be able to run potentially malicious code with a very limited blast radius.
  - zadikian 7mo ago
    Also even obfuscated JS code is easier to understand than machine code, if you're trying to tell what some non-open-source thing is doing
  - palata 7mo ago
    > Open source helps, but if you didn't build it yourself, you'll need to trust whoever did. You need to audit the code. If you are not capable of doing that, you need to trust someone to do it.
  - deleted 7mo ago
    [deleted]

AlBugdy 7mo ago

> And that you can't check the "hash" of the webapp, like you can with an app? Can someone reading this make an addon for this?

palata 7mo ago
Meta and Cloudflare did something like that for WhatsApp Web, there is a nice blog post about it here: https://blog.cloudflare.com/key-transparency/ https://blog.cloudflare.com/key-transparency/ Now it only ensures that Cloudflare doesn't tamper with the WhatsApp Web code they serve, you still have to trust Meta. I feel like reaching the same level as "checking the hash for the app" would be very hard in practice. I.e. the web is not built around doing that. Your extension would have to scan all the files you download when you reach a page, somehow make a hash of it, somehow compare it to... something, but then make the difference between "tampered with" and "just a normal update". Also you just can't "download the sources, audit them and compile them yourself" with a webapp. If you do that, it's just "an app built with web tech", like Electron, I guess?

tennysont 7mo ago

I think the question is: where should the information barrier exist? A web browser puts a barrier between your OS and the company, while an app (potentially) puts a barrier between the client and the server. For security minded and source-available apps like Signal, the latter is the right choice. For low trust companies with no expectation of app/server separation, the former seems right.

palata 7mo ago
One thing is that on mobile OSes (iOS and Android), the apps are sandboxed. It is wrong to say that they are not, I don't know what people believe. Programs are typically not sandboxed on desktop OSes (though they can be, but the user has to do something about it), but on mobile they most definitely are. That's part of the reason why the security models of iOS and Android are better than desktop OSes. Just like you don't have to give access to your filesystem to a webapp (but you can), you don't have to give this access to an app. The reason to like webapps better than mobile apps is, IMO, not security (again, IMO it's worse in terms of security). The reason could be that they want to rely on an open source tech stack (which iOS does not provide, but Android does!). But really my feeling is that it's often either uninformed or political (i.e. it feels like a strong statement against Google to refuse Android apps?). Which again is weird to me because Google controls the browsers development (via Chromium) just as much as they control the Android core (AOSP). People who are happy with chromium should be happy with GrapheneOS, I would say.