4 ms·

Never heard of Zone Alarm before, but from what I've read it sounds like it _only_ controls network access. All other application permissions are left completel

Never heard of Zone Alarm before, but from what I've read it sounds like it _only_ controls network access. All other application permissions are left completely unrestricted; is that correct? I'd hardly call that robust. iOS/Android are much closer, but still don't offer quite the same level of control (you can literally revoke a web app's ability to execute code or play sound; good luck getting that to work on iOS). > My point is the current permissions model of the web doesn't eliminate a whole lot of bad behavior. In fact I'd go further than that and say it's fundamentally useless at eliminating bad behavior. Again, that's true of all permissions systems, by definition. You can't eliminate bad behavior with permissions, you can only limit what that bad behavior can affect. > XSS was just the first example that came into my head about how permissive the web is by default XSS isn't a permission (and certainly not a "feature"), it's a security vulnerability (essentially the web app equivalent of an RCE). Pretty much irrelevant to a discussion of the web's permission model. > That's not a permissions system of the web, that's additional security, usability or privacy tools you have to install to block parts of the web. You're right, that's not part of the web permissions model. I only brought it up because you mentioned "data leakage and privacy concerns that we seemingly have little control over", whereas in reality the web allows much more extensive control over that sort of thing than any other platform. > having to install additional plugins to block stuff that should be blocked by default Ads, persistent storage, and analytics don't need to be blocked by default. Though if you disagree, there are browsers that will do that for you. Worth noting that in native apps this sort of thing is effectively impossible to block. If an iOS app decides to keep track of how you interact with it and send that data to advertisers, there's little you can do to stop it other than to stop using the app. The web gives you other options. > Actually you'd be surprised at just how many consumer friendly networking tools there are. Fair, but I don't think that merely controlling network access externally gives you a sufficient level of control over an application's behavior for that to be considered a "robust permissions system" all on its own. > Sure there are some rudimentary security policies baked into the OS/browser but they're often not granular enough and definitely not far reaching enough. What more would you add? The existing permissions system on the web seems to be very granular to me.

laumars 8y ago
> Never heard of Zone Alarm before, but from what I've read it sounds like it _only_ controls network access. All other application permissions are left completely unrestricted; is that correct? I'd hardly call that robust. The base application is a software firewall. So yes, "only" controls network access but it's a highly robust software firewall with features that extend beyond what your typical host-based firewall would offer (notifications, application aware, etc). There are other products available from Zone Alarm which extend it more into the complete solutions like your typical modern AV suite. However it seems pointless me going into the finer details given you've already dismissed it out of hand before even bothering to find out what it does first. That, to me, just feels like you're now out to win an argument rather than interested in any point someone else has to make. > iOS/Android are much closer, but still don't offer quite the same level of control (you can literally revoke a web app's ability to execute code or play sound; good luck getting that to work on iOS). Once again you're grouping the multiple different permissions models of the web into one entity. I feel that's a really disingenuous position to take given you started the discussion talking about disallowing specific Javascript features as a "robust permissions system" (please note you said "system" - singular). Plus as I said in my former post, if you're going to group them then you're left with a disjoined mess of options cluttered around various tools; which is anything but user friendly and thus not what I would define as "robust". > Again, that's true of all permissions systems, by definition. You can't eliminate bad behavior with permissions, you can only limit what that bad behavior can affect. Yes, but the point I've made several times now is that the permission model of the web allows far more bad behaviour than any other security model I've worked with in the last 20 years. If you honestly can't see this then I question what other systems you've developed against or had to harden. Have you actually even used any other permissions systems or is web your own area of experience? You've yet to example another system that is worse than the one you're claiming king yet I've exmapled plenty which are better. > XSS isn't a permission (and certainly not a "feature"), it's a security vulnerability (essentially the web app equivalent of an RCE). Pretty much irrelevant to a discussion of the web's permission model. At risk of repeating myself: it's only a security vulnerability because the security model of the web allows cross site scripting by default. A robust permissions system would disallow that right from the outset (like how OS's block applications from directly manipulating the memory of other running applications executed by other users - because quite clearly that is ridiculously bad idea to allow). The fact that security vulnerability is even a thing demonstrates how open and insecure the web is by default. And any permissions model with shitty defaults is not one I'd define as "robust". > You're right, that's not part of the web permissions model. I only brought it up because you mentioned "data leakage and privacy concerns that we seemingly have little control over", whereas in reality the web allows much more extensive control over that sort of thing than any other platform. No it doesn't. To block tracking across all of my devices I have to run a custom DNS server with known bad domains pointed to localhost. That bypasses any "web" element entirely (DNS resolution is one of the technologies the web uses, but it predates the web by decades and exists to serve more than just A / AAAA records - so I don't agree that's a web permissions system). And how would bad actors get around that? Just create another domain. Even my most platform agnostic solution is riddled with easy workarounds. It's like how it has become an impossible job to reliably detect new malware threats so instead AVs just add new signatures to their databases as quickly as they can (I know I'm overly simplifying things to make a point - but you seem to think you can reliably control what data gets leaked on the web and quite clearly that's bullshit) > Ads, persistent storage, and analytics don't need to be blocked by default. Though if you disagree, there are browsers that will do that for you. But not reliably (as demonstrated above) > Worth noting that in native apps this sort of thing is effectively impossible to block. If an iOS app decides to keep track of how you interact with it and send that data to advertisers, there's little you can do to stop it other than to stop using the app. The web gives you other options. The web gives you literally zero additional options that the host OS of any given platform - or the wider infrastructure you're connected to - also offers. I have actually done this as a practical exercise - both professionally when I worked in IT security and for fun when I wanted to track what outgoing connections were being made from my home. I've even done this exercise on physical devices like set top boxes (Sky+ box to be precise) and embedded hardware too. The web literally offers you no more options than network engineers and security researchers have had available to them for decades already. > Fair, but I don't think that merely controlling network access externally gives you a sufficient level of control over an application's behavior for that to be considered a "robust permissions system" all on its own. I guess it depends if you're talking about "robust permissions system" in the UNIX sense (ie this tool does one thing and does it well) or if you're specifically thinking about application sandboxing. If the latter than the only truly robust system is air gapping the damn thing. However that quite clearly wouldn't work for the web given it's entire point is being a connected network.

laumars 8y ago

> Never heard of Zone Alarm before, but from what I've read it sounds like it _only_ controls network access. All other application permissions are left completely unrestricted; is that correct? I'd hardly call that robust. The base application is a software firewall. So yes, "only" controls network access but it's a highly robust software firewall with features that extend beyond what your typical host-based firewall would offer (notifications, application aware, etc). There are other products available from Zone Alarm which extend it more into the complete solutions like your typical modern AV suite. However it seems pointless me going into the finer details given you've already dismissed it out of hand before even bothering to find out what it does first. That, to me, just feels like you're now out to win an argument rather than interested in any point someone else has to make. > iOS/Android are much closer, but still don't offer quite the same level of control (you can literally revoke a web app's ability to execute code or play sound; good luck getting that to work on iOS). Once again you're grouping the multiple different permissions models of the web into one entity. I feel that's a really disingenuous position to take given you started the discussion talking about disallowing specific Javascript features as a "robust permissions system" (please note you said "system" - singular). Plus as I said in my former post, if you're going to group them then you're left with a disjoined mess of options cluttered around various tools; which is anything but user friendly and thus not what I would define as "robust". > Again, that's true of all permissions systems, by definition. You can't eliminate bad behavior with permissions, you can only limit what that bad behavior can affect. Yes, but the point I've made several times now is that the permission model of the web allows far more bad behaviour than any other security model I've worked with in the last 20 years. If you honestly can't see this then I question what other systems you've developed against or had to harden. Have you actually even used any other permissions systems or is web your own area of experience? You've yet to example another system that is worse than the one you're claiming king yet I've exmapled plenty which are better. > XSS isn't a permission (and certainly not a "feature"), it's a security vulnerability (essentially the web app equivalent of an RCE). Pretty much irrelevant to a discussion of the web's permission model. At risk of repeating myself: it's only a security vulnerability because the security model of the web allows cross site scripting by default. A robust permissions system would disallow that right from the outset (like how OS's block applications from directly manipulating the memory of other running applications executed by other users - because quite clearly that is ridiculously bad idea to allow). The fact that security vulnerability is even a thing demonstrates how open and insecure the web is by default. And any permissions model with shitty defaults is not one I'd define as "robust". > You're right, that's not part of the web permissions model. I only brought it up because you mentioned "data leakage and privacy concerns that we seemingly have little control over", whereas in reality the web allows much more extensive control over that sort of thing than any other platform. No it doesn't. To block tracking across all of my devices I have to run a custom DNS server with known bad domains pointed to localhost. That bypasses any "web" element entirely (DNS resolution is one of the technologies the web uses, but it predates the web by decades and exists to serve more than just A / AAAA records - so I don't agree that's a web permissions system). And how would bad actors get around that? Just create another domain. Even my most platform agnostic solution is riddled with easy workarounds. It's like how it has become an impossible job to reliably detect new malware threats so instead AVs just add new signatures to their databases as quickly as they can (I know I'm overly simplifying things to make a point - but you seem to think you can reliably control what data gets leaked on the web and quite clearly that's bullshit) > Ads, persistent storage, and analytics don't need to be blocked by default. Though if you disagree, there are browsers that will do that for you. But not reliably (as demonstrated above) > Worth noting that in native apps this sort of thing is effectively impossible to block. If an iOS app decides to keep track of how you interact with it and send that data to advertisers, there's little you can do to stop it other than to stop using the app. The web gives you other options. The web gives you literally zero additional options that the host OS of any given platform - or the wider infrastructure you're connected to - also offers. I have actually done this as a practical exercise - both professionally when I worked in IT security and for fun when I wanted to track what outgoing connections were being made from my home. I've even done this exercise on physical devices like set top boxes (Sky+ box to be precise) and embedded hardware too. The web literally offers you no more options than network engineers and security researchers have had available to them for decades already. > Fair, but I don't think that merely controlling network access externally gives you a sufficient level of control over an application's behavior for that to be considered a "robust permissions system" all on its own. I guess it depends if you're talking about "robust permissions system" in the UNIX sense (ie this tool does one thing and does it well) or if you're specifically thinking about application sandboxing. If the latter than the only truly robust system is air gapping the damn thing. However that quite clearly wouldn't work for the web given it's entire point is being a connected network.