Inconsistency: Navigation to file:// URLs using tabs and windows APIs

[oliverdunk]

Currently Chrome and Safari support opening file:// URLs with browser.tabs.create, whereas Firefox forbids this (MDN).

We are interested in making a change to start blocking this in Chrome. Supporting file:// URLs presents a security risk as it can help as part of an exploit chain where a vulnerable extension (e.g one that accepts messages without validating the source) is tricked in to downloading and then opening a malicious file. If this file is able to exploit a vulnerability to gain control of the renderer process, this can result in local file access.

Looking at our metrics we can see that opening file:// URLs is fairly uncommon and this change would not impact a significant number of users.

In discussions internally, we have considered a couple of options:

• Prevent opening file:// URLs using the tabs and windows APIs unless the "Allow access to file URLs" checkbox is enabled.
• Add an allowNavigationToFiles boolean to the properties objects which can be used to explicitly opt in to this. This would still allow extensions to navigate to files, but require them to opt in, fixing this exploit in extensions which do not need it.

We are currently leaning towards the first option. This provides a more robust solution (we don't need to worry about developers opting in without understanding the trade-offs) and we could always add the boolean in the future if we realise it's needed.

[oliverdunk]

@xeenon Could you add a label for Safari?

[shhnjk]

Chromium has sent out an announcement, and this change is planned to be ship on Chromium 118.

[xeenon]

Safari/WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=261040

[oliverdunk]

This shipped in Chromium 118: https://chromium-review.googlesource.com/c/chromium/src/+/4772028

[yankovichv]

@oliverdunk , do I understand correctly: with version 118 of Chrome we will lose the ability to reproduce browser functions when working with files in the history and tab manager?

Bad news :(

[oliverdunk]

Hi @yankovichv - assuming you're calling one of the tabs or windows APIs with a file URL, that would no longer work by default. One solution could be to add a prompt encouraging users to enable file access for your extension on the chrome://extensions page which would allow this to start working again.

If you are able to get any data or feedback on the impact of this change, we'd definitely be interested. Since there was no feedback on the chromium-extensions post or in the WECG, we decided to go ahead, but happy to chat more.

[yankovichv]

@oliverdunk, my pleasure 🤗.

As you can see in my screenshot, our extension has a tab and history manager function. Tabs and history entries with the "file://" URL are a special case of data that the user sees in the browser's native managers and which is returned by the history and tabs API.

Next, we need to understand that users have very simple requirements for extensions that reproduce native browser functions - so that "it works exactly the same as in a browser". And now we cannot fulfill this requirement.

The option with additional permission in the form of a checkbox on the permission page is not working. Nobody will ever press it. The features and users are too casual, and the requirement is too complex. Uninstall is more easy 😂.

Of course, it’s a pity that the decision has already been made. But if we talk about a possible way out of the situation:

1. the new optional permission in the manifest
2. hide this data from API responses.

Will probably be better.

[shhnjk]

Hi @yankovichv!
There is no changes to history API as part of this changes. And things like tabs.query should work same as previously.
The only change we've made is when you call tabs.create, tabs.update, etc with file URL, that navigation will be blocked.

[yankovichv]

I understand it. But now I won’t be able to work with this data, like with everyone else.

For example, I see a history entry, but if this entry is file://, how can I now implement the actions open in a new tab or open in a new window for this entry? This is impossible. In fact, all history managers and all tab managers (for example, the duplicate tab action) will suffer from this.

I'm not sure your change is as harmless as you make it out to be. Still, every year for many people the browser replaces the OS. And viewing files is a basic OS scenario. I've been reading PDFs only in a browser for 10 years now.

[shhnjk]

For example, I see a history entry, but if this entry is file://, how can I now implement the actions open in a new tab or open in a new window for this entry? This is impossible. In fact, all history managers and all tab managers (for example, the duplicate tab action) will suffer from this.

You are right that navigation to file: URLs in such use case won't be possible by default. But you can recommend users to change settings to allow access to files when a user clicks on such a history entry.

While I also read PDFs in the browser, UX for accessing downloaded PDFs have been either through the chrome://downloads popup or from the download folder.

Given Firefox does not support navigation to file: URLs from extensions, I hope above option would be good enough for heavy users who needs to access files from the history.
And this dramatically helps increasing security of extensions.

[yankovichv]

Are there no changes in this release? I checked the 118th release of the beta channel, and everything works.

[oliverdunk]

Are there no changes in this release? I checked the 118th release of the beta channel, and everything works.

Were you checking with an unpacked extension that gets file access by default maybe? (Feel free to email me to continue this discussion, we probably shouldn't add noise to this issue)