New Chrome for iOS scans for beacons broadcasting URLs(blog.estimote.com)
blog.estimote.com
New Chrome for iOS scans for beacons broadcasting URLs
http://blog.estimote.com/post/124778667895/beacons-chrome-ios
57 comments
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.
This is Jakub, founder of Estimote here.
@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.
@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.
Thank you.
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).
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...
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...
Nice - Sydney Uni have a similar thing with an iOS app: https://itunes.apple.com/au/app/campus-flora/id918408102
I can't see anything there' but I _think_the app code is open source and they're encouraging reuse.
I can't see anything there' but I _think_the app code is open source and they're encouraging reuse.
There are many cities with tree plaques modern ones have qcode / nfc, some even have a text number so you can donate to "adopt" that tree.
Hah! another opportunity to use this link:
http://picturesofpeoplescanningqrcodes.tumblr.com/
http://picturesofpeoplescanningqrcodes.tumblr.com/
Not quite what you are asking for but Melbourne has a digital strategy for their trees and is in the process of rolling out a sensor network also ... http://www.melbourne.vic.gov.au/Sustainability/UrbanForest/P...
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.
this is a pretty cool startup idea, mate.
Well, this is precisely what no user wants or needs. Slow clap to everyone involved.
Are you sure? I'd quite like to walk up to my bus stop and have my phone provide me a link to a stop-specific schedule, among other uses.
But Nextbus already knows what stop you're at using AGPS. What's the point of the beacon? Perhaps you can come up with a use for beacons, but you need to deal with the fact that users don't need or want another intrusive advertising channel.
What if I don't have Nextbus installed, or have location services disabled?
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?
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?
Really reaching here. Nextbus is a web app. Location is in my experience always good enough without a sat lock. You don't need "to spin up GPS" to get your answer.
But Nextbus data is not available everywhere - and installing beacons on bus stops to broadcast URL addresses is fairly easy and low cost.
The infrastructure you'd need for your beacons is the same as Nextbus (i.e. trackers on public transport and a city data feed), but Nextbus requires no distributed/deployed devices. Therefore, rolling out a beacon approach must have more overhead than something like Nextbus. You really can't come up with a reason why these beacons are better for that use case.
Hell, just put up a QR code at the bus stop. What could be cheaper than that?
Hell, just put up a QR code at the bus stop. What could be cheaper than that?
Beacons are much more precise than GPS. You can setup more than 1.5m accuracy and they can have built-in sensors (e.g. motion sensor). So the signal is broadcasted (URL opened) when you touch something for example.
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).
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).
That's not exactly true. Try adding an app that listens for the iBeacon's specific GUID (but doesn't do anything else, like background app processing when it gets the notification) and then be in a area with lots of beacons with that GUID. You'll notice a difference in battery life without a doubt. That said, if nothing is listening for that GUID, then there's zero impact to battery life.
What if I'm in a country without Nextbus?
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?
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?
It works by RSSI [1], and I believe you can calibrate it with your antenna/case design. Not to mention any attenuation by the phone's antenna or your hand/body.
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."
[1] http://developer.estimote.com/
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."
[1] http://developer.estimote.com/
Beacons use the newer Bluetooth 4.0/'low energy' specification so they're not like old Bluetooth devices that are constantly connected. It's up to each beacon to decide how often it broadcasts, how powerfully, etc. Check out BLE SoC's like the Nordic nRF51822 for examples of hardware that could turn into a beacon without a ton of work.
We're doing sensor-fusion trying to use as much data as possible coming from different sources, so besides RSSI from beacons there's also accelerometer, magnetometer, etc. Lots of non-trivial maths to combine that into a robust model, but results are getting more and more incredible. :)
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.
Jakub here, founder of Estimote.
@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.
@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.
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).
We're yet to see how Google implements this on Android. Currently it's iOS only, and the "Today" Chrome widget only, no push notifications at all.
Also, see the above comment from jimiasty about Google ranking/filtering the URLs before it shows them in the widget.
Also, see the above comment from jimiasty about Google ranking/filtering the URLs before it shows them in the widget.
Notifications are application specific, so that would prevent Chrome from prompting notifications completely, not a solution...
A better solution is to turn BT off :)
A better solution is to turn BT off :)
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.
> information about users won’t be saved until they click a link, so the beacon owner will not know anyone was nearby until they visit the website
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...
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...
The beacons them selves have proximity sensing built in, that at least how the "ibeacons" works...
https://en.wikipedia.org/wiki/Bluetooth_low_energy#Proximity...
https://en.wikipedia.org/wiki/Bluetooth_low_energy#Proximity...
Proximity detection is done by the receiver. An iBeacon is just a dumb broadcaster.
It's not the device to fetch metadata. There is an additional service from Google to prevent that - see my comment here: https://news.ycombinator.com/item?id=9940474
Probably easier just to sniff their various MAC addresses.
iOS devices randomise the MAC when scanning to avoid this.
It actually doesn't in most cases, last I heard:
http://blog.airtightnetworks.com/ios8-mac-randomization-anal...
http://blog.airtightnetworks.com/ios8-mac-randomization-anal...
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?
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?
Honest question: How is Bluetooth insecure?
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).
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.
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.)
Every iOS user get's Bluetooth turned back on every update...
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.
OT: the scrolling hijack for the animation in the middle of your site is really annoying.
Hey there,
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.
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.
[deleted]