1927971 - Gather data on CalDAV OAuth tokens

Status: RESOLVED FIXED

(Calendar :: Provider: CalDAV, task)

Description

[Geoff Lankow (:darktrojan)]

CalDAV with OAuth is a mess. We still have the old Lightning client ID in the code. When it comes to storing tokens in the login manager there are three choices of username (the actual username, the session ID from when we had sessions, and the calendar's ID) and three choices of origin (the hostname of the issuer like we do elsewhere, the session ID, and the calendar's ID). I count seven different ways to store a token. We may or may not even have the username for the service.

Fortunately, I think all of the weirdness is restricted to Google calendars. There's also code for Fastmail but that was added recently and I think avoided all of the historical changes.

Long term, I plan to clean this all up, so it uses all the same mechanisms as the other things that use OAuth. But first I want to know the state of play. If there's a lot of users with (e.g.) no username stored, I may change approach and try to migrate them, instead of forcing an authentication prompt in their face. I'm writing a Glean probe that can exist for a few versions (and be migrated back to old school Telemetry for ESR).

Comment 1

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1927971 - Gather data on CalDAV OAuth tokens. r=#thunderbird-reviewers

Comment 2

[Geoff Lankow (:darktrojan)]

Attachment: 1927971-data-review.md

Comment 3

[Andrei Hajdukewycz [:sancus]]

Comment on attachment 9434144 [details]
1927971-data-review.md

Sounds good.

1. Is there Documentation?

• This collection is documented in the Glean Dictionary at https://dictionary.telemetry.mozilla.org/
• https://hg.mozilla.org/comm-central/mail/metrics.yaml

2. Is there a control mechanism that allows the user to turn this data collection off?

Yes: Standard telemetry preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, Geoff Lankow(:darktrojan).

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 1: Technical Data.

Is the data collection request for default-on or default-off?

default-on

Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)?

No.

Is the data collection covered by the existing Thunderbird privacy notice? If unsure: escalate to legal if:

Yes.

Does the data collection use a third-party collection tool? If yes, escalate to legal.

No.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d4568348a8b7
Gather data on CalDAV OAuth tokens. r=aleca

Comment 5

[Geoff Lankow (:darktrojan)]

Comment on attachment 9434131 [details]
Bug 1927971 - Gather data on CalDAV OAuth tokens. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #):
User impact if declined: none
Testing completed (on c-c, etc.): on central a week, data submission is working
Risk to taking this patch (and alternatives if risky): none

Comment 6

[Corey Bryant]

Comment on attachment 9434131 [details]
Bug 1927971 - Gather data on CalDAV OAuth tokens. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta

Comment 7

[Corey Bryant]

Thunderbird 133.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/eeb58d513c39

Comment 8

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1927971 - [ESR128] Gather data on CalDAV OAuth tokens. r=#thunderbird-reviewers

Port of https://hg.mozilla.org/comm-central/rev/d4568348a8b755729a52f23cd721ff9021f9ca74 but with Telemetry instead of Glean.

Comment 9

[Corey Bryant]

Comment on attachment 9436295 [details]
Bug 1927971 - [ESR128] Gather data on CalDAV OAuth tokens. r=#thunderbird-reviewers

[Triage Comment]
Approved for esr128

Comment 10

[Daniel Darnell [:dandarnell]]

Thunderbird 128.4.3esr:
https://hg.mozilla.org/releases/comm-esr128/rev/2795c974a2fa

Comment 11

[Geoff Lankow (:darktrojan)]

Here's a sample from the ESR channel.

Where we have a user name :

• the token is stored using the user name - 98.83% (of all Google calendars reported)
• the token is stored with the calendar's ID (could been fixed) - 0.00%
• there is no token stored - 0.79%
• the token is for the old client, and is stored with the calendar's ID - 0.00%

Where we don't have a user name at all:

• the "session" ID is used - 0.00%
• the token is stored with the calendar's ID - 0.06%
• there is no token stored - 0.03%
• the token is for the old client, and is stored with the calendar's ID - 0.28%

This is good news, if we just switch everybody to the Thunderbird client (using only the user name for storing tokens) very few people will see a new authentication prompt. I think that is what I'll do.

I'm now going to back this patch out, as it was a one-off collection of data and is no longer needed.

Comment 12

[Geoff Lankow (:darktrojan)]

Backed out:
https://hg.mozilla.org/comm-central/rev/b43e4ab38ee373edb7991d4ae4aeef27e409b20c