[eddythompson80]

The camera isn't the part doing that verification. The google service serving that "reCAPTCHA" is what's doing that validation. Unless you're using a custom browser that is reporting a different domain to google than the one requesting the reCAPTCHA, google's service will know which domain is which.

[tardedmeme]

How does the verification app on your phone know what's in the URL bar on your desktop?

[ranger_danger]

The QR code/URL would be generated/requested by the javascript running on the website you're viewing, which knows what's in your address bar.

[tardedmeme]

It would be generated by some other website like Amazon. Because I own, say, Meta, I copy these Amazon-generated codes over to Meta, make people scan them on their phones to sign into Meta and then pass the solution back to Amazon so my bots can sign into Amazon.

[ranger_danger]

We don't yet know how the client side works, perhaps there will be a decompilation posted soon.

It's possible this scenario is acceptable to them because it means they can still tie your access to something that's easier to ban without requiring a full account login.

[tardedmeme]

They're tying my access to random users of a completely different service, and a different random user each time.

[ranger_danger]

What are you implying? That it will become ineffective due to that?

That's possible... and they might change their mind if so, we will see.

I feel like it's a similar issue to when scrapers pretend to be an allowed-origin webpage in order to abuse "public" API keys for web services.

They could also require the mobile device to interact with the requesting webpage in some manner, similar to mutual PIN/codes for Bluetooth/TV pairing these days. That way bulk sharing of the codes would still require active participation from the device that requested it in the first place, likely with a short time limit.