Hacker News new | comments | show | ask | jobs | submit login

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.

Multiplayer gaming is a legitimate use of data channels, but I don't see why it couldn't prompt for permission.

WebRTC folks insist prompts will confuse people and be bad. But ignoring explicit networking settings is good, somehow.

Acceptable default but one should be able to enable prompts as a less-confused user.

There are some really cool uses of webrtc data channels. e.g. https://webtorrent.io/

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!

Simply visiting a link downloads dozens, sometimes hundreds of files without your explicit permissions. It simply uses a different protocol.

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

It's bad that it ignores network settings.

But that's orthogonal to whether it's torrenting. You can torrent while respecting network settings, and without exposing local IPs.

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.

> Visiting a link exposes also a lot on default.

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.

Simply visiting a YouTube link should result in the video to start streaming right away though?

How will you know that a download is desired or not?

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

> Simply visiting a YouTube link should result in the video to start streaming right away though?

I hate that. Is there a reliable way to turn that behavior off?

If you're Firefox user go to 'about:config' and set 'media.autoplay.enabled' to false

To know that arbitrary netcode can run silently on the background of my browser is really surprising. And not in a good way.

https://snapdrop.net is also a cool use of webrtc ;)

Is the wink because of the 502?

No, it's an app of mine and up again. Thanks a lot for telling me it was down!

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"

It was spot on for my phone at 85% and charging

My desktop system is saying the exact same thing.

The page also thinks my system is flat on a table. Close; the screens are, while the tower's on the floor :P

Works quite well on my phone.

Oh so it works on mobile phones then, not laptops.

It made a correct reading for my laptop (Macbook).

More likely, battery detection is just a little broken, like most of the supercharged, application delivery platform, content-powered Web 2.0.

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.

1. https://developer.mozilla.org/en/docs/Web/API/Battery_Status...

2. http://caniuse.com/#search=battery

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact