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

Publish minutes of extra TPAC 2023 meetings #459

Merged
merged 1 commit into from
Oct 24, 2023

Conversation

Rob--W
Copy link
Member

@Rob--W Rob--W commented Sep 30, 2023

Generated from (non-public) https://docs.google.com/document/d/1ebrHySL0oag2u3gnXogM8LuahT397kKDNVRFYQDWy-8/edit using the tool and process from #105.

During these face-to-face meetings at TPAC 2023 (#385) we discussed #433, #414, #403, #113, #438, #251, #338, #431, #450, #316, #293, #387, #440, #238, #365.

@Rob--W Rob--W mentioned this pull request Sep 30, 2023
* [rob] You want to get the handle to communicate across contexts. If comms are supported as part of the userScript API you don't need this. But otherwise this primitive would enable you to communicate between worlds (isolated world and user script world). In the userScripts API design, have you considered synchronous communication between user script and manager?
* [oliver] is the reason for that to cancel an event?
* [rob] There are user script APIs that are synchronous (GM_getValue), changing that would break existing scripts. Admittedly, without special API support, it would be possible to establish an initially secure communication channel between the isolated world and the user script world, by saving copies of prototypes and using a secret event name to communicate.
* [devlin] Having a communication channel is something we'll pursue, but I don't know that I'd comment to it being synchronous. User scripts, I hope, won't have that much data associated with them. You could asynchronously update the data exposed by the user script manager.
Copy link

Choose a reason for hiding this comment

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

Many popular userscripts absolutely need to run before the first JS statement of the page even if it's an inline <script>alert(1)</script> and they need their config synchronously at document_start.

* [rob] MV2 Chrome extensions can currently inject an inline script element, a primitive that is also built upon in the user scripts API. MV3 extensions can't do so due to the default CSP, and Firefox extensions cannot bypass the page's CSP to permit inline scripts either. Rather than disabling the script execution restrictions, I would prefer a dedicated API to run specific scripts from the content script.
* [devlin] Why wouldn't the extension use scripting.executeScript?
* [rob] if there's a way to directly invoke from a content script, this could be extended to pass a handle to communicate between the main and isolated world. There are classes of extensions that want to run a trusted piece in the main world and have a trusted piece of code in an isolated script.
* [devlin] It's impossible to have a trusted main world script.
Copy link

Choose a reason for hiding this comment

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

It's possible, but it's very hard, particularly because of https://crbug.com/1261964, see how Tampermonkey or Violentmonkey do it via a detached iframe + closed shadow DOM + extraction of prototypes and careful use of those.

Comment on lines +229 to +231
* [tomislav] lets separate externally_connectable from this, and only focus on the extension world. Safari does not support externally connected right?
* [kiara] no, we do support it
* [tomislav] oh, ok. I was out of date. Can we discuss the two concepts separately
Copy link
Collaborator

Choose a reason for hiding this comment

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

We do support it, and had to only expose window.browser to pages since in our very limited testing we saw pages thinking Safari was Chrome because window.chrome existed.

Comment on lines +248 to +249
* [patrick] Is there a reason we can't expose browser as an alias?
* [devlin] That's largely what we're discussing.
Copy link
Collaborator

Choose a reason for hiding this comment

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

It is an alias in Safari, window.chrome === window.browser.

@Rob--W Rob--W force-pushed the meeting-2023-09-11-2023-09-14-tpac-extra branch from 52d7ee8 to a9770d5 Compare October 12, 2023 16:07
@Rob--W
Copy link
Member Author

Rob--W commented Oct 12, 2023

@oliverdunk Is there anything to add/modify before merging it? The meeting notes are supposed to reflect the discussion that has taken place; if there is anything more, we can discuss that separately in new issues or in the biweekly meetings.

Copy link
Member

@oliverdunk oliverdunk left a comment

Choose a reason for hiding this comment

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

I only had a chance to skim this but assuming it's just a tidied up version of the doc we reviewed, I'm happy :)

@Rob--W Rob--W merged commit 9ffddf6 into main Oct 24, 2023
1 check passed
@Rob--W Rob--W deleted the meeting-2023-09-11-2023-09-14-tpac-extra branch October 24, 2023 14:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants