As a user of Chrome on iOS, I absolutely do not want this. Is there a way to turn this "feature" totally off? I've been looking through the links and didn't see a mention of it.
@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.
One thing I've wanted to do, but is total impractical.. I want to put beacons on trees around the city that will provide information about the tree, for example what type of tree it is, when it was planted, etc. Of course, I could just put little signs on them and it would be available to more people. But it sounds cool.
Every tree maintained by the City of Melbourne (Victoria, Australia) has "an email address" (in the mainstream press it's been "one email per tree"; in reality it's a single mailbox the CoM staffers respond to).
Why not just a QR code? I've seen some institutions already QR code their campus trees for their own tracking purposes. Info about the tree does not change much over short timescales.
Tanuj from the Estimote team here. If you're curious about some of the under-the-hood mechanics between BLE beacons, Eddystone, and the Physical Web check out developer docs http://developer.estimote.com/eddystone/
Does the indoor location feature work on time of flight, RSSI or something else? If it's time of flight, how do you convince the OS to give you accurate enough time measurements?
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?
Does chrome put in anything to protect against developers spamming notification center? I can just imagine putting a couple hundred of these throughout time square and making everyone really hate chrome for ios.
@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.
Think of it as of seeing URL printed on the wall (or hidden in QR-code), just easier to use if you actually want to.
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.
Beacon's won't be able to spam notifications. That's why they're only broadcasting URLs. If you have the app installed (I can't remember what it is) you'll be able to open it to view nearby beacons. The user has to initiate the search for beacons.
On Android it does, and assuming that it uses the Push Notification API via WebServiceWorker, the user should be able to globally turn the notifications off (as they wouldn't be device-specific).
One privacy issue I'm seeing is that it seems like the users device still needs to make a request to get the metadata? So the retailer could use fingerprinting of requests to track people around. I wasn't entirely clear on where the metadata comes from so I could have this wrong.
How many users actually have BT on? I never have it on, and i don't anyone else who has it on unless they pair it with their car, and even then most of them prefer the USB pairing since it charges the phone.
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).
I leave it on all the time. I don't want to be bothered flipping switches when I want to use a feature. My phone is paired with my car, and I frequently use Airdrop to share photos and videos.
> How many users actually have BT on? I never have it on
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.
Anybody with a smart watch I'd guess. I pretty much only ever switch Bluetooth off if my phone's battery is looking like it won't make it until my next opportunity to charge (only ever when I'm away from home/work - usually a long weekend motorcycle trip.)
This is really nice, will it also be available for Android and if so what Android versions? Right now you have to install Google's physical web app thingy on Android to get beacons so it's kinda clunky and annoying. I know Eddystone was supposed to change a lot of that but I didn't see any mention of what Android versions it will work on. Is it only 5.1 and beyond or are they going to update 4.4, 5.0, etc?
Estimote founder here.
Few days ago Google released their new, open beacon format - eddystone and today just updated Chrome for iOS that can scan for beacons broadcasting Eddystone URLs.
You can read more on our blog how to start broadcasting URL using beacons and how to test it on Chrome for iOS.
I'll ask the uncomfortable question: How conscious are you of how this tech will be abused as a pure advertising medium and how annoying and ugly this potentially will be for users? And how concerned are you by that? Popups were useful once upon a time.
OT: the scrolling hijack for the animation in the middle of your site is really annoying.
[+] [-] RexRollman|10 years ago|reply
[+] [-] jimiasty|10 years ago|reply
@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.
[+] [-] rsuelzer|10 years ago|reply
[+] [-] RossP|10 years ago|reply
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...
[+] [-] dogma1138|10 years ago|reply
[+] [-] flgb|10 years ago|reply
[+] [-] lvs|10 years ago|reply
[+] [-] stevesunderland|10 years ago|reply
[+] [-] lvs|10 years ago|reply
[+] [-] callahad|10 years ago|reply
[+] [-] tanujparikh|10 years ago|reply
[+] [-] michaelt|10 years ago|reply
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?
[+] [-] tashoecraft|10 years ago|reply
[+] [-] jimiasty|10 years ago|reply
@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.
[+] [-] aflinik|10 years ago|reply
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.
[+] [-] quest88|10 years ago|reply
[+] [-] nevi-me|10 years ago|reply
[+] [-] rdancer|10 years ago|reply
[+] [-] aflinik|10 years ago|reply
[+] [-] dantiberian|10 years ago|reply
[+] [-] chrisfosterelli|10 years ago|reply
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...
[+] [-] jimiasty|10 years ago|reply
[+] [-] steckerbrett|10 years ago|reply
[+] [-] dogma1138|10 years ago|reply
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?
[+] [-] tjohns|10 years ago|reply
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).
[+] [-] bradleyland|10 years ago|reply
[+] [-] pilingual|10 years ago|reply
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.
[+] [-] bigiain|10 years ago|reply
[+] [-] fowl2|10 years ago|reply
[+] [-] tdicola|10 years ago|reply
[+] [-] jimiasty|10 years ago|reply
[+] [-] scrollaway|10 years ago|reply
OT: the scrolling hijack for the animation in the middle of your site is really annoying.
[+] [-] unknown|10 years ago|reply
[deleted]