Add support for emitting isTrusted=true events from the chrome extension content script

[Daniel]

Hi Devs!

I'm building an extension that enables users to control browser by the means other than mouse and keyboard. Sounds like an easy task of mapping whatever the other control system is to the corresponding mouse / keyboard events and emitting them. The problem though is that since those events are emitted as non-trusted they end up being ignored most of the time. I do appreciate the care taken to improve security with this feature but would also love to have a good balance between security and dev experience/possibilities.     

Would it be possible/make sense to introduce a new MV3 permission that would allow the content scripts to produce trusted events?

Conceptually, feels like such a possibility would quite fit the overall idea of extensions empowering users to automate tedios tasks (compare to things like pyautogui) if done without sacrificing security.

P.S. Similar discussion once sparked long time ago at the end of this conversation but the use case was quickly deemed unworthy at the time.

[guest271314]

I think you can achieve the requirement now using chrome.scripting.executeScript(), among other approaches. I would not expect a swift response to your feature request. What issues are you having?

[Dave Tapuska]

You should be able to use the chrome.debugger API to send an input injection event. 

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/252ffcbd-5692-46fc-a7a8-58e759b3e306n%40chromium.org.

[Dave Tapuska]

You can also use the automation API. I'm not sure but it might only be available on dev channel but that might work for your use case.

On Tue, Jan 24, 2023 at 2:11 PM Daniel <cyber.b...@gmail.com> wrote:

Yes, chrome.debugger API seems to be the only thing that is capable of emitting isTrusted=true events but it's designed to be used in conjunction with, well, debugging. It creates a debugging session, halts client JS execution, etc. All this is highly undesirable (totally unrelated) when the extension merely promises to give a user an alternative input source to control the browser.

Just double checked. All mouse/keyboard events created via chrome.scripting.executeScript also end up being isTrusted=false. The issue in a nutshell is that since all mouseover/mouseout/etc. events produced from extension scripts are inevitably isTrusted=false a sizeable bulk of extensions that focus on alternative input source and/or user<->browser iteration automation become almost unfeasible to develop.

Again, I totally support the fact that script-produced events are isTrusted=false since it helps a lot with preventing user control highjacking malware. My point is that within the framework of chrome extensions that 

    a) are being reviewed before publishing 

    b) already allow access/control of way more "intimate" things through MV3 permission system    

there should be a way to emit trusted events (other than for debugging).

[Daniel]

Yes, chrome.debugger API seems to be the only thing that is capable of emitting isTrusted=true events but it's designed to be used in conjunction with, well, debugging. It creates a debugging session, halts client JS execution, etc. All this is highly undesirable (totally unrelated) when the extension merely promises to give a user an alternative input source to control the browser.

Just double checked. All mouse/keyboard events created via chrome.scripting.executeScript also end up being isTrusted=false. The issue in a nutshell is that since all mouseover/mouseout/etc. events produced from extension scripts are inevitably isTrusted=false a sizeable bulk of extensions that focus on alternative input source and/or user<->browser iteration automation become almost unfeasible to develop.

Again, I totally support the fact that script-produced events are isTrusted=false since it helps a lot with preventing user control highjacking malware. My point is that within the framework of chrome extensions that 

    a) are being reviewed before publishing 

    b) already allow access/control of way more "intimate" things through MV3 permission system    

there should be a way to emit trusted events (other than for debugging).

On Tuesday, January 24, 2023 at 3:06:23 AM UTC+1 dtap...@chromium.org wrote:

[Dave Tapuska]

You are redefining the definition of istrusted then to meet your needs. And you'd need an adjustment to the DOM specification. 

The definition of isTrusted is who called dispatchEvent. Was it the user agent or a JavaScript callee?

It's far better to add an API that extensions can call (chrome.automation or the chrome.debugger) which can be gated on extension permissions than to arbitrarily change the implementation of dispatchEvent. 

On Wed, Jan 25, 2023, 3:17 AM Billy Bradley <billy.jac...@gmail.com> wrote:

This seems like a good suggestion. I'd even go as far as to suggest that all events from extension content scripts should be trusted. The entire concept of extensions is based on the assumption that they are trusted. An evil content script can already do arbitrary script injection, keylogging, etc. This suggestion makes extensions more powerful without meaningfully impacting security.

[guest271314]

If you want to get a trusted event you can call new Notification() with executeScript() when chrome.action is clicked when user activates notification the onclick attached to Notification event will be trusted. You can also use navigator.permissions.request() for some cases. Why is a trusted event needed? What is the use case?

On Wed, Jan 25, 2023 at 4:27 AM Billy Bradley <billy.jac...@gmail.com> wrote:

My needs? No, I'm not. I have no need for this change. I'm thinking of the needs of other people.

It's not really so clear cut. I don't see why a content script shouldn't be considered part of the user agent. The user agent is the browser and a browser extension is an extension of this user agent. To my knowledge the DOM spec doesn't address browser extensions directly - it makes a distinction between user agent and application. It surely makes more sense to consider an extension to be part of the user agent than part of the application.

Then again, the spec does state that dispatchEvent sets isTrusted = false, so you're right. Maybe an API function for content scripts to dispatch trusted events would be the best solution.

[Billy Bradley]

This seems like a good suggestion. I'd even go as far as to suggest that all events from extension content scripts should be trusted. The entire concept of extensions is based on the assumption that they are trusted. An evil content script can already do arbitrary script injection, keylogging, etc. This suggestion makes extensions more powerful without meaningfully impacting security.

On Tuesday, 24 January 2023 at 23:57:34 UTC cyber.b...@gmail.com wrote:

[Billy Bradley]

My needs? No, I'm not. I have no need for this change. I'm thinking of the needs of other people.

It's not really so clear cut. I don't see why a content script shouldn't be considered part of the user agent. The user agent is the browser and a browser extension is an extension of this user agent. To my knowledge the DOM spec doesn't address browser extensions directly - it makes a distinction between user agent and application. It surely makes more sense to consider an extension to be part of the user agent than part of the application.

Then again, the spec does state that dispatchEvent sets isTrusted = false, so you're right. Maybe an API function for content scripts to dispatch trusted events would be the best solution.

On Wednesday, 25 January 2023 at 11:32:38 UTC dtap...@chromium.org wrote: