You're assuming that the attacker either 1) controls Chrome's sourcecode so fully that they can modify it and nobody else will review the change and/or 2) this new api will introduce a security bug.

#1 is a possibility for every single piece of hardware and software that we interact with. There is nothing that makes Chrome more vulnerable, other than being a higher profile target. That's countered by higher levels of scrutiny from the whitehat community and Google themselves.

#2 applies to any feature that they add. There is nothing special about a Bluetooth API. We're already trusting browsers to handle stuff far more sensitive than this. Chrome is one of the most thoroughly tested, hardened, and sandboxed pieces of software there is. If it's not provided by the browser (which has essentially replaced the OS these days in terms of running 3rd party code) then we have to trust some 3rd party extension to do the device interaction, and to do it with the level of security that Chrome would. Sorry, but I don't see that as any better or likely. Whether it's the Chrome app on a mobile phone, or Chrome on the desktop, this will make working with Bluetooth much easier, while keeping things as safe as can be reasonably expected.

I'm sorry, but it sounds like you realize your whole comment is a slippery slope argument, but not that that is a logical fallacy. The permission request is there -- just like there's a request in every browser before for sharing your location -- because it isn't always appropriate to share personal data with untrusted sites.

I don't understand this literacy laziness. It feels like most of the people here are willfully blind. In the very same section you're referring to, it says: "Google Chrome will prompt user with a device chooser where they can pick one device or simply cancel the request." That's the browser doing that. The website you're on doesn't suddenly now trivially have permission to scan all available devices. It's the browser -- the app you're already trusting with the passwords for all the sites you access -- doing the scan.

Is this even a tech blog anymore? These assumptions about privacy loss only make sense if you haven't done even the most trivial reading of the spec. The docs are here: https://developers.google.com/... A site can request to connect to a bluetooth device. Chrome prompts the user for which one (or none), and the website can then interact with the selected device. I did less than a minute's worth of research. It's even mentioned in the article, but then the article just goes on to assume that the user has granted permission to the page to access every device they have somehow. Maybe I've missed something, but nobody seems to be talking about the actual implementation.

I recently discovered the nice work they did on their Android apps (finance & weather). I had completely written Yahoo! off before then. If they keep that up, they might get some traction from them. (It even got me to sign in to my old account)

citation?

Wouldn't the C to C++ rewrite be considered a derivative work, and thus be covered by copyright?

You can also turn on the tinyurl preview feature. http://tinyurl.com/preview.php

Does the shim actually get around the requirements of the GPLv2? To my knowledge that hasn't been officially determined.

The hobbling of the phone OS is optional:

http://bits.blogs.nytimes.com/2007/11/27/verizon-wireless-says-bring-your-own-device/

(Article from 2 years ago)

I remember reading something about this a while ago, but I forgot: what did KDE do wrong?

Re: You probably meant 0.25 ^ 5.

So according to you, if he makes 25% over 5 years, then he makes 0.09765625%... and then when he keeps the same pace up for 5 more years, he makes 0.25^10, which is 0.000095367431640625%.. riiiight