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.
