They used to support TOTP directly, but removed it in favor of their proprietary mobile apps. It's still TOTP under the hood though, just requires a couple API calls to "activate" it.
Though they recommend their own app, id.me directly supports any standard compatible authenticator app. I use it with Google Authenticator TOTP. It's also SOTA for creating and accepting passkeys on ChromeOS as well as Android. Probably Apple, too!
Other built-in available MFA methods include: security key; NFC mobile security key; Push Notifications (id.me app); text message or phone call; and passkeys.
I don't know if it's an A/B test, but they no longer allow adding new TOTP authenticators for my family member's account. Existing setups continue to work fine.
That's why I had to do the hackery of having the script pretend to be the mobile app to set that up.
This release also fixes runtime.findnull() to be compatible with MTE on Android ([1] and [2]). This was the only thing preventing MTE from being enabled for apps that use gomobile on MTE-compatible Android OS's like GrapheneOS.
It looks like all the old files are still hosted on the server. You can just replace the version number in the download links with one of the tags from https://git.zx2c4.com/wireguard-windows.
This article isn't about the installation of regular apps. The "sideloading" it's referring to is the option to use the "adb sideload <OTA file>" command when booted into recovery mode to install OS updates. The functionality being removed is being able to install a proper OEM-signed OS update from a local file.
It's probably worth pointing out that the online process is one time and it installs a token that permanently lets the setting be toggled offline afterwards. This persists across factory resets and flashing any OS.
NFC payments via Google Wallet running on my Pixel Watch 3 connected to a phone running GrapheneOS works just fine. I use this regularly. (It doesn't require Google Wallet to be installed on the phone.)
At least one of my cards required Google Play Services to have the location permission when initially adding the card though.
I wrote https://github.com/chenxiaolong/MSD for exactly that. It's a small wrapper around the Linux kernel's mass storage emulation support (CONFIG_USB_CONFIGFS_MASS_STORAGE). It can emulate a read-only optical drive, a readable disk, or a writable disk.
It is compatible with both older devices that configure USB via init scripts and newer devices that use Android's USB gadget HAL, but it does require Android 11+.
For me, I begrudgingly use GitHub for my personal projects because GitHub Actions is free. If I move elsewhere, I'll have to stop providing precompiled binaries for OS's that I can't cross-compile for from Linux (eg. macOS).
I would not provide precompiled binaries for other systems if I could not even test it properly (nor know all of the details for programming for those other systems), whether or not it uses GitHub Actions.
If you do use GitHub Actions for compiling, then it might be better for the actual implementation of compiling to be in a separate file (which can also be used outside of GitHub) and the GitHub Actions file will only specify the conditions to trigger that separate file.
(I do use GitHub Actions, but only to automatically assign issues to myself (which is not something that is necessary in order to work the software that is being made by your repository). If it is moved to (or copied or mirrored to) something else that cannot use GitHub Actions files, it might have another way to auto-assign issues or make it unnecessary to do s.)
Yeah, my GitHub Actions workflows don't do much more than `cargo build --release && cargo test --release`. I don't use any of the fancy features that would lock me in.
It's really just running the tests on Mac that I rely on it for. For Windows and Android, I can (and regularly do) use wine and qemu-user-static to run the tests on Linux. My project (a computationally heavy CLI tool) is simple though. It doesn't need much from the OS besides memory allocation, thread spawning, and opening a user-specified file.
If this is enforced via Play Protect, then the whole mechanism can likely be disabled with:
adb shell settings put global package_verifier_user_consent -1
This does not require root access and prevents Android from invoking Play Protect in the first place. (This is what AOSP's own test suite does, along with other test suites in eg. Unreal Engine, etc.)
I personally won't be doing this verification for my open-source apps. I have no interest in any kind of business relationship with anyone just to publish an .apk. If that limits those who can install it to people who disable Play Protect globally, then oh well.
I really hope this ends up being possible! Play Protect seems to jump up every so often and try to scare me into turning it on. Very annoying. I've wanted to disable Play Protect permanently, but never did the query to learn how, so thank you.
There could of course be side effects in the future when this restriction is rolled out, as in your device's Play Integrity status could be affected and your banking app/phone wallet might not let you perform app-based payments from that device.
I'm curious how the check is implemented in Google Play Services. If it's based on the package manager's initiatingPackageName field, it should be trivial to bypass on rooted devices (or unrooted custom ROMs).
They used to support TOTP directly, but removed it in favor of their proprietary mobile apps. It's still TOTP under the hood though, just requires a couple API calls to "activate" it.