Clarify use cases in Screen Brightness API explainer

[beaufortfrancois]

It would be nice to clarify use cases in https://github.com/w3c/screen-wake-lock/blob/gh-pages/brightness-mode-explainer.md#introduction and potentially associate them to a list of partners that request this API.

Here's an example:

Use cases:

• Increase the screen brightness help illuminate a user's facial features, improving the viability of an application that rely on the front facing camera. It has been requested by iproov.com to authenticate remote users online for onboarding and verification

@willmorgan Would you be able to help?

[anssiko]

@willmorgan I think iProov would qualify as a partner for this new API proposal. Talk to @beaufortfrancois for more if interested.

[eligrey]

No proposed use cases justify controlling screen brightness. I can only see justification for controlling content brightness, which could be combined with the requestFullscreen API to effectively control full screen brightness.

Can anyone think of a use case that justifies system-level brightness control over content-level brightness control?

[willmorgan]

@beaufortfrancois @anssiko Yes, we'd be happy to partner.

@eligrey Sure, going via requestFullscreen would work. Looking at iOS/Android implementations, I can't see how brightness can be handled on "atomic content" level vs system level, but I'm unaware of any screen that allows region level control of its brightness.

[eligrey]

I'm unaware of any screen that allows region level control of its brightness

This is how HDR works when viewed on displays with dimming zones or per-pixel brightness control.

Here are a list of screens with region-level brightness control:

• Every recent TV and monitor from every major manufacturer from the last 6 years that mentions "HDR" and "dimming zones"
• The M1 MacBook Pro 14/16
• Every OLED display and monitor that advertises HDR support (includes devices as far back as 2015)

There are hundreds of different displays already on the market that meet these descriptions.

[eligrey]

Just because the ideal APIs don't yet exist, doesn't mean we should create a worse solution around the APIs that do currently exist.

Device makers and OS vendors need to provide more intuitive developer interfaces if the issue here is OS API compatibility with the ideal state of this API. I think existing APIs are adequate, albeit unideal for browser vendors.

Instead of moving the goalposts, let's try to stay on-topic. Nobody has proposed any use cases that justify the use of system-level brightness control over existing content-level brightness control so far.

[willmorgan]

Just because the ideal APIs don't yet exist, doesn't mean we should create a worse solution around the APIs that do currently exist.

Device makers and OS vendors need to provide more intuitive developer interfaces if the issue here is OS API compatibility with the ideal state of this API. I think existing APIs are adequate, albeit unideal for browser vendors.

Instead of moving the goalposts, let's try to stay on-topic. Nobody has proposed any use cases that justify the use of system-level brightness control over existing content-level brightness control so far.

Interesting, so do you suggest that perhaps a Canvas based API would be more a appropriate way to harness existing HDR support to achieve brightness control?

[eligrey]

CSS is probably a better abstraction, but canvas APIs also seem like a good fit.

[beaufortfrancois]

@beaufortfrancois @anssiko Yes, we'd be happy to partner.

@willmorgan I've started #342

[marcoscaceres]

For the identity verification use case, as an industry, we are now moving towards improved identity credential presentment and verification on the web. The W3C community is working towards standardizing identity credentials in a way that may not require brightness because it relies on other biometrics as part of enrollment (e.g., Face ID and/or TouchID being used for registration and authentication). Google has similar solutions/requirements, I believe. And there are forthcoming regulatory requirements around this too.

The identity credential work may obliviate the need for brightness controls in this particular case.

[anssiko]

@marcoscaceres thank you for bringing your write up to our attention.

@willmorgan is probably in a position to comment on whether that doc has a bearing on the use cases for the screen brightness control capability. The work on the declarative approach (and its earlier iteration) was initiated to allow for innovation and differentiation to happen in this space.

Now that regulatory requirements were brought up, I need to say W3C groups usually focus on technical work within their charters and steer clear of regulatory discussions. From what I know about regulation as an EU citizen, the EU aspires to create an environment that is fair for businesses and consumers, and open to innovation by all. To help with this, the EU's Digital Markets Act imposes a ban on requiring to use so-called gatekeeper's services, including identity providers. To me, this suggests it is important to keep exploring this capability that enables innovation, rather than stop work on it.

Thank you everyone for your diligent work. Your contributions are valued.

[willmorgan]

@anssiko @marcoscaceres Sorry, was on paternity leave!

The mDL and DC/VC specs are interesting and absolutely progressive moves, however you still need some way of asserting that the person is the right one at the point of enrolling/binding the credential to a particular device.

Technically, Face ID/Touch ID or even YubiKeys don't actually send biometric data, which means you can't do a comparison against a user's submitted identity credential like a passport or drivers license, therefore there's no way of attesting that the user of a service is the right person.

There is also no current way to access the Apple "Verify With Wallet" API on the web, unless I am mistaken?

It is also the choice of each government or issuing authority to integrate with the mDL standard which would seem, in this case, to be vendor locked to Apple. This is not likely to be universally desirable.

[marcoscaceres]

There is also no current way to access the Apple "Verify With Wallet" API on the web, unless I am mistaken?

That's true. Apple doesn't comment on or speculate on future products/services, but we are actively participating in the standardization of digital credentials.

The digital credential API is supposed to enable accessing credentials from wallets.

It is also the choice of each government or issuing authority to integrate with the mDL standard which would seem, in this case, to be vendor locked to Apple. This is not likely to be universally desirable.

mDL is an ISO standard. It's also supported by Chrome / Android. It might even be supported in Windows... at least they are participating in the community group that's standardizing digital credentials.

[willmorgan]

Thank you for your reply @marcoscaceres, hope you are doing well.

Have you anything to add on my earlier comment, pasted below?

Face ID/Touch ID or even YubiKeys don't actually send biometric data, which means you can't do a comparison against a user's submitted identity credential like a passport or drivers license, therefore there's no way of attesting that the user of a service is the right person.