3 ms·

Uhm, I strongly disagree with making fullscreen https only feature. For WebGL and WebVR community this would be a big step backwards, making browser applicatio

by bd 12y ago

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

shangxiao 12y ago
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.
- JustGotHere 12y ago
  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.
- bd 12y ago
  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.
- TeMPOraL 12y ago
  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.
pjmlp 12y ago
> 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.
TazeTSchnitzel 12y ago
Well, fullscreen wouldn't have to be HTTPS-only, just the permission wouldn't persist for HTTP.
matthewmacleod 12y ago
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?
- quinndupont 12y ago
  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.
  - dragonwriter 12y ago
    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.
    - quinndupont 12y ago
      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.
    - icebraining 12y ago
      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.
elros 12y ago
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.
unreal37 12y ago
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?

by bd 12y ago

shangxiao 12y ago

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.

JustGotHere 12y ago
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.
bd 12y ago
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.
TeMPOraL 12y ago
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.

pjmlp 12y ago

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

TazeTSchnitzel 12y ago

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

matthewmacleod 12y ago

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?

quinndupont 12y ago
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.
- dragonwriter 12y ago
  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.
  - quinndupont 12y ago
    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.
  - icebraining 12y ago
    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.

elros 12y ago

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.

unreal37 12y ago

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?