The app that scans the code talks to the TPM in your phone to prove that your phone is running an unmodified Google OS.
replySo openclaw or whatever future software will run or control unmodified google os devices.
replyI 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?
replyWhich would be meaningful if phones weren't remotely controllable.
replySo 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.
replyAnd the official Google OS just won't feature remote-control software.
There's also remote control hardware (a printer-like device can operate a touchscreen). But the first point stands, yes. Be it a phone or another hardware attestation device, they and Apple will be giving "I am human, let me participate in society" checkmarks out, directly or indirectly for money
replyOr keep stealing IMEI IDs. Now regular people will start getting banned from the internet because of bot activity. You would open your phone one day and see "You have been disconnected from society" and there will be nothing you can do.
replyOne can expect it will be tied to a government ID, at which point they ban you from the internet if you disobey them.
reply... which is why you'll get locked out if you happen to visit an unusual number of sites in a day.
replyBluetooth 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.
replyNo browser supports Bluetooth.
replyThese 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.
replyThat's passkey QR codes generated by the browser, it has nothing to do with random QR codes offered by websites.
replyChrome does...
replyThat's news to me https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetoo...
replyWebsites cannot use Bluetooth anywhere. The QR codes shown in the blog post are not passkey QR codes, which is likely what's confusing you.
Interestingly, only on desktop/Android and not iOS it seems.
replyChrome on iOS uses WebKit, so that makes sense.
reply(*I think in the EU, iOS Chrome can use Blink, but I am not sure if it actually does.)