Re: Network Information API

Hey Thomas,

+1 to the comments from Ilya and Yoav. In terms of NetInfo API usage, most
large partners for adaptive loading (eBay, Tinder, Twitter etc) relied on
effectiveType while a smaller minority (Algolia) used more of the signals
like rtt. See
https://www.algolia.com/blog/engineering/netinfo-api-algolia-javascript-client/
.

saveData had some minor adoption sites worked on by web performance experts
(
https://nooshu.com/blog/2019/09/01/speeding-up-the-web-with-save-data-header/)
but I didn’t see this go mainstream.

Perhaps the most helpful insight I can share is that the majority of users
just needed the ability to distinguish whether a connection was “fast” or
“slow” (not granular at all) while it was the most advanced partners
(Facebook) that felt they needed even more granularity than ECT currently
offers.

Happy to go into more detail on any of these points if needed.

Cheers,
Addy

On Thu, Aug 26, 2021 at 11:26 PM Ilya Grigorik <ilya@igvita.com> wrote:

> Hey folks.
>
> On Mon, Aug 23, 2021 at 12:47 AM Thomas Steiner <tomac@google.com> wrote:
>
>> One question that came up for you, Ilya, was whether there's still some
>> active spec work happening. It seems like all use cases circle around the
>> .type property, but not the other pieces of information exposed by the
>> API.
>>
>
> I've not been able to dedicate time to it in the last ~year, sadly. That
> said, I agree with Yoav's earlier assessment. The API has meaningful
> adoption in the wild and delivers value. That said, we've also learned a
> bunch over the past few years and I'd love to see a reboot that
> incorporates lessons learned and cleans up some of the rough edges.
>
> ig
>
>
>
>> For Addy, are you aware of example sites that use this API for adaptive
>> loading <https://addyosmani.com/blog/adaptive-loading/>? I feel like we
>> had case studies maybe?
>>
>> Thanks, both, in advance!
>>
>> Cheers,
>> Tom
>>
>>
>> ----------
>> From: Yoav Weiss <yoav@yoav.ws>
>> Date: Thu, Oct 22, 2020 at 10:00 AM
>> To: Thomas Steiner <tomac@google.com>, Tarun Bansal <tbansal@google.com>,
>> Noam Helfman <noamh@microsoft.com>
>> Cc: Ilya Grigorik <igrigorik@google.com>, Addy Osmani <addyo@google.com>,
>> W3C Devices and Sensors WG <public-device-apis@w3.org>
>>
>>
>> +Tarun Bansal <tbansal@google.com> +Noam Helfman <noamh@microsoft.com>
>> - FYI
>>
>> Hey Thomas!
>>
>> This was somewhat discussed in the WebPerformance WG yesterday (rough
>> minutes
>> <https://docs.google.com/document/d/1inejuvPONXPOLKTCcUzOBhPh6QOckMcltnR-E3xyZVQ/edit?ts=5f809f01#heading=h.8gfnc7p4nih>
>> , video <https://youtu.be/aID3BvpU_pE>).
>> Regarding spec work, at least on my end, there's desire (but not
>> necessarily immediate capacity) to revamp the API to ensure it provides
>> more value to developers while emitting less entropy.
>> The use cases, at least as far as I'm concerned, are not around `type`,
>> but around providing accurate measurement of the network conditions (so
>> around `effectiveConnectionType` and `RTT`). (e.g. this blog post
>> <https://blog.algolia.com/netinfo-api-algolia-javascript-client/>)
>>
>> Maybe Addy has more case studies.
>>
>> If folks at Device & Sensors are interested in collaborating on NetInfo
>> at the WICG or elsewhere, that'd be awesome! :)
>>
>> Cheers,
>> Yoav
>>
>>
>> ----------
>> From: Thomas Steiner <tomac@google.com>
>> Date: Thu, Oct 22, 2020 at 1:23 PM
>> To: Yoav Weiss <yoav@yoav.ws>
>> Cc: Thomas Steiner <tomac@google.com>, Tarun Bansal <tbansal@google.com>,
>> Noam Helfman <noamh@microsoft.com>, Ilya Grigorik <igrigorik@google.com>,
>> Addy Osmani <addyo@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>
>>
>>
>> On Thu, Oct 22, 2020 at 10:00 AM Yoav Weiss <yoav@yoav.ws> wrote:
>>
>>> +Tarun Bansal <tbansal@google.com> +Noam Helfman <noamh@microsoft.com>
>>> - FYI
>>>
>>> Hey Thomas!
>>>
>>> This was somewhat discussed in the WebPerformance WG yesterday (rough
>>> minutes
>>> <https://docs.google.com/document/d/1inejuvPONXPOLKTCcUzOBhPh6QOckMcltnR-E3xyZVQ/edit?ts=5f809f01#heading=h.8gfnc7p4nih>
>>> , video <https://youtu.be/aID3BvpU_pE>).
>>> Regarding spec work, at least on my end, there's desire (but not
>>> necessarily immediate capacity) to revamp the API to ensure it provides
>>> more value to developers while emitting less entropy.
>>>
>>
>> Yeah, the objective is shared between the two WGs :-)
>>
>>
>>> The use cases, at least as far as I'm concerned, are not around `type`,
>>> but around providing accurate measurement of the network conditions (so
>>> around `effectiveConnectionType` and `RTT`). (e.g. this blog post
>>> <https://blog.algolia.com/netinfo-api-algolia-javascript-client/>)
>>>
>>
>> Just to clarify, I meant the use cases as outlined in the spec
>> <https://wicg.github.io/netinfo/#requirements-and-use-cases>. Marcos
>> Caceres confirmed my suspicion that it all started with .type, and then
>> later on more details were added, but the use cases in the spec not updated.
>>
>>
>>> Maybe Addy has more case studies.
>>>
>>
>> That would be great!
>>
>> If folks at Device & Sensors are interested in collaborating on NetInfo
>>> at the WICG or elsewhere, that'd be awesome! :)
>>>
>>
>> We're definitely interested, judging from the discussion today.
>>
>> Cheers,
>> Tom
>>
>>
>> ----------
>> From: TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>
>> Date: Thu, Oct 22, 2020 at 4:18 PM
>> To: Thomas Steiner <tomac@google.com>, Yoav Weiss <yoav@yoav.ws>
>> Cc: Tarun Bansal <tbansal@google.com>, Noam Helfman <noamh@microsoft.com>,
>> Ilya Grigorik <igrigorik@google.com>, Addy Osmani <addyo@google.com>,
>> W3C Devices and Sensors WG <public-device-apis@w3.org>
>>
>>
>> Hi all,
>>
>>
>>
>> Quick question, is there any discussions on the privacy and security
>> implications of network api somewhere? If not, it might be a good idea to
>> consider that aspect, too.
>>
>>
>>
>> All the best,
>>
>> Ehsan
>>
>>
>> ----------
>> From: Noam Helfman <noamh@microsoft.com>
>> Date: Thu, Oct 22, 2020 at 4:49 PM
>> To: TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Thomas Steiner <
>> tomac@google.com>, Yoav Weiss <yoav@yoav.ws>
>> Cc: Tarun Bansal <tbansal@google.com>, Ilya Grigorik <
>> igrigorik@google.com>, Addy Osmani <addyo@google.com>, W3C Devices and
>> Sensors WG <public-device-apis@w3.org>
>>
>>
>> Some privacy related content here:
>>
>> https://wicg.github.io/netinfo/#privacy-considerations
>>
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> ------------------------------
>> *From:* TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>
>> *Sent:* Thursday, October 22, 2020 5:18:19 PM
>> *To:* Thomas Steiner <tomac@google.com>; Yoav Weiss <yoav@yoav.ws>
>> *Cc:* Tarun Bansal <tbansal@google.com>; Noam Helfman <
>> noamh@microsoft.com>; Ilya Grigorik <igrigorik@google.com>; Addy Osmani <
>> addyo@google.com>; W3C Devices and Sensors WG <public-device-apis@w3.org>
>> *Subject:* [EXTERNAL] Re: Network Information API
>>
>>
>>
>> ----------
>> From: TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>
>> Date: Thu, Oct 22, 2020 at 4:52 PM
>> To: Noam Helfman <noamh@microsoft.com>, Thomas Steiner <tomac@google.com>,
>> Yoav Weiss <yoav@yoav.ws>
>> Cc: Tarun Bansal <tbansal@google.com>, Ilya Grigorik <
>> igrigorik@google.com>, Addy Osmani <addyo@google.com>, W3C Devices and
>> Sensors WG <public-device-apis@w3.org>
>>
>>
>> Hi Noam,
>>
>>
>>
>> Thanks for link. Same as here, tracking was the first scenario I came up
>> with. I will have a read…
>>
>>
>>
>> All the best,
>>
>> Ehsan
>>
>>
>> ----------
>> From: Addy Osmani <addyo@google.com>
>> Date: Thu, Oct 22, 2020 at 5:11 PM
>> To: TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>
>> Cc: Noam Helfman <noamh@microsoft.com>, Thomas Steiner <tomac@google.com>,
>> Yoav Weiss <yoav@yoav.ws>, Tarun Bansal <tbansal@google.com>, Ilya
>> Grigorik <igrigorik@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>
>>
>>
>> Hey folks,
>>
>> I have observed almost no partner sites leveraging .type, but many do
>> rely on ECT for an adaptive loading strategy on low-quality networks
>> (Tinder, eBay, Algolia, Twitter). As Yoav mentioned, the most recent
>> conversations regarding ECT have focused on ways to offer a higher-level
>> signal with less entropy, which could do the right thing from a privacy
>> perspective. This direction does receive some pushback from partners who
>> want as much granularity as they can get.
>>
>> If folks are after specific case studies, happy to pull a list together.
>>
>> Cheers!
>> Addy
>>
>>
>> ----------
>> From: Thomas Steiner <tomac@google.com>
>> Date: Fri, Oct 23, 2020 at 2:12 PM
>> To: Addy Osmani <addyo@google.com>
>> Cc: TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <
>> noamh@microsoft.com>, Thomas Steiner <tomac@google.com>, Yoav Weiss <
>> yoav@yoav.ws>, Tarun Bansal <tbansal@google.com>, Ilya Grigorik <
>> igrigorik@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>
>>
>>
>> Thanks, all, for the responses so far. The initial question for @Ilya
>> Grigorik <igrigorik@google.com> still stands (whether there's still some
>> active spec work happening).
>>
>> Also, thanks, Addy, for the household names, we definitely have some
>> strong industry representatives in there and can thus say the use cases are
>> indeed valid and on active use.
>>
>> For the use cases in fact, there's some great discussion happening
>> already in issue 85 <https://github.com/WICG/netinfo/issues/85>, with
>> the "metered" aspects being the topic of issue 84
>> <https://github.com/WICG/netinfo/issues/84>. So I guess we're in a
>> theoretically good position to continue this discussion and just need to
>> agree on a practical way as to the how. Is this an adequate summary of the
>> state of affairs?
>>
>> Thanks,
>> Tom
>> --
>> Thomas Steiner, PhD—Developer Advocate (https://blog.tomayac.com,
>> https://twitter.com/tomayac)
>>
>> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg, Germany
>> <https://www.google.com/maps/search/ABC-Str.+19,+20354+Hamburg,+Germany?entry=gmail&source=g>
>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>> Registergericht und -nummer: Hamburg, HRB 86891
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.1.23 (GNU/Linux)
>>
>>
>> iFy0uwAntT0bE3xtRa5AfeCheCkthAtTh3reSabiGbl0ck0fjumBl3DCharaCTersAttH3b0ttom.
>> hTtPs://xKcd.cOm/1181/ <https://xkcd.com/1181/>
>> -----END PGP SIGNATURE-----
>>
>>
>> ----------
>> From: Ilya Grigorik <igrigorik@google.com>
>> Date: Fri, Oct 23, 2020 at 4:51 PM
>> To: Thomas Steiner <tomac@google.com>, Yoav Weiss <yoavweiss@google.com>
>> Cc: Addy Osmani <addyo@google.com>, TOREINI, EHSAN <
>> ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>, Yoav
>> Weiss <yoav@yoav.ws>, Tarun Bansal <tbansal@google.com>, W3C Devices and
>> Sensors WG <public-device-apis@w3.org>
>>
>>
>> Hey all.
>>
>> On Fri, Oct 23, 2020 at 5:12 AM Thomas Steiner <tomac@google.com> wrote:
>>
>>> Thanks, all, for the responses so far. The initial question for @Ilya
>>> Grigorik <igrigorik@google.com> still stands (whether there's still
>>> some active spec work happening).
>>>
>>
>> +Yoav Weiss <yoavweiss@google.com> captured it well, there is desire but
>> no active spec work to address some of the lessons learned. If someone is
>> willing to drive that process, that'd be great.
>>
>>
>>> Also, thanks, Addy, for the household names, we definitely have some
>>> strong industry representatives in there and can thus say the use cases are
>>> indeed valid and on active use.
>>>
>>> For the use cases in fact, there's some great discussion happening
>>> already in issue 85 <https://github.com/WICG/netinfo/issues/85>, with
>>> the "metered" aspects being the topic of issue 84
>>> <https://github.com/WICG/netinfo/issues/84>. So I guess we're in a
>>> theoretically good position to continue this discussion and just need to
>>> agree on a practical way as to the how. Is this an adequate summary of the
>>> state of affairs?
>>>
>>
>> Yes, I'd just caution not to over-index on the past backlog and first
>> spend some quality time on unpacking lessons learned from what is already
>> out there, and have a think on whether there is a simpler implementation
>> that can satisfy the key needs whilst exposing less entropy.
>>
>> ig
>>
>>
>> ----------
>> From: Thomas Steiner <tomac@google.com>
>> Date: Mon, Oct 26, 2020 at 10:09 AM
>> To: Ilya Grigorik <igrigorik@google.com>
>> Cc: Thomas Steiner <tomac@google.com>, Yoav Weiss <yoavweiss@google.com>,
>> Addy Osmani <addyo@google.com>, TOREINI, EHSAN <
>> ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>, Yoav
>> Weiss <yoav@yoav.ws>, Tarun Bansal <tbansal@google.com>, W3C Devices and
>> Sensors WG <public-device-apis@w3.org>
>>
>>
>> On Fri, Oct 23, 2020 at 4:51 PM Ilya Grigorik <igrigorik@google.com>
>> wrote:
>>
>>> Hey all.
>>>
>>> On Fri, Oct 23, 2020 at 5:12 AM Thomas Steiner <tomac@google.com> wrote:
>>>
>>>> Thanks, all, for the responses so far. The initial question for @Ilya
>>>> Grigorik <igrigorik@google.com> still stands (whether there's still
>>>> some active spec work happening).
>>>>
>>>
>>> +Yoav Weiss <yoavweiss@google.com> captured it well, there is desire
>>> but no active spec work to address some of the lessons learned. If someone
>>> is willing to drive that process, that'd be great.
>>>
>>
>> Thanks for the update, Ilya! I guess it's up to the two WGs' chairs then
>> to see if and how to collaborate on this spec then, right?
>>
>>
>>>  Also, thanks, Addy, for the household names, we definitely have some
>>> strong industry representatives in there and can thus say the use cases are
>>> indeed valid and on active use.
>>>
>>>>
>>>> For the use cases in fact, there's some great discussion happening
>>>> already in issue 85 <https://github.com/WICG/netinfo/issues/85>, with
>>>> the "metered" aspects being the topic of issue 84
>>>> <https://github.com/WICG/netinfo/issues/84>. So I guess we're in a
>>>> theoretically good position to continue this discussion and just need to
>>>> agree on a practical way as to the how. Is this an adequate summary of the
>>>> state of affairs?
>>>>
>>>
>>> Yes, I'd just caution not to over-index on the past backlog and first
>>> spend some quality time on unpacking lessons learned from what is already
>>> out there, and have a think on whether there is a simpler implementation
>>> that can satisfy the key needs whilst exposing less entropy.
>>>
>>
>> I agree. @Addy Osmani <addyo@google.com>, are you in a position to
>> provide some insights here? And @Yoav Weiss <yoavweiss@google.com>, you
>> the WG members would probably have opinions on this, too. Is it worth
>> opening an Issue to collect new use cases and another one to reflect on
>> existing use cases?
>>
>> Cheers,
>> Tom
>>
>>
>> ----------
>> From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
>> Date: Mon, Oct 26, 2020 at 11:04 AM
>> To: Thomas Steiner <tomac@google.com>
>> Cc: Ilya Grigorik <igrigorik@google.com>, Yoav Weiss <
>> yoavweiss@google.com>, Addy Osmani <addyo@google.com>, TOREINI, EHSAN <
>> ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>, Yoav
>> Weiss <yoav@yoav.ws>, Tarun Bansal <tbansal@google.com>, W3C Devices and
>> Sensors WG <public-device-apis@w3.org>
>>
>>
>> Hi All,
>>
>> I just opened two GH issues to discuss the DAS WG TPAC proceedings for
>> the Network Information API.
>>
>> Maybe we'll move this discussion to the spec GH repo to have more
>> eyeballs on the issues? See inline.
>>
>> On 26. Oct 2020, at 11.09, Thomas Steiner <tomac@google.com> wrote:
>>
>> On Fri, Oct 23, 2020 at 4:51 PM Ilya Grigorik <igrigorik@google.com>
>> wrote:
>>
>>> Hey all.
>>>
>>> On Fri, Oct 23, 2020 at 5:12 AM Thomas Steiner <tomac@google.com> wrote:
>>>
>>>> Thanks, all, for the responses so far. The initial question for @Ilya
>>>> Grigorik <igrigorik@google.com> still stands (whether there's still
>>>> some active spec work happening).
>>>>
>>>
>>> +Yoav Weiss <yoavweiss@google.com> captured it well, there is desire
>>> but no active spec work to address some of the lessons learned. If someone
>>> is willing to drive that process, that'd be great.
>>>
>>
>> Thanks for the update, Ilya! I guess it's up to the two WGs' chairs then
>> to see if and how to collaborate on this spec then, right?
>>
>>
>> https://github.com/WICG/netinfo/issues/88
>>
>>  Also, thanks, Addy, for the household names, we definitely have some
>>> strong industry representatives in there and can thus say the use cases are
>>> indeed valid and on active use.
>>>
>>>>
>>>> For the use cases in fact, there's some great discussion happening
>>>> already in issue 85 <https://github.com/WICG/netinfo/issues/85>, with
>>>> the "metered" aspects being the topic of issue 84
>>>> <https://github.com/WICG/netinfo/issues/84>. So I guess we're in a
>>>> theoretically good position to continue this discussion and just need to
>>>> agree on a practical way as to the how. Is this an adequate summary of the
>>>> state of affairs?
>>>>
>>>
>>> Yes, I'd just caution not to over-index on the past backlog and first
>>> spend some quality time on unpacking lessons learned from what is already
>>> out there, and have a think on whether there is a simpler implementation
>>> that can satisfy the key needs whilst exposing less entropy.
>>>
>>
>> I agree. @Addy Osmani <addyo@google.com>, are you in a position to
>> provide some insights here? And @Yoav Weiss <yoavweiss@google.com>, you
>> the WG members would probably have opinions on this, too. Is it worth
>> opening an Issue to collect new use cases and another one to reflect on
>> existing use cases?
>>
>>
>> https://github.com/WICG/netinfo/issues/87
>>
>> Thanks,
>>
>> -Anssi (DAS WG co-chair)
>>
>>
>>
>> ----------
>> From: Thomas Steiner <tomac@google.com>
>> Date: Fri, Aug 13, 2021 at 1:16 PM
>> To: Kostiainen, Anssi <anssi.kostiainen@intel.com>
>> Cc: Thomas Steiner <tomac@google.com>, Ilya Grigorik <
>> igrigorik@google.com>, Yoav Weiss <yoavweiss@google.com>, Addy Osmani <
>> addyo@google.com>, TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Noam
>> Helfman <noamh@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Tarun Bansal <
>> tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>
>>
>>
>> Hi all,
>>
>> I have rebooted the Network Information API based on long-going
>> discussions with @Yoav Weiss <yoavweiss@google.com> (who currently is
>> still OoO):
>>
>>    - Motivational doc:
>>    https://docs.google.com/document/d/1RDA23zSNdDuIcxZTX9Xo3zlD2fxf8dZg9-e0YaJQv0g/edit?usp=sharing
>>    - Explainer:
>>    https://github.com/tomayac/netinfo/blob/relaunch/README.md
>>    - Spec draft:
>>    https://ghcdn.rawgit.org/tomayac/netinfo/relaunch/index.html
>>
>> This is all in a relatively early stage, but I thought now would be a
>> good time to get early feedback.
>>
>> Cheers,
>> Tom
>>
>>
>> ----------
>> From: Mail Delivery Subsystem <mailer-daemon@googlemail.com>
>> Date: Fri, Aug 13, 2021 at 1:16 PM
>> To: <tsteiner@google.com>
>>
>>
>> [image: Error Icon]
>> Address not found
>> Your message wasn't delivered to *igrigorik@google.com* because the
>> address couldn't be found, or is unable to receive mail.
>> LEARN MORE <https://support.google.com/mail/answer/6596>
>> The response was:
>>
>> The email account that you tried to reach does not exist. Please try
>> double-checking the recipient's email address for typos or unnecessary
>> spaces. Learn more at https://support.google.com/mail/answer/6596
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Thomas Steiner <tomac@google.com>
>> To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
>> Cc: Thomas Steiner <tomac@google.com>, Ilya Grigorik <
>> igrigorik@google.com>, Yoav Weiss <yoavweiss@google.com>, Addy Osmani <
>> addyo@google.com>, "TOREINI, EHSAN" <ehsan.toreini@durham.ac.uk>, Noam
>> Helfman <noamh@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Tarun Bansal <
>> tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>
>> Bcc:
>> Date: Fri, 13 Aug 2021 13:16:27 +0200
>> Subject: Re: Network Information API
>> ----- Message truncated -----
>>
>> ----------
>> From: Thomas Steiner <tomac@google.com>
>> Date: Fri, Aug 13, 2021 at 1:19 PM
>> To: Thomas Steiner <tomac@google.com>
>> Cc: Kostiainen, Anssi <anssi.kostiainen@intel.com>, Thomas Steiner <
>> tomac@google.com>, Yoav Weiss <yoavweiss@google.com>, Addy Osmani <
>> addyo@google.com>, TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Noam
>> Helfman <noamh@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Tarun Bansal <
>> tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>, <ilya@igvita.com>
>>
>>
>> [Removed Ilya's Google mail and used the address from his homepage.]
>>
>>
>> ----------
>> From: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
>> Date: Fri, Aug 13, 2021 at 2:09 PM
>> To: Thomas Steiner <tomac@google.com>, Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>
>> Cc: Ilya Grigorik <igrigorik@google.com>, Yoav Weiss <
>> yoavweiss@google.com>, Addy Osmani <addyo@google.com>, TOREINI, EHSAN <
>> ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>, Yoav
>> Weiss <yoav@yoav.ws>, Tarun Bansal <tbansal@google.com>, W3C Devices and
>> Sensors WG <public-device-apis@w3.org>, Alex Russell <
>> slightlyoff@chromium.org>
>>
>>
>> Very interesting Thomas!
>>
>> Great that you are picking this up.
>>
>> In the future we might want the ability to also give hints to the network
>> connection, for instance Wi-Fi 7 will have Multi Link Operations where the
>> applications can configure how they want to receive data per link at any
>> time, like duplicate data for lower latency and more reliable connection
>> (e.g. for game streaming and video calls) or data stream separate on
>> multiple links to receive faster download speed. It is still around 3 years
>> off, but it is something we should consider for the future (also future
>> re-charters).
>>
>> Cheers
>> Kenneth
>> ------------------------------
>> *From:* Thomas Steiner <tomac@google.com>
>> *Sent:* Friday, August 13, 2021 1:16 PM
>> *To:* Kostiainen, Anssi <anssi.kostiainen@intel.com>
>> *Cc:* Thomas Steiner <tomac@google.com>; Ilya Grigorik <
>> igrigorik@google.com>; Yoav Weiss <yoavweiss@google.com>; Addy Osmani <
>> addyo@google.com>; TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>; Noam
>> Helfman <noamh@microsoft.com>; Yoav Weiss <yoav@yoav.ws>; Tarun Bansal <
>> tbansal@google.com>; W3C Devices and Sensors WG <
>> public-device-apis@w3.org>
>> *Subject:* Re: Network Information API
>>
>>
>>
>> ----------
>> From: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
>> Date: Fri, Aug 13, 2021 at 2:11 PM
>> To: Thomas Steiner <tomac@google.com>, Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>
>> Cc: Yoav Weiss <yoavweiss@google.com>, Addy Osmani <addyo@google.com>,
>> TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <
>> noamh@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Tarun Bansal <
>> tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>, Alex Russell <slightlyoff@chromium.org>,
>> ilya@igvita.com <ilya@igvita.com>
>>
>>
>> (update Ilya's email address)
>> ------------------------------
>> *From:* Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
>> *Sent:* Friday, August 13, 2021 2:09 PM
>> *To:* Thomas Steiner <tomac@google.com>; Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>
>> *Cc:* Ilya Grigorik <igrigorik@google.com>; Yoav Weiss <
>> yoavweiss@google.com>; Addy Osmani <addyo@google.com>; TOREINI, EHSAN <
>> ehsan.toreini@durham.ac.uk>; Noam Helfman <noamh@microsoft.com>; Yoav
>> Weiss <yoav@yoav.ws>; Tarun Bansal <tbansal@google.com>; W3C Devices and
>> Sensors WG <public-device-apis@w3.org>; Alex Russell <
>> slightlyoff@chromium.org>
>>
>>
>>
>> ----------
>> From: Marcos Caceres <marcosc@w3.org>
>> Date: Mon, Aug 16, 2021 at 2:50 AM
>> To: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>, Thomas
>> Steiner <tomac@google.com>, Kostiainen, Anssi <anssi.kostiainen@intel.com>,
>> Yoav Weiss <yoavweiss@google.com>, Addy Osmani <addyo@google.com>,
>> TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <
>> noamh@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Tarun Bansal <
>> tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>, Alex Russell <slightlyoff@chromium.org>,
>> ilya@igvita.com <ilya@igvita.com>
>>
>>
>> Hi Thomas,
>>
>> Thanks for attempting to pick this up again. My opinion/advice as someone
>> involved with this API from the beginning...
>>
>> The `sustainedSpeed` and `Sec-CH-Sustained-Speed` needs to go, IMO. If we
>> can just get implementers to even agree on `metered`, that will be a
>> significant achievement for interop.
>>
>> Also, consider the use cases (which are mostly misaligned with the
>> original use cases for this API [1]):
>>
>>         • Instead of Retina resolution images use "regular" resolution
>> images.
>>         • Reduce the quality of lossy compressed images.
>>         • Disable autoplay for foreground videos.
>>         • Replace background videos with poster images.
>>         • Request fewer or more results from a search API.
>>
>> The image ones should be handled by <picture> and <img> etc. IMO, we
>> should refocus our energy there, not here.
>>
>> Similarly, the video ones are better handled by adaptive video codecs (or
>> the UA itself, in case where videos shouldn't auto play).
>>
>> Aim small, and build up from there.
>>
>> [1] https://www.w3.org/TR/netinfo-usecases/
>>
>>
>> > On 13 Aug 2021, at 10:10 pm, Christiansen, Kenneth R <
>> kenneth.r.christiansen@intel.com> wrote:
>> >
>> > (update Ilya's email address)
>> > From: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>
>> > Sent: Friday, August 13, 2021 2:09 PM
>> > To: Thomas Steiner <tomac@google.com>; Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>
>> > Cc: Ilya Grigorik <igrigorik@google.com>; Yoav Weiss <
>> yoavweiss@google.com>; Addy Osmani <addyo@google.com>; TOREINI, EHSAN <
>> ehsan.toreini@durham.ac.uk>; Noam Helfman <noamh@microsoft.com>; Yoav
>> Weiss <yoav@yoav.ws>; Tarun Bansal <tbansal@google.com>; W3C Devices and
>> Sensors WG <public-device-apis@w3.org>; Alex Russell <
>> slightlyoff@chromium.org>
>> > Subject: Re: Network Information API
>> >
>> > Very interesting Thomas!
>> >
>> > Great that you are picking this up.
>> >
>> > In the future we might want the ability to also give hints to the
>> network connection, for instance Wi-Fi 7 will have Multi Link Operations
>> where the applications can configure how they want to receive data per link
>> at any time, like duplicate data for lower latency and more reliable
>> connection (e.g. for game streaming and video calls) or data stream
>> separate on multiple links to receive faster download speed. It is still
>> around 3 years off, but it is something we should consider for the future
>> (also future re-charters).
>> >
>> > Cheers
>> > Kenneth
>>
>>
>> ----------
>> From: Thomas Steiner <tomac@google.com>
>> Date: Mon, Aug 16, 2021 at 2:26 PM
>> To: Marcos Caceres <marcosc@w3.org>
>> Cc: Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>, Thomas
>> Steiner <tomac@google.com>, Kostiainen, Anssi <anssi.kostiainen@intel.com>,
>> Yoav Weiss <yoavweiss@google.com>, Addy Osmani <addyo@google.com>,
>> TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <
>> noamh@microsoft.com>, Yoav Weiss <yoav@yoav.ws>, Tarun Bansal <
>> tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>, Alex Russell <slightlyoff@chromium.org>,
>> ilya@igvita.com <ilya@igvita.com>, Pete LePage <petele@google.com>
>>
>>
>> On Mon, Aug 16, 2021 at 2:50 AM Marcos Caceres <marcosc@w3.org> wrote:
>>
>>> Thanks for attempting to pick this up again. My opinion/advice as
>>> someone involved with this API from the beginning...
>>
>>
>> Thanks a lot, greatly appreciated!
>>
>>
>>> The `sustainedSpeed` and `Sec-CH-Sustained-Speed` needs to go, IMO. If
>>> we can just get implementers to even agree on `metered`, that will be a
>>> significant achievement for interop.
>>
>>
>> One idea could be to let UAs report `Infinity` as a valid value for
>> `sustainedSpeed` if they don't want to report one of the more accurate
>> speed buckets.
>>
>>
>>> Also, consider the use cases (which are mostly misaligned with the
>>> original use cases for this API [1]):
>>>
>>>         • Instead of Retina resolution images use "regular" resolution
>>> images.
>>>         • Reduce the quality of lossy compressed images.
>>>         • Disable autoplay for foreground videos.
>>>         • Replace background videos with poster images.
>>>         • Request fewer or more results from a search API.
>>>
>>> The image ones should be handled by <picture> and <img> etc. IMO, we
>>> should refocus our energy there, not here.
>>>
>>
>> As pointed out in the "Distinction from the save data use case" (
>> https://github.com/tomayac/netinfo/tree/relaunch#distinction-from-the-save-data-use-case),
>> these adaptive loading patterns are exactly that: adaptive. How would you
>> want to describe this (this being, for example: In general I have a Retina
>> device, but if the network doesn't permit Retina graphics right _now_, just
>> give me low-res images) in `<picture>` or `<img>`? @Addy Osmani
>> <addyo@google.com> has collected a lot of such adaptive loading patterns
>> in https://adaptive-loading.web.app/.
>>
>>
>>> Similarly, the video ones are better handled by adaptive video codecs
>>> (or the UA itself, in case where videos shouldn't auto play).
>>
>>
>> Yes, this is definitely not about adaptive streaming. It's more about
>> adaptive _loading_, for example, swapping a video for an image. For the
>> auto play case, UAs already have policies regarding this (
>> https://developer.mozilla.org/en-US/docs/Web/Media/Autoplay_guide#:~:text=For%20details%2C%20see,.)
>> that would not be affected by the proposal. For example, Chrome always
>> allows muted autoplay (
>> https://developer.chrome.com/blog/autoplay/#:~:text=Muted%20autoplay%20is%20always%20allowed.),
>> but in the case of bad network connectivity, rather than desperately force
>> the browser to fulfill the auto play desire the developer may have in the
>> general case, the developer could tell the UA to only even try this if the
>> network is good enough.
>>
>>
>>> Aim small, and build up from there.
>>
>>
>> Definitely :-)
>>
>> Cheers,
>> Tom
>>
>>
>> ----------
>> From: Marcos Caceres <marcosc@w3.org>
>> Date: Thu, Aug 19, 2021 at 7:59 AM
>> To: Thomas Steiner <tomac@google.com>, Christiansen, Kenneth R <
>> kenneth.r.christiansen@intel.com>, Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>, Yoav Weiss <yoavweiss@google.com>, Addy
>> Osmani <addyo@google.com>, TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>,
>> Noam Helfman <noamh@microsoft.com>, Tarun Bansal <tbansal@google.com>,
>> W3C Devices and Sensors WG <public-device-apis@w3.org>, Alex Russell <
>> slightlyoff@chromium.org>, ilya@igvita.com <ilya@igvita.com>, Pete
>> LePage <petele@google.com>
>>
>>
>>
>>
>> > On 16 Aug 2021, at 10:26 pm, Thomas Steiner <tomac@google.com> wrote:
>> >
>> > On Mon, Aug 16, 2021 at 2:50 AM Marcos Caceres <marcosc@w3.org> wrote:
>> > Thanks for attempting to pick this up again. My opinion/advice as
>> someone involved with this API from the beginning...
>> >
>> > Thanks a lot, greatly appreciated!
>>
>> To be frank (and this is not in any way directed at you, Thomas!): After
>> 7+ years, I think the API is now too poisoned by bad history to revive. I'd
>> urge us to just cut our losses and see if we can just do something
>> new/entirely different or come at this from a different angle.
>>
>> Instead of focusing on the API at all, if we can get other implementers -
>> which are noticeably absent from the cc: and possibly the working group (!)
>> - to agree on a tiny set of use cases, I think that would be a better
>> (re)start to this effort.
>>
>> Otherwise, I worry that we are going to just fall into the "well, we all
>> think it's a good idea" Chromium-echo-chamber, while just further
>> frustrating and polarizing WebKit and Gecko folks with respect to the
>> netinfo use cases. I know that's not on purpose, but that's kinda where we
>> are (specially with anything "net info").
>>
>> Kind regards,
>> Marcos
>>
>>
>>
>> ----------
>> From: Noam Helfman <noamh@microsoft.com>
>> Date: Thu, Aug 19, 2021 at 1:30 PM
>> To: Marcos Caceres <marcosc@w3.org>, Thomas Steiner <tomac@google.com>,
>> Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>, Kostiainen,
>> Anssi <anssi.kostiainen@intel.com>, Yoav Weiss <yoavweiss@google.com>,
>> Addy Osmani <addyo@google.com>, TOREINI, EHSAN <
>> ehsan.toreini@durham.ac.uk>, Tarun Bansal <tbansal@google.com>, W3C
>> Devices and Sensors WG <public-device-apis@w3.org>, Alex Russell <
>> slightlyoff@chromium.org>, ilya@igvita.com <ilya@igvita.com>, Pete
>> LePage <petele@google.com>
>>
>>
>> Another important use case we should consider if reviving API this is
>> ability to detect network unavailability causes based on topology. E.g.: is
>> only the local WiFi network is slow/down or the whole route to the ISP or
>> route to the target app?
>>
>> We had a short discussion about this last TPAC and main feedback was
>> about privacy concerns. I would imagine some non privacy violating
>> definition could be devised if there is enough consensus about the
>> importance of such use case.
>> ------------------------------
>> *From:* Marcos Caceres <marcosc@w3.org>
>> *Sent:* Thursday, August 19, 2021 8:59 AM
>> *To:* Thomas Steiner <tomac@google.com>; Christiansen, Kenneth R <
>> kenneth.r.christiansen@intel.com>; Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>; Yoav Weiss <yoavweiss@google.com>; Addy
>> Osmani <addyo@google.com>; TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>;
>> Noam Helfman <noamh@microsoft.com>; Tarun Bansal <tbansal@google.com>;
>> W3C Devices and Sensors WG <public-device-apis@w3.org>; Alex Russell <
>> slightlyoff@chromium.org>; ilya@igvita.com <ilya@igvita.com>; Pete
>> LePage <petele@google.com>
>> *Subject:* [EXTERNAL] Re: Network Information API
>>
>>
>>
>>
>> ----------
>> From: Yoav Weiss <yoavweiss@google.com>
>> Date: Thu, Aug 19, 2021 at 4:12 PM
>> To: Marcos Caceres <marcosc@w3.org>
>> Cc: Thomas Steiner <tomac@google.com>, Christiansen, Kenneth R <
>> kenneth.r.christiansen@intel.com>, Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>, Addy Osmani <addyo@google.com>, TOREINI,
>> EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>,
>> Tarun Bansal <tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>, Alex Russell <slightlyoff@chromium.org>,
>> ilya@igvita.com <ilya@igvita.com>, Pete LePage <petele@google.com>
>>
>>
>> I'll be frank as well then :)
>>
>>
>> On Thu, Aug 19, 2021 at 7:59 AM Marcos Caceres <marcosc@w3.org> wrote:
>>
>>>
>>>
>>> > On 16 Aug 2021, at 10:26 pm, Thomas Steiner <tomac@google.com> wrote:
>>> >
>>> > On Mon, Aug 16, 2021 at 2:50 AM Marcos Caceres <marcosc@w3.org> wrote:
>>> > Thanks for attempting to pick this up again. My opinion/advice as
>>> someone involved with this API from the beginning...
>>> >
>>> > Thanks a lot, greatly appreciated!
>>>
>>> To be frank (and this is not in any way directed at you, Thomas!): After
>>> 7+ years, I think the API is now too poisoned by bad history to revive.
>>
>>
>> The API is alive and kicking, and it's being used
>> <https://www.algolia.com/blog/engineering/netinfo-api-algolia-javascript-client>
>>  by enthusiastic <https://twitter.com/Dieulot/status/1427699698996031490> developers
>> to provide better
>> <https://github.com/WICG/netinfo/issues/85#issuecomment-615161295>
>> experiences
>> <https://github.com/WICG/netinfo/issues/85#issuecomment-615346371> to
>> users <https://github.com/WICG/netinfo/issues/85#issuecomment-621454042>
>> .
>> From my perspective, there are a few issues this reboot can solve:
>> 1) The API is currently exposing too much information and could
>> potentially cover the same use cases while exposing less entropy
>> 2) The API is currently not as useful as it can be, and can cover the use
>> cases more accurately
>> 3) The API is currently Chromium-only. That is mostly due to criticism
>> related to (1), as well as lack of interest in the legitimate use cases
>> that it solves. Fixing (1) could solve the former part.
>>
>>
>> I'd urge us to just cut our losses and see if we can just do something
>>> new/entirely different or come at this from a different angle.
>>
>>
>> Again - this is being used in the wild today to create better experiences
>> for bandwidth-constrained users, as well as better analytics. "Cutting our
>> losses" would mean to regress the web experience for users under harsh
>> network-conditions and remove those developers' ability to optimize their
>> sites for these scenarios.
>>
>>
>> ----------
>> From: Marcos Caceres <marcosc@w3.org>
>> Date: Fri, Aug 20, 2021 at 8:56 AM
>> To: Yoav Weiss <yoavweiss@google.com>
>> Cc: Thomas Steiner <tomac@google.com>, Christiansen, Kenneth R <
>> kenneth.r.christiansen@intel.com>, Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>, Addy Osmani <addyo@google.com>, TOREINI,
>> EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>,
>> Tarun Bansal <tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>, Alex Russell <slightlyoff@chromium.org>,
>> ilya@igvita.com <ilya@igvita.com>, Pete LePage <petele@google.com>
>>
>>
>>
>>
>> > On 20 Aug 2021, at 12:11 am, Yoav Weiss <yoavweiss@google.com> wrote:
>>
>> > Again - this is being used in the wild today to create better
>> experiences for bandwidth-constrained users, as well as better analytics.
>>
>> The utility of the solution is not in dispute. We know that anything we
>> put out in the wild will be used by someone to do something useful - that's
>> why we specified NetInfo in the first place and put it out there. But that
>> doesn't change the fact that the API might be bad for *reasons* (e.g.,
>> privacy).
>>
>> > "Cutting our losses" would mean to regress the web experience for users
>> under harsh network-conditions and remove those developers' ability to
>> optimize their sites for these scenarios.
>>
>> That's absolutely not the case at all: no one said that Chromium should
>> remove the API.
>>
>> We can just acknowledge that it's a Chrome(mium) API. That's totally
>> ok... standardizing something new (supported by all the browser vendors)
>> that developers can transition to should be the goal. That way, we don't
>> break existing content, and we get a path forward.
>>
>> Put differently: just because we have a Chromium-only API shipping right
>> now doesn't mean we can't come up with something different that other
>> browser vendors can adopt. One doesn't negate the other.
>>
>>
>>
>> ----------
>> From: Yoav Weiss <yoavweiss@google.com>
>> Date: Fri, Aug 20, 2021 at 9:31 AM
>> To: Marcos Caceres <marcosc@w3.org>
>> Cc: Thomas Steiner <tomac@google.com>, Christiansen, Kenneth R <
>> kenneth.r.christiansen@intel.com>, Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>, Addy Osmani <addyo@google.com>, TOREINI,
>> EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>,
>> Tarun Bansal <tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>, Alex Russell <slightlyoff@chromium.org>,
>> ilya@igvita.com <ilya@igvita.com>, Pete LePage <petele@google.com>
>>
>>
>>
>>
>> OK, that sounds perfectly reasonable. It also feels extremely similar to
>> what Thomas is proposing % the spec & interface name. Would renaming those
>> help from your perspective?
>>
>>
>> ----------
>> From: Marcos Caceres <marcosc@w3.org>
>> Date: Fri, Aug 20, 2021 at 10:12 AM
>> To: Yoav Weiss <yoavweiss@google.com>
>> Cc: Thomas Steiner <tomac@google.com>, Christiansen, Kenneth R <
>> kenneth.r.christiansen@intel.com>, Kostiainen, Anssi <
>> anssi.kostiainen@intel.com>, Addy Osmani <addyo@google.com>, TOREINI,
>> EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <noamh@microsoft.com>,
>> Tarun Bansal <tbansal@google.com>, W3C Devices and Sensors WG <
>> public-device-apis@w3.org>, Alex Russell <slightlyoff@chromium.org>,
>> ilya@igvita.com <ilya@igvita.com>, Pete LePage <petele@google.com>
>>
>>
>>
>>
>> > On 20 Aug 2021, at 5:31 pm, Yoav Weiss <yoavweiss@google.com> wrote:
>> >
>> > OK, that sounds perfectly reasonable. It also feels extremely similar
>> to what Thomas is proposing % the spec & interface name. Would renaming
>> those help from your perspective?
>>
>> It's not a matter of renaming, it's a matter of nailing down the limited
>> set of use cases. What I'd really like to see is Gecko and WebKit folks,
>> together with the dev community/sites that need this, be like: "yep, X, Y,
>> and maybe Z would be great things to figure out together."
>>
>> Personally, what I'd like to see is ~3-5 different ways of attempting to
>> solve those cases (e.g., here is solution X with an API, here is one with
>> declarative <whatever> element or attribute, and so on...). That way, we
>> don't become overly attached to a single solution.
>>
>> If folks can spare a few minutes, Ilya has a great post + talk
>> "retrospective at performance.now()", which I think is super relevant here
>> (~20min mark) - around considering approaching these kinds of problems from
>> different perspectives:
>>
>>
>> https://discourse.wicg.io/t/proposal-native-media-optimization-and-basic-editing-support/4068/12
>>
>>
>>
>>
>> ----------
>> From: Thomas Steiner <tomac@google.com>
>> Date: Fri, Aug 20, 2021 at 2:12 PM
>> To: Marcos Caceres <marcosc@w3.org>, Mounir Lamouri <mlamouri@google.com>
>> Cc: Yoav Weiss <yoavweiss@google.com>, Thomas Steiner <tomac@google.com>,
>> Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>, Kostiainen,
>> Anssi <anssi.kostiainen@intel.com>, Addy Osmani <addyo@google.com>,
>> TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <
>> noamh@microsoft.com>, Tarun Bansal <tbansal@google.com>, W3C Devices and
>> Sensors WG <public-device-apis@w3.org>, Alex Russell <
>> slightlyoff@chromium.org>, ilya@igvita.com <ilya@igvita.com>, Pete
>> LePage <petele@google.com>
>>
>>
>> [Adding Mounir, full context:
>> https://lists.w3.org/Archives/Public/public-device-apis/2021Aug/0003.html
>> ]
>>
>> Thanks, Marcos, I will reach out to WebKit and Mozilla now that the spec,
>> explainer, and motivation document start to be in an OK enough shape.
>>
>> Fun fact: I just found
>> https://www.w3.org/TR/2012/WD-netinfo-api-20121129/#the-connection-interface,
>> which looks kind of familiar and which, I swear, I wasn't aware of before
>> coming up with my proposal. Things have changed significantly in between
>> 2012 and 2021, so the shortcomings that @Mounir Lamouri
>> <mlamouri@google.com>'s spec brought up no longer hold true.
>>
>>
>> ----------
>> From: Thomas Steiner <tomac@google.com>
>> Date: Fri, Aug 20, 2021 at 4:59 PM
>> To: Thomas Steiner <tomac@google.com>
>> Cc: Marcos Caceres <marcosc@w3.org>, Mounir Lamouri <mlamouri@google.com>,
>> Yoav Weiss <yoavweiss@google.com>, Thomas Steiner <tomac@google.com>,
>> Christiansen, Kenneth R <kenneth.r.christiansen@intel.com>, Kostiainen,
>> Anssi <anssi.kostiainen@intel.com>, Addy Osmani <addyo@google.com>,
>> TOREINI, EHSAN <ehsan.toreini@durham.ac.uk>, Noam Helfman <
>> noamh@microsoft.com>, Tarun Bansal <tbansal@google.com>, W3C Devices and
>> Sensors WG <public-device-apis@w3.org>, Alex Russell <
>> slightlyoff@chromium.org>, ilya@igvita.com <ilya@igvita.com>, Pete
>> LePage <petele@google.com>
>>
>>
>> FYI, I just asked for early feedback from the following vendors:
>>
>> - Mozilla: https://github.com/mozilla/standards-positions/issues/569
>> - Apple:
>> https://lists.webkit.org/pipermail/webkit-dev/2021-August/031950.html
>> - Brave:
>> https://github.com/brave/brave-browser/issues/4598#issuecomment-902743761
>>
>> Cheers,
>> Tom
>>
>>
>>