another raw idea:
- would the bridge auth be willing to publish a randomly generated AS
identifier (regenerated daily) that allows new bridges added on the same day to be grouped by that identifier without directly disclosing the AS itself.
Bridges don't necessarily contact the bridge auth before producing their descriptors. So we'd need a protocol change to do this.
All that is needed is the IP address and fingerprint of the bridge and that is known by the bridge auth. There should not be any requirement to involve the bridges themself?
How could we avoid an adversary brute-forcing all the possible ASs and days/hours?
I'm not sure I understand what you mean by brute-forcing in this case since I would not suggest any deterministic algorithm (like a hash) that takes an ASname and a timestamp and produces a string but just a AS number -> random id mapping, stored for a day or an hour and deleted after that.
Another way an attacker could take advantage of this: unique AS sign-up rate patterns "everyday there are about x new bridges in AS y" so it doesn't help much if we change the random AS id daily.
Anyway I do not think anything like that will be implemented and very simple detection based on first_seen, nickname, platform, .. is already possible without AS level information.
David, I'm glad you asked about first_seen=1970-01-01 on metrics-team@, I was wondering about the same thing. A bug affecting that timestamp would certainly be rather bad for anything using first_seen as a grouping data point.