Should access to sandboxed file system be secure context only?

[mkruisselbrink]

As currently written, only access to the native file system (via chooseFileSystemEntries) requires a secure context, while access to the sandboxed file system can be done by insecure origins as well (after all, that's what the chrome-only existing sandboxed file system API also does).

But probably we want to just make the entire API secure context only?

[inexorabletash]

+1 to SecureContext only.

(Having the legacy API exposed in non-secure origins is something Chrome already has for quota APIs)

[pwnall]

+1

Long-term, all client-side storage features should be restricted to secure origins.

[guest271314]

Is file: protocol considered a secure context? Is reading and writing to the user filesystem at file: protocol considered to be any less "secure" than JavaScript code a web site reading and writing to the user filesystem where the https: protocol is being used? If so, for what technical reasons?

[mkruisselbrink]

Excellent question, but probably a better question for https://github.com/w3c/webappsec-secure-contexts/issues.

A context being a secure context is more than just the origin being secure, but anyway, according to https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy it does appear that file: origins are "potentially trustworthy", and thus assuming none of the other situations that can make a context insecure apply, pages loaded from file: should be considered secure contexts.

However that isn't the entire story, the first step in the algorithm checks if an origin is opaque, and https://url.spec.whatwg.org/#origin kind of leaves it up in the air if file: is opaque or not.

Either way even without the secure contexts spec apparently treating all opaque origins as insecure, I don't think we would want to make sandboxed file system available in opaque origins anyway, similar to how most other storage mechanisms aren't available in opaque origins either.

[guest271314]

@mkruisselbrink From the point-of-view of "trust nothing" and verify everything, file: is just as if not more "secure" than a network request outside of the machine. As no network communication can be considered "secure" in the first instance (see A Good American), perhaps save for use of RSA (even then if an individual were to be able to overcome RSA they would not necessarily announce such an achievement, other than for some form attribution for doing so).

Aside from the semantics and specification author indecision as to whether file: is a "secure context", users should definitely be able to use this API - offline or online - at file: protocol; certainly offline. To mandate that the API be used only online, over a network, though not offline, at own filesystem, under the auspices that network computing is more "secure" than non-network computing is counter-intuitive.

Am banned from WHATWG (evidently indefinitely) ostensibly for asking such questions, therefore cannot presently ask any further questions at WHATWG umbrella documents at GitHub.

FWIW, will cast vote that whatever any specification has decided or not decided conclusively as to file: protocol being "secure", that this specification explicitly and unequivocally permit use of of the API at file: protocol, for the above stated reasons.

[guest271314]

@mkruisselbrink w3c/webappsec-secure-contexts#66