- From: Piotr Bialecki <notifications@github.com>
- Date: Thu, 16 Sep 2021 09:47:41 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/652/921064901@github.com>
> People who are bystanders don't have a way to opt out of being part of this scenario. The fact that you can be logged into a service and through the use of this API expose other people to privacy threats is problematic. What do you mean here by "logged into a service"? I think I'm missing something - is there a threat model document that I could read up on? All of the concerns that you are listing above are already possible via `getUserMedia()` if we assume a malicious website (camera web app / QR code scanner web app don't have to stop accessing the camera after it took a picture / scanned the QR code, and the API is accessible w/o additional software download). After a bad actor convinces the user to grant the permission for camera, the user and the bystanders are already potentially compromised - that's not something specific to WebXR's raw camera access. In a way, WebXR offers slightly more protection that is built into the behavior of the API (on smartphones, the camera is by default displayed to the user as well, and the field of view is more limited compared to what the camera could actually capture). In the end, any API that allows the sites to access camera pixels can be used maliciously, and I'm worried that crippling this particular API will not increase users' security. On the contrary, if it turns out WebXR doesn't have an answer ready for the use cases that require access to pixels, app developers could fall back to relying on `gUM()` + SLAM algorithms to enable AR scenarios (we know of one existing product that does it now and is blocked to switch to WebXR due to the lack of a camera access API), in which case the UA is entirely out of the loop (while also potentially sacrificing battery life and the quality of experience, if not done right). The only outcome is that the barrier of entry to offer full AR experience while silently capturing the camera feed may be higher than with WebXR’s API, but there can always be a site that advertises itself as awesome-ar-experience.example.com, asks for camera permissions, fakes an attempt to enter AR, & immediately shows an "oops, something went wrong" message, but keeps recording the camera feed (or even falls back to WebXR for AR experience w/o raw camera access, but will start capturing the camera feed as soon as the user leaves the session). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/652#issuecomment-921064901
Received on Thursday, 16 September 2021 16:47:53 UTC