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