I know that's the final destination, but I didn't see that listed in the requirements page linked above. Any proof of this affecting the current implementation?
The attestation will include a unique ID of the phone, so that if you get banned you have to keep buying new phones and keep paying money to Google. Google won't stop this because it makes them money.
And the official Google OS just won't feature remote-control software.
Bluetooth is generally used to prove that the two devices are co-located, which makes it more complex to do your proposed kind of deployment at-scale. Bespoke solutions could perhaps work around for some smaller number of devices, this QR code layer by itself isn't intended to stop 100% of workarounds.
These passkey QR codes don't need to use Web Bluetooth API, because they utilize the WebAuthn API. The website itself isn't given access to the bluetooth, the task is handed off to the browser, which as a native application, can access bluetooth and abstracts the bluetooth away.
The app that scans the code talks to the TPM in your phone to prove that your phone is running an unmodified Google OS.
So openclaw or whatever future software will run or control unmodified google os devices.
I know that's the final destination, but I didn't see that listed in the requirements page linked above. Any proof of this affecting the current implementation?
Which would be meaningful if phones weren't remotely controllable.
So the net effect is every AI agent will also have and connect to a physical phone.
The attestation will include a unique ID of the phone, so that if you get banned you have to keep buying new phones and keep paying money to Google. Google won't stop this because it makes them money.
And the official Google OS just won't feature remote-control software.
2 replies →
One can expect it will be tied to a government ID, at which point they ban you from the internet if you disobey them.
... which is why you'll get locked out if you happen to visit an unusual number of sites in a day.
Bluetooth is generally used to prove that the two devices are co-located, which makes it more complex to do your proposed kind of deployment at-scale. Bespoke solutions could perhaps work around for some smaller number of devices, this QR code layer by itself isn't intended to stop 100% of workarounds.
No browser supports Bluetooth.
These passkey QR codes don't need to use Web Bluetooth API, because they utilize the WebAuthn API. The website itself isn't given access to the bluetooth, the task is handed off to the browser, which as a native application, can access bluetooth and abstracts the bluetooth away.
1 reply →
Chrome does...
3 replies →