4 ms·
> Good. That's the direction the mobile world has already been going for a decade now. I genuinely don't understand this argument at all -- either you understa
by danShumway 7y ago
> Good. That's the direction the mobile world has already been going for a decade now.
I genuinely don't understand this argument at all -- either you understand something about native platforms that I don't, or you're working under the assumption that all of your native apps:
a) aren't already vacuuming your data at the same rate as web apps.
b) wouldn't get considerably worse if they replaced the web ecosystem.
On the first point, native sandboxing is almost universally terrible. There's some promising stuff happening (notably with MacOS and with Flatpak/Wayland) but it's all just playing catch-up to where the web was years ago.
Pick just about any company that maintains both a website and a native version of the same app -- almost universally, the web version is safer to use. Nobody should be installing Facebook, Twitter, or Reddit on their phone. In fact, I would say the single best piece of advice I can give to anyone to improve their privacy/security on their phone is to stop installing things.
On the desktop, the situation is better, mainly because the desktop is very slowly turning into a niche platform and the web is a much more attractive place to put skuzzy, privacy-violating software. But this is a bit like the old argument that MacOS was more secure than Windows because no one was targeting Mac with viruses at the time. Get rid of the web and all of those skuzzy developers you hate aren't going to go away, they're just going to start making native apps. Where, again, the current sandboxing for most users and OSes is completely inadequate.
If your security model on the desktop is, "I'll only run code I trust", you can already do that on the web today. You can already turn off Javascript. And if you don't feel like the modern web-app ecosystem accommodates that decision, then what makes you think a theoretical, purely native world would accommodate you running a small, tight system that only includes code you trust? I can run a beautiful, tight Linux system because I don't have to install much software on it.
The unfortunate, horrible problem, is that running code we don't trust is gonna be necessary, no matter what world we move to. Sandboxing and permission systems are something we are going to have to figure out. Web or not, there is never going to be a world where you'll be able to trust all of the code you run on your computer. And currently, despite the many problems that browsers have, they're still still the best consumer-accessible solution for sandboxing code.
Of course integration and app performance suffers on the web. But frankly, neither of those are more important than sandboxing.
- yellowapple 7y ago> There's some promising stuff happening (notably with MacOS and with Flatpak/Wayland) but it's all just playing catch-up to where the web was years ago. And in the proposed 10 years being discussed here, there's no reason to believe locally-installed applications won't have exceeded browser sandboxing capabilities, let alone caught up. Meanwhile, the web sandbox is actively deteriorating specifically because frontend developers want to do the things locally-installed applications can do. > Nobody should be installing Facebook, Twitter, or Reddit on their phone. Not at the current state of native app deployment, no, but that's improving rapidly and substantially, especially in the mobile space. Also: the vast majority of users are doing that anyway, so it's worth investing the time and energy into being able to sandbox apps without needing an entire HTML + CSS + JS engine/stack to do it (and indeed, both Google and Apple have made significant strides on that front in the last 10 years, though there's certainly still room for improvement). > The unfortunate, horrible problem, is that running code we don't trust is gonna be necessary, no matter what world we move to. Yes, but at least with a locally-installed app, I'm explicitly opting into that app existing and running on my device. This on its own will at least somewhat cut down on the amount of untrustworthy code running on my system. Yes, I can do the same thing for a website's JS code (and indeed do so), but it's asinine that I need Javascript enabled to read a blog post or post to social media or do the myriad number of other things that are theoretically and practically possible with server-side processing exclusively. > Of course integration and app performance suffers on the web. But frankly, neither of those are more important than sandboxing. No, but sandboxing - again - is a problem that can (and almost certainly will) be solved within the next decade, at which point integration and performance benefits will make local app installation even more attractive than it already is.
- laughinghan 7y ago> there's no reason to believe locally-installed applications won't have exceeded browser sandboxing capabilities What? Sure there is! 1. The reason to believe native apps' sandboxing won't exceed the browser is that any sandboxing that works on native apps would also work on the browser app itself. 2. There's also 2 reasons to believe native apps' sandboxing may always be inferior to the browser: (a) The Web has wider reach, and people are already more confident/careless visiting strange websites than downloading and running strange apps, so exploits targeting the Web are more valuable and therefore more resources are spent battle-testing it. (b) Native apps currently have deeper access to the device which makes it easier for them to do bad things, and (similar to reason 1) will never have less access to the device than the browser app which is also an app. (I'm aware there's arguably a slight exception here about Mobile Safari and W^X, but I don't think that disproves the overarching reasoning.)