Downloads Feature Policy

[jkarlin]

This is a proposal for a Downloads Feature Policy. The purpose of the feature is to restrict the ability for a frame to incur a download navigation. That is, if the restricted frame (or its descendant) attempts to navigate to a URL that would cause a download (e.g., by content sniffing or by attribute), the download will be aborted. This is particularly useful on third-party embedded content to prevent drive-by downloads, but may also be useful at the top-level for the same purpose.

I have some questions on what we should do (if anything) about the following scenarios:

1. The restricted subframe navigates its unrestricted parent frame to cause a download.
2. The restricted subframe calls window.open() to cause the new window to download.

Both of those scenarios could be restricted with sandbox policies (and hopefully someday soon with feature policies) to prevent popups and top-frame navigation.

Should we just have super clear documentation that if you want to prevent all downloads you'll need to also block popups and top-frame navigations? Or should restricting downloads automatically prevent top-frame navigation and popups? I'm leaning toward the former, since it provides the most options. Especially since, for ads, you might want to restrict top-frame navigation but it's likely you still want it to be able to open a popup.

[annevk]

Perhaps there should be a navigation policy of sorts that explains the sandboxing we have today and allows more granularity with regards to distinguishing between downloads and other resources?

[jkarlin]

Interesting. Can you explain a bit more what you mean by a navigation policy? Perhaps an example?

[annevk]

E.g., disabling top-level navigation (setting parent.location).

[jkarlin]

Are you referring to a single Feature Policy where the feature is navigation and there is a list of options for what's enabled/disabled per origin? Or a bunch of feature policies that copy what's already in sandbox plus some new ones?

[annevk]

Just for navigation. It's not clear to me that we should do downloads on its own as it's part of navigation.

[jkarlin]

I was under the assumption that all of the sandbox policies were eventually coming to Feature Policy. So top-level navigation and popups should be on the way. @clelland is that still true?

[clelland]

That is definitely planned; I have a proposal out for explaining sandbox in terms of feature policy, which should immediately allow a 'top-navigation' feature (as well as a 'top-navigation-by-user-activation' feature, I suppose). It still needs some discussion around how to escape the sandbox, and what that even means, when it is expressed through feature policy, but it should be doable.

I do like this policy, though -- not about navigation specifically, but being about whether a frame is allowed to drop files into the user's filesystem at all. I presume that there are other ways besides top-level navigation to get a browser to write a file -- this should disable all of those paths as well.

[jkarlin]

The escaping the sandbox conversation is relevant to the downloads feature policy as well.

Do you think the downloads feature policy, by default, should prevent the frame from navigating the top-frame and from opening popups?

[jkarlin]

Ah, I forgot that sandbox already has a policy to restrict downloads (Chrome never implemented it). So downloads is one of the many sandbox features that should be ported over to Feature Policy.

Does it make sense to create the policies individually or should they be done en masse?

[jkarlin]

I was led to believe that Mozilla had implemented it due to https://bugs.chromium.org/p/chromium/issues/detail?id=539938#c3, but now I'm uncertain because in my own tests FF does in fact allow downloads in a sandboxed iframe. And I can't seem to find anything about it in MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe.

[clelland]

Do you think the downloads feature policy, by default, should prevent the frame from navigating the top-frame and from opening popups?

I think it makes sense to separate those -- although I we may have to specify the behaviour when navigating to, e.g., a resource served with mime type application/octet-stream. Probably have to either stay on the previous page or render an error message. I'm not sure what precedent exists in specs.

Ah, I forgot that sandbox already has a policy to restrict downloads (Chrome never implemented it)

Oh? I hadn't seen that in any of my digging; and in fact from whatwg/html#3236 and w3c/html#301 (and others) I thought it was still a leak in the current sandbox model.

Does it make sense to create the policies individually or should they be done en masse?

I think it only makes sense to do them all at the same time, rather than leaving the platform in a semi-consistent state; @ehsan-karamad has been working on a PoC for that for Chrome

[jkarlin]

Yeah, I was wrong. It's not part of the spec. So this makes me want to create it as a new feature policy for now and the sandbox apis can be ported when it's convenient. It's still a useful API even without the top-frame and popup restrictions.