Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add webUtils module with getPathForFile method #38776

Merged
merged 22 commits into from Nov 20, 2023

Conversation

MarshallOfSound
Copy link
Member

@MarshallOfSound MarshallOfSound commented Jun 13, 2023

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

@MarshallOfSound MarshallOfSound requested a review from a team as a code owner June 13, 2023 22:48
@electron-cation electron-cation bot added the new-pr 🌱 PR opened in the last 24 hours label Jun 13, 2023
docs/api/blink-utils.md Outdated Show resolved Hide resolved
Copy link
Member

@ckerr ckerr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's here so far LGTM.

Agree on the TODO for adding tests. I have no opinion on the naming but surely the API WG will want to bikeshed 😸

Copy link
Member

@dsanders11 dsanders11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another todo: note deprecation of .path in docs/breaking-changes.md

shell/renderer/api/electron_api_blink_utils.cc Outdated Show resolved Hide resolved
@jkleinsc jkleinsc added the semver/minor backwards-compatible functionality label Jun 14, 2023
@dsanders11
Copy link
Member

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

Copy link
Member

@zcbenz zcbenz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

API LGTM

The API name is fine to me, but I'm also good with other alternatives.

shell/renderer/api/electron_api_blink_utils.cc Outdated Show resolved Hide resolved
@jkleinsc
Copy link
Contributor

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.

Copy link
Contributor

@itsananderson itsananderson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The old File.path augmentation always struck me as a weird privacy gap because AFAIK there's no way to prevent an "untrusted" renderer from accessing the full path of an uploaded file. 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.

docs/api/file-object.md Outdated Show resolved Hide resolved
@electron-cation electron-cation bot removed the new-pr 🌱 PR opened in the last 24 hours label Jun 20, 2023
@MarshallOfSound
Copy link
Member Author

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
Copy link
Contributor

miniak commented Jun 23, 2023

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

@MarshallOfSound
Copy link
Member Author

@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
Copy link
Contributor

miniak commented Jun 23, 2023

@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
Copy link
Contributor

miniak commented Jun 23, 2023

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

@MarshallOfSound
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Contributor

miniak commented Jun 26, 2023

API LGTM

@jkleinsc jkleinsc changed the title feat: add blinkUtils module with getPathForFile method feat: add webUtils module with getPathForFile method Jun 26, 2023
Copy link
Contributor

@jkleinsc jkleinsc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requesting changes so that this doesn't get merged without tests.

MarshallOfSound and others added 9 commits September 1, 2023 00:25
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.
@MarshallOfSound
Copy link
Member Author

Both test failures are known flakes, merging

@MarshallOfSound MarshallOfSound merged commit d6bb9b4 into main Nov 20, 2023
14 of 16 checks passed
@MarshallOfSound MarshallOfSound deleted the replace-file-path branch November 20, 2023 23:59
Copy link

release-clerk bot commented Nov 20, 2023

Release Notes Persisted

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

MrHuangJser pushed a commit to MrHuangJser/electron that referenced this pull request Dec 11, 2023
* feat: add blinkUtils module with getPathForFile method

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.

* add error

* refactor: update per PR feedback

* chore: update patches

* oops

* chore: update patches

* chore: update patches

* feat: add blinkUtils module with getPathForFile method

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.

* add error

* refactor: update per PR feedback

* chore: update patches

* oops

* chore: update patches

* chore: update patches

* chore: update patches

* fix: provide isolate to WebBlob::FromV8Value

* chore: add tests

* build: fix depshash mismatch on arm64 macOS

---------

Co-authored-by: PatchUp <73610968+patchup[bot]@users.noreply.github.com>
@nornagon nornagon mentioned this pull request May 6, 2024
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants