- From: Scott Wilson <scott.bradley.wilson@gmail.com>
- Date: Wed, 30 Jun 2010 14:59:53 +0100
- To: marcosc@opera.com
- Cc: Arthur Barstow <art.barstow@nokia.com>, Thomas Roessler <tlr@w3.org>, Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
On 30 Jun 2010, at 14:30, Marcos Caceres wrote: > I've evaluated the discussions in this thread and am strongly leaning > towards proposing we drop openURL() from the specification on privacy > and security grounds. > > Although I can think of cases where it might be useful to have a > widget programmatically call openURL (e.g., "when it's 5pm, and if I'm > at home, sms these people and let him know 'I'm here, bring beer!'"), > there are just too many abuse cases and complexities. I haven't seen too many examples of OpenURL() in the wild, and in Wookie you may as well just use HTML <a> and window.open() as its running in a browser anyway. The UC would be for environments where window.open() was not handled by the UA; however implementing that would probably be better effort spent than implementing widget.openURL(). > I think we should follow Adam's advice from May 10 and just make URL > handling reliant on a declarative model (i.e., leave it to HTML's a > element and friends, as suggested by Adam below): > >> 1) Remove the API and replace it with a declarative API, like a >> hyperlink. Remove the ability to programmatically click the hyperlink >> and instead rely on the user actually clicking the link. This >> approach is related to the "browser button" element discussed in the >> HTML working group for dealing with similar security issues with >> programmatic access to other APIs. > > I'm unsure if we should get HTML5 to specify this, or if we should > specify this behavior (if they don't already). I personally think the > widgets API spec would be overreaching if it started saying how URI > handling in HTML should be done. > >> 2) If we require an imperative API for following a hyperlink, restrict >> the API to a whitelist of known-safe URL schemes. We can allow user >> agents to extend this list with a registry of known-safe URL schemes, >> but we shouldn't allow access to random side-effecting schemes like >> sms (to pick an example from the spec) by default. > > I'm still thinking we could drop openURL for this version and then add > it once we work out all the kinks and if developers really cannot live > without it. Sounds fine by me +1 > > > > > > > > On Tue, May 11, 2010 at 6:28 PM, Arthur Barstow <art.barstow@nokia.com> wrote: >> Several responses to this thread were made by Thomas and Adam and since >> those responses are not archived in a Public area, with their permission, >> here are all of the responses, starting with the oldest. >> >> The last Public response to this thread is: >> >> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0465.html >> >> -Art Barstow >> >> >> ** From: w3c@adambarth.com >> Subject: Re: [widgets] API - openURL security considerations >> Date: May 10, 2010 12:15:38 PM EDT >> >> It's lame that we're using a blacklist instead of a whitelist here. >> Also this recommendation is somewhat useless: >> >> "it is recommended that the user agent prompt the user for >> confirmation before passing the URI to a scheme handler" >> >> It's unlikely that users will have much context for understanding the >> consequences of this confirmation experience and hence will make poor >> security decisions. >> >> Personally, I think the API is poorly design and should be removed in >> favor of something that is secure by design. We're stuck with this >> API in the web platform in the form of window.open(), but we'd be >> better off without. You can see all the machinations around popup >> blockers and vulnerabilities that it has created. Fpr example, >> <http://www.gnucitizen.org/blog/ie-pwns-secondlife/>. >> >> Adam >> >> >> ** From: tlr@w3.org >> Subject: Re: [widgets] API - openURL security considerations >> Date: May 10, 2010 3:21:07 PM EDT >> >> On 10 May 2010, at 18:15, Adam Barth wrote: >> >> >>> Personally, I think the API is poorly design and should be removed in >>> favor of something that is secure by design. We're stuck with this >>> API in the web platform in the form of window.open(), but we'd be >>> better off without. You can see all the machinations around popup >>> blockers and vulnerabilities that it has created. Fpr example, >>> <http://www.gnucitizen.org/blog/ie-pwns-secondlife/>. >>> >> >> Are you suggesting to completely drop openURL from the widget API? Or do >> you suggest a redesign? >> >> >> ** From: w3c@adambarth.com >> Subject: Re: [widgets] API - openURL security considerations >> Date: May 10, 2010 3:36:11 PM EDT >> >> On Mon, May 10, 2010 at 12:21 PM, Thomas Roessler <tlr@w3.org> wrote: >> >>> On 10 May 2010, at 18:15, Adam Barth wrote: >>> >>>> Personally, I think the API is poorly design and should be removed in >>>> favor of something that is secure by design. We're stuck with this >>>> API in the web platform in the form of window.open(), but we'd be >>>> better off without. You can see all the machinations around popup >>>> blockers and vulnerabilities that it has created. Fpr example, >>>> <http://www.gnucitizen.org/blog/ie-pwns-secondlife/>. >>>> >>> >>> Are you suggesting to completely drop openURL from the widget API? Or do >>> you suggest a redesign? >>> >> >> I'm not familiar enough with the use cases for widgets to know what >> the alternatives are. My perspective is that we'd be better off with >> a much weaker window.open() API in the web platform, but we're stuck >> with what we have. In the widgets space, it seems like there's an >> opportunity to do something better that doesn't require us to reinvent >> popup blockers and all the other pseudo-security cruft we have around >> to deal with window.open() in browsers. >> >> Adam >> >> >> ** From: tlr@w3.org >> Subject: Re: [widgets] API - openURL security considerations >> Date: May 10, 2010 3:43:48 PM EDT >> >> On 10 May 2010, at 21:36, Adam Barth wrote: >> >>>> Are you suggesting to completely drop openURL from the widget API? Or do >>>> you suggest a redesign? >>>> >>> >>> I'm not familiar enough with the use cases for widgets to know what >>> the alternatives are. My perspective is that we'd be better off with >>> a much weaker window.open() API in the web platform, >>> >> >> So, it sounds like you have something specific in mind. Mind sharing that? >> Perhaps it fits the widgets work's requirements. (And yes, I'm totally >> asking you to give a solution while we both don't have the requirements >> swapped in. ;-) >> >> >> ** From: w3c@adambarth.com >> Subject: Re: [widgets] API - openURL security considerations >> Date: May 10, 2010 3:54:02 PM EDT >> >> On Mon, May 10, 2010 at 12:43 PM, Thomas Roessler <tlr@w3.org> wrote: >> >>> On 10 May 2010, at 21:36, Adam Barth wrote: >>> >>>>> Are you suggesting to completely drop openURL from the widget API? Or >>>>> do you suggest a redesign? >>>>> >>>> >>>> I'm not familiar enough with the use cases for widgets to know what >>>> the alternatives are. My perspective is that we'd be better off with >>>> a much weaker window.open() API in the web platform, >>>> >>> >>> So, it sounds like you have something specific in mind. Mind sharing >>> that? Perhaps it fits the widgets work's requirements. (And yes, I'm >>> totally asking you to give a solution while we both don't have the >>> requirements swapped in. ;-) >>> >> >> Here are two proposals: >> >> 1) Remove the API and replace it with a declarative API, like a >> hyperlink. Remove the ability to programmatically click the hyperlink >> and instead rely on the user actually clicking the link. This >> approach is related to the "browser button" element discussed in the >> HTML working group for dealing with similar security issues with >> programmatic access to other APIs. >> >> 2) If we require an imperative API for following a hyperlink, restrict >> the API to a whitelist of known-safe URL schemes. We can allow user >> agents to extend this list with a registry of known-safe URL schemes, >> but we shouldn't allow access to random side-effecting schemes like >> sms (to pick an example from the spec) by default. >> >> Adam >> >> >> ** From: tlr@w3.org >> Subject: Re: [widgets] API - openURL security considerations >> Date: May 11, 2010 5:25:33 AM EDT >> >> On 10 May 2010, at 21:54, Adam Barth wrote: >> >>> 2) If we require an imperative API for following a hyperlink, restrict >>> the API to a whitelist of known-safe URL schemes. We can allow user >>> agents to extend this list with a registry of known-safe URL schemes, >>> but we shouldn't allow access to random side-effecting schemes like >>> sms (to pick an example from the spec) by default. >>> >> >> So, this is interesting since it's (to first order) indistinguishable from >> the current API, as far as things the API signatures proper are concerned: >> Whether or not a certain URI scheme is supported sounds like an >> implementation decision that can go either way, and is likely opaque from a >> Web application. >> >> Possible security considerations to take this approach could (in rough >> terms) sound like this: >> >> "Implementations MUST support dereferencing the HTTP and HTTPS URI schemes >> with the openURL method. Implementations MAY support other URI schemes, but >> need to take scheme-specific security considerations into account. For >> example, dereferencing an sms: URI may cause costs to the user, and must >> therefore be tightly controlled." >> >> Is that the direction you're suggesting? Marcos, what do you think? >> >> >> >> > > > > -- > Marcos Caceres > Opera Software ASA, http://www.opera.com/ > http://datadriven.com.au >
Received on Wednesday, 30 June 2010 14:00:35 UTC