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

41–50 of 96 posts

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

#41

Post by organsnyder »

RyanMcGreal wrote: post #39
thomasfoster96 wrote: post #2

Once Let's Ecrypt [0] launches, I suppose most web developers won't have any more excuses not to use HTTPS. It'll be free, pretty easy and quick time wise, plus it'll give you an SEO boost. Browser vendors are certainly doing the right thing by making http be marked as non-secure, and not implementing unencrypted http/2 and not allowing non-HTTPS access to powerful api are completely reasonable steps to take. [0] htt…

How will Let's Encrypt be different/better than a StartSSL Free certificate?

I used to use StartSSL, but abandoned it for a few reasons:

1. Their user interface is slow and clunky. Acquiring/renewing certificates is a PITA.

2. For organizations, they require both extended personal validation and organizational validation. In addition to being fairly expensive ($100 annually, each), they require you to send images of a bunch of sensitive personal documents (passport, credit card, etc.). While you can often slip by and get certs without them realizing you're getting them for an organization, once they've noticed and flagged your account, each cert requires manual review.

3. Their website hasn't been updated in a number of years. They do not give the impression of being a healthy company.

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

#42

Post by organsnyder »

TazeTSchnitzel wrote: post #36
thomasfoster96 wrote: post #32

Earlier quoted context omitted.

Reading through the W3C draft linked to in the announcement, localhost over HTTP will be considered probably secure.

Make sense: if you can run a web server, you don't need the browser's help to do a phishing attack.

Not necessarily. Any user could run a web server on an unprivileged port. While this is a far-fetched scenario—it requires the attacker having access to a different user's account on the machine, but not the victim's (if they had access to the victim's account, they wouldn't need to take these measures)—it is possible.

The only solution is to restrict privileged status to privileged ports. However, that would also limit the usefulness of the exception, since dev servers usually run on unprivileged ports (that could be changed, of course).

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

#43

Post by quinndupont »

matthewmacleod wrote: post #38
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…

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.

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

#44

Post by organsnyder »

vertex-four wrote: post #37
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…

> 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 lawsuit from being an enforcement mechanism.

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

#45

Post by fpgeek »

ldng wrote: post #22
fpgeek wrote: post #6

Earlier quoted context omitted.

Did you even look at the kinds of attacks that motivate these restrictions before concluding that there was a nefarious agenda at work? I took a look at a Fullscreen API attack ( http://feross.org/html5-fullscreen-api-attack/ ) and found it pretty creepy even though I knew exactly what to expect and what to look for. Tighter controls over that sort of thing seem like a great idea to me.

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 have been responsible.

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

#46

Post by organsnyder »

ldng wrote: post #22
fpgeek wrote: post #6

Earlier quoted context omitted.

Did you even look at the kinds of attacks that motivate these restrictions before concluding that there was a nefarious agenda at work? I took a look at a Fullscreen API attack ( http://feross.org/html5-fullscreen-api-attack/ ) and found it pretty creepy even though I knew exactly what to expect and what to look for. Tighter controls over that sort of thing seem like a great idea to me.

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 ?

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 full desktop environment. Since Bob has already given youtube.com access to the fullscreen API, the browser grants Eve's site fullscreen rights without notifying Bob.

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

#47

Post by icebraining »

RyanMcGreal wrote: post #39
thomasfoster96 wrote: post #2

Once Let's Ecrypt [0] launches, I suppose most web developers won't have any more excuses not to use HTTPS. It'll be free, pretty easy and quick time wise, plus it'll give you an SEO boost. Browser vendors are certainly doing the right thing by making http be marked as non-secure, and not implementing unencrypted http/2 and not allowing non-HTTPS access to powerful api are completely reasonable steps to take. [0] htt…

How will Let's Encrypt be different/better than a StartSSL Free certificate?

Free certificate revocations. StartSSL was crucified for charging $25 for revocations, and not waiving the fee during Heartbleed.

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

#48

Post by userbinator »

fpgeek wrote: post #6
jbb555 wrote: post #3

Basically they are destroying the simplicity of the internet in order to push their own agenda. I'd get annoyed about it, but it's not going to be long before it all collapses under it's own weight and something new and lightweight turns up to take over from what http used to be good for.

Did you even look at the kinds of attacks that motivate these restrictions before concluding that there was a nefarious agenda at work? I took a look at a Fullscreen API attack ( http://feross.org/html5-fullscreen-api-attack/ ) and found it pretty creepy even though I knew exactly what to expect and what to look for. Tighter controls over that sort of thing seem like a great idea to me.

Memories of receiving tons of full-screen popup and popunder ads (and without any close buttons, address bars, or any other browser controls... thankfully I knew what Alt+F4 did at the time!) may have biased me a bit... but I think the fullscreen API is a bad idea in general - the browser should not allow scripts to do things that modify the UI outside of the content area of the page. If the user wants to resize the content area, he/she should do that through the facilities the OS window manager already provides.

Besides, a similar attack could be carried out even without the fullscreen API - just replace the page contents when the link is clicked, and the same people who don't notice the changes in UI will probably not notice the address bar either (it also doesn't help that browsers are attempting to deemphasise/hide the URL...)

If they wanted "tighter controls", they should just remove the fullscreen API. I guess a lot of web developers won't like it, but the user has always had the ability to fullscreen the browser if he/she wanted to.

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

#49

Post by dchest »

ldng wrote: post #22
fpgeek wrote: post #6

Earlier quoted context omitted.

Did you even look at the kinds of attacks that motivate these restrictions before concluding that there was a nefarious agenda at work? I took a look at a Fullscreen API attack ( http://feross.org/html5-fullscreen-api-attack/ ) and found it pretty creepy even though I knew exactly what to expect and what to look for. Tighter controls over that sort of thing seem like a great idea to me.

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.

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

#50

Post by elros »

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 guess that's why it's just a proof of concept. Also, those three points you raise would certainly deter you and me from being caught, but e.g. my father (in his early 50s), who uses Word, Internet Banking, Email, pretty much the same way for 20 years and does not understand, for example, the concept of a "folder", he would assume the computer is displaying normal behaviour, because he doesn't have the knowledge to assume otherwise.

"Fake UI" or "user-specific browser settings", "font rendering", are things that don't even (make sense/matter/seem odd) to him.

Ironically, my great-aunt, who's almost 90 but was always somewhat of a "techie", would notice something weird and call me or her son.

But I guess my point still stands.

Post reply on HN