Re: Adding support for HDR headroom in ScreenDetailed

Thanks for sharing that insight! Perhaps implementers wouldn't use an
entropy-limiting getScreenDetails() signal.
While adding that later would be more complex, we can proceed without it,
if it's unlikely to be useful.
Let's plan to land the PR as-is on Dec 5th, unless any objections are
raised before then. Thanks!
Mike

On Fri, Nov 21, 2025 at 5:34 PM Kai Ninomiya <kainino@google.com> wrote:

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