Should browsers signal data budget via request header?

Websites want to serve rich multimedia experiences. For an example, see the promotional site for the new Majora’s Mask 3D game. That site in particular isn’t sufficiently optimized (the images aren’t optimized and lazy-loaded - applying these techniques would reduce the page weight significantly), but still, a fair amount of images are needed to create the experience and on mobile devices high-resolution versions are needed, so the page weight can only be optimized so much.

Mobile networks usually have data caps, so a user may want to ensure that data is used conservatively when viewing websites. Ideally, a website should be able to serve a low-KB version on user request. Opera and Chrome have innovated in this area by providing a setting to dynamically compress page resources (using their own proxy servers), but maybe this feature would be useful in the web platform itself… somehow. At least, there could be a standard HTTP request header for signaling that a low-KB version of the web page should be served if available. This header could be activated via browser setting (just like DNT).

tl;dr Sometimes websites want to serve rich multimedia experiences that require lots of KB. Some users want to conserve KB. Do we need a standard for signaling to websites to serve a low-KB version on request?

I think the hard part here is determining how the user would be given the option to say it; is it a browser-wide preference, something they select site-by-site, etc.?

There has also been discussion of letting the network itself tell the site when it is congested, when the user is paying, etc.

@mnot maybe share a link or two to some relevant discussions/summaries of output from those? might save rehashing. I think it’s interesting, but hard because there are so many potential variables - Still, something might be better than nothing… I’d like to see what others have already said and avoid making the same points.

Hey - we (W3C Webmob and some google/moz/telefonica people!) are working on the idea that a mobile operator (/ carrier) can provide this information back to the mobile OS, which could then, one assumes, be fed into the browser. There are some huge legal issues that come with this though, and given how different operators core networks are this does come with some issues envisioning how it could happen. In any case we’re going to make a proof of concept with a few operators and go from there.

So - question for you guys, does the API we are working on suit your uses cases? Check it out here: https://github.com/Data-Info-API/Architecture/blob/master/API.md

Also @simevidas, good choice of website! (As in, great game, but sad it’s not optimised!)

Most of those have been f2f / hallway discussions. I put up a very straw thing at: https://tools.ietf.org/html/draft-nottingham-gin-00

Hey Natasha - interesting stuff. Is the idea that this information will be made available through Web platform APIs? I.e., so that my Web page can query how much data you have left? (hmm)

There have been talks of something similar as part of the Client-Hints spec. I’m guessing that a “give me smaller resources when possible” hint sent to the server has less privacy issues than “I have X$ left on my budget, and I’m roaming so data costs me Y$ per MB”, so we should shoot for the former rather than the latter.

Natacha - Such an OS level API would be very exciting since the browser could then make better decisions when given multiple resource options (srcset and image-set are the first examples that come to mind). I agree with @mnot that it’s not something we’d want to provide an explicit API for (at least not without the user’s permission), but maybe we can try to expose it as a “small resource preference” combined out of network cost info, user preference, etc.

At the moment the idea would be just to send this back to the OS. We can see the draw of sharing this with webapp developers of course (simple use cases like being able to select a streaming rate or image quality based on the user’s available allowance left) but we have two major issues: [1] privacy and [2] laws protecting privacy! We’re currently looking at how / if this can be done in a way which still ensures privacy for the user. Off the top of my head we could make sure:

[1] user’s info is only returned to the user [2] some permissions flow would need to be added to make sure the user has allowed for an app to see this information [3] make some guidelines as to whether we should allow this data to be stored by the app, and then, maybe add some functionality to ensure this (not sure if this is possible…).

If people have any other thoughts on this feel free to drop them here. Also, I wonder if some sort of open id connect / oauth flow could make this happen in a safer way, but I haven’t put much thought into this aside from dropping these words onto this page!