New Chrome for iOS scans for beacons broadcasting URLs
blog.estimote.com
blog.estimote.com
@RexRollman: it seems Google is experimenting with that at the moment and the feature is opt-in only, so no worry.
When you download the new Chrome for iOS you "have to" include Chrome into "Today widgets" section and also Enable "Physical Web Scanning" that will show you the list nearby URLs broadcasted by beacons.
As you can see there is still a lot of efforts there and you need to turn on initially.
Click a tree marker on the map near the top of the Melbourne Urban Forest website (http://melbourneurbanforestvisual.com.au/) and you can email your selected tree to find further information, etc. A bit more info is in this Broadsheet article: http://www.broadsheet.com.au/melbourne/entertainment/article...
I can't see anything there' but I _think_the app code is open source and they're encouraging reuse.
Or even if I have location enabled, what if Nexbus could figure out which stop you're at without having to spin up GPS, in turn saving battery?
Hell, just put up a QR code at the bus stop. What could be cheaper than that?
As you know beacons use Bluetooth Low Energy - it is different Bluetooth and really low-powered. Beacon can last many years on a single coin battery. It's also way more power efficient for the phone to scan for beacons that GPS regions. Beacons have almost no impact on phone's battery.
In addition it is important to remember that 80% of time people spend indoor when GPS doesn't work, so that technology might be useful for indoor applications (e.g. museums, airports, retail, etc).
The website claims 3 year beacon battery life - but bluetooth has a reputation for poor power performance. How often do the beacons broadcast, for how long, and at what power output?
Quote:
"Phones or other smart devices can pick up the beacon’s signal and estimate the distance by measuring received signal strength (RSSI). The closer you are to the beacon, the stronger the signal. Remember that the beacon is not broadcasting continuously—it’s blinking instead. The more frequent the blinks, the more reliable the signal detection."
A better solution is to turn BT off :)
Also, see the above comment from jimiasty about Google ranking/filtering the URLs before it shows them in the widget.
It's not spamming notification center. Whenever the beacon signal is heard the information about it is shown in Chrome widget, but you still have to manually go there to see it. If you ignore it and move away from the beacon it will simply disappear.
@tashoecraft: Google did here a really elegant design. URLs from beacons are not rendered in the browser directly (it's not the device that resolves URL or fetches description). There is a Google service based on Google Search doing that and then data are rendered in the browser.
We expect this is how Google is actually planning to prevent spam. Before they present anything in the browser for the user, they might filter that and/or rank, same way they do it with links in the search.
It sounds like the metadata is sourced from the bluetooth-broadcast, not via a separate request.
However, the specification itself[0] only has room for the URL and the telemetry data, so how they achieve this in practice is questionable.
[0] https://github.com/google/eddystone/blob/master/protocol-spe...
https://en.wikipedia.org/wiki/Bluetooth_low_energy#Proximity...
http://blog.airtightnetworks.com/ios8-mac-randomization-anal...
Also abusing an already insecure standard and pretty much stitching this onto it doesn't seem like that much of a good idea to me, I wonder what effect all that spam has on actual compliant devices....
The good thing is that it doesn't support URL's that are longer than 18 chars, and only supports 14 top tier TLD's so pretty much USA only.
The odd part is that all their examples seem to use shorthand url's provided by goo.gl, but the .gl TLD isn't supported by the standard, eh? who thought this through?
There are some specific insecure devices out there, and Bluetooth has some optional anonymous pairing modes, but my understanding was that the default pairing process provided a reasonable level of security for most applications.
Notwithstanding that, I thought Bluetooth LE beacons are broadcast-only, which avoids the pairing issue anyway.
And to answer your first question: I leave bluetooth on, both to pair with my car (USB connections don't give enough power to charge with GPS running, and don't provide live audio) and because it's a much lower power way of tethering my other devices to the Internet compared to WiFi tethering. Oh, and my smartwatch uses it too. As does a few other devices at home (BBQ thermometer, conference phone, headphones).
You are making arguments to support the past.
> Also abusing an already insecure standard
Bluetooth Smart (i.e. 4.0+/LE) supports AES128 encryption, though that is irrelevant here since we are talking about beacons, which are public.
> the .gl TLD isn't supported by the standard, eh? who thought this through?
It is supported. If you read the Eddystone documentation carefully, you'll see that the TLD bytes are merely convenient shortcuts. You can encode "thedrop.club" if you want.
OT: the scrolling hijack for the animation in the middle of your site is really annoying.
Wojtek from Estimote team here: actually, Google is approaching this very conciously when it comes to privacy and UX. You need to opt-in to see those URLs in notification center, then metadata is fetched so you know what you click, and still no tracking is possible until you actually click.
Also, they're iterating very fast with Physical Web, but it's still in experimentation phase. Physical Web for Chrome is big news, but keep in mind that Chrome on iOS has ~5% penetration.