Is "file:" protocol considered a "secure context", if not why?

[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?

Given that any and all external network communications can be considered insecure, file: protocol, specifically within the scope of Native File System https://github.com/WICG/native-file-system should be considered a "secure context", where no external network communication is necessary.

(Was referred to this specification from WICG/file-system-access#58 (comment))

[inexorabletash]

Historically file: was indeed trusted. Pages on the local machine were trusted like applications.

But here's an attack. Convince a user to download an HTML file containing malicious script, and then open the HTML file locally (e.g. file:///Users/foo/Downloads/bad.html). Given the prevalence and risk of this, file: should be potentially be treated as less secure than even http:, e.g. treated as an opaque origin.

Relevant discussion at: whatwg/html#3099

[mkruisselbrink]

It is kind of weird though that this spec treats file: as potentially trustworthy (just like https), but only if the user agent happens to not treat them as opaque. I guess I would at least expect some kind of non-normative note at the scheme=file branch in https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy to explain that that's only for historical reasons or something, or note something about file URLs potentially being opaque origins so that branch being unreachable in at least some implementations.

Right now the "file" branch is pretty much the only branch in that algorithm with no explaining note, and it's easy to miss that despite the explicit file=trustworthy branch, file URLs generally aren't actually treated as trustworthy.

[guest271314]

@inexorabletash

But here's an attack. Convince a user to download an HTML file containing malicious script, and then open the HTML file locally (e.g. file:///Users/foo/Downloads/bad.html). Given the prevalence and risk of this, file: should be potentially be treated as less secure than even http:, e.g. treated as an opaque origin.

How is that attack different from an attack (or simply visiting any web site; e.g., browser fingerprinting) at a different protocol, http: or https:, or any other network communications?

The entire world wide web is inherently insecure. As of last century 20TB a second was being read and analyzed in real-time over any arbitrary wire. That fact is verifiable by the primary sources.

[guest271314]

@inexorabletash Only posted this issue due to being referred here re using Native Filesystem at file: protocol, and this specification appears to have some influence over whether or not file: protocol is listed as "ok" to use with the Native Filesystem API; where the primary interest is in testing the API at ostensibly FOSS browsers (Chromium; Firefox) within the sense of

so we need people to have weird new ideas ... we need more ideas to break it and make it better

Use it
Break it
File bugs
Request features

(AT THE FRONTEND 2016 - Real time front-end alchemy, or: capturing, playing, altering and encoding video and audio streams, without servers or plugins! by Soledad Penadés)

or, put in another way, in the immortal words of Suga Free (Angry Enuff)

Look for lies! Misconduct is at an all-time high too

where have found more than one bug at more than one FOSS browsers testing API's and code at file: protocol that likely would not have found at a "trusted" protocol; two examples

1. While trying to compose code which allowed upload and reading of directories at HTML <input type="file"> which output the same result at Chromium and Firefox found that at a previous version of Firefox if a directory was dropped at a <textarea> element the full path ("path component") of each directory and sub-directory and files therein was set as value of the <textarea> (https://stackoverflow.com/a/40146883);

2. Far more egregious, and demonstrating that simply because https: is used, or a specification describes a context as "secure", in certain cases, relying on a a label of "trusted' or "secure' might not reflect what is actually occurring relevant to user PII and "security". While testing the Web Speech API found that at Chromium webkitSpeechRecognition "did not work" at file: protocol. Looking in to the matter further found that when the user executes webkitSpeechRecognition - at a "secure context" - that the users' voice (PII; biometric data) is recorded and sent by some form of network request to a remote web service. The recording and sending of the user biometric data to a remote web service is not disclosed to the user. Chromium developers include deprecation warnings for API's in the source code printed at a message at console; though there is no official documentation that could locate where Chromium authors/developers have notified the user (at console or other conspicuous documentation) that their voice is being sent to a remote web service - nor is the user notified as to whether their recorded voice is stored FOREVER by the undisclosed third-party web service to which their PII biometric data was sent; and/or used for development of *oogle TTS/STT technologies; where a substantial corpus of voice data, in general, is used within the scope of speech synthesis (https://github.com/mozilla/voice-web).

In the former case it is unlikely that would have found the bug at Firefox if had not tested code over and over again at file: protocol.

In the latter case, the user is far less "secure" (in fact, not secure at all; that is, if they consider their voice being recorded and sent to an undisclosed third-party for an undisclosed storage time and potential further undisclosed third-party usage) using webkitSpeechRecognition at a "secure context" (e.g., https:, online) compared to using webkitSpeechRecognition offline at file: ("opaque") protocol only to discover (or, confirm) that the behaviour at Chromium is for the API to not work, thus, use https://github.com/cmusphinx/pocketsphinx to avoid having their voice recorded and possibly being used for undisclosed purposes (research; profit). The issue https://bugs.chromium.org/p/chromium/issues/detail?id=816095 is marked as WontFix. Which from a "secure context" perspective could be evaluated as equivalent to DontUse (at least until Chromium developers make it abundantly clear that the speech recognition code (apparently proprietary) at desktop version is not shipped with the browser; that user voice is not processed in real-time by code at the browser offline, but rather, sent to a third-party web service, in a "secure context").

The case of

But here's an attack. Convince a user to download an HTML file containing malicious script, and then open the HTML file locally (e.g. file:///Users/foo/Downloads/bad.html). Given the prevalence and risk of this, file: should be potentially be treated as less secure than even http:, e.g. treated as an opaque origin.

any GitHub repository that is downloaded and executed has the same vector; e.g., a shell (or even to an appreciable degree, HTML, CSS, JavaScript shipped with the browser) script in code could execute a directory read/write operation (when permissions are granted or not); or launch Chrome from the script after having read the local directories; etc.

Therefore, marking a particular context as "secure" could be a misnomer in certain cases.

To the extent that this specification has influence over the Native Filesystem API am only requesting clarification as to how use of that API at file: protocol would be any different than downloading a GitHub repository and arbitrarily executing code within the folder? FWIW, from perspective here, the API is far more at risk of being compromised when used online than when used offline at file: protocol (whether the applicable label applied is "insecure" or "opaque"; etc.).

[guest271314]

@mkruisselbrink The only reason posted this issue is for the purpose of somehow allowing the API at file: protocol. Whether a particular context is considered "secure" or not be a specification body is not the purpose of this issue, unless that specification controls the allowance of an API at file: (e.g., for testing). Still not clear if the Native Filesystem API will be able to be run at file: protocol? If that is the case, can --allow-file-access-from-files or other flag be set (at Chromium source code; and/or suggested to prospective implementers at the specification, accompanied by whatever appropriate warning the API specification authors deem fitting) to allow the use of the API at file: protocol?