In T237669#5724576, @Dbrant wrote:

Cool, this is now deployed in the latest Android app. I'm untagging Android, and leaving iOS to handle on their end.

@Prtksxna We also talked about the sticky highlights showing up in the filters at one point. Are you still planning to add that in?

In T175587#5682669, @dbarratt wrote:

In T175587#5681956, @Niharika wrote:

For each UA we have the three parts. For 22 records, that is 66 pieces. So for each library, how many of those were right/wrong would be helpful to know.

I updated the spreadsheet: https://docs.google.com/spreadsheets/d/1Hgv3waJxzBMuHiFIDyWBSNJqPO5ILHUYhWLnYfAwvGM/edit?usp=sharing
I gave Green to the best answer, Yellow to an acceptable answer, but not complete (from what I could tell), Blue for an acceptable answer, but maybe not accurate, and Red for an answer that is wrong. I only subtracted credit for the completely wrong answers.

In T175587#5681950, @dbarratt wrote:

In T175587#5681931, @Niharika wrote:

It would be helpful to quantify how often we got accurate results from both the libraries.

What do you mean? errr... how do you define accuracy? Can you provide an example?

In T175587#5681677, @dbarratt wrote:

I retrieved 20 random User Agent strings from the cu_changes table on eswiki and put them into a spreadsheet and compared the parsing of devicedetector.net and whichbrowser.net.
The results can be seen here:
https://docs.google.com/spreadsheets/d/1Hgv3waJxzBMuHiFIDyWBSNJqPO5ILHUYhWLnYfAwvGM/edit?usp=sharing
whichbrowser.net (and their free library) seems a lot better than the alternative (on average).

In T238603#5675849, @dbarratt wrote:

The only difference between this field and that one, is that this field allows multiple values. As far as I know, everyone who has access to CheckUser should also have access to Block, so everyone is already familiar with this pattern.

While this is true, I would not presume everyone using CheckUser does frequent Special:Block too. I'm kinda leaning towards Prateek's point about providing some more guidance here as this UI is pretty different from what they are using currently.
@cwylo Do you have an opinion on this ticket?

Thanks for that information, @JJMC89. As I mentioned, we have no intention of doing that. :)

@Prtksxna assigning this to you for the mock and design specs.

@Prtksxna Putting this in your column for the couple mocks needed.

In T237034#5676979, @AronManning wrote:

@Niharika the field is short for a textual description and a link. Either a longer 2-line textfield or 2 fields would be enough.
In any case, the comments should instruct to paste the link to the cause and form validation should check its presence.
The check is a bit simpler with a separate field, but it is less busy with one longer field.

In T175587#5676999, @dbarratt wrote:

In T175587#5676994, @Niharika wrote:

I see. I think we need some baseline estimate of how often it is wrong. If it's like 1 in 10 cases, then maybe we could split up the UA and give them a disclaimer that it might be wrong and give them an option to see the complete UA. If it's 1 in 2 cases, we probably don't want to do the splitting.

makes sense. I'm not sure how we would figure that out other than taking some random UAs and testing them manually.

In T200938#5676995, @dbarratt wrote:

or rather, the problem does not exist on he, it only exists on en.

In T175587#5676963, @dbarratt wrote:

In T175587#5676953, @Niharika wrote:

Hmm, if we can have a sense of how inaccurate a parsed UA is (say, 80% or 20%) then based on that we can decide whether to display the complete UA or not. One of the use cases of this is to also know when the user might have spoofed their UA.

Hmm... I guess since it's three parts, I guess we are really saying how accurate each part is.. I'm not sure you can tell this without looking at it.
For instance, with the UA generated in T237669#5661529
throwing WikipediaApp/2.7.50302-r-2019-11-13 (Android 8.1.0; Phone; Nexus 6P Build/OPM6.171019.030.E1) Alpha Channel into https://whichbrowser.net/tryout/ we get: Android Browser on a Huawei Nexus 6P running Android 8.1.0. two of those parts are correct, but one isn't.

@dbarratt Has this been deployed already? In that case we can verify if the problem exists on the actual hewiki.

Thanks for doing an investigation on this, @dbarratt.

One strategy could be to utilize a parsing library. Sadly, a lot of user agents lie, so it might not be completely accurate.

Hmm, if we can have a sense of how inaccurate a parsed UA is (say, 80% or 20%) then based on that we can decide whether to display the complete UA or not. One of the use cases of this is to also know when the user might have spoofed their UA.

@Dbrant @Charlotte Yes, that seems about right. Thanks for picking this up!

In T237034#5673142, @AronManning wrote:

The cause of doing CU is often an SPI or a user request or suspicious edit. In any case, the reason should link to this cause and the form should require this link for the reason.
Would a separate field for the link be better or a two-line reason field?
With two separate fields I think it would be cleaner:

• Getting the data, sorting and pagination
• Display the data
• Building the filters and filtering
• Adding the new data records

@Prtksxna Flagging this for you.

I actually kinda like this bug. :)

In T237034#5672654, @dbarratt wrote:

@Prtksxna This seems really busy to me...

the placeholder text seems unnecessary.... do we even need it at all?

In T237296#5665416, @dmaza wrote:

@Niharika What is the acceptance criteria for this task? Should ip users also be supported as part of this or is it supporting only registered accounts enough?

In T237034#5661181, @Tchanders wrote:

@Niharika @Prtksxna A few questions about the acceptance criteria:

• Input box for usernames. [...]
  • Placeholder: Add users

Should the placeholder be the default "Add more..." instead? Might make more sense since this is not just for adding users.

Yeah, it can be a user or IP address. I'm a bit iffy about Add more... as it kinda means they already added something. How about Add username or IP address instead?

• Input box for the reason for the check.
  • [...]
  • Placeholder text: Example: Investigating Apples for suspected sockpuppetry

Are we OK with the fact that Apples can be a real username?

Ooh, good catch! It could be Investigating User:... for suspected sockpuppetry. @Prtksxna thoughts?

Finally, just wanted to ask whether we should make the help text inline? It's the default and recommended for accessibility, though it does make the page a bit busier:

inline: true	inline: false

Should be @Prtksxna's call.

@Tchanders Should we poke more people for code review on this?

In T236981#5656727, @Tchanders wrote:

Proposed acceptance criteria in more detail:

• Name tbc

I updated the description with the name after the previous round of comments. It's Special:Investigate.

• If config is set to unavailable, the special page URL points to a page with the title "No such special page" (similar to Special:Mute)

Yep.

• If config is set to available:
  • Unblocked user with 'checkuser' right sees the page title and a submit button that does nothing
  • Blocked user with 'checkuser' right sees a user blocked error (similar to Special:CheckUser)
  • User with 'checkuser' right sees the special page listed at Special:SpecialPages under the section "Users and rights" (similar to Special:CheckUser)
  • User without 'checkuser' right sees a permissions error

Yep, all this sounds good. I will copy this to the task description. Thanks for more detail.

In T236981#5647987, @AronManning wrote:

Imo CheckUserTest or CheckUserDev or CheckUserAlpha. I assume when it goes to production (new version enabled in config) it will replace the current CheckUser and this in-development name will be dropped.

@AronManning The redesigned version is so radically different that I don't expect folks to switch back and forth often. The idea is that we will remove the older page at some point and the new page will just be Special:CheckUser. Until then I would like the page name to be distinctive enough so when we share it people do not confuse the new page with the old.
I ran this by our Community Engagement folks and their recommendation was to go with Special:Investigate that Prateek chose for the mocks. So let's go with that.
@dbarratt ^ I'll update the ticket.

In T174553#5648183, @kaldari wrote:

@Niharika - This is something that AHT team wants, correct? Huji's already done some work to add the geoip2 library and some related MaxMind components as a dependency to core (which actually dates back to our work on LoginNotify), so we could go ahead and request an initial security review, if this seems like it would be useful to you (for CentralAuth and/or LoginNotify).

@AronManning Don't worry, I can take care of adding the mocks and expanding the task description. I think the mocks are likely to change based on the on-wiki feedback, hence I'm holding back on adding those for now.

In T237669#5645494, @Dbrant wrote:

This isn't very difficult to add, but wouldn't it have security implications? (i.e. wouldn't it reduce the anonymity of the user?)

@AronManning Can you provide more context on this ticket? I'm not sure what's being requested and why.

Resolving this as it seems low risk and Dom already has a bunch on his plate (column).