Re: Network Information API

+David Schinazi <dschinazi@google.com> (Full thread pasted below.)


Hi Ilya and Addy,
(the working group FYI)

In the Devices and Sensors Working Group meeting today at TPAC we were
discussing <https://www.w3.org/2020/10/22-dap-minutes.html> the Network
Information API.

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.

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