The intention is that the client (whether that's the OS itself or an app as in the current Android proof-of-concept) visiting the broadcast URL will return specific metadata that will allow the user to know what the target content / action is, rather than content itself - https://github.com/google/physical-web/blob/master/documenta...
There is obviously some potential for data snooping and privacy issues, but if the experiment becomes a full standard then it will likely be fleshed out much more to avoid this issue.
Pulling metadata from a publicly broadcast (and therefore inspectable) URL still feels more transparent than the iBeacons implementation, which mediates all beacon interactivity through the "black box" of an app with unknown configuration (with regard to exactly which beacons it listens for - it could be a single UUID, or it could be all beacons) which could be phoning home with all kinds of data without the user knowing.
And if a vulnerability is found in the client's HTTP header parser or other part of the client?
What about these URLs recording client IP addresses and locations (based on the known beacon location)?
Is there no way to put everything in the beacon? Will users be prompted before their devices perform actions dictated by a third party? Will beacons be featured in future pwn2own contests?
There is obviously some potential for data snooping and privacy issues, but if the experiment becomes a full standard then it will likely be fleshed out much more to avoid this issue.
Pulling metadata from a publicly broadcast (and therefore inspectable) URL still feels more transparent than the iBeacons implementation, which mediates all beacon interactivity through the "black box" of an app with unknown configuration (with regard to exactly which beacons it listens for - it could be a single UUID, or it could be all beacons) which could be phoning home with all kinds of data without the user knowing.