Skip to content

Latest commit

 

History

History
145 lines (121 loc) · 11.5 KB

2023-06-08-wecg.md

File metadata and controls

145 lines (121 loc) · 11.5 KB
Raw

WECG Meetings 2023, Public Notes, Jun 8

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=64811a00,384 Call-in details: WebExtensions CG, 8th June 2023 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: github issues

The meeting will start at 3 minutes after the hour.

  • Carry-over from previous meetings
    • None
  • Other new issues
    • Issue 398: Support appending to User-Agent header in declarativeNetRequest
    • Issue 406: Persistence of alarms in browser.alarms API
    • Issue 402: [DNR/webRequest] Discriminating initiators and destinations belonging to a local (private) network (Maone)
    • Issue 403: Proposal: Ability to insert CSS from content script context
    • Issue 404: Proposal: Allow notifications API in content scripts
    • Issue 407: Inconsistency: returned value for windows.create({incognito: true})
  • Open discussion queue (add yourself at the bottom)
    • (ran out of time, remaining topics moved to next meeting)
  • Check-in on ongoing issues
    • None

Attendees (sign yourself in)

  1. Rob Wu (Mozilla)
  2. Patrick Kettner (Google)
  3. Benjamin Bruneau (1Password)
  4. Giorgio Maone (NoScript, Tor)
  5. Carlos Jeurissen (Jeurissen Apps)
  6. Oliver Dunk (Google)
  7. Richard Worth (Capital One)
  8. Steven McLintock (1Password)
  9. Dmitriy Seregin (AdGuard)
  10. Kiara Rose (Apple)
  11. David Johnson (Apple)
  12. Timothy Hatcher (Apple)
  13. Mukul Purohit (Microsoft)
  14. Maxim Topciu (AdGuard)
  15. Tomislav Jovanovic (Mozilla)
  16. Simeon Vincent (Incremental Software)
  17. Tim Heflin (Keeper)

Meeting notes

Issue 398: Support appending to User-Agent header in declarativeNetRequest

  • [oliver] Discussion in issue; joining appended values with space. Firefox is already supportive.
  • [timothy] Would also be supportive.

Issue 406: Persistence of alarms in browser.alarms API

  • [oliver] Safari and Firefox currently don't persist across sessions, but Chrome usually does. There is a bug in Chrome that sometimes clears the alarm.
  • [tomislav] Is this part of the API design or a recent change?
  • [oliver] Don't know the full history here. There is explicit logic added intentionally for persistence.
  • [giorgio] Recently developed an extension where they were quite happy to find that alarms were not persistent, because the alarms were associated with a private window. Persistency should ideally be configurable.
  • [simeon] I can see the utility for opting in to persistence.
  • [oliver] Given that we don't have onEnabled now, it's impossible to guarantee the existence of an alarm.
  • [rob] Do we have a list of use cases that we should support? Some cases need persistence (e.g. periodic update checks), others don't (e.g. Giorgio's use case). And what should happen when the device suspends and resumes.
  • [tomislav] I believe that non-persistency with opt-in to persistent makes most sense.
  • [timothy] I have a similar expectation - drop timers when the browser closes.
  • [giorgio] I'm supportive of the option.
  • [simeon] Seems like there is consensus on not persistent by default, with opt in.
  • [oliver] Would like more discussion. This would be a bigger breaking change in Chrome.
  • [tomislav] And similarly persisting would be a breaking change in Firefox/Safari.
  • [giorgio] Is Chrome able to survey the usage to determine the impact of such a change?
  • [olivery] Not sure we have a good metric for this. Can see alarms carrying over across sessions but can't necessarily infer developer intent.
  • [timothy] “alarms” API usage in Safari is uncommon right now.
  • [rob] “alarms” permission is common in Firefox.
  • [ben] Speaking for 1Password, alarms are quite important for our needs. Adopted alarms when migrating to MV3.
  • [rob] Changing the default may be risky; an option to move forward here is to add explicit flags so that extension author can signal intent that works across all browsers.
  • [simeon] When left unspecified the behavior would be inconsistent, but when the option is set the behavior is consistent.
  • [timothy] I agree with this approach.
  • [oliver] I have to check with Chrome, but this sounds like a good idea.

Issue 402: [DNR/webRequest] Discriminating initiators and destinations belonging to a local (private) network (Maone)

  • [giorgio] We (NoScript and others) were previously not worried about the absence of this capability, because there was a web platform feature proposal. But the feature has been suspended and is not going anywhere. Would be nice to have a condition in DNR and/or information in webRequest to expose whether a request belongs to a local (private) network.
  • [oliver] You mentioned that this work was on the web platform. Any details?
  • [giorgio] Chrome experimented, required CORS to access local resources, but the experiment concluded with no follow-up.
  • [simeon] How are you imagining this would be supported by browsers?
  • [giorgio] a keyword e.g. “wan” in the ruleset that resolves, wherever a domain is accepted.
  • [rob] Current domain properties allow matching subdomains. DNS can make any domain point to another IP address.
  • [giorgio] Don't care about the exact domain, just whether the request belongs to a local network or not.
  • [rob] Sounds like this isn't necessarily part of the domain, it's matching the initiator.
  • [giorgio] Must happen after DNS resolution.
  • [rob] That's a problem for DNR as rule processing takes place before it hits the network. All conditions are evaluated upfront, and there are actions that may take place at later stages (e.g. modifyHeaders).
  • [giorgio] It's freaky because we want to block the request before it hits the destination. CSRF mitigations require this.
  • [rob] The requested feature does not fit in the design of DNR. If you would like this capability, you would have to come up with a declarative way for this feature that fits in DNR.

Issue 403: Proposal: Ability to insert CSS from content script context

  • [simeon] Is gorhill here? Seems not. Does anyone have any context?
  • [rob] In principal I don't have any hesitation. Not sure why this would need to be done in the content script context.
  • [simeon] Initial thought is that they may want to perform this synchronously.
  • [oliver] They don't want to message the background on every navigation.
  • [rob] Constructable Stylesheets are an option, but that is visible to web pages.
  • [carlos] Could inject CSS using standard DOM methods, but that may conflict with CSP.
  • [rob] Constructable Stylesheets allow you to modify styles without DOM modification.
  • [rob] And if there is a concern with the web page trying to remove the stylesheet, then they can add an inline style with !important.
  • [oliver] You insert with a higher precedent level, for example as a user stylesheet.
  • [simeon] I believe that this is an adversarial environment where content blockers want to minimize the impact they have on web pages – DOM
  • [rob] Do we need more information before deciding on this proposal?
  • [simeon] Modifying stylesheets doesn't sound like a security concern. The web page itself already has the capability to apply stylesheets.
  • [rob] With this same reasoning, it would also make sense to run a script in the main world (func+args), because this is exactly the same capability that the scripting.executeScript API already offers. And a web page would already have the ability to run a script on its own page.
  • [oliver] Would this limit adding additional capabilities to insertCSS in the future? Potentially have to support two different implementations of that method, one for content scripts and one for extension contexts?
  • [timothy] Not an implementation concern from the Safari point of view, but that may make working with this API more awkward.
  • [timothy] And if we say that “insertCSS” is fine, then “executeScript” should too.
  • [rob] The advantage of a dedicated API is that we can be very intentional about what security restrictions should be bypassed (ideally: none). Opposed to the current behavior, where injection of DOM elements is governed by the CSP of the content script (in Chrome). Having the ability to inject styles into the page as if it were the page itself may be useful.

Issue 404: Proposal: Allow notifications API in content scripts

  • [tomislav] Didn't see any use case that helps with this beyond not waking up the service worker. The API itself is already async, so the delay.
  • [rob] And also, the web already has a Notification API.
  • [oliver] Agreed.
  • [timothy] Agreed.
  • Consensus: Close request.

Issue 407: Inconsistency: returned value for windows.create({incognito: true})

  • [simeon] Opening an incognito window in Chrome returns a null value, in Firefox it returns window data.
  • [rob] If an extension has access to incognito, opening a window should return the details of the window. If the extension does not have access to incognito, the method should reject the call and the caller should not see the window.
  • [david] In Safari 17 we updated the implementation, we offer the ability to restrict extensions in private browsing.
  • [timothy] Currently we don't even let you open a window if you're in private mode. We return null and don't open a window.
  • [oliver] Chrome returns null and does open the window.
  • [rob] Des Safari return null or error? Seems wrong to return null when you don't perform the requested action. From an API design perspective, I think that a rejection with an error would be appropriate here.
  • [oliver] What's your thinking for returning information about the window if you can't interact with it?
  • [rob] Shouldn't provide information about the window if you can't interact with it.
  • [maxim] Note that this is specific to incognito:split in Chrome.
  • [simeon] Unclear what the behavior in split is but this conversation is specifically around the behavior in spanning when incognito access has not been granted.
  • [timothy] Safari only supports incognito:spanning, not split.
  • [rob] Firefox also only supports incognito:spanning, not split.
  • [rob] If there is a desire to hide incognito windows in split, the API should not allow extensions to create a private window from a non-private extension context. An extension should then communicate with the other part of its extension to intentionally interact with incognito contexts.
  • [oliver] Aren't there cases on the web where you can open a window but not interact with it?
  • [tomislav] An example would be target="_blank".
  • [mukul] There may be use cases where an extension wants to open, say, a banking site in private mode, but otherwise doesn't want to interact.

The next meeting will be on Thursday, June 22nd, 8 AM PDT (3 PM UTC).