Note the relevant L3SC discussion is happening here: https://app.asana.com/0/0/1208478147018066/f

Per conversation with @XiaoXiao-WMF and discussions in https://app.asana.com/0/0/1208478147018066/f, would like to put this on hold (or at least, keep it as something we are thinking about and discussing rather than actively working on) while we are working out if integration with hCaptcha is possible.

In T381031#10370230, @kostajh wrote:

Note the relevant L3SC discussion is happening here: https://app.asana.com/0/0/1208478147018066/f

Per conversation with @XiaoXiao-WMF and discussions in https://app.asana.com/0/0/1208478147018066/f, would like to put this on hold (or at least, keep it as something we are thinking about and discussing rather than actively working on) while we are working out if integration with hCaptcha is possible.

OK, I thought this through some more and discussed with @SCherukuwada, my updated view is that we should move forward with this hypothesis in Q2/Q3, because:

• even though hCaptcha will have a superior unique device identifier mechanism, we hedge our bets by not relying entirely on hCaptcha
• the technical implementation seems feasible within a quarter of work
• we can have a working solution in production sooner, based on established infrastructure (client hints collection + CheckUser)
• we can work through legal and privacy concerns in this hypothesis that will apply to other work (e.g. hCaptcha)

I'd suggest removing the ml-model-requests tag--AIUI, no model would be needed here.

Thank you for starting this. As an enwiki CU, I appreciate the effort WMF is devoting to Trust and Safety Tools. Would it be possible for project CUs to weigh in more on their needs for such a tool? In particular, I will note that project CUs don't normally limit themselves to looking for exact matches (IP and User-Agent exactly matching), and so if this ever comes to supplant the raw availability of user-agents or client hints, the MVP of the unique device identifier locality-sensitive hash would then have to include include:

• The ability to tell how similar one UA (or UA-equivalent) is to another (not just if it is identical)
• The ability to tell how typical or atypical the UA is to the overall pool (for example, to be able to detect very old UAs, which is one common but not universal hallmark of UA spoofing, which is quite common on the projects)
• Some ability to "look under the hood" to understand what drove the similarity score
• More advanced ability to provide context on how the ISP or geography handles UAs, IP sharing, etc.

I'd be glad to chat more if that's helpful. Thank you!

In T381031#10381167, @L235 wrote:

Thank you for starting this. As an enwiki CU, I appreciate the effort WMF is devoting to Trust and Safety Tools. Would it be possible for project CUs to weigh in more on their needs for such a tool?

Yes, definitely! This is work intended to support the efforts of CUs. We're still in the early stages of seeking legal, security, privacy and safety center approval, but it's good to start talking about details of implementation and requests.

In particular, I will note that project CUs don't normally limit themselves to looking for exact matches (IP and User-Agent exactly matching), and so if this ever comes to supplant the raw availability of user-agents or client hints

I don't think there are plans to replace legacy user agent, user agent client hints, or IP address with the work described in this task. That would continue as-is.

, the MVP of the unique device identifier locality-sensitive hash would then have to include include:

• The ability to tell how similar one UA (or UA-equivalent) is to another (not just if it is
• The ability to tell how typical or atypical the UA is to the overall pool (for example, to be able to detect very old UAs, which is one common but not universal hallmark of UA spoofing, which is quite common on the projects)
• Some ability to "look under the hood" to understand what drove the similarity score
• More advanced ability to provide context on how the ISP or geography handles UAs, IP sharing, etc.

Looking under the hood would be challenging (from a privacy/legal point of view). If this is approved, what we'd likely end up doing is hashing e.g. the list of fonts and the canvas fingerprint and incorporating them into a locality-sensitive hash using a salt, and storing that.

To give an idea of what that might look like, some very rough, not-reviewed proof of concept code generates output like this:

Hash 1: c2f92a630e01080b
Hash 2: d2f92a630e01080b
Similarity Score: 96.88%

Changes in input:
- Removed fonts: 1
- Canvas hash: unchanged
- Model changed: MacBookPro18,2 -> MacBookPro18,3
- Platform version changed: 13.2.1 -> 13.2.2
- Browser version changed in fullVersionList

so, by changing one item in the font list, leaving canvas fingerprint the same, and slightly modifying the client hints, you'll get two hashes that look very similar, and are visually identifiable as being similar.

I'd be glad to chat more if that's helpful. Thank you!

Sure, would be happy to. Perhaps on Discord on the Wikimedia Community server? Or we could set up a video meeting if you prefer, just let me know.

Update ext.checkUser.clientHints to obtain list of fonts and generate a canvas fingerprint

Have we exhausted all avenues of passive fingerprinting? Canvas and font fingerprinting feel like a massive overreach in terms of violating a user's privacy in a way that a user cannot explicitly opt out of. (Outside of ceasing to edit Wikipedia)

In T381031#10384123, @Soda wrote:

Update ext.checkUser.clientHints to obtain list of fonts and generate a canvas fingerprint

Have we exhausted all avenues of passive fingerprinting? Canvas and font fingerprinting feel like a massive overreach in terms of violating a user's privacy in a way that a user cannot explicitly opt out of. (Outside of ceasing to edit Wikipedia)

Yes, we will also be looking at other features within CheckUser along the same lines of thoughts, e.g. hashing, or ways to reduce entropy.

In T381031#10384123, @Soda wrote:

Update ext.checkUser.clientHints to obtain list of fonts and generate a canvas fingerprint

Have we exhausted all avenues of passive fingerprinting? Canvas and font fingerprinting feel like a massive overreach in terms of violating a user's privacy in a way that a user cannot explicitly opt out of. (Outside of ceasing to edit Wikipedia)

If you have suggestions for alternatives, I would be happy to hear them. I'm also not sure where to draw the line between passive/active fingerprinting, and if that is the important thing to focus on in regard to privacy. For example, obtaining user agent http-client-hints data happens via JS that fires after an edit is saved. I suppose that would be active fingerprinting?

Some assumptions for this task:

• abuse from repeat visitors is a significant problem
• IP blocking sometimes causes collateral damage
• IP blocking is sometimes ineffective
• being able to mitigate actions based on device similarity scores allows for more precisely targeting bad actors

Moving from the quarterly lane to in-progress as I'm closing the quarterly lane. Please set/update the deadline for the task.

The hypothesis is completed as per the scope in Q3. Here is the report: https://docs.google.com/document/d/1mmEgAJP3fh3H8p9LnWbUTrrPxew9Ola-og0JgUax404/edit?tab=t.0

Can we please get some version of the report publicized?

In T381031#10787653, @Izno wrote:

Can we please get some version of the report publicized?

Hi @Izno, yes of course, I've pasted a copy of the report below.

The tl;dr from this work is that Research folks worked on defining an algorithm for generating a locality sensitive hash to allow taking a variety of inputs and generating hashes that can be compared for similarity against each other. We'll write more about next steps for experimenting with that algorithm soon (cc @sgrabarczuk).

Summary

Created and tested various hashing algorithms to compare client hints and other browser signal data.

Provided recommendations for a working algorithm and similarity measure that is ready to be converted into production usage.

Provided suggestions, in the context of production, to best protect the privacy of users and editors.

Potential use cases

1. Integration with CheckUser: Assist CheckUser for comparing, and reduce their cognitive loads to compare Client Hints data as well as other browser signals.
2. Integration with LoginNotify: Automatically identify registered users that have been blocked previously.

Algorithm

The algorithm is hashing based. It takes client hints data and other browser signals to provide one hash per record. The hash ensures the privacy of the browser signatures, while preserving the similarity between the original data points.

Analysis

We performed a number of analyses around the weighted hashing algorithm and distance metrics. Due to the lack of canvas hash and list of fonts, we created synthetic data for analytic purposes.

Output usage and benchmarking (will be finalized in Q4): https://gitlab.wikimedia.org/repos/research/research-datasets/-/blob/mnz/fp-samples/notebooks/ua\_hash\_samples.ipynb