I mean, that's the web summed up in a single sentence. What started as a way to view text and pictures online is now more complicated than many operating systems. You cram all that stuff into a single binary, give lackluster and ever changing controls to manage all that and call it the future. Never attempt to break down the functionality across several dedicated clients that do only one thing and do it well, that's for losers.
But I somehow disagree with your statement in that it seems to imply that the people designing that garbage are naive or don't really think about the consequences of what they're doing. That might have been true in the early days of the web when nobody knew exactly what it was going to be but it's clearly not the case now.
The folks at Google know exactly what they are doing, making browsers more complicated and easier to interconnect with smartphone is win/win for them. It makes it harder to make a competing browser (anybody attempting to make a new browser these days basically has to fork Chrome or Firefox, and generally they go with the former), you need huge developer resources to maintain and optimize it (look at how hard Firefox is struggling to keep up despite the large number of people working full time on it) and while the big G doesn't control Windows, Mac or Linux they do control Chrome and Android so they have a huge incentive to push everything possible away from desktop OSs and into Chrome. They want Chrome to be the OS.
Google is 90's Microsoft with better PR. Well actually it's worse than that because MS didn't usually have access to my private data while google knows almost everything about their users if they have an Android phone and use gmail.
I don't want Chrome or Firefox or any browser to be the OS, I don't want 99% of the gimmicks that are getting added. I can barely tolerate an OS being the OS given how they are steadily moving to less and less actual control and towards knowing best (Windows updates, iOS turning bluetooth off "until tomorrow" etc etc).
Just in case I'm becoming too old to be relevant, neither do my kids and their friends as far as I can see. if anything they're far more simplistic than me - YT, browsing, and a few chat and social apps. So presumably all this junk is for adtech and tracking, for sites to hassle us on yet another device.
Of my friends who work in tech, none of them seem to much like the monster they helped create any more.
Of course if you use a fancy webmail, Google docks or even something like Facebook it makes sense to have a full blown webapp but I personally seldom use these. But the thing is whether or not you need those feature they still bloat your web browser because you have to have it. How many websites ought to require JS to function properly out there? How many do?
Have you tried browsing the new Reddit interface on a low power smartphone? So much richness that it's barely usable. All that to display a list of titles or text comments. Or how about Discord which manages to lag in my browser despite being effectively a chat application.
Sometimes less is more. We've made it normal for people to use software that by default automatically runs a turing complete programming language for any random website you browse. If we had a tiny little bit of friction for going from website to webapp developpers and managers would think twice before cramming "rich" features and a thousand ad scripts everywhere.
You're right that they're not completely read-only documents but the interactive functionality is limited enough that it doesn't really qualify as an app. You don't need a client-side turing complete language to implement it, just forms. It's more akin to filling some paper form than interacting with Visual Studio if you see what I mean.
Most of the web is still designed around displaying text. Even SPAs that require javascript to display text, for all the faults and valid criticisms that model entails, is still no less of a document in terms of its intended function than a bare HTML page.
This is the statement that I have known for years but never put into words. And it rings terrifyingly true.
When I started using Google services, I knew they were siphoning my data and using it personally and as a group to do machine-learny things. TANSTAAFL. I made that choice voluntarily, knowing they weren't going to be upfront about it.
I also made $8.35/hr at a crummy job when I made that decision. I couldn't afford the services Google offered for free from anywhere else.
These days, I'm working as a competent sysad, making appropriate pay. Now, I can afford for-pay services that can supplant various googly-eyed services. But now, my problem is different: how do I know non-google company doing X that I pay for isn't also making similar deals with advert companies? How do I know my data is private?
Obviously, Google is a SPOF in many ways. I don't like that. But the converse is to pay individual companies for service, and hope they're better than Google with respect to service, privacy, and ethics. But those are awfully nebulous to gauge.
I think this is funny because people also complain that Facebook broke Messenger out into its own app. I realize that "the internet" is not just one person and has varying opinions, but it's a "damned if you do, damned if you don't"
When your audience is captive you don't have to pretend to care anymore.
It also works on your MacBook. [4]
[1] https://w3c.github.io/deviceorientation/
[2] https://caniuse.com/#feat=deviceorientation
[3] https://www.engadget.com/2010/07/06/google-chrome-gets-some-...
[4] https://simpl.info/deviceorientation/
(PS my humble opinion is "yes we should". I like being able to develop a heart rate monitor PWA for my phone, and I don't see what's different from granting some random native app the same access. At least with the web I can read the underlying code.)
It did absolutely nothing on my 2015 MacBook (tried Safari, Chrome and Firefox).
It does work on 2012 MacBook model on Google Chrome. I guess it only works on MacBook models that supported a mechanical disk — I think the sensor exists in the first place to protect spinning rust disks by parking the heads just before impact.
The API is pretty well supported on tablets and phones though, which is where the main use case is.
No, this is usually not how new features are being used in the browser (see geolocation). Websites won't be able to scan your nearby devices without asking for permission, and it's up to the user to accept/decline it.
I'm actually quite excited over having Bluetooth accessible in the browser. That means that we could build P2P applications that works in the browser, that works even when not connected to a wifi and can talk with nearby computers via Bluetooth, something that has not been possible before (FlyWeb was close at achieving something like that as well)
You can ask for devices with a given set of features, and then the browser provides UX to select a device, and then the JS API provides a handle for that device.
The only potential way would be requesting devices with various filters, and seeing which return NotFoundError after a given time (though I don't think scanning for Bluetooth devices takes a deterministic time on any platform?) to determine which filters match something. Though of course you can only request the devices list after user interaction.
No! I've never said that! In fact, no one has ever said "I wish I could use Bluetooth in my browser", except for people who want to collect more data on their users.
This is like an idea from Todd on Bojack Horseman. Again, too much time on "could we", not enough time on "should we".
Bojack clip in question: https://youtu.be/Ct6EuC1W1gE
I literally just wrote above that I do want that. I also don't care about collecting any data. Guess you have to take my word for that. So now you know one person at least :)
I'm not sure where in the world you are, but there are many use cases where meshing clients together is the only way of getting non-restricted network access to each other.
The only reason why I think Bluetooth + Browsers are a powerful combination is the fact that it's so easy for people to get started, compared to how desktop works.
> I've always been on my desktop computer and said ... No! I've never said that!
Great, maybe this is not for you but you should try to consider other peoples point of view as well, that might live on the other side of the planet. Otherwise discussing further becomes rather depressing.
The problem isn't accessibility to JavaScript developers. The problem is a crummy radio protocol. Putting it inside Firefox doesn't solve bad design issues.
While bandwidth for Bluetooth is not great, it'll work for small amount of information exchange and at the very least discovery of other methods for communication like ad-hoc wifi.
I'd be happy to hear about more details why Bluetooth is crummy as well.
If for some reason the OFDM ack isn't gotten, then neither side can understand the timings to actually communicate. So you end up with non-pairing hell. This especially happens between different "specs" of BT.
2. Raises noise floor for whole BT carveout
If they had 2 control channels, and then moved the comms to an agreed upon channel, this would never be an issue. Look at how Simplex ham radio works - do announce on a channel, and move elsewhere when agreed upon. But whatever you do, don't just blanket the whole channel (or all of 2m) for 'reasons'. And heavier bandwidth BT can take over multiple channels. This isn't easy, but nowhere near as difficult/stupid as what it is now.
3. Multiple incompatible BT specs
BT used to be a IEEE spec. Not any more. And there's more than 7 or so major versions. Oh, and many are incompatible with each other. What's that XKCD about "Standards"? :(
4. arcane pairing sequences
Again, pairing is crazy complex. I'll have to post the actual IQ data and show a comparison between FM (88MHz-108MHz), 2m amateur radio (144MHz-148MHz), analog TV, 802.11BGN wifi, and what BT looks like in various states.
To sum it up, "They're doing it wrong".
Fragile OFDM? Any other rock solid narrowband interference mitigation techniques that are not electronically complex?
No dedicated control channel? Remember, BT just like wifi implies operation along non-cooperative 3rd parties.
I would agree.
I was at our hackerspace last night working with a SDR transceiver ADALM-Pluto and tuned in to the 2.4 802.11bgn spectrum. Its a clean swath of radio for comms. Its easy to establish a connection. And the bandwidth graph is cleanly edged.
Then I look at the Bluetooth part of 2.4GHz... Holy crap. Each device frequency hops like a rabid rabbit. And when you look for a device, over the radio it looks like its just dumping beacons everywhere in the hopes that something responds.
Just viewing a device with bt connected, and looking for a device makes it clear that their scheme of BT is -bad-. Its a bad protocol, bad detection strategy, and bad usage of spectrum (yay raise noise floor for everyone).
> I literally just wrote above that I do want that. I also don't care about collecting any data.
I believe you, but frankly, most of the society doesn't want to build mesh apps and (hopefully...) finally started to care about their privacy and data, and that's the point.
But in the end, always good to have choices so the ones that happy with what they have, can always stay that way.
At least this doesn't seem to be a priority feature for Mozilla yet. MDN doesn't even have proper docs for it. So I'm a bit thankful for that, for now.
As for Facebook and the accelerometer, I'm presuming you're on Android, so you can definitely blame Google for that.
Malicious sites can trick you into accepting too:
https://www.reddit.com/r/assholedesign/comments/9p3172/yeah_...
Firefox at least has very slightly more distinct pop-downs than Chrome's.
Not all the sensor APIs have a hard requirement to require permissions; accelerometer data is available at a low sampling frequency in Chrome, which as far as I'm aware avoids any known attacks based on accelerometer data.
What about a keylogger with 50% accuracy?
The accelerometer is limited to (IIRC) 25Hz without a permissions prompt. IIRC, at that sampling interval, you can't even distinguish between a phone being held in a hand and a phone in a pocket, and I know the decision to go with 25Hz was done on the basis of various studies. From memory, some study failed to get numeric PINs from full-screen entry at 60Hz, and a typical on-screen keyboard requires much more granularity than that.
For that though, you had to have an ability to do millisecond precision timestamping. I'm not math PhD, but been told by one that the only avenue to mitigate that was to drive down sampling frequency to single hertz.
Guys who write web standards today don't even try to put some farsight into security implications of countless random apis being introduced to the web standard every year.
Would Chrome unbreak the timing, or if somebody will find a workaround, that technique will become viable again.
It shouldn't be asking, ever. The answer is such a hard no, it makes me wonder why they even tried.
Definitely will be useful in my web browser.
I don't think this is true in this particular case. The user can't just click "accept", they have to explicitly choose a device to connect to.
This person's phone has been tilting less often over the past decade - a trend correlated with, let's say, a more strained gait caused by weight gain. The algorithm markets them more sugary foods, because there's a higher likelihood they're effectively addicted to calories.
This other person is letting their battery run down more often - a trend correlated with undiagnosed depression. The algorithm ratchets up the fear and sadness because it infers these will be more effective motivators to buy products.
The best part is that this will probably all happen invisibly. GDP and human suffering creeping up slowly, with no human at the helm, and the world none the wiser.
I feel that we are frogs in boiling hot water.
[1] https://developers.google.com/web/updates/2016/03/access-usb...
In a wider sense, there are legitimate uses for many of these apis. To me it seems like the option would be that some phones would get these apis patched into the browser by the manufacturers instead, and that would run an even higher risk of security problems than when the browser vendors do it.
If you don't like your browser application having access to certain hardware in your phone, you can just revoke the permission, and it won't have the access (at least on Android, I have no idea how iOS works in this regard).
And it was done by Mozilla people working on FFOS, specifically. They had no intention of exposing it to web content IIRC.
Now, whether this is good or not is left as an exercise to the reader.
It quite an edge case but it’s one of those things that make a web app less than native.
To be precice, by using the device orientation API offered by the browser, Facebook has no access to your hardware any more than it has access to your display hardware by utilizing the DOM API to draw on screen or access to your cellular radio by making a TCP connection.
Whether the browser should require your permission (per site?) to use device orientation API, that's debatable. Anyway, that's up to the browser implementation.
I think anything that involves making new/more input available to remote sites should require opt in. At the very least it should have a toggle to disable it globally.
No major browser vendor (and I mean not a single one) puts users' privacy first. People should treat browsers as the privacy hazard they are.
No. Only the user allows it.
>FFS. This is like the battery api. Too much time spent on "can we", too little time spent on "should we".
The battery API can be tremendously useful on mobile if used effectively. For example, disabling certain animations and high end GPU intensive effects if the battery is less.
So Javascript has always controlled your radios. This is just one more connection.
That is to say, without the analogy, that it's the ad companies who will abuse these, ruining virtually every web site that exists, and jading users against the technology for the few websites who aren't abusing it.
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.
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.
By default, sites shouldn’t have access to anything more than a JavaScript engine and HTML rendering facilities. If they need/want more, they should have to make a case and earn my trust.
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.
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.
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.
> 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
You also made a point that some users might not what those options and frankly thats irrelevant if your aim is robustness, which you keep harping on about.
However I agree that there will have been some bad ideas there and some which need more fleshing out. You were basically asking me to do the work of hundreds of people over the last 20 years by myself in one evening. A point I did emphasise in that post in fact :)
Re GDPR and cookie laws, I was using that to illustrate how bad the problem had gotten. I don’t agree with the cookie concent law either but I do disagree with your point about GDPR. There are measures you can do to mitigate data collection (or at least the current modes) but You’re definitely right that it’s imposs to prevent entirely.
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.
> However it seems pointless me going into the finer details given you've already dismissed it out of hand
I haven't dismissed it, that's why I _asked_ whether or not it only controls network access. Does it? You mentioned other related products that offer features similar to "your typical modern AV suite", but I've never seen an AV suite that offered any sort of fine-grained control over application permissions before; certainly not to the extent that the web or even mobile OSs do. Control over network access, no matter how advanced, is not sufficient to constitute a "robust permission system".
> Once again you're grouping the multiple different permissions models of the web into one entity.
I'm not referring to extensions here. The ability to disable JS, sound, Flash, images, third-party cookies, etc, is built into modern browsers. chrome://settings/content
> 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
Give me an example. Again, vulnerabilities like XSS don't count; only permissions.
> You've yet to example another system that is worse than the one you're claiming king
I can name plenty. Windows, Linux, and Mac all allow apps full access to every file on the hard drive owned by the user by default. It's hard to get much worse than that.
> yet I've exmapled plenty which are better.
No you haven't. You named Zone Alarm (which is still under discussion), Firewalls (which only control network access), SELinux (which is way too hard for the average user to use), and iOS (which is very close to the level of the web, but still not quite as flexible).
> it's only a security vulnerability because the security model of the web allows cross site scripting by default
This is like saying "RCE is only a vulnerability because the security model of Linux allows buffer overflows by default". First, it has nothing to do with permissions. Second, it's attributing a vulnerability in a third party application to the platform rather than the application. Third, the web does _not_ allow "Cross Site Scripting" by default. Are you familiar with how XSS works?
> 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)
You're right, it's not reliable. That's why it's not part of the web permissions model. But it's still far more control than any other platform gives you, which is the point I'm trying to make.
> 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.
Counterexamples: uMatrix, Privacy Badger, Tor Browser.
> 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.
Clearly the latter, as we're talking about consumer software platforms here (the web), not isolated tools.
I'll let you in on a secret: Facebook is also controlling your graphics card, and CPU, and memory. Controlling as in "sending HTML that is then displayed via those hardware components".
And just like a media query can "access" your device orientation, panoramic media can adapt to the data from accelerometers.
The missing information here is the concept of "secure contexts": https://w3c.github.io/webappsec-secure-contexts/#intro. Being able to use this data does not mean that it can be send back to the server.
"Your Wells Fargo bank accounts perfectly safe from bank employees because armored cars are used to transport money. They don't let normal bank employees into the back of those vehicles. Only licensed and bonded security guards are allowed."
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".