2024-09-26-wecg-tpac.md

WECG TPAC Sep 26, 2024

Agenda

Thursday: https://github.com/w3c/webextensions/wiki/TPAC-2024-Coordination#thursday

• 08:00 - 09:00
  • [60 min] Regular WECG meeting (minutes: 2024-09-26-wecg.md).
• 11:00 - 12:30
  • [60 min] MessageFormat 2 - presentation & discussion
  • [30 min] Declarative cosmetic rules (#362)
• 15:00 - 16:00 (non-WECG meeting)
  • [60 min] Browser Testing and Tools Sync
• 16:30 - 18:00
  • [50 min] Event management in non-persistent contexts (Devlin)
  • [40 min] WebExtensions permission model

Attendees

• Rob Wu (Mozilla)
• Christos Bacharakis (Eyeo)
• Timothy Hatcher (Apple)
• Kiara Rose (Apple)
• David Johnson (Apple)
• Elijah Sawyers (Apple)
• Brian Weinstein (Apple)
• Simeon Vincent (Mozilla)
• Mukul Purohit (Microsoft)
• Devlin Cronin (Google)
• Carlos Jeurissen (Jeurissen Apps)
• Oliver Dunk (Google)
• Jordan Spivack (Capital One)
• Casey Garland (Capital One)
• George Henderson (Capital One)
• Tomislav Jovanovic (Mozilla)
• Ioana Chiorean (Interledger Foundation)
• Eemeli Aro (Mozilla)
• Ali Spivak (Google)
• Brian Shultz (Tango)
• Mohamed Elgendi (Malwarebytes)

Notes

[60 min] MessageFormat 2 - presentation & discussion

• [eemeli] Have been working under the Unicode consortium to define a new message formatting language - called MessageFormat2. Successor to ICU MessageFormat, which was not specified as standard. This work started under the i18n group under TC39. Spun off in 2019 to be under Unicode since needs are not JavaScript specific. Work is reaching a point where 2.0 release may be concluded this year, or next Spring. Lots of parties waiting on this. Have done some work over the last two days building this demo. Expect we can do this without backwards compatibility issues.
• [eemeli] <Demo>
  • Current messages.json vs example of MF2: https://github.com/eemeli/myqonly/commit/d286337fdf4e2b16e394decceb0fc470583294b2
  • Showing messages.json file where “message” contains the translation in MF2 format, with 18n.getMessage calls accepting an object with properties.
  • Showing new features such as first-class pluralization support.
  • E.g. .input {$num :number} .match $num one {{1 review on Github}} * {{{$num} reviews on Github}}
  • Non-parametric messages looking identical to the existing messages.json format.
  • To distinguish between regular messages.json and MF2 messages.json file, the top-level object has a ”@@format”: “mf2” property.
• [eemeli] Main question - what are the possible blockers to adopting this: 1) supporting multiple formats, and 2) specifically MessageFormat 2? MF2 is a new spec, so there are not currently a large number of users. Before introducing Intl.MessageFormat in JS, TC39 wants to see more adoption in the wild. Use case for web extensions is similar. Could this be adopted? If not, what are the blockers?
• [devlin] Can you give a brief overview of the capabilities that MF2 provides? I see pluralization in this demo. What else?
• [eemeli] Yes, there are other benefits. :number annotations allow you to pass options similar to Intl.NumberFormat. Matching is not limited to numbers but can be related to grammatical gender, verb tense and many other ways messages can vary. Format suitable for both developers and translators.
• [devlin] You also mentioned that Mozilla is adopting this and have benefits to the ecosystem at large. Are there other adopters of note?
• [eemeli] Because this work is being done at Unicode, it will be made available as part of ICU4C and ICU4J. ICU4X implementation will follow.
• [devlin] You mentioned you're planning to launch version 2.0. What does this mean?
• [eemeli] Stability policy guarantees start applying, and it's a marker that we've internal consensus in the WG that this is good for the long term (no more tweaks).
• [devlin] The demo format looks heavily designed to be compatible with existing messages.json format. Is this same structure the one you would choose if you didn't have to do this? message.json isn't the only place we could do this – could signal in the manifest.
• [eemeli] A lot of focus has been on MessageFormat (i.e, a single message). We are also working on message resource syntax, but this is not developed as far. Working to find where its spec will live. Heavily based on TOML, takes into account specific requirements we've identified as beneficial for message authors and translators. This format allows attaching messages and comments. This helps provide additional context to translators to translate a given string. Based on our experience at Mozilla, we should be able to build a parser with performance on part with JSON parsing.
• [devlin] Do you have an example of a message with placeholders and descriptions? Or pluralisation or matching?
• [eemeli] Not to hand.
• [timothy] Would almost like to see inputs in a distinct section if we stuck with JSON format.
• [eemeli] This is assuming translators will end up looking at raw format. This will happen in many cases but a lot of translation work these days is mediated through tooling. A big focus has been making things easier for tooling, syntax highlighting, assistive technologies.
• [devlin] (To carlos) Do you use automated translations?
• [carlos] Around 5000 users have signed up to translate. Current translation support doesn't include things like gender. Looking forward to adopting something like this.
• [devlin] Was mostly wondering what tooling would need to be in place. Carlos, would this work for you if there was tooling?
• [carlos] Yes.
• [timothy] If there is another better file format, we could also adopt that instead.
• [eemeli] Yes, but there is a danger that this work is slow. MessageFormat started midway through 2019 and is only reaching this stage now. It could be another 2, 3 or 4 years before MessageResource is standardized.
• [devlin] If the message format is not in the spec, what components are included in the stable spec?
• [eemeli] Everything that is in MessageFormat 2 spec (including standard functions) could be used. There is also support for custom functions but this should likely be left out of messages.json until this is figured out in TC39. It would make sense to align.
• [devlin] In WebExtensions, we try to have the contents of the package be reviewable for privacy/security reasons. If the format is too flexible, one might worry about how it could be abused.
• [timothy] Demo JSON format can be hard to parse.
• [devlin] less worried about that then how it could be abused (for example, arbitrary code execution).
• [eemeli] Without custom functions arbitrary code execution should absolutely not be possible. We've also limited what custom functions can do. Spec promises not to present a case where a standard function is not implementable as a black box that does not use external inputs.
• [eemeli] MessageFormat 2 does not need to be output to a string. You can format to parts. There will be further work to ensure security of this.
• [carlos] For clarity on previous comments, I'm not waiting on tools for gender to be integrated. That's not a blocker for me.
• [timothy] Plain text without substitutions doesn't need curly braces?
• [eemeli] Nope.
• [timothy] Demo isn't using a modified format?
• [eemeli] Demo is using a MessageFormat 2 library with no modifications.
• [simeon] Did you strip newlines in the demo?
• [eemeli] Yes, since this is easiest in JSON.
• [timothy] The other format had lots of @ symbols, what were these for?
• [eemeli] <Demo of format with more formatting>
  • .input {$total :number} .match $total 0 {{Nothing to do! \\\\o/}} one {{Found 1 thing to do}} * {{Found {$total} things to do}}
  • Above is one line because JSON does not support line breaks, more natural MF2 formatting would include line breaks such as:

.input {$total :number}
.match $total
0   {{Nothing to do! \\\\o/}}
one {{Found 1 thing to do}}
*   {{Found {$total} things to do}}

• [oliver] As someone not familiar with MF2, the JSON format looks more readable than the TOML format.
• [timothy] I also see potential for separating the message in an object with properties for “0”, “one”, “*” instead of embedding another microformat in the JSON.
• [george] Have you looked at i18next for inspiration on format?
• [eemeli] Yes, there is a prototype of using i18next for MessageFormat. We are trying to take learnings from other projects and start from the ground up so we don't accumulate tech debt.
• [devlin] Is there validation of inputs? e.g numbers Is there overlap with JSON schema?
• [eemeli] There's validation. If input is not a number, BigInt, a string with a JSON representation of a number, an object with a valueOf() method that returns an object with a number or a string.
• [timothy] You don't think we should go the route of using JSON, and should instead use string microformat?
• [eemeli] Correct.
• [simeon] When we were talking about this previously, we were discussing messages file, manifest as possible locations for this. We were also considering being able to migrate specific files or messages so it can be done more gradually.
• [timothy] This sounds aspirational but there are already syntax changes to how you pass in substitutions.
• [devlin] Independently, this is a strict superset. We might be able to write a tool that does a translation between formats.
• [eemeli] Separately from introducing MessageFormat 2, passing an object with keys to getMessage() should work. Current syntax has examples for variables included, you can do that in MessageFormat 2 but slightly differently.
• [oliver] Is @example a reserved space or just a name that is irrelevant?
• [eemeli] The @ marks it as an attribute with no runtime impact, but “example” is made up, but agreed we might want to agree on some common terms.
• [timothy] Back to gradual rollout, I still think this will be difficult if you start adopting plurals, currency input and only have the message in the new format in certain translations. So not sure if this should be a goal.
• [simeon] Yeah, to Devlin's point it should be possible to convert.
• [timothy] I would opt for a key in the manifest to opt in to the MF2.
• [oliver] From a practicality point of view, you mentioned in a previous session that there are reference implementations and browsers will need to ship an implementation once this is supported by TC39?
• [eemeli] Yes. Functions provided won't necessarily be the ICU ones, but they can be.
• [rob] Timothy mentioned declaring format in the manifest. Would that be JSON or MF2?
• [timothy] As JSON or whatever format, as opposed to putting ”@@format”: “mf2” in the JSON.
• [eemeli] Whatever format, allow for future changes by using a string/enum value rather than a boolean.
• [rob] What are next steps?
• [eemeli] Haven't heard blockers or concerns related to waiting for wider industry adoption before considering adoption in WebExtensions.
• [devlin] I do have some concerns. As Timothy alluded to, we want to use something because we don't want to roll our own. So want something somewhat standardized, it sounds like you are on a good track. There is no particular milestone we need to wait for.
• [eemeli] Once this reaches 2.0, accepted into CLDR and ICU, this will be the only standardized message formatting syntax.
• [timothy] Once this is in ICU, I see no issues for us adopting this.
• [eemeli] Hopefully coming in a matter of months. In this demo I've made a point of avoiding parts of MF2 outside of getMessage. Want to avoid the possibility of conflicting with future TC39 specs.
• [tomislav] So what shouldn't we be doing?
• [eemeli] Formatted parts. We should only return strings. Formatted parts could take e.g. a DOM element as input, and the result could include that element, or other non-string values.
• [devlin] Concrete next steps: we're likely waiting on MF2 finishing. After that, we can take up adoption discussions.
• [timothy] One thing I notice is that we only have a message key in the messages.json.
• [devlin] The messages.json format also accepts a “description” field next to the “message” field. This would still be applicable.
• [devlin] You mentioned Firefox are planning on adopting this, have you spoken to Chrome engineers localizing the browser?
• [eemeli] To some extent yes. A number of Google engineers are contributing to MessageFormat 2 spec; not sure if they are working on Chrome.
• [timothy] And Apple folks?
• [eemeli] Yes, George Rhoten, although they have not been active for a little while.
• [rob] We should file an issue to track this, previous and future discussions.
• Resolution: Wait for MF2 finalization and pick it up from there, create a tracking issue.
  • [eemeli] Created: Issue 698: MessageFormat 2 support

[60 min] Browser Testing and Tools Sync

• The WECG met with the Browser Testing and Tools group to discuss extension installation through WebDriver BiDi (including a related PR at w3c/webdriver-bidi#778). We anticipate needing this functionality to integrate WebExtensions testing in wpt (#19).
• Minutes: https://www.w3.org/2024/09/26-webdriver-minutes.html#t14

[30 min] Declarative cosmetic rules (#362)

• Issue 362: Proposal: Declarative Cosmetic Rules
• [david] We've been thinking about this at Apple. Looking at rule formats we have for content blockers today. Would like to apply Declarative Net Request API to content on the page as well. Do we want to limit the scope to blocking/hiding content or also adding content/badging?
• [timothy] Devlin mentioned badging earlier this week.
• [devlin] I'd like to limit to blocking for now. I'm supportive of expanding in the future. Expect that other capabilities would significantly slow down work.
• [timothy] Was initially hesitant to use a new namespace, but if this morphs into adding content as well that may make more sense.
• [george] Can you clarify “blocking?
• [timothy] Hiding or removing page content. There is an option for display: none; and an option for visibility: hidden.
• [david] Thoughts about other approaches?
• [devlin] Nothing specific at the moment. For cosmetic rules, would be helpful if we had content blockers here. Do we care about relationships between content like initiator? I assume we care about child frame or main frame. Not sure what else we'd need to carry over.
• [george] in the filter rules I've seen I don't think they take parents into account beyond CSS selectors.
• [devlin] Would be curious how often global selectors are used and why. Seems like it could be performance draining. Would we want limits on CSS selector size/depth? From our experience with declarativeContent, matching many CSS rules is costly. Could we e.g. limit to 5000 global cosmetic rules with limited depth. Curious what we could do that would be guardians that don't hinder blocking.
• [timothy] In practice we haven't seen issues with selector complexity today. We've even opened it up to the :has() selector. We have a CSS JIT which helps with performance for this use case.
• [george] Could you apply rules dynamically after page load?
• [timothy] Right now there's no dynamic way. It's applied at document_start.
• [oliver] Issue on GitHub was opened by AdGuard. They requested domains and excluded domains.
• [devlin] Expect they'll need at least URLs. Google and Google Maps are very different. How have modern web dev practices impacted selectors? For example, ID is no longer reliable.
• [timothy] Seen in React that IDs are dynamic. CSS is flexible with CSS selector syntax.
• [devlin] Ways to work around the ID limitation. Are there enough dynamic flows that those work around no longer apply?
• [mohamed] …
• [devlin] washingtonpost.com may have a different layout, different number of children, etc. on every page load.
• [mohamed] there are some patterns that repeat on spice sites. Might not apply across domains.
• [devlin] Was thinking more broadly about industry trends and what is/isn't reliable.
• [timothy] Notable feature of our implementation.
• [devlin] We're supportive. Know this is a useful case. Blocking content without host permissions is huge.
• [timothy] Also opens the door for adding content.
• [george] Do you allow for blocking inside shadow dom?
• [timothy] Don't think so. CSS doesn't allow you to select inside.
• [rob] I think that it should be supported.
• [simeon] Have been selectors in the past that pierce. We could support it here if CSS writ large does not.
• [rob] CSS folks have been very hesitant about adding selector support for “piercing”. I recently linked some relevant #647 (comment). We should be able to match inside shadow root without selector support.
• [timothy] XPATH in shadow root might be an alternative as well.
• [david] Would love to get feedback on features that should be considered for V1.
• [casey] Would users be able to tap/click to reveal?
• [devlin] Would probably want to support something like that.
• [george] A feature I'd like to see is the ability to dynamically set rules and apply them to the active tab without reload.
• [casey] Have you thought about …
• [timothy] Not requiring host permissions is ideal. Being able to add content to the page and, once the user interacts, getting access to the page to enhance it is ideal.
• [david] Starting point would likely be inject always.
• [timothy] Pinterest tag use case.
• [david] Could imagine abuse scenarios where an extension puts transparent content across 100% of the page to trigger injection.
• [rob] Action items?
• [timothy] Apple to write a proposal. Names? Leaning towards a new namespace. Allows API to
• [oliver] browser.declarativeCosmeticRules
• [devlin] Don't need to include “declarative”
• [oliver] Don't like “cosmetic” as it implies visual-only.
• [devlin] Would like to allude to page appearance.
• [rob] What functionality do you expect to host in this namespace?
• [timothy] cosmetic additions.
• [devlin] Not just cosmetic.
• [simeon] So injecting a UI that can grant activeTab?
• [devlin] Leaving the door open to that option.
• [david] Main use case is hiding content.
• [] Save content modification.

[50 min] Event management in non-persistent contexts (Devlin)

• [devlin] There's a common thread of non-persistent contexts are hard. I've been wondering how we can make this easier. Don't want to move away from non-persistence. I'd be curious for general thoughts on main problems and challenges. The three that come to mind are (1) there is no guarantee your service worker will stay alive while you are handling an event (2) there is no way to asynchronously register a listener and (3) there is not a good way to bootstrap state in the listener.
• [tomislav] Can you elaborate on the last one?
• [devlin] You have to init each time you handle an event in case the event started your non-persistent context. After awaiting something you may no longer have a user gesture.
• [simeon] Loss of user gesture in async handlers on background startup is a problem I wanted to call out.
• [rob] Added several related issues corresponding to the three topics:
  • #416 (waitUntil proposal)
    • (covers “there is no guarantee your service worker will stay alive while you are handling an event”)
  • #501 (toggleable event listener)
    • (covers “there is no way to asynchronously register a listener“)
    • [rob] Idea behind it of being able to register an event listener later was related.
  • #353 (onEnabled proposal)
    • (related to “there is not a good way to bootstrap state in the listener”)
    • [rob] Not exact match, this is about bootstrap at startup, not at event dispatch.
• [devlin] Don't see how 519 is related.
• [rob] Corrected to 501.
• [rob] Related to bootstrapping, 353.
• [oliver] Do we want to talk about more advanced filtering capabilities on event listeners?
• [devlin] Could.
• [oliver] The reason for this is that we've said we don't want to add filters to new events until we've had a general discussion.
• [devlin] Let's punt on that for now.
• [devlin] Other problems? In the past we've discussed freezing instead of stopping the process, almost like pausing a debugger and resuming later. Not sure that's the right solution, but restoring state may be useful.
• [timothy] Isn't that session storage?
• [devlin] Still async.
• [rob] Did you mean retrieving config, etc. for bootstrapping?
• [devlin] Related. Not having to wait on fetching data from storage, for example.
• [rob] We, browser, could delay startup of the context based on initializing session state. I'd be in favor of storing state and restoring it before initialization.
• [timothy] That seems fine.
• [rob] (to devlin) To confirm, would you be ok with that idea?
• [devlin] … trying to figure out what the main problems we're trying to solve are.
• [rob] Would like to support synchronously available state at startup, which also addresses the togglable listener case.
• [devlin] Doesn't address togglable listeners, you don't want to be woken up.
• [rob] Right, they complement each other. There are two aspects: ensuring that an event whose listener is removed does not wake up, but also that a renewed listener registration can detect the event. Synchronously available state at startup enables the extension to register a listener and receive event data. Otherwise events are either dropped, or we would have to remember event details near startup and dispatch later.
• [devlin] Does today.
• [rob] Would have to limit to a bounded time.
• [devlin] Not necessarily. Could introduce a message queue to queue events until listeners are ready.
• [timothy] We queue some messages while waiting for a process to spin up. It's very short.
• [devlin] In effect we all do. But we could also have a queue in the renderer to wait on the initialization before dispatching. This is already implemented by some extensions in userland.
• [rob] I think these 3 areas you outlined are a good start.
• [carlos] ATM every listener needs to be top level. That means SW gets started at times when it doesn't need to be.
• [devlin] Ties into the question of whether you need to register synchronously, togglable events.
• [timothy] Or filters.
• [simeon] Is the idea of updating a filter for a registered listener part of any of these?
• [devlin] If nothing else you can unregister and register again with a different filter.
• [devlin] Do we agree that these three issues mentioned at the start are the three issues to focus on?
• [rob] Yes.
• [timothy] Yes.

Topic: “there is not a good way to bootstrap state in the listener”

• [devlin] One ​​of the most impactful ones is having state synchronously available at startup. Building block for extensions and for addressing other issues. Are we all on board with addressing this?
• [timothy] Yes.
• [tomislav] yes.
• [devlin] Are we comfortable saying the SW will start slower?
• [timothy] Depends on how much storage, etc. we set aside.
• [tomislav] Keep the developer in control. If they don't use it, there's minimal impact.
• [oliver] Would want to avoid introducing another storage area.
• [devlin] Torn on that. Session storage is more or less JSON.
• [oliver] We should fix that.
• [timothy] Doesn't match our behavior.
• [rob] Firefox already supports structured cloning in the storage.session API.
• [devlin] Structured cloning is great, tabling that. We could do structured cloning, but we should aim for more flexibility. For example, that doesn't cover an initialized WASM module. We said these values would be available when the bg context starts. Does that include browser start?
• [timothy] I'm inclined to tie it to the browser session.
• [rob] Could support two, one small that persists, and more storage for resumed workers/event pages.
• [rob] Another argument against combining in storage.session is that is has the setAccessLevel method that can cause storage.session to be exposed to content scripts, readable & writable.
• [devlin] Are we okay with the assumption that extensions will initialize this data on browser start?
• [oliver] Session storage was motivated in large part by password managers. I imagine they'd also want this.
• [devlin] If were providing a solution that allows behavioral configuration, we'd want that to persist across browser sessions. But if we do that, we'd have less flexibility in what we expose.
• [tomislav] Wouldn't that just bring us back to where we are now where they must initialize at startup?
• [devlin] Not necessarily, you could limit your conditional handling by listening to browser startup. assuming browser start is the first event, every subsequent event would have that state initialized.
• [carlos] Having data persists has privacy implications, no? Persisting data means it's serialized.
• [devlin] We can provide guidance on how to use this safely, properly. I don't think we can say “because of password managers we can't do this at all.”
• [devlin] We've gone back and forth on persisting across browser starts.
• [timothy] I could go either way. Agree that it limits us.
• [devlin] I assume persisting across browser starts is generally desirable for developers. Curious for extension devs opinions?
• [casey] Yeah, we already do that. We might rework it if we had the option of deferring to the browser.
• [carlos] same
• [rob] Should we add a method to flush the storage?
• [devlin] it's a storage API, so we'd have all the same CRUD APIs.
• [rob] Would it be sync?
• [devlin] From the extension's point of view, but that doesn't mean it would be under the hood.
• [rob] use case might be to flush and store data to persist as fast as possible
• [devlin] Can provide extensions a mechanism to notify when write completes.
• [rob] More important part is for extension to be able to signal that writes are not critical.
• [devlin] We are past the 30 min mark. Next steps: browser vendor to draft a proposal.
• Action Item: Devlin to draft proposal for synchronous storage mechanism
  • [rob] Created Issue 703: State in background scripts, synchronously available across restarts

Topic: “there is no guarantee your service worker will stay alive while you are handling an event”

• [rob] There is a proposal here, but pending “chrome: follow-up”.
  • Issue 416: Introduce runtime.waitUntil API to keep background service worker / event page active during a specific task
• [devlin] waitUntil makes sense. What I'm torn on is I don't know how we would do it. IDK what that would look like in an extension. The web has an event. In extensions there's no such thing, just bags of data. There's nothing to hang the method on. The open question is how do we do something like that without fully adopting the Event interface. Could see this being something like chrome.runtime.waitUntil().
• [rob] I wouldn't require it to be tied to Event; there is also utility in having a runtime.waitUntil method that can be called without extension API.
• [devlin] Would prefer to have a waitUnit in response to events.
• [rob] Could be implemented by only allowing waitUntil when an event has been called recently. We can discuss mitigations more later.
• [devlin] Could theoretically have a manifest key to opt into a given style of lifetime management. That could enable us to dispatch events with the current data bags on an event object.
• [tomislav] You're proposing a manifest key causing all events to dispatch an event?
• [devlin] They would receive a thing, an Event, an Object interface, etc. But largely yes.
• [devlin] To be clear, not attached to any particular solution. This is for discussion and ideation.
• [rob] Could introduce an extentableEvent manifest key that lists the specific events that should receive event objects.
• [devlin] On the web you call waitUntil on the event. If we could match that, that brings us more in line with the web platform, avoids introducing a pattern that doesn't have a clear association between the event and the wait mechanism.
• [devlin] We can't do that today, but right now the listener has data passed in. You could imagine that we wrap that in an object that also has a waitUntil method.
• [tomislav] I think we should discuss making our events more web like. This doesn't seem like a sufficient motivator for a partial step in that direction.
• [timothy] Agreed.
• [devlin] I don't think it would be that complex to pass in an object with a method.
• [timothy] It's not our complexity.
• [tomislav] It's the ecosystem.
• [devlin] I'm not attached to this. That said, I don't think waitUntil is a small issue. Would wonder if there are other things this would pave the way for. I don't want to completely replace our event system at this moment, but do want to lay the groundwork for addressing these problems.
• [rob] Are you suggesting that addListener should take an object, e.g. as suggested in ​​issue 519?
• [devlin] No, have the thing passed to the listener be the event.
• [oliver] Feels like we're making this complicated. What's necessary to address the pain point can be addressed with smaller mitigations.
• [tomislav] If you're in an event, you're allowed to call this method with a promise.
• [timothy] We definitely know when we're handling an event.
• [rob] runtime.waitUntil also allows for integration with web APIs.
• [devlin] Main action item is to write a proposal for a synchronous storage mechanism. Maybe another if we want a proposal for waitUntil.
• [tomislav] Do you not think we should move towards the web model for events?
• [devlin] I'm open to it. What we were discussing was a step towards that.
• [tomislav] Worried about documentation challenges with that.
• Resolution: Consensus on capability of extending lifetime, with mitigations.
• Action item: Rob to draft concrete proposal.

[40 min] WebExtensions permission model

• [simeon] Multiple recent issues, even just 7 in the 6xx range.
• [devlin] A lot of these issues seem like good candidates for issue triage (some were already triaged), tomorrow. Potential discussion around scoping permissions to origins.

Issue 687: Proposal: Targeted Permissions

• [rob] General issue is that some capabilities are not dangerous, but are in a namespace that's restricted by a permission.
• [devlin] History API referenced here seems like a good example.
• [rob] I see 3 levels in the history API example: privacy-impacting (querying history), destructive (deletion), already-possible-in-other-ways (add history item). Would you require permission warnings for them all, even the last one?
• [devlin] Yes. Not sure about the last one.
• [devlin] In general we strive to have APIs bucketed in a way that you generally want that functionality and there aren't dramatic differences in what the APIs can do/capabilities they expose. Already have some examples where scaling of permissions doesn't match namespaces. For example, downloads.download vs. downloads.open. Don't know that we'd want to go towards a new permission for every method – would be challenging to explain to the user, hard for developers to rationalize.
• [timothy] I know other browsers struggle with extensions adding new permissions and getting disabled.
• [devlin] Brian mentioned that Tango wants new permissions but avoids requesting because they will be disabled.
• [brian] Definitely.
• [brian] We have 3 main buckets: browsing history, ability to track across web pages, webpage content.
• [devlin] Generally in favor of more granular then we have now, but not as granular as per-method.
• [timothy] Liked where you were going with the history example.
• [devlin] Essentially read and write.
• [random talk about incognito – can't open a tab in a specific window unless you have incognito access]
• [rob] Another aspect is that there are some APIs that are useful but don't pose a risk. Would we be comfortable with making them available without a permission warning?
• [devlin] Without a permission or warning?
• [rob] Warning. For an extension that only wants to save something, it's a bit much to warn about downloads.download, since the same functionality is already freely available in web content APIs (<a download>).
• [devlin] Given a permission, we would determine an appropriate warning for that permission which may be no warning. If we think there's an API with meaningful buckets, it makes sense to segment those buckets and warn as appropriate.
• [rob] Safari doesn't have warnings so this isn't relevant, right?
• [timothy] Depends on the buckets. May still be relevant.
• [david] For example, DNR. Basic capabilities are fine and don't show a warning, but you want to redirect and then we need to tell the user.
• [devlin] Seems like we're largely in agreement.
• [devlin] If we had history.read and history.write, would we deprecate history?
• [timothy] Next manifest version.
• [rob] What if we define new features outside the bounds of those permissions? E.g. history.delete. Unless we are confident that we can define all permission scopes upfront, we should not deprecate the broader history.
• [oliver] Next step might be a call to action for anyone in the community that wants to break down permissions.
• [devlin] Would prefer not to do all of them. Maybe just 3 to start, maybe find a pattern.
• [tomislav] Get a sense of how well its working and determine next steps.
• [devlin] Anything else on finer grained permission warnings?
• Resolution: Tentatively in favor of finer grained permissions. Proposals welcome.

Per-origin permissions

• [devlin] The last piece was further breaking down permissions by host permissions. Opposed to that approach. The reason we have host permissions is that they generally give you the ability to perform arbitrary, dangerous actions on a given origin. There's not a meaningful distinction between being able to access, say, cookies via a content script and being able to access them via the Cookies API.
• [devlin] Maybe httpOnly could be behind a finer grained permission, since content scripts cannot read them.
• [rob] webRequest can see httpOnly cookies.
• [tomislav] Using webrequest is how I found out just how far you can go with host permissions.
• [timothy] We have the concept of associated app domains. In that case we should just grant access to those origins.
• [rob] We don't have that.
• [devlin] It is not something we would do.
• [timothy] Could hypothetically do a DNS verification step, but that's asking to set up a whole set of infrastructure.
• [tomislav] Google and Apple already have that, Mozilla does not.
• [timothy] I know it's a lot, but giving you instant access to your own cookies seems like a win.
• [devlin] We know developers want it, but store concepts are out of scope.
• [devlin] Circling back, since limiting which APIs you can use by host doesn't impose a meaningful constraint. Are we all on board with passing on this?
• [tomislav] Yes.
• [timothy] Yes.
• [carlos] There are likely other ways you could constrain permissions, like only allowing an extension to access host permissions when showing extension UI.
• [casey] We use hosts to determine when we should expose UI, though.
• [carlos] As a popup you might not need access to a site, opting out could improve the security of the extension.
• [timothy] We see URL access as the ability to track. Page access is a whole other level of data access.
• [devlin] I'm very supportive of providing users with more tools to scope the duration of grants. There's not too much we can do here, though, as it's a browser UI consideration.
• [simeon] Suggest we wrap up there.
• [tomislav] one quick topic…

Optional-only permissions

• [tomislav] Have run into two situations where we have wanted to support optional permissions. E.g. experimental APIs and userScripts API. In the userScripts API example, the “userScripts” permission can be in the manifest be ignored.
• [tomislav] Suggestion: optional only permissions (name not final). Permissions that you can declare in the manifest, but that would never be granted by default.
• [devlin] Sounds interesting, would not be sure if we would use it in Chrome.
• [timothy] Use feature detection for experimental APIs?
• [devlin] In userScripts API case, we would not want extensions to trigger the install prompt.
• [tomislav] Whether you display the permission request is up to the browser. It wouldn't necessarily be triggered by the extension. It would be a capability that's directly mappable to the manifest.
• [timothy] I would expect permissions.contains() to return false if you do not have the permission.
• [devlin] You have the permission, you just can't use it.
• (laughter)
• [timothy] Sounds like it should be equivalent to no permission.
• [devlin] I can see a case for a permission.contains special handling. Don't know if there's anything else we'd use this for other than user scripts.