Closed Bug 1025881 Opened 8 years ago Closed 8 years ago

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

Categories

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

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: ferjm, Assigned: rhubscher)

References

Details

(Whiteboard: [qa?] ft:Loop)

Attachments

(1 file)

56 bytes, text/x-github-pull-request
alexis+bugs
: review+
Details | Review
Priority: -- → P2
Summary: Loop server - Incoming calls need to display the name of the calling user → Loop server - calls need to store the name of the calling user
Whiteboard: [qa?]
Blocks: 1011472
Whiteboard: [qa?] → [qa?] ft:Loop
Blocks: 1030253
Assignee: nobody → rhubscher
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.
Duplicate of this bug: 1025894
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.
In order to make a choice, can you tell me what is the status of a call from somebody not in our contact list?
Flags: needinfo?(rtestard)
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.
Flags: needinfo?(rtestard)
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`?
Flags: needinfo?(rtestard)
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?
Flags: needinfo?(rtestard)
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.
(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?
least* (I have a terrible english syntax sorry.)
You're right, it's the creation date not the expiration date, apologies for the confusion.
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).
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?
Flags: needinfo?(adam)
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.
Flags: needinfo?(adam)
Attached file Link to github PR
Attachment #8448688 - Flags: review?(alexis+bugs)
Status: NEW → ASSIGNED
Blocks: 1020449
https://github.com/mozilla-services/loop-server/commit/675a5c152a291576f0d6c50ce1ce47068e094372
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Attachment #8448688 - Flags: review?(alexis+bugs) → review+
Verified in code review, especially for loop/encrypt.js, loop/hmac.js, test/encrypt_test.js, and test/hmac_test.js.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.