1157643 - Stop sending the roomOwner or always send it as guest

Status: RESOLVED INCOMPLETE

(Hello (Loop) :: Server, defect)

Description

[Mark Banner (:standard8)]

We're not currently using the roomOwner field, and the way it is currently set up in desktop/fxos clients leads to a possible privacy leak of the FxA id to other people when the user didn't necessarily intend on it.

Whilst we may want to bring it back later (e.g. when we do multi-party), I think we'll want it in a different form, i.e. a user-confirmed name/field that they wish to share.

The standalone doesn't currently display the roomOwner, although the FFOS client does.

I'm going to file a separate bug on the desktop client to stop sending the FxA id when creating the room, and only send "Guest" for now.

For this bug, I think we should consider either removing roomOwner completely, or making it optional - maybe just always sending it to clients as "Guest" even if it supplied (although that would 'break' l10n).

If we stop sending it, that would likely break the FFOS client, although I haven't tested that scenario.

Adam: any opinions on how we should handle this?

Comment 1

[Adam Roach [:abr]]

(In reply to Mark Banner (:standard8) from comment #0)
> Adam: any opinions on how we should handle this?

Let me summarize what I think you said:

* Desktop sets but does not read roomOwner
* Standalone sets but does not read roomOwner
* FFxOS sets and reads roomOwner

If this is correct, then I think we need to hold any server changes on an update to the FFxOS client.

However, in reading through the FFxOS client just now, they appear to use this field for purposes substantially more important than simply displaying the owner of a room. It looks like they have a cache of all the rooms a user has ever joined, and use the roomOwner field as a means of determining whether they own the room or someone else does.

I'm tagging Fernando, Borja, and Jose Antonio for their input.

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

Sorry, I am not familiar with the rooms implementation. Maybe Cristian knows.

Comment 3

[Cristian Rodriguez (:crdlc)]

AKAIR the roomOwner is needed for:

* to know if the current authenticated user is the owner or not

https://github.com/mozilla-b2g/firefoxos-loop-client/blob/5a82c2457c2409c6b67012a0ff19e4d291170448/app/js/helpers/room/room_controller.js#L385

https://github.com/mozilla-b2g/firefoxos-loop-client/blob/88fabf863e512e3ae8d81252a27b38c87defacaa/app/js/helpers/rooms_synchronizer.js#L116

* We could share a room *only* if we are the owners

https://github.com/mozilla-b2g/firefoxos-loop-client/blob/e2d298fb998ee1d50f5cc40d4f8160d41d0e0fab/app/js/screens/calllog.js#L57

Comment 4

[José Antonio Olivera Ortega [:jaoo]]

Clearing the ni? request as Cristian provided the answer. Sorry for the lag.

Comment 5

[Alexis Metaireau (:alexis)]

I'm not sure what we should do here. Can you provide higlights of changes we need to do on the server side?

Comment 6

[Mark Banner (:standard8)]

The desktop side is going to change to show "-" as the owner (bug 1157645). This will get rid of the minor leak for desktop. AFAICT doing that won't affect the FxOS client.

For this bug, I think we should drop the roomOwner field at some stage. That either depends on changing the FxOS client and/or we could file it under a list of things to do for a v2 protocol when we need one.

It doesn't feel like we need to fix this bug in the short term, more a long term improvement.

Comment 7

[Alexis Metaireau (:alexis)]

Okay. I'll then consider this bug blocked by changes on the mobile client.

Comment 8

[Mark Banner (:standard8)]

Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.