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

61–70 of 96 posts

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

#61

Post by ldng »

fpgeek wrote: post #45
ldng wrote: post #22

Earlier quoted context omitted.

Maybe I'm dense but I don't see how requiring HTTPS would solve phishing attacks. To me it falls in the social engineering realm, people clicking link in their mail thay really should not. Having an extra 's' in the URL will not change that. Am I missing the point ?

If I click on https://foobarbaz.com and get phishsed then I know that either foobarbaz.com had something to do with it or certificate verification has been compromised. If I click on http://foobarbaz.com anyone who can successfully mess with that HTTP connection (a much wider universe of attackers that I have less visibility into, especially if I frequently use different networks [home, work, mobile, etc.]) could hav…

The thing is most phising attack don't even bother going that far, some people will click on https://foobazbar.com for a "rightly" crafted mail. HTTPS does not prevent anything here.

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

#62

Post by lambda »

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.

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.

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

#63

Post by ldng »

dchest wrote: post #49
ldng wrote: post #22

Earlier quoted context omitted.

Maybe I'm dense but I don't see how requiring HTTPS would solve phishing attacks. To me it falls in the social engineering realm, people clicking link in their mail thay really should not. Having an extra 's' in the URL will not change that. Am I missing the point ?

Go here and click on the link to BoA website in the side bar: http://en.wikipedia.org/wiki/Bank_of_America Anyone in the middle between you and Wikipedia servers can apply the phishing attack. If you go here: https://en.wikipedia.org/wiki/Bank_of_America Only Wikipedia editors/admins can perform the attack.

That is why I don't click on links to my bank but rather type the URL ;-)

There is so much you can do to help with phising. HTTPS everywhere is not IMHO a solution. It could even lead to a false sense of security. It's more, HTTPS is the tip of the iceberg. Your bank should send a SMS to confirm any potentially litigious action (mine does).

Security is a trade off. Some sites that really need high levels of security (and they are not that many) could say, look, I have HTTPS, you're safe. Errr ... no ... they are some much more you could/should do.

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

#64

Post by icebraining »

ldng wrote: post #60
organsnyder wrote: post #46

Earlier quoted context omitted.

Here's the scenario they're trying to prevent: 1. Bob often views videos on YouTube, so he grants youtube.com permanent access to the fullscreen API. 2. Eve runs an open wifi AP near a coffee shop. The AP includes a proxy server that redirects youtube.com requests to Eve's own server. 3. Bob connects to Eve's AP. When he goes to youtube.com, he instead gets a response from Eve's server, which is designed to imitate a…

Ok. Here I can see the problem. That said, does this happens really that much ? Shouldn't we educate on open wifi instead ? My point is HTTPS has a cost and is a barrier of entry, the trade off isn't always worth it, IMHO.

Open Wifi is not necessarily the problem. An AP with a shared password (99% of them) is also vulnerable, if the attacker also has a password. It's not reasonable to expect people to never use YouTube on public WiFi hotspots.

And the cost of HTTPS is pretty low nowadays. Cloudflare even offers it on their free plan, and it doesn't require you to set it up on your own server.

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

#65

Post by ldng »

TazeTSchnitzel wrote: post #28
ldng wrote: post #22

Earlier quoted context omitted.

Maybe I'm dense but I don't see how requiring HTTPS would solve phishing attacks. To me it falls in the social engineering realm, people clicking link in their mail thay really should not. Having an extra 's' in the URL will not change that. Am I missing the point ?

1) You need to have been approved by a CA to get a TLS certificate 2) If HTTPS is required, MITMing can't be used to take advantage of permissions you've granted to existing sites

1) Expensive for no good reason for 80% of sites out there 2) We agree it is useful in some case. That what makes it hard to go against, because it seems a reasonable objective. The problem is where do you put the limit. I don't "fullscreen" my bank account. To me, forbidding fullscreen on HTTP is quite over the top but fits Google agenda of HTTPSing All The Things.

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

#66

Post by ldng »

icebraining wrote: post #64
ldng wrote: post #60

Earlier quoted context omitted.

Ok. Here I can see the problem. That said, does this happens really that much ? Shouldn't we educate on open wifi instead ? My point is HTTPS has a cost and is a barrier of entry, the trade off isn't always worth it, IMHO.

Open Wifi is not necessarily the problem. An AP with a shared password (99% of them) is also vulnerable, if the attacker also has a password. It's not reasonable to expect people to never use YouTube on public WiFi hotspots. And the cost of HTTPS is pretty low nowadays. Cloudflare even offers it on their free plan, and it doesn't require you to set it up on your own server.

Do you really need to secure Youtube viewing on a public WiFi hotspots ? Unless you want to sell DRM movies, I don't see the need for HTTPS here. Unless you want privacy on a public network. But we're not talking about security anymore.

So you're suggesting trading a potential MitM but an official Cloudflare MitM ? :)

It is not only about a money cost, it is also about a complexity cost and false sense of security. HTTPS is not the be-all and the end-all of security. Just a step to security, if/when you need it.

I'm not arguing HTTPS is not needed. I'm the first to push for when needed. But it is not needed for watching cat videos, sorry.

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

#67

Post by carbocation »

arcatek wrote: post #55
air wrote: post #13

Earlier quoted context omitted.

The intent is to prevent man in the middle -attackers from getting access to those features.

Why would they need the fullscreen access? I could see the interest for cookies or local storage, but fullscreen?

So they can pretend to be your entire browser.

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

#68

Post by nknighthb »

ldng wrote: post #66
icebraining wrote: post #64

Earlier quoted context omitted.

Open Wifi is not necessarily the problem. An AP with a shared password (99% of them) is also vulnerable, if the attacker also has a password. It's not reasonable to expect people to never use YouTube on public WiFi hotspots. And the cost of HTTPS is pretty low nowadays. Cloudflare even offers it on their free plan, and it doesn't require you to set it up on your own server.

Do you really need to secure Youtube viewing on a public WiFi hotspots ? Unless you want to sell DRM movies, I don't see the need for HTTPS here. Unless you want privacy on a public network. But we're not talking about security anymore. So you're suggesting trading a potential MitM but an official Cloudflare MitM ? :) It is not only about a money cost, it is also about a complexity cost and false sense of security. H…

> Do you really need to secure Youtube viewing on a public WiFi hotspots ?

This suggests you did not, in fact, see the problem. The attacker in this scenario is not limited to replacing YouTube videos. They can make anything they want appear on the user's screen, including things like a Google login page, or even a bank login page.

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

#69

Post by dragonwriter »

quinndupont wrote: post #43
matthewmacleod wrote: post #38

Earlier quoted context omitted.

For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps. I don't really understand why this is the case — surely they'd just serve them over HTTPS and be done with it?

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.

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

#70

Post by icebraining »

ldng wrote: post #65
TazeTSchnitzel wrote: post #28

Earlier quoted context omitted.

1) You need to have been approved by a CA to get a TLS certificate 2) If HTTPS is required, MITMing can't be used to take advantage of permissions you've granted to existing sites

1) Expensive for no good reason for 80% of sites out there 2) We agree it is useful in some case. That what makes it hard to go against, because it seems a reasonable objective. The problem is where do you put the limit. I don't "fullscreen" my bank account. To me, forbidding fullscreen on HTTP is quite over the top but fits Google agenda of HTTPSing All The Things.

I don't "fullscreen" my bank account.

They don't want to prevent you from fullscreening on HTTP. They want to prevent websites from fullscreening your browser on their own accord using the Fullscreen API, which is quite different.

HTTPS might be expensive for 80% of the sites, but 80% of sites don't use the Fullscreen API anyway.

Frankly, I think people here should read and understand more carefully what the Chrome team is actually saying before accusing them of nefarious intent (it's fine to accuse them after carefully understanding, of course).

Post reply on HN