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.

Sign up for GitHub

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

Jump to bottom

Publish minutes of 2023-04-27 meeting #383

Merged
merged 1 commit into from
May 10, 2023
Merged

Publish minutes of 2023-04-27 meeting #383

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
145 changes: 145 additions & 0 deletions _minutes/2023-04-27-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,145 @@
# WECG Meetings 2023, Public Notes, Apr 27

* Chair: Simeon Vincent
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=6449bb00,384
Call-in details: [WebExtensions CG, 27th April 2022](https://www.w3.org/events/meetings/731a34ef-46f2-4ac6-8ae0-b30998883a29/20230427T080000)
Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [discussion in #376](https://github.com/w3c/webextensions/issues/376), [github issues](https://github.com/w3c/webextensions/issues)

The meeting will start at 3 minutes after the hour.

* **Carry-over from previous meetings**
* [Issue 362](https://github.com/w3c/webextensions/issues/362): Proposal: Declarative Cosmetic Rules
* **Other new issues**
* [Issue 378](https://github.com/w3c/webextensions/issues/378): Proposal: Privileged navigator.clipboard for content scripts
* [Issue 379](https://github.com/w3c/webextensions/issues/379): Inconsistency: DNR Redirect Action using regexSubstitution
* [Issue 381](https://github.com/w3c/webextensions/issues/381): Inconsistency: Ability to open extension pages using redirect
* [Issue 380](https://github.com/w3c/webextensions/issues/380): Proposal: Distinguish local/synced items in History API
* [Issue 382](https://github.com/w3c/webextensions/issues/382): Provide a mock way to test upgrade extensions from the extension store
* **Open discussion queue (add yourself at the bottom)**
* <end of list>
* **Check-in on ongoing issues**
* (out of time, moved to next week)


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Tomislav Jovanovic (Mozilla)
3. Oliver Dunk (Google)
4. Luke Selker (Dashlane)
5. Hal Massey (1Password)
6. Timothy Hatcher (Apple)
7. Bradley Cushing (Dashlane)
8. Simeon Vincent (Unaffiliated)
9. Jason Waterman (Mozilla)
10. Carlos Jeurissen (Jeurissen Apps)
11. Dmitriy Seregin (AdGuard)
12. Jackie Han (No affiliation)
13. Benjamin Bruneau (1Password)
14. Maxim Topciu (AdGuard)
15. Kiara Rose (Apple)
16. David Johnson (Apple)
17. Anton Bershanskiy (Dark Reader)
18. Andrey Meshkov (AdGuard)
19. Tim Heflin (Keeper)


## Meeting notes

[Issue 378](https://github.com/w3c/webextensions/issues/378): Proposal: Privileged navigator.clipboard for content scripts

* [rob] The request here is to allow content scripts to have privileged access to navigator.clipboard. The “old” document.execCommand APIs can already interact with the clipboard through the clipboardRead/clipboardWrite permissions. Firefox & Chrome specific notes: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Interact_with_the_clipboard#browser-specific_considerations
* [simeon] Historically, Chrome is reluctant to expose privileged functionality to content scripts because that could allow content (processes) to abuse the functionality. Does docuemnt.execCommand() work without click on a normal webpage?
* [timothy] I'm pretty sure there are
* [simeon] I took us a little into the weeds. My main point is that I tend to think of the security boundary for extension the division between page and extension processes. As such, I prefer to defer to handling sensitive operations in the background & facilitating those operations with message passing in the content script.
* [tomislav] navigator.clipboard is not available to service workers.
* [simeon] right, I'm strongly supportive of addressing that for extension workers.
* [timothy] I'd be supportive of write but not read in content scripts.
* [oliver] I'd like to follow up with the Chrome team here.

[Issue 379](https://github.com/w3c/webextensions/issues/379): Inconsistency: DNR Redirect Action using regexSubstitution

* [timothy] This was a Safari-only bug that has been resolved in Safari Tech Preview. A follow-up bug has been filed (in issue 381). This issue can be closed.

[Issue 381](https://github.com/w3c/webextensions/issues/381): Inconsistency: Ability to open extension pages using redirect

* [luke] Use case is to use identity provider; whenever we redirect to a custom extension page, the request is blocked because it's not a http(s) page.
* [timothy] Are you using a dynamic URL?
* [luke] Yes.
* [timothy] The safari-extension scheme is marked as a secure scheme, so this should work.
* [rob] Recently tried to create an extension using only static rules to redirect to an extension resource. Found that it's impossible because the host component is generally not known in advance, especially with dynamic extension IDs. extensionPath requires a fixed path, regexSubstitution requires the use of regexFilter. Would be nice to support it in “transform”.
* [timothy] I'd be supportive of a way to get the extension ID as a token.
* [tomislav] We could use the existing localization tokens, `__MSG_@@extensionId__`
* [simeon] As a dev, I expect that this means I could use localization.
* [rob] I'm not in favor of supporting localization of static DNR rules because that makes it unnecessarily more complex to load DNR rules.
* [rob] The original issue is Safari-specific and has been resolved, should we repurpose this issue to support transform to extension paths?
* [timothy] Yes, that makes sense.

[Issue 380](https://github.com/w3c/webextensions/issues/380): Proposal: Distinguish local/synced items in History API

* [oliver] I shared a couple links in the issue, but in short we're planning to expose more items in the history API that have been synced from the sync history database.
* [rob] Worried about potential collisions in ID (historyItem.id & visitItem.id). There is currently no way in the API to query history by this ID. Is there a plan to guarantee that this will be a unique or stable ID?
* [oliver] Will need to follow up on this. Wanted to get people's initial impression on having a bool on history entries to indicate if this item has been synced.
* [rob] why would extensions be interested in explicitly having or not having synced items?
* [tomislav] session manager extension. Carry on tasks on this device, from other devices.
* [oliver] Other use case I've seen is new tab page that shows most visited pages on this device.
* [tomislav] I'm overall supportive.
* [jackie] How about delete methods of history?
* [oliver] Deleting is interesting. By default when you delete an item from history it also is deleted from sync. That's already the behavior today.
* [tomislav] I think that's the behavior in Firefox today as well, but would need to double check.
* [timothy] Safari does not support the history API at all. I think that including the remote may make sense.

[Issue 382](https://github.com/w3c/webextensions/issues/382): Provide a mock way to test upgrade extensions from the extension store

* [jackie] It is difficult to test updating of extensions, including permission changes, etc..
* [timothy] This is likely out of scope for the group since this is about the stores.
* [simeon] This is about the experience of updating an extension.
* [simeon] The concern here is that e.g. in Chrome, an update with new permissions would disable the extension. Currently testing this behavior is weird in Chrome. The availability of the API can be tested by dragging the extension to chrome://extensions/, the update path has to be tested by dragging a packed (crx) file to the extension page.
* [rob] Packaging and extension store are out of scope; I linked resources for testing in Firefox and Chrome in the issue. Updating and the relevant considerations around it are very browser-specific, so the closest way to test anything close to realistic is to test the real browser-specific update mechanisms.
* [simeon] I'm thinking of potentially supporting this in WebDriver-bidi, so that extension devs can test the end user experience of applying an upgrade.
* [jackie] I am not asking for a unified way to do this, but a way to do it.
* [rob] This is already possible today, are you familiar with the links that I posted in the issue?
* [jackie] The current mechanism in Chrome (...)
* [oliver] Been thinking about this recently. When testing, I run a local update server to emulate the experience end to end. Potential area for future work, nothing to announce today.
* [timothy] For context, Safari 16.4 now has a similar dialog to Chrome when an extension update has additional permissions. When the extension is built in Xcode, Safari has the same flow that makes testing of this easier.
* [tomislav] I agree with Simeon that his functionality would be in scope, and leaving the packaging details open. I do view this as a developer feature, not for users.
* [simeon] follow-up:safari so that Timothy can add details about testing in Safari.

[Issue 362](https://github.com/w3c/webextensions/issues/362): Proposal: Declarative Cosmetic Rules

* [andrey] See my recent comment. In a previous meeting about this topic, some concerns were expressed. E.g. scriptlets. We don't propose to allow arbitrary JS, but a shim to replace a requested script on the web with a fixed script from extensions. Browser extension devs wouldn't provide the scriptlets.
* [andrey] Secondly, about arbitrary CSS. I agree that arbitrary CSS is dangerous. The content blocker use case only needs a very limited subset of properties.
* [rob] Would the scriptlets be provided by the browser or the browser extension?
* [dmitriy] The browser I think.
* [andrey] The browser.
* [rob] How would the browser know what scripts to bundle? I'd imagine these to be quite website-specific.
* [andrey] The scripts are quite generic. (examples)
* [tomislav] Can these be parametrized?
* [andrey] Yes.
* [tomislav] What would be the amount of scripts?
* [andrey] Tens at most. Initial impressions?
* https://bugs.webkit.org/show_bug.cgi?id=225861
* [tomislav] Rob is more authoritative, but this feels promising
* [rob] Need to take a closer look. This only covers the injection part, glosses over the condition/mechanism that decides whether scripts need to be injected at all. Seems like it might be tied to network requests. So that part could be tied to declarativeNetRequests?
* [andrey] Could be tied to network requests, but we were thinking this would apply to documents only. There's an old API in Chrome called DeclarativeContent. Thought it might be able to be used for this, but seems like it was intended for something else.
* [rob] I'm aware of that API. It also has a request content script feature. How often would a script need to be injected? If it's not tied to network requests, then it sounds similar to content scripts.
* [andrey] This is a specific script that needs to run at document-start. The sooner the better. These scriptlets are designed to run before anything else.
* [tomislav] Are these dependent on CSS rules?
* [andrey] Usually specified on which document it should launch.
* [rob] Sounds like this is an existing content script mechanism that injects into the main world at document_start.
* [andrey] difference is content scripts are hard-coded into the extension. We need some level of control over it. Lots of different rules determining how/when a cosmetic rule is applied. Today that behavior is hard coded in the content script.
* [rob] I think this discussion needs more time than we have remaining.
* [oliver] Sounds like there may be some potential for abuse.
* [andrey] All APIs can be abused to some extent. Even DNR. Real life example: there was a Finnish adblocker that silenced political speech from an opposing party, by hiding its content.
* [rob] Is the goal here functionality with maximal or minimal permissions?
* [andrey] Exposing the functionality in a way that can be easily reviewed and verified safe. Preferably with no additional permissions.
* [timothy] We would want something that does not require host permissions.
* [andrey] Browser extensions have a way to redirect with permissions. The requested functionality is already available in content scripts with permissions.
* [timothy] I think that we are agreeing with each other here.

The next meeting will be on [Thursday, May 11th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=645c3000,384).
5 changes: 3 additions & 2 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,22 +10,23 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2023-04-27 at 8 AM PDT = https://everytimezone.com/?t=6449bb00,384
- 2023-05-11 at 8 AM PDT = https://everytimezone.com/?t=645c3000,384
- 2023-05-25 at 8 AM PDT = https://everytimezone.com/?t=646ea500,384

## Past meetings

* 2023-04-27 ([minutes](2023-04-27-wecg.md))
* 2023-04-13 ([minutes](2023-04-13-wecg.md))
* 2023-03-30 ([minutes](2023-03-30-wecg.md))
* 2023-03-16 ([minutes](2023-03-16-wecg.md))
* 2023-03-02 ([minutes](2023-03-02-wecg.md))
* 2023-02-16 ([minutes](2023-02-16-wecg.md))

<details>
<summary><strong>All past meeting notes</strong></summary>

**2023**

* 2023-04-27 ([minutes](2023-04-27-wecg.md))
* 2023-04-13 ([minutes](2023-04-13-wecg.md))
* 2023-03-30 ([minutes](2023-03-30-wecg.md))
* 2023-03-16 ([minutes](2023-03-16-wecg.md))
Expand Down