Chrome 61 Beta Rolls Out With JavaScript Modules, WebUSB Support

[DrYak]

I fail to see any sabe useful purpose for that kind of shit.

Giving access to USB devices iver the web ?!

WebGL and the like I can understand - might be useful for online games, now that flash is getting phased out.

But generic USB ? Makes no fucking sense ti me.

I would instead work on class devices:
- camera/mike/GPS have already each their own APIs.
- HID class could be improved so that controllers are easier to use with games.

- 2FA over a plain USB link straigh to the wev makes no sense to ne. Instead they should get the existing API working (public key interfaces like keycards, etc. that API is the better target.)

- and for all the weird single use devices (IoT shit like web enabled flower pots), for whitch there is no use to develop a full class and API, micro controllers with minimal WiFi, enabling ad-hoc connections and thus an embed web portal are available.

(as in: connect to the private WiFi network of the device, and open its default webpage in your browser.)

(works better than USB given that most end users will use their smartphones and tablet preferably).

[linuxgeex]

It's a sharing API. It's super simple and there's not a lot you can do with it. Less than with some old browser extensions, in fact.
Most of the more powerful stuff of that particular API has been removed ages ago. Including chat and video functionality.

It's also incredibly transparent. It basically lets the user opt in to every provided Social API provider and then a button is added to the social panel.
Been in Firefox for quite some time already, albeit somewhat hidden (accessible by going to https://activations.cdn.mozilla.net/...harePanel.html)

That doesn't change the fact that with a single unified API (and the promiscuity that it encourages) it becomes much less work to PWN multiple networks and at the same time increases the reach of the attacker by reducing isolation. And here I am talking about the isolation that exists by having users maintain isolated logins between their social media accounts and it being significant work to share among them. The unified API will reduce that work, it will encourage apps that automatically share between networks, and kiss all isolation goodbye. Because the average person is lazy and security is inconvenient.

[linuxgeex]

I fail to see any sabe useful purpose for that kind of shit.

Giving access to USB devices iver the web ?!

WebGL and the like I can understand - might be useful for online games, now that flash is getting phased out.

But generic USB ? Makes no fucking sense ti me.

I would instead work on class devices:
- camera/mike/GPS have already each their own APIs.
- HID class could be improved so that controllers are easier to use with games.

- 2FA over a plain USB link straigh to the wev makes no sense to ne. Instead they should get the existing API working (public key interfaces like keycards, etc. that API is the better target.)

- and for all the weird single use devices (IoT shit like web enabled flower pots), for whitch there is no use to develop a full class and API, micro controllers with minimal WiFi, enabling ad-hoc connections and thus an embed web portal are available.

(as in: connect to the private WiFi network of the device, and open its default webpage in your browser.)

(works better than USB given that most end users will use their smartphones and tablet preferably).

TL;DR - The browser should be treated like a Virtual Machine. If you see Virtualbox having a need for USB, so does a modern browser. End of story.

I disagree. Generic USB over web is a great thing. You or I cannot know what anyone wants to do with a USB device over the web, or whether their use case is valuable enough to warrant the security risk. They need the right to make that decision themselves. Today they already can - they can download an executable that accesses the USB device and exports it to the Web. The hoops they have to jump through? Agree to download a possibly malicious file type, then run it.

It's dead easy to block all device IDs other than a whitelist maintained by the browser vendors, such that any device not already whitelisted will require the user to agree that the site can control the device. Maybe even have a cert exported by the site and the device so that you can receive a device (ie dongle from your bank) and have it automatically read by your browser when a matching cert is presented by the bank's site. Same or superior level of security to the file download method, let the user do it right in the browser, let the developer work directly with the browser. Win Win Win. It could even be implemented in a trusted execution environment with matching OS support so that if the browser is hijacked it still can't access the device inappropriately.

[unixfan2001]

That doesn't change the fact that with a single unified API (and the promiscuity that it encourages) it becomes much less work to PWN multiple networks and at the same time increases the reach of the attacker by reducing isolation. And here I am talking about the isolation that exists by having users maintain isolated logins between their social media accounts and it being significant work to share among them. The unified API will reduce that work, it will encourage apps that automatically share between networks, and kiss all isolation goodbye. Because the average person is lazy and security is inconvenient.

It doesn't do any such thing.
You still have separate logins and every social network still runs in its own sandbox.

If this was even inherently an issue, you'd see a lot more "pwning" on iOS and Android.

[linuxgeex]

It doesn't do any such thing.
You still have separate logins and every social network still runs in its own sandbox.

If this was even inherently an issue, you'd see a lot more "pwning" on iOS and Android.

So you're saying this API isn't going to make cross-posting (one service receiving content from another service for the one user's two distinct accounts) easier? Well then, silly me.

[unixfan2001]

So you're saying this API isn't going to make cross-posting (one service receiving content from another service for the one user's two distinct accounts) easier? Well then, silly me.

No, that's definitely not its use nor is it the case in practice.
What it does is merely register an endpoint to a specific social network/service and present the end-user with a sharing UI.

Say you, as a user, register for the Facebook social API. A "Share on Facebook" button is added to your browser chrome and, upon clicking it, a panel embedding the "Share on Facebook" web UI is opened (separate login and all), referencing the URL of your currently open tab and providing a screenshot of it.

That API only works on regular websites, too. No privileged/extension pages or the browser chrome itself.

[linuxgeex]

No, that's definitely not its use nor is it the case in practice.
What it does is merely register an endpoint to a specific social network/service and present the end-user with a sharing UI.

Say you, as a user, register for the Facebook social API. A "Share on Facebook" button is added to your browser chrome and, upon clicking it, a panel embedding the "Share on Facebook" web UI is opened (separate login and all), referencing the URL of your currently open tab and providing a screenshot of it.

That API only works on regular websites, too. No privileged/extension pages or the browser chrome itself.

But it's still going to save auth tokens for the many social media networks within the browser, so that any arbitrary code exploit will have access to those tokens and be able to do exactly what I'm talking about, unless those tokens are issued by the social media networks with post-only permissions. So it could be less bad than I originally thought. ;-)

Yes I know most users are leaving live login sessions for all their social networks in their browsers already, but again those are heterogenous auth stacks and therefore a bit more work to pwn all of them.

[starshipeleven]

But it's still going to save auth tokens for the many social media networks within the browser, so that any arbitrary code exploit will have access to those tokens and be able to do exactly what I'm talking about, unless those tokens are issued by the social media networks with post-only permissions. So it could be less bad than I originally thought. ;-)

Yes I know most users are leaving live login sessions for all their social networks in their browsers already, but again those are heterogenous auth stacks and therefore a bit more work to pwn all of them.

isn't the fact that browsers spawn a thread for each page (chrome or firefox with e10 enabled) going to make it harder?

Or there is only one process handling auth for all threads?

[linuxgeex]

isn't the fact that browsers spawn a thread for each page (chrome or firefox with e10 enabled) going to make it harder?

Or there is only one process handling auth for all threads?

In google-chrome there's some isolation by default. See the Chromium Process Models re "--process-per-tab" and the other related command-line switches and you'll get a taste for the isolation decisions that chrome makes. Firefox has no isolation yet but they're working on it. Long story short, no there is no reliable isolation, even in Chrome, even though they flaunted process isolation heavily some years ago. They don't flaunt it any more because they aren't actually doing it... mostly because they would need to spawn a dozen or more processes per tab (parser, script, render, compilers, plugins) to do it properly. The best way to get proper isolation in Chrome is to start it with a different "--user-data-dir=X" for each separate web site, which then gives you the same isolation that Firefox does with "--no-remote --profile X"

Also, this may come as a shock, something neither vendor warns you about is that if you start each site in a Private/Incognito window - these "private" windows are run in a shared process space, and with shared cookie/cache/webworker/localStorage etc.

For an example, open a new Incognito window and open this HTML5 Halma game. Play a few moves then create another new Incognito window and open the same link in it. See how you are instantly recognised in the supposedly "private" window. And if you think about it for a second, this has to be the case or popups with shared session state would be impossible, so I'm not complaining, just pointing it out so people are aware.

Again the per-site process isolation that Chrome offers still runs frames for different sites in the same process space as the site in the location bar. That means that the ad iframes and social media buttons on sites today are all running in the same address space as the site you might think they are isolated from, and many sites can share CDN script repos such as cdnjs, googleapis,etc. Any entity which can spoof the SSL certs of those sites can MITM you without your knowledge, PWN your sessions, and hijack one from another, without leveraging any exploits in your browser whatsoever. Who can spoof those certs? NSA and DOD at the very least - anyone who can get their hands on a root CA cert that's recognised by your browser. Major issuers have had leaks, ie DigiNotar, C.O.M.O.D.O, StartCOM/WoSign...

Sorry I'm digressing but seriously, people fail to recognise what a security nightmare this all is to begin with. There's a little lock on the location bar and it makes people feel all fuzzy and warm but it only protects you from highly-un-organized crime.