Not sure why battery is exposed; I guess that's the result of making browsers more like OSes.
The only really annoying thing is the idiotic WebRTC settings. Their love for "data channels" with zero prompts, despite having no legitimate uses[1], ignores your proxy settings. This should be fixed.
1: I asked someone involved with WebRTC. They suggested "maybe a page wants to communicate with your fridge directly" as a serious use of WebRTC data channels.
Yeah, and that's also a great example of what should NOT be allowed without the user's EXPLICIT permission - simply visiting a link should not result in a torrent download!
No, it doesn't just use a different protocol. It ignores your network settings (proxy) and exposes your local network information.
I can understand not wanting to scare people with "Allow P2P Data Channel", but ignoring proxy settings and revealing all IPs is unacceptable. WebRTC folks toss off these concerns with "there's no way to prevent tracking so heh".
Visiting a link exposes also a lot on default. Browser, OS, Resolution. The major browsers are not build for this needs. Best experience first. BTW: There are extensions to block webrtc ip leak.
We should be reducing the amount of data exposed and fixing the mistakes of the past that allowed so much data to be easily exfiltrated.
> Best experience first.
"Best" is not a defined term. What software developers should (always) be providing is the safest method first. Fancy UI tricks are a far lower priority than safety. If there is any doubt, fail safely.
Anybody that isn't putting safety first is being incredibly irresponsible. Stop leaking data and design for safety and security first. Yes, this it will be harder to make a nice user experience. In time, this will improve, but in the meantime safety is not something that can simply be ignored.
> extensions
Safety is not an optional feature that only some people should have.
<video> tags are a more standardized part of the web. Although I should be able to disable auto-buffering as well as auto-play.
Ideally the user can control whether all types of content get loaded—images, CSS, JavaScript, web fonts—or even allow/deny individual domains or files, but so far browsers require an extension like uMatrix for that.
The fact that some browsers do allow you to control these things, even if you have to use an extension because they don't support it themselves, is crucially important and totally acceptable. AFAIK there is nothing equivalent to NoScript for IE, however, so that's just one of many reasons I don't use it.
I don't really mind the trend in browsers over the last several years to give explicit access to more OS resources, it frees us from both Flash and Java Applets, Adobe's PDF reader, and other crap. But I'm not sure the browser replacements, at least in the short term, will actually get the security models any better. Is there any reason to prefer all these new JS APIs over allowing a Java Applet, besides "Java Applets are insecure"? It's certainly not performance -- I know many people chuckle when someone demos the latest X in JS (with or without WebGL) where X was done better with less hardware years ago via an applet. Secure or not, it's incredibly difficult to actually run an applet these days, and it's a strange disconnect with how the browser is fine doing so much else without warning. Will we see a similar increase in difficulty for running JS that can be just as insecure?
I've been a NoScript and adblock advocate for many years, but the first is often met with alien stares and the second is only successful when I install it on their browser myself or when I'm recommending adblocking to either other technical people or people who really hate ads even on TV. There's a weird resistance some people have that can get brought up in both cases, though, and it's probably going to take more than a few big public fails due to malicious websites before people will stop bringing it up. The argument adblocking users have been making for ages: this is my computer, my browser, and neither is under any obligation to act in a particular way based on the contents of what your server sends me. I don't like your ads? I can choose not to see them. I don't trust your JS? I can choose not to execute it. I don't like your theme? I can load my own. It's very weird to me that people oppose this view.
Do you use NoScript in everyday? I think while it would make those annoying APIs go away, the web site experience would became a bit poor and even not work properly.
I'ts funny with WebRTC, because I rememeber when the same could be accomplish with Java applets (Java ignored any proxy settings, which allowed to deanonynimize people on the internet, e.g. it no longer mattered if you were behind TOR if you had Java enabled). I think it was considered security bug and was patched later. Seems that WebRTC people are not so security-wise I suppose...
I am not sure if this battery is not just FUD and some other sections as well. Because I currently have no battery in my laptop (no battery detected) and site is saying "Charging: charging", "Battery level: 100%", "Charging time: 0h"
Just like with mobile apps, battery info can help websites decide whether they should run a complex operation now. It also helps detect regressions if a commit happens to suck power faster. Unfortunately, it's more bits available to deanonymize users across websites.
Data channels are useful for synchronizing your phone and your laptop. All native platforms support this. Most websites do it with a roundtrip to the server. So it would be mysterious to the user why a permission is prompted for something that should just work. Obviously it's bad for privacy though.
So painting it as having no legitimate uses is a bit one-sided. There is no easy fix.
What websites do CPU-intensive work that can be delayed for hours?
In general I want a website to suck as much power as possible so it can be done sucking power as soon as possible, whether I'm on battery or not. If you want to find waste, track execution time and bandwidth use.
I'm not sure I understand your point. Many apps (would) benefit from delaying some tasks and waiting to be on charge and a wifi connection. Typically, synchronization for example requires the device to be awake for a long period because of network roundtrips, transfers, disk seeks and CPU work. Software updates are similarly impactful on the battery.
At least, it makes sense to measure battery usage to optimize your code. And in my opinion, it's also beneficial to react to battery events (delay when on low battery, process when on a wall socket) and network events (bad coverage vs. strong wifi).
Battery levels are exposed in the Battery Status API [1] which is currently implemented on Firefox and Chrome, both desktop and Android editions [2] but not on iOS.
The only really annoying thing is the idiotic WebRTC settings. Their love for "data channels" with zero prompts, despite having no legitimate uses[1], ignores your proxy settings. This should be fixed.
1: I asked someone involved with WebRTC. They suggested "maybe a page wants to communicate with your fridge directly" as a serious use of WebRTC data channels.