W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [widgets] API - openURL security considerations

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Wed, 30 Jun 2010 14:59:53 +0100
Cc: Arthur Barstow <art.barstow@nokia.com>, Thomas Roessler <tlr@w3.org>, Adam Barth <w3c@adambarth.com>, public-webapps <public-webapps@w3.org>
Message-Id: <727390A6-9CCA-4D57-9FE6-0EC7A780C52E@gmail.com>
To: marcosc@opera.com

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:39 GMT