1234672 - Social API should consider userContextID

Status: RESOLVED INVALID

(Core :: Security, defect, P3)

Description

[Tanvi Vyas[:tanvi]]

Social API will likely use the default user context id of 0 (https://bugzilla.mozilla.org/show_bug.cgi?id=1233908).  Imagine the following scenario:

* User is signed in to Facebook in the "Personal" context, but not the default context.
* User opens social API and wants to use Facebook chat.  User is confused about why they are not signed in and signs in.  This adds their facebook cookies to the default user context.
* User later opens a facebook page in the default user context and assumes they are not signed in, since they signed in on the Personal context but not the default one.  User finds, to their surprise, that they are signed in in the default context.

This is confusing.  We should decide if we want to:
* Make social API have its own unique user context id
* Make the UI clear that the social API operates in the default context
* Allow the user to change which context it uses social API in (this is probably too complex an option for most users)

This is for v2+ of Contextual Identity.

Comment 1

[Bram Pitoyo [:bram]]

I think that Social API should respect userContextID.

So the scenario becomes something like this:

* User signs into Facebook in multiple contexts: “Personal” and “Work”.
* In each context, user opens Social API. Each Social API will display information from different accounts, as expected.
* User tries to open Social API in the default context. Firefox notices that user is already signed into Facebook elsewhere, so it displays a message: “You are already using Facebook in [container_1] as [username_1] and [container_2] as [username_2]. Want to use a different account? [Sign in].”

Alternatively, we can disable Social API everywhere but in the default context. To me, this seems like a brutal catch-all solution, but it may result in less issues and confusion.

Thoughts?

As an aside, do we have a list of Firefox components that will be impacted by userContextID? We should make sure that our solution is consistent in each instance.

Comment 2

[Tanvi Vyas[:tanvi]]

This bug requires UX work, UI work, and platform work.  But isn't required for the initial launch of containers.  Marking P3.

Comment 3

[Dave Huseby [:huseby]]

Tantek,
This is the social API bug that I was thinking about.  Social API needs to be origin attribute aware.  That basically means that whenever it creates a principal, it needs to inherit the origin attributes correctly.  I just wanted to make sure you saw it.

--dave

Comment 4

[Tantek Çelik]

:huseby makes sense. I see :mixedpuppy is already on the bug so I'll add my +1. I believe there is a larger restructuring planned for Social API that may make this moot but I'll leave that to :mixedpuppy to clarify. Thanks, Tantek

Comment 5

[Shane Caraveo (:mixedpuppy)]

SocialAPI has been reduced down to Share in fx51.  There is one share panel currently per window, however as part of the activity stream test pilot a new UI has been used, one where there is simply a menu that opens a popup window for the share page.  

The UI described in comment #1 wont work, there are too many providers and we do not have sign-in data from any of them (ie. know way to know what accounts you're signed in as).  I do not beleive UX/UI work is necessary here at all.

I think that we need to look at what container the page (being shared) is in, and open the iframe using that container, then let the provider (e.g. Facebook) handle user account UI based on their cookies in that container.

Comment 6

[Firefox Bug Husbandry Bot]

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020

Comment 7

[Tom Ritter [:tjr]]

Social API is gone.