Subject: [apps-discuss] W3C TAG feedback on draft-ietf-appsawg-file-scheme-03

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Sep 2015 16:40:45 -0400

<https://github.com/w3ctag/wiki/wiki/fileUrl>

Version under review:
https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-03

## General comments

There hasn’t been – to this point – a document that describes how the `file://` scheme works, and for that reason this is a good document. We are glad to see that the document specifies how to convert between file URIs and OS-dependent system filepaths.

### Limitations

Regarding the use of `file://` URIs on the web, there are a few issues that need to be resolved for interoperability:

1. How does `file://` fit into the web's origin model?
2. How does retrieval of `file://` URIs fit into
   [Fetch](https://fetch.spec.whatwg.org/) and/or the [URL standard](https://url.spec.whatwg.org)?

This document does not address any of these issues, so we encourage the APPSAWG to consider addressing these.

Regarding Fetch and URL, we recommend coordinating with Anne van Kesteren (@annevk) of the WHATWG.

The TAG would be happy to coordinate with APPSAWG to address the question of what the origin of `file://` is (coordinating with others like Anne as necessary).

--
Mark Nottingham   https://www.mnot.net/

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 21 Sep 2015 09:06:51 +1000

Thanks for this Mark. I had a look at the discussion when you first linked
to it, and assumed the outcome would be something to this effect.

To be honest, I'm still not sure in my own mind exactly how file URIs ought
to work on the web; my original goal was just to specify an standard
syntax, and describe how to convert to/from file paths in a pretty
interoperable way.

I'm tempted to say that file URIs don't really belong on the web.

To that end we could add something to say that each file URI has its own
implicit, globally unique origin, as Anne suggested[1]. That would address
the origin model, but might go against the various implementations. Another
tech survey might be in order.

Would anyone here be particularly upset if browsers stopped loading
"file://.." webfonts?

To address the second point, I also don't know how to fit it into 'fetch.'
We've said, "you probably ought to let people read() file URIs" and W3 has
said, "it's an exercise for the reader." I don't know what the right way
forward is on that point. Suggestions are welcome, but to be honest I'm
happy to leave it as it is.

Cheers

[1] https://github.com/w3ctag/spec-reviews/issues/59#issuecomment-131493548

On 16 September 2015 at 06:40, Mark Nottingham <[email-masked]> wrote:

> There hasn’t been – to this point – a document that describes how the
> `file://` scheme works, and for that reason this is a good document. We are
> glad to see that the document specifies how to convert between file URIs
> and OS-dependent system filepaths.
>
> ### Limitations
>
> Regarding the use of `file://` URIs on the web, there are a few issues
> that need to be resolved for interoperability:
>
> The TAG would be happy to coordinate with APPSAWG to address the question
> of what the origin of `file://` is (coordinating with others like Anne as
> necessary).
>
> --

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: t.petch <[email-masked]>
Date: Mon, 21 Sep 2015 10:15:13 +0100

----- Original Message -----
From: "Matthew Kerwin" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>
Cc: "Anne van Kesteren" <[email-masked]>; "Apps Discuss"
<[email-masked]>
Sent: Monday, September 21, 2015 12:06 AM

Thanks for this Mark. I had a look at the discussion when you first
linked
to it, and assumed the outcome would be something to this effect.

To be honest, I'm still not sure in my own mind exactly how file URIs
ought
to work on the web; my original goal was just to specify an standard
syntax, and describe how to convert to/from file paths in a pretty
interoperable way.

<tp>

Matthew

Me too.  I am mindful of RFC3986,

" A resource is not necessarily
      accessible via the Internet; "

I cannot even get file: to work with File Sharing over NetBIOS but that
does not stop me from using file: every day and see the I-D as a useful
step foward with its current scope so my resolution would be to add an
explicit statement thereof although you could argue that the I-D already
does that (" A file URI can only be dereferenced or translated to a
local file
   path if it is local.  ")

Tom Petch

To that end we could add something to say that each file URI has its own
implicit, globally unique origin, as Anne suggested[1]. That would
address
the origin model, but might go against the various implementations.
Another
tech survey might be in order.

To address the second point, I also don't know how to fit it into
'fetch.'
We've said, "you probably ought to let people read() file URIs" and W3
has
said, "it's an exercise for the reader." I don't know what the right way
forward is on that point. Suggestions are welcome, but to be honest I'm
happy to leave it as it is.

Cheers

[1]
https://github.com/w3ctag/spec-reviews/issues/59#issuecomment-131493548

On 16 September 2015 at 06:40, Mark Nottingham <[email-masked]> wrote:

> This document does not address any of these issues, so we encourage
the
> APPSAWG to consider addressing these.
>
> Regarding Fetch and URL, we recommend coordinating with Anne van
Kesteren
> (@annevk) of the WHATWG.

------------------------------------------------------------------------
--------

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 23 Sep 2015 10:21:37 +1000

> On 21 Sep 2015, at 9:06 am, Matthew Kerwin <[email-masked]> wrote:
> 
> Thanks for this Mark. I had a look at the discussion when you first linked to it, and assumed the outcome would be something to this effect.
> 
> To be honest, I'm still not sure in my own mind exactly how file URIs ought to work on the web; my original goal was just to specify an standard syntax, and describe how to convert to/from file paths in a pretty interoperable way.
> 
> To that end we could add something to say that each file URI has its own implicit, globally unique origin, as Anne suggested[1]. That would address the origin model, but might go against the various implementations. Another tech survey might be in order.
> 
> Would anyone here be particularly upset if browsers stopped loading "file://.." webfonts?

I suspect it'd be better to ask over on the W3C WebAppSec mailing list; it has more attention from browser security teams, etc.

> To address the second point, I also don't know how to fit it into 'fetch.' We've said, "you probably ought to let people read() file URIs" and W3 has said, "it's an exercise for the reader." I don't know what the right way forward is on that point. Suggestions are welcome, but to be honest I'm happy to leave it as it is.

To be clear -- Fetch is *not* a W3C specification, at least yet; it's in WHATWG. Ideally someone would step forward to help Anne fill out that section <https://fetch.spec.whatwg.org/#basic-fetch>, but at the least, it'd be good to go through the exercise of making sure that there isn't a blatant conflict between what Fetch needs to do there and this spec.

---

From: Graham Klyne <[email-masked]>
Date: Wed, 23 Sep 2015 10:10:05 +0100

I think it is more important to get a document out that describes well 
established use of file: URIs than it is to also incorporate new/upcoming work. 
  If taking this newer work into account will delay publication of the current 
draft then I would suggest to defer its consideration for a future revision or a 
separate additional document.

I tend to agree that file: URIs don't really belong on the wide web.  Their main 
value, in my experience, is that they provide a way to unify local file access 
with wider web access, often used in a base URI against which relative 
references can be resolved.  In my experience, the main value for using file: 
URIs in browsers is for local testing of web pages and apps.

#g
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 23 Sep 2015 08:14:29 -0700

On Wed, Sep 23, 2015 at 2:10 AM, Graham Klyne <[email-masked]> wrote:

> established use of file: URIs than it is to also incorporate new/upcoming
> work.  If taking this newer work into account will delay publication of the
> current draft then I would suggest to defer its consideration for a future
> revision or a separate additional document.
>

+1; I'd prefer to see this move forward.  Its delivery milestone was July.

-MSK

---

From: Dave Thaler <[email-masked]>
Date: Wed, 23 Sep 2015 23:19:42 +0000

+1 to what Graham said.

Dave

-----Original Message-----
From: apps-discuss [mailto:[email-masked]] On Behalf Of Graham Klyne
Sent: Wednesday, September 23, 2015 2:10 AM
To: Matthew Kerwin <[email-masked]>; Mark Nottingham <[email-masked]>
Cc: Anne van Kesteren <[email-masked]>; Apps Discuss <[email-masked]>
Subject: Re: [apps-discuss] W3C TAG feedback on draft-ietf-appsawg-file-scheme-03

I think it is more important to get a document out that describes well established use of file: URIs than it is to also incorporate new/upcoming work. 
  If taking this newer work into account will delay publication of the current draft then I would suggest to defer its consideration for a future revision or a separate additional document.

I tend to agree that file: URIs don't really belong on the wide web.  Their main value, in my experience, is that they provide a way to unify local file access with wider web access, often used in a base URI against which relative references can be resolved.  In my experience, the main value for using file: 
URIs in browsers is for local testing of web pages and apps.

#g
--

On 21/09/2015 00:06, Matthew Kerwin wrote:
>> There hasn't been - to this point - a document that describes how the

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 24 Sep 2015 09:22:32 +1000

I don't think I disagree on the Fetch integration part, but not documenting the origin of file -- thereby leaving potentially HUGE security issues intact -- seems unwise. At the very least, I'd expect a "there be dragons" security consideration (and that's at the *very* least).

We can say "it shouldn't be on the Web" as much as we like, but the reality is that it's implemented in all browsers. 

> On 23 Sep 2015, at 7:10 pm, Graham Klyne <[email-masked]> wrote:
> 
> I think it is more important to get a document out that describes well established use of file: URIs than it is to also incorporate new/upcoming work.  If taking this newer work into account will delay publication of the current draft then I would suggest to defer its consideration for a future revision or a separate additional document.
> 
> I tend to agree that file: URIs don't really belong on the wide web.  Their main value, in my experience, is that they provide a way to unify local file access with wider web access, often used in a base URI against which relative references can be resolved.  In my experience, the main value for using file: URIs in browsers is for local testing of web pages and apps.
> 
> #g
> --
>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Sep 2015 16:26:06 -0700

> established use of file: URIs than it is to also incorporate

Right.

For work that has well-established practice, a well-established process
pattern is to ship a document recording that practice and soon as
possible and /then/ go work on the spiffy new stuff.  So this needn't be
treated as "either vs. or", but "rather now and then later".

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 24 Sep 2015 16:02:26 +0900

> I'm tempted to say that file URIs don't really belong on the web.

I think "belong to the Web" is more like a philosophical question. Just 
write about the actual practical limitations, and readers will get what 
that means.

> tech survey might be in order.

It would be the safest solution, but also the most restrictive. In 
particular, current browsers allow to save a Web page locally. Last time 
I checked, at least Firefox did that by creating a local file that 
references other local files. This means that all these have "file:" 
addresses.

> Would anyone here be particularly upset if browsers stopped loading

It would be a pity if in a scenario such as the above, webfonts couldn't 
be used anymore. Given that in theory, webfonts should be safe (I know 
that if there are implementation bugs, such bugs can be exploited badly, 
but that shouldn't affect the design, because otherwise, we would have 
to prohibit everything.), I don't see why their use (at least from 
another file: URI) should be prohibited.

> happy to leave it as it is.

I agree with Graham and others that this should be deferred until more 
information is available. Of course, if this information is available 
soon, it could be integrated.

I agree with Mark and others that we need some serious text in the 
Security Section.

Regards,   Martin.

---

From: t.petch <[email-masked]>
Date: Thu, 24 Sep 2015 10:24:58 +0100

----- Original Message -----
From: "Martin J. DÃ¼rst" <[email-masked]>
To: "Matthew Kerwin" <[email-masked]>; "Mark Nottingham"
<[email-masked]>
Cc: "Anne van Kesteren" <[email-masked]>; "Apps Discuss"
<[email-masked]>
Sent: Thursday, September 24, 2015 8:02 AM

linked
address
Another
> references other local files. This means that all these have "file:"

Martin

I am confused by this.  I use IE and when I save a web page, one option
is to create an .html file with the css, script, jpeg etc in a separate
folder but the link from the former to the latter is of the form

<link href="../stylesheet.css" rel="stylesheet" type="text/css">

or

<A HREF="mtgs88.htm#mtgs8821">

and whether or not the links are relative or absolute, I never see IE
using file: just (sometimes) ftp: or http:

Tom Petch

'fetch.'

---

From: Graham Klyne <[email-masked]>
Date: Thu, 24 Sep 2015 12:54:46 +0100

I agree that "shouldn't be on the web" is no excuse for not mentioning known 
security issues.  I have no argument that there should be mention of origin issues.

My own experience of using file has been (IIRC) that file:// references are a 
distinct origin from HTTP sites and others, so that any attempt to access a web 
resource via a page loaded locally runs in to an access violation.  Maybe I 
misremember, or maybe things have changed since I did any serious browser app 
coding.

#g
--

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 24 Sep 2015 09:11:27 -0700

> On Sep 24, 2015, at 4:54 AM, Graham Klyne <[email-masked]> wrote:
> 
> I agree that "shouldn't be on the web" is no excuse for not mentioning known security issues.  I have no argument that there should be mention of origin issues.
> 
> My own experience of using file has been (IIRC) that file:// references are a distinct origin from HTTP sites and others, so that any attempt to access a web resource via a page loaded locally runs in to an access violation.  Maybe I misremember, or maybe things have changed since I did any serious browser app coding.

Yes, but URI scheme implementations consist of much more than just browsers
and it is common for all such implementations (including browsers) to use file URIs,
both internally and externally, when working within a local context.  There should
be mention of security issues when a file reference appears inside an unexpected
(remote) context received by a browser, but there is no need to go overboard with
regard to the identifier scheme in general.

....Roy

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 29 Sep 2015 17:45:15 +1000

On 24 September 2015 at 09:22, Mark Nottingham <[email-masked]> wrote:

> I don't think I disagree on the Fetch integration part, but not
> documenting the origin of file -- thereby leaving potentially HUGE security
> issues intact -- seems unwise. At the very least, I'd expect a "there be
> dragons" security consideration (and that's at the *very* least).
>
>
​How about pointing to and quoting RFC 6454:

"​4. If uri-scheme is "file", the implementation MAY return an
implementation-defined value.

NOTE: Historically, user agents have granted content from the
file scheme a tremendous amount of privilege.  However,
granting all local files such wide privileges can lead to
privilege escalation attacks.  Some user agents have had
success granting local files directory-based privileges, but
this approach has not been widely adopted.  Other user agents
use globally unique identifiers for each file URI, which is
the most secure option."

That's a pretty solid "here be dragons," with a hint towards "proper"
behaviour, without prescribing or proscribing what any current
implementations do.

Cheers

---

From: Eliot Lear <[email-masked]>
Date: Tue, 29 Sep 2015 13:20:33 +0200

Mark,

> I don't think I disagree on the Fetch integration part, but not documenting the origin of file -- thereby leaving potentially HUGE security issues intact -- seems unwise. At the very least, I'd exp…

I agree and we've done that before.  While I'm not particularly proud of
the URI spec, check out THE ALL CAPITALS WARNINGS AT THE FRONT OF rfc
3617 ;-)

Eliot