Re: Adding support for HDR headroom in ScreenDetailed

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.
>>
>>
>>
>>