Some questions:

• Are there other places in Extension:CheckUser where we display user agent data?
• How should we display the client hint data? Add a row within the existing table cell? Add another column?
  • If we implement a normalized structure for storing the client hint data, we could potentially have multiple columns for each attribute in the client hints data object. Do we want that?

In T337942#8895749, @kostajh wrote:

Some questions:

• Are there other places in Extension:CheckUser where we display user agent data?

The table shown holds a summary of the data shown below in the results, and is displayed when using either 'Get edits' or 'Get users'. On 'Get edits' the associated user agent data is shown for each item stored by CheckUser (like edits or log actions) next to the IP address used to edit. On 'Get users' the data is grouped per user/IP in a bullet point list.

Special:Investigate shows the user agent data in both the "Timeline" and "IP & User agents" tab. On the Timeline tab, the data is shown in a similar way to Special:CheckUser's 'Get edits' mode. "IP & User agents" tab shows this data in a table as shown in https://commons.wikimedia.org/wiki/File:IP_options.png (grouping by combinations of user agent and IP per user).

This data is accessible via the CheckUser API in a similar way to Special:CheckUser but instead providing the data as JSON.

• How should we display the client hint data? Add a row within the existing table cell? Add another column?
  • If we implement a normalized structure for storing the client hint data, we could potentially have multiple columns for each attribute in the client hints data object. Do we want that?

With respect to this table, the script currently only summarises what is shown below by parsing the HTML using JavaScript. This script is also used to allow copying of the results to the CheckUser wiki in a condensed format. Only including the client hint data in this table (and not below in the full results) would change the intention of this table (which is to summarise the results by displaying the IPs and user agents used by each user).

Furthermore, this table currently has issues with being too wide on smaller screens. Adding new columns could cause the height of the table to expand too much when the device screen width is small. However, the client hint data would still be useful in this table so a way round this should be found.

Some screenshots of where the UA is displayed, along with how the data are grouped:

Where	Grouped by	Screenshot
CheckUser 'get edits' log line	not grouped
CheckUser 'get edits' table	user
CheckUser 'get users' log line	user/IP
CheckUser 'get users' table	user/IP
Investigate 'IPs & UAs' table	user/IP/UA
Investigate 'Timeline' log line	not grouped

Thoughts on Special:CheckUser:

• For the log lines, a concatenated string might make most sense
• For the tables, there's no relationship offered between the IP addresses and the UA strings that belong to the same IP/UA combination - example:
  
  ...so we could either add another column or just append to the UA list

Thoughts on Special:Investigate:

• For the timeline log lines, a concatenated string. Or not at all - just rely on the IPs & UAs table
• For the IPs & UAs table, should we change how we group the data now? There could be multiple client hint vectors for one given username/IP/UA combination. How could we display these?
  • Add one new column and show concatenated, as a bullet list (similar to the Special:CheckUser tables)?
  • Add a new column for each data type, and display a bullet list in each cell (that's currently 10 more columns, including Sec-CH-UA)?
  • Group by user/IP/UA/client hints, but this might risk being too granular?

Could we just display client hints in one place? If exploring the structure is important, then the Special:Investigate table might make most sense. Or is a concatenated string OK to start with?

I'm currently exploring what the CheckUser table would look like it we broke Client Hints data into distinct columns.

I'd love to get thoughts on how we might group attributes together to minimise the number of table columns?

Example set of data:

• Architecture: x86
• Bitness: 64
• Brands: Not.A/Brand 8
• Brands: Chromium 114
• Brands: Google Chrome 114
• Full version list: Not.A/Brand 8.0.0.0
• Full version list: Chromium 114.0.5735.199
• Full version list: Google Chrome 114.0.5735.199
• Mobile: No
• Model: (empty string)
• Platform: Windows
• Platform version: 15.0.0

This is my attempt:

PLATFORM
Architecture: x86
Bitness: 64
Platform: Windows
Platform version: 15.0.0

BROWSER
Brands: Not.A/Brand 8
Brands: Chromium 114
Brands: Google Chrome 114
Full version list: Not.A/Brand 8.0.0.0
Full version list: Chromium 114.0.5735.199
Full version list: Google Chrome 114.0.5735.199

DEVICE
Mobile: No
Model: (empty string)

@Dreamy_Jazz and @kostajh

Mockup is attached showing 3 options for adding Client Hints to Check User table:

Latest designs are attached.

1. Table with additional Client Hints column:

2. Log line with Client Hints added after User Agent string:

cc @Dreamy_Jazz

Change 958024 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[operations/mediawiki-config@master] clienthints: Pin wgCheckUserDisplayClientHints to false

https://gerrit.wikimedia.org/r/958024

Change 958024 merged by jenkins-bot:

[operations/mediawiki-config@master] clienthints: Pin wgCheckUserDisplayClientHints to false

https://gerrit.wikimedia.org/r/958024

Mentioned in SAL (#wikimedia-operations) [2023-09-18T20:05:05Z] <cjming@deploy1002> Started scap: Backport for [[gerrit:958024|clienthints: Pin wgCheckUserDisplayClientHints to false (T337942)]]

Mentioned in SAL (#wikimedia-operations) [2023-09-18T20:06:32Z] <cjming@deploy1002> cjming and dreamyjazz: Backport for [[gerrit:958024|clienthints: Pin wgCheckUserDisplayClientHints to false (T337942)]] synced to the testservers mwdebug1001.eqiad.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2002.codfw.wmnet, mwdebug2001.codfw.wmnet, and mw-debug kubernetes deployment (accessible via k8s-experimental XWD option)

Mentioned in SAL (#wikimedia-operations) [2023-09-18T20:13:23Z] <cjming@deploy1002> Finished scap: Backport for [[gerrit:958024|clienthints: Pin wgCheckUserDisplayClientHints to false (T337942)]] (duration: 08m 18s)

Change 964545 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[operations/mediawiki-config@master] Enable display of Client Hints data on all wikis

https://gerrit.wikimedia.org/r/964545

Change 964545 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable display of Client Hints data on all wikis

https://gerrit.wikimedia.org/r/964545

Mentioned in SAL (#wikimedia-operations) [2023-10-16T20:10:16Z] <cjming@deploy2002> Started scap: Backport for [[gerrit:964545|Enable display of Client Hints data on all wikis (T341110 T337942)]]

Mentioned in SAL (#wikimedia-operations) [2023-10-16T20:11:29Z] <cjming@deploy2002> dreamyjazz and cjming: Backport for [[gerrit:964545|Enable display of Client Hints data on all wikis (T341110 T337942)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2023-10-16T20:18:33Z] <cjming@deploy2002> Finished scap: Backport for [[gerrit:964545|Enable display of Client Hints data on all wikis (T341110 T337942)]] (duration: 08m 17s)