Re: Adding support for HDR headroom in ScreenDetailed

I don't think limiting fingerprinting entropy requires requires making this
this requestable: `ScreenDetailed.hdrHeadroom` is an `attribute` (a getter)
so the value isn't exposed to the page unless the page actually
accesses `screenDetailed.hdrHeadroom`. Entropy actually *needs* to be
measured at the point it's accessed since its value can change over
time  (it can't be measured in `getScreenDetails()`).
(A while back WebGPU went through a long process trying to figure out
whether we needed to add complexity to the API - in a way that would have
been alien in older APIs - just to avoid pages having to request more info
than they wanted. Eventually we figured out that the getters could do this
for us.)

That doesn't negate the second point though: Any info that you might need
to show the permission prompt *does* need to be passed to
`getScreenDetails()` since that's what shows the prompt. I don't have input
on whether you need this for the prompt.

-Kai (he/they)


On Fri, Nov 21, 2025 at 5:08 PM Mike Wasserman <msw@google.com> wrote:

> The Second Screen group unfortunately didn't meet during TPAC, so there
> was not F2F discussion here.
>
> I took another look and think this looks good, but the accuracy of HDR
> headroom values and frequency of events warrant privacy consideration:
> Q: Does this increase *default* entropy enough that we should require
> clients to opt-in: e.g. `getScreenDetails({includeHDRHeadroom: true})`? I
> think so.
> While we could add options later, changing default behavior would be
> breaking. So, we should err towards "Limit the fingerprinting surface to
> only the entropy necessary" (Best Practice 5
> <https://www.w3.org/TR/fingerprinting-guidance/#limit-surface>) by
> defualt.
> This also lets implementers clearly scope any potential permission
> re-prompting or enterprise controls around actual expanded access, rather
> than across all access.
>
> I think the spec/implementation burden should be reasonable, and pave the
> way for related options e.g.
> `getScreenDetails({withoutWindowManagementAccess:true})`. What do folks
> think?
>
> On Fri, Nov 21, 2025 at 12:22 AM Christopher Cameron <ccameron@google.com>
> wrote:
>
>> Hello Second Screen group!
>>
>> Is there anything left to do before we merge the PR
>> <https://github.com/w3c/window-management/pull/150> for this issue
>> <https://github.com/w3c/window-management/issues/149>?
>>
>> Thank you!
>>
>>
>> On Tue, Aug 26, 2025 at 4:07 PM Kostiainen, Anssi <
>> anssi.kostiainen@intel.com> wrote:
>>
>>> Hi Christopher, All,
>>>
>>> Thank you for the HDR headroom proposal — it’s on the Second Screen WG’s
>>> WIP TPAC agenda:
>>>
>>> https://github.com/w3c/secondscreen-wg/issues/13
>>>
>>> WG participants - please review the proposal and provide feedback via GH
>>> prior. See the links provided by Christopher for the issue(s), PR and
>>> explainer.
>>>
>>> Color on the Web CG participants at TPAC are welcome to join us for this
>>> discussion.
>>>
>>> Thanks,
>>>
>>> -Anssi (Second Screen WG/CG co-chair)
>>>
>>>
>>> On 23. Jun 2025, at 20.33, Christopher Cameron <ccameron@google.com>
>>> wrote:
>>>
>>> Hello Second Screen WG (and ColorWeb-CG as FYI)!
>>>
>>> The HDR headroom of a screen is a core parameter for how HDR content is
>>> rendered (see this description in CSS HDR
>>> <https://drafts.csswg.org/css-color-hdr/#introducing-headroom>).
>>> Advanced applications may want to perform custom tone mapping using this
>>> parameter. This is another brick in the HDR canvas proposal
>>> <https://github.com/w3c/ColorWeb-CG/blob/hdr_canvas_r2/hdr_html_canvas_element.md> that
>>> has been slowly making progress.
>>>
>>> The short version of the proposal is: Add the screen's HDR headroom
>>> parameter to ScreenDetailed. It is a potential fingerprinting vector, so
>>> ScreenDetailed is a better fit than Screen. It can also fluctuate rapidly
>>> (e.g, when the screen brightness changes) and independently of other screen
>>> properties, and so it gets its own "on change" event, separate from the
>>> other screen properties.
>>>
>>> Please see below for the fully fleshed out proposal:
>>>
>>>    - Issue <https://github.com/w3c/window-management/issues> on
>>>    window-management API
>>>    - PR <https://github.com/w3c/window-management/pulls> on
>>>    window-management API
>>>    - Explainer
>>>    <https://github.com/ccameron-chromium/ColorWeb-CG/blob/screen_hdr_headroom/screen_hdr_headroom.md>
>>>
>>> This has been shipping behind a flag for several years (although with
>>> some slight API differences, which have been ironed out to better fit the
>>> CSS HDR model). Now that HDR content is getting to be much more common,
>>> there have been several requests to get this out from behind the flag.
>>>
>>>
>>>
>>>