CR Request for Device Posture API - device-posture

[himorin]

Document title, URLs, estimated publication date

Device Posture API
https://www.w3.org/TR/2024/WD-device-posture-20241115/
2024-11-26

NOTE: this issue will be marked as transition review after PR for changes section merged merged

Abstract

https://www.w3.org/TR/2024/WD-device-posture-20241115/#abstract

Status

https://www.w3.org/TR/2024/WD-device-posture-20241115/#sotd

Link to group's decision to request transition

CfC: https://lists.w3.org/Archives/Public/public-device-apis/2024Nov/0000.html
resolution: https://lists.w3.org/Archives/Public/public-device-apis/2024Nov/0002.html

Changes

https://www.w3.org/TR/2024/WD-device-posture-20241115/#substantive-changes-summary-fpwd

Requirements satisfied

yes

Dependencies met (or not)

dependencies unlikely to change

Wide Review

• tracker: Wide review tracker device-posture#146
  • a11y: Device Posture API 2024-05-31 > 2024-08-31 a11y-request#84
  • tag: Device Posture API [formerly Screen Fold API] w3ctag/design-reviews#575
    • delta: Viewport Segments Property w3ctag/design-reviews#689 , Foldable Device CSS Primitives w3ctag/design-reviews#690
  • i18n: Device Posture API 2024-05-31 > 2024-08-31 i18n-request#233
  • privacy: Device Posture API 2024-05-31 > 2024-08-31 w3cping/privacy-request#136
  • security: Device Posture API 2024-05-31 > 2024-08-31 security-request#69

Issues addressed

https://github.com/w3c/device-posture/issues?q=is%3Aissue+is%3Aclosed

Formal Objections

no

Implementation

will be prepared from https://wpt.fyi/results/device-posture

Patent disclosures

https://www.w3.org/groups/wg/das/ipr/

/cc @diekus @kenchris @darktears @anssiko @reillyeon

[himorin]

updated URL following PR (on changes section) merged.
would take some time (on r?) for html tidyup for actual publication.

[plehegar]

@simoneonofri , we're wondering if the cross-origin section in this specification was looked at from a security perspective.

(this wasn't flagged as problematic by the privacy folks)

[darktears]

@plehegar yes it was. We went through PING review. I don't want to discuss again what was discussed before (see PING minutes) but long story short, there isn't a mechanism existing in the web platform to guard CSS API (specifically CSS MQs) behind a permission policy so adding permission policy would only apply to the JS surface (and thus defeating the purpose). PING and CSS WGs have started a discussion around that (which has been silent so far). At the end it was deemed that the fingerprinting is very low risk provided it doesn't expose much information useful to bad actors and is getting less and less relevant as more devices hit the market.

[plehegar]

@darktears , yes, we did note that it was reviewed by PING. But we also noticed that the TAG wasn't asked for the changes and we're wondering if that particular section is of interest to the security folks.

[darktears]

I did not request another TAG look on this specific section. When TAG reviewed this specification there were never plans to add a permission policy in the first place. This specific section was documented to be concise about the problem space that's really it.

FWIW this API just shipped in Chromium.

[plehegar]

we're double-checking with @simoneonofri and did not see anything otherwise.

[simoneonofri]

hi @plehegar, thank you for the pointer.

@darktears i am reading the spec (from a security point of view)

[simoneonofri]

Since the API only provides information, the security part is assimilated to privacy concerns (it should also be nice to reference fingerprinting here).

I am specifically reasoning about this message concerning possible abuse cases (e.g., how this can be abused by aggressive advertising? or for XS-leaks).

No further issues for now.

[darktears]

Thanks @simoneonofri for taking a look.

We do cover fingerprinting over here.

There isn't much value in the API for abuse by advertisers. If the intention is to detect a foldable device there are many other ways to detect them without that API. If it's to track them across contexts again it's only possible to potentially track a user which is using the 'folded' posture (any other devices will return continuous and non folded foldable devices as well) but it will all fall apart if the posture changes while changing context (posture change is a user triggered action). Also many many devices are shipping now so folded devices are getting more and more common. It does add a bit of entropy for sure but I don't think it's very sensitive.

We do want to expose the API to iframes because there are legit use cases for it (as some developers commented).

[simoneonofri]

@darktears, you're welcome.

Could you put in the Security Considerations Section the reference to that point already mentioned in the privacy considerations?

Another Threat Actor we can consider is someone who places in the iframe something like BeEF - back in the day, I tended to put it inside an iframe :).

[darktears]

I could add the reference but I'm not sure it provides any value provided that the Security Considerations Section is right above the Privacy section and the first paragraph is what we're talking about, no-scrolling required pretty much.

[plehegar]

Approved.

Thank you @simoneonofri and @darktears .

[darktears]

Thanks @plehegar for the approval.