1025881 - Loop server - calls need to store the name of the calling user

Status: VERIFIED FIXED

(Hello (Loop) :: Server, defect, P2)

Description

[Fernando Jiménez Moreno [:ferjm]]

https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/#call-incoming

Comment 1

[Alexis Metaireau (:alexis)]

From Bug 1025894:

> Loop server does not store the user ID in plain text, it stores an HMAC of it instead.
> That makes not possible to provide the caller ID to the callee party in an ID enabled call.

Comment 3

[Rémy Hubscher (:natim)]

I am looking into this ticket and what I understand is that:

**We want a way to link a incoming call to a user in order to display its name.**

Technically, this means that we need to store:

 1 - The UserId of a Hawk authenticated user during the registration phase.
 2 - The UserId of the caller on a call so that the callee can read it.

**We don't want to store non encrypted private data in our databases.**

What can we do?

 - We can store a SHA-256 hash of the id so that it can be link to the user buddy list but then what happens if the caller is not in the callee buddy list?

 - We can encrypt the UserId using the HawkId (that only the client knows) during the registration phase so that we can decrypt it during the POST /calls phase. But then we still need to store it in clear text in the call information to give it back to the callee.

Comment 4

[Rémy Hubscher (:natim)]

In order to make a choice, can you tell me what is the status of a call from somebody not in our contact list?

Comment 5

[Romain Testard [:RT]]

Not sure I understand the question.

You can be called by someone who is not in your contact list so long as you don't prevent it by using the feature which prevents non contacts from calling you.

Comment 6

[Rémy Hubscher (:natim)]

Ok this helps, and I think we want to display the caller email address or MSISDN even if we don't have it on our contact list? Or can we display : `Unknown contact`?

Comment 7

[Romain Testard [:RT]]

The information to display on incoming call notification are listed here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1011472#c4

Incoming call visual notification when not signed in (link call-back only):
* URL name (custom or randomly generated)
* Information whether the caller's media selection is audio only or audio+video
* Link expiration date

Incoming call visual notification when signed in and receiving a link call-back:
* URL name (custom or randomly generated)
* Information whether the caller's media selection is audio only or audio+video
* Link expiration date

Incoming call visual notification when signed in and receiving a direct call:
* Caller's friendly name (or ID if no friendly name)
* Caller's avatar (or default avatar if not applicable)
* Information whether the caller's media selection is audio only or audio+video

When receiving a direct incoming call, the list applies regardless of whether the person is a contact or not.
Although thinking this through now I assume that the friendly name display is managed client side if the incoming call comes from a contact so I assume we can only display the ID for incoming calls originating from non contacts?

Comment 8

[Rémy Hubscher (:natim)]

Yes there is no such Friendly Name metadata in FxA certificate.

We just have the https://github.com/mozilla/fxa-auth-server/blob/master/bin/signer.js#L40

What I think I will do is:

 - Storing HawkHmacId for database indexes instead of HawkId
 - During the registration phase, encrypting the user fxa-verifiedEmail or verifiedMSISDN from the Firefox Account or MSISDN Gateway certificate using the HawkId (that only the client knows)
 - During the call phase, storing the callerId unencrypted. (knowing that the call data will leave for 30 seconds.)

Then I will be able to give to the callee the verified callerId from the User Authentication Certificate without liking any email address in the long term database.

Comment 9

[Alexis Metaireau (:alexis)]

(In reply to Romain Testard [:RT] from comment #7)
> Incoming call visual notification when not signed in (link call-back only):
> * URL name (custom or randomly generated)
> * Information whether the caller's media selection is audio only or
> audio+video
> * Link expiration date

Isn't it the link creation date?

Comment 10

[Rémy Hubscher (:natim)]

At list here it is: https://people.mozilla.org/~dhenein/labs/loop-mvp-spec/#call-incoming-unknown

Comment 11

[Rémy Hubscher (:natim)]

least* (I have a terrible english syntax sorry.)

Comment 12

[Romain Testard [:RT]]

You're right, it's the creation date not the expiration date, apologies for the confusion.

Comment 13

[Alexis Metaireau (:alexis)]

If we really need to store this data, then let's hmac(data, hawkid) in the persistent storage and store it in clear in the temp storage (because we cannot do it in any other way).

Comment 14

[Rémy Hubscher (:natim)]

I've been starting to implement this and I discovered that we have actually two couple of things that we were mixing:

 - calleeId and calleeFriendlyName

as well as

 - callerId and callerFriendlyName

The calleeId and callerId are taken from the FxA or MSISDN assertion, it should be a verifiedEmail or a verifiedMSISDN.

Then we have a Friendly Name value that is defined directly by users.

For now the callerFriendlyName is only defined by the call-url issuer and cannot be defined for direct calls where we are using the callerId directly without letting the user define his friendly name.

Maybe this is what we want, use the callerId all the time when the user is connected and the callerFriendlyName defined by the callee on callUrl generation.

But then why do we want the callee to be able to define his friendly name instead of using directly his verifiedID?

I'd like users to be able to define their friendly name on the registration endpoint so that we can access it later. Is that ok for you?

Comment 15

[Rémy Hubscher (:natim)]

Ok, so actually, we don't seem to need the calleeId, because in case of direct calls, we know who we are calling and in case of call-url, we have the calleeFriendlyName.

Comment 16

[Rémy Hubscher (:natim)]

Attachment: Link to github PR

Comment 17

[Alexis Metaireau (:alexis)]

https://github.com/mozilla-services/loop-server/commit/675a5c152a291576f0d6c50ce1ce47068e094372

Comment 18

[James Bonacci [:jbonacci]]

Verified in code review, especially for loop/encrypt.js, loop/hmac.js, test/encrypt_test.js, and test/hmac_test.js.