Add Safe browsing Unique ID stable over a week or two

NEW
Unassigned

Status

()

P3
normal
2 years ago
2 months ago

People

(Reporter: tnguyen, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: pwphish-threathit)

(Reporter)

Description

2 years ago
Opt-in report may require a unique ID which will be refreshed every 1-2 weeks.
We should:
- Create two new prefs: user id and user id timestamp to manage the ID and its lifetime
- Refresh the ID if the timestamp >= 2 weeks (when initializing SB or about to send report)
(Reporter)

Updated

2 years ago
Blocks: 1331138
(Reporter)

Updated

2 years ago
Priority: -- → P3
Here's a very simple scheme:

1. create a permanent UUID if it doesn't already exist (like toolkit.telemetry.cachedClientID but not the same)
2. store that permanent UUID in "browser.safebrowsing.provider.google4.datasharing.id"
3. concatenate the userid with year and week number in YYYYWww format [1] (e.g. 2017W05)
4. hash the concatenated string
5. send the hash as the userid

The advantage of this scheme is that we don't have to manually rotate the ID and it's guaranteed to be different every week.

[1] https://en.wikipedia.org/wiki/ISO_week_date
Whiteboard: pwphish-threathit
Assignee: nobody → francois
Status: NEW → ASSIGNED
Priority: P3 → P2
The user_id will be added to the ClientReport API like this:

  // Details about the user that encountered the threat.
  message UserInfo {
    // The UN M.49 region code associated with the user's location.
    optional string region_code = 1;

    // Unique user identifier defined by the client.
    optional bytes user_id = 2;
  }

  // Details about the user that encountered the threat.
  optional UserInfo user_info = 22;
Assignee: francois → nobody
Status: ASSIGNED → NEW
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.