-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
the NFC ring project collects heat maps where the nfc "antenna" works best. You can look these up on http://nfcring.com/sweetspot/ Also, the Sony Z3 has a NFC sign on the back where the "antenna" is integrated. It worked better than all other devices I tested in our lab. Keep in mind that NFC is based on induction, so traditional antenna design does not apply here. Regards Dominik On 04/21/2015 06:58 PM, Yaron Goland wrote: > 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 > <[email protected]> on > behalf of Hans-Christoph Steiner <[email protected]> Sent: > Tuesday, April 21, 2015 8:33 AM To: > [email protected] 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: [email protected] >> > > -- 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: [email protected] > _______________________________________________ List info: > https://lists.mayfirst.org/mailman/listinfo/guardian-dev To > unsubscribe, email: [email protected] > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBAgAGBQJVNoqzAAoJEHGMBwEAASKCSO0H/2vsYvtBUkvYTgJ5ptZ0SkAk 1ad9/y/QZm+9BWI0mpnAe1b6wa4IZ2EdZpd7LMxu99/D5xtB6V/Mwp5HV3UQQY70 OOOaQLOb3aBFP8pychrdtOTe4uauXKZSu2onKjts40yzD7k9R4l4ookuXM4gaX0M MqMwwQF4ugD19AWlxq4FBbRU1WBWntFLvltsPN/5PGmMgkl4kRECxsuquWVmxTCN kXfHSF2mUD/BQ4EvfAbaO8o2Jr+WafdPcNd6RHMc0jgUWZUHHs38yjSnoMcDs7Si Z+p8gtAjjcY/DsO8X67auFwQPef6GYY+FmUJ09EZlB37+qWhjgknxFr9ZX3VhBg= =wK82 -----END PGP SIGNATURE----- _______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
