Just a quick update: the launch is now being retargeted for M151, following the most recent discussions and the finalization of the specification at https://w3c.github.io/mediacapture-extensions/#media-capture-html-elements. On Tuesday, May 5, 2026 at 10:19:00 PM UTC+2 [email protected] wrote:
> Note in case folks missed it, <usermedia> is pausing their launch and > extending their OT > <https://groups.google.com/a/chromium.org/g/blink-dev/c/RtvK2dTcrEI?e=48417069> > instead > in order to give more time to address some of the feedback. > > On Tue, May 5, 2026 at 3:58 PM 'Thomas Nguyen' via blink-dev < > [email protected]> wrote: > >> Thanks for the standards position requests. But they reference >>> https://github.com/w3c/mediacapture-extensions/pull/168 which is more >>> recent, has outstanding review comments, and looks quite different ( >>> preview >>> <https://pr-preview.s3.amazonaws.com/tungnh28/mediacapture-extensions/pull/168.html#media-capture-html-elements> >>> , explainer >>> <https://github.com/tungnh28/mediacapture-extensions/blob/5884ebfb706ff227da2429447470c53b11ec6fa0/media-capture-elements-explainer.md>) >>> >>> from spec references and explainers in this I2S. >>> For clarity on how those requests relate to this I2S, what exactly is >>> intended to ship? Will <usermedia> deviate from what's described in >>> the standards position requests, and if so how? >> >> That’s a good catch. The explainer in >> https://github.com/w3c/mediacapture-extensions/pull/168 is the most >> accurate reflection of the plan (including both MVP for <usermedia> and >> post-MVP <camera> and <microphone> shipping). I'll make sure the I2S >> document is updated to point to that link as soon as it lands. >> >> The *"Goals for experimentation"* part that was removed mentioned: >>> *"To ensure a seamless transition and prevent disruption for our valued >>> OT partners, this trial will initially launch with an API shape that is >>> functionally equivalent to the previous <permission> trial, simply using >>> the new <usermedia> element name".*Does this also apply to what's >>> shipping? A lot of the agreement that was reached over this API came from >>> abandoning the request permission-ahead-of-use in favor of the established >>> permission-at-point-of-use model on the web. >>> Specifically, will the MVP <usermedia> element allow requesting >>> permission ahead of turning on camera/microphone devices? If yes, do you >>> have a migration path away from that model, as it is generally a regression >>> of the web model that is web incompatible? >> >> You’re right, the original OT had a different scope. To address the >> concerns in the MVP launch, we are implementing a migration path allowing >> sites to opt into the new element at their own pace (while keeping the >> behavior the same as the generic permission element), and we are evaluating >> a reverse OT to further assist this transition. >> To ensure a smooth transition for developers, we have prepared a >> migration document detailing the necessary steps. I'll update the doc as a >> public link and share it here shortly. (or in the above PR). >> >> On Fri, May 1, 2026 at 8:08 PM Jan-Ivar Bruaroey <[email protected]> >> wrote: >> >>> On Thursday, April 23, 2026 at 11:02:51 AM UTC-4 Minh Le wrote: >>> >>> Hi Dan, >>> thank you for the reminder, here are the standard positions requests >>> >>> - https://github.com/WebKit/standards-positions/issues/651 >>> - https://github.com/mozilla/standards-positions/issues/1392 >>> >>> >>> Thanks for the standards position requests. But they reference >>> https://github.com/w3c/mediacapture-extensions/pull/168 which is more >>> recent, has outstanding review comments, and looks quite different ( >>> preview >>> <https://pr-preview.s3.amazonaws.com/tungnh28/mediacapture-extensions/pull/168.html#media-capture-html-elements>, >>> >>> explainer >>> <https://github.com/tungnh28/mediacapture-extensions/blob/5884ebfb706ff227da2429447470c53b11ec6fa0/media-capture-elements-explainer.md>) >>> >>> from spec references and explainers in this I2S. >>> >>> For clarity on how those requests relate to this I2S, what exactly is >>> intended to ship? Will <usermedia> deviate from what's described in >>> the standards position requests, and if so how? >>> >>> The *"Goals for experimentation"* part that was removed mentioned: *"To >>> ensure a seamless transition and prevent disruption for our valued OT >>> partners, this trial will initially launch with an API shape that is >>> functionally equivalent to the previous <permission> trial, simply using >>> the new <usermedia> element name".* >>> >>> Does this also apply to what's shipping? A lot of the agreement that >>> was reached over this API came from abandoning the request >>> permission-ahead-of-use in favor of the established >>> permission-at-point-of-use model on the web. >>> >>> Specifically, will the MVP <usermedia> element allow requesting >>> permission ahead of turning on camera/microphone devices? If yes, do you >>> have a migration path away from that model, as it is generally a regression >>> of the web model that is web incompatible? >>> >>> On Wednesday, April 29, 2026 at 11:19:55 AM UTC-4 [email protected] >>> wrote: >>> >>>> LGTM3 >>>> >>>> On Tuesday, April 28, 2026 at 11:23:38 AM UTC-7 [email protected] >>>> wrote: >>>> >>>>> Please update the chromestatus entry to specify the new TAG review for >>>>>> <usermedia> rather than the old PEPC one, and link to the new webkit >>>>>> standards position. >>>>> >>>>> Done, thanks. >>>>> >>>>> Also, this I2S specifies "goals for experimentation" - why is that >>>>>> there? You're asking to fully ship, right? >>>>> >>>>> I think that's a left over we filled in in the OT request. Removed >>>>> that. >>>>> >>>>> On Tue, Apr 28, 2026 at 5:55 PM Chris Harrelson <[email protected]> >>>>> wrote: >>>>> >>>> Please update the chromestatus entry to specify the new TAG review for >>>>>> <usermedia> rather than the old PEPC one, and link to the new webkit >>>>>> standards position. >>>>>> >>>>>> Also, this I2S specifies "goals for experimentation" - why is that >>>>>> there? You're asking to fully ship, right? >>>>>> >>>>>> On Mon, Apr 27, 2026 at 2:51 AM 'Thomas Nguyen' via blink-dev < >>>>>> [email protected]> wrote: >>>>>> >>>>> That sounds like a solid idea. Thank you for the suggestion, Philipp; >>>>>>> I have noted it down. >>>>>>> We will certainly add this to our roadmap and include the sample >>>>>>> after the API is merged into the media capture extensions. This will >>>>>>> ensure >>>>>>> better alignment with the approved shape. >>>>>>> >>>>>>> >>>>>>> On Sat, Apr 25, 2026 at 4:57 PM Philipp Hancke < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>> Looking forward to this shipping! Can you please also add a sample to >>>>>>>> https://github.com/webrtc/samples >>>>>>>> which remains a go-to location for all things getUserMedia and >>>>>>>> WebRTC (maybe we can get it to 15k stars finally ;-)) >>>>>>>> >>>>>>>> Am Mi., 15. Apr. 2026 um 16:39 Uhr schrieb Chromestatus < >>>>>>>> [email protected]>: >>>>>>>> >>>>>>> *Contact emails* >>>>>>>>> [email protected], [email protected] >>>>>>>>> >>>>>>>>> *Explainer* >>>>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md >>>>>>>>> >>>>>>>>> *Specification* >>>>>>>>> https://wicg.github.io/PEPC/permission-elements.html >>>>>>>>> >>>>>>>>> *Summary* >>>>>>>>> Usermedia Capability Element, is a declarative, user-activated >>>>>>>>> control for accessing the starting and interacting with media >>>>>>>>> streams. This >>>>>>>>> addresses the long-standing problem of permission prompts being >>>>>>>>> triggered >>>>>>>>> directly from JavaScript without a strong signal of user intent. By >>>>>>>>> embedding a browser-controlled element in the page, the user's click >>>>>>>>> provides a clear, intentional signal. This enables a much better >>>>>>>>> prompt UX >>>>>>>>> and, crucially, provides a simple recovery path for users who have >>>>>>>>> previously denied the permission. Note: This feature was previously >>>>>>>>> developed and tested in an Origin Trial as the more generic >>>>>>>>> <permission> >>>>>>>>> element. Based on feedback from developers and other browser vendors, >>>>>>>>> it >>>>>>>>> has evolved into capability-specific elements to provide a more >>>>>>>>> tailored >>>>>>>>> and powerful developer experience. >>>>>>>>> >>>>>>>>> *Blink component* >>>>>>>>> Public Trackers > Chromium Public Trackers > Chromium > Internals >>>>>>>>> > Permissions > PermissionElement >>>>>>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Public%20Trackers%20%3E%20Chromium%20Public%20Trackers%20%3E%20Chromium%20%3E%20Internals%20%3E%20Permissions%20%3E%20PermissionElement%22> >>>>>>>>> >>>>>>>>> *Web Feature ID* >>>>>>>>> permissions <https://webstatus.dev/features/permissions> >>>>>>>>> >>>>>>>>> *Motivation* >>>>>>>>> The current web permission model for interacting with user media >>>>>>>>> relies on JavaScript-triggered prompts, giving the user agent no >>>>>>>>> strong >>>>>>>>> signal of user intent. This results in out-of-context prompts, user >>>>>>>>> frustration, and difficult-to-recover-from denial states. We propose >>>>>>>>> the >>>>>>>>> <usermedia> element, or a suite of elements. This will be semantic >>>>>>>>> HTML >>>>>>>>> control with browser-controlled content and strict styling >>>>>>>>> constraints. >>>>>>>>> These constraints are fundamental to the security model, ensuring a >>>>>>>>> very >>>>>>>>> high level of confidence in the user's intent when making a >>>>>>>>> permission >>>>>>>>> decision at both the site and OS level. Crucially, the <usermedia> >>>>>>>>> element >>>>>>>>> evolves beyond simply managing permissions; it streamlines the entire >>>>>>>>> journey by also facilitating starting and interacting with media >>>>>>>>> streams. >>>>>>>>> This often eliminates the need for separate JavaScript API calls, >>>>>>>>> simplifying implementation and creating a more seamless user flow. By >>>>>>>>> providing a clear, consistent, in-page control, this element solves >>>>>>>>> significant user problems related to context blindness and >>>>>>>>> "permission >>>>>>>>> regret," offering a simple recovery path from a previously denied >>>>>>>>> state. >>>>>>>>> The combination of a user-initiated element and a subsequent >>>>>>>>> browser-controlled confirmation UI enhances intent capture, improves >>>>>>>>> accessibility, and prevents manipulative patterns, providing a >>>>>>>>> significantly better experience for both users and developers. >>>>>>>>> >>>>>>>>> *Initial public proposal* >>>>>>>>> https://github.com/WICG/PEPC/issues/62 >>>>>>>>> >>>>>>>>> *TAG review* >>>>>>>>> https://github.com/w3ctag/design-reviews/issues/1079 >>>>>>>>> >>>>>>>>> *TAG review status* >>>>>>>>> Issues addressed >>>>>>>>> >>>>>>>>> *Origin Trial Name* >>>>>>>>> UserMediaElement >>>>>>>>> >>>>>>>>> *Goals for experimentation* >>>>>>>>> This Origin Trial serves two primary purposes: ensuring continuity >>>>>>>>> for existing partners who have successfully integrated this pattern, >>>>>>>>> and >>>>>>>>> providing a platform to validate and iterate on the new, >>>>>>>>> capability-specific <usermedia> element. While our previous Origin >>>>>>>>> Trial >>>>>>>>> for <permission> provided strong evidence for the core user-initiated >>>>>>>>> model, feedback from developers and browser vendors prompted us to >>>>>>>>> evolve >>>>>>>>> the design. This new trial is essential for gathering insights on a >>>>>>>>> refined, data-centric API shape to help us reach cross-browser >>>>>>>>> consensus. >>>>>>>>> To ensure a seamless transition and prevent disruption for our valued >>>>>>>>> OT >>>>>>>>> partners, this trial will initially launch with an API shape that is >>>>>>>>> functionally equivalent to the previous <permission> trial, simply >>>>>>>>> using >>>>>>>>> the new <usermedia> element name. This provides a stable foundation >>>>>>>>> from >>>>>>>>> which we will iterate based on further discussion. Our goal is to >>>>>>>>> evolve >>>>>>>>> this element towards our proposed data-centric design ( >>>>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md). >>>>>>>>> However, we recognize that this more advanced API has raised >>>>>>>>> compatibility >>>>>>>>> and complexity concerns with developers ( >>>>>>>>> https://github.com/WICG/PEPC/issues/62). Therefore, a primary >>>>>>>>> objective of this trial is to work closely with the community to >>>>>>>>> address >>>>>>>>> these concerns and refine the final API. TPAC WebRTC minutes >>>>>>>>> https://www.w3.org/2025/11/11-webrtc-minutes.html#551 >>>>>>>>> >>>>>>>>> *Chromium Trial Name* >>>>>>>>> UserMediaElement >>>>>>>>> >>>>>>>>> *Origin Trial documentation link* >>>>>>>>> https://github.com/WICG/PEPC/blob/main/usermedia_element.md >>>>>>>>> >>>>>>>>> *WebFeature UseCounter name* >>>>>>>>> kHTMLPermissionElement >>>>>>>>> >>>>>>>>> *Risks* >>>>>>>>> >>>>>>>>> >>>>>>>>> *Interoperability and Compatibility* >>>>>>>>> There is a risk that this feature fails to be adopted by other >>>>>>>>> browsers. This can be mitigated by backwards designing a reasonable >>>>>>>>> fallback mechanism so that the element can degrade gracefully if the >>>>>>>>> it's >>>>>>>>> in an unsupported environment. >>>>>>>>> >>>>>>>>> *Gecko*: Under consideration ( >>>>>>>>> https://github.com/mozilla/standards-positions/issues/1245) >>>>>>>>> >>>>>>>>> *WebKit*: No signal >>>>>>>>> >>>>>>>>> *Web developers*: Positive >>>>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393820279 >>>>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393861768 >>>>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2393911331 >>>>>>>>> https://github.com/WICG/PEPC/issues/2#issuecomment-2619657041 >>>>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3482975001 >>>>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3482981942 >>>>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3498355775 >>>>>>>>> https://github.com/WICG/PEPC/issues/62#issuecomment-3513734884 >>>>>>>>> >>>>>>>>> *Other signals*: >>>>>>>>> >>>>>>>>> *Ergonomics* >>>>>>>>> No foreseen ergonomics risks. >>>>>>>>> >>>>>>>>> *Activation* >>>>>>>>> A polyfill can help developers use this feature without risking >>>>>>>>> broken functionality on non-supporting browsers. >>>>>>>>> >>>>>>>>> *Security* >>>>>>>>> https://github.com/WICG/PEPC/blob/main/explainer.md#Security >>>>>>>>> >>>>>>>>> *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? >>>>>>>>> Feature is not shipping on WebView due to it requiring permission >>>>>>>>> manager embedder support. >>>>>>>>> >>>>>>>>> >>>>>>>>> *Debuggability* >>>>>>>>> The element raises issues to the devtools issues panel which help >>>>>>>>> developers debug issues with their usage of the element. >>>>>>>>> >>>>>>>>> *Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>>>>>>> No >>>>>>>>> The element is not supported on Android WebView as it requires >>>>>>>>> permission manager support to function and the WebView permission >>>>>>>>> manager >>>>>>>>> defers most permission decisions to the embedder by design. >>>>>>>>> >>>>>>>>> *Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>>>>>>> Yes >>>>>>>>> https://wpt.fyi/results/html/semantics/permission-element/usermedia >>>>>>>>> >>>>>>>>> *DevTrial instructions* >>>>>>>>> https://github.com/WICG/PEPC/blob/main/HOWTO.md#enabling-usermedia >>>>>>>>> >>>>>>>>> *Flag name on about://flags* >>>>>>>>> *No information provided* >>>>>>>>> >>>>>>>>> *Finch feature name* >>>>>>>>> UserMediaElement >>>>>>>>> >>>>>>>>> *Rollout plan* >>>>>>>>> Will ship enabled for all users >>>>>>>>> >>>>>>>>> *Requires code in //chrome?* >>>>>>>>> True >>>>>>>>> >>>>>>>>> *Tracking bug* >>>>>>>>> https://crbug.com/443013457 >>>>>>>>> >>>>>>>>> *Availability expectation* >>>>>>>>> Feature is available only in Chromium browsers. We are not aware >>>>>>>>> of other browsers adoption. >>>>>>>>> >>>>>>>>> *Adoption expectation* >>>>>>>>> Feature is used by specific partner(s) to provide functionality >>>>>>>>> within 12 months of launch in Chrome. Partners who are tested the >>>>>>>>> feature >>>>>>>>> in OT are expected to continue usage. >>>>>>>>> >>>>>>>>> *Adoption plan* >>>>>>>>> We are planning to publish on developer.chrome.com and do further >>>>>>>>> partner outreach >>>>>>>>> >>>>>>>>> *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? >>>>>>>>> No >>>>>>>>> >>>>>>>>> *Estimated milestones* >>>>>>>>> Shipping on desktop 149 >>>>>>>>> Origin trial desktop first 144 >>>>>>>>> Origin trial desktop last 148 >>>>>>>>> DevTrial on desktop 144 >>>>>>>>> Shipping on Android 149 >>>>>>>>> Origin trial Android first 144 >>>>>>>>> Origin trial Android last 148 >>>>>>>>> DevTrial on Android 144 >>>>>>>>> >>>>>>>>> *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). >>>>>>>>> This is an MVP launch. The MVP feature is fully functional and >>>>>>>>> used by developers right now. We are working closely with the WebRTC >>>>>>>>> on >>>>>>>>> post-MVP features, the open topics will based on the foundation of >>>>>>>>> the MVP, >>>>>>>>> that we agreed upon with the WebRTC. Some of the open topics are for >>>>>>>>> example: In the future, we might want to add a parameter to the >>>>>>>>> getUserMedia algorithm so that the algorithm can determine whether >>>>>>>>> the >>>>>>>>> getUserMedia is called from the <usermedia> element or getUserMedia >>>>>>>>> API. >>>>>>>>> Potential to add additional attributes for <usermedia> interface. >>>>>>>>> We're >>>>>>>>> putting finishing touches on the spec now, work-in-progress PR is >>>>>>>>> here, but >>>>>>>>> once that lands we want to ship for M149 so wanted to start the >>>>>>>>> discussion >>>>>>>>> now. >>>>>>>>> >>>>>>>>> *Link to entry on the Chrome Platform Status* >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/4926233538330624?gate=6467532078841856 >>>>>>>>> >>>>>>>>> *Links to previous Intent discussions* >>>>>>>>> Intent to Prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/692719de.050a0220.17ec37.00c3.GAE%40google.com >>>>>>>>> Intent to Experiment: >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6942ed09.050a0220.1050d6.0961.GAE%40google.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/chromium.org/d/msgid/blink-dev/69dfa184.050a0220.c8e20.03e8.GAE%40google.com >>>>>>>>> >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69dfa184.050a0220.c8e20.03e8.GAE%40google.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Thomas Nguyen >>>>>>> >>>>>>> Software Engineer >>>>>>> >>>>>>> [email protected] >>>>>>> >>>>>>> Google Germany GmbH >>>>>>> >>>>>>> Erika-Mann-Straße 33 >>>>>>> >>>>>>> 80636 München >>>>>>> >>>>>>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>>>>>> >>>>>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>>>>> >>>>>>> Sitz der Gesellschaft: Hamburg >>>>>>> >>>>>>> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise >>>>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich >>>>>>> bitte >>>>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail is confidential. If you received this communication by >>>>>>> mistake, please don't forward it to anyone else, please erase all >>>>>>> copies >>>>>>> and attachments, and please let me know that it has gone to the wrong >>>>>>> person. >>>>>>> >>>>>>> -- >>>>>>> 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/CA%2BoJCSxCm3w%3DJSaikf6HwAfYe%3DgwrOi7rR%2Bi3Uz2sybR_Uuhew%40mail.gmail.com >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BoJCSxCm3w%3DJSaikf6HwAfYe%3DgwrOi7rR%2Bi3Uz2sybR_Uuhew%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Thomas Nguyen >>>>> >>>>> Software Engineer >>>>> >>>>> [email protected] >>>>> >>>>> Google Germany GmbH >>>>> >>>>> Erika-Mann-Straße 33 >>>>> >>>>> 80636 München >>>>> >>>>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >>>>> >>>>> Registergericht und -nummer: Hamburg, HRB 86891 >>>>> >>>>> Sitz der Gesellschaft: Hamburg >>>>> >>>>> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise >>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich >>>>> bitte >>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. >>>>> >>>>> >>>>> >>>>> This e-mail is confidential. If you received this communication by >>>>> mistake, please don't forward it to anyone else, please erase all copies >>>>> and attachments, and please let me know that it has gone to the wrong >>>>> person. >>>>> >>>> >> >> -- >> >> Thomas Nguyen >> >> Software Engineer >> >> [email protected] >> >> Google Germany GmbH >> >> Erika-Mann-Straße 33 >> >> 80636 München >> >> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado >> >> Registergericht und -nummer: Hamburg, HRB 86891 >> >> Sitz der Gesellschaft: Hamburg >> >> Diese E-Mail ist vertraulich. Falls Sie diese fälschlicherweise erhalten >> haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, >> löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, >> dass die E-Mail an die falsche Person gesendet wurde. >> >> >> >> This e-mail is confidential. If you received this communication by >> mistake, please don't forward it to anyone else, please erase all copies >> and attachments, and please let me know that it has gone to the wrong >> person. >> >> -- >> 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/CA%2BoJCSwo%3Du6bGD5C7M0bnr1mNbnregxxx8gsLzaTUEFpc0_bEQ%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BoJCSwo%3Du6bGD5C7M0bnr1mNbnregxxx8gsLzaTUEFpc0_bEQ%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/chromium.org/d/msgid/blink-dev/d3204299-b276-4847-afd7-2cfc7a8f0b2an%40chromium.org.
