Splitting up Save-Data from NetInfo

#1

<chair hat off>

Hey all!

I’ve heard some desire to change the fact that currently the Save-Data client hints are defined as part of the Network Information API. Save-Data is different than the other set of APIs defined there, as it represents the user’s preference rather than the network conditions.

Any objections? Support? General thoughts?

0 Likes

#2

I support splitting out Save-Data as a separate header. It’s a request on a specific connection from the user system, more than exposing a property of the client’s network. I’d like to see clients that don’t want to support sending hints about their network be able to still request save-data resources.

0 Likes

#3

I think it makes sense to define it separately. The purpose is different enough. That said, I do appreciate the convenience of querying it as part of the Network Information API, so I would not want to lose that feature.

0 Likes

#4

For applications (like streaming video players) that make decisions about what to fetch from a field of alternatives, it is critical to be able to query that feature in JS, so that we can make decisions which respect it.

That said, it doesn’t need to be on the NetInfo API necessarily. But it should not be just a header. A JS API is important.

0 Likes

#5

(not an indicator of support from Mozilla)

It would be good to split things out. There is still a lot of privacy concerns around NetInfo, so having this split out might be good (though it’s still a tracking data point, in that it reflects a user preference).

0 Likes