I wasn't aware of these changes, but these are good changes because the apps that would benefit from a location-based BT-actived notification probably aren't going to be used often, so I might go several months between hitting certain places and in that time a point update will probably have caused me to reboot my phone.
IIRC Apple has changed the way iBeacon works with one of the recent iOS point updates. It's no longer necessary for a user to open the app to enable communication with an appropriate Beacon. Simply having it resident on your phone is all that's required. Yes you read that right. The user can intentionally close the app absolutely and completely yet it will still interface with iBeacons, pushing notifications to your lockscreen anyway. Developers and advertisers will appreciate the new functionality.
Interesting. I would imagine it is user configurable, otherwise I could see that as being rather distracting at times when it is not wanted.
I wasn't aware of these changes, but these are good changes because the apps that would benefit from a location-based BT-actived notification probably aren't going to be used often, so I might go several months between hitting certain places and in that time a point update will probably have caused me to reboot my phone.
mstone: Interesting. I would imagine it is user configurable, otherwise I could see that as being rather distracting at times when it is not wanted.
No kidding!
Gatorguy: Configurable i suppose by turning off “location permission” under settings, turning Bluetooth off altogether, or deleting your offending app entirely.
I already disable "location permission", but yes, if there is no system-wide "Disable iBeacons" setting, this will lead me to turn off bluetooth altogether as well. Read on before dismissing this as overkill. Your 3rd option is relevant.
If individual apps trigger iBeacons just by being installed, not running, and the only option to "disable" them is to delete them, how will people deal with this when this type of location tracking digs its way into widely-used, non-geo specific apps like Facebook? What if it gets built into Apple's apps, like Safari or Mail? You can't delete Apple's core apps at all!
At the end of the day, there needs to be a global Disable function for iBeacons. I hope Apple does do this, and I think they probably will. Why? Because the more widely iBeacons are used, the more likely that centralized services will attempt to take advantage of them. This has happened with phone #s, UUIDs, pretty much anything that can be tied to an individual.
Think about how cookies are used. Initially their primary purpose was to allow persistent logins and preferences, with access being limited to a single company or web site. Doesn't seem like a bad thing. However, today, while that part still exists, go look through your cookies and see how many of them are centralized through marketing and profiling companies. And every site that has a Facebook "Like" button is tracking your web travels whether you click on the button or not -- because web developers include 3rd party code on their pages without giving it a second thought.
I don't see how marketing and personal profiling companies are not going to latch onto this and provide tools and libraries for app developers that will allow this fine location data to be aggregated centrally, with super-fine-grained location data for each individual. At that point it only takes one retailer to tie a single purchase to your real-world identity, put that in the system, now you're identified with all iBeacons anywhere in the world that use said libraries. Your physical location will be tracked with extremely fine granularity and you can't even shut it off because it apparently continues to run when you've closed your apps. With enough traction, it would not be surprising to eventually see marketing companies providing and installing iBeacons everywhere "on behalf of the brick and mortars" and managing them centrally.
I'd love to hear Dick weigh in on this, because while I think the technology is very cool, and I do see some potentially neat things that could come from it, I can't see how this kind of centralization won't happen.
This is just one slice of the overriding problem of not being in control of your digital devices, your data, tracking of your physical location (and therefore, for some people, safety), etc.
[quote name="Blah64" url="/t/179025/virgin-atlantic-unveils-new-airport-terminal-experience-powered-by-apples-ibeacon#post_2527041"]if there is no system-wide "Disable iBeacons" setting, this will lead me to turn off bluetooth altogether as well. Read on before dismissing this as overkill.[/QUOTE]
I did read your whole post but it doesn't make any sense to me. You appear to be attributing the iBeacon nodes as having control over the messages you receive. This is no different than any other 802.15 signal your device can "hear" and yet ignores, or any other location service you've enabled on your device. There is absolutely no reason to believe that your device will be picking up and sending that information to every app which will then send you messages from every BT device it encounters.
In fact, the only issue I see isn't with your apps — as this has never been a problem with iOS despite years of location services being available to apps — but rather with [I]fake[/I] iBeacon nodes using the UUID of another node to spoof a legitimate iBeacon node. For example, you're at a football game where the stadium has iBeacon nodes around. You're getting the proper information as you have the stadium's app installed and the requisite settings enabled, you then leave to go to your car in the parking lot across the street, but as you're walking over you get an iBeacon from the stadium's app that you love letting you know that the bar right in front of you is having a 2 for 1 specials and free nachos with proof of ticket stub. That could be a problem which is why I hope iBeacon 2.0 will also use a hash to verify the authenticity of the iBeacon node but so far I haven't seen anything like that.
In fact, the only issue I see isn't with your apps — as this has never been a problem with iOS despite years of location services being available to apps — but rather with fake iBeacon nodes using the UUID of another node to spoof a legitimate iBeacon node.
I did read your whole post but it doesn't make any sense to me. You appear to be attributing the iBeacon nodes as having control over the messages you receive. This is no different than any other 802.15 signal your device can "hear" and yet ignores, or any other location service you've enabled on your device. There is absolutely no reason to believe that your device will be picking up and sending that information to every app which will then send you messages from every BT device it encounters.
I think you're missing my point. Or it's possible I'm missing yours.
Control is within the apps, right? So given the landscape at the moment, that means location data is specific app-by-app, and (in theory, sort of) you can control what data on your device that a given app has access to. So it doesn't sound too bad.
However, just like with web apps, I see an extremely likely (almost inevitable) scenario where 3rd parties provide libraries to app developers that centralize the data gathering. Just like 3rd parties today provide countless javascript snippets that web developers plaster all throughout their web site code which gets executed on each and every visitor's device every time they visit.
It started happening with device UUIDs and Apple was able to more or less shut that down. How can a similar scenario with iBeacons be prevented?
Quote:
In fact, the only issue I see isn't with your apps — as this has never been a problem with iOS despite years of location services being available to apps — but rather with fake iBeacon nodes using the UUID of another node to spoof a legitimate iBeacon node. For example, you're at a football game where the stadium has iBeacon nodes around. You're getting the proper information as you have the stadium's app installed and the requisite settings enabled, you then leave to go to your car in the parking lot across the street, but as you're walking over you get an iBeacon from the stadium's app that you love letting you know that the bar right in front of you is having a 2 for 1 specials and free nachos with proof of ticket stub. That could be a problem which is why I hope iBeacon 2.0 will also use a hash to verify the authenticity of the iBeacon node but so far I haven't seen anything like that.
I agree this could be a huge problem. Unlike the above, though, I see this as something that's potentially fixable by Apple, perhaps as you suggested, with some kind of hash.
I think you're missing my point. Or it's possible I'm missing yours.
Control is within the apps, right? So given the landscape at the moment, that means location data is specific app-by-app, and (in theory, sort of) you can control what data on your device that a given app has access to. So it doesn't sound too bad.
However, just like with web apps, I see an extremely likely (almost inevitable) scenario where 3rd parties provide libraries to app developers that centralize the data gathering. Just like 3rd parties today provide countless javascript snippets that web developers plaster all throughout their web site code which gets executed on each and every visitor's device every time they visit.
It started happening with device UUIDs and Apple was able to more or less shut that down. How can a similar scenario with iBeacons be prevented?
I'm still not sure I'm following your train of thought. If you want to give an app access to your GPS location then the app knows where you are already and they can pass that data back to the server which can then sell it to others. They can even package that data with user account info, if that is something you supplied them, so if you're worried about any location being send anywhere then you should already have location data disabled for all worrisome apps. This means that iBeacons simply won't work for those apps. If anything iBeacons are less intrusive because there needs to be an iBeacon within range for that data to be sent from the system to the app that has that node's UUID listed, but with the current system you're not likely to be escaping your device being tracked by GPS, WiFi and cell towers.
I agree this could be a huge problem. Unlike the above, though, I see this as something that's potentially fixable by Apple, perhaps as you suggested, with some kind of hash.
Wooooaaah there! I presented a scenario but this in no way is a problem right now, much less a huge one.
Originally Posted by SolipsismX I'm still not sure I'm following your train of thought. If you want to give an app access to your GPS location then the app knows where you are already and they can pass that data back to the server which can then sell it to others. They can even package that data with user account info, if that is something you supplied them, so if you're worried about any location being send anywhere then you should already have location data disabled for all worrisome apps. This means that iBeacons simply won't work for those apps. If anything iBeacons are less intrusive because there needs to be an iBeacon within range for that data to be sent from the system to the app that has that node's UUID listed, but with the current system you're not likely to be escaping your device being tracked by GPS, WiFi and cell towers.
Wooooaaah there! I presented a scenario but this in no way is a problem right now, much less a huge one.
On the first point, you're right, it's a sub-case of a bigger problem. I already disable GPS access for all apps, that's an easy no-brainer. I'd prefer to not have to completely disable bluetooth as well, or diligently monitor the setting all the time, as I do play the occasional bluetooth-networked game.
When you say that disabling GPS "means that iBeacons simply won't work for those apps", are you quite sure about that? iBeacons operate independently of GPS, no? Your app pings a Beacon, but it already knows *exactly* where it is, that's kind of the point. Additionally, the fact that this location-grabbing happens even when an app isn't open is quite troubling. If someone really wants to utilize an app with a meaningful location-based service, then I can understand why some people think that's a reasonable tradeoff for exchanging your current location at that moment. I would never purposely do that, but I can understand the appeal in certain situations. However, having it on all the time, whether you are using the app or not, with no obvious way to disable it (like simply quitting the app) doesn't seem reasonable at all.
If disabling GPS/location also disables beacon use entirely, then that's basically what I was asking for earlier, and I'll totally buy what you're saying. I don't use anything related to location, and I'm not going to upgrade to iOS 7 as long as I can help it (which means until I get a new device), so I don't have a direct line to look at some of this stuff.
On your second point, I agreed that it could be a problem, not that it is a problem now. But step back away from this issue for a moment to consider general human (and therefore business) behavior. If there's a way to "cheat" a system for profit, there's no doubt it will eventually happen. History shows us that nearly every day. If iBeacons become the "next big thing", and they're in use everywhere, then a problem like this would certainly be huge. Hell, it wouldn't just be the local shops, but people walking around with portable beacons, you name it. I just don't think it's that a big a concern, because I think this type of problem has a technical solution, as you already mentioned.
If iBeacons become the "next big thing", and they're in use everywhere, then a problem like this would certainly be huge. Hell, it wouldn't just be the local shops, but people walking around with portable beacons, you name it.
I still don't think you're understanding how they work. So what if people have portable beacons, those beacon IDs still need to match up to an installed app that has told the iOS system to let it know about specific IDs? What scenario would this be a huge problem? You're more likely to get SMS spam which can be sent to anyone, anywhere, from anywhere in the world, than be the mercy of someone being near a specific spoofed beacon that also has user with an app installed that is listening for that UUID that also has location services installed and BT enabled.
Spot on. The one thing I would add is that the 'end action' when a phone is woken by an iBeacon does not have to be a lock screen notification. For example when someone is in range of an iBeacon transmitter then the device wakes up and sends a signal back to the iBeacon which (if using the correct firmware and management layer) can then send information back to the app owner, which could then alert a personalised sales associate to approach the person. Now that of course does sound big brother, but if done correctly it's not going to feel different to have a sales associate approach you as you enter a store, just with a little more information about the customer habits and needs.
I still don't think you're understanding how they work. So what if people have portable beacons, those beacon IDs still need to match up to an installed app that has told the iOS system to let it know about specific IDs? What scenario would this be a huge problem? You're more likely to get SMS spam which can be sent to anyone, anywhere, from anywhere in the world, than be the mercy of someone being near a specific spoofed beacon that also has user with an app installed that is listening for that UUID that also has location services installed and BT enabled.
You described the problem earlier as not having "a hash to verify the authenticity of the iBeacon node". So when you say now that "those beacon IDs still need to match up to an installed app" it seems like you're contradicting yourself. (?)
Regardless, this is just a distraction -- I agreed with you that this could be a problem, and we're quibbling about silly stuff like whether it might be "huge" or not. Since I think it's a fixable problem, I think the debate is moot.
More relevantly, do you understand the main point I was making above in the previous post?
In today's world, personal data is valuable. It's more valuable when it's collected from as many sources as possible and individualized. Market forces therefore naturally tend to favor $olution$ that can be pushed out to as many apps or web sites or physical locations as possible with a single unified data collection mechanism. This has proven to be true on the web, and $billions have been made by companies that have managed to get 10s of millions of web sites to embed data-collection code snippets on their web sites. I simply see a similar scenario where this can play out with mobile apps and beacons.
To make up an example based on the above: as soon as your favorite Stadium app starts using Google's new whizbang beacon library (they'll figure out some way to make it seem useful or profitable to the app developers), Google now has access to a boatload even more super fine-grained location data. If this happens across all your apps 24/7 regardless of whether or not you have any of them open, that's a problem. It's actually rather google-esque because it makes it clumsy to not spill 24/7 location data if you'd like to make occasional use of it, but not track your whereabouts everywhere (thanks to the aggregation tools). Maybe it eventually even gets married to offline purchase data by using merchants' locations and timestamps, but let's stop here because I think that's far enough for now.
It's possible there's still something I'm missing, but nothing I've read from either you or Dick (previous thread) has given me any reason to think something like this won't happen. I think most of what I'm talking about can indeed already happen with existing location-based apps, and I expect it will continue to get much worse over time. The aspect that's most troublesome to me about the beacons is that apps are still able to collect data when they're supposedly not running. That's misleading, which is something Google does every day, but I don't like to see Apple enabling it. As if you can't already tell, I think it's vile to physically track people around 24/7 like animals; beacons aren't hugely new in this regard, they're just another piece of straw tossed onto the personal data-collection camel's back.
You described the problem earlier as <i>not</i> having "a hash to verify the authenticity of the iBeacon node". So when you say now that "those beacon IDs still need to match up to an installed app" it seems like you're contradicting yourself. (?)
I really don't know why this is such a hard concept. This has got to be one of the simplest, most straightforward packagings of already available technology I've ever seen from Apple.
1) Your device will notice all iBeacons it comes in contact with providing you have BT enabled.
2) Your device will have a list of iBeacon node IDs that it was given by each app. If matched and if location services are enabled the system will alert the app that you are in range of that particular node and its payload.
(if the app is off you need to have background app refresh enabled for it to start the app)
3) The app then does what it does with the data from the node.
That's it in a nut shell.
The mention of the hash was a future option from Apple to allow the addition of an MD5, SHA-1 or similar cryptographic hash function that can be stored for each node, and the app (or a connected server) so it can be verified.
The aspect that's most troublesome to me about the beacons is that apps are still able to collect data when they're <i>supposedly</i> not running.
How will they be able to collect data when they are not running? They are not running! But let's say they are, if you have given any app access to your GPS location, contacts, internet, whatever then you're giving it a lot more access than some very short range BT node that might randomly encounter… but you still need to have installed, location services enabled, and for those node IDs sent to the system to monitor. How are all these checks from the system and the very small range of a BT signal a huge issue, especially when compared to giving an app your actual location, contacts, calendar, and access back to its servers?
Now will Macy's record when you are in contact with their store's nodes? I can't imagine why they wouldn't, but you still will have to have installed their app, location services and app background refresh enabled, BT on, and be next to each node before any of the chain reaction happens to give the Macy's app the small package of data from the node.
Worrying about iBeacons is like worrying about the calories of an extra piece of broccoli but then completely ignoring that you had cheesecake for dessert.
iBeacons simply won't work for those apps", are you quite sure about that? iBeacons operate independently of GPS, no? Your app pings a Beacon, but it already knows *exactly* where it is, that's kind of the point.
Well what's a beacon? The most well-known one is a lighthouse. It shines it's light for all or none to. You can be somewhere with a iBeacon in place and without the specific app you won't know. It's not force fed into your device. You actively choose if you want to receive the transmission, like adjusting a dial on a radio. The transmission is only one way.
I was addressing the negative part of his post. These people slam things even before seeing or trying them. That's what I'm talking about.
He wasn't slamming the technology, only its initial use for spamming people based on location. While that usage is perhaps inevitable, it would probably be wise at the onset to focus on providing something of value to the user (the check-in example qualifies.)
I don't know whether it's the same tech or not, but Apple's Passbook has pretty much the same functionality, at least in terms of showing you an electronic version of your boarding pass when you enter the terminal, which is all I really want anyway.
The one flaw I found, at least with Delta, is that if your seat is changed, the electronic boarding pass on the iPhone doesn't update.
The last thing I want when walking through a terminal and carrying luggage is to be plagued with incessant notices about bogus discounts. On the other hand, if they want to let me into the Club for free, that would be fine.
Passbook works with wifi, I believe. iBeacon can provide very precise location data down to a few feet, which opens up the possibilities.
Passbook works with wifi, I believe. iBeacon can provide very precise location data down to a few feet, which opens up the possibilities.
I thought PassBook works with your general location based on a geofence. WiFi can be involved with getting your location but I don't recall reading about any aspect of PassBook that can register, say, a WiFi SSID or BSSID at a Starbucks and then put your pass in the Notification Center.
Originally Posted by SolipsismX I really don't know why this is such a hard concept. ..... The mention of the hash was a future option from Apple to allow the addition of an MD5, SHA-1 or similar cryptographic hash function that can be stored for each node, and the app (or a connected server) so it can be verified.
I fully understand the general scheme of how beacons work (though that was actually a very good description on your part, perhaps the most concise that I've read, but I'm also not a fan of any location-tracking tech, so I admittedly have not read a lot).
What I'm talking about here that you're apparently not getting, is that afaik there is no protection against impersonating Beacon IDs. That's what I think/thought you were referring to with the hash, so I'm just echoing your initial concern. Unless I'm mistaken about this, it could be a problem in the future. As for the potential magnitude of the problems this might cause, maybe "huge" is a stretch if we're only thinking about the obvious right now, but any time there is potential for abuse, miscreants will find a way to do so to the maximum extent possible. And as I stated earlier, I think it's fixable, so I'm not super concerned about it.
If there are protections against impersonating beacons, I'm happy to be corrected. Otherwise, I guess we can just disagree on the magnitude of potential for abuse.
Quote:
How will they be able to collect data when they are not running? They are not running!
This part you're wrong about. I said:
Quote:
The aspect that's most troublesome to me about the beacons is that apps are still able to collect data when they're supposedly not running.
Not the emphasized "supposedly". When someone hard-quits an app and it's not active, nor in their tray, the expectation is that app is not running. Like full-stop not running. Unless someone is a techie (tiny minority), they are not going to understand that these apps are actually still active in the background even when they're not in the tray. That's not cool, no matter how minor an issue it might be, and it kind of reeks of google-esque behavior, even though I don't think Apple is doing it for the same kind of reasons google and facebook and their ilk pulls their crap.
in which the author clearly considers this as an "improvement". Most of the developers appear to be excited (devs love new tech), but the last couple comments (not me! I just saw this article) have the same problems with it that I do.
Quote:
But let's say they are, if you have given any app access to your GPS location, contacts, internet, whatever then you're giving it a lot more access than some very short range BT node that might randomly encounter… but you still need to have installed, location services enabled, and for those node IDs sent to the system to monitor. How are all these checks from the system and the very small range of a BT signal a huge issue, especially when compared to giving an app your actual location, contacts, calendar, and access back to its servers?
Now will Macy's record when you are in contact with their store's nodes? I can't imagine why they wouldn't, but you still will have to have installed their app, location services and app background refresh enabled, BT on, and be next to each node before any of the chain reaction happens to give the Macy's app the small package of data from the node.
Worrying about iBeacons is like worrying about the calories of an extra piece of broccoli but then completely ignoring that you had cheesecake for dessert.
You're mischaracterizing my concerns. I'm VERY concerned about all the other stuff. Far more so than beacons. And no, I am in no way hypocritical, I walk the walk, and it poses more and more challenges as things like location-tracking get embedded into our culture. I do not, and never have, enabled any kind of location services, and in fact take great care in other areas as well, which I won't get into here. A 24/7/365/lifetime surveillance society is where we are headed, and it's pretty disgusting. That's a MUCH bigger problem than silly beacons, but that doesn't mean small issues around the edges shouldn't be addressed. As a Beacon developer stated on that blog:
Quote:
I think this is bad idea. Any app the needs to run in background should be granted that right on the “Background App Refresh” menu. Allowing individual Apps to do so opens security and power consumption issues the average user many not be aware of, especially when they might rightfully assume such privileges are granted on the background app refresh menu. There is no reason to hide this, we need to be forthright with our users!
Ultimately, this is the problem I have. Apple needs to be absolutely forthright and transparent about how stuff works, and a simple setting should be exposed to give users control. A user might choose to install something to give it a quick try, say a Starbucks beacon-enabled app. They decide they don't want to use it now, but maybe they'll keep it around to check it out in the future, so they quit the app and forget about it among the hundreds of apps on page 10 of their phone. AFAIK, with GPS-tracking, when you quit the app, you're no longer providing location data to the app, but with beacons, the app will continue to track this person's Starbucks visits forever. Is this a minor thing? Maybe in the scope of all the other tracking crap that's happening, but it doesn't mean it's wrong to point it out and push for a change.
<div class="quote-container" data-huddler-embed="/t/179025/virgin-atlantic-unveils-new-airport-terminal-experience-powered-by-apples-ibeacon#post_2527284" data-huddler-embed-placeholder="false"><span>Quote:</span><div class="quote-block">Originally Posted by <strong>SolipsismX</strong> <a href="/t/179025/virgin-atlantic-unveils-new-airport-terminal-experience-powered-by-apples-ibeacon#post_2527284"><img src="/img/forum/go_quote.gif" class="inlineimg" alt="View Post"/></a>
I really don't know why this is such a hard concept.
.....
The mention of the hash was a future option from Apple to allow the addition of an MD5, SHA-1 or similar cryptographic hash function that can be stored for each node, and the app (or a connected server) so it can be verified.<br /></div></div>
I fully understand the general scheme of how beacons work (though that was actually a very good description on your part, perhaps the most concise that I've read, but I'm also not a fan of <i>any</i> location-tracking tech, so I admittedly have not read a lot).
What I'm talking about here that you're apparently not getting, is that <i>afaik</i> there is no protection against impersonating Beacon IDs. That's what I think/thought you were referring to with the hash, so I'm just echoing your initial concern. Unless I'm mistaken about this, it could be a problem in the future. As for the potential magnitude of the problems this might cause, maybe "huge" is a stretch if we're only thinking about the obvious right now, but any time there is potential for abuse, miscreants will find a way to do so to the maximum extent possible. And as I stated earlier, I think it's fixable, so I'm not super concerned about it.
If there are protections against impersonating beacons, I'm happy to be corrected. Otherwise, I guess we can just disagree on the magnitude of potential for abuse.
<div class="quote-container" data-huddler-embed="/t/179025/virgin-atlantic-unveils-new-airport-terminal-experience-powered-by-apples-ibeacon#post_2527284" data-huddler-embed-placeholder="false"><span>Quote:</span><div class="quote-block">How will they be able to collect data when they are not running? They are not running! </div></div>
This part you're wrong about. I said:
<div class="quote-container" data-huddler-embed="/t/179025/virgin-atlantic-unveils-new-airport-terminal-experience-powered-by-apples-ibeacon#post_2527284" data-huddler-embed-placeholder="false"><span>Quote:</span><div class="quote-block">The aspect that's most troublesome to me about the beacons is that apps are still able to collect data when they're <i>supposedly</i> not running.</div></div>
Not the emphasized "supposedly". When someone hard-quits an app and it's not active, nor in their tray, the expectation is that app is not running. Like full-stop not running. Unless someone is a techie (tiny minority), they are not going to understand that these apps are actually still active in the background even when they're not in the tray. That's not cool, no matter how minor an issue it might be, and it kind of reeks of google-esque behavior, even though I don't think Apple is doing it for the same kind of reasons google and facebook and their ilk pulls their crap.
in which the author clearly considers this as an "improvement". Most of the developers appear to be excited (devs love new tech), but the last couple comments (not me! I just saw this article) have the same problems with it that I do.
<div class="quote-container" data-huddler-embed="/t/179025/virgin-atlantic-unveils-new-airport-terminal-experience-powered-by-apples-ibeacon#post_2527284" data-huddler-embed-placeholder="false"><span>Quote:</span><div class="quote-block">But let's say they are, if you have given any app access to your GPS location, contacts, internet, whatever then you're giving it a lot more access than some very short range BT node that might randomly encounter… but you still need to have installed, location services enabled, and for those node IDs sent to the system to monitor. How are all these checks from the system and the very small range of a BT signal a huge issue, especially when compared to giving an app your actual location, contacts, calendar, and access back to its servers?<br />
<br />
Now will Macy's record when you are in contact with their store's nodes? I can't imagine why they wouldn't, but you still will have to have installed their app, location services and app background refresh enabled, BT on, and be next to each node before any of the chain reaction happens to give the Macy's app the small package of data from the node.<br />
<br />
Worrying about iBeacons is like worrying about the calories of an extra piece of broccoli but then completely ignoring that you had cheesecake for dessert.</div></div>
You're mischaracterizing my concerns. I'm <i>VERY</i> concerned about all the other stuff. Far more so than beacons. And no, I am in no way hypocritical, I walk the walk, and it poses more and more challenges as things like location-tracking get embedded into our culture. I do not, and never have, enabled any kind of location services, and in fact take great care in other areas as well, which I won't get into here. A 24/7/365/lifetime surveillance society is where we are headed, and it's pretty disgusting. That's a MUCH bigger problem than silly beacons, but that doesn't mean small issues around the edges shouldn't be addressed. As a <i>Beacon developer</i> stated on that blog:
<div class="quote-container" ><span>Quote:</span><div class="quote-block">
I think this is bad idea. Any app the needs to run in background should be granted that right on the “Background App Refresh” menu. Allowing individual Apps to do so opens security and power consumption issues the average user many not be aware of, especially when they might rightfully assume such privileges are granted on the background app refresh menu. There is no reason to hide this, we need to be forthright with our users!</div></div>
Ultimately, this is the problem I have. Apple needs to be absolutely forthright and transparent about how stuff works, and a simple setting should be exposed to give users control. A user might choose to install something to give it a quick try, say a Starbucks beacon-enabled app. They decide they don't want to use it now, but maybe they'll keep it around to check it out in the future, so they quit the app and forget about it among the hundreds of apps on page 10 of their phone. AFAIK, with GPS-tracking, when you quit the app, you're no longer providing location data to the app, but with beacons, the app will continue to track this person's Starbucks visits forever. Is this a minor thing? Maybe in the scope of all the other tracking crap that's happening, but it doesn't mean it's wrong to point it out and push for a change.
(My apologies but on iPhone so can't reply to your thorough response with the same completeness.)
1) Don't Apple's guidelines only allow for 10 iBeacon IDs to be saved per app? I don't know if you can swap out beacon IDs as easily as you can with geofence locations, like when choosing your PassBook pass stores, so I don't know how hard of a rule that would be if an app could get your GPS-based location and then swap out new beacon IDs for iOS to look for.
2) The way it reads to me is that the system (iOS) looks for the beacon IDs, just as it has always done with any BT radio signals, and only when an ID matches an ID given to it by an app that also has location services enabled is that beacon ID data ever passed to the app, so only then will the system wake the app if there is a match. It will not mean all beacons will be sent to all apps with location services enabled.
3) I wouldn't mind seeing Enable buttons for the various types of location services for each app in iOS 8 Settings.
4) I'm a firm believer is asking questions and voicing your concerns (which is why I appreciate your comments despite being frustrated with them at the same time. ). My suggestion to you is to email Tim Cook with your concerns, your wishes for more clarity, and perhaps some of the ideas presented in this thread. He may or may not answer you but I am pretty sure it will be read.
Comments
IIRC Apple has changed the way iBeacon works with one of the recent iOS point updates. It's no longer necessary for a user to open the app to enable communication with an appropriate Beacon. Simply having it resident on your phone is all that's required. Yes you read that right. The user can intentionally close the app absolutely and completely yet it will still interface with iBeacons, pushing notifications to your lockscreen anyway. Developers and advertisers will appreciate the new functionality.
Interesting. I would imagine it is user configurable, otherwise I could see that as being rather distracting at times when it is not wanted.
Configurable i suppose by turning off “location permission” under settings, turning Bluetooth off altogether, or deleting your offending app entirely.
I wasn't aware of these changes, but these are good changes because the apps that would benefit from a location-based BT-actived notification probably aren't going to be used often, so I might go several months between hitting certain places and in that time a point update will probably have caused me to reboot my phone.
No kidding!
I already disable "location permission", but yes, if there is no system-wide "Disable iBeacons" setting, this will lead me to turn off bluetooth altogether as well. Read on before dismissing this as overkill. Your 3rd option is relevant.
If individual apps trigger iBeacons just by being installed, not running, and the only option to "disable" them is to delete them, how will people deal with this when this type of location tracking digs its way into widely-used, non-geo specific apps like Facebook? What if it gets built into Apple's apps, like Safari or Mail? You can't delete Apple's core apps at all!
At the end of the day, there needs to be a global Disable function for iBeacons. I hope Apple does do this, and I think they probably will. Why? Because the more widely iBeacons are used, the more likely that centralized services will attempt to take advantage of them. This has happened with phone #s, UUIDs, pretty much anything that can be tied to an individual.
Think about how cookies are used. Initially their primary purpose was to allow persistent logins and preferences, with access being limited to a single company or web site. Doesn't seem like a bad thing. However, today, while that part still exists, go look through your cookies and see how many of them are centralized through marketing and profiling companies. And every site that has a Facebook "Like" button is tracking your web travels whether you click on the button or not -- because web developers include 3rd party code on their pages without giving it a second thought.
I don't see how marketing and personal profiling companies are not going to latch onto this and provide tools and libraries for app developers that will allow this fine location data to be aggregated centrally, with super-fine-grained location data for each individual. At that point it only takes one retailer to tie a single purchase to your real-world identity, put that in the system, now you're identified with all iBeacons anywhere in the world that use said libraries. Your physical location will be tracked with extremely fine granularity and you can't even shut it off because it apparently continues to run when you've closed your apps. With enough traction, it would not be surprising to eventually see marketing companies providing and installing iBeacons everywhere "on behalf of the brick and mortars" and managing them centrally.
I'd love to hear Dick weigh in on this, because while I think the technology is very cool, and I do see some potentially neat things that could come from it, I can't see how this kind of centralization won't happen.
This is just one slice of the overriding problem of not being in control of your digital devices, your data, tracking of your physical location (and therefore, for some people, safety), etc.
I did read your whole post but it doesn't make any sense to me. You appear to be attributing the iBeacon nodes as having control over the messages you receive. This is no different than any other 802.15 signal your device can "hear" and yet ignores, or any other location service you've enabled on your device. There is absolutely no reason to believe that your device will be picking up and sending that information to every app which will then send you messages from every BT device it encounters.
In fact, the only issue I see isn't with your apps — as this has never been a problem with iOS despite years of location services being available to apps — but rather with [I]fake[/I] iBeacon nodes using the UUID of another node to spoof a legitimate iBeacon node. For example, you're at a football game where the stadium has iBeacon nodes around. You're getting the proper information as you have the stadium's app installed and the requisite settings enabled, you then leave to go to your car in the parking lot across the street, but as you're walking over you get an iBeacon from the stadium's app that you love letting you know that the bar right in front of you is having a 2 for 1 specials and free nachos with proof of ticket stub. That could be a problem which is why I hope iBeacon 2.0 will also use a hash to verify the authenticity of the iBeacon node but so far I haven't seen anything like that.
I did read your whole post but it doesn't make any sense to me. You appear to be attributing the iBeacon nodes as having control over the messages you receive. This is no different than any other 802.15 signal your device can "hear" and yet ignores, or any other location service you've enabled on your device. There is absolutely no reason to believe that your device will be picking up and sending that information to every app which will then send you messages from every BT device it encounters.
I think you're missing my point. Or it's possible I'm missing yours.
Control is within the apps, right? So given the landscape at the moment, that means location data is specific app-by-app, and (in theory, sort of) you can control what data on your device that a given app has access to. So it doesn't sound too bad.
However, just like with web apps, I see an extremely likely (almost inevitable) scenario where 3rd parties provide libraries to app developers that centralize the data gathering. Just like 3rd parties today provide countless javascript snippets that web developers plaster all throughout their web site code which gets executed on each and every visitor's device every time they visit.
It started happening with device UUIDs and Apple was able to more or less shut that down. How can a similar scenario with iBeacons be prevented?
I agree this could be a huge problem. Unlike the above, though, I see this as something that's potentially fixable by Apple, perhaps as you suggested, with some kind of hash.
I'm still not sure I'm following your train of thought. If you want to give an app access to your GPS location then the app knows where you are already and they can pass that data back to the server which can then sell it to others. They can even package that data with user account info, if that is something you supplied them, so if you're worried about any location being send anywhere then you should already have location data disabled for all worrisome apps. This means that iBeacons simply won't work for those apps. If anything iBeacons are less intrusive because there needs to be an iBeacon within range for that data to be sent from the system to the app that has that node's UUID listed, but with the current system you're not likely to be escaping your device being tracked by GPS, WiFi and cell towers.
Wooooaaah there! I presented a scenario but this in no way is a problem right now, much less a huge one.
I'm still not sure I'm following your train of thought. If you want to give an app access to your GPS location then the app knows where you are already and they can pass that data back to the server which can then sell it to others. They can even package that data with user account info, if that is something you supplied them, so if you're worried about any location being send anywhere then you should already have location data disabled for all worrisome apps. This means that iBeacons simply won't work for those apps. If anything iBeacons are less intrusive because there needs to be an iBeacon within range for that data to be sent from the system to the app that has that node's UUID listed, but with the current system you're not likely to be escaping your device being tracked by GPS, WiFi and cell towers.
Wooooaaah there! I presented a scenario but this in no way is a problem right now, much less a huge one.
On the first point, you're right, it's a sub-case of a bigger problem. I already disable GPS access for all apps, that's an easy no-brainer. I'd prefer to not have to completely disable bluetooth as well, or diligently monitor the setting all the time, as I do play the occasional bluetooth-networked game.
When you say that disabling GPS "means that iBeacons simply won't work for those apps", are you quite sure about that? iBeacons operate independently of GPS, no? Your app pings a Beacon, but it already knows *exactly* where it is, that's kind of the point. Additionally, the fact that this location-grabbing happens even when an app isn't open is quite troubling. If someone really wants to utilize an app with a meaningful location-based service, then I can understand why some people think that's a reasonable tradeoff for exchanging your current location at that moment. I would never purposely do that, but I can understand the appeal in certain situations. However, having it on all the time, whether you are using the app or not, with no obvious way to disable it (like simply quitting the app) doesn't seem reasonable at all.
If disabling GPS/location also disables beacon use entirely, then that's basically what I was asking for earlier, and I'll totally buy what you're saying. I don't use anything related to location, and I'm not going to upgrade to iOS 7 as long as I can help it (which means until I get a new device), so I don't have a direct line to look at some of this stuff.
On your second point, I agreed that it could be a problem, not that it is a problem now. But step back away from this issue for a moment to consider general human (and therefore business) behavior. If there's a way to "cheat" a system for profit, there's no doubt it will eventually happen. History shows us that nearly every day. If iBeacons become the "next big thing", and they're in use everywhere, then a problem like this would certainly be huge. Hell, it wouldn't just be the local shops, but people walking around with portable beacons, you name it. I just don't think it's that a big a concern, because I think this type of problem has a technical solution, as you already mentioned.
I still don't think you're understanding how they work. So what if people have portable beacons, those beacon IDs still need to match up to an installed app that has told the iOS system to let it know about specific IDs? What scenario would this be a huge problem? You're more likely to get SMS spam which can be sent to anyone, anywhere, from anywhere in the world, than be the mercy of someone being near a specific spoofed beacon that also has user with an app installed that is listening for that UUID that also has location services installed and BT enabled.
Spot on. The one thing I would add is that the 'end action' when a phone is woken by an iBeacon does not have to be a lock screen notification. For example when someone is in range of an iBeacon transmitter then the device wakes up and sends a signal back to the iBeacon which (if using the correct firmware and management layer) can then send information back to the app owner, which could then alert a personalised sales associate to approach the person. Now that of course does sound big brother, but if done correctly it's not going to feel different to have a sales associate approach you as you enter a store, just with a little more information about the customer habits and needs.
I still don't think you're understanding how they work. So what if people have portable beacons, those beacon IDs still need to match up to an installed app that has told the iOS system to let it know about specific IDs? What scenario would this be a huge problem? You're more likely to get SMS spam which can be sent to anyone, anywhere, from anywhere in the world, than be the mercy of someone being near a specific spoofed beacon that also has user with an app installed that is listening for that UUID that also has location services installed and BT enabled.
You described the problem earlier as not having "a hash to verify the authenticity of the iBeacon node". So when you say now that "those beacon IDs still need to match up to an installed app" it seems like you're contradicting yourself. (?)
Regardless, this is just a distraction -- I agreed with you that this could be a problem, and we're quibbling about silly stuff like whether it might be "huge" or not. Since I think it's a fixable problem, I think the debate is moot.
More relevantly, do you understand the main point I was making above in the previous post?
In today's world, personal data is valuable. It's more valuable when it's collected from as many sources as possible and individualized. Market forces therefore naturally tend to favor $olution$ that can be pushed out to as many apps or web sites or physical locations as possible with a single unified data collection mechanism. This has proven to be true on the web, and $billions have been made by companies that have managed to get 10s of millions of web sites to embed data-collection code snippets on their web sites. I simply see a similar scenario where this can play out with mobile apps and beacons.
To make up an example based on the above: as soon as your favorite Stadium app starts using Google's new whizbang beacon library (they'll figure out some way to make it seem useful or profitable to the app developers), Google now has access to a boatload even more super fine-grained location data. If this happens across all your apps 24/7 regardless of whether or not you have any of them open, that's a problem. It's actually rather google-esque because it makes it clumsy to not spill 24/7 location data if you'd like to make occasional use of it, but not track your whereabouts everywhere (thanks to the aggregation tools). Maybe it eventually even gets married to offline purchase data by using merchants' locations and timestamps, but let's stop here because I think that's far enough for now.
It's possible there's still something I'm missing, but nothing I've read from either you or Dick (previous thread) has given me any reason to think something like this won't happen. I think most of what I'm talking about can indeed already happen with existing location-based apps, and I expect it will continue to get much worse over time. The aspect that's most troublesome to me about the beacons is that apps are still able to collect data when they're supposedly not running. That's misleading, which is something Google does every day, but I don't like to see Apple enabling it. As if you can't already tell, I think it's vile to physically track people around 24/7 like animals; beacons aren't hugely new in this regard, they're just another piece of straw tossed onto the personal data-collection camel's back.
I really don't know why this is such a hard concept. This has got to be one of the simplest, most straightforward packagings of already available technology I've ever seen from Apple.
1) Your device will notice all iBeacons it comes in contact with providing you have BT enabled.
2) Your device will have a list of iBeacon node IDs that it was given by each app. If matched and if location services are enabled the system will alert the app that you are in range of that particular node and its payload.
(if the app is off you need to have background app refresh enabled for it to start the app)
3) The app then does what it does with the data from the node.
That's it in a nut shell.
The mention of the hash was a future option from Apple to allow the addition of an MD5, SHA-1 or similar cryptographic hash function that can be stored for each node, and the app (or a connected server) so it can be verified.
How will they be able to collect data when they are not running? They are not running! But let's say they are, if you have given any app access to your GPS location, contacts, internet, whatever then you're giving it a lot more access than some very short range BT node that might randomly encounter… but you still need to have installed, location services enabled, and for those node IDs sent to the system to monitor. How are all these checks from the system and the very small range of a BT signal a huge issue, especially when compared to giving an app your actual location, contacts, calendar, and access back to its servers?
Now will Macy's record when you are in contact with their store's nodes? I can't imagine why they wouldn't, but you still will have to have installed their app, location services and app background refresh enabled, BT on, and be next to each node before any of the chain reaction happens to give the Macy's app the small package of data from the node.
Worrying about iBeacons is like worrying about the calories of an extra piece of broccoli but then completely ignoring that you had cheesecake for dessert.
Well what's a beacon? The most well-known one is a lighthouse. It shines it's light for all or none to. You can be somewhere with a iBeacon in place and without the specific app you won't know. It's not force fed into your device. You actively choose if you want to receive the transmission, like adjusting a dial on a radio. The transmission is only one way.
I was addressing the negative part of his post. These people slam things even before seeing or trying them. That's what I'm talking about.
He wasn't slamming the technology, only its initial use for spamming people based on location. While that usage is perhaps inevitable, it would probably be wise at the onset to focus on providing something of value to the user (the check-in example qualifies.)
I don't know whether it's the same tech or not, but Apple's Passbook has pretty much the same functionality, at least in terms of showing you an electronic version of your boarding pass when you enter the terminal, which is all I really want anyway.
The one flaw I found, at least with Delta, is that if your seat is changed, the electronic boarding pass on the iPhone doesn't update.
The last thing I want when walking through a terminal and carrying luggage is to be plagued with incessant notices about bogus discounts. On the other hand, if they want to let me into the Club for free, that would be fine.
Passbook works with wifi, I believe. iBeacon can provide very precise location data down to a few feet, which opens up the possibilities.
I thought PassBook works with your general location based on a geofence. WiFi can be involved with getting your location but I don't recall reading about any aspect of PassBook that can register, say, a WiFi SSID or BSSID at a Starbucks and then put your pass in the Notification Center.
I really don't know why this is such a hard concept.
.....
The mention of the hash was a future option from Apple to allow the addition of an MD5, SHA-1 or similar cryptographic hash function that can be stored for each node, and the app (or a connected server) so it can be verified.
I fully understand the general scheme of how beacons work (though that was actually a very good description on your part, perhaps the most concise that I've read, but I'm also not a fan of any location-tracking tech, so I admittedly have not read a lot).
What I'm talking about here that you're apparently not getting, is that afaik there is no protection against impersonating Beacon IDs. That's what I think/thought you were referring to with the hash, so I'm just echoing your initial concern. Unless I'm mistaken about this, it could be a problem in the future. As for the potential magnitude of the problems this might cause, maybe "huge" is a stretch if we're only thinking about the obvious right now, but any time there is potential for abuse, miscreants will find a way to do so to the maximum extent possible. And as I stated earlier, I think it's fixable, so I'm not super concerned about it.
If there are protections against impersonating beacons, I'm happy to be corrected. Otherwise, I guess we can just disagree on the magnitude of potential for abuse.
This part you're wrong about. I said:
Not the emphasized "supposedly". When someone hard-quits an app and it's not active, nor in their tray, the expectation is that app is not running. Like full-stop not running. Unless someone is a techie (tiny minority), they are not going to understand that these apps are actually still active in the background even when they're not in the tray. That's not cool, no matter how minor an issue it might be, and it kind of reeks of google-esque behavior, even though I don't think Apple is doing it for the same kind of reasons google and facebook and their ilk pulls their crap.
Gatorguy was kind enough to point out this conversation:
http://beekn.net/2014/03/apple-ios-7-1-launches-major-ibeacon-improvement/
in which the author clearly considers this as an "improvement". Most of the developers appear to be excited (devs love new tech), but the last couple comments (not me! I just saw this article) have the same problems with it that I do.
Now will Macy's record when you are in contact with their store's nodes? I can't imagine why they wouldn't, but you still will have to have installed their app, location services and app background refresh enabled, BT on, and be next to each node before any of the chain reaction happens to give the Macy's app the small package of data from the node.
Worrying about iBeacons is like worrying about the calories of an extra piece of broccoli but then completely ignoring that you had cheesecake for dessert.
You're mischaracterizing my concerns. I'm VERY concerned about all the other stuff. Far more so than beacons. And no, I am in no way hypocritical, I walk the walk, and it poses more and more challenges as things like location-tracking get embedded into our culture. I do not, and never have, enabled any kind of location services, and in fact take great care in other areas as well, which I won't get into here. A 24/7/365/lifetime surveillance society is where we are headed, and it's pretty disgusting. That's a MUCH bigger problem than silly beacons, but that doesn't mean small issues around the edges shouldn't be addressed. As a Beacon developer stated on that blog:
I think this is bad idea. Any app the needs to run in background should be granted that right on the “Background App Refresh” menu. Allowing individual Apps to do so opens security and power consumption issues the average user many not be aware of, especially when they might rightfully assume such privileges are granted on the background app refresh menu. There is no reason to hide this, we need to be forthright with our users!
Ultimately, this is the problem I have. Apple needs to be absolutely forthright and transparent about how stuff works, and a simple setting should be exposed to give users control. A user might choose to install something to give it a quick try, say a Starbucks beacon-enabled app. They decide they don't want to use it now, but maybe they'll keep it around to check it out in the future, so they quit the app and forget about it among the hundreds of apps on page 10 of their phone. AFAIK, with GPS-tracking, when you quit the app, you're no longer providing location data to the app, but with beacons, the app will continue to track this person's Starbucks visits forever. Is this a minor thing? Maybe in the scope of all the other tracking crap that's happening, but it doesn't mean it's wrong to point it out and push for a change.
(My apologies but on iPhone so can't reply to your thorough response with the same completeness.)
1) Don't Apple's guidelines only allow for 10 iBeacon IDs to be saved per app? I don't know if you can swap out beacon IDs as easily as you can with geofence locations, like when choosing your PassBook pass stores, so I don't know how hard of a rule that would be if an app could get your GPS-based location and then swap out new beacon IDs for iOS to look for.
2) The way it reads to me is that the system (iOS) looks for the beacon IDs, just as it has always done with any BT radio signals, and only when an ID matches an ID given to it by an app that also has location services enabled is that beacon ID data ever passed to the app, so only then will the system wake the app if there is a match. It will not mean all beacons will be sent to all apps with location services enabled.
3) I wouldn't mind seeing Enable buttons for the various types of location services for each app in iOS 8 Settings.
4) I'm a firm believer is asking questions and voicing your concerns (which is why I appreciate your comments despite being frustrated with them at the same time.