Webxr: WebXR API allows 2 or 3 bits of fingerprintability through isSessionSupported

[pes10k]

As called out by the spec, the API currently reveals fingerprint-sensitive information about the user's device, in a way thats not gated (i.e. isSessionSupported). I'm not sure if this is 2 or 3 bits b/c its not clear to me if inline ever returns false.

I think the best solution here would be to make isSessionSupported gated behind the permission too.

[toji]

First off, inline should never return false, so it's not a fingerprintable bit.

Aside from that the 2 bits of fingerprintability that comes from isSessionSupported() is very intentional and was given a lot of discussion within the group. The API shape is designed such that sites can query that boolean to determine whether or not they should advertise XR capabilities, which is a crucial user ergonomics capability. Imagine a large site like YouTube wants to use the API to display 360 videos. They would most likely want to put an icon for triggering VR presentation next to the fullscreen icon, etc, but only if the user has some hope of actually being able to view the content in VR. It's simply not going to be acceptable to sites that strive for a polished user experience to show the button to all users only to immediately say "Nope, sorry" to the majority of them when they click it. Similarly, if a permission was required to even be able to show the button, no site would use it because it's incredibly intrusive, confusing, and unwanted to have a page immediately pop up a "I want access to your VR headset!" prompt when it first opens. Instead, we want the permissions prompts to be associated with the actual creation of a session, at which point the user has presumably asked for the VR capabilities to activate (it requires transient user activation) and thus a permission prompt won't be surprising.

The API has been designed such that doing anything useful with it requires creating an XRSession, which DOES make use of permissions prior to exposing anything else fingerprintable. This was the tradeoff the group made between making the API useful and usable for pages vs. revealing as little as possible until the user consents to it. I feel pretty comfortable with the balance that we struck.

[pes10k]

Hmm, i don't follow. Surely if YouTube wants to present a "view in webxr" button, they can either ask "would you like youtube to know about webxr" or similar, or YouTube can have some "enable WebXR flow", just as with notifications or anything else.

I'm not following whats unique about WebXR that should expose users to fingerprinting risk

[toji]

As mentioned in my previous comment, this would be similar to showing a fullscreen button, in that it's advertising the availability of a particular viewing mode. Would you find it acceptable if every page you visited with video prompted you if you wanted to allow it to show the fullscreen button, well before you gave any indication that you even wanted to interact with the video?

[pes10k]

If there was fingerprinting harm in showing my device had "fullscreen" capability, then

i) yes, I would absolutely prefer to be asked,
ii) id like it even more if sites took that as a hint to be more cautious about when to ask
iii) but most important, I'd hope that the folks who designed the "fullscreen" relevant spec figured out a solution that didn't force me between constant permission prompts and enabling tracking (e.g. me raising the issue here ;)

It also doesn't seem like a fair comparison bc the number of sites that will have use for WebXR for the short to medium term is very small, while the number of sites who'd like to fingerprint me is extremely large. I imagine the math works out diff for fullscreen video

[toji]

There _is_ fingerprinting information exposed by that button, since the API is not supported by iOS phones.

I get the impression that we're talking past eachother, though. I have a hard time accepting that APIs should make themselves user and developer antagonistic in order to avoid exposing even a single bit of fingerprintable information. We've gone to great lengths to keep the amount of information our API exposes without user consent to an extreme minimum, and had plenty of input on the current policy from a large variety of vendors, the TAG, etc.

User Agents that are willing to make user ergonomics tradeoffs in the name of incremental user privacy gains could either always report "false" with the API and simply never expose XR capabilities, or always report "true" and wait until the point that a user attempts to interact with XR content to inform them that their device is not compatible.

[pes10k]

There is fingerprinting information exposed by that button, since the API is not supported by iOS phones.

This is not fingerprinting surface since the site can easily determine you're on iOS through other means. There is no additional identifiability.

plenty of input on the current policy from a large variety of vendors, the TAG, etc

Not sure what to say on this point other than in the W3C there is horizontal review for privacy issues, and that review is distinct from vendors and the TAG.

More broadly, I understand the temptation to say "eh, its only 2 bits, who cares". But there are dozens and dozens of specs in the web platform. If each spec gives one bit of fingerprintability, thats enough to uniquely identify everyone on the planet. Its an especially bad trade off since the vast majority of sites will not use this feature in the short to medium term, so for most sites, its all cost and no benefit

In other words, i dont think we're talking past each other. I think we're just disagreeing

[toji]

/agenda to acknowledge this concern during the next Working Group call.

I'd encourage you to join our next call, which will be March 17th at 12:00 PST. Information about joining can be found here: https://github.com/immersive-web/administrivia/tree/master/meetings

[pes10k]

@toji thank you, I can attend that call and will talk to you all then

[kearwood]

FWIW, there is a Firefox specific issue about this for the special "resist fingerprinting" mode that takes more extreme precautions when activated:

https://bugzilla.mozilla.org/show_bug.cgi?id=1579243

When in this "resist fingerprinting" mode, isSessionSupported will always return immersive-vr and immersive-ar as supported, without showing a permission prompt. Then, when RequestSession is called, the permission prompt is always shown, even if no hardware is present. This prevents any possibility of sites inferring the presence of hardware through observing the time elapsed during the prompt.

In regular modes of operation, Firefox and Firefox Reality will query hardware and report the capabilities accurately when isSessionSupported is called. Also, permission prompts are suppressed when no hardware is present for RequestSession.

[nbutko]

Having the ability to detect XR device capabilities is a high value signal that improves user experience. Websites with immersive content that prioritize product excellence will have a strong incentive to infer this information with reasonable reliability because not doing so will result in a poor end user experience.

[toji]

One action item that came out of today's call is to add text to the spec that specifically calls out the approach that Kip outlines above (The "resist fingerprinting" mode) as valid behavior for UAs that wish to reduce fingerprinting surface.

This does not solve the core issue, as @pes10k has indicated that the preference of privacy interest group is that the default spec behavior does not allow any fingerprintable bits, while others in the group remain concerned about the page ergonomics that would result in. (As @nbutko pointed out in the prior comment.) As such the discussion is ongoing.

[pes10k]

Hi all, just a follow up that i've completed re-reviewing the spec, and this issue still seems present

[Manishearth]

@pes10k Yeah, this issue is tagged as pre-REC since as we understand it the spec already allows the behavior written out in @kearwood's comment, and it's just a matter of specifically writing it out. I can do that now if you'd wish, the plan was to add that text post CR.

[pes10k]

Hi @Manishearth , i'm not sure I follow. I see the text in the spec saying browsers can lie if they want to. But my issue is that that doesn't address the privacy concern (browsers can always lie if they want to, the goal of privacy review is to make sure implementations are privacy preserving).

Apologies if i've misunderstood your comment

[Manishearth]

Oh, I see, @kearwood's comments were already incorporated in https://github.com/immersive-web/webxr/pull/986

@pes10k It's unclear to me at this point if it's possible to resolve the situation here any further. This is a pretty crucial API for the functionality here, and the API has now been unflagged in implementations since January.

[pes10k]

There were several ideas that came up during the previous call that would help address the concern (not mutually exclusive):

1. collapse audio and video into a single option ("supports vr session")
2. require user gesture in frame before API resolves
3. bundle this "does this device have advanced hardware capabilities" request with other related advanced-hardware-capabiltiy requests
4. limiting to 1p frame

I expect the WG could come up with other ideas too, since I very much don't have domain-expertise here. :)

[klausw]

1. limiting to 1p frame

Unless I'm misunderstanding it, this is already controlled by the xr-spatial-tracking permissions policy, and isSessionSupported will always return false for immersive modes in cross-origin iframes unless the parent explicitly opts in.

(Edit: added "cross-origin")

[pes10k]

@klausw thats terrific, thank you for pointing me at that! It doesn't fully address the concern (fingerprinting in the 1p is a concern too), but combined with some / all of the other mitigations would be a useful defense / solution!

[Manishearth]

collapse audio and video into a single option ("supports vr session")

idk what you mean by audio and video here

---

The permissions policy (né feature policy) solves the frame concern (and aiui, the gesture concern).

I don't see how 3. can be resolved without a breaking change.

[toji]

idk what you mean by audio and video here

I'm going to guess that @pes10k actually means "AR" and "VR" here, which in the context of our API don't refer to "audio" and "video" but "Augmented" and "Virtual". It's easy to see how someone not previously familiar with the terminology could confuse the two.

In this case the functionality of those two modes is distinct enough that querying them both as a single boolean wouldn't make much sense. For example: A application that allows you to place virtual furniture in your home to determine if the real thing requires AR and makes no sense in VR (where the environment around you is entirely virtual and you can't see the real world).

There's a reasonable parallel to be drawn here with audio and video, actually, in that if I was building an application that requires camera access but could only ask "Can I access the camera OR microphone", an answer of "yes" doesn't actually tell me much useful.

[pes10k]

I'm going to guess that @pes10k actually means "AR" and "VR" here

Yes thank you, my error :)

In this case the functionality of those two modes is distinct enough

Point taken that the functionality is different, but does the WG expect it to be common that users have a device that supports one but not the other? If not, then it makes sense to collapse them into a single point. If so, then this is exactly the privacy harm that needs to be mitigated / solved

[Manishearth]

Some AR devices may choose to support both, but in most cases you will have a device that supports one or the other. The feature is not very useful without this bit being exposed.

[pes10k]

The feature is not very useful without this bit being exposed.

Understood; this is why I am marking the issue as "needs resolution". If its both true that i) there is significant privacy risk here (seems unambiguous) and ii) that there is the potential for benefiting users, you all (the WG) are the folks who are best suited to figure out how to square that circle.

My role is just to identify that the spec needs more work to not be privacy harming and seemingly incompatible with the web / platform's w3c's privacy commitments and goals.

[Manishearth]

I will also point out: there are basically broadly speaking three situations where you have an AR/VR device connected to the browser:

• The browser is running on a VR device: you can already detect this case from the user agent string, usually
• The browser is running on a phone supporting handheld AR: again, this is clear from the user agent string (Chrome version X+, etc)
• The browser is on a desktop connected to a headworn device. This is the one case where an actual potential fingerprinting bit exists, and it only really exists if people are leaving their devices powered on and connected to their computers while doing regular browsing. That does not seem very likely to me. If it is, one potential mitigation is to more strongly suggest that user agents implement the permission prompt already suggested in the spec for this case.

[toji]

does the WG expect it to be common that users have a device that supports one but not the other?

@Manishearth already mentioned AR headsets, but a far more common device that supports both is a wide range of Android phones. Chrome on Android can support handheld AR or "Cardboard-style" VR, which are very different in terms of utility even if they surface very similar device data. Depending on the mode the application uses entirely different backends are spun up to support the desired use case.

If its both true that i) there is significant privacy risk here (seems unambiguous)... [emphasis mine]

Forgive me, but this doesn't seem as unabiguous as you claim. The API has privacy implications, yes, but I would tend to view a "significant privacy risk" as something on the order of "might take pictures of the user or record their voice when they're not aware of it."

you all (the WG) are the folks who are best suited to figure out how to square that circle.

The working group takes this very seriously, and spent copious amounts of time discussing how to approach this issue thoughtfully and in a privacy preserving way. The compromise we landed on to square said circle was whittling it down to the two most critical bits of information we felt was necessary for enabling pages to inform their users of available features and pushing absolutely everything behind a user consent step.

[pes10k]

significant privacy risk

Fair point; i disagree with the line you're drawing, but I totally take your point that diff folks will have diff lines. But "enables and strenghtens persistent and invisible reidentification, tracking and profiling, through fingerprinting" is not something new specs should enable or allow.

Again, i appreciate this is a frustrating process, but if every spec allowed an extra bit of passive fingerprintabilty, everyone on the web would be uniquely identifiable. The spec needs to prevent passive querying of hardware capabilities. This is the same point / review / response that came up last time I reviewed the spec.

I am very happy to work with the group to further brianstorm ways of addressing this privacy harm; the WG might consider bringing in useable privacy or related experts to help. But there is still work to be done here before the spec moves to rec

[Manishearth]

If I'm not wrong @avadacatavra, a privacy expert, was around for this discussion and has typically driven most of these discussions (Diane, please correct me here if I'm wrong in this instance!)

I really do think this is the best compromise possible here.

The alternative to this API is a permissions-fatiguing API where a lot of websites request this to see if they can show the "enter XR" button (IIRC a lot of media outlets did this with WebVR for 360 photos and videos), and it would be separate from the main XR permission, so now you have two very similar permissions: one with a small fingerprinting risk, and one with a much larger risk, with the small one being shown very often to users.

[avadacatavra]

We had to find a balance between permissions fatigue and letting devices know what's supported. In this case, it wasn't clear that putting isSessionSupported behind a permission empowered users in any way, so the tradeoff made sense.

Like @Manishearth said, isSessionSupported is used for a website to determine if they can show the "enter XR" button, so we would be showing an XR permission without any clear indication that there is any XR content on the site, which is confusing to users, as well as adding an additional permission.

I recognize that this extra bit of fingerprinting may be controversial, but the only other option was to bombard users with useless permission prompts.

[pes10k]

I understand the point being made here, honestly, but this is the same argument made for every “id like to query hardware capabilities passively” feature, for every piece of hardware that touches the web.

I suggest folks think about encouraging user flows that would fulfill these use cases w/o the privacy harm. An example that comes to mind is that Twitter has a “enable notifications” button in its preferences; it doesn’t just ask for permission for notifications right away. Perhaps you could encourage WebXR needing sites to do something similar.

Im offering the twitter example not bc I think it is (or isn’t) the right approach, but as an example of how sites incorporate advanced browser capabilities w/o permission fatigue.

But, allowing sites to passively query hardware capabilities is a privacy harm and spec-antipattern, and specs need to prevent passively querying hardware before going to rec.

On Aug 28, 2020, at 10:36 AM, Diane Hosfelt [e-mail] wrote:

We had to find a balance between permissions fatigue and letting devices know what's supported. In this case, it wasn't clear that putting isSessionSupported behind a permission empowered users in any way, so the tradeoff made sense.

Like @Manishearth said, isSessionSupported is used for a website to determine if they can show the "enter XR" button, so we would be showing an XR permission without any clear indication that there is any XR content on the site, which is confusing to users, as well as adding an additional permission.

I recognize that this extra bit of fingerprinting may be controversial, but the only other option was to bombard users with useless permission prompts.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Manishearth]

I don't think notifications are a good example here because while Twitter does a good thing here, basically every other site does not follow the pattern, especially ones where users typically do not have an account.

I'll note that WebVR, the deprecated API WebXR is trying to replace, _already tried the approach_ of having a "let this site know about your VR devices" permissions prompt and it did not work out well.

I'd like to point out again that 99% of the time this isn't an actual fingerprinting bit, it's only one when you are on a desktop browser with a powered on tethered VR device connected. All other cases are ones where you can get the fingerprinting bit from the user agent string anyway.

A thing we could do is non-normatively strongly suggest that such user agents mitigate the fingerprinting risk by autorejecting the promise with a randomized delay when used without a tethered device being connected, and throw up a permissions prompt _only when such a device is connected_.

[pes10k]

I'd like to point out again that 99% of the time this isn't an actual fingerprinting bit, it's only one when you are on a desktop browser with a powered on tethered VR device connected. All other cases are ones where you can get the fingerprinting bit from the user agent string anyway.

The fact that it's a rare fingerprinting bit is exactly what makes it a dangerous fingerprinting bit; for the users in the category it's enormously identifying.

A thing we could do is non-normatively

Non-normative text is useful and helpful for guiding implementations, doing so is terrific and if I can be helpful here please let me know. But it doesn’t solve the problem. The normative / mandatory parts of the spec / functionality need to be privacy-preserving by default.

On Aug 28, 2020, at 10:56 AM, Manish Goregaokar [e-mail] wrote:

I don't think notifications are a good example here because while Twitter does a good thing here, basically every other site does not follow the pattern, especially ones where users typically do not have an account.

I'll note that WebVR, the deprecated API WebXR is trying to replace, already tried the approach of having a "let this site know about your VR devices" permissions prompt and it did not work out well.

I'd like to point out again that 99% of the time this isn't an actual fingerprinting bit, it's only one when you are on a desktop browser with a powered on tethered VR device connected. All other cases are ones where you can get the fingerprinting bit from the user agent string anyway.

A thing we could do is non-normatively strongly suggest that such user agents mitigate the fingerprinting risk by autorejecting the promise with a randomized delay when used without a tethered device being connected, and throw up a permissions prompt only when such a device is connected.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Manishearth]

Non-normative text is useful and helpful for guiding implementations, doing so is terrific and if I can be helpful here please let me know. But it doesn’t solve the problem. The normative / mandatory parts of the spec / functionality need to be privacy-preserving by default.

I don't think any web specification goes as far as to normatively dictate precisely what permission/consent flows user-agents must implement.

The fact that it's a rare fingerprinting bit is exactly what makes it a dangerous fingerprinting bit; for the users in the category it's enormously identifying.

It's not, though? These users are being identified only when their devices are connected and powered on (rare, if they're not actually doing XR browsing where you _want_ this info to be leaked). The moment they turn off or disconnect their device, they are back to being a regular user fingerprinting-wise. It's not much of a fingerprinting vector if for an affected user it only shows up a fraction of the time.

[pes10k]

I don't think any web specification goes as far as to normatively dictate precisely what permission/consent flows user-agents must implement

There is a blurry, undefined line here about how much UX is mandated by a spec, but either way, thats not my suggestion here. My suggestion is to build mandatory protections into the spec (which is very common in specs), and then give non-normative recommendations to websites / adopters on how they can build pleasant experiences w/in the confines of those “table-stakes” protections.

It's not, though? These users are being identified only when their devices are connected and powered on (rare, if they're not actually doing XR browsing where you want this info to be leaked). The moment they turn off or disconnect their device, they are back to being a regular user fingerprinting-wise. It's not much of a fingerprinting vector if for an affected user it only shows up a fraction of the time.

This is not the case. A high fidelity fingerprinting signal is valueable, even if its temporary, since the temp-in-time fingerprinting is often how cookie syncing is performed. If the fingerprint is highly identifying, even temporarily, it becomes the common key to link long term 1p storage across 1p-origins.

I’m happy to go into more detail on how fingerprinting is insidious on the web, and the long range of ways its used to harm people on the web, if it would help explain why these two bits in the WebXR spec are of such concern, though a call would likely be a better forum for that than me writing a novel here :)

On Aug 28, 2020, at 11:17 AM, Manish Goregaokar [e-mail] wrote:

Non-normative text is useful and helpful for guiding implementations, doing so is terrific and if I can be helpful here please let me know. But it doesn’t solve the problem. The normative / mandatory parts of the spec / functionality need to be privacy-preserving by default.

I don't think any web specification goes as far as to normatively dictate precisely what permission/consent flows user-agents must implement.

The fact that it's a rare fingerprinting bit is exactly what makes it a dangerous fingerprinting bit; for the users in the category it's enormously identifying.

It's not, though? These users are being identified only when their devices are connected and powered on (rare, if they're not actually doing XR browsing where you want this info to be leaked). The moment they turn off or disconnect their device, they are back to being a regular user fingerprinting-wise. It's not much of a fingerprinting vector if for an affected user it only shows up a fraction of the time.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Manishearth]

/agenda

Would you be able to attend the next immersive-web meeting (Tuesday at 12PM PST)? #immersive-web on IRC, someone can send you a link for joining the meeting

[Yonet]

@pes10k if you would like to attend the next meeting, feel free to sign in to #immersive-web on IRC on Tuesday or email chairs for meeting link: [email protected].

[Manishearth]

cc @avadacatavra who should also probably join

[pes10k]

Sure, i'd be happy to attend. Which Tuesday is this meeting? Or is it every Tuesday, and so the next meeting is Sept 8, 2020, at 12 PST?

Either way, I'd be very glad to talk with you all, whichever Tuesday it is :)

[Manishearth]

Every Tuesday, though this specific item is on the agenda for Sept 8

[pes10k]

Okie dokie, I can join from 12-12:30 PDT on Sept 8, 2020 if that is likely to be enough time

[Manishearth]

Should be

[Yonet]

@pes10k meeting is tomorrow. You can find the meeting agenda and instructions here.
Join IRC: irc.w3.org:6667 #immersive-web and ping me or anyone else for the link to video meeting.

[Manishearth]

My concrete proposal from the meeting:

We change the spec to require permissions prompts only for cases where there is actually an additional fingerprinting bit (brandon had some good wording about this). However, we also explicitly call out that it is okay for UAs to silently reject the prompt with a random delay (random is important!) when the result of isSessionSupported() is going to be "no". So the only people who see a prompt are those who are on desktop browsers, _and_ have a tethered, powered-on XR device attached, and we can pretty safely expect that such people will be okay with and expect such prompts.

At the moment the only browser this effects is Chrome Desktop so I'd definitely like to hear @mounirlamouri's thoughts on this.

[nbutko]

I have concerns about adding random delays toisSessionSupported() => no. One of the goals mentioned in the meeting was to preflight the fetch of assets which may be differentiated in one use case versus another. Adding a random delay that is on the order of seconds could degrade the user experience in this case by increasing the time at which assets that are appropriate to a page are loaded.

[mounirlamouri]

I've no concerns with the spec recommending that the UAs are mindful of the exposed entropy but there are so many cases (headsets, phone AR, desktop VR) with so many solutions (per-origin prompt, global state, info bubble, etc.) that having the spec mandating a specific flow would be unrealistic. It will just lead to browsers not implementing what the spec suggests.

[Manishearth]

@mounirlamouri to be clear I do not want to mandate any flow, rather we mandate that in the case of UAs where there actually is a fingerprinting bit here, the UA must use some form of permissions flow to mask the bit without the user consent. The randomized rejection flow is an example of one that might be sufficient for Chromium Desktop, but is not the only option.