Hacker News Reader

Comment by Lorin | Hacker News Reader

I have no idea why browsers moved away from providing the DPR (device pixel ratio) header on media requests so one could continue using the sensible and simple <img> whilst the server could return the correct images on its own.

Would love to know the rationale.

View on HN

Doesn't work for static sites. At one point it seemed like home computers would be going away and everyone would just use small, thin clients with most of the "work" done on servers. I'm glad this hasn't happened. I prefer the idea of a static site where the user's browser makes all the decisions.

I haven’t followed Client Hints closely, but a change[1] in RFC 9842 internal drafts “removed specific features to be defined in other specifications”, and the `DPR` header ended up as `Sec-CH-DPR` in the nascent Responsive Images Client Hints spec[2].

[1] https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cli... [2] https://wicg.github.io/responsive-image-client-hints/#sec-ch...

I'm not sure, but my understanding was that this is to reduce browser fingerprinting.

This doesn’t make sense to me. You can perform the exact same fingerprinting by looking at which image in a srcset is being requested.

The server doesn't know what size the image will be displayed, but the browser does.

Isnt it same reason why using srcset device ratio is not recommended and you should use widths. Sending DPR in header is kinda useless and maybe hurts privacy/fingerprinting?

Reply on news.ycombinator.com