Re: Classifying potentially hostile URLs seems
like a good entrypoint into a lot of this discussion.  I find that spec
mind-numbingly arcane, but I'm sure that there is something at Step 21 that
might help ("fetch scheme" seems like a useful concept to explore more).

On Tue, Aug 17, 2021 at 3:03 PM Marcos Caceres <> wrote:

> Hi WebAppSec Folks,
> I'm writing to you in my capacity as WebApps WG Chair, formally seeking a
> liaison with WebAppSec's on a security matter described below.
> ## What happened...
> About 2 years ago, the Web Share API was found to have a vulnerability
> whereby "file://" could be used to "steal local files using Safari Web
> Share API" [1]. In particular, passwords could be stolen.
> As part of that, we patched up various browsers to disallow anything that
> was not "http", "https", plus any schemes the user agent deems unsafe to
> navigate. In Firefox, for instance, this includes "blob:" URLs, as they
> don't make sense outside the browser - and you can imagine other URLS that
> might be unsafe to "share" (e.g., "javascript:", "data:" and so on). You
> can see how Gecko handles this at [2].
> Over in the Github issue related to this [3], Martin Thompson wrote:
> > it might be worth examining principles a little closer to determine
> whether a looser set of constraints can be made to work. @dveditz suggested
> that we block URLs if we might not permit both navigation or redirection. I
> think that is a reasonable starting point here. We don't allow navigation
> or redirects to file:// and so sharing that seems to be primarily a means
> of circumventing that policy.
> ## Do we need "a thing..."?
> So, generally for the platform, should we try to define some kind of
> primitive or concept around these kinds of URLs (i.e., those that "those
> whereby we allow navigation or redirection")? Or, should we just leave it
> to each implementer to determine what set of URLs are safe to "share"?
> Would like to hear your thoughts over at [3] or here. Right now, the Web
> Share API is leaning towards just leaving it to implementers - but maybe
> there is something we can formalize here for the platform at large (or
> perhaps something exists already which we hadn't considered)?
> Thanks in advance your thoughts an input!
> Marcos
> [1]
> [2]
> [3]

Received on Tuesday, 17 August 2021 06:04:00 UTC