about:networking#networkid shows an ID that is too persistent: it can be used to successfully link users (STR: visit the page with two different profiles, or with two different Linux machines on the same network).

I think this should be properly documented.
Your privacy policy mentions IP addresses and a generic "hardware configuration", but nothing like persistent hardware identifiers, such as your gateway's MAC address, and/or their combinations.

As an improvement, I suggest adding a seed to the generated network ID. NetlinkService contains a local-rubbish seed already.
I suggest changing it with a random nsID generated at each startup, or at least with a seed stored in the profile and somehow changeable by the user.

(In reply to Pier Angelo Vendrame from comment #0)

I suggest changing it with a random nsID generated at each startup, or at least with a seed stored in the profile and somehow changeable by the user.

That sounds good. I'm going to put this in the backlog for now. I'm happy to mentor someone on doing this if they want to work on it sooner than we can get to it.
The random id would need to be added to the hash here, here and here.

For start we could probably use the ProcessCreation timestamp as a seed.

(In reply to Valentin Gosu [:valentin] (he/him) from comment #1)

(In reply to Pier Angelo Vendrame from comment #0)

I suggest changing it with a random nsID generated at each startup, or at least with a seed stored in the profile and somehow changeable by the user.

That sounds good. I'm going to put this in the backlog for now. I'm happy to mentor someone on doing this if they want to work on it sooner than we can get to it.

I am working on a patch for Tor Browser (which is based on 102 ESR, but I guess the patch will probably apply cleanly to nightly).

The random id would need to be added to the hash here, here and here.

These are the same points I found in my analysis 🙂️.

For start we could probably use the ProcessCreation timestamp as a seed.

My current Windows implementation is based on nsID (I have not tried to build it, yet):

  auto createSeed = []() {
    Maybe<nsID> rv;
    rv.emplace();
    if (NS_FAILED(GenerateUUIDInPlace(*rv))) {
      rv.reset();
    }
    return rv;
  };
  static Maybe<nsID> seed = createSeed();
  if (seed.isNothing()) {
    MutexAutoLock lock(mMutex);
    mNetworkId.Truncate();
    return;
  }
  sha1.update(seed.ptr(), static_cast<uint32_t>(sizeof(*seed)));

Is there any reason to prefer ProcessCreation to this?
The only one I could think of is that GenerateUUIDInPlace could fail (but its documentation says it is very, very unlikely).

(In reply to Pier Angelo Vendrame from comment #2)

Is there any reason to prefer ProcessCreation to this?
The only one I could think of is that GenerateUUIDInPlace could fail (but its documentation says it is very, very unlikely).

Most lilkely ProcessCreation has already been computed and doesn't require a source of randomness.
If you do go the UUID route, I'd prefer it if networkID computation didn't fail if createSeed happens to fail. Otherwise we might not send out network change notifications, and that's worse IMO.

This helps to prevent linkability of users in the same network.

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