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: w...@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: t...@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: w...@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 <t...@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: t...@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: w...@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 <t...@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: t...@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?
