introduce some kind of easy to read and write id for looking friends up on the map

[stephanlindauer]

maybe even proper names

[MartinNowak]

I'd like to work on this.
Currently the changingDeviceToken could be linked to a phone if you can get hold of it's android id anyhow, so replacing that id makes sense anyhow.

My initial design idea goes as follows:

• add a new sidebar menu entry (id, connect, or so)
  • allows to generate a new random id (maybe encode it as wordlists)
  • shows how old the former id is (and recommend refresh after a day or so, could be mandatory as well by factoring in the date)
  • allow to share that id as link (via whatever communication medium people like) or in spoken word
  • add an "add friend" button to manually add name & id (or allows to update existing links)
  • add an intent to open links which prefills the id input of the above
  • add a purge all button
• allow the app to query for the position of those ids
  • maybe show them in different colors on the map
  • there must be a rate limit on wrong API queries to prevent brute forcing the secret

[stephanlindauer]

is that id you are suggesting really supposed to be a secret? i would suggest just attaching this newly generated id to the location object and communicate to the user that other users will be able to track him via this id.

[stephanlindauer]

also we will have to think about id collisions if we allow the user to generate it him/herself.

[cbalster]

I also put some thought into this and I also think it would be best to just use the existing system but just keep the id constant if the user wants to be able to be tracked. This way we don't need any registration mechanisms and don't have change the api. Also the information will be pushed with the usual location updates without adding any additional overhead. Regarding the collision: maybe we can just use an ID generated by the existing code. The drawback here is that it's hard to communicate. To alleviate this we should support as many ways to share it as possible (SMS, messengers, email...) and register an intent as suggested by Martin.

[stephanlindauer]

so basically:

• keep the old hash we're already sending
• add a new field in which the user can generate a human readable name, like:
  https://github.com/TomFrost/node-phonetic
https://github.com/moby/moby/blob/master/pkg/namesgenerator/names-generator.go
  this name could be seeded by the user id hash we already have
  makes sense?

[stephanlindauer]

@MartinNowak hey martin, i could adapt the backend on the weekend accordingly. let me know what changes you need done.

[lennet]

I started thinking about this feature and tried to come up with a solution that doesn’t require and server changes but also doesn’t requires a constant id.

How about using asymmetric encryption instead of hashing for generating the token that we are sending to the server?
We could encrypt a static ID + a random suffix That changes once per day, so that the we don´t end up with a constant ID.
For a friend invitation, we could send and url that contains the static ID, the users public key And optional the users name. To detect if an ID is a friends identifier, we try to iterate over all public keys and try to decrypt it with the key and check if the decrypted ID has the static ID as a prefix

We could even encrypt the updated name in the id if static ID And random suffix Have a constant length

[derhuerst]

Can you explain why using asymmetric crypto has an advantage over a hash here? Hashes are commonly used in P2P systems for privacy-preserving discovery of well-known/trusted peers.

We could encrypt a static ID + a random suffix That changes once per day, so that the we don't end up with a constant ID.

I'd like to propose hash(static user-defined name/handle, day). This essentially is like 2FA secrets work, except that the secret is your handle (and not secret). It would solve several problems at once:

• It allows me to pick an intuitive name that others can easily find me by. Obviously the UI would have to explain that picking 123 as a handle allows strangers to easily track you.
• It prevents tracking of people over longer periods of time, as the computed hash/ID changes from time to time.
• It is technically very simple and there is no exchange of a long (even if encoded in a humane format) key necessary.

cc @dirkschumacher

[lennet]

I like the idea but what happens with name duplicates?

Using the day instead of a random suffix or hashing parameter totally makes sense and makes it way more performant as the users knows for which keys they have to look for instead of trying all keys.

I personally dont like that once a users knows the name/secret, they can track them until this secret gets updated but that’s a problem with both approaches.

The iOS client has a proof of concept of the feature in a separate branch criticalmaps/criticalmaps-ios#88

[derhuerst]

I like the idea but what happens with name duplicates?

Good question. Then maybe an install-unique ID & a share-your-ID feature is more appropriate.

I personally dont like that once a users knows the name/secret, they can track them until this secret gets updated but that’s a problem with both approaches.

A good way to mitigate this is to

• generate a random handle by default
• add a random suffix when the user enters the handle (and display it)
• let the app periodically generate a new suffix (users who can always change it to something static)
• make the share-your-ID feature truly convenient: app deep links, QR codes, emoji encoding, share button?

[pictarus]

why do you worry about duplicates? If there are two goofy on the road, then it is so. Either you find a new cyclist or you give your friend a call to change to goofy_2. And after the ride you can easily change your nick. Andy Am Montag, den 12.08.2019, 11:44 -0700 schrieb Jannis Redmann:

…

> I like the idea but what happens with name duplicates? Good question. Then maybe an install-unique ID & a share-your-ID feature is more appropriate. > I personally dont like that once a users knows the name/secret, > they can track them until this secret gets updated but that’s a > problem with both approaches. A good way to mitigate this is to generate a random handle by default add a random suffix when the user enters the handle (and display it) let the app periodically generate a new suffix (users who can always change it to something static) make the share-your-ID feature truly convenient: app deep links, emoji encoding, share button?

[derhuerst]

Does the app send the user identity and the device id as two values, or is it one? If it was one, you wouldn't be able to distinguish to device or two users (using the same handle) anymore, so you can't do stuff like count the number of people, etc.