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

Add a way to prevent injecting extension content_scripts to certain webContents #23616

Closed
3 tasks done
sentialx opened this issue May 15, 2020 · 9 comments
Closed
3 tasks done

Comments

@sentialx
Copy link
Contributor

sentialx commented May 15, 2020

Preflight Checklist

  • I have read the Contributing Guidelines for this project.
  • I agree to follow the Code of Conduct that this project adheres to.
  • I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Ref #19447

Problem Description

Currently, extensions content_scripts are being injected into all webContents in a given session. There's no way to exclude certain webContents from injecting content_scripts.

Proposed Solution

  • Expose an API in session or a parameter in session.loadExtension which accepts an array of webContents excluded from content_scripts injection, or
  • expose an event in session like before-content-scripts which passes webContents and e.preventDefault() would cancel the injection.

Alternatives Considered

None.

@MarshallOfSound
Copy link
Member

Exposing APIs for filtering things like certain features of chrome extensions from accessing specific webContents is a non-trivial quantity of work especially given the surface area of all the chrome extension APIs that could in theory touch a specific renderer / webContents.

My suggestion would be to put webContents you don't want to receive the content scripts in a different session. The purpose of us using the upstream implementation of chrome extensions was to reduce the amount of patching and hackery we had around making this work, adding these events would add a large amount of complexity IMO

@sentialx
Copy link
Contributor Author

@MarshallOfSound I wonder if making a different session just for a BrowserWindow uses more resources...

@MarshallOfSound
Copy link
Member

It might end using slightly more disk as the cache for sessions is separate, but their shouldn't be any runtime penalty

@sentialx
Copy link
Contributor Author

sentialx commented May 18, 2020

@MarshallOfSound I think it should be reopened. There's an another problem. What if I wanted to prevent content scripts from injecting to i.e URLs starting with wexond:// the same as Chrome does? Chrome extensions are not privileged to inject content_scripts to WebUI context. The same situation with my browser, I don't want to allow injecting content scripts to wexond:// pages.

@sentialx
Copy link
Contributor Author

sentialx commented May 31, 2020

For reference:
Google Chrome with Dark Reader on chrome://newtab:
image

Wexond with Dark Reader on wexond://newtab:
image

@nornagon
Copy link
Member

nornagon commented Jun 4, 2020

I think it makes sense to be able to disable loading extensions on certain custom protocols. I'm unsure about doing it on a domain basis or on an individual webcontents basis, but that could plausibly make sense too (how does that interact with the domains that extensions request access to in their manifest files?)

@RangerMauve
Copy link

I think setting it for certain protocols would be sufficient, TBH. Maybe even a new option inside registerSchemesAsPrivileged?

@RangerMauve
Copy link

Seems like as of electron 9.0.5, the extension's content scripts are only running on http and https protocols. 🤔

I'm testing it with my web-palette extension which should be matching ['<all-urls>']

@sentialx
Copy link
Contributor Author

sentialx commented Dec 3, 2020

I'm closing this issue in favor of #26812

@sentialx sentialx closed this as completed Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants