Meeting minutes
Anssi: welcome to the new participants joining the group:
… Joshua Lochner and Tarek Ziade from Hugging Face
… Yoav Weiss from Shopify
… Rupert Manfredi from Telepath
… Chelsea Kohl from Flying Okole
… Joan Leon and David Mulder as individual contributors
… welcome all to the WebML Community Group!
… as a reminder, we'll use IRC-based queue management in this meeting:
https://
Anssi: to suggest agenda topics, use Agenda+ label
Announcement: Workshop on E-commerce for Humans and AI Agents
Anssi: a new "Workshop on E-commerce for Humans and AI Agent" in preparation, goals:
… "This workshop aims to share experience of creating content with AI Agents in mind."
… "The impetus for the workshop is from ecommerce which will be a particular focus of the event."
… I contributed the WebMCP shopping use case for consideration:
webmachinelearning/
Anssi: for more information, and general questions and comments, see the GH issue:
<gb> Issue 544 Workshop: ECommerce for humans and AI Agentss (joint workshop with GS1) (by dontcallmedom)
Anssi: I will share more information when this workshop is officially announced
Writing Assistance APIs
Repository: webmachinelearning/writing-assistance-apis
New parameter to support model tiering in Summarizer
Anssi: issue #96
<gb> Issue 96 New parameter to support model tiering in Summarizer (by jingyun19) [Agenda+]
Anssi: Jaewon Lee from Google will present the proposal
… he has produced an explainer document that contains the latest proposal:
Jaewon: I work on Web AI team at Google, working with Reilly and Mike
… presenting model tiering proposal that can apply to multiple APIs, initially summarizer
… currently, developers have no way to signal to the browser that they are willing to trade off some output quality
… or ask for specific capabilities for faster execution or broader device compatibility
… proposing a new parameter, preference, to the SummarizerCreateCoreOptions
enum PerformancePreference {
"auto",
"speed",
"capability"
};
Jaewon: "capability" for the most capable model, "speed" for the fastest response, "auto" for the implementation to decide
… three things, this helps with a11y and reach, UX with faster interaction, graceful degradation with availability check
Anssi: thank you Jaewon for the introduction to this proposal
Anssi: is the group supportive of advancing this proposal to the spec PR?
Anssi: how about implementation exprience at this stage?
Jaewon: we are working on a smaller model currently, not yet tested this with a bigger model
Kushal: do developers get feedback on what model will be selected?
Jaewon: we don't currently expose the model
Mark: I wondered if the idea was to set preference to speed to make sure you always get the fastest model?
Jaewon: if you choose speed now, in Chrome you'd have two models to choose from, in the future we might have a larger variety of models
Mark: I'm wondering if in 3 model scenario you'd always have a speed-optimized model option
Jaewon: the logic is currently implemention-defined
<Mark_Foltz> +1
<iris> +1
<lgombos> +1
RESOLUTION: Add a three-tier performance preference feature to the Summarizer API. (issue #96)
Translator and Language Detector APIs
Repository: webmachinelearning/translation-api
Definition of "On-Device Models"
Anssi: Ehsan shared a draft explainer that attempts to define "On-Device Models"
https://
Anssi: problem statement, inference may run locally or on remote servers
… users have varying privacy/security needs wrt this
… Web APIs have no standard way to express or enforce such preferences
… proposed solution: API extension to allow the User Agent to constrain where inference runs based on user preference, two preference knobs proposed:
… 1) execution locations:
… personal-secure = "personal device" + "secure area"
… personal = "personal device"
… remote-secure = "remote device" + "secure area"
… remote-attested = "remote device" + "legal/contractual guarantees"
… remote = "remote device" + "no guarantees"
… 2) direction preference:
… more-privacy-preserving = allow upgrade to more privacy-preserving location
… less-privacy-preserving = allow fallback to less privacy-preserving location
… key design principles:
… - user preferences take precedence over developer preferences
… - UA picks the most privacy-preserving location both parties accept
… - fingerprinting risk mitigated via user activation or rate limiting
Ehsan: Ehsan from Samsung, this is a follow-up to an email I sent to the group earlier, TAG response to Translation API and its network usage
… that led to a discussion what we mean by "on-device models" actually, and explainer drafting followed
… TAG wanted to hear this group's opinion on this direction
… TAG sees a lot of features using on-device models so this would generalize
Anssi: given this is not a testable feature, it cannot be a normative requirement
… I wonder if this mechanism has value if it is informative hints?
Ehsan: my initial response is there's a compliance framework, if compliance for service provider is explained we can infer indirectly about it
Mark: I think potentially as a user I'd like to know if there's a way to expose from a platform I trust what compute unit is actually used
… that might be out of scope of the API spec but worth discussing in the explainer
… some kind of audit log might be a solution
Anssi: this feature is similar to the DNT (Do Not Track) feature that is no longer recommended due to challenges in enforcing websites to comply
Ehsan: DNT came up in TAG discussion and we are trying to learn from those mistakes
… thank you for resurfacing that issue
Ehsan: the issue is open for further feedback, I hear from this group the general sense is we are in the right direction but not quite ready with the exact mechanism or API shape
Anssi: maybe use case focus would help enhance the explainer
WebMCP
Repository: webmachinelearning/webmcp
Allow iframes to declare tools
Anssi: issue #57
<gb> Issue 57 Allow iframes to declare tools (by khushalsagar) [Agenda+]
Anssi: in our last meeting we resolved to explore Document Policy as a bi-directional opt-in mechanism without a wildcard mechanism that addresses the two use cases, figure out a solution for name collisions
https://
Anssi: as a reminder, we target two use cases:
… 1. To allow iframes to declare tools for browser/extension agents to operate
… 2. To allow some form of cross frame calling of tools
… since the resolution was made, new information has been shared:
… Dominic re-raised MarkF's comment for the need to come up with a serialization scheme to disambiguate name collisions across frames
… Alex noted we can use postMessage to relay tools between host and child to address use case 2
Anssi: Victor shared a concrete example for use case 1, embedded Calendry automated scheduling tool that does not work with postMessage only:
… a user adds <iframe src="https://
… this should not require setting up a postMessage bridge, <iframe> embed should be enough
… but would still require Calendry to explicitly opt in to exposing tools
… Johann notes security benefits of embedding iframe vs embedding JS
… Victor asked Ian for insights re Document Policy vs Permission Policy, no response yet
<AlexN> +1
Anssi: does the group agree the Calendry use case (concrete example of use case 1) is important to support?
Victor: Calendry has been the key use case for this feature, a lot of people prefer to embed iframes, copy-paste skippets to websites
… it'll be great if tools like this could expose WebMCP tools, the parent does not care about these tools to be exposed
… one thing what came out, consider a case where the service says "I allow anyone that embeds me to access my tools"
Anssi: do we want to await for further data on Document Policy vs. Permission Policy?
Victor: main concern is that firstly, in general Document Policy is the Right Thing, more ergonomic
… and on the embeddee site also "I allow this site to embed me"
… Document Policy is only implemented in Chromium, the question is should we take a dependency on that
… alternative is to use a mix of Permission Policy and bake into the WebMCP spec "I allow this website to use me" mechanism
Kushal: relaying this from Dominic, one question he had, for Mozilla folks, RFP for Document Policy was neutral, are you interested in this feature?
Benjamin: part of the reason it is neutral is that there wasn't many applications for that feature, WebMCP is now one such application
Benjamin: I will follow up on that Document Policy Mozilla position
Mark: comment on the Calendry use case, makes a lot of sense, I perceive that with Document Policy also emberred needs to opt in, in that case for this new capability it means Calandry would need to update its code
Kushal: question about name collision aspect, what's the issue there?
… we have to deal with docs that have the same name and deal with that as a consuming agent, two docs with the same name, why this needs to be solved on the platform side
<Mark_Foltz> Site agents may see name collisions from embeds
Victor: mostly came from the 2nd use case, website A embeds an iframe and is able to see the tools on another website B
… some sort of origin key needed for interaction between iframe and website in this scenario
Kushal: either origin-based namespacing or document-based namespacing is needed
Victor: I thought iframe gives parent frame access to all tools
Kushal: consumer needs to know the document id and tool name
Kushal: how do we deal with nested iframes?
Johann: Permissions Policy bubbles up, not sure how Document Policy works in that regard
… following up on Mark's comment for widcard
… are we reducing the utility of the API by making it so straight, top-level should not be able to say " I accept tools from any 3rd party"
… on the 3rd party side, I'd be more flexible if we can make it so web developers understanding opting in to share with all is potentially dangerous
… want to avoid the attack case that wildcard allows
… category of attack where you can iframe someone else
Mark: about name collision issue, two aspects, one on the browser agent side, multiple frames and multiple browsing contexts, how to organize tool names in namespacing, origin-keys don't address all edge cases
… for the API space this is about site agents, to enumerate tools across document tree
… how to present the enumeration to site agents to disambiguate tools
… ideally, the frame providing the tools could provide a hint so the model understand from where they came from
Victor: use cases coming up, interested in iframe giving the browser access
<victor> iframe giving the browser access*
Threat modeling
Anssi: issue #154
Anssi: Security Interest Group has produced a guide to help spec authors and implementers document and understand threats facing the web
<gb> Issue 154 Threat modeling (by anssiko) [Agenda+] [security]
https://
Anssi: the guide is WIP thus rough edges expected
… I reviewed the doc and provided feedback via GH issues
… "How to Threat Model" is a three step process:
… 1. Paint a picture of the system
… 2. Capture threats
… 3. Describe responses
… for step 1, the expected deliverable is a data flow diagram, UML sequence diagram or such that illustrates the actors and the flows between them
… WebMCP explainer has a diagram we can reuse as a starting point:
https://
Anssi: for step 2, I've asked the authors of this guide for enhancements to the guide to help us get started with WebMCP threat identification and analysis
… I think step 3 follows more naturally when we have identified the threats in step 2
… questions, comments?
<brwalder> Credit goes to Google for that diagram. I just converted it to PNG.
Simone: thanks for the comments for the guide, Anssi
… I love the diagram in the explainer, I also see Johann and others looking at privacy and security aspects of WebMCP
… we have threat modeling group that does threat modeling together on new proposals
… we it can say work asynchronously
… we can help this group with this exercise
Anssi: are there other web features that have done threat modeling we could learn from?
Simone: digital credentials is one early feature that has experimented with this threat modeling process
Johann: I appreciate the exercise, related features are a bit new space, a lot of depend on probabilistic defences for which we don't have solutions in the standards based, we've worked on deterministic features
… historically
Simone: next step would be to work asynchronously on the threat modeling of WebMCP and perhaps set up a meeting to work on the problem space in realtime
Johann: everyone's very busy working with WebMCP so we appreciate support from Security IG participants with this exercise
Johann: let's sync in the issue for the exact next steps