- From: Daniel Micay via GitHub <sysbot+gh@w3.org>
- Date: Thu, 20 Apr 2023 13:32:52 +0000
- To: public-webauthn@w3.org
There **are** some UX issues with some parts of FIDO2 via the sandboxed Google Play compatibility layer since it **does** use privileged access on the stock OS for various parts of it and our mapping of that to regular unprivileged APIs is not currently 100% perfect. This mostly seems to impact Google Play's own usage of FIDO2 and isn't an issue with other apps. It has an annoyance for NFC where the OS will still scan it and open a URL so it can require multiple attempts to get it working. It's essentially 100% perfect for most other things including installing and updating apps with the Play Store, Play Asset Delivery, Play Feature Delivery, dynamite modules and other things but the parts that have to do with hardware like FIDO2 are harder since they took shortcuts other apps can't take and it's more niche than the basic functionality, especially since there are multiple kinds of it (phone as security key including for other devices, USB, Bluetooth, NFC, passkeys). Similarly, Android Auto can't be used since we haven't figured out a way to make that work via unprivileged APIs and so far we've avoided the shortcut of providing a toggle to give certain privileged access as we had to temporarily do for using their eSIM activation app which is another thing where it's very unfortunate it isn't in AOSP despite eSIM quickly replacing physical SIMs. There is a partial open source implementation of eSIM but it's not quite a full replacement and implements an older standard version, so while we plan on including it, we can't get rid of the Google eSIM activation integration yet. Feels a lot like the situation with FIDO2 although there's more of an excuse for eSIM because it has been largely Pixel specific for the time being. Android has mainline modules so them being able to ship updates across devices where they don't provide the OS hasn't been usable as an excuse for years. There is simply not reason beyond lack of prioritization or business interests for many of these things to still not be open source. Also consider that the Titan M sources were supposed to be open sourced, and it's strange that Pixels moved to using Trusty OS for TEE / secure core and some variant of Open Titan for the Titan M2 without open sourcing it, just as it is with the boot chain where Qualcomm publishes EDK2 sources but Google did not for the Snapdragon devices and now similarly does not for current Pixels. Android unfortunately has a different approach to open source than Chromium, and it leaks into other things. Chromebooks are more open source than Pixels, for example, and Android Chromium is less openly developed + has things missing in the upstream (Chromium) code. It's all frustrating. It has impacted our willingness to contribute upstream **including not reporting all privacy and security vulnerabilities we find anymore**. To let that sink in, billions of Android devices are not receiving patches for security issues we know about **because we do not feel we are being treated fairly** especially when we contributed a fair bit to upstream projects (and tried to contribute more than we succeeded in landing too). -- GitHub Notification of comment by thestinger Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1819#issuecomment-1516338759 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 20 April 2023 13:32:54 UTC