Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink - Intent to deprecate: Insecure usage of powerful features

groups.google.com

Post reply on HN
Print view View original

71–80 of 96 posts

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#71

Post by pornel »

Danilka wrote: post #14

What is going to be the protocol for development environment? Should one deal with ssl just to quickly test out the code? What if a service streams video, which requires full screen feature? It takes quite a bit more compute power to pack it into encrypted connection, and what if the video is not of any value as a secure content. Why should people be forced to encrypt and decrypt spending extra power (battery, in cas…

DevTools can whitelist dev domains: https://w3c.github.io/webappsec/specs/powerfulfeatures/#deve...

> What if a service streams video; […] spending extra power (battery, in case of portable devices)

Then they'll encrypt, because it's cheap. YouTube could do it. Only Netflix is making a fuss because they want to legitimize their DRM as a security layer.

It's not 1995 any more. Today even low-end cell phones are orders of magnitude faster than CPUs were when SSL was slow. We've got fast ciphers and hardware-accelerated decoding.

https://istlsfastyet.com/

> SSL does not guarantee the security de-facto.

The problem is that HTTP is de-facto guaranteeing insecurity.

• HTTPS is the new HTTP.

• HTTPS+HSTS+preloaded pinning is the new HTTPS.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#72

Post by spankalee »

lambda wrote: post #62
kevincennis wrote: post #40

Earlier quoted context omitted.

I view EME as sort of a necessary evil. There was never any chance that large content companies were going to be okay with serving unencrypted media over HTTP. So the choices were: 1. No major film or television content on the web 2. The survival of Flash/Silverlight 3. EME I'm not crazy about any of those choices, but #3 seems the most reasonable.

Between these options, 1 seems the most reasonable to me. I refuse to play along with anyone who thinks that they need to hijack my computer in order to sell me content. They want my money, they can sell me DRM free content.

Then don't use EME, it's that simple.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#73

Post by icebraining »

dragonwriter wrote: post #69
quinndupont wrote: post #43

Earlier quoted context omitted.

This would work, but I think the issue is that there's an unacknowledged reversal of thinking going on here: HTTPS is the "norm", and HTTP is the aberrant case. The commenter doesn't seem to agree with this reversal, or hasn't realized that it is occurring.

I personally disagree with it -- I think its fine in outline, but should be configurable so that HTTP internal to a controlled network, as specified by the user (or, perhaps more accurately, administrator) can be treated as trusted. Once that is established, enabling/disabling features based on connection trust makes sense; but I don't like the rush to do so on protocol alone.

On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? You don't need a paid cert, just to run a couple of openssl commands.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#74

Post by dragonwriter »

icebraining wrote: post #73
dragonwriter wrote: post #69

Earlier quoted context omitted.

I personally disagree with it -- I think its fine in outline, but should be configurable so that HTTP internal to a controlled network, as specified by the user (or, perhaps more accurately, administrator) can be treated as trusted. Once that is established, enabling/disabling features based on connection trust makes sense; but I don't like the rush to do so on protocol alone.

On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? You don't need a paid cert, just to run a couple of openssl commands.

> On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP?

Why should we accept the browser forcing internal networks to bear the technology costs (if not the additional financial/administrative costs) of securing for the public internet? Especially for services that might need to communicate with things other than browsers and might not want the overhead.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#75

Post by icebraining »

dragonwriter wrote: post #74
icebraining wrote: post #73

Earlier quoted context omitted.

On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? You don't need a paid cert, just to run a couple of openssl commands.

> On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? Why should we accept the browser forcing internal networks to bear the technology costs (if not the additional financial/administrative costs) of securing for the public internet? Especially for services that might need to communicate with things other than browsers and might not want the overhead.

Why should we accept the browser forcing internal networks to bear the technology costs (if not the additional financial/administrative costs) of securing for the public internet?

You shouldn't. Feel free to not those browsers.

Especially for services that might need to communicate with things other than browsers and might not want the overhead.

If you're not communicating with a browser - don't use HTTPS. It's not like you're prevented from supporting both protocols.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#76

Post by quinndupont »

dragonwriter wrote: post #69
quinndupont wrote: post #43

Earlier quoted context omitted.

This would work, but I think the issue is that there's an unacknowledged reversal of thinking going on here: HTTPS is the "norm", and HTTP is the aberrant case. The commenter doesn't seem to agree with this reversal, or hasn't realized that it is occurring.

I personally disagree with it -- I think its fine in outline, but should be configurable so that HTTP internal to a controlled network, as specified by the user (or, perhaps more accurately, administrator) can be treated as trusted. Once that is established, enabling/disabling features based on connection trust makes sense; but I don't like the rush to do so on protocol alone.

I agree with you. To anyone who's been paying attention there's a pretty palpable recent rush to encrypt everything (largely as a response to the Snowden revelations). There should be a genuine debate about the implications on social, political, ethical, and technological levels, but instead we only hear about the bogeymen of NSA spying (although, this is a legitimate concern). I'm a strong advocate of cryptography, but I think we need to come up with a way to speak meaningfully about it, instead of just rushing to encapsulate all human expression within cryptography.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#77

Post by unreal37 »

bd wrote: post #20

Uhm, I strongly disagree with making fullscreen https only feature. For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps. And it's not like there aren't already strong enough protections in place. Try for example visiting this mock attack site: http://feross.org/html5-fullscreen-api-attack/ In every browser I tried it was already obvio…

I didn't get that impression from the mailing list post. They were exploring ways of adding more security depending on context. That's a long way from "https only feature". Perhaps the user just needs to acknowledge the switch (instead of just being notified of it)? Or set a browser flag to override?

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#78

Post by unreal37 »

organsnyder wrote: post #44
vertex-four wrote: post #37

Earlier quoted context omitted.

> Copyright enforcement should be left to law You would prefer that all copyright violation is a criminal matter rather than a civil one?

"Law" isn't limited to criminal cases. Nothing in the poster's statement precluded a law suit from being an enforcement mechanism.

But that's the way it currently is. And so little 12-year-old Janie gets a $3,000 "demand to pay" letter for downloading a Britney Spears song with the threat of a lawsuit that will take her family's house away if she refuses. Maybe having a somewhat impartial legal entity in between is more protection for the consumer.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#79

Post by TeMPOraL »

shangxiao wrote: post #23
bd wrote: post #20

Uhm, I strongly disagree with making fullscreen https only feature. For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps. And it's not like there aren't already strong enough protections in place. Try for example visiting this mock attack site: http://feross.org/html5-fullscreen-api-attack/ In every browser I tried it was already obvio…

The point of that article was that people don't notice subtle changes, especially when their not tech savvy/tired after a long day of work/whatever. Also someone pointed out in the comments that some people tend to ignore changes and click on whatever to get to their destination.

And that's one of the reasons webapps will be always second-class citizens vs. native apps - because browsers have to limit tons of useful features to keep users protected from various attacks.

Re: Blink - Intent to deprecate: Insecure usage of powerful features

#80

Post by aikah »

kevincennis wrote: post #40
jpgvm wrote: post #9

Though only tangentially related I do wish EME had been properly shot in the head. It's just another Flash that hides behind being "html5" (as if they makes it all ok). At the end of the day it's proprietary code executing on my machine that I have little or no control over. It's not just a security risk, it's also a stability concern and generally a terrible idea. Copyright enforcement should be left to law, content…

I view EME as sort of a necessary evil. There was never any chance that large content companies were going to be okay with serving unencrypted media over HTTP. So the choices were: 1. No major film or television content on the web 2. The survival of Flash/Silverlight 3. EME I'm not crazy about any of those choices, but #3 seems the most reasonable.

I believe the W3C is an open standard consortium. What Big Entertainment wants to do is none of its concern.Let them use a plugin,there is already an interface for that. EME isn't different from a plugin, that's what you don't understand.I does less sure,but it still relies on something people will have to install on their computer, or even worse, encryption at the hardware level.
Post reply on HN