@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 commented 21 hours ago

@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 commented 21 hours ago

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 commented 21 hours ago

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

simoneonofri commented 21 hours ago

hi @plehegar, thank you for the pointer.

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

simoneonofri commented 19 hours ago

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 commented 18 hours ago

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 commented 18 hours ago

@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 commented 18 hours ago

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.

w3c / transitions

CR Request for Device Posture API - device-posture #667

Document title, URLs, estimated publication date

Abstract

Status

Link to group's decision to request transition

Changes

Requirements satisfied

Dependencies met (or not)

Wide Review

Issues addressed

Formal Objections

Implementation

Patent disclosures