Created privacy-design.md

[johnpallett]

This is a privacy design for the WebXR Device API, designed to inform text for the specification. It draws upon work in the Privacy and Security repo.

Please see the Background section for an explanation of threat vectors and mitigations that informed this design.

A few notes about this revision:

• At time of writing, this revision matches the currently published spec at https://immersive-web.github.io/webxr ... it does not incorporate issues still in discussion.
• It is assumed that inline and immersive sessions can be fulfilled by the same privacy requirements. For example, the 'focused' and 'visible' requirements for viewer pose data are the same for both immersive and inline sessions, though the implications for user experience and privacy are different.
• User consent - when required - is designed as part of session creation. This is done to avoid user fatigue or confusion of having multiple consent prompts during a session, and to address UX concerns surrounding consent prompts after don flows.
• There are several unaddressed threats listed at the end of the Background section.

[NellWaliczek]

Hey John, thanks so much for posting this to get the ball rolling. You've covered a lot of really critical information and have been very thorough in laying out the details. Seriously, thank you for taking the time to do this.

At first glance, I do have a few concerns with several of the statements running the risk of preventing different browsers from making different choices where appropriate for their business needs. Though, I definitely understand there's a balance to be struck so that we're creating a consistent API and protecting end-users. Over the next few days I'll give this a deeper look and be sure to get you specific feedback in a timely manner.

Thanks, again!

[johnpallett]

Thanks Nell! Eager to hear your feedback and looking forward to the discussion. Please let me know if you have questions in the meantime.

[asajeffrey]

I have a question about user consent, in particular "User consent should only be considered valid for the browsing context within which it was obtained."

Imagine a scenario where a user navigates to a document, provides consent for entering immersive mode, and bookmarks the document, then later visits the bookmark. Do we want to require the browser to ask for consent again whenever the browsing context changed? So user consent needs to be asked for only when the resources for the document have been reclaimed, e.g. due to memory pressure or a process being closed?

[NellWaliczek]

Ok, I've gone through the whole document and again want to thank you for getting all these details laid out so thoroughly. It's readily apparent how much time and effort you put into making sure your proposal was specific, precise, and actionable.

My biggest take away is that your proposal calls for all user consent prompts to be tied to the requestSession() call as opposed to the individual feature function calls that might require permissions. The key thing being that once a feature has been granted permission, subsequent calls to requestSession() would not trigger a user consent prompt unless a new feature is requested. Is that a correct summary?

If so, I'm really keen to hear the opinion of other browser vendors. IIRC, Mozilla had expressed some concerns that this approach limited their flexibility to deliver on the customer perception of their brand? I also recall this being an active topic of conversation with Microsoft and Magic Leap.

That said, what's interesting about this approach is that it doesn't actually prevent developers from creating new immersive sessions as they require more functionality, but it will cause them to have to tear down and recreate all their rendering resources and reference spaces each time. Due to the asynchronous nature of the API calls which will need to be chained in response, this approach would cause a glitch from a user perspective (even if the UA enables the consent dialogs to be displayed over an active immersive session's content).

I've got a few other thoughts about how we can approach defining and enumerating the internal permissions list in the spec text regardless of which approach we take, but I'll leave that off the discussion for now ;)

[NellWaliczek]

Is this a requirement to create a WebGL canvas context? If not, it seems a bit heavy-handed to apply this requirement to an inline session only using the viewer reference space.

[johnpallett]

There may be an opportunity to remove all privacy requirements in this doc if there is no information generated by sensors (or information otherwise reflective of the real world) in the XRSession. Any suggestions on text for that?

(Note: I don't believe this question is related to inline sessions or the viewer reference space. For example, a viewer reference space might still allow tracking of viewer pose, for example by calling getPose() on the viewer reference space relative to a known static reference space, e.g. a 6DOF controller which is known not to be moving.)

[johnpallett]

Note: We'd want to avoid a situation where the language allows platform divergence - e.g. if some platforms support sensors, and others do not, then the wrong language could lead to a potentially breaking scenario where x-origin content works on some platforms (those without sensors) and does not work at all on others (those with sensors).

One approach specifically for x-origin would be to say that x-origin sessions are allowed. but they cannot use sensor data, real-world data, or expose any privacy data (e.g. IPD, real floor height, controllers) at all. That could provide a consistent x-platform path for x-origin content.

[NellWaliczek]

I'm supportive of that approach. 👍 The interesting thing is that this would only be possible for inline sessions because they're the only kind that can be created with all tracking disabled. And I suspect that this not being called out explicitly was a big part of my initial confusion.

[NellWaliczek]

Do we really want to be calling out sensor types given that WebXR has no actual association with the Generic Sensor specification?

[johnpallett]

I think so - the design here says that feature policy for any underlying sensors must be respected (e.g. if the feature policy disables IMU sensors, then sites can't use WebXR to access IMU data indirectly through GetViewerPose). Open to suggestions if there is a different way of saying this, though.

[NellWaliczek]

Ah this is a case of GitHub being slightly too smart and formatting text in a way to hide the link.

What I was asking is do we really want to be relying on the Devices and Sensors spec to be the exhaustive definition of data sources that can drive an XR system's tracking tech. For example, the underlying accelerometer data might not actually be exposed as a Sensor on some devices. Also cameras are a big part of XR tracking and is not exposed as a Sensor.

[johnpallett]

We do not want the Devices and Sensors spec to be an exhaustive definition of data sources (nor is that the purpose of this section).

The purpose here is to avoid the scenario where developers use WebXR to work around the feature policies governing underlying sensor data. In the case of IMU data there is a fairly direct correlation between XRPose and IMU data, and it would be inappropriate to allow developers access to XRPose data (and thus IMU data) if feature policy prevented access to IMU data.

However, to your point the use of camera data to generate XRPose falls into a different category, as it's unlikely that a developer could use XRPose to get camera data, and the camera isn't a Generic Sensor.

I wonder if this section should be generalized in terms of respecting feature policies beyond sensors, but also more precise about the intent to prevent using WebXR as a 'back door' for feature policies.

[NellWaliczek]

Just to make sure I'm reading between the lines correctly here.... your proposal is that in order to use a reference space, developers must indicate their intent to use reference space types at the time a session is created? In other words, you are proposing there be no path to upgrading an existing session allow the creation a a reference space not enumerated as part of the session's creation?

[johnpallett]

In the current revision of the XR spec, I'm not aware of a way for developers to indicate their intent to use reference space types. I'm also not aware of any enumeration of reference space types at session creation.

Having said that, #424 does explore the idea of allowing developers to indicate their intent at session creation. This privacy design was written to allow for that. Specifically, the design does not indicate what features are allowed in which types of session, so if the spec changes to allow developers control over that, the design should be fine. (Side note - this is why 'inline' isn't called out as part of the design doc).

The design does not allow capabilities to be added to an existing session afterwards ('bespoke' feature requests.) This is primarily due to the diversity of device form factors and the challenges with cross-platform user consent. I've added more detail to #424.

[NellWaliczek]

There actually was a feature added as part of the original spatial tracking explainer I wrote before TPAC 2018 that allowed a session to reject if it didn't support the requested reference space type. (https://github.com/immersive-web/webxr/pull/409/files#diff-f02c24f867e61b8e58dc8f2c228f476cR185) There was an issue filed to determine how to better handle developers wanting to require more than one type and we ended up removing it from the designs while we sorted out the more generic approach you refer to in #424.

That aside! I think this gets to the heart of the second main pillar of the design being proposed, yes? In addition to "should permissions be granted at session creation time?" the other big question is: are developers expected to enumerate the permissions they want or is it an all-or-nothing deal. If the former, we'll need an API design to make that possible in a consistent way across all browsers. In other words, what is the categorization of permissions options you're proposing? Is it just "spatial-tracking" for now?

[johnpallett]

Agreed on all points. This doc probably isn't the right place to answer the 'all-or-nothing' session creation question unless it affects the privacy design (AFAICT it does not). Bespoke feature requests would affect this privacy design and that's covered in #424.

re: "permissions" - this design intentionally avoids specifying permissions as it's not clear whether permissions are (in all cases) suitable for gaining informed user consent. If a user agent wants to use permissions that's fine, as long as the requirements here are met, but other approaches could also meet the requirements in this doc and may be preferred depending upon a user agent's privacy policies, permissions implementation, and hardware capabilities. So, the design intentionally does not specify permission categories or options.

[johnpallett]

I've clarified in the summary that the privacy design does not have an opinion on whether user consent must be 'all or nothing' or whether the user agent can disable features based upon what the user has consented to.

[NellWaliczek]

Another clarification question... are you proposing that user consent is NOT required if the floor will be emulated? If so, doesn't that provide a way for developers to differentiate between systems with emulation and without?

[johnpallett]

Great question! There may be other reasons why user consent is required (e.g. if viewer pose data cannot be quantized) so user consent shouldn't be a reliable signal on this one dimension.

[NellWaliczek]

I suspect the answer to that one depends on how many UAs decide to use quantization or not. Also, how many categories of consent exist...

[NellWaliczek]

Is this on a per-permission basis or is it cumulative for a browsing context? As in if Session 1 requests Permission A and then Session 2 requests Permission B, will new user consent be required if Session 3 requires both Permissions A and B?

[johnpallett]

I don't believe there's a situation in the current specification where that could happen... there is no provision for features to be requested, and the capabilities of a device are fairly static.

Having said that, if this became possible in the future then a cumulative approach would make sense (so if an origin already has consent for A and consent for B then it doesn't need consent for A+B). Do you want this added to cover potential future directions?

[NellWaliczek]

If we do decide to break the permissions requests down more granularly, then yes we should be explicit about this cumulative approach here.

[NellWaliczek]

I'm not really sure this section is accomplishing anything since the underlying tracking systems use that same camera data along with IMU data to perform the combined pose estimation. There's no reason a webxr polyfill wouldn't do the same thing (and in fact do), so I'm not sure what this restriction gains in terms of privacy?

[johnpallett]

It's a good question. In theory WebXR pose data may be more accurate than an estimated pose from web-based IMU sensor data, and may be easier to align temporally with the camera feed than web-based IMU data. That means that in theory the site could get more information from camera+WebXR than camera+IMU.

Practically speaking, another more practical consideration not mentioned here is that on devices that have a camera, the user may have forgotten that the site has access to the camera and might wish to know that before they don the device that has that camera.

Originally when we'd discussed this, you'd asked for this section to be added, was there another consideration missing?

[NellWaliczek]

This feels kinda like a buried lead :p This is maybe the biggest point in your proposal; your stance is that consent should only ever be requested at session creation time, yes?

[johnpallett]

The proposed design does indeed take that stance. It's not clear that allowing user consent to be requested elsewhere in the life of a WebXR session could be supported across platforms in a predictable way. I've added more detail to #424 (direct link to comment)

[johnpallett]

@asajeffrey thanks for the question.

Imagine a scenario where a user navigates to a document, provides consent for entering immersive mode, and bookmarks the document, then later visits the bookmark. Do we want to require the browser to ask for consent again whenever the browsing context changed?

As written, yes that is the suggested guideline. I could see an argument that a user agent might choose to persist user consent between browsing contexts (after acquiring it the first time) if the user agent has some other strong signal that the user trusts the origin. However, there are some relevant concerns around user consent outlined here that user agents should consider when making that choice.

So user consent needs to be asked for only when the resources for the document have been reclaimed, e.g. due to memory pressure or a process being closed?

Browsing contexts cover how garbage collection occurs when a browsing context is discarded, but I don't know that consent recommendations need to specifically be tied to garbage collection. Was there a specific scenario you had in mind?

[asajeffrey]

@johnpallett the sort of thing I'm thinking about is things like bookmarks. If a user bookmarks a page and later goes back to it, they might be confused as to why sometimes it asks for all the permissions again, and sometimes doesn't. It can skip the permissions if the browser didn't get restarted (e.g. to reclaim resources) and it's being opened in the same tab (or whatever the equivalent of tab is for XR) but not otherwise?

[johnpallett]

Great feedback Nell thank you; I've made several changes to the design doc to reflect some of your comments; feedback on others directly in the comments.

[johnpallett]

It's a good question. In theory WebXR pose data may be more accurate than an estimated pose from web-based IMU sensor data, and may be easier to align temporally with the camera feed than web-based IMU data. That means that in theory the site could get more information from camera+WebXR than camera+IMU.

Practically speaking, another more practical consideration not mentioned here is that on devices that have a camera, the user may have forgotten that the site has access to the camera and might wish to know that before they don the device that has that camera.

Originally when we'd discussed this, you'd asked for this section to be added, was there another consideration missing?

[johnpallett]

I don't believe there's a situation in the current specification where that could happen... there is no provision for features to be requested, and the capabilities of a device are fairly static.

Having said that, if this became possible in the future then a cumulative approach would make sense (so if an origin already has consent for A and consent for B then it doesn't need consent for A+B). Do you want this added to cover potential future directions?

[johnpallett]

Suggested (at least in the current version). I agree this is not sufficient to entirely mitigate the fingerprinting concern in a variety of scenarios (including a simple bounds geometry that happens to be unique even with 5cm rounding).

The intent of this requirement is to reduce the threat of fingerprinting, but a user agent may wish to acquire user consent in cases where the bounds are likely to be truly unique. I'm not sure that this needs to be a firm requirement, what do you think?

[johnpallett]

Note: We'd want to avoid a situation where the language allows platform divergence - e.g. if some platforms support sensors, and others do not, then the wrong language could lead to a potentially breaking scenario where x-origin content works on some platforms (those without sensors) and does not work at all on others (those with sensors).

One approach specifically for x-origin would be to say that x-origin sessions are allowed. but they cannot use sensor data, real-world data, or expose any privacy data (e.g. IPD, real floor height, controllers) at all. That could provide a consistent x-platform path for x-origin content.

[johnpallett]

An earlier revision did indeed break this out, but I had feedback (I believe from @toji) that different bounds seemed arbitrary and reflective of the spec design, instead of the underlying privacy threat and mitigation. In practice room scale bounds are sufficient to mitigate the privacy threat for all reference space types.

There is also a complicating factor mentioned later in the doc that makes it desirable to have a single bounds: If you create multiple reference spaces in the same session, they should all have the same maximum bounds, to prevent the creation of a series of references spaces that can be compared to indirectly get the effect of an unbounded space. That complication suggests that it'd be desirable for a single size recommendation, allowing the user agent to establish the maximum bounded region with the first reference space, instead of potentially having to 'grow' it depending upon which reference space was created in which order.

Having said that, I don't have a strong opinion... as long as the bounds mitigate the privacy threat, there is some flexibility in approach here. @toji curious to hear your thoughts.

[johnpallett]

As one more note, a benefit of more restrictive bounds for local/local-floor is that it helps mitigate the threat of user fingerprinting based upon gait and height (since a more limited position makes this more difficult).

[johnpallett]

@johnpallett the sort of thing I'm thinking about is things like bookmarks. If a user bookmarks a page and later goes back to it, they might be confused as to why sometimes it asks for all the permissions again, and sometimes doesn't. It can skip the permissions if the browser didn't get restarted (e.g. to reclaim resources) and it's being opened in the same tab (or whatever the equivalent of tab is for XR) but not otherwise?

That's a great observation, particularly for browser contexts that could be running for months. The scenario suggests that user agents may wish some flexibility for how they handle consent longevity, to account for these types of scenarios (in this case, expiring user consent even though the browsing context is still active).

Right now I think that flexibility exists - the design 'suggests' but does not 'require' the guidelines - but perhaps it could be worded more precisely. Any suggestions?

@toji @NellWaliczek FYI when considering spec text.

[NellWaliczek]

So the main thing that jumps out at me is that you’ve got a handful to key design points that we probably want to call out at the very top of the document in a summary and then the rest of the document can go into the details. It’s these key design points that we should aim to get consensus on at the F2F. Please correct me if I’ve misunderstood… these are the things I’ve distilled out of your doc….

1. All WebXR permissions must be requested only in response to requestSession() calls and will last as long as the browsing context.
2. Permissions are required in order to retrieve all sensor-based data (ex. poses) and user configurable data (ex. IPD, bounds).
3. UA may opt out of requesting permissions if they follow a set of required mitigations such as quantization (this makes me a bit nervous because of inconsistencies for developers)

And probably my biggest point of confusion is whether or not you’re advocating for defining granular permissions?

[NellWaliczek]

As @johnpallett pointed out to me yesterday, I forgot that we'd already decided that WebXR disallows creating an immersive session when one already exists. This means we wouldn't have the difficulty of new an immersive session being requested while the user was already in one.
Given that, I do have one concern (that I'm not sure how relevant it is) that if we allow granular user consent granting that developers will be encouraged to request the kitchen sink at session creation time because they won't be able to add additional user consent after the fact.

[blairmacintyre]

Hmmm. Sorry that I haven't commented on this yet (I will try to this week) (as some of you know, I've been heads down on something else for about a month).

I'm keen on the idea that consent for all features can be requested during session creation, of course. For the reasons stated (fatigue).

I'm not keen on the constraint that consent must only be requested during session creation, although depending on how permissions are structured and how permission is granted/exposed it might be ok.

How do we envision permission would be conveyed back. If I request XR, but deny a few sub-features (detailed world knowledge, or camera/sensor access), does the request succeed (since I said yes to XR)? Will users be told I said no, or that this feature is unavailable (but not distinguish between the device abilities or my permissions)?

Future, if a UA has the ability for users to change their mind and upgrade permissions later, how would this work? Or are we completely disallowing this?

In our current WIP on permissions in the WebXR Viewer, the session succeeds if they say yes, even if they deny specific sub features. We haven't really settled on if features should be "upgradable" after you say no (right now, I think the UI allows that, but it might not actually work 😄), but you can definitely turn approved features off/on over time (e.g., stop the camera for a while).

If the app can tell what you've approved or not, or if the requestSession fails if you don't approve everything, there are obvious scenarios where this is problematic.

For example, I visit an AR (XR) application, and that application has a range of modes or features, so of which I want to use, some of which I'm uncomfortable granting the required permission. E.g., random shopping site using a "stock" Shopify e-commerce infrastructure that provides the ability for me to visualize the product in a bunch of ways, from "floating in space" to "click to pick a point then place it", to "capture the full structure and illumination of the room, with light probes and realistic illumination and occlusion". Perhaps I never want to allow that last feature on any site.

The site would need to request everything up front. If it can tell I said no to something, it may refuse to run, even if I have no intention of using the part of the site/page that needs that feature (or, if I'm happy to have a less rich experience).

[johnpallett]

Thanks @blairmacintyre, these are good questions and observations.

I'm not keen on the constraint that consent must only be requested during session creation, although depending on how permissions are structured and how permission is granted/exposed it might be ok.

The rationale for why consent can only be requested during session creation is covered in more detail here. I'll add a note to this design as well.

How do we envision permission would be conveyed back. If I request XR, but deny a few sub-features (detailed world knowledge, or camera/sensor access), does the request succeed (since I said yes to XR)? Will users be told I said no, or that this feature is unavailable (but not distinguish between the device abilities or my permissions)?

This is an interesting question not directly addressed by this design. #424 is a related topic. There is at present no mechanism that I'm aware of in the WebXR Device API to report user consent choices back to the developer (and to your point, ideally the developer wouldn't know anyway).

An explicit requirement in the privacy design is that if the user does not consent to what the session will allow, the session should not be created.

The privacy design also allows the user agent to limit the capabilities of a session to address privacy concerns. For example, an inline session might use quantized pose data, if the user agent determines that quantization would not affect the user experience. There is no mechanism to tell the developer that this is happening.

The privacy design also requires user consent for certain features. For example, an unbounded reference space may allow the site to infer the user's geographic location, and if the user does not consent to that, the unbounded reference space should not be created. The design requires that consent to use those features be obtained at session creation, and consent must be obtained for any features that are possible in the session being created.

The design does not specify whether 'partial' consent is allowed for some set of features, where the user consents to some, but not all. For example, a user might consent to sharing floor height, but not location; in theory this would allow the creation of a local-floor reference space but not an unbounded one within the session. The privacy design does not address whether the user agent must fail to create a session, or whether the user agent may create a session that allows the 'partial' set of features that the user consented to, but disables the ones that the user did not consent to.

One challenge with creating sessions based on such 'partial' consent is that if the XRDevice list of supported modes includes a reference space that is disallowed after the session is created, there could be a mismatch between the reported capabilities and the actual capabilities allowed by the user. This might allow the developer to infer what the user had consented to.

Future, if a UA has the ability for users to change their mind and upgrade permissions later, how would this work? Or are we completely disallowing this?

This design does not allow user consent to be solicited mid-session because it's not clear that there is a cross-platform way for trusted interfaces to be reliably presented without terminating the session or causing user discomfort. More detail is here. The core concern is that unless developers test on every possible platform, they may build behaviors into their experience that work on some platforms but cause the experience to terminate (or otherwise cause discomfort for users) on others.

[johnpallett]

Given that, I do have one concern (that I'm not sure how relevant it is) that if we allow granular user consent granting that developers will be encouraged to request the kitchen sink at session creation time because they won't be able to add additional user consent after the fact.

Agreed. While I don't believe the current revision of the WebXR specification allows developers to request features at session creation time, this is an important consideration for #424

One approach would be (as outlined in #424) for developers to be able to request the features they want when creating a session. This has the benefit of allowing developers to request only the features they plan to use which would allow the user agent to streamline user consent (or even avoid it in some situations).

A different approach would be for user consent to shape the capabilities of the session, giving the user more control over what the session allows. For example, if a user allows floor height to be shared, but disallows location, this would suggest that it's OK to create a session that allows creation of a local-floor reference space but not an unbounded one. One consideration of this approach is that differences between the capabilities of an XRSession and the XRDevice list of supported modes might allow developers to infer what a user consented to.

Per our in-person discussion I'll ensure the User Communication section has a complete list of feature/consent pairs.

[NellWaliczek]

Per my conversation with @ddorwin and the discussion on yesterday's call, it seemed sensible to divide up the large number of related but distinct topics covered by the discussion on this PR into separate issues to make it easier to follow. fingers crossed that I've captured things correctly so far and haven't missed anything major!
Once we've gotten (most) of those issues resolved we can come back and figure out what we'd like to do with this PR.

[johnpallett]

Note: In the design the term "suggest(ion)" is intended to propose a non-"MUST" requirement (either a "SHOULD" or "MAY" or something else like a design consideration).

[NellWaliczek]

Hey @johnpallett,
I know we've mostly moved discussion out of this PR, so I'm sorry if posting here opens a can of worms. I have some questions some of the content in this PR that isn't covered in any of the other issues that have been filed, so I figured it might be safe ^_^

For context, I'm trying to put the finishing touches on a PR that should encapsulate the remaining unaddressed content in this PR, and I have a few minor questions that I'd love to get clarified before I post it:

For these sentences

• User consent must have been obtained on devices with configurable interpupillary distance before creating an XRViewerPose that will return an XRView for each eye.
• If the device supports configurable or factory-calibrated interpupillary distance that may vary from device to device, then the XRView transform data must be rounded to prevent fingerprinting. Specific precision for rounding is at the discretion of the user agent.
• If the XRViewerPose will include multiple XRViews for displays whose positions and orientations have been configured by the user (e.g. in a CAVE) then the XRView transform data must be rounded to prevent fingerprinting.

I'm a bit confused in trying to distinguish the difference in threat level between an n-view headset with configurable IPD and an n-view CAVE system that allows the view panel placement to be configured. Do you have any additional background information that might help out? For example, why is user consent necessary for IPD data and not the other?

For these sentences

• If XRViewerPose data is generated by sensors, at least one of the following conditions must be met to mitigate sensor fingerprinting threats; the user agent may choose the approach that provides the best user experience:
  • User consent must have been obtained, or
  • Any XRView transform data generated by sensors must be quantized to prevent sensor fingerprinting, or
  • The user agent must otherwise ensure that the underlying device sensors are not susceptible to sensor fingerprinting.

Two questions:

First, what's the reasoning behind these protections only needing to apply to XRViewerPose data and not XRPose data?

Second, IIRC, the Devices and Sensors WG settled settled on requiring a clear statement of intent for access to acellerometer data. Given that, do we still believe that the options 2 and 3 are allowable?

[johnpallett]

@NellWaliczek these are great questions, thank you!

I'm a bit confused in trying to distinguish the difference in threat level between an n-view headset with configurable IPD and an n-view CAVE system that allows the view panel placement to be configured... why is user consent necessary for IPD data and not the other?

In that specific case, the raw display positions in the n-view CAVE might be fingerprintable (i.e. the values might be unique to that device) whereas IPD data might be used for user profiling of sensitive characteristics. The fingerprinting risk can be mitigated by the user agent, but I couldn't find a way to mitigate the user profiling risk, thus user consent.

I've summarized the general principles used in this design for fingerprinting and user profiling towards the end of this comment.

For reference, this table outlines the rationale behind the different requirements.

What's the reasoning behind these protections only needing to apply to XRViewerPose data and not XRPose data?

I believe the same protections are present for both XRPose and XRViewerPose. The XRPose section doesn't mention XRView, but otherwise is similar:

If an input to getPose includes data generated by sensors, at least one of the following conditions must be met to mitigate sensor fingerprinting threats; the user agent may choose the approach that provides the best user experience:

• User consent must have been obtained, or
• Any transform data generated by sensors must be quantized to prevent sensor fingerprinting, or
• The user agent must otherwise ensure that the underlying device sensors are not susceptible to sensor fingerprinting.

One thing we'd previously discussed (and which I didn't have time to address before the last f2f) was merging the requirements for XRPose and XRViewerPose to better reflect the inheritance. Please let me know if you'd still like me to do that in this PR, or if there's something else I can do to help make things clearer.

Second, IIRC, the Devices and Sensors WG settled settled on requiring a clear statement of intent for access to acellerometer data. Given that, do we still believe that the options 2 and 3 are allowable?

Yes. IIUC the D&S WG did accept a contribution for a requestPermission() method covering the DeviceOrientation Events API. I'm told the primary motivation for this was fingerprinting; I haven't found any other concerns that would apply to WebXR. Unless there are other concerns (feedback welcome!), options 2 and 3 should still be allowable since they mitigate the primary concern. User agents who prefer can of course still require user consent.

---

In case it's useful, here are the general principles used in this PR with regards to fingerprinting and user profiling:

Fingerprinting

• The user agent must take steps (where possible) to prevent exposing data that is unique to the device. This is true even if consent has been obtained for other reasons. For example, even if user consent is obtained to expose IPD data (for reasons of user profiling) it is still in the user's best interests that the IPD data be anonymized to prevent fingerprinting.
• Some raw sensor data might be fingerprinted (e.g. IMU data) and thus access to that raw sensor data outside of WebXR requires user consent. The user agent must either ensure WebXR data based on those sensors is anonymized sufficiently to prevent fingerprinting, otherwise user consent is required.
• Mitigating the threat of fingerprinting is a requirement, but specific mitigation details are up to the user agent who is best equipped to evaluate the actual threat on a given platform using the platform's APIs. The approaches (e.g. values for rounding thresholds) in the design are intended as suggestions, not firm requirements.

User Profiling

• Consent is required before exposing data that sites might use to reliably infer sensitive user characteristics (such as race, gender, or age) for some population of users. For example, user-configured IPD data might allow a site to determine the age of some users. Note: Even if most users couldn't be profiled, if some users can be reliably profiled then this requirement holds for all users.
• This design prioritizes the protection of sensitive user characteristics. If there is a reasonable possibility that a reliable signal for a sensitive characteristic exists, then user consent is required.
• User profiling concerns are not sufficient to require consent before exposing data that either provides a weak signal for all users, or where the information that can be inferred is not particularly sensitive. For example, the size of a user's room could (in theory) indicate a user's wealth, but it might just as easily indicate that a user is at work; this ambiguity suggests the signal is unreliable and thus user consent is not required.

[klausw]

"Mitigating the threat of fingerprinting is a requirement, but specific mitigation details are up to the user agent who is best equipped to evaluate the actual threat on a given platform using the platform's APIs. The approaches (e.g. values for rounding thresholds) in the design are intended as suggestions, not firm requirements."

In case it helps, here's a couple of examples to try to make this more concrete.

If a HMD has user-adjustable IPD where the in-world camera distance is configured to match, an application can get this IPD value by examining the per-eye view origins. The IPD value can potentially be used for user profiling, but if this value is provided at a very high precision it could also identify a specific device, i.e. if the underlying platform stores a measured value persistently in a user profile. In this case, rounding the application-visible IPD value to the nearest 0.1mm would help reduce the fingerprinting impact, but the user profiling issue would still remain. This type of rounding would only be recommended if it doesn't make the experience worse, and this example assumes there wouldn't be a noticeable difference in perceived world scale between a rounded value of 65.3mm vs an API-reported value of 65.324323mm.

Another example would be if a manufacturer stores per-unit calibration values in each device to compensate for small manufacturing differences, and data derived from these device specific values end up visible through the WebXR API, for example if each device ends up with unique small variations in the supplied projection matrices. This could be mitigated if the application-visible API can hide these details, for example if it uses generic projection matrices and applies per-device correction in a separate reprojection step, but this may require cooperation from the underlying platform APIs.

[NellWaliczek]

Ok, I think I've captured these answers accurately in #746. Please leave comments there if I've messed it up.

[johnpallett]

#746 covers IPD well. It also addresses most of the topics in this PR. Thank you @NellWaliczek!

#748 will also extend the privacy & security explainer to clarify the sensitivity of certain profiling data and user consent suggestions

After that, most of this PR is covered but there is still some material not addressed elsewhere. I'd suggest we do the following:

1. I'd suggest Private Browsing modes should be part of the privacy & security explainer. I've added Address private browsing modes in P&S explainer #750 for this.
2. Camera Data and privacy. @NellWaliczek you'd suggested we add this as a consideration to the design doc, do you think we should bring it forward to the explainer?
3. There is a table showing features, corresponding threat vectors, and mitigations which shows a feature-based analysis of privacy.
4. There is a Background section reviewing individual threat vectors and how they are mitigated, including an Unaddressed section covering threats not covered.
5. The principles for when sensitive data is/is not considered a threat is covered in the comments.

Topics 1 and 2 seem suitable for the P&S explainer.

Topics 3, 4, and 5 are background, so maybe not suitable for the explainer, but I'd rather not lose them... I've referred to them frequently during our conversations and presumably they might be useful in the future as new features get added.

One approach for 3-5 would be to rework this PR into a "WebXR Privacy Principles & Analysis" document, to cover just those topics. @NellWaliczek WDYT?

[NellWaliczek]

Thanks for going through and ensuring nothing slipped through the cracks!

1. Sounds good!
2. Good catch. Yes, I agree it'd be a good idea to include in the privacy-security-explainer.md
3. What do you think about this being an appendix in the privacy-security-explainer.md?
4. I think most of the Background section would be covered by the existing privacy-security-explainer.md text, the proposed fixes in Privacy & Security explainer: Clarify threat vectors #748, and adding the table from bullet point 3 above. The unaddressed stuff might be good either as it's own section or as an appendix in the privacy-security-explainer.md. WDYT?
5. Another good catch. Those definitions (i assume you mean the stuff at the very bottom of that comment) would probably be good right after the first or second paragraph of the privacy-security-explainer.md. Seem reasonable?

As for this PR, maybe the best thing to do is to add a big note at the top that this was background that went into the authoring of the privacy-security-explainer.md, link to it, and just merge this document as an artifact.

[johnpallett]

Thanks @NellWaliczek

On (2) that SGTM, added #753 to track
On (3) that SGTM, added #754 to track
On (4) I agree, the table covers it well. I've added a note to #754 regarding the unaddressed section
On (5) that SGTM. This probably makes sense as part of #748 and I've added a comment there.

I'll add a big note at the top shortly.

[johnpallett]

@NellWaliczek added note. Do you want to merge as an artifact? (I'm not sure whether that designates a particular process - if there's anything I need to do please LMK)