Hacker News Reader

Comment by bd | Hacker News Reader

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 obviously fake. It doesn't work already with current security tech:

1) browsers ask for fullscreen permission (with big unmissable dialogs)

2) emulated fake layout is very different from real layout (missing all per-user specific browser settings, e.g. bookmarks or extension buttons or any theme customizations, also font rendering looks different)

3) emulated fake browser UI doesn't respond to interactions in the same way as native UI

View on HN

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 article is ignoring that the site can then add https and do that fullscreen attack anyway.

A better solution would be to keep showing a message telling you it has gone fullscreen like browsers currently do.

Yes, that's true. But for people who don't notice changes there isn't much help anyways.

Even much more primitive phishing will still work on them (just think about those "you have virus / clean your computer" ads from past, with images looking like Windows pop-ups, or remember how those "Nigerian prince" scams intentionally use broken English to selectively address more gullible folks).

These new proposed security measures will not help those people much, they can still be phished from within browser tab content rectangle.

Instead these changes will just basically kill whole class of web applications for a benefit of small subset of population phishable enough with fullscreen attacks but immune to content rectangle attacks.

-----

BTW recent Lenovo Superfish fiasco has shown us that in fact you can't even trust native browser security UI elements. Those real UI green locks on https pages can be as misleading as those JS/HTML generated ones.

I would much more prefer browsers to secure me from known rogue certificates attacks than from hypothetical hard-to-pull-off fullscreen phishing attacks.

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.

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.

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.

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.

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.

Well, fullscreen wouldn't have to be HTTPS-only, just the permission wouldn't persist for HTTP.

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?

> For WebGL and WebVR community this would be a big step backwards, making browser applications again second class citizen vs native apps.

They still are. Most of the time someone posts a WebGL demo here, they fail to run on my devices that have no issue with OpenGL ES 3.0 for native applications.

Reply on news.ycombinator.com