1547120 - Make more FxA attributes available to snippet admin service for targeting via AS Router

Status: RESOLVED FIXED

(Firefox :: Sync, enhancement, P3)

Description

[Jean Collings]

Is it possible to target via snippets users who have or do not have a Firefox account?

And if a user does have a Firefox account, can we tell what type of service they have - as in do they have Membership, Monitor, Sync, Lockwise, Pocket or Send?

Currently we are using the "if a Firefox user uses Sync" as a proxy for FxA targeting for snippets.

I'm cc'ing Alex Davis to help us better understand if this information is exposed and if we can connect it to the snippet admin.

Comment 1

[Vijay Budhram]

Is it possible to target via snippets users who have or do not have a Firefox account?

This is currently possible and I believe snippets admin service does it already.

can we tell what type of service they have

FxA currently has this ability but it is not exposed in the browser (which snippets has access too). To support this, we would have to add some helper functions that can take an oauth token and can issue a request to /client-tokens. Example response:

[
  {
    "name": "Notes",
    "id": "a3dbd8c5a6fd93e2",
    "lastAccessTime": 1556025613000,
    "lastAccessTimeFormatted": "7 days ago",
    "scope": [
      "https://identity.mozilla.com/apps/notes",
      "profile"
    ]
  }
]

Comment 2

[Jean Collings]

Hi Vijay,

Thanks for the details. Can you confirm if the work to "expose" is on the FxA side or the AS side?

J

Comment 3

[Vijay Budhram]

The changes would involve browser code updates so technically it could be either FxA or AS person to work on it.

There would need to be a new endpoint in the Oauth Client that calls /client-tokens endpoint and parses the response.

Comment 4

[Jean Collings]

Thanks Vijay - flagging Kate to ask if this is possible before June 4th?

Comment 5

[Vijay Budhram]

Hey Jean/Kate,

Just spoke with Alex, and I recommended that FxA put together a patch for Kate. I don't think it will be too complex and it could be used as a starting point. Let me know if you have any objections.

Comment 6

[Vijay Budhram]

Attachment: Bug 1547120 - Add api to fetch fxa oauth client tokens

Comment 7

[Jean Collings]

Andrei do you mind taking a look at this while Kate is out?

Comment 8

[Andrei Oprea [:andreio]]

I can take this. It's too late for 68 but this can definitely make it to 69.

Comment 9

[Andrei Oprea [:andreio]]

Hey, what's the status of the patch? Are you planning to make more changes or is it very close to land?

Comment 10

[Vijay Budhram]

Hey Andrei,

Unfortunately this patch has bitrotted and needs to be updated. :rfk landed a patch [1] recently in FxA servers that would allow fetching devices and clients much easier. Ideally, we should use this new API instead of the method in this patch.

I am currently working on some Skyline deliverables but have cc Wil and Dave since they might be able to help and prioritize it in upcoming week.

[1] - https://github.com/mozilla/fxa/pull/1552

Comment 11

[Ryan Kelly [:rfkelly]]

:markh, here's another pending ask for FxA data, being able to find out what services the user has enabled on their account. Something to factor in as part of Bug 1565960 and encapsulate behind a nice API.

Comment 12

[Ryan Kelly [:rfkelly]]

FWIW, I don't think we should just hand out all the details of every client connected to the user's account, that seems like very tight coupling to an internal FxA service API. Would it suffice to expose some sort of higher-level listAttachedOAuthClients() method that just returns the set of active OAuth client ids without all the extra bits about last-active time etc?

Andrei, this bug blocks something with [Skyline] in the title, is it something that we need to prioritize to land in 70?

Comment 13

[Ryan Kelly [:rfkelly]]

Andrei, this bug blocks something with [Skyline] in the title, is it something that we need to prioritize to land in 70?

We chatted on slack; yes, we need this for 70.

Mark and Ed, is this something we could take on as part of evolving the FxAccounts public API?

Comment 14

[Edouard Oger [:eoger]]

I'd be ok with adding to listAttachedOAuthClients the new FxA API. I believe Mark is currently working on that?

Comment 15

[Ryan Kelly [:rfkelly]]

Reading through Bug 1548404, it's not clear to me how actionable this is right now for Skyline, it seems like we don't quite have agreement on how this will be consumed. For example, that bug talks about know whether the user has an account but is not signed in to Sync, which is not something that FxA-in-the-browser is in a position to know (we only know about your account at all if you are in fact signed in to Sync).

Who is the appropriate DRI to help scope deliverables here for Skyline?

Comment 16

[Andrei Oprea [:andreio]]

This requires changes in the FxA API. The messaging system follow up is tracked in bug 1550720.

Comment 17

[Ryan Kelly [:rfkelly]]

Who is the appropriate DRI to help scope deliverables here for Skyline?

Bug 1548404 has been removed from tracking for Skyline. We should still figure out how to move this forward though, and given that Bug 1565960 is close to landing I think we'll be able to address this soon.

:andreio, I'm interested in potential server-load impacts of adding this API, can you say more about how it will be called by the system in Bug 1550720? For example, will it be called once per browser session, or once per profile, etc? This will affect whether we want to do any internal caching of the results before exposing it outside of the FxA module.

There are two new kinds of data proposed in Comment 0, which I'll phrase as:

1. Does the user have a membership/subscriptions on their Firefox Account?
2. What services does the user currently have attached to their Firefox Account?

I think we should get (1) for free through the existing getProfile method, since the user's list of subscriptions is part of their profile info. If we have any targeting we want to do based on this piece of info, we should be able to test it out right now in Stage.

For (2), listing all attached OAuth clients seems fine, probably by calling the new /attached_clients endpoint. I didn't really intend for this endpoint to be called by the browser (which means committing to it as a long-lived public API that's hard to refactor) but I think it'll be OK.

However, I do not want to expose many of the fields returned by that API, such as the various token ids. Let's limit the output of any listAttachedClients method to just the fields callers will need, such as:

• client name
• client id
• last access time

Does that seem reasonable?

Comment 18

[Andrei Oprea [:andreio]]

There's an extra step on our side to expose any Firefox API to JEXL expressions which is what we use to decide if a user should see a message or not. This step could have it's own caching layer (it's what we do for other calls that are IO/CPU intensive) if needed.

Our targeting getters are lazy so as long as it is not referenced by any message (or all messages have already been seen) it won't get called.
Otherwise I expect it to be accessed many times per browsing session. Every time there is an opportunity to show a message we evaluate the JEXL expression and evaluate the targeting attributes. AFAIK JEXL expressions don't support short circuiting the evaluation (false && APICall() will evaluate APICall) so caching will be required.

So at minimum let's assume 1 call per browsing session. This can be further reduce by storing the information in IndexedDB (or similar) and caching for some reasonable amount of time (if required).

Comment 19

[Ryan Kelly [:rfkelly]]

Thanks for the info; it sounds like we have some good options for managing server load of doing this call, and also an emergency stop if something goes terribly wrong in production (we disable messaging that checks this flag). So I'd be happy with exposing a pretty direct listAttachedClients API on the FxAccounts object.

Comment 20

[Ryan Kelly [:rfkelly]]

:eoger, just flagging this as another bug that may be worth a look if you're working on Bug 1581709 and friends.

Comment 21

[Edouard Oger [:eoger]]

Attachment: Bug 1547120 - Add a method to list attached clients.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e0977f7ff71f
Add a method to list attached clients. r=rfkelly

Comment 23

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/e0977f7ff71f

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Comment 25

[Edouard Oger [:eoger]]

71 is fine