[guardian-dev] Discovery and user rights

Thu Apr 30 15:08:03 EDT 2015

I like the metaphor of creating URLs, address bars, and lock icons.  That
really seems like the direction we need to be thinking right now: what are the
minimal necessary concepts required for a usable and useful system?  Which
metaphors can we reuse?

I think this should be one discussion topic for the Wind Farm event.

.hc

Yaron Goland:
> For whatever it's worth the second article [1] I ever published on Thali (the first [2] was defining the problem I was trying to tackle [3]) was about user's rights and the last right was "A right to successfully use these rights without being a computer/security expert".
> 
> But I must admit that this is aspirational. The complexity you describe is exactly the problem. Some problems are just plain hard. My guess is that we will require some sort of user training. Just like people had to learn about URLs and address bars and lock icons, they are going to have to learn some concepts for them to manage their local discovery well.
> 
> All we can do is try and learn.
> 
>         Yaron
> 
> 
> [1] http://www.goland.org/ausersbillofrights/
> [2] http://www.goland.org/opendataweb/
> [3] If you look at these articles you will see the name Paeony. This was the original name for Thali and is a name that I personally still own the domain for. The Thali name is owned by my employer. I maintain the Paeony name just in case something goes sidewise. But keep in mind that everything we do in Thali is released under MIT or Apache 2.0.
> ________________________________________
> From: Hans-Christoph Steiner <hans at guardianproject.info>
> Sent: Wednesday, April 22, 2015 8:39 AM
> To: Yaron Goland; guardian-dev at lists.mayfirst.org
> Subject: Re: [guardian-dev] Discovery and user rights
> 
> Its great to see that you have incorporated ethics into your development
> process.  That really needs to be not only part of all technology development,
> but also tech education and research.
> 
> Reading through http://www.goland.org/localdiscoverybillofrights I agree with
> the laws that you have laid out, but my overriding thought is that making
> general systems based on discovery will always end up being really complicated
> to the user, since they have to be aware of all the permutations of access
> controls in order to have any say in how they are used.  Also, it is a pretty
> complicated UI question on top of that.
> 
> I think that complexity is inevitable since the goal here is to map the
> psychology of inter-personal relationships to a software system.  And the
> psychology of inter-personal relationships is vastly complicated.  So for
> systems like this to have any chance of working, they must be mapped as
> directly as possible to existing human behavior.
> 
> .hc
> 
> Yaron Goland:
>> For what it's worth we did some experimenting with NFC and eventually gave up. The reason is that the range is so outrageously small that if we didn't exactly line up the NFC transceivers we couldn't get data flowing. The result was a sort of rubbing dance with the phones that didn't result in a great user experience. None of this, btw, is unsolvable. I could imagine having a NFC  logo that identifies where the NFC transceivers are on the phone or maybe increasing their power a tiny bit so they don't have to be so outrageously close. But for our scenarios we actually want range since the point is to allow people to collaborate over as long a distance as their radios will support.
>>
>> Never the less I still ended up in a similar place to your mail below about range restrictions.
>>
>> I published an article on my blog, http://www.goland.org/localdiscoverybillofrights/, where I try to define what I believe are the rights that a user should have in terms of controlling presence. In one of the points I talk about how users should be able to have a policy that lets them only be discovered based on distance.
>>
>> In other words there might be someone who is harassing me at work. I don't want to walk around with an electronic leash on my neck constantly telling them where I am. But I still need to work with them. So I could imagine having logic that could measure the strength of the signal I'm getting from the harasser. I could then say things like "This person is only allowed to discover me if they are within 5 feet." At that distance (baring walls :( ) they can just see me. Also by having some connectivity it will be slightly harder for them to know I've essentially "un-friended" them.
>>
>> But I also realize that I'm just playing games. A determined attacker is going to be able to discover where people are and who has unfriended them. In my longer technical article that I'm still working on I talk about a bunch of these attack scenarios. But fundamentally if the person you are trying to avoid is part of your social group then there are just too many channels for them to use discovery to find you. I don't know if that problem is solvable. It's one thing to hide from strangers, but it's extremely difficult to hide from the friends of your friends.
>>
>>         Yaron
>>
>> ________________________________________
>> From: guardian-dev <guardian-dev-bounces+yarong=microsoft.com at lists.mayfirst.org> on behalf of Hans-Christoph Steiner <hans at guardianproject.info>
>> Sent: Tuesday, April 21, 2015 8:33 AM
>> To: guardian-dev at lists.mayfirst.org
>> Subject: Re: [guardian-dev] Discovery and user rights
>>
>> Sounds right on topic for us! We're working with the exact same issues and tech.
>>
>> I'd like to throw out on related idea, just to get the ideas flowing.  I've
>> been trying to think about how to keep the range small enough so that we can
>> rely on inter-personal skills for handling some of the privacy issues.  NFC is
>> perfect for that, Bluetooth and local WiFi are also pretty good, but can be
>> locally monitored.
>>
>> This is a core idea of the FDroid app swap process.  The authentication comes
>> from actually physically exchanging with the other people, and having that
>> session last as long as the people are physically present in the same room.
>> That maps concretely to our experience of agreeing to be in the same room with
>> people, and choosing who in that room to talk to.
>>
>> There are of course large limitations to working like this, so it won't work
>> for lots of use cases where local data transfer can be useful.
>>
>> .hc
>>
>> Yaron Goland:
>>> Guardian Folks,
>>>
>>>
>>> First off I sincerely apologize if this is the wrong mailing list to bring this issue up on. I know y'all are working in this area and so I was hoping we might share notes. But if this isn't the right place please tell me and I promise to cease and desist.
>>>
>>>
>>> Right now I'm working on an design for how to use technologies like BLE to enable discovery in ways that respect user rights and don't kill user batteries.
>>>
>>>
>>> To this end I've written (and will soon publish) a Users Bill of Rights for discovery based on Kim Cameron's Laws of Identity. One of the key rights is the right to decide who can discover you.
>>>
>>>
>>> For example, imagine that you are part of a group of 100 or 200 people. It's a big discussion list. The contents of the list are being passed around via BLE/Wi-Fi. Specifically, BLE is used to discover people around you and if they aren't people you have sent your post to then you will contact them over Wi-Fi Direct (or Bluetooth or Multi-Peer Connectivity or whatever) to pass the data.
>>>
>>>
>>> However there is someone in the group who has been harassing you and you don't want them to be able to find you via your telephone. In other words, you don't want your phone to tell them you are "in the area". So you go to your app and say "Exclude person X from notifications".
>>>
>>>
>>> Now you post to that group of 100 or 200 people. In theory if your phone discovers someone who is a member of the group who you haven't already sent a copy of the post to then your phone should transmit it automatically.
>>>
>>>
>>> The easiest way to do all of this is to just announce your identity (in our case a public key). That way if you see someone else's public key that you know you haven't updated yet then your device can contact them. But of course the inverse is a big problem. That is, if your phone is constantly advertising your public key then the person you want to exclude will see it and know you are in the area.
>>>
>>>
>>> In theory the answer to this is to not advertise your key directly but rather to take your key and then encrypt it with the keys of the people you are trying to reach. In other words if you want to send out 200 updates then you would advertise, over BLE, 200 values. Each value is your identity encrypted with each person's key.
>>>
>>>
>>> Which means that someone receiving your advertisement would see 200 values and have no idea if any of those values are for them. So they would have to try to decrypt each and every one using their private key to see if any match. If they do then they know who is looking for them.
>>>
>>>
>>> The benefit of this approach is that if someone is advertising out they can simply not advertise to any member of the group they have excluded. Similarly if someone receives an advertisement from someone they excluded then they can just ignore it.
>>>
>>>
>>> The problem is that this approach will almost certainly end up being a DOS attack on the low bandwidth BLE channel and potentially turn each device into a toaster oven as it tries to process potentially hundreds of tokens from 10 or 20 different sources (depending on how many devices are in range).
>>>
>>>
>>> BLE is unbelievably slow. In practice I'm told that you aren't going to get much about 35KB/s and that's on a clear channel (which this isn't).
>>>
>>>
>>> Furthermore we are processing these trial decryptions on battery powered devices. The good news is that modern phones generally use processors that have built in support for encryption operators. But I'm not clear how much of modern crypto software for iOS/Android actually uses those instructions. Even so, performing literally 1000s of public key decryptions over a period of a few hours isn't going to make anyone happy.
>>>
>>>
>>> So I did think of an optimization. The optimization is that we could try to create pairwise keys between all members of the group. In that case what someone would advertise is some value encrypted with the key shared with that person. We could then use something like AES-128/GCM to do the encryption. This has a couple of benefits. The encrypted value instead of being measured in K as it would with say RSA 4K keys, would instead be around 40 or so bytes. Also the expense of "testing" each value will go way down, especially if we use code that supports the ARM processor's support for AES. [1]
>>>
>>>
>>> AES-128/GCM/SHA-256 is what higher end TLS implementations use and mobile processors these days are largely optimized to handle it quickly for that reason. But to be fair the performance profile is likely to be very different than TLS because we are talking about large numbers of short encryptions/decryptions and most of those are going to fail. Unexpected results do awful things to desktop processor pipelines, I don't know enough about ARM's architecture to know what to expect. But I suspect it won't be pretty.
>>>
>>>
>>>
>>>
>>>
>>>
>>> [1] Another option would be use to HMAC-SHA256 but I think this would require an initialization vector to make the resulting hash not be invariant and thus act as a beacon. I'm not clear if this would really provide any meaningful savings.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>>>
>>
>> --
>> PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
>> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81
>> _______________________________________________
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>> To unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>>
> 
> --
> PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81
> 

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81