As part of the Thali project we are working on using BLE and Wi-Fi Direct to provide for local discovery. That is, the ability to discover who is around you using BLE/Bluetooth/Wi-Fi. This feature has enormous implications for people’s fundamental rights to privacy as well as personal security. So in this article I try to enumerate what rights I believe users of local presence software must have for such software to be considered ethical. I built these rights based on Kim Cameron’s Laws of Identity.
1 The Bill of Rights
Users have rights and as ethical engineers we have a moral obligation to support those rights. In the area of local discovery we can determine user’s rights based on Kim Cameron’s Laws of Identity. I review each of those laws below and explain how I believe they apply to local P2P discovery in Thali.
“Technical identity systems must only reveal information identifying a user with the user’s consent.”
- First Law
In practical terms I believe the first law means:
- An application MUST NOT make the User discoverable without the User’s explicit approval.
- Users MUST always be prominently notified by an application whenever the app has made the user’s device discoverable. When the app is in the foreground it MUST display a prominent UX element as long as discoverability is activate. When the app is the background it MUST use a task bar, toast or similar mechanism to make it clear to the user that they are still discoverable.
Discoverability is fundamentally different than other types of services in that it can open a user up to various imminent dangers. So applications must go “above and beyond” to make sure a user is aware of the fact that they can be discovered.
- Users MUST always be able to completely disable all app controlled mechanisms to make them discoverable easily and quickly.
- Users MUST always be able to specify constraints on how the app makes them discoverable, such constraints MUST include the ability to ban discovery by specific people/devices and to limit discovery based on day of week, time of day and geography.
If someone is being harassed and the harasser is using discovery features to enable their harassement what is a user to do? We can naively argue that they should just turn off discoverability features all together but that is to only further punish the person being harassed for the actions of another. So we have a responsibility to provide mechanisms where by a user can disable the harassers ability to find them while still allowing other people to discover them.
In addition in some circumstances a user might be comfortable being discovered by a large group of people over a wide distance but only in certain circumstances. For example, someone at work might be fine with some of their co-workers being able to find them but won’t be at all happy if those same co-workers get notices of the User’s location when the co-workers happen to be near the user outside of work. So we have to empower the user with the ability to control how discoverable they are based on restrictions such as geo-fencing, time of day, and day of week.
- If a User chooses to exclude a specific person from being able to discover them all appropriate precautions MUST be taken to ensure that the person so excluded can not easily determine that they have been excluded.
This is more of a wish than a reality. It’s unbelievably hard in any truly interconnected social situation for someone who has been excluded not to discover this fact. Just do a quick browse for ways to detect if someone un-friend-ed you. This is the aspect of discovery that worries me more than other (except possibly radio fingerprinting), especially for people in a situation where they are being harassed.
- When specifying limits on who can discover a user the user SHOULD be able to specify specific distances beyond which they cannot be discovered either at all or by identified people/devices.
This is one way to minimize the potential ramifications of cutting someone off. If one could just shorten the distance that certain people can discover the user this can help to reduce some of the harm of discovery. Unfortunately I haven’t really seen this capability available on devices but it’s something I would expect to see sooner or later and once it is there we should use it so users can reduce the distance which some people are allowed to discover them over.
- All decisions about discover-ability MUST be made by the lawful user, even if those decisions contradict the desires of the lawful owner of the device.
The last requirement can seem a bit odd but it mostly applies in corporate scenarios. In those scenarios the entity that legally owns the device might not be the person actually using the device. Since only the user has the full context of what threats they might be facing and why those threats require not being discoverable it is therefore the case that only the user can make safe decisions about discover-ability. Thus we must not support features such as administrative override to extend the discover-ability of a device in contradiction to the lawful user’s wishes.
“The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.”
- Second Law
“Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship.”
- Third Law
In Thali’s case these two laws work together:
- User data MUST only be exposed in the smallest amount to the smallest number of devices for the shortest period of time consistent with the user’s desires.
For example, in many cases the absolute easiest way to handle various discovery driven scenarios is to just announce the user’s identity to the world. Really, it simplifies so many things. When you see the article on how to do opportunistic synching via discovery in a manner that is consistent with this article you will really understand what I mean. But screaming a user’s identity from the roof tops does not honor this requirement.
This requirement also argues pretty strongly against any sort of general “Ping” feature where someone can say “Show me everyone around me.” Or at the very least it requires heavy restrictions. For example, such a Ping feature might only work with users who have the app in the foreground and explicitly approve responding to the ping. Of course what do we do if the user is being harassed but wants to send out a ping that won’t notify their harasser? That one is a real nightmare.
“A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.”
- Fourth Law
For Thali this means:
- User IDs MUST only be shared in forms that provide the most minimal correlation capabilities necessary for the immediate purpose.
There are very practical implications of this previous rule. For example, it generally means that we should never advertise a user’s identity (a public key in Thali’s case) directly since public keys are “omni-directional” identifiers, that is, they advertise the user’s identity to everybody, everywhere. We will discuss, in gory detail, alternative ways to share identity that meet this rule in future articles.
“A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers.”
- Fifth Law
For Thali this means:
- Thali’s discovery protocols MUST NOT assume that they are the final and only way to perform discovery and bind identities, they MUST leave open extensibility points to allow for other approaches.
This is more a cautionary note to Thali’s implementers then the programmers building on top of Thali.
“The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks.”
- Sixth Law
When we discuss specific features, like flood sync, we will refer back to this law. But in general it really means that identity systems have to be understandable to humans. Personally I doubt we will meet that bar without including some level of training.
“The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.”
- Seventh Law
Our expectation is that Thali will start in identity ghettos. That is, an app will use Thali’s technology to enable itself and its community but at least initially the app’s associated identities will be separate from all other identities. Over time we hope to fix this by convincing developers that there are significant benefits to using common identities in common ways. But we start simple, one app, one identity. So the seventh law doesn’t apply yet. But we hope it will apply soon. So for us the seventh law is more aspirational.
2 Given the use of MACs isn’t all this privacy guff just a bit of nonsense?
Let’s look at the various ways that the radios on a cell phone make it easy to track the cell phone’s owner.
International Mobile Subscriber Identity (IMSI) This is a globally unique number that identifies a cell phone to cell phone towers and anyone with an IMSI catcher can scan and collect them. Unless cell phones capabilities are turned off this number is constantly announced.
Wi-Fi Media Access Control (MAC) Address This is a globally unique number that identifies a particular Wi-Fi radio. Whenever a phone is looking for Wi-Fi connections it advertises its MAC in the clear. I believe that the MAC is also exposed even over secure networks but I’m not an expert in Wi-Fi security so I’m not sure. In either case, a Wi-Fi device spends plenty of time announcing its MAC to the world.
Bluetooth MAC Bluetooth also uses a MAC and near as I can tell goes around all day advertising it to anyone who listens.
Bluetooth Low Energy (BLE) Device Address BLE also uses MACs but calls them device addresses. These addresses are announced to anyone listening. But it is interesting that the BLE spec explicitly calls out the fact that one can have a public and/or a random device address. We’ll get to that point below.
All of the above addresses are globally unique identifiers that a phone spends time screaming out to whomever will listen. In fact there is a whole industry built around tracking these addresses. It lets stores, for example, see how people walk through their premises, where they dawdle, etc. The addresses themselves are just numbers but once associated with a person’s identity they allow someone to be tracked.
Given the plethora of permanent addresses already being screamed out, who cares about an extra few introduced by local discovery?
The answer is simple - the current common behavior of using fixed addresses is a bug and it is being fixed.
There is nothing magical about these addresses. They just need to be unique amongst the devices in the immediate area. So, for example, Apple has already started using randomly generated MACs while doing WI-FI discovery. And as one saw, BLE explicitly acknowledges in its design documents the idea of using a randomly generated address.
It seems reasonable therefore to assume that over time all of these addresses will become random. As such we don’t want Thali to be the one who ruins the anonymity experience. So it’s important for Thali to start off with the assumption that the phone isn’t constantly trumpeting unique IDs for the user so that when phones finally do stop trumpeting those IDs, Thali won’t ruin things.
3 Fine, so radios will stop blabbing permanent IDs, but what about radio fingerprinting?
Radio fingerprinting does scare me. It’s not clear to me that anyone is even trying right now to seriously prevent radio fingerprinting from working. But to be fair a radio fingerprinting attack, much like using an IMSI catcher, isn’t (at least yet) easy. It requires specialized equipment (for now). But to paraphrase Bruce Schneier who was apparently quoting the NSA, “Attacks always get better; they never get worse.” We can expect that as phones stop bleating unique IDs left and right that there will be increasing interest in radio fingerprinting. I don’t know if the solution is software defined radios or just introducing some random element into physical radios. But Thali shouldn’t make it worse. So yes, Thali will worry about user rights. If we want to be part of a world which respects user rights then we have to go build it.
The technical design that meets these requirements is described at http://thaliproject.org/PresenceProtocolForOpportunisticSynching/ and http://thaliproject.org/PresenceProtocolBindings/
FYI the “technical design” link is now invalid.
Thanks! Sorry about that. The links are now fixed in the comment.