feat: add webUtils module with getPathForFile method

[MarshallOfSound]

This is designed to replace the File.path augmentation we currently have in place to allow apps to get the filesystem path for a file that blink has a representation of.

File.path is non-standard and messes with certain websites, using a method like this is effectively 0-cost and removes one of the final deviations we have with web standards.

TODO:

• Bikeshed of blinkUtils namespace
• Bikeshed over getPathForFile method name
• Tests

Notes: Added new webUtils.getPathForFile method to replace File.path augmentation

[dsanders11]

Bikeshed of blinkUtils namespace

I'm not in API WG but my 2 cents on the namespace would be not including blink since that feels a bit too internal/unnecessary detail for end API users.

Possible alternatives:

• webUtils
• rendererUtils

[jkleinsc]

Bikeshed of blinkUtils namespace

I'm not in API WG but my 2 cents on the namespace would be not including blink since that feels a bit too internal/unnecessary detail for end API users.

Possible alternatives:

• webUtils
• rendererUtils

I agree that blinkUtils is a bit esoteric. I think rendererUtils makes sense.

[MarshallOfSound]

If we're going to deprecate the old API, would it be worth considering the privacy implications of the new API, and perhaps having a way to limit its availability? Having a way to enable it in "preload" but disable it in the main world might be useful, for example.

At it's core the file path is available to the renderer process (this just returns a value that blink already had). Following our standard security assumptions this doesn't change the availability of that information to the process. All it does is improve web compatibility with things that don't expect File.path to be present and prevent zero-exploit exposure of that path.

Any permission model we put in place would be self-governing because it would be the renderer guarding itself (which doesn't make sense)

[miniak]

@MarshallOfSound does it make sense to expose this in sandboxed renderers as well?

[MarshallOfSound]

@MarshallOfSound does it make sense to expose this in sandboxed renderers as well?

Per my comment above

At it's core the file path is available to the renderer process (this just returns a value that blink already had).

This isn't exposing any new capabilities to the process, so I think exposing this information to the slightly-more-privileged isolated preload context is perfectly valid 👍

[miniak]

@MarshallOfSound what I mean is that the PR is not doing that, it's not listed in lib/sandboxed_renderer/api/module-list.ts. Even though the path won't be directly usable there due to the sandbox, it might still be useful?

[miniak]

@MarshallOfSound in case it's added there, it should be listed in docs/tutorial/sandbox.md as added by #38568

[MarshallOfSound]

Even though the path won't be directly usable there due to the sandbox, it might still be useful?

Yeah I think it will still be useful because you could take that path (albeit untrusted) and hand it off to the main process to do something with 🤔

[MarshallOfSound]

Thanks for the reviews folks @dsanders11 @ckerr @itsananderson @zcbenz @miniak

I've renamed the module to the suggested webUtils as it's a good home for interactions with "Web" APIs (File, Blob, Etc.). I think I've addressed all the other comments too 👍

[miniak]

API LGTM

[MarshallOfSound]

Both test failures are known flakes, merging

[release-clerk[bot]]

Release Notes Persisted

Added new webUtils.getPathForFile method to replace File.path augmentation