Re: Network Information API

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
> 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
>
>
>