Purpose of Estimote Cloud in Android

BLE Beacons
1

Hello.
I’m new to the Beacons topic. I’ve received the dev kit and did some tests. What is troubling me is the Secure UUID and mac address. On the android SDK I have access to mac address that does not change during the rotation of UUIDs when secure UUID is changing. That means that I can build offline application based only on mac addresses without the need to communicate to the cloud. That also worries me, because the others can do exactly the same thing with my own beacons :frowning: .

Am I missing something ??

2

Thanks for bringing this up, it’s an important topic.

Short version: Secure UUID was designed around iBeacon and iOS SDK, and doesn’t provide the same level of security for our Android SDK. We’re already working on a secure solution for Android, and will announce it in the near future.

To understand why things are this way, I encourage you to read the long version :wink:

Long version:

We designed Secure UUID a year ago for iBeacon and our iOS SDK—at that time, Android was still far behind iOS when it comes to beacons: there was no Eddystone; Android 5.0 barely came out, introducing a new, better Bluetooth Low Energy API; and with 4.x, rotating MAC addresses was known to crash the Bluetooth stack.

Now, fast-forward to today, the beacon scene looks different: large-scale beacon deployments are starting to pop up, lots of them utilizing Secure UUID. More importantly, it’s no longer iOS game—our customers start thinking about Android too. And so, we started hearing a lot of feedback about bringing Secure UUID support to our Android SDK, so that they can utilize their existing Secure UUID deployments to easily add beacons to their Android apps. A few days ago, we did just that—brought Secure UUID to our Android SDK.

Naturally, this doesn’t solve the “MAC address problem,” but it’s important to understand why—and simply, Secure UUID was designed around iBeacon (where there’s no MAC address), and we brought it to Android more to allow easy integration with existing, Secure UUID enabled deployments, than for strict security reasons.

Does it mean we don’t care about security on Android? Of course not! We’re a young and agile company, and try to be solving problems as they appear.

When customers started approaching us about first production iBeacon + iOS deployments two years ago, and expressing the security concerns, we came up with Secure UUID.

Then, more people started asking about Android, and we’ve been among the first to implement the Eddystone protocol from Google.

Then, we’ve heard that people want to use Android with their existing iBeacon + Secure UUID infrastructure, and we added Secure UUID compatibility.

Today, when many of our customers are interested in joint iBeacon + Eddystone deployments, to support iOS and Android equally well (and equally securely), we’re working on some really exciting things that we’ll announce in the near future.

3

Thank You for answer. I’m looking forward to see the upcoming changes :smile: