A Rose by Any Other Name: Multi-tenancy with Secure

One of the deceptively simple elements of a beacon is that when you change something elementary about it, it can have large repercussions that go beyond the obvious. Just like you wouldn’t necessarily think of an oriental folding fan as a weapon, you might not realize what adding Secure to a beacon can do. So let’s talk about one of the big benefits that we saw while developing secure this year: multi-tenency.

What is multi-tenancy?


There are a number of applications for beacons that may require that more than one person have access to some part or all of the beacon owner’s infrastructure. An example: Proxama has talked a while back about how they’re beaconizing London’s taxi’s with our beacons. They’ll be sending push notification advertisements to taxi riders who can interact with them on their phones. Over time, they will have many different companies who have been given temporary permission to advertise to people who are riding in cabs in London. Like most things involving technology, this is not as simple as it sounds.

There are a number of ways to make this work, but there’s a common problem: once your advertiser’s campaign has ended, how do you make it so that they cannot message anyone who encounters one of your beacons any more? The usual solution is to serve as an arbitrage provider: the advertiser needs to include your SDK into their app and then any beacon that’s found is first processed by the arbitrage provider’s SDK before the phone can react to it. Only after then can the phone present a notification to the rider. This, of course takes time, consumes memory on the phone, and doesn’t protect the beacon owner (Proxama) from an instance where the advertiser who is renting the beacon infrastructure for a month noting all of the UUIDs of the beacons that their app interacts with and then continuing to message them after the advertising contract has ended. Theoretically, a few bad actors could end up causing the poor taxi cab rider to be flooded with multiple messages at once when he or she gets into the cab, which is a surefire way to make someone turn Bluetooth off so they quit getting spammed. But there’s a better way.

Secure Sharing with Secure


Instead of serving as an arbitrator, Proxama can leave the administrative work of their beacon infrastructure to Using Secure, they can simply share a limited number of the deshuffled values for their beacon fleet with their advertiser. 30 days’ worth, for example. On the 31st day (and the 32nd, and the 33rd, and so on), the beacon will shuffle its broadcast identifiers again, and the advertiser whose contract has ended with Proxama won’t be able to use the beacon infrastructure again until he or she renews his or her contract. Simple! Any already-recorded values for the beacons won’t work for the advertiser, because there are some 4 billion possible shuffled values for any beacon, so it’ll be a little over 10 million years before that beacon’s value wraps back around to the start. 😉
Multitenancy is definitely not an application that every client needs, but including our ~1Mb SDK and adding about 4kb of memory footprint to an app to enable secure sharing through Secure can solve a lot of headaches, and for very little effort. As I’ve already mentioned last week, our SDK saves you a minimum of $60,000 per platform you launch your app on if you need security, and it may be that Secure can save you even more than that.

Contact us