The other day I was scrolling past a panoramic picture on Facebook. I happened to jostle my phone, and was surprised to find I could look around the picture by tilting my phone.
When the fsck did this become a feature? Why did nothing ask me if I was ok giving Facebook access to my hardware? How do I turn it off? Who thought this was a good idea!?
These same questions apply to Bluetooth. Already, such a terrible standard when it comes to privacy. And now, random websites can grab control of my radios? With JavaScript? Nothing wrong can happen with this, for sure!
FFS. This is like the battery api. Too much time spent on "can we", too little time spent on "should we".
hi. i develop webapps that run in the browser. these apps leverage webrtc, battery api, local/session storage, websocket, webvr/xr, webgl, you name it. all have legitimate purposes, all run in a browser under https and none have ever been used for tracking: one app that uses webrtc does one to many broadcasts, another uses webxr/webgl to display 3d vr experiences, etc. these apps are used by tens of thousands on a daily basis. and they’re nothing fancy. my advice is to not dismiss the advantages of the web just because of a few bad apples.
> my advice is to not dismiss the advantages of the web just because of a few bad apples.
Except protecting against the "few bad apples" is exactly what we're supposed to be doing. Eg you made a point that your use cases are all served over HTTPS - why should we be doing this when it adds complexity, adds bandwidth and breaks many legitimate corporate management tools? The reason we bother with TLS is precisely because of "a few bad apples".
The point of security is to harden against those bad apples rather than ignore they exist just because developers want a shiny new toy to play with.
Which is why the web has the most robust permissions system of any platform, period. Sites that need these features for legitimate purposes can access them, while sites that don't can't.
> Which is why the web has the most robust permissions system of any platform, period.
I fundamentally disagree with that. Yes it has a permissions system but is it really all that robust? Let alone the most robust of any platform? First off you're dependant on the browser implementing that correctly (that's not always the case) and often there are thousand different ways you can still do naughty things even if those permissions are implemented correctly. Then there are the thousands of vulnerabilities built into the very design of the web that developers (of both web and browsers) are constantly having to code around (XSS, et al). And that's without even addressing the current problems we have with data leakage and privacy concerns that we seemingly have little control over at all.
Compare that to networking where you have VLANs, subnets, firewalls and other network ACLs; or Linux servers where you have tools like SELinux. These tools might not be simple to use from the outset but their certainly a great deal more robust than any of the models the web has offered us thus far.
Sorry, I should have qualified that statement a bit more. The web has the most robust permissions system of any _consumer-facing_ platform, period.
Obviously if you're willing to trade convenience for security there are millions of ways you could build a more "robust" system, but it doesn't help to have the most secure system in the world if it's too inconvenient for anyone to bother using it.
With that being said, the web's permissions system _is_ very robust:
> First off you're dependant on the browser implementing that correctly (that's not always the case)
When is it ever not the case? Zero-day vulnerabilities? That's not a very convincing argument; every system has vulnerabilities on occasion.
> often there are thousand different ways you can still do naughty things even if those permissions are implemented correctly
When is that ever not true of a permissions system? The point of permissions is to _limit_ what naughty things an application can do, not eliminate bad behavior entirely.
The web's permissions model was built with the expectation of abuse in mind, which is the reason why it's so robust in the first place.
> Then there are the thousands of vulnerabilities built into the very design of the web that developers (of both web and browsers) are constantly having to code around (XSS, et al).
I don't see what vulnerabilities in third party apps has to do with permissions. XSS can't bypass permission prompts.
> the current problems we have with data leakage and privacy concerns that we seemingly have little control over at all
You actually have a _ton_ of control. Just look at some of the crazy things you can do with extensions like uBlock or Privacy Badger: those extensions can actually reach into the internal workings of a web application and disable tracker code or replace it with noop stubs. No other platform affords that level of control over third party apps.
Yes, this stuff was built out of necessity; the web is a much more hostile environment than most. But _because_ these web platform features were built with that environment in mind, the web's permissions system is the most robust of any _consumer-facing_ platform.
> VLANs, subnets, firewalls and other network ACLs; or Linux servers where you have tools like SELinux
These are not remotely consumer friendly. Again, my apologies for not qualifying my earlier statement.
> Sorry, I should have qualified that statement a bit more. The web has the most robust permissions system of any _consumer-facing_ platform, period.
I don't agree with that elaboration either. eg Zone Alarm offered far more robust permissions for desktop Windows users in the 90s than the web offers now, 20 years later.
Then you have the permissions system on iOS that does all the same things you're boasting browsers do but with the additional feature of telling you about apps that have been granted access to x and been using it frequently (eg if location data is being heavily used) so you get some warnings if a particular app might be abusing the permission you granted it (it's pretty rudimentary compared to the tools techies like us might use but for an average consumer it's far better than expecting them to look at the `networks` tab in Chrome)
> The point of permissions is to _limit_ what naughty things an application can do, not eliminate bad behavior entirely.
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.
> I don't see what vulnerabilities in third party apps has to do with permissions. XSS can't bypass permission prompts.
XSS was just the first example that came into my head about how permissive the web is by default but i think it's a relevant one. Applications should not be able to alter private data or runtime behavior of another running application unless the developers of that other application specifically allows it. This is something OS's have had to harden against and yet it's considered a "feature" of the web. That's definitely not an example of a robust permissions system in my opinion.
> You actually have a _ton_ of control. Just look at some of the crazy things you can do with extensions like uBlock or Privacy Badger: those extensions can actually reach into the internal workings of a web application and disable tracker code or replace it with noop stubs. No other platform affords that level of control over third party apps.
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. And even if you want to argue that is the same thing as browser permissions then it's worth pointing out that having to install additional plugins to block stuff that should be blocked by default is categorically not a robust system. Let alone the fact that these countermeasures aren't 100% effective and are easily circumvented. Again, hardly an example of a robust system (though that's not the fault of the aforementioned tools - they're doing the best job they can under the circumstances).
> [VLANs, subnets, firewalls and other network ACLs] are not remotely consumer friendly. Again, my apologies for not qualifying my earlier statement.
Actually you'd be surprised at just how many consumer friendly networking tools there are. From the management interfaces on home routers to firewalls in desktop solutions like AV suites.
I've been lucky enough to have worked in a great many different niches within IT over the course of my career. From managing a team of desktop support engineers where I've hard to familiarise myself with different solutions available for desktop users, to software development (web development as well as "traditional" software for Windows desktops and Linux/UNIX server daemons), to being part of a security team (I've installed SIEMs and guided businesses through PCI DSS and gambling commision compliance), to server administration (and, more recently, DevOps); and honestly my takeaway from that varied experience is the web is very much like PC security in the early 90s. 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. Thus to get any real security you're forced into running all sorts of (often performance crippling) 3rd party solutions and even those aren't 100% effective. It's definitely not robust - but frankly I'd go further and say it's completely garbage. But that's just my 2c.
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.
(i've had to add this as a separate post because my comment was too long)
> What more would you add? The existing permissions system on the web seems to be very granular to me.
It's disjoined, inconsistent and insecure by default. If it was as robust as you make out then we wouldn't have a need for the cookie consent law nor GDPR (opinions of the EU and those respective laws aside).
I honestly don't think web can have a robust permissions system given its current architecture. I think it would need a ground up redesign - or at the very least it would need to make breaking changes. But one idea I have is where sites have to send metadata down (as part of the headers if like?) with each page stating what permissions that page requires to function. Eg: make outbound JS requests to it's own site, to other sites. To save cookies on it's own domain, or other domains. Which hardware it has access to. Whether it uses local storage. Whether it's allowed to write HTML into it's own page. etc. This will be a bit like the XML file that includes Android APK files and tells the JVM which APIs you are using (but not as shitty). So if the page doesn't declare it needs access to something in the metafile, then it simply doesn't get access to do that. That way users can see what each page is doing just be looking at the requested permissions even before any popup appears requesting access to xyz.
Further to that, you can define in the browser which permissions to allow by default - this is a little like what is available already but more granular (eg the self-modifying page example earlier). You can define those policies as "Never allow", "Request authorisation", or "Allow" and the authorisation with be on a per-domain basis (again, like some browsers already do). The benefit there is you now have all of your Javascript, cookies, etc permissions wrapped up in one centralised ACL and an easy way of seeing what each web page/application wants to do even before a request popup appears on your screen.
Further to that, some interactions (the exploitable ones) will be logged. eg calls from one domain to another. So some of the more experienced users have the ability to scan for suspicious behaviour without having to trawl through thousands of HTTP get / post requests.
I'd also like reminder prompts. eg if a service you allowed to make location requests does it frequently, I'd want a banner across the bottom of the page reminding users that this is happening frequently and that can only be mitigated by "trusting" that service with that API (an additional manual action on top of allowing it initial access to a particular browser feature).
Another cool feature would be if versioning was built into webpages. Each page would be versioned and that version number would stored with a checksum of the page. Thus if the page changes between refreshes, the browser knows and resets all the permissions on that page to the user defaults (ie any previous prompts would then have to be re-prompted again). This would cause issues for content that's dynamically generated on the server side (eg forums, API endpoints, etc) but there could be another couple of permissions there, one where the API declares itself as an API and thus you grant the Javascript permission to call an API; and another where you can define whether to ignore version changes on any particular domain.
In fact if we are doing a ground up redesign, then it would be possible to separate the textual data content from the formatting and application code in ways that HTML currently makes difficult. So you could still version and checksum the code and still have the page rendered at the server side.
It would also be nice to have some definable CPU and memory caps too - since each tab is basically now a virtual machine.
This is all pie-in-the-sky stuff and probably really badly explained too (it's late and I've never been great at explaining things at the best of times anyway). Plus a lot of it is stuff I've just thought of now as examples to your question. So I'm sure you'd find many faults with what I've posted. Thus all I ask is you respect the spirit of what I'm saying rather than taking the points literally as a written gospel I'm suggesting we implement tomorrow. There will be problems implementing that verbatim but my point is to illustrate just how little protection the web offers and how much further we need to go given its current nature is basically just allowing anyone to run any untrusted application on their local machine.
We _don't_ need that law. All it's resulted in is tons of annoying pop-ups all over the web (which I block with an extension). Browsers already have the ability to grant or deny cookie usage per-domain, which is much more user-friendly and effective.
> nor GDPR
No technically-enforceable permissions system in the world will let you control what a company does with data you've already voluntarily given them, so I don't see how better permissions would eliminate the need for GDPR.
> But one idea I have is where sites have to send metadata down (as part of the headers if like?) with each page stating what permissions that page requires to function
Sounds like you're describing [Content Security Policy][1] and [Feature Policy][2]? Obviously those aren't required by default, for backwards-compatibility reasons, but they _do_ exist.
> That way users can see what each page is doing just be looking at the requested permissions even before any popup appears
Can you clarify what you mean by this? Most of the permissions you described are very low-level; not the sort of thing most users would want to concern themselves with (and certainly not for every site they visit).
> Further to that, you can define in the browser which permissions to allow by default - this is a little like what is available already but more granular (eg the self-modifying page example earlier).
Again, most of this seems like the sort of thing users wouldn't want to concern themselves with. What benefit would result from users being able to prevent a page from modifying its own DOM, for example? For permissions that actually impact the user's security or privacy (e.g. Camera, Mic, Clipboard, Cookies, Third-Party Cookies) this already exists. (See chrome://settings/content)
Could you give some more examples of permissions you believe would be valuable to include here? Preferably stuff that has a clear, concrete impact on the user's security or privacy.
> Further to that, some interactions (the exploitable ones) will be logged. eg calls from one domain to another. So some of the more experienced users have the ability to scan for suspicious behaviour without having to trawl through thousands of HTTP get / post requests.
Is this really such a common use case that you think this needs to be built-into the browser rather than handled via an extension or Dev Tools?
I'd also like to point out that in the case of cross-domain calls, a site which wants to hide their behavior could simply proxy calls to third-party sites through their own server.
> I'd also like reminder prompts. eg if a service you allowed to make location requests does it frequently, I'd want a banner across the bottom of the page reminding users that this is happening frequently and that can only be mitigated by "trusting" that service with that API (an additional manual action on top of allowing it initial access to a particular browser feature).
Already exists. Browsers show an icon in the address bar and on the tab when a page is accessing sensitive information like your mic, camera, or location. Mobile browsers display a persistent notification.
> Another cool feature would be if versioning was built into webpages. Each page would be versioned and that version number would stored with a checksum of the page. Thus if the page changes between refreshes, the browser knows and resets all the permissions on that page to the user defaults (ie any previous prompts would then have to be re-prompted again).
So every time a site make some minor update to their code, I'd have to re-authorize all permissions on that site? Seems rather inconvenient to me, and might lead to warning blindness (which would decrease overall security). That said, the upcoming [Web Packaging Standard][3] might do the "versioning" part of this at least.
> It would also be nice to have some definable CPU and memory caps too - since each tab is basically now a virtual machine.
I'm not sure this is something the user really wants to micromanage. If a tab I'm using needs to use 100% of my CPU to do its job, I don't think I'd want it to bother me with a prompt; I'd much rather just see an indicator or something indicating high resource usage so I can intervene if necessary. With the recent rise of JS-based cryptocoin miners; something like this may end up getting implemented in the near future.
> Thus all I ask is you respect the spirit of what I'm saying rather than taking the points literally as a written gospel I'm suggesting we implement tomorrow. There will be problems implementing that verbatim but my point is to illustrate just how little protection the web offers and how much further we need to go given its current nature is basically just allowing anyone to run any untrusted application on their local machine.
Thanks for the reminder. I've gone back over all my points in this post and tried to re-imagine your suggestions in the most constructive way possible.
Sorry if I still seem skeptical. You have some good ideas, but keep in mind that these problems have already been considered in detail by numerous standards committees and browser vendors, so it's no surprise that a lot of the things you've suggested either already exist, or have good reasons for not existing.
[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP