Thank you for the additional details. Sounds good, LGTM3

On Wed, Apr 8, 2026 at 10:47 AM Vladimir Levin <[email protected]> wrote:

> Thank you for your responses.
>
> LGTM2
>
> Thanks,
> Vlad
>
> On Tue, Apr 7, 2026 at 7:16 PM Mike Wasserman <[email protected]> wrote:
>
>>
>>
>> On Tuesday, April 7, 2026 at 12:43:45 PM UTC-7 Rick Byers wrote:
>>
>> On Tue, Apr 7, 2026 at 3:00 PM Mike Wasserman <[email protected]> wrote:
>>
>> See responses inline, thanks!
>>
>> On Tuesday, April 7, 2026 at 7:45:10 AM UTC-7 Vladimir Levin wrote:
>>
>> On Mon, Apr 6, 2026 at 6:04 PM Mike Wasserman <[email protected]> wrote:
>>
>> *Regarding TAG review status:*
>> The scope of issues raised is broad. We conducted thoughtful
>> google-internal reviews <http://go/prompt-api-internal-tag-review> and
>> triage <http://go/prompt-api-internal-tag-triage>, and prioritized
>> addressing issues that couldn't be addressed after launch by
>> backwards-compatible spec and implementation changes. In that regard,
>> sampling parameters are not part of this initial launch proposal, and
>> various API identifiers have been renamed.
>>
>>
>> Thanks Mike. From the triage doc I see there were three ship blockers
>> identified and now addressed:
>> [Tag Review] - Quota vs. context window
>> <https://github.com/webmachinelearning/prompt-api/issues/177>
>> [Tag Review] - Interoperable model parameters
>> <https://github.com/webmachinelearning/prompt-api/issues/170>
>> measureInputUsage includes <model> start response token
>> <https://issues.chromium.org/issues/481450143>
>>
>> I agree the others are non-blocking. Thank you! Broadly from all the
>> public dialog and collaboration I've seen I trust you and the team to keep
>> investing in the tricky tradeoffs here and expanding the industry
>> alignment. So this is good enough for me for now.
>>
>> Is the explainer up-to-date with the proposed changes? I'm struggling to
>> understand exactly what will ship if this intent is approved. As an aside,
>> the explainer starts with "This proposal is an early design sketch ...",
>> which I suspect should be updated to indicate that this is close to
>> shipping.
>>
>>
>> Thanks for this question. While we've kept many aspects of the explainer
>> updated with changes for the initial web platform API launch, we've also
>> been representing enhancements slated for experimentation after the initial
>> launch (e.g. tool use, sampling parameters), and other parts have grown
>> stale. I'm preparing an explainer PR to update and clarify this document in
>> the next day or two.
>>
>>
>> Also in the explainer: "The following features have been recently
>> renamed. The legacy aliases are deprecated, and clients should update their
>> code ...". Was this an OT or developer trial or just people trying this out?
>>
>>
>> The API has been in Web Origin Trial from Chrome 139 (August 2025), and
>> launched general availability for Chrome Extensions in Chrome 138 (June
>> 2025). TAG feedback
>> <https://github.com/w3ctag/design-reviews/issues/1093#issuecomment-3515070512>
>>  provided
>> in Nov 2025 suggested these renames; spec
>> <https://github.com/webmachinelearning/prompt-api/pull/192> and impl
>> <https://issues.chromium.org/issues/481707656> renames were performed in
>> Feb 2026. Their legacy aliases are deprecated in extension contexts and
>> will be removed in due course to align with the Web API.
>>
>>
>> Generally, I agree that we should ship something in this space like this
>> API so thank you for working on this! I'm a little worried about stability
>> of the API shape though. Specifically, I'm wondering if we've had developer
>> feedback on the shape of the API and that it accomplishes the needed goals.
>> Can you comment on this? As a concrete example, specifying "role" as
>> hard-coded strings either "user" or "assistant" seems a little brittle to
>> me as compared to some declared constant in LanguageModel. Again, I'm not
>> suggesting that these should change, but simply asking if real-world
>> developers had a chance to explore this feature and provide feedback
>>
>>
>> We believe API shape has stabilized through comprehensive experimentation
>> phases (lengthy Extension+Web Dev Trial, early partner programs and
>> hackathons, Extension Origin Trial and GA Launch, extended Web Origin
>> Trial), and is ready for shipping to the open Web in Chrome. Most developer
>> feedback about the API shape was in early Dev Trial stages, which
>> precipitated many improvements for ergonomics and extensibility, reflected
>> in commits
>> <https://github.com/webmachinelearning/prompt-api/commits/main/> during
>> the first half of 2025 by our retired spec editor. These included the
>> addition of an append() method, message and content sequence refinements
>> (e.g. interleaving multimodal content of the same role), continued support
>> for `prompt("write a poem")` shorthand, and more.
>>
>> Since then, many real world developers have integrated this API in real
>> sites and exploratory demos, while others have built polyfills and
>> incorporated use in JS toolkits. We've additionally solicited feedback
>> through additional channels (e.g. devtools console messages on session
>> creation), and recent API shape feedback has generally been positive; no
>> issues have been raised regarding the LanguageModelMessageRole enum and its
>> use in the LanguageModelMessage dictionary. Our team is happy to continue
>> discussing any thoughtful feedback through issues filed in the spec
>> repository or Chromium issue tracker.
>>
>>
>> Thanks!
>> Vlad
>>
>>
>> We still need to respond to the rest; some touch on inherent risks of
>> platform advancements in this nascent domain; many could benefit from
>> outlining non-normative best practices for implementers to respect device
>> resources and real world costs. We will expedite sharing those responses.
>>
>> *Regarding wpt.fyi test failures:*
>> Almost all failures are model download timeouts; we hope to devise a way
>> to retain or sideload models in wpt.fyi's continuous integration
>> infrastructure.
>>
>>
>> Thanks. Do you have a report of some kind about what's passing vs.
>> failing in a harness that avoids the model download issue? I ran a few of
>> the tests myself manually (on wpt.live) and they passed. So I'm assuming
>> we're broadly in good shape, right? Just want to know details (a few known
>> failures with bugs is fine).
>>
>>
>> Thanks for asking. Internally, we have a separate python script that
>> side-loads pre-downloaded models and configurations to run WPTs on Chrome
>> builds, those are run continuously on FYI internal.optimization_guide
>> <https://ci.chromium.org/p/chrome/g/internal.optimization_guide/console> "wpt
>> bots" with a separate set of /third_party/blink/web_tests/AIExpectations
>> <https://crsrc.org/c/third_party/blink/web_tests/AIExpectations>, which
>> enumerates known failures (inherent side-loading availability values, and
>> hopefully solvable platform-specific timeouts). There's a single new
>> Mac-x64 failure there that I've been meaning to address this week.
>>
>> I also took the liberty of manually running the 28 WPT files in
>> https://wpt.live/ai/language-model/ on Chrome Canary and observed: 90/95
>> tests pass that pertain to proposed stable API surfaces. Two failures are
>> missing `gc()` WPT method references, two pertain to multimodal session
>> creation, and the last is a context usage measurement OBO. I will file
>> issues and followup with all of these. There are another 43 tests related
>> to experiments for params and tool use that aren't part of the initial API
>> launch.
>>
>>
>> *Regarding conformance testing and benchmarks / eval suites:*
>> Web platform tests should continually expand to include more substantive
>> conformance coverage, ideally including support for more objective analysis
>> of natural language. We have also conducted initial research
>> <https://docs.google.com/document/d/16r6Rdw-yomYu1GBce12IMLqrM8sVAX2Wy9YytbTlh3Q/edit?tab=t.0#heading=h.yzph7ln63fw4>
>> on cross-browser interop and are collaborating on followups, including
>> Microsoft fixing several bugs and planning model training around those
>> shared use cases of interest. Microsoft collaborators also explored a very
>> rough quality benchmark
>> <https://sushanthr.github.io/PromptAPI/quality.htm>. We are also
>> discussing internally and with partners about use cases and data sets that
>> can be shared publicly and use to represent performance baselines on
>> different representative devices. We don't have yet a formal open/public
>> discussion yet, but we have been iterating on some eval tests, e.g.
>> https://web-ai.studio/cortex. We will continue to iterate and engage
>> with the goal of formalizing open quality and performance eval suites.
>>
>> *Adding color to the "strongly positive" web developers feedback
>> statement:*
>> We have run a number of hackathons, especially the Google Chrome
>> Built-in AI Challenge 2025 <https://googlechromeai2025.devpost.com/>, and
>> have a good number of engagement from specific partner explorations. We
>> also get anecdotal positive organic signals from press articles, forum
>> threads, and direct feedback
>> <https://github.com/webmachinelearning/prompt-api/issues/200>.
>>
>> On Monday, April 6, 2026 at 1:23:22 PM UTC-7 Rick Byers wrote:
>>
>> On Fri, Apr 3, 2026 at 3:53 PM Mike Taylor <[email protected]>
>> wrote:
>>
>> LGTM1
>>
>> The only thing I was going to request was already taken care of: pinging
>> the Mozilla issue and providing a pointer to this thread (since it's been
>> about a year - maybe their position has evolved).
>> On 4/1/26 6:57 p.m., Deepti Bogadi wrote:
>>
>> Contact emails
>>
>> [email protected], [email protected], [email protected],
>> [email protected]
>>
>> Explainer
>>
>> https://github.com/webmachinelearning/prompt-api/blob/main/README.md
>>
>> Specification
>>
>> http://webmachinelearning.github.io/prompt-api
>>
>> Summary
>>
>> The Prompt API gives web developers direct access to a browser-provided
>> on-device AI language model. The API design offers fine-grained control,
>> aligned with cloud API shapes, for progressively enhancing sites with model
>> interactions tailored to individualized use cases. This compliments
>> task-based language model APIs (e.g. Summarizer API), and varied APIs and
>> frameworks for generalized on-device inference with developer-supplied ML
>> models. The initial implementation supports text, image, and audio inputs,
>> as well as response constraints that ensure generated text conforms with
>> predefined regex and JSON schema formats.
>>
>> This supports a variety of use cases, from generating image captions and
>> performing visual searches to transcribing audio, classifying sound events,
>> generating text following specific instructions, and extracting information
>> or insights from multimodal source material.
>>
>> This API has already been shipped in Chrome Extensions; this intent
>> tracks the shipping on the web. An enterprise policy
>> GenAILocalFoundationalModelSettings
>> <https://chromeenterprise.google/policies/#GenAILocalFoundationalModelSettings>
>> is available to disable the underlying model downloading, which would
>> render this API unavailable. Enterprise admins can also set the
>> BuiltInAIAPIsEnabled policy to block Built-In AI API usage, while still
>> permitting other on-device GenAI features.
>>
>> Language support log:
>>
>>    -
>>
>>    Chrome M139 and earlier only supported English ('en')
>>    -
>>
>>    Chrome M140 added support for Spanish and Japanese ('es' and 'ja')
>>
>>
>>
>> Blink component
>>
>> Blink > AI > Prompt
>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%20%3E%20AI%20%3E%20Prompt%22>
>>
>> Web Feature ID
>>
>> https://github.com/web-platform-dx/web-features/issues/3530
>>
>> Motivation
>>
>> Direct access to a language model can help web developers accomplish
>> tasks beyond those with dedicated APIs (e.g. Summarizer API) , and tailor
>> their usage for site-specific requirements. Compared to the low-level APIs
>> approach (e.g a custom AI model run via WebGPU, WASM, or WebNN), using the
>> built-in language model can save the user's bandwidth and disk space, and
>> has a lower barrier to entry. The design offers simple shorthands for
>> common patterns (e.g. await session.prompt(‘write a haiku’)), and
>> supports more complex use cases for handling structured content sequences,
>> streaming responses, availability checks, session management, and response
>> constraints.
>>
>> Initial public proposal
>>
>> https://github.com/webmachinelearning/charter/pull/9
>>
>> Search tags
>>
>> LanguageModel <https://chromestatus.com/features#tags:LanguageModel>, 
>> Language
>> Model <https://chromestatus.com/features#tags:Language%20Model>, Prompt
>> API, Built-in AI
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/1093
>>
>> TAG review status
>>
>> Issues addressed
>>
>> Can you elaborate on this? I see 14 issues
>> <https://github.com/webmachinelearning/prompt-api/issues?q=label%3A%22tag-tracker%22>
>> were filed in the spec repo based on TAG feedback, but all are still 'open'
>> with little comment. As you mentioned below, the interoperable model
>> parameters <https://github.com/webmachinelearning/prompt-api/issues/170>
>> one was addressed by leaving these as "experimental", so I assume they are
>> not covered by this I2S.
>>
>> Many of these issues don't seem particularly actionable to me - they
>> represent inherent risks in this space which, personally, I think we should
>> be comfortable taking, learning from and iterating on post-ship. It's fine
>> to disagree with TAG on this (especially since even TAG couldn't agree
>> among themselves - the issue is formally 'lacks consensus'). But maybe
>> there are still one or two things we should be doing now to reduce
>> future interop risk?
>>
>> Can you do a triage pass over the issues and flag which are fine to leave
>> for future consideration (as a non-breaking enhancement), which have
>> been mitigated for now (eg. model params), and which are ones the group
>> just disagrees with and wants to close? If there are any which seem like
>> they have a good chance of leading to future interop risk, just call those
>> out. Personally interop risk here seem unavoidable and I appreciate the
>> amount of effort that's gone into collaborating between two different
>> implementations (Google and Microsoft). Given the developer demand I do
>> think we should be shipping, I just want the transparency of being clear on
>> our thinking at this point to maximize learning.
>>
>> WebFeature UseCounter name
>>
>> kLanguageModel_Create
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> The Prompt API is designed to provide a stable and interoperable surface
>> for language model interactions, acknowledging the inherent diversity and
>> non-deterministic nature of underlying models. Variance in behaviors and
>> responses is a well understood expectation amongst developers employing
>> this technology, and this API aims to provide an interoperable framework
>> for consistent web platform access across browsers and models.
>>
>> The Prompt API specifically aims to maximize compatibility by:
>>
>> - Codifying an interoperable API surface for generalized language model
>> interactions, so developers can write code that works across different
>> browser engines and models. This surface has demonstrated compatibility
>> with models from Google and Microsoft, and been polyfilled by extensions
>> and JS frameworks, using different backends.
>>
>> - Enforcing objective response conformance with constraints that ensure
>> output adheres to known JSON schemas or regexes for interoperable
>> processing of generated text.
>>
>> - Supporting progressive enhancement patterns, by offering availability
>> signals that encapsulate device and model support dimensions, and encourage
>> developers to consider this API as one option among varied compatible AI
>> offerings, including developer supplied models and cloud-based services.
>>
>> Shipping this API provides a critical opportunity to broaden real-world
>> implementation experience, explore future refinements, and collaborate with
>> the web community on interoperable model diversity within a robust,
>> predictable platform surface.
>>
>> Agreed, thank you!
>>
>> Gecko: Negative (https://github.com/mozilla/standards-positions/issues/
>> 1213)
>>
>> WebKit: No signal (https://github.com/WebKit/sta
>> ndards-positions/issues/495)
>>
>> Web developers: Strongly positive (https://github.com/webmachine
>> learning/prompt-api/blob/main/README.md#stakeholder-feedback)
>>
>> Other signals: Microsoft Edge developers have been strong collaborators
>> with notable contributions including structured output, and experimental
>> tool use enhancements. Edge will be shipping this API using a different
>> underlying model.
>>
>> Ergonomics
>>
>> The API deprecated parameters and renamed identifiers, leaving legacy
>> access for previously launched extension contexts. We plan to align the web
>> and extension surfaces through careful additive changes and cautious
>> deprecation processes. Developers are encouraged to use the new identifier
>> names in both contexts and observe deprecation messages regarding planned
>> API alignments.
>>
>> Activation
>>
>> This feature would definitely benefit from having polyfills
>> <https://www.npmjs.com/package/prompt-api-polyfill>, backed by any of:
>> cloud services, lazily-loaded client-side models using WebGPU/WASM/WebNN,
>> or the web developer's own server. We anticipate seeing an ecosystem of
>> polyfills and client frameworks grow as more developers experiment with
>> this API.
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> Not Applicable; this API is not available in WebView.
>>
>>
>> Debuggability
>>
>> The API surface supports basic DevTools debugging. Perfetto tracing (via
>> optimization_guide and other events) is useful, and internal debugging
>> pages which give more detail on the model's status, e.g.
>> chrome://on-device-internals might be suitable to port into DevTools.
>> The team is maintaining extensions
>> <https://chromewebstore.google.com/detail/webai-extension/lmjgpcigjcffnphimblhcoccjfefamcp>
>> of DevTools panels for improving debuggability. It is possible that giving
>> more insight into the nondeterministic states of the model, e.g. random
>> seeds, could help with debugging.
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>>
>> No
>>
>> The initial launch focuses on Windows, Mac, Linux, and ChromeOS (on 
>> Chromebook
>> Plus <https://www.google.com/chromebook/chromebookplus/> devices). An
>> implementation for Android using that platform’s OS-level built-in language
>> model is being prototyped and will ship after the initial launch.
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?
>>
>> No
>>
>> Web platform tests cover the API surface adequately:
>> https://wpt.fyi/results/ai/language-model These attempt to mitigate
>> execution environments differences, e.g. stub/full implementations
>> (content_shell, chrome), and device/model states (unavailable,
>> downloadable, downloaded).
>>
>> Yeah that's probably the most we can ask for in this intent. However most
>> of these tests appear to be failing on wpt.fyi. Can you please triage all
>> the failures on wpt.fyi and either fix them so they're passing or explain
>> why the failure doesn't represent a real interop issue?
>>
>> The core responses of real models can be unpredictable (especially
>> without sampling parameters) and may cause inconsistent test results, but
>> some facets are more readily testable, e.g. the adherence to structured
>> output response constraints. Test coverage and reliability improvements are
>> ongoing, including planning for WebDriver extensions.
>>
>> Are there tracking issues in the CG regarding conformance testing that
>> you can point to? Are there discussions somewhere around benchmarks / eval
>> suites? Just like with our other big non-determinstic area of competition
>> in browsers, web performance, having open benchmarks can be very useful for
>> promoting compatibility.
>>
>>
>> DevTrial instructions
>>
>> https://developer.chrome.com/docs/ai/prompt-api
>>
>> Flag name on about://flags
>>
>> prompt-api-for-gemini-nano-multimodal-input
>>
>> Finch feature name
>>
>> AIPromptAPIMultimodalInput
>>
>> Rollout plan
>>
>> Will ship enabled for all users
>>
>> Requires code in //chrome?
>>
>> True
>>
>> Tracking bug
>>
>> https://crbug.com/417526788
>>
>> Launch bug
>>
>> https://launch.corp.google.com/launch/4461863
>>
>> Measurement
>>
>> The API has use counters for all methods and attributes e.g.:
>> LanguageModel_Create LanguageModel_Availability LanguageModel_Prompt
>> LanguageModel_PromptStreaming LanguageModel_Append LanguageModel_
>> MeasureContextUsage LanguageModel_OnContextOverflow
>> LanguageModel_ContextUsage LanguageModel_ContextWindow LanguageModel_Clone
>> LanguageModel_Destroy
>>
>> Non-OSS dependencies
>>
>> Does the feature depend on any code or APIs outside the Chromium open
>> source repository and its open-source dependencies to function?
>>
>> Yes: this feature depends on a language model, which is bridged to the
>> open-source parts of the implementation via the interfaces in
>> //services/on_device_model.
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>> 148
>>
>> Origin trial desktop first
>>
>> 139
>>
>> Origin trial desktop last
>>
>> 144
>>
>> Origin trial extension 1 end milestone
>>
>> 147
>>
>> DevTrial on desktop
>>
>> 137
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>>
>> Params may be re-added after addressing interop concerns:
>> https://github.com/webmachinelearning/prompt-api/issues/170 Identifiers
>> have been renamed for clarity before Web GA launch: https://github.com/
>> webmachinelearning/prompt-api/issues/177 Any post-launch additive
>> changes should be backwards compatible: e.g. tool use, multimodal sampling
>> info/options and outputs, session history access, model info/options, etc.
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5134603979063296?gate=5123192519393280
>>
>> Links to previous Intent discussions
>>
>> Intent to Prototype: https://groups.google.com/a/ch
>> romium.org/d/msgid/blink-dev/CAM0wra_LXU8KkcVJ0x%3DzYa4h_sC
>> 3FaHGdaoM59FNwwtRAsOALQ%40mail.gmail.com
>>
>> Intent to Experiment: https://groups.google.com/a/ch
>> romium.org/d/msgid/blink-dev/CAM0wra9oT0jygAYT00WPp0_wtZ-
>> znrB2OdZ6GQb%2B3thFLP19pA%40mail.gmail.com
>>
>> Intent to Extend Experiment 1: https://groups.google.com/a/ch
>> romium.org/d/msgid/blink-dev/CAJcT_ZhyheBntZHMEwFJA%3DuhpkWmDx8yFieL5E5g%
>> 2Bwp5UA0mzQ%40mail.gmail.com
>>
>> This intent message was generated by Chrome Platform Status
>> <https://chromestatus.com/>.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion visit https://groups.google.com/a/ch
>> romium.org/d/msgid/blink-dev/CAJcT_Zj73wjXZfmMcpQRWePp-H%
>> 3D5LzxYBOnasViYcn%3DFzY2vVQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJcT_Zj73wjXZfmMcpQRWePp-H%3D5LzxYBOnasViYcn%3DFzY2vVQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
>> To view this discussion visit https://groups.google.com/a/ch
>> romium.org/d/msgid/blink-dev/c257bea5-b444-42ab-b195-402593
>> 0206f2%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c257bea5-b444-42ab-b195-4025930206f2%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>>
>> To view this discussion visit https://groups.google.com/a/ch
>> romium.org/d/msgid/blink-dev/fd88dc6e-a5fd-4dfd-9a8a-78971c
>> 13d363n%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fd88dc6e-a5fd-4dfd-9a8a-78971c13d363n%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25e6f203-87b6-4844-9edf-fa301ad36e3an%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/25e6f203-87b6-4844-9edf-fa301ad36e3an%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_YCuAajD2NZWSFrj5Q9ZBKvS8D6CXNOmxrS9uxodWUQg%40mail.gmail.com.

Reply via email to