Unrestricting because this isn't a security issue.

The general requirement here is a secure context for accessing powerful features[1]. I don't know a lot about the content:// origin - rsesek, do you know more? My suspicion is that file:// has to reference an exact file on disk, whereas I suspect content:// can be formulated and passed to the browser without a concrete backing (i.e. it isn't a secure context).

[1]: https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins

Hi, 

thank you for your reply. The use case I have is so that I upload my html file at google drive, then I search and open it from Drive app on Android via Chrome (the address is content://com.google.android.apps.docs.storage.legacy/enc%3DDn6EKuYHX2T6qZ5aBVFPHfOjKK0lUZPxob15lYj-k4JzL6iL%0A) which points to phone storage.

I understand the general requirement here concerning the security, so it is up to somebody of you to decide whether this is a secure context or not.

Anyway, thank you for the reply.

Jaroslav

Hi, 

I have made some tests. When I download the file via the Drive app, the file appears in Download directory at internal storage (file:///storage/emulated/0/Downloads/refuge.html). When I open the same file at internal storage via e.g. Samsung MyFiles, then I got the content://0@media/external/file/7795, which practically references the same file, but in this case, I have the powerful features not available.

Thank you,
Jaroslav

This seems to be a feature request, same behavior is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged for further inputs from dev team.

Thanks!

I don't know enough about how `content://` works on Android to understand whether it ought to be considered "secure enough" for the kinds of APIs we lock to secure contexts. Does it only allow access of static files on disk? Does it have some ability to read data from the network? Do we actually display/link to `content:` from the web at large, or is this really only a concern for WebView?

torne@: Can you help me understand the impact here? If it's basically the same as `file:`, then there's probably not much risk to treating it similarly for purposes of the Secure Contexts spec. If it's different in interesting ways, we might make a different decision.

Android content providers are just an IPC-exposed service that any app can declare any number of, and the app is responsible for parsing the URL parameters itself. Many apps use the parameters to construct SQL database queries (not necessarily safely). They can return any data they like as the result, dynamically constructed or not, and if the application that implements the content provider has internet access, then it can certainly trigger network requests inside that app - there's nothing preventing an app from providing a content provider that was just a crude HTTP proxy, for example.

I doubt content: URLs are referenced or linked to on the web at large in any way that isn't probably malicious or simply broken. I don't think Chrome even allows this currently, in fact? (it probably shouldn't?)

However, what I believe it does allow is the reporter's case, which is probably quite common: Android devices often expose downloaded files via a content provider, so that calling applications need not have arbitrary access to the SD card (required to load file:// URLs from the download directory) and so that the actual storage location of the downloaded file is abstracted in a flexible way. So, "launching" a downloaded file which is of a MIME type that's associated with Chrome may launch Chrome with an intent whose initial URL is content://something

Inside WebView it's probably more likely that they are actually used as subresources/links, though I don't really know how common that is?

Some content providers provide a way to request the actual on-disk location of a content: URL that refers to a file, such that the caller, if they have the required disk access permissions, can directly open the file itself. Chrome could probably do this in some cases, but i'm not sure whether this is standardised in android or not - it might require whitelisting specific content providers that are known to expose this capability in a particular way?