-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define behavior for file://
documents' origin.
#3099
Comments
Maybe worth discussing the behavior of document.cookie in file URLs too. |
@shhnjk: Yeah. I didn't do exhaustive tests, but I assume that the |
/cc @whatwg/security for thoughts. |
The actual Firefox behavior is more or less like so:
There are some implications from this not captured by the discussion above. Specifically, if The fundamental reason for the Firefox behavior was to allow things like HTML help systems and whatnot to work. There are some drawbacks, of course. There's the problem of scanning the download directory. There's some weirdness around interacting with symlinks (see https://bugzilla.mozilla.org/show_bug.cgi?id=670514). That sort of thing. In addition to the document origin question, there's the question of subresources. If I have a document at |
Thanks, @bzbarsky! That's helpful context!
Based on the
I can see this as a real concern. But, Chrome's been shipping tighter behaviors than Firefox for some time now, and the anecdotes I know about personally are positive. For example, my partner often gets HTMLized schoolbooks on CD from which they can print out worksheets and etc. for their classes. Thus far, Chrome hasn't frustrated that effort. shrug Things seem to just work without DOM or XHR access. I grant that this might not be the case for more complex material, but (again anecdotally) I haven't seen any bugs filed against on the issue. It might not be a large use case? Or perhaps everyone who needed it has migrated to Firefox? Tough to tell from metrics alone...
This does seem to be a real problem. Moreso for Edge than for Firefox, though, given that it doesn't seem to do directory-based scoping. Is this a problem that Firefox would be interested in poking at?
I'd hope that each of these would be explained by the origin question above. If we treat |
No, I meant what I said, though the antecedents may not have been very clear. The "represents" bit was talking about "a file:// origin", not the URL being loaded. Maybe a clearer phrasing:
Or to IE/Edge, yes? On Windows, Chrome is the only browser that doesn't support this use case.
Yes. We've been trying to figure out sane ways to restrict this case without breaking too many users for a while. Maybe we could try gathering some telemetry about how much breakage users would actually encounter... It's hard to say with some of the corporate-firewall dark matter out there. :(
Right, but the question is what browsers do right now. Note that Chrome, for example, doesn't enforce CSSOM origin checks the way the spec says it should (see https://bugs.chromium.org/p/chromium/issues/detail?id=650534 and https://bugs.chromium.org/p/chromium/issues/detail?id=775525), which means there are cases that would work in all browsers right now but stop working if Firefox stops inheriting file:// origins into stylesheets but keeps correctly enforcing the CSSOM security checks. |
Got it, thanks!
A very fair point.
Yup. That's a real problem. What metrics would be helpful to add? I could imagine adding something along the lines of "How many pageviews are on
Thanks for the poke. I've pinged the bug again, let's see if we can get more alignment. |
FWIW, we can probably approximate "How many pageviews are |
As a user, I prefer Firefox's behavior for DOM access/ As a developer, I often make little utilities for friends and family by giving them an [EDIT]: these utilities are often specifically to get around corporate restrictions, so they can use an small tool at work that is considered safe by the system and doesn't require network access. Example: a color picker for a friend who wanted a particular behavior (the colors mixed in some application-specific way) that output a pasteable snippet for the software they were using. It remembers their previous combinations for ease-of-use, since |
I know this issue hasn't seen any activity for a while but if anybody comes back here to talk about local file access, it might be helpful to add a data point about XHR behavior, since Chrome behaves differently between XHR and FWIW, I strongly agree with @tigt, that while you may not see huge numbers of people relying on advanced features from a |
Firefox 68 and newer treat files as unique origins (https://bugzilla.mozilla.org/show_bug.cgi?id=1500453). Maybe it's time to make the spec change. |
Note that when we did this we discovered various places where Chrome does NOT in fact treat different files as different origins. That has been pretty frustrating, with the whole "now we have to reverse-engineer this stuff" business... |
Chrome seems to have a single global "file://" origin used by a lot of origin code. There's at least one place in the renderer where a file origin is replaced by an opaque origin, but a lot of code uses origins that were not parsed by that code. So localStorage for Chrome URLs is global. If you enable network state partitioning in Chrome, all file URLs use a single "file" origin partition, etc. Also, it looks to me like the FireFox and Safari descriptions here are inaccurate, at least with respect to localStorage (which is all I tested). FireFox looks to have a per-directory localStorage. Safari looks to have a global file localStorage (I suspect it just deletes it every so often, but didn't test that). |
Let me share some thoughts I had after reading about the cross-directory behavior described below:
I assume that we want most security decisions to be based on the origin that initiates a navigation or a subresource fetch. Therefore I assume that the directory information would need to be somehow encoded in the origin (in specs + in implementations). Q1: Is this a fair assumption? I think that the assumption leads to 2 additional questions: Q2: What is / should be the algorithm for calculating the origin of a document? At the high-level the algorithm used by Chromium only looks at the document's URL in most cases. The only major exceptions are "about:blank" and "about:srcdoc" and initial empty documents, which may inherit their origin from the navigation initiator ("about:blank", "about:blank#blah", etc.), from the parent frame ("about:srcdoc", etc.) or from the creator/owner (initial empty document). It seems that inheriting directory-based-restrictions might require changes (in the quoted example the initiator origin might matter when navigating to file:///A/subsubframe.html even though it is not an about:blank, about:srcdoc, etc.) AFAIK, Chromium's algorithm is implemented in the following places:
Q3: How should the directory information be represented in an origin? Do we want an explicit How crazy would it be to encode the directory information into the hostname? It seems rather icky, but is it off-the-table-icky? FWIW, I assume that |
The text as https://html.spec.whatwg.org/#sandboxOrigin defines a document's origin in the case that "the Document's URL's scheme is a network scheme" and for
data:
schemes, but declines to define behavior for non-network schemes likefile:
. Unsurprisingly, different browsers have made different choices here. When a document is loaded fromfile:///directory/file.html
:file://
forlocation.origin
(it doesn't yet implementwindow.origin
)file:///directory/other-file.html
,file:///directory/subdirectory/file.html
, andfile:///parent-directory.html
when framed.localStorage
across allfile:
URLsfetch()
is called onfile:
URLs.null
forwindow.origin
file:///directory/other-file.html
andfile:///directory/subdirectory/file.html
, and disallows DOM access tofile:///parent-directory.html
when framed.localStorage
seems scoped to the same-or-sub directory as well.fetch()
to access content fromfile:///directory/other-file.html
andfile:///directory/subdirectory/file.html
, and returns a network error when fetching fromfile:///parent-directory.html
null
forwindow.origin
file:///directory/other-file.html
,file:///directory/subdirectory/file.html
, andfile:///parent-directory.html
(that is,<iframe src="file:///whatever/directory/file.html"></iframe>
stays inabout:blank
and pops a Finder window to/whatever/directory/
)localStorage
for allfile:
URLsfetch()
onfile:///directory/other-file.html
,file:///directory/subdirectory/file.html
, andfile:///parent-directory.html
.null
forwindow.origin
file:///directory/other-file.html
,file:///directory/subdirectory/file.html
, andfile:///parent-directory.html
when framed.localStorage
across allfile:
URLsfetch()
onfile:///directory/other-file.html
,file:///directory/subdirectory/file.html
, andfile:///parent-directory.html
.I wonder if we could get more alignment if we talked about it a bit. There seems to be general agreement that the page should have an opaque origin, but a little bit of disagreement about what that should mean. I'd kinda like to keep Chrome's behavior for DOM access and Fetch, for instance, as it protects against scanning the entire disk or a user's downloads directory. I'm less enthusiastic about Chrome's
localStorage
behavior. I'd prefer Safari's, I think, but could live with something less draconian if there's good reason to.@annevk, @travisleithead, @johnwilander: Would y'all mind looping in relevant folks (or having opinions yourselves? :) )?
The text was updated successfully, but these errors were encountered: