Re: full screen api
On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch pya...@gmail.com wrote: There was a limited discussion on that a few days ago with the limited consensus (?) being that requiring user-consent up front before switching to fullscreen is desired, should be in the standard and isn't sacrificing UX. There was no implementor involved in that discussion. I want to see their feedback before changing the standard. Also, FYI, http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html is not maintained, http://fullscreen.spec.whatwg.org/ is. -- http://annevankesteren.nl/
Re: [XHR] Open issue: allow setting User-Agent?
I came across an article [1] that describes some of the reasoning for Flash's change in security policy when it banned setting User-Agent. Apparently, some sites echo the User-Agent value back in markup in certain contexts (maybe a browser requirements page for example). Being able to set User-Agent from web content thus might cause XSS issues for such pages. These backends never had any reason to filter the User-Agent string before, so they probably don't. Obviously, any XSS-injected scripts would not run as a result of simply loading the content with XHR (or Flash) - scripts in the response are not executed unless more steps are taken like jQuery's global eval taking SCRIPT tags from received markup and inserting them into the page. However, another threat might be using an XHR request to put a generated page with injected content in the browser's cache, then opening the page directly in a new window. The page would likely be taken from cache, and the XSS would be successful. So it seems reasonable to keep the limitation on setting User-Agent. (I'm still wondering if we could lift it only for the cross-domain case where the target site must opt in to receiving a changed UA string though..) [1] http://www.securityfocus.com/archive/1/441014
Defenses against phishing via the fullscreen api (was Re: full screen api)
On Oct 13, 2012, at 1:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 12, 2012 at 8:25 PM, Florian Bösch pya...@gmail.com wrote: There was a limited discussion on that a few days ago with the limited consensus (?) being that requiring user-consent up front before switching to fullscreen is desired, should be in the standard and isn't sacrificing UX. There was no implementor involved in that discussion. I want to see their feedback before changing the standard. Also, FYI, http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html is not maintained, http://fullscreen.spec.whatwg.org/ is. I think it's unlikely that Apple would implement a requirement of prior user consent before entering fullscreen. I also personally think OK/Cancel security nag dialogs are a very poor security mechanism in general. Users do not read them, and placing them in the path of operations that are harmless the vast majority of the time only has the effect of training users to click ok on dialogs. Cancel or allow dialogs are nearly useless for real security and seem mainly to provide CYA security - if a user gets hacked, you can tell them they were bad for clicking OK on the dialog. Now, there are some limited cases where a permissions dialog may make sense. Specifically, these are cases where the user can reasonably be expected to relate the risk to the functionality requested. For example, when a site asks for your geolocation, a user can generally understand that there may be privacy implications to having a location tracked. But this does not really apply to fullscreen. A user is not likely to understand the security implications of fullscreen. So they won't be able to make a reasoned risk assessment based on a warning dialog. This situation is much like bad certificate warnings, where the evidence indicates that users almost always click through, even relatively informed users. I think the most effective defense against phishing via fullscreen is to prevent keyboard access. The original design for requestFullscreen had an optional argument for requesting keyboard access, which led to a warning in some browsers and which for Safari we chose to ignore as the risk outweighed the benefit. The new spec does not have this parameter and makes no mention of keyboard access. It is not even clear if refusing to send key events or grant keyboard focus in fullscreen would be conforming. I think this should be fixed. I think the spec should at minimum explicitly allow browsers to block delivery of key events (or at least key events for alphanumeric keys). Regrettably, this defense would not be very effective on pure touchscreen devices, since there is no physical keyboard and the soft keyboard can likely be convincingly faked with HTML. The second most effective defense that I can think of is a distinctive visible indicator that prevents convincingly faking the system UI. The common notification to press escape to exit partly serves that purpose. A potentially more effective version would be to show a noticeable visible indicator every time the user moves the mouse, presses a key, or registers a tap on a touchscreen. Ideally this would cover key areas needed to fake a real browser UI such as where the toolbar and address bar would go, and would indicate what site is showing the fullscreen UI. However, while such an effect is reasonable for fullscreen video (where the user will mostly watch without interacting), it might be distracting for fullscreen games, or the fullscreen mode of a presentation program, or a fullscreen editor. Despite both of these defenses having drawbacks, I think it is wise for implementations to implement at least one of them. I think the spec should explicitly permit implementations to apply either or both of these limitations, and should discuss their pros and cons in the Security Considerations section. Regards, Maciej
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com wrote: I think the most effective defense against phishing via fullscreen is to prevent keyboard access. The original design for requestFullscreen had an optional argument for requesting keyboard access, which led to a warning in some browsers and which for Safari we chose to ignore as the risk outweighed the benefit. The new spec does not have this parameter and makes no mention of keyboard access. It is not even clear if refusing to send key events or grant keyboard focus in fullscreen would be conforming. I think this should be fixed. I think the spec should at minimum explicitly allow browsers to block delivery of key events (or at least key events for alphanumeric keys). Regrettably, this defense would not be very effective on pure touchscreen devices, since there is no physical keyboard and the soft keyboard can likely be convincingly faked with HTML. I've got no objection against a user poll for things like keyboard interactions in fullscreen as long as the implemention honors the intent to show this once for a session or remembered state and not all the time when going back and forth. The second most effective defense that I can think of is a distinctive visible indicator that prevents convincingly faking the system UI. The common notification to press escape to exit partly serves that purpose. A potentially more effective version would be to show a noticeable visible indicator every time the user moves the mouse, presses a key, or registers a tap on a touchscreen. Ideally this would cover key areas needed to fake a real browser UI such as where the toolbar and address bar would go, and would indicate what site is showing the fullscreen UI. However, while such an effect is reasonable for fullscreen video (where the user will mostly watch without interacting), it might be distracting for fullscreen games, or the fullscreen mode of a presentation program, or a fullscreen editor Such a scheme would render fullscreen virtually useless for most of its intended purpose.
Re: [XHR] Open issue: allow setting User-Agent?
On 10/13/12 5:08 AM, Hallvord R. M. Steen wrote: I came across an article [1] that describes some of the reasoning for Flash's change in security policy when it banned setting User-Agent. Apparently, some sites echo the User-Agent value back in markup in certain contexts (maybe a browser requirements page for example). And naturally do not send Vary: User-Agent? However, another threat might be using an XHR request to put a generated page with injected content in the browser's cache, then opening the page directly in a new window. The page would likely be taken from cache This seems simple enough to deal with on the browser side: Assume Vary: User-Agent on all requests. Probably a good idea anyway. -Boris
URL work in HTML 5
I know there are a lot of private conversations about this, but I'd like to try, in the time frame of the next W3C TPAC and IETF meetings, to work out a solution to the issue of forking the URL specifications. Does everyone know what the issues are? Is everyone willing to talk about solutions? I think forking is harmful and unnecessary. Bcc: public-ietf-...@w3.org IETF W3C Liaison public-webapps@w3.org W3C Web Applications group chartered to work on something in W3C URL releated www-...@w3.org W3C Technical Architecture Group, since we discussed it public-...@w3.org mailing list of IETF IRI working group, responsible for IRI spec Did I leave anyone out? Larry -- http://larry.masinter.net
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Oct 13, 2012, at 4:58 AM, Florian Bösch pya...@gmail.com wrote: On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com wrote: I think the most effective defense against phishing via fullscreen is to prevent keyboard access. The original design for requestFullscreen had an optional argument for requesting keyboard access, which led to a warning in some browsers and which for Safari we chose to ignore as the risk outweighed the benefit. The new spec does not have this parameter and makes no mention of keyboard access. It is not even clear if refusing to send key events or grant keyboard focus in fullscreen would be conforming. I think this should be fixed. I think the spec should at minimum explicitly allow browsers to block delivery of key events (or at least key events for alphanumeric keys). Regrettably, this defense would not be very effective on pure touchscreen devices, since there is no physical keyboard and the soft keyboard can likely be convincingly faked with HTML. I've got no objection against a user poll for things like keyboard interactions in fullscreen as long as the implemention honors the intent to show this once for a session or remembered state and not all the time when going back and forth. Our current intended behavior in Safari is to never allow alphanumeric keyboard access in fullscreen. No cancel/allow prompt. Did you read the part where I explained why such prompts are useless for security? The second most effective defense that I can think of is a distinctive visible indicator that prevents convincingly faking the system UI. The common notification to press escape to exit partly serves that purpose. A potentially more effective version would be to show a noticeable visible indicator every time the user moves the mouse, presses a key, or registers a tap on a touchscreen. Ideally this would cover key areas needed to fake a real browser UI such as where the toolbar and address bar would go, and would indicate what site is showing the fullscreen UI. However, while such an effect is reasonable for fullscreen video (where the user will mostly watch without interacting), it might be distracting for fullscreen games, or the fullscreen mode of a presentation program, or a fullscreen editor Such a scheme would render fullscreen virtually useless for most of its intended purpose. That depends on what you think most of its intended purpose is. Many native video fullscreen implementations already have behavior somewhat like this, because they expect that the user is not producing UI events most of the time while watching the video. It may be annoying in the context of a game or slideshow. So far I have encountered such uses much less often than video. Regards, Maciej
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
You're making fullscreen useless for games. On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 13, 2012, at 4:58 AM, Florian Bösch pya...@gmail.com wrote: On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com wrote: I think the most effective defense against phishing via fullscreen is to prevent keyboard access. The original design for requestFullscreen had an optional argument for requesting keyboard access, which led to a warning in some browsers and which for Safari we chose to ignore as the risk outweighed the benefit. The new spec does not have this parameter and makes no mention of keyboard access. It is not even clear if refusing to send key events or grant keyboard focus in fullscreen would be conforming. I think this should be fixed. I think the spec should at minimum explicitly allow browsers to block delivery of key events (or at least key events for alphanumeric keys). Regrettably, this defense would not be very effective on pure touchscreen devices, since there is no physical keyboard and the soft keyboard can likely be convincingly faked with HTML. I've got no objection against a user poll for things like keyboard interactions in fullscreen as long as the implemention honors the intent to show this once for a session or remembered state and not all the time when going back and forth. Our current intended behavior in Safari is to never allow alphanumeric keyboard access in fullscreen. No cancel/allow prompt. Did you read the part where I explained why such prompts are useless for security? The second most effective defense that I can think of is a distinctive visible indicator that prevents convincingly faking the system UI. The common notification to press escape to exit partly serves that purpose. A potentially more effective version would be to show a noticeable visible indicator every time the user moves the mouse, presses a key, or registers a tap on a touchscreen. Ideally this would cover key areas needed to fake a real browser UI such as where the toolbar and address bar would go, and would indicate what site is showing the fullscreen UI. However, while such an effect is reasonable for fullscreen video (where the user will mostly watch without interacting), it might be distracting for fullscreen games, or the fullscreen mode of a presentation program, or a fullscreen editor Such a scheme would render fullscreen virtually useless for most of its intended purpose. That depends on what you think most of its intended purpose is. Many native video fullscreen implementations already have behavior somewhat like this, because they expect that the user is not producing UI events most of the time while watching the video. It may be annoying in the context of a game or slideshow. So far I have encountered such uses much less often than video. Regards, Maciej
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
WebGL FPSes with fullscreen support - http://media.tojicode.com/q3bsp/ - https://developer.mozilla.org/en-US/demos/detail/bananabread - http://dl.dropbox.com/u/6873971/data/cube2/index.html On Sat, Oct 13, 2012 at 9:58 PM, Florian Bösch pya...@gmail.com wrote: You're making fullscreen useless for games. On Sat, Oct 13, 2012 at 9:56 PM, Maciej Stachowiak m...@apple.com wrote: On Oct 13, 2012, at 4:58 AM, Florian Bösch pya...@gmail.com wrote: On Sat, Oct 13, 2012 at 1:49 PM, Maciej Stachowiak m...@apple.com wrote: I think the most effective defense against phishing via fullscreen is to prevent keyboard access. The original design for requestFullscreen had an optional argument for requesting keyboard access, which led to a warning in some browsers and which for Safari we chose to ignore as the risk outweighed the benefit. The new spec does not have this parameter and makes no mention of keyboard access. It is not even clear if refusing to send key events or grant keyboard focus in fullscreen would be conforming. I think this should be fixed. I think the spec should at minimum explicitly allow browsers to block delivery of key events (or at least key events for alphanumeric keys). Regrettably, this defense would not be very effective on pure touchscreen devices, since there is no physical keyboard and the soft keyboard can likely be convincingly faked with HTML. I've got no objection against a user poll for things like keyboard interactions in fullscreen as long as the implemention honors the intent to show this once for a session or remembered state and not all the time when going back and forth. Our current intended behavior in Safari is to never allow alphanumeric keyboard access in fullscreen. No cancel/allow prompt. Did you read the part where I explained why such prompts are useless for security? The second most effective defense that I can think of is a distinctive visible indicator that prevents convincingly faking the system UI. The common notification to press escape to exit partly serves that purpose. A potentially more effective version would be to show a noticeable visible indicator every time the user moves the mouse, presses a key, or registers a tap on a touchscreen. Ideally this would cover key areas needed to fake a real browser UI such as where the toolbar and address bar would go, and would indicate what site is showing the fullscreen UI. However, while such an effect is reasonable for fullscreen video (where the user will mostly watch without interacting), it might be distracting for fullscreen games, or the fullscreen mode of a presentation program, or a fullscreen editor Such a scheme would render fullscreen virtually useless for most of its intended purpose. That depends on what you think most of its intended purpose is. Many native video fullscreen implementations already have behavior somewhat like this, because they expect that the user is not producing UI events most of the time while watching the video. It may be annoying in the context of a game or slideshow. So far I have encountered such uses much less often than video. Regards, Maciej
