Re: [widgets] API - openURL security considerations

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







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 13:31:54 UTC