New in Chrome 70 | Hacker News Reader

New in Chrome 70

developers.google.com

180 pointsguzik193 comments

HackerNews is starting to become less and less useful for reading tech news as of late. I come here to read stuff that's interesting in tech/science/etc, because the signal-to-noise was great.

The vast majority of comments on this article are complaining about a single thing: a bluetooth API behind permissions check, and then spilling over into political arguments about what the Web should be (documents only!) and hyperbole (e.g. "i'll be bombarded by permission requests" -- lots of Web APIs can ask for permissions already like the Mic and Webcam, why isn't there an epidemic of permission spam from those, but you expect BT?)

For example, if I hadn't read the link in detail, I wouldn't have even known about the Web Authentication API extension (https://developer.mozilla.org/en-US/docs/Web/API/Web_Authent...) to the Credential Management API. Improving authentication on the Web should be an interesting topic for HN, but no one even mentioned it.

The ship has sailed, we're 20+ years into this open ecosystem of ephemeral, mobile code execution, with Web Assembly poised to take it even further. We're not going back to documents-only, so either we improve the Web, it's security, performance, and capability, or we freeze in place, and hand our lives over to the App Stores of the world (the security world of native-platforms with side-load app capability isn't very impressive at this point)

> The vast majority of comments on this article are complaining about a single thing: a bluetooth API behind permissions check,

A HackerNews staffer wrote, some time ago:

> We've reverted the title from “Chrome 70 supports Web Bluetooth on Windows 10”, which breaks the guidelines by editorializing.

So that's your proximate cause. Somebody editorialized the article and the initial responses are to that editorialized title.

Good point, and an excellent justification for the no-editorializing-policy! They should link that policy to this thread to show what happens to S/N when people editorialize for clickbait.

I absolutely feel the same way and was thinking about this when I read the comments. Its like we have become old and disenchanted. We no longer see the the positive potential of an underlying piece of technology(or even the technology itself) but see ways to further exploit us.

Somebody has to though. If we just blindly accept things, then we end up in a nightmare we have with unsecure IoT devices. It should be accepted that if something can be exploited, it will be exploited. As developers, we shouldn't be blind of that.

But almost no one goes any further than complaining about the modern web and javascript and the existence of "web apps."

If these tangents came with constructive ideas about how to improve the situation, that would be fine. But the only suggestions people seem to offer are to abandon the web as a lost cause or break the web somehow.

And heaven forbid anyone mention Webassembly without someone predicting that the entire web will inevitably be converted into closed proprietary WASM blobs and HTML will be deprecated... for reasons.

It's getting unreasonable and counterproductive. I feel like if some people had their way, computing would have never advanced beyond the terminal, or at best, at the state of the art in 1990.

> If these tangents came with constructive ideas about how to improve the situation, that would be fine. But the only suggestions people seem to offer are to abandon the web as a lost cause or break the web somehow.

Some of us are suggesting constructive alternatives:

- test your site in all major browsers

- make sure it works without JavaScript and is readble without styling. Thst is unless you are creating a frontend application.

We've been complaining about this since IE6 and we had it more or less nailed for a while around web 2.0 until enough devs started thinking

- it was enough to target Chrome

and

- JavaScript is available everywhere.

There's no reason why most blogs and news sites should need JavaScript.

And there is no reason why Chrome monoculture should be more acceptable than IE6 monoculture.

Regardless of the industry, bad actors always ruin it for the rest of us. I am familiar with the saying of "don't bring me problems, bring me solutions". However, not every problem has an immediate solution, or just because I found the problem doesn't mean I understand it or even in the correct place to fix it. I would think that applies to most people finding issues and trying to report it as well.

What I find counterproductive is that we know there are bad actors out there just waiting for the next thing to come out that they can exploit, yet very little is done to counter act it during development. Yes, develop the thing, but before releasing it into the wild, maybe do a little pen-testing on it before releasing the next delivery device for the whatever ill will someone might use it for.

Plus, this is Hacker News where part of the group are the ones cracking things open to see what's under the hood while another part of the group are the ones building the next "thing". Keeping these kinds of articles front of mind might actually make one of these devs actually think about adding some extra security.

I think my problem is that the comments are so often predictable. I wouldn't mind if it were annoying niche complaints from a unique perspective, but this static web discussion comes up all. the. time.

Exactly. You can read the repetitive arguments over a document-web vs an application-web everywhere, just like I can read Android vs OSX, or Emacs vs VI everywhere. This has been going on for decades with no resolution.

Often what I love about HN is someone in comments raises an interesting or unique point, and posts a link to some paper, article, or video that goes in-depth into the issue in a thoughtful way. More of that, and less of "FooFramework was announced? Sorry but do we need another FooFramework!?" style stuff.

HN was really interesting because the entire purpose of the site was to engineer and moderate it in such a way that signal is inherently promoted and noise is downplayed. But the fascinating thing to me is that its users have evolved to post content that matches what HN's algorithms have considered "signal", despite it not actually being signal, and HN's algorithms and moderation haven't evolved with this statistically significant influx of faux-signal! The very goal of the site is put in danger by its own users learning how to use it, almost like natural-selection. Ironic!

Is it even possible for any open community to be immune to natural selection effects?

Perhaps fawning over the latest piece of technology and APIs has become unpalatable as more people have woken up to the idea that technology is neither politically nor morally neutral.

That's a sign of the industry growing up: those working in it are starting to think about the consequences of what they are doing and are speaking up against misbehaving companies like Google.

Who cares about some silly web authentication API when Google will engineer the thing to its maximal data collection potential anyway?

Did any of the critics making unsubstantiated claims like this even bother to read the Working Group mailing lists where people are discussing the security and privacy requirements of these APIs? These specs are being developed in the open, with input from organizations like Mozilla and security engineers from all over. If you have a specific claim, you can reference the spec and make it.

Also, the whole point of the "silly web authentication API" is to do away with passwords and usernames, and let users supply authenticated credentials, which would enable -- if desired -- creation of as many user credentials as you like, without having to tie everything to your email + password, which could make it a lot easier for people to have many different identities that can't be linked between sites, as well as make it easy to create 'throwaway' identities.

This 'silly' API doesn't increase data collection, it simply fixes some of the biggest problems with web security: passwords and 2-factor authentication.

This is the tech equivalent of the following fallacious kneejerk reasoning you see in anti-vaxxers: "big pharmaceutics/Monsanto is evil, therefore since big pharma also makes vaccines, any new vaccines that comes out is bad because they just want your money." This kind of knee-jerk conspiracy theory stuff doesn't help public health and isn't linked to any specific claim.

If you've got a specific technical critique of a new spec, you should make it, but to dismiss a new security API as "silly" is a non-sequitur.

> ...so either we improve the Web, it's security, performance, and capability, or we freeze in place, and hand our lives over to the App Stores of the world

Considering the most-important browser and the second-most important app store are made by the same company, with the company having about the same capabilities of control in both, I wonder if there is really that much of a difference anymore.

Wow. You completely missed the point OP was making and instead did what he was complaining about. Incredible.

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".

>Too much time spent on "can we", too little time spent on "should we".

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.

The user is not a part of the conversation. Very little seems to be for the user any more, as every site and browser update seems to demonstrate.

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.

I love the fact that there's an OS-in-OS. It makes writing cross platform applications with easy distribution and access to rich APIs very easy.

I agree that it's great, my big problem is that most web pages don't have anything to do with being an "application", they're just a document. I'd say that 99% of my web browsing has nothing to do with web applications. Hacker News, Wikipedia, search results, news websites, issue trackers... When I look at my browsing history I don't find many webapps.

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.

The way to solve this is static analysis. I'm not giving up on the Turing machine, so we'll just need a way to analyze a given machine to determine whether it falls in to your low power use case.

Hackernews, Wikipedia, issue trackers are all web apps and not documents even if the primary function is to show documents/text. They all have functionality to add/edit comments, etc.

AFAIK the only functionality requiring JS on Hacker News is the up/downvote system. Comments open a new page anyway, so does editing. Wikipedia and issue trackers are the same, you only need to be able to GET and POST content basically. In terms of complexity it's very low.

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.

Very little on the web qualifies as a "web app" if the definition of that is, in essence, a simulation of a native application in the browser rather than merely an interactive document. But if that's the case, why are people upset about web apps "taking over" the document paradigm of the web?

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 true, there are benefits. We must ask ourselves collectively whether the benefits(easier cross platform development) are worth the price(increased data collection by gigantic multinational corporations used to manipulate populations to direct user spending).

And the answer is yes, the benefits are worth the price, provided you have a way to analyze a given page to determine whether or not it's a part of that multinational corporation botnet.

>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

This is the statement that I have known for years but never put into words. And it rings terrifyingly true.

What is terrifying for me is that when it was happening - and it didn't happen overnight, it was a long process - relatively few people were objecting. The ones who objected were often ridiculed as the tinfoil-hat group. The people who should have been smart enough have been blinded by shiny new releases, the amazing things we can do now, for free. It's only recently that the general public started to discover the ugly truth, whereas we could clearly see it already many years ago!

That's a tough one.

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.

> Never attempt to break down the functionality across several dedicated clients that do only one thing and do it well, that's for losers.

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"

Microsoft used to have decent PR in the past, too. They lost it because of their user-hostile behavior, just like Google is losing it now.

They had good PR with businesses but I don't think they really cared much about the opinions of end users. When the overwhelming majority of computers sold come preinstalled with your software you don't really care if people dislike you. I think for many people (even today) Windows is just something they need to use the software they want. Chrome is getting there too, with more and more websites requiring it to work correctly.

When your audience is captive you don't have to pretend to care anymore.

If you're talking about the DeviceOrientation event [1], it's been shipping in browsers since 2010 [2,3].

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 also works on your MacBook. [4]

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.

I just noticed that [4] doesn't work on Safari or Firefox either (but does on Chrome) on my MacBook 2010. Maybe it wasn't the best demo of that feature ...

The API is pretty well supported on tablets and phones though, which is where the main use case is.

Doesn't do anything on my Chrome @ MBP 2015, but then again I use all kind of extensions.

> 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!

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)

Websites can't trivially scan nearby devices, as far as I'm aware.

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.

I'd be very happy if this could solve the decades-long computing problem of sending a file from one computer to another one next to you.

AirDrop :D

Because you know, I've always been on my desktop computer and said... "You know, I'd totally use that cool mesh Bluetooth chat app that's so popular and lets you communicate with people within a 25 yard radius, but ultimately falls back to using WiFi because Bluetooth is impractical for this application. Sadly it's not for desktops. If only I could use my web browser..."

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

> In fact, no one has ever said "I wish I could use Bluetooth in my browser"

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.

Let me be perfectly blunt. This idea won't work, because Bluetooth is an atrocious protocol. If it would work, a native app would have successfully implemented it, and taken the world by storm.

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.

Thank you, that's valid criticism.

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.

1. You need exact timing between devices for the freq hopping to get to the right freq

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".

Actually, from 1.0 and on, bt specwriters did everything to balance the complexity of implementing bt in silicon with protocol's performance.

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.

> This idea won't work, because Bluetooth is an atrocious protocol.

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).

>> In fact, no one has ever said "I wish I could use Bluetooth in my browser"

> 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.

I'm not sure which society you are referring to specifically. The one I'm most familiar with (Catalunya) don't really care how things happen, as long as they can get communication access to each other that is not controlled by a government entity. Mesh networks is just one way to achieve this.

But in the end, always good to have choices so the ones that happy with what they have, can always stay that way.

The Web Bluetooth API asks you for permission every time. Like every new web standard like it. It's still something many users will blindly click through but at least there's that.

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.

> It's still something many users will blindly click through but at least there's that.

Malicious sites can trick you into accepting too:

https://www.reddit.com/r/assholedesign/comments/9p3172/yeah_...

That “allow notifications” popup is way too small... instead, it should pop up in the middle of the screen, have big bold letters, and gray out the website in the background. Then wevsites would be much more careful about asking you about it...

This is frustrating because this isn't a difficult UX problem to mitigate. Opera 12 for example had excellent distinction between in-page and browser-powered UI prompts. It will always be possible to socially engineer some people, but making it a bit more obvious isn't difficult.

Firefox at least has very slightly more distinct pop-downs than Chrome's.

> As for Facebook and the accelerometer, I'm presuming you're on Android, so you can definitely blame Google for that.

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.

Well, not all... Googlers had no idea what a gold mine they were giving away up until around late 2016, when they unknowingly broke high precision timing in V8.

What about a keylogger with 50% accuracy?

V8's timers have nothing to do with this, given the API doesn't give the data to even do any timing analysis on.

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.

The tricks had much to do with kalman like techniques, and possibly non-linear analysis, than doing brute force position estimation or statistics.

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.

How kind of them to ask! It has all the charm of someone walking up to my house at four in the morning, and knocking on the door to conduct a survey of which radio stations I listen to.

It shouldn't be asking, ever. The answer is such a hard no, it makes me wonder why they even tried.

Why specifically at four in the morning in your analogy? I mean, door-to-door surveys are a pretty common thing at normal hours of the day, and that seems like a reasonable analogy without the arbitrary time change.

Bluetooth provides useful features for many users, that's why.

Yes, like making poor estimates of my heart rate, being an insecure keyboard, or occasionally failing to deliver audio to my car speakers.

Definitely will be useful in my web browser.

Are you claiming that Bluetooth can never be useful for anyone because you don't find it useful?

> It's still something many users will blindly click through

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.

Site's can not do anything with Bluetooth API unless the user explicitly granting them permission to use the feature. A site can't even query the devices around the user without the user getting a very clear and actionable prompt - so in this case it is nothing like the orientation API.

So the sheep can't query the interface without the wolf's permission? great... I'll be sleeping so much better tonight.

Right? Now imagine phone tilt or battery information on the scale of billions of people. Imagine what you can infer.

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.

Does phone tilt really give an acceloremeter data stream? I thought it was just landscape or portrait.

it does but only while the page is active. As soon as you switch tabs, apps, or your phone locks the data stops

Also, when the phone is upside down (reading in bed), or traveling etc. Scary to think of all the things that could be gleaned.

This is also similar to the time that WebUSB[1] was added to Chrome, allowing access to USB devices in the browser.

I feel that we are frogs in boiling hot water.

[1] https://developers.google.com/web/updates/2016/03/access-usb...

FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity.

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).

> FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity.

And it was done by Mozilla people working on FFOS, specifically. They had no intention of exposing it to web content IIRC.

I still see FFOS as ahead of its time. I really wish it would have worked out better.There's all this jostelling happening between the role of software based apps vs. the role of web content/apps on devices... but in the end every day I see more and more content being served through the web. As browser integration improves (through things like 'web bluetooth') I think we're creeping more closely to the browser essentially being an app sandbox for your hardware/OS.

Now, whether this is good or not is left as an exercise to the reader.

I think the original idea was that background JavaScript apps could suspend operations when your battery is running low.

It quite an edge case but it’s one of those things that make a web app less than native.

> [...] 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?

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.

> 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.

The battery api was removed from Firefox for this reason, it was only used for tracking unfortunately.

Another one is the Push Notifications in browsers. I always block them. Once you open up such APIs websites will abuse it no matter what.

I run my(?) browsers in their own separate virtual machines. You loose copy and past and you'll need to set up folder sharing, but shit like this is a non-issue.

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.

Why lose copy&paste? Virtualbox supports seamless copy&paste, every other VM probably supports it as well.

Would you complain that web browsers have access to your keyboard and mouse without explicitly asking? If not, then why complain about access to DeviceMotionEvent?

Oh, they're asking "should we" -- they're just not asking the public (the public is the product being sold, after all).

> And now, random websites can grab control of my radios? With JavaScript?

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.

The industry is trying to replace native apps on mobile devices with web pages.

Technically, Javascript can already make web requests, whoch when you are on a phone means using wifi or mobile data, both of which are radios.

So Javascript has always controlled your radios. This is just one more connection.

This is an android thing right? They gotta add more fine grained permissions

If some browser application can get bluetooth devices to actually work and do things for it, good for it. I sure as hell have never been able to hehe.

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.

It's not a few bad apples. It's a shipping container full of rotten apples, and maybe two good ones.

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.

> 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.

Also worth mentioning that there’s a ton of stuff that browsers just hands over to websites without making so much as a peep to the user. It’s great that they pop dialogs for the things they do, but they’re still far too permissive.

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.

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.

> If it was as robust as you make out then we wouldn't have a need for the cookie consent law

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

[2]: https://github.com/WICG/feature-policy

[3]: https://github.com/WICG/webpackage

The “good reasons” is backwards Compatibility. Which is why I keep taking about a new ground up standard for web applications.

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.

> 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.

EDIT: Nevermind, I'm abandoning this part of the thread. Your other comment where you suggest concrete improvements to the web's permissions and security model is proving to be a far more productive line of conversation. You can just ignore the rest of this comment if you want.

> 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 think we’ve hit an impasse tbh. I fundamentally disagree with your points and you fundamentally disagree with mine. However I think part of the problem is we both come from different worlds within IT so our perspectives are likely just a reflection of that.

Get Off My Lawn!

WebAssembly and PWAs are only going to make this worse, as they give browser vendors an excuse to give websites full access to the user's local machine.

All new web standars are a terrible idea to our privacy and security. And for some reason nobody seems to care.

My theory on this is becoming - because the nerds that would care all work for the Big Five and as such think it's ok because "we're not evil". Once that crowd gets quieted then there's no on to raise the flags for others.

People care, but those who do are not working on them and their voices get drowned out by the "push the web forward"/"progress is always good" crowd. I suppose there is a bit of cognitive dissonance among developers of such things too.

> Why did nothing ask me if I was ok giving Facebook access to my hardware?

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.

"Secure Contexts" just means you're visiting the site over HTTPS. It has nothing to do with restricting the ability of JS to communicate with the internet.

That's a misleading non-argument for the actual issue.

"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."

Great, another feature that is probably useful for <1% of websites but will likely be used for anti-user functionality like tracking and surveillance more than that.

Maybe I'm just old, but I find this trend of exposing more to the outside over the network quite disturbing, and it's also becoming rare for me to be joyful about a new version of software instead of "what did they break or bloat this time"... the Web was far more pleasant when it was about hyperlinked documents and not this cloud-computing-inspired frenzy.

the Web was far more pleasant when it was about hyperlinked documents and not this cloud-computing-inspired frenzy

It was also a lot less useful though, as it was mostly about consumption. All of the creating happened elsewhere. People made things on their computer in other apps and then published them to the web. Now though, the web platform is shifting towards being a creative place in itself. People can make and share things entirely within a browser. I'd think that's a significant positive change.

I would disagree that the web was more about consumption.

There where more personal pages because html was simple and there was little reason for large businesses to build pages around consumption or write html for you. Older browsers even had edit modes and would use the http PUT method to send updated versions of the document.

The original intention of the web was a sort of global wiki, not this tool to connect you to some coorperate service.

There where more personal pages...

Than Instagram accounts? YouTube channels? Facebook pages? Twitter profiles? No. There's far more now.

The landscape has changed and things look very different, but those things are personal pages where people publish what they want to say. The only thing that's changed is that the platforms people publish to have far less scope for personalisation.

I'd definitely agree that those pages are worse than homepages we had in the 90s as far as a personal voice is concerned. They're mostly boring, homogeneous things that only very close friends of the owner want to read (and even then...). Nonetheless though, they are homepages.

> All of the creating happened elsewhere. People made things on their computer in other apps and then published them to the web.

The interesting thing there is that most people use those tools (Instagram, etc.) through an app, not through a browser.

I'd argue that things like "likes" have created an environment where people generally publish what they think other people would want them to say (e.g. things that will be "rewarded" with internet points), rather than what they actually want to say.

That's just 'better' metrics. Back in the day we had hit counters and server logs, and some of us tweaked our content to drive them up. There were early forms of SEO, clickbait, content marketing ("content is king" was something every web person knew). The desire for recognition was there at the start.

I beg to differ. The web I participated in through the early to late 00s, most of which came before the web app craze, had a far, far better ratio of creation:consumption.

This held true both in meta sense (the web itself) with tens of thousands of individually run sites and blogs instead of a handful of hypercentralized content warehouses, as well as in the proliferation of numerous creative communities and individuals making things. I know because I spent the majority of the 00s on these sorts of sites.

Today, all of that’s died almost entirely and no subreddit or facebook group or anything can hold a candle to it. Today, the web is all about endless monetized entertainment streams designed to maintain the attention of as many eyeballs as possible as long as possible. It’s effectively turned into the modern equivalent of network TV.

People can make and share things entirely within a browser. I'd think that's a significant positive change.

Forums and blogs don't count? Those were present long before this "turn browser into OS" trend started.

Forums and blogs don't count?

I've been making web things for a long time. When the grandparent posted "when it was about hyperlinked documents" I took that to mean "When we wrote things for Mosaic". Forums didn't really exist on the web back then. I'd say that comments, forums, etc were one of the first creative tools. We've come a long way since then, but there's much more to do, and it's all very exciting. It's definitely making the web better IMO.

> I've been making web things for a long time.

I've been making internet things since before the "web" existed.

> Forums didn't really exist on the web back then

Gopher didn't really have the necessary interactivity, but nobody cared at the time because if you wanted to talk about something in a global forum, you used NNTP (or email lists).

The web (HTML+HTTP) had comment/forums/etc from the very beginning, because it was designed with IBM 3270 style form submission features (<form>/<input> tags and HTTP POST). I used these (and other interactive features) regularly in text browsers over my 2400 baud modem. Even if I had better bandwidth, there was no way I could run NCSA Mosaic in the 4MB of RAM installed on my 386DX. Yes, it was slow, but submitting comments only required special support by the server, which then returned a new hypertext document to the client.

The feature that arrived later was Javascript, allowing some features to be done directly on the client. However, this was not a necessary required for writing forums software; that always worked as server side software.

Shoving everything into the client didn't create many new opportunities; a lot of that existed already in separate software. What did happen is we attached everything to the same single point of failure and created a lot of security problems because risk is transitive.

No, what we did was trade off one set of security problems to having dozens of clients for every TCP protocol (IRC, NNTP, SMTP, IMAP, FTP, WAIS, Gopher, fingerd, etc) with their own set of security flaws, but which had less oversight, and that gets you things like the Morris worm.

And because every one of these had their own rigorous protocol, and their own binary clients, if there was a flaw in the protocol itself, it could take ages to get a fix to the protocol from the IETF and all clients deployed with the fixes.

So for example, the obvious and horrible security of usenet led to the first massive spam bots, which then led to a bunch of even more horrible mitigations like Cancelbots, which led to a bunch of counter-mitigations like Resurrector-bots.

These days, with ephemeral, mobile code, a security hole in the client/server protocol of a particular app can be fixed in an instant and rolled out to everyone. And the Web is better at this than the native mobile or desktop platforms, now behind curated App Stores, with a lower update frequency, and whose very closed-source curation process means they don't get as much rigorous testing as the Web in running untrusted code.

The Web has been running untrusted global scale mobile code for decades now, and most of the exploits on the Web have occurred as a result of bad server programming, not holes in Javascript. So Web 1.0 request/response apps won't save you, all it will do is punish everyone with bad latency and higher server loads.

There are already tons of features that are only useful for <1% of websites. You can't deny that this is useful though - this is one of the things that makes the physical web actually plausible.

Combined with Android's support for bluetooth beacons you can now have this feature, with no additional software installation required:

1. You walk up to a device.

2. A notification appears on your phone saying you are near it.

3. You tap the notification. It takes you to a website that lets you connect to the device via BLE.

4. You interact with the device via BLE.

All without requiring network connectivity for the device (which is always a huge pain).

You have to give permission for the website to access BLE. This is cool. You are just old.

What are you going to do in a year when you get hundreds of these notifications per day?

I definitely see the potential for harm in this, but I'm excited to program arduinos from a web ide with a statically-served text editor + toolchain. Personally I switched to Firefox. The ideology is only minimally better, but I'd sooner trust Mozilla to ask my permission to use a new web api.

>the Web was far more pleasant when it was about hyperlinked documents and not this cloud-computing-inspired frenzy.

The web was far more useful for you. I, for one, am glad the days of IE6 and the lot are over.

I think the GP is talking about long before IE6 was a thing. Even back in the IE4 days there were web based games, HTML chat rooms, etc. I remember writing vast interactive 3D landscapes in VRML which were embedded into home page even as early as the late 90s (~4 years before IE6 was released).

But aside VRML and other browser plugins the web was ostensibly just a network of hyperlinked documents. You'd make an action and get a fresh page. Make another action and get another fresh page. Sure it was primitive by today's standards but it wasn't possibly to do half the "evil" things we complain about today (user tracking, browser mining, etc) and there were still big social hubs like the Yahoo! portal too. What's more, because the barrier for entry as well as people's own expectations were that much lower it meant you saw a hell of a lot more individuality in the content posted. People would literally put a website up about their favourite designs of bridges, the shapes of snail shells, cartoon trivia no normal person should care about, or some local landmark. There were sites dedicated to the most mundane of things yet they were strangely fascinating topics because you get drawn into the topic through the obsession and wonder that drove the sites author to dedicate his on little piece of the web to it.

These days the signal to noise ratio is so far tilted the other way with people obsessing too much about contributing what they think people want read or boasting about stuff they feel is boast-worthy that it almost completely drains out the purist content from people who just post stuff that genuinely interests themselves. This is compounded by the fact that the web has been gamified by some big names to encourage the kind of boastful content I described earlier because that feedback loop of posting content then waiting for "likes" and/or means more screen time which, in turn, means more eyeballs on adverts. The fact that everything is so bite-sized hardly helps either; Facebook statuses, Twitter "tweets", Instagram posts - they're all short, direct, "shots" of information. Fewer people engage in the longer process of having a page dedicated to a subject. Which means we lose a lot of detail, creativity and personality.

The only good thing about the modern web is that while the barrier for entry writing a website has gone up, inversely the barrier for entry publishing content has gone down dramatically.

>What's more, because the barrier for entry as well as people's own expectations were that much lower it meant you saw a hell of a lot more individuality in the content posted. People would literally put a website up about their favourite designs of bridges, the shapes of snail shells, cartoon trivia no normal person should care about, or some local landmark

You can still find those types of sites if you want.

>These days the signal to noise ratio is so far tilted the other way with people obsessing too much about contributing what they think people want read or boasting about stuff they feel is boast-worthy that it almost completely drains out the purist content from people who just post stuff that genuinely interests themselves.

With more people joining the web, that will be a side effect of it. On the flip side, there has been so much massive positive change on the web too. Online transactions, many government services becoming online (many times reducing corruption), email and IM connecting people around the world in a way never before, and many many more things. Just focussing on the negatives by commenting a few types of sites like fb, insta, twitter etc is fainting a very one-dimensional picture.

>The only good thing about the modern web is that while the barrier for entry writing a website has gone up, inversely the barrier for entry publishing content has gone down dramatically

I actually think that is a bad thing, not good. What made the web the web was the low barrier to entry. Also, if you think that is the only good thing about the modern web, then I really don't think you truly realize the scale in which most people take the web for granted nowadays in their everyday lives, which affects them in a positive way.

> You can still find those types of sites if you want.

You can. And I made that point myself. The issue is the signal to noise ratio and the way search engines rank sites. Finding those gems I described above have become harder than it used to (in my personal opinion)

> less corruption

I very much disagree that there’s less corruption now the web has taken off. Or at least if there is, I disagree it’s directly related to stuff getting published on the web.

> email and IM connecting people around the world like never before

Email and IM have existed long before the web (decades before in emails case), nevermind being available around the period of the early web that we were talking about.

> just focusing on negatives like fab, Twitter, etc creates a very one dimensional picture

I totally agree.

The reason it was written that as was because I wanted to offer a counterbalance to the previous post rather than a balanced and impartial commentary. However you’re right that the reality is somewhere between the two arguments.

> I actually thing that’s a bad thing

I think you’ve completely misunderstood my point because you’re arguing the same point I made with using language that suggests I was opposed to those points you’re making.

Also you seem to be confusing “web” with “internet” in some of your previous remarks and also suggesting I’m totally against the web in its entirety; neither of those points are true (in fact I’m very much pro-web)

If you don't use these capabilities, they probably amount to less than a Megabyte increase in the file size of the binary, and the potential that you could be shown a dialog when a website asks for permission.

I fail to see how this might significantly cramp your lifestyle, or what this has to do with cloud computing.

(You can even disable these functions globally. Or at least that's what you can currently do with similar APIs like MIDI device access. (And btw: Did MIDI device access ever get you profiled by the CIA?))

> potential that you could be shown a dialog when a website asks for permission

First, I suspect that this is in itself annoying to many users (it is to me). Next, even at 1% of accidental clicks it would give out large unintended access. A cynical part of me says that if technology shows tracking benefits it would switch to "accept once, reject every time" and many users would be tempted to click on it just to make those annoying popups go away.

The main beneficiaries of this misfeature are advertisers.

I think Google tries to cram all this functionality (WebUSB, now Bluetooth) into Chrome because of the limitations of ChromeOS.

So many I'll informed comments on top of this submission. First, the web Bluetooth API requires a permission. It's useful for more fully featured PWAs. Even though I personally think the browser shouldn't have become an app platform, that's the world we live in now. The best cross platform solution is the one most platforms support and today this is the browser.

>First, the web Bluetooth API requires a permission.

ActiveX also required a permission...

Mac has supported beginner friendly ways of sshing into let's say a Raspberry Pi over Bluetooth[0]. I would love to see a progressive really any app for Windows like this.

[0]: https://hacks.mozilla.org/2017/02/headless-raspberry-pi-conf...

Aside - It also lets you install progressive web apps onto the desktop. Has anyone built PWAs, and if so, why? Do they work cross-platform/mobile well?

Installing as app works great for our PWA: https://editor.construct.net/

> Has anyone built PWAs, and if so, why? Do they work cross-platform/mobile well?

Works cross platform great. Construct 3 is a sophisticated productivity app, although it works on mobile devices it's not the ideal environment to get lots of stuff done with it.

Coming from a Windows native app, main advantage in developing a PWA is that it allows easy cross platform support (Chromebooks especially good for educational markets) and much more agility in developing compared to say a native app.

Very cool. Do you happen to have any links to read about getting started? Any specific technologies (frameworks/libraries/etc) that helped out? Any lessons learned?

My brother (and co-founder) actually develops the product with 2 other full time engineers, I'm not involved in the product development directly.

It was all built from the ground up though. I think we were well ahead of the curve when it was started to be developed 3-4 years ago.

Mentioned in another comment yesterday that we decided against using third party UI because we were worried about bloat, third party dependencies and general responsiveness. Whole app is usable in ~1mb of network load (less than lots of big-corp homepages) and we get comments from users saying after using it for a while they forget they are in the browser which is great and a strong indicator we've hit the mark.

If we were to start again today, we'd still roll our own UI.

My brothers blog is very good and often technical and goes into a lot of interesting web tech stuff relating to Construct 3 and PWA's: https://www.construct.net/en/blogs/ashleys-blog-2?orderID=1

There are a whole raft of benefits of PWA's, probably too many to list especially coming from our native predecessor Construct 2. Auto updating users to latest versions, no download/installation which helps significantly with converting users into just trying the product, faster load times than our native Windows predecessor, easier distribution etc etc.

Cross platform support is an incredible competitive advantage in some markets such as education where Chromebooks are common and competition is sparse/non-existent. It even runs on Raspberry Pi's and we're confident we're future proofed for new devices.

Making your PWA fully functional online is tricky but doable and I believe particular care needs to be taken here from the beginning. Retroactively implementing offline support would be difficult.

It's also important to not get too fancy and building it for offline use helps you avoid these traps. We've seen some PWA's record every user interaction within the PWA which appears to be the basis of some features such as undo - this brings in a huge raft of complexities.

A few shortcomings, but the gaps are being bridged slowly but surely. For example copying images to clipboard: https://bugs.chromium.org/p/chromium/issues/detail?id=150835

To me the progressive part is a side issue.

For someone like me, who has been trying off and on to use the web as a common application distribution platform for many years, being able to just pop up an install prompt and then have it installed like a regular desktop application seems very huge. I wonder why people aren't making a bigger deal about it.

It's a big deal because the simple fact of having to visit a website in order to access a web application was one of the main differences that affected the user experience versus native applications. Some applications will see more users because of this change.

Since it is somehow still controversial, I will go ahead and review my own perspective on the benefits of the web as an application platform. This is really down to programmer worldview so I realize some other people are always going to see things differently.

1. The web platform allows you to create one code base rather than having to maintain source for Windows, Mac and Linux.

2. The web platform has a set of APIs that are comprehensive and well designed.

3. The web platform handles distribution. Trying your application is as simple as one click.

I can actually see this as gradually taking share away from Steam for distribution of games (that can be created for the web).

I just toyed around with them, but I am slowly changing my opinion about native vs mobile Web.

PWAs appear to be a very good solution for typical CRUD style performance apps, specially with Web Components now being available across Chrome and Safari on mobile devices.

On Windows 10, PWAs have replaced UWP JavaScript apps, meaning if a PWA is properly signed and packaged into the store, you get to access the UWP APIs directly.

I haven't used ChromeOS, but I imagine similar functionality is available.

So you get to combine Web and native APIs with the runtime doing the necessary FFI for you.

This seems a good compromise when the native features aren't fully required, e.g. WebGL 2.0 vs ES 3.x / Vulkan...

I noticed that too. I'm not sure of the benefit of PWA on desktop, but I built a progressive web app, mainly because I need very few native features (currently only using push notifications) and I'm only one person so I don't have time/interest in writing native code when I can write for the web and be done.

I use it daily on my Android and it works well for my needs. I get caching and push notifications, my app is right on my home screen so just one click away. All this is very cheap (writing a service worker) compared to trying to figure out Cordova or Electron.

I currently use the 'app' feature of Epiphany (GNOME's web browser) and it has 90% replaced my need to install Electron apps. So I welcome the future where most of my apps are really just nicer looking isolated tabs rather than separate web browsers.

PWA are obsolete, weixin miniapps are the future.

Is there an English primer on how to build WeChat apps? What's involved?

https://open.wechat.com/cgi-bin/newreadtemplate?t=overseas_o...

Aside from that, simply integrating individual apis into your pages can also be a solution if you don't want a full blown miniapp

The greatest threat to the web is those that want to turn it into an “app platform” instead of a hypermedia system. Sadly the battle has probably been lost.

HN commenters have such a strange cognitive dissonance on this issue.

On one hand, there's this consistent theme of web Luddism - a lament for the simplicity of when the web was for documents, rather than apps.

On the other hand, there's this rage against increasing control of distribution channels by tech giants like Apple. The whole point of the web as app platform is to circumvent that.

Those are not incompatible sentiments.

You can think centralized distribution is a problem and still think the modern web is a bad solution to that problem.

A problem is that the web is being used for both applications and documents. I don't mind if an application I explicitly launched as an application asks to make Bluetooth connections, but I would mind if a blog post did that.

I think there's a lot of value in web applications, but I really don't like how it interferes with the non-application web.

> I don't mind if an application I explicitly launched as an application asks to make Bluetooth connections

The security model for a desktop-installable 'app' is a superset of a webpage. Or at least it was in Firefox OS, where additional permissions were required for accessing the filesystem or hardware APIs. In this way they were not available to websites to hijack the in-browser sandbox; the system web browser was itself a 'browser app' with a restricted set of permissions.

(I presume it's similar in Chrome OS, while this blog post is in the context of 'appifying' Windows desktop outside the browser.)

> I don't mind if an application I explicitly launched as an application asks to make Bluetooth connections, but I would mind if a blog post did that

There is an easy way of getting this experience today. Install NoScript (or some other extension so you can enable JS ondemand for certain websites) and everything is by default basically documents (well, forms, inputs and such will still be there). Then, when you encounter a application that needs JS, you simple enable it for that website.

Granted, I encounter many websites per week that simply won't render without JS, even non-interactive articles! Usually I just close them down unless the content is something I really, really want to read.

It would be nice if websites and web apps existed on different layers, so you could opt out of either if desired and know exactly what you’re going to get on both.

I can imagine people having the same conversation back in the 90s: "Who needs images?"

In what way is it a threat? It’s not like every website needs to use the new features.

If you mean security/privacy wise, then yeah I agree. But I don’t think it’s a “threat” in any other sense, eg it doesn’t mean every website is suddenly going to be using accelerometers and Bluetooth. It just means a subset of websites will have more features for browsers that support them.

Aside from the security/privacy issues, shouldn’t we be celebrating this as a liberation of functionality from walled garden app stores?

You are right. The sites that will use this are those who have a strong incentive to do so. Therefore this will likely be used by: 1) A really tiny minority of sites that enhance functionality with this. 2) Malicious sites. 3) Sites that are trying to track you more and better (so, for example, FB can use this to ID you across devices even if you’re not logged in because you probably use the same Bluetooth headphones across your devices).

A really tiny minority? Today I navigated some maps in an unfamiliar city in a web browser. I also edited some images. I streamed some video too. These are incredibly useful features.

Pretty much the only "raw document" websites I ever visit are wikipedia, hn, and stack overflow.

There's no threat to the web. Having the ability to be an app platform in no way stops people from sending non-interactive documents over it.

The 'threat' is that people will use these features. And if the only thing that is keeping the 'old web' alive is that it simply wasn't possible to develop rich applications then it's already dead and probably never really existed in the first place.

You think this is bad? Wait 10-15 years, when the next layer of abstraction starts to take hold and now you're running some other platform on top of a web browser on top of an OS and all the kids are saying "this time will be different!".

We are already running all kinds of JS frameworks as an abstraction. Like React

Making "Hold ⌘Q to Quit" the default on Mac is such a user-hostile change. There is no reason to deviate from the platform default that literally every other Mac app uses.

> Users can now install Desktop Progressive Web Apps on Windows & Linux!

This is great, but hopefully Safari(especially on iOS) will follow suit and support PWAs. I recently wrote a PWA but changed it to use Cordova because Safari on iOS doesn't support "Add to Desktop" for PWAs. If it does, I definitely couldn't figure it out when running the latest iOS.

One thing I'd like to see Google do is allow PWAs to be listed in the Play store. A lot of apps are already web views, and a PWA could be much more practical, especially if they provide some APIs to fill the gap between web and native.

EDIT: Nah, I take that back. Fuck the Play store. I hope people can become comfortable with downloading PWAs directly. One of the things that held me back from releasing a PWA is the people I tested it with weren't comfortable downloading an app from a "random" website, which is pretty ridiculous seeing how easy it is to release horseshit software on the Play store.

It definitely does. If it’s not appearing something is wrong. A common cause is some asset being delivered over http rather than https.

Actually, it should allow you to add ordinary websites to the desktop, but doesn’t display them full screen. Forgive me if this is a stupid question, but did you just not scroll right on the menu in safari? I couldn’t find it the first time I went to add a site to desktop either.

Most of this thread seems to be people upset that this exists. Do people not realize can control javascript permissions?

They're rightly concerned that it will be used like notification permissions: just one more thing you need to cancel when you use a site. Yes you need to consent, but even being asked is audacious.

Notification permissions are widely (mis)used because many sites already have a legitimate use-case for that permission; keeping users updated on new articles posted on the site.

It's not at all clear that a similar widely applicable use-case exists for Bluetooth.

This is just plain boring to be honest, I don't want to be notified when a new article is released, I'd rather manually check a RSS app when I want to read such news instead of receiving a notification while I'm working. To each its own I guess.

It's another google invented 'extension' to the web, built for one purpose: to validate their assumption that a Chromebook is a viable computing platform.

"The web has all these limitations, how can a device run only web apps" "Oh well we're google, we'll just shoe-horn whatever shit we need into web specs and force them through."

When this came up for discussion a year or two ago, it was highlighted that they acknowledged the potential for harm, and gave zero solutions to resolve that issue.

Edit: its an almost comically similar story with their other attempt, "web usb"

People are upset that javascript exists as well

Being able to use Bluetooth REPL for microcontrollers running MicroPython is somewhat cool, but also rises serious security concerns, if such a device is used for IoT.

I'm sure nothing terrible will happen by exposing Bluetooth to the world of skeezy javascript malware.

What is the realistic everyday use case for this?

Maybe not a wide use case, but the first thing that comes to mind is for people who work outside an office (law enforcement, for example) to collect data on their device as they do their job, then have a way to upload it into a web app when they return to the office, and not be sending it over a more public network while in the field.

Pairing your phone with your pc for realtime inputs w/o going through internet.

For example https://www.airconsole.com/ turns your phone into a gamepad for multiplayer browser games. But I think they are using web sockets or webrtc right now which is kind of silly when everyone is in the same room looking at the same browser.

Airconsole is awesome and it's a very innovative idea. This will really help them to reduce the data usage.

Not a use case per se but, I think it could be useful in combination with Progressive Web Apps (which can work without an internet connection) to control bluetooth devices without installing an App.

It might be nice if My PC knows my phone is there a notification doesn't need to buzz my phone too.

The physical web - you can now interact with physical devices using your phone (or laptop I guess?) via BLE. Importantly, the devices don't need network connections (which is a pain).

Configuring a Fitbit directly from their website?

Or just uploading fitness data from a device that's not paired with a phone.

It can be used to access a company's own hardware.

You can browse Hacker News with it.

I wonder how much of this is directly related to Google’s game streaming ambitions. Chrome, the browser, is pretty much it’s own os at this point

Gotta say though, the OSification of browsers has been the greatest thing to happen for Linux compatibility. We can talk about efficiency and purity and integration and things but hot damn a decade ago I would have never thought I would be able to run so many apps without any sort of friction.

Does anyone know of something like a search engine for PWAs? I'm kind of intrigued by the new desktop PWA functionality described, but I don't know how to find out which sites I can desktopify. Thanks!

I wonder what the next layer is gonna be after web browsers have completely taken over all operating system functions.

Web workers and service workers are already a new layer of tightened sandboxing on top of the JavaScript sandbox whose volume of sand is soon approximating Sahara.

I like how POSIX is loved and the web is hated.

Guess what, after companies agreed to POSIX, they wisened up. The web is the best cross-platform platform we're ever going to get. Best not because it's amazing, but because everything else will be nipped in the bud by today's crafty multinationals.

It's JavaScript all the way down.

Wait... Windows 10 allows applications to control radios...

So couldn't you go past some site doing a driveby, Chrome get's control of the Bluetooth radio and then the site can just go Bluesnarfing against nearby devices?

Or say have an extension in Chrome that gets control of the radio and you can use the control of the radio and go sniffing for data like I don't know messages or health data sent between phones and smartwatches?

A pity that the classic RFCOMM interface is not supported (at least how I read it).

about://config (ok, chrome://config) is gone

Nothing Bluetooth is in chrome://flags

Google search results are their usual, these days, jumble of largely uselessness.

In the context of a relatively quick search and results skimming, this result is dated 2015 but still seems to be pertinent. It is also the link that is cited in the OP's linked announcement.

https://developers.google.com/web/updates/2015/07/interact-w...

In particular, where it says:

https://developers.google.com/web/updates/2015/07/interact-w...

A "Bluetooth Internals" page is available in Chrome at chrome://bluetooth-internals so that you can inspect everything about nearby Bluetooth devices: status, services, characteristics, and descriptors.

Checking the system I'm on, I'm not hooked up to any Bluetooth devices. I see the Status panel shown in the article, although it's not titled. Nothing else. There are two left-side tab-ish controls that let me switch between "Adapter" and "Devices". Devices shows the headset I was using the other week. It also has a button to "Scan".

Nowhere, a browser-level control to turn this off.

This is not acceptable.

Google et al. are not going to stop. So, we are going to have to rewrite support for these stacks, and/or reconfigure how we run their apps and under what permissions, to cut them off.

OS development (on "free" OS's, at least) is going to have to start assuming that applications the user actually wants and needs to run, can be and are at the same time at least partially hostile.

Or, we just put up with this situation and being relegated to "cattle". I was just at a dairy farm the other week, and they now tag both ears -- so they don't even potentially have to take a step to identify the cow.

This system uses Ubuntu 16.04, so supposedly control of this subsystem is more limited than on e.g. Windows 10. But there's no way I'm "relying" on that, all the more so going forward in time.

We've reverted the title from “Chrome 70 supports Web Bluetooth on Windows 10”, which breaks the guidelines by editorializing.

Reply on news.ycombinator.com