Intent to Implement: Providing effective network speed to web servers

[Tarun]

Contact emails

tba...@chromium.org, be...@chromium.org, igri...@chromium.org

Spec

Explainer: https://github.com/WICG/netinfo/issues/46#issuecomment-276804272

WICG thread: https://discourse.wicg.io/t/proposal-netinfo-provide-effective-network-speed-expose-save-data/1980

The API was discussed with web developers and CDN providers at BlinkOn7, and the response was positive.

Summary:

This is a proposal for two new HTTP request headers and an extension to the Network Information API to convey the HTTP client's network connection speed. The headers will be sent together, and will be sent only to hosts that opt in to receiving them. The Network Information API extensions will surface the same data make it easy to make speed-related decisions from within JavaScript.

Motivation:

See explainer for detailed motivation.

Web servers and proxies benefit, because they can tailor content to network constraints. For example, on very slow networks, a simplified version of the page can be provided to improve document load and first paint times. Users benefit by being offered only that content that they can consume given network constraints, which results in faster paints, and less frustration.

Interoperability and Compatibility Risk:

Low. Opt-in header and extension to NetInfo API.

Ongoing technical constraints:

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Requesting Approval to Ship?

No.

OWP launch tracking bug:
No launch bug because not requesting approval to ship yet.

[Yoav Weiss]

Yay! Super excited about this and the use-cases this will enable.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Chris Bentzel]

+1

[Jochen Eisinger]

What granularity of data will we expose to the web servers? I see that the spec already mentions in its privacy considerations section that there's a risk of finger printing and tracking the physical location of the client. I wonder whether there's a possible compromise in providing only coarse grained data that would still allow for websites to achieve their goals?

Will those headers be sent over https only?

[tba...@google.com]

Both the RTT and bandwidth data would both be rounded up to the nearest 25 ms. The headers will be sent over both http and https.

[Jochen Eisinger]

Any particular reason why we would want to send this information over an unprotected link?

[tba...@google.com]

After some discussion, it has been decided that the network quality headers will be sent only on HTTPS connections. Thanks!