Intent to Deprecate and Remove: Support for filesystem URLs on Android media

258 views
Skip to first unread message

Brianna Goldstein

unread,
Jan 25, 2022, 4:58:09 PM1/25/22
to blin...@chromium.org

Primary eng (and PM) emails

brgol...@google.com, m...@chromium.com, jadek...@chromium.com


Explainer

Storage partitioning explainer


Summary

We propose to remove support for loading media via filesystem:// URLs on Android.



Motivation

As part of our storage partitioning efforts, we will need to update Filesystem URLs to be partitioned by StorageKey rather than by Origin. Doing this will add complexity since the entire current codepath on Android is not dependent on Blink where StorageKey currently lives. On Android only 0.0000001% of URLs loaded by <audio> or <video> use the filesystem:// URL scheme and we consider this low enough usage to remove support, rather than do the work of partitioning. Note that this removal is only for Android. On other platforms there will be no effect and media playback of filesystem:// URLs will continue to work.


Blink component

Blink>Storage


Initial public proposal 

None


TAG review

None


TAG review status

N/A


Interoperability and Compatibility Risk

Interoperability risk:

The filesystem:// URL scheme was never widely adopted and is only implemented by Chrome. Therefore there should be no interoperability risks associated with this feature depreciation.


Compatibility risk:

This feature is very low usage as only 0.0000001% of URLs loaded by <audio> or <video> use the filesystem:// URL scheme. Therefore the expected compatibility risk is very low.


Alternative implementation suggestion for web developers

Developers can continue to load media from other schemes (http, https, blob, file, etc.).


Usage information from UMA

Android Chrome (Browser App): 0.0000001%

Android Webview: 0.0%


Tracking Bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1258029


Entry on the feature dashboard

https://chromestatus.com/feature/5632429577469952


Chris Harrelson

unread,
Jan 25, 2022, 7:13:45 PM1/25/22
to Brianna Goldstein, blink-dev
Hi, could you outline the use counter values for other platforms? Also, is there something special about Android that leads you to want to disable only there?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALDP-vS2KA47PGLh3YkxqAr9z24nP1_u%2BtvY6eWzqSQgq987cQ%40mail.gmail.com.

Daniel Bratell

unread,
Jan 26, 2022, 5:41:17 AM1/26/22
to Chris Harrelson, Brianna Goldstein, blink-dev

How confident can we be in the WebView counter? I'd expect this to be used more in WebView than on other platforms.

/Daniel

Yoav Weiss

unread,
Jan 26, 2022, 10:49:26 AM1/26/22
to blink-dev, Daniel Bratell, blink-dev, Chris Harrelson, Brianna Goldstein
At the risk of piling on with another question: are these URLs different from `file://` scheme URLs?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Brianna Goldstein

unread,
Jan 26, 2022, 11:23:35 AM1/26/22
to Daniel Bratell, Yoav Weiss, Chris Harrelson, blink-dev
Hey all, 

To answer your questions -

@Chris Harrelson  The reason we want to remove support from Android specifically is that the media playback codepath is completely different on Android. Other platforms use the normal URL loading but on Android there is a custom code path which is difficult to partition by the new StorageKey. Since it's extremely rare that media is loaded this way we've decided to drop support rather than leave it vulnerable as an unpartitioned path.

@bratell.d This is actually not currently supported for WebView, we turn it off here.

@Yoav Weiss yes these are from the `filesystem://` scheme which is different from `file://`. Here's some information about where this scheme comes from.

Rick Byers

unread,
Jan 26, 2022, 11:23:46 AM1/26/22
to Yoav Weiss, blink-dev, Daniel Bratell, Chris Harrelson, Brianna Goldstein
Yoav, yeah this is a bit of rarely used legacy, see FileSystemEntry.toURL.  IIRC we used filesystem URLs in Offline GMail to enable opening email attachments while offline. I think this provided a better UX than blob: URLs because of the existence of a human readable file name, but I can't remember if there were other reasons filesystem: URLs were essential.

It does seem like a wart to me to have filesystem: URLs continue to work everywhere EXCEPT media on Android, but given the very low usage I think I'd be OK considering this an open low-priority bug in the platform to potentially be fixed in the future based on the level of partner demand. Thoughts?

Checking the WebView UseCounter is a good idea, but I suspect it'll be very low since I think apps would generally prefer to load resources directly out of the bundle with file: URLs, not the virtual web-only filesystem created by the Filesystem APIs.

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1f198100-936d-41e3-8952-826c9bb0b9ban%40chromium.org.

Brianna Goldstein

unread,
Jan 26, 2022, 1:48:54 PM1/26/22
to Chris Harrelson, blink-dev
Additionally to follow up on @Chris Harrelson's question on usage - Chrome OS usage is 1.38%, Mac OSX is at 0.12% and Windows is 0.05%. We propose to only remove support for Android here.

Mike West

unread,
Feb 1, 2022, 4:32:25 AM2/1/22
to blink-dev, Brianna Goldstein, blink-dev, Chris Harrelson, Joshua Bell, Victor Costan
I worry that removing `filesystem:` for media elements on Android, while maintaining support for other platforms, will end up causing some developer confusion without much value for the codebase as a whole (since we need to maintain all the exciting bits and pieces of infrastructure). Are the numbers you quoted for media elements on those other platforms, or all element types? Perhaps we could remove support for media elements on all platforms if there's substantial benefit to doing so.

Honestly, I'd prefer that we outline a plan to fully remove `filesystem:` if we're not going to support it going forward (+Josh and +Victor). It has some pretty complicated effects on the security state of navigations, and while we have a reasonable plan for PolicyContainer integration with `blob:` URLs, we're still a ways away from doing the same for `filesystem:`. Is there a path towards deprecating and dropping support on other platforms? The large ChromeOS usage makes me somewhat suspicious that this is wrapped up in one Google property or another... have y'all done that analysis?

-mike
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Victor Costan

unread,
Feb 1, 2022, 12:17:27 PM2/1/22
to Mike West, blink-dev, Brianna Goldstein, Chris Harrelson, Joshua Bell
Some background:
  • The filesystem: URL scheme was introduced to the File API: Directories and System specification, which I generally refer to as the old FileSystem API. This API is only implemented in Blink (maybe it was in the pre-fork WebKit?). To the best of my knowledge, it was never shipped in Safari, Firefox, IE, or EdgeHTML.
  • The main benefit (for developers) of filesystem: URLs over blob: is their indefinite lifetime. Blob URLs only live as long as the frame that created them. This property made them very attractive for serving sub-resources stored locally, at a time when we didn't have Service Workers.
  • We intentionally left the filesystem: URL scheme out of the File System Access API. Service Workers have a clear model that works well for both top-level navigation and sub-resources.
We (the folks maintaining storage APIs in Chromium) would very much like to deprecate the entire old FileSystem API, beginning with the filesystem: URL scheme. We want to be cognizant of introducing too much stress on the ecosystem, though -- we just finished removing AppCache from Blink, and we're planning to focus on WebSQL next. Though, maybe you're saying that filesystem: URLs are worse, and we should tackle them first?

I hope this helps!
    Victor





To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Rick Byers

unread,
Feb 1, 2022, 4:47:45 PM2/1/22
to Victor Costan, Mike West, blink-dev, Brianna Goldstein, Chris Harrelson, Joshua Bell
Given the plan to deprecate this blink-only technology, it does seem silly to do extra work to keep this one obscure case working. I agree though that developer confusion is a potential concern. Perhaps an exception / window.onerror explaining the reason for the failure to play media is enough? +1 to having a deprecation plan we can point to for at least the filesystem: URL, then perhaps this can just be the first step in that plan?

Rick

Alex Russell

unread,
Feb 2, 2022, 11:50:21 AM2/2/22
to blink-dev, Rick Byers, Mike West, blink-dev, Brianna Goldstein, Chris Harrelson, Joshua Bell, Victor Costan
While others weight in on the specific intent, I'd like to see the addition of handling Response objects (potentially directly from the Cache Storage) API added to Media elements as a replacement for this. Folks shouldn't have to need to install a Service Worker to do this directly, and it would cover many of these use-cases as we look to remove this more globally.

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Mike West

unread,
Feb 2, 2022, 11:58:36 AM2/2/22
to blink-dev, Rick Byers, Mike West, blink-dev, Brianna Goldstein, Chris Harrelson, Joshua Bell, Victor Costan
Thanks for the background, Victor! To your question: I don't think dropping `filesystem:` is more important than dropping WebSQL, but I share your excitement about deprecating the filesystem API.

Brianna, I'm still interested in understanding whether the numbers you posted for other platforms reflect usage in media elements or usage overall. If the numbers for media elements specifically on all platforms are as low as they are on Android, I'd prefer for us to remove usage through media elements everywhere. That seems more consistent and explainable if we can get away with it.

-mike

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Rick Byers

unread,
Feb 2, 2022, 12:07:10 PM2/2/22
to Mike West, blink-dev, Brianna Goldstein, Chris Harrelson, Joshua Bell, Victor Costan
+1 to removing on all platforms if the numbers are low enough.

But if the compat risk is materially greater on at least one other platform than on Android, I personally could accept removal just on Android as an acceptable first step on the deprecation path.

Rick

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Brianna Goldstein

unread,
Feb 2, 2022, 12:22:23 PM2/2/22
to Mike West, blink-dev, Rick Byers, Chris Harrelson, Joshua Bell, Victor Costan
Mike, these numbers are for media elements specifically. Since Chrome OS is > 1% I'd suggest removing `filesystem://` from Android as a first step in deprecating across platforms rather than leaving the Android path unpartitioned and then following up with a depreciation path to deprecate across platforms.

Brianna

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
Feb 2, 2022, 2:11:53 PM2/2/22
to Brianna Goldstein, Mike West, blink-dev, Rick Byers, Joshua Bell, Victor Costan
Here are two more questions and one suggestion:

1. It looks like the usage on ChromeOS is an outlier. Is this due to Chrome Apps? Do we have UKM on it?
2. Is a migration to ServiceWorkers a simple drop-in replacement or would it require significant work for a site to adopt?
3. Do you think the larger deprecation is feasible to do over the next year, based on data you have now? If so I wonder if we could go with a deprecation message now and a reverse origin trial & outreach to drive down usage.

Frédéric Wang

unread,
Feb 3, 2022, 6:34:57 AM2/3/22
to blin...@chromium.org
Hello,

filesystem: URLs were one of the remaining proprietary behavior when I was trying to unify the notions of "secure context" in Chromium [1]. I support a plan for unshipping it.

To elaborate a bit, a URL is potentially trustworthy if its origin is potentially trustworthy [2]. But Chromium determines the origin of filesystem: URLs the same as blob: URLs, instead of treating them as opaque origins per the WHATWG spec [3] [4].

So maybe that's a silly idea, but perhaps another intermediate step before full removal would be to stop treating filesystem: URLs as trustworthy if their origin is trustworthy? That would be an easy way to limit what web developers can do with filesystem: URLs, while still keeping the core support in place.

[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/2fNfT6DEWJo
[2] https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy
[3] https://url.spec.whatwg.org/#concept-url-origin
[4] https://github.com/w3c/webappsec-secure-contexts/pull/89

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8670f31d-d4d2-443f-8757-250bb5611cdbn%40chromium.org.


-- 
Frédéric Wang

Nigel Tao

unread,
Feb 3, 2022, 8:37:55 PM2/3/22
to Brianna Goldstein, Daniel Bratell, Yoav Weiss, Chris Harrelson, blink-dev
On Thu, Jan 27, 2022 at 3:23 AM Brianna Goldstein
<brgol...@chromium.org> wrote:
>On Thu, Jan 27, 2022 at 2:49 AM Yoav Weiss <yoav...@chromium.org> wrote:
>> At the risk of piling on with another question: are these URLs different from `file://` scheme URLs?
>
> @Yoav Weiss yes these are from the `filesystem://` scheme which is different from `file://`. Here's some information about where this scheme comes from.

I'll ask another naive question...

I understand "file://" URLs. "file:///home/user/bar.txt" is an example.

Can you give some examples of "filesystem://" URLs? Do they look like
"filesystem:///home/user/bar.txt" or
"filesystem://example.domain/foo/bar.txt" or something else? Do these
URLs look different for Android versus Desktop? Do they look different
for Browser App versus Web View?

Your "Here's" link points to
https://www.iana.org/assignments/uri-schemes/historic/filesystem which
doesn't give an example, nor does the
https://www.w3.org/TR/file-system-api/ or
http://www.html5rocks.com/en/tutorials/file/filesystem/ (which
redirects to https://web.dev/read-files/) links from its references.

pwnall@ later linked to
https://dev.w3.org/2009/dap/file-system/file-dir-sys.html and
https://wicg.github.io/file-system-access/ and the only example URL is
"Proposal currently under discussion: Use a format such as
filesystem:http://example.domain/persistent-or-temporary/path/to/file.html"
but even if it's more than a proposal, I'm not sure if that's a legit
URL if it doesn't have a double-slash after the first colon.

Mike Taylor

unread,
Feb 3, 2022, 9:16:55 PM2/3/22
to Nigel Tao, Brianna Goldstein, Daniel Bratell, Yoav Weiss, Chris Harrelson, blink-dev
On 2/3/22 8:37 PM, Nigel Tao wrote:
> On Thu, Jan 27, 2022 at 3:23 AM Brianna Goldstein
> <brgol...@chromium.org> wrote:
>> On Thu, Jan 27, 2022 at 2:49 AM Yoav Weiss <yoav...@chromium.org> wrote:
>>> At the risk of piling on with another question: are these URLs different from `file://` scheme URLs?
>> @Yoav Weiss yes these are from the `filesystem://` scheme which is different from `file://`. Here's some information about where this scheme comes from.
> I'll ask another naive question...
>
> I understand "file://" URLs. "file:///home/user/bar.txt" is an example.
>
> Can you give some examples of "filesystem://" URLs? Do they look like
> "filesystem:///home/user/bar.txt" or
> "filesystem://example.domain/foo/bar.txt" or something else? Do these
> URLs look different for Android versus Desktop? Do they look different
> for Browser App versus Web View?

Here's some sample code to illustrate how to get a filesystem URL:
https://gist.github.com/miketaylr/df58ae669abc4eec1b514f4cfc71fc21 -
pasted below as well

```

function writeFile(fs) {
  fs.root.getFile("coolguy.txt", {create: true}, fileEntry => {
    fileEntry.createWriter(fileWriter => {
      fileWriter.onwriteend = e => {
        window.webkitRequestFileSystem(window.TEMPORARY, 1024, readFile);
      };
      fileWriter.write(new Blob(["😎😎😎"], {type: "text/plain"}));
    });
  });
}

function readFile(fs) {
  fs.root.getFile("coolguy.txt", {}, fileEntry => {
    fileEntry.file(file => {
      const reader = new FileReader();
      reader.onloadend = e => {
        console.log(e, fileEntry.toURL());
      };
      reader.readAsText(file);
    });
  });
}

navigator.webkitTemporaryStorage.requestQuota(1024, granted => {
  window.webkitRequestFileSystem(window.TEMPORARY, granted, writeFile);
});

```

PhistucK

unread,
Feb 4, 2022, 3:26:58 AM2/4/22
to Nigel Tao, Brianna Goldstein, Daniel Bratell, Yoav Weiss, Chris Harrelson, blink-dev
I'm not sure if that's a legit URL if it doesn't have a double-slash after the first colon.
Double-slash is not a requirement for all URL/URIs, for example, data:text/html,bla. file: uses triple-slash and so on...
(Not entirely sure regarding URL versus URI, if you meant specifically the former and not the latter)
The scheme/protocol specifies the format after the colon, but the general "how to write a URL/URI" does not mandate anything in this regard, I think.

PhistucK


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Brianna Goldstein

unread,
Feb 8, 2022, 8:44:28 PM2/8/22
to PhistucK, Nigel Tao, Daniel Bratell, Yoav Weiss, Chris Harrelson, blink-dev

Hey all, following up with a proposed plan for moving forward here -


The Chrome Storage team considers the old Filesystem API to be an undesirable API, one that should eventually be deprecated and removed. Our short-term goal is to partition storage APIs, but Android media playback from filesystem:// URLs is the one codepath where this is not easily done. Given it’s near-zero usage, we’d like to remove it instead. However, it is a bit awkward to only remove this one use case on this one platform, especially since we want to eventually remove it everywhere. So, in order to meet both our short-term needs and the Storage team’s long-term goals we propose the following:


  1. Remove support for media playback from filesystem:// URLs on Chrome on Android (the original proposal in this thread).

  2. Remove support for media playback from filesystem:// across all platforms. 

  3. Eventually, remove support for filesystem://.


In order to get to steps 2 and 3 we need to:

  1. Formally deprecate filesystem://, sending devtools Issues and deprecation reports. We’ll work on I2Ds for both 2 and 3 with detailed timelines (as they emerge).

  2. Add an Enterprise policy to allow more time for migration, and possibly a deprecation trial as well

  3. Work with DevRel to write an article recommending workarounds and a migration path

  4. Work with internal and external partners to ensure we can drive down usage to a level where we’re comfortable removing filesystem://. We’ll focus efforts on ChromeOS media playback first.

  5. Investigate adding capabilities to the platform that addresses the use cases of media playback from Cache storage without requiring a ServiceWorker



Brianna

Yoav Weiss

unread,
Feb 9, 2022, 3:09:25 AM2/9/22
to Brianna Goldstein, PhistucK, Nigel Tao, Daniel Bratell, Chris Harrelson, blink-dev
That sounds generally reasonable to me, with the main caveat being that deprecations require a clear timeline, and having one requires understanding of usage and having a plan for driving it down.
It might be worthwhile to dig into usage and see who the main culprits are, and then try some targeted outreach to get them to move off of filesystem://


chrishtr via Chromestatus

unread,
Feb 9, 2022, 11:51:12 AM2/9/22
to blin...@chromium.org
The deprecation plan sounds great to me, thanks! LGTM1

Yoav Weiss

unread,
Feb 9, 2022, 12:03:10 PM2/9/22
to blink-dev, chrishtr via Chromestatus
LGTM2

Daniel Bratell

unread,
Feb 9, 2022, 12:21:21 PM2/9/22
to Yoav Weiss, blink-dev, chrishtr via Chromestatus

LGTM3 to remove filesystem:// on Android only for now.

For whoever files the deprecation for the other platforms, I want to second what Yoav said about deprecations needing a time limit. Deprecations without time limits are not effective and we avoid those.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

jmedley via Chromestatus

unread,
Feb 10, 2022, 9:58:22 AM2/10/22
to blin...@chromium.org
Which version are you hoping to ship in?

jmedley via Chromestatus

unread,
Mar 24, 2022, 1:45:55 PM3/24/22
to blin...@chromium.org
Is the deprecation starting in 101? I need to know soon.
Reply all
Reply to author
Forward
0 new messages