seems like a privacy issue, we don't make other user preferences available for the same reason...

In T430471#12063493, @Johannnes89 wrote:

seems like a privacy issue, we don't make other user preferences available for the same reason...

However, interface administrators already have the ability to modify any user's interface experience, so they are already granted a high level of trust.

In T430471#12063498, @Niepodkoloryzowany wrote:

In T430471#12063493, @Johannnes89 wrote:

seems like a privacy issue, we don't make other user preferences available for the same reason...

However, interface administrators already have the ability to modify any user's interface experience, so they are already granted a high level of trust.

Interfaceadminship currently does not require signing an NDA of any description, though, so there is no requirement of confidentiality that prevents them from divulging the information about user preferences to anyone else.

Interface administrators could be granted this access conditional upon signing an NDA. If they require access to this information, they would be required to sign the agreement. Otherwise, they do not receive those access rights.

Uhm, do you want to create another group of "preference-viewers"?

@Niepodkoloryzowany , having the right to investigate which users use a particular gadget seems like a breach of the user's privacy, and as an interface admin, I dislike any situations involving the interface admin right to sign an NDA for accessing users' private information (especially if I need to disclose my real-life legal name and other personal information). Instead, it is better if there is a mechanism for normal users to be able to give feedback through "Preference > Gadget" if there are any associated errors (instead of searching which MediaWiki namespace the gadget is located), and if interface admin(s) need to change/delete any very outdated gadget the interface admins can automatically e-mail or anonymously inform the associated users if needed.

In T430471#12064141, @neriah wrote:

Uhm, do you want to create another group of "preference-viewers"?

Yes, that sounds reasonable.

In T430471#12064420, @Hakimi97 wrote:

I dislike the situation that requires the interface admin right to sign NDA in any situations involving accessing user's private information

You would not be required to sign an NDA unless you specifically choose to access that information. You would retain your interface administrator rights regardless, but simply would not be able to view which gadgets a user has enabled.

the interface admins can automatically e-mail or anonymously inform the associated users if needed

Great idea. This could be implemented alongside the features proposed here.

In T430471#12064420, @Hakimi97 wrote:

@Niepodkoloryzowany , having the right to investigate which users use a particular gadget seems like a breach of the user's privacy, and as an interface admin, I dislike any situations involving the interface admin right to sign an NDA for accessing users' private information (especially if I need to disclose my real-life legal name and other personal information). Instead, it is better if there is a mechanism for normal users to be able to give feedback through "Preference > Gadget" if there are any associated errors (instead of searching which MediaWiki namespace the gadget is located), and if interface admin(s) need to change/delete any very outdated gadget the interface admins can automatically e-mail or anonymously inform the associated users if needed.

Re: disclosing personal info, these kinds of onwiki disclosures would typically require signing L37, which does not require the disclosure of personal information on the part of the rights holder. Heck, even the more involved WMF-NDA requires only a valid email AFAIR.

In T430471#12065648, @Soda wrote:

Re: disclosing personal info, these kinds of onwiki disclosures would typically require signing L37, which does not require the disclosure of personal information on the part of the rights holder. Heck, even the more involved WMF-NDA requires only a valid email AFAIR.

The point is simple. I don't want the interface adminship to be tightly associated with handling of any sensitive personal information requiring any signature of documents involving disclosure of any private information such as legal names. I as an interface admin would not want to access (therefore I will respect) other people's private preferences or information, and at the same time I do not want other people to know my real life information without my consent.

Unless if the right such as "preference-viewers" or "gadget-preference-viewers" is (1) independent from the interface adminship; or (2) a further add-on in a voluntary manner, but not tightly or completely integrated with interface adminship.

If we are doing this, we should just expose it to all users. I don't get what's so private about gadget preferences and beta feature opt-ins. Everyone can already see what user scripts someone is using. If anything, it'll improve transparency.

I am currently preparing a script update on ruwiki. This modification will potentially introduce a bug for users who have a specific gadget enabled. To prevent this disruption, I need to identify which users are actively using that gadget and implement an alternative update specifically for them.

I am a bit confused by this rationale, especially without having an actual example for it. There is already a way to check if a certain gadget is enabled in JS code, it doesn’t necessarily require knowing any individual users’ settings. Gadget updates should not break other gadgets.

I think the actual use cases for this are described a bit too nebulously. I am sure it can help in debugging but I am not sure whether that won’t be helped by an easier solution of implementing a button that copies debugging data for users in some understandable enough format. Then the control is still on the user side but interface admins can ask for that data.

In T430471#12070411, @stjn wrote:

I am currently preparing a script update on ruwiki. This modification will potentially introduce a bug for users who have a specific gadget enabled. To prevent this disruption, I need to identify which users are actively using that gadget and implement an alternative update specifically for them.

I am a bit confused by this rationale, especially without having an actual example for it. There is already a way to check if a certain gadget is enabled in JS code, it doesn’t necessarily require knowing any individual users’ settings. Gadget updates should not break other gadgets.

I think the actual use cases for this are described a bit too nebulously. I am sure it can help in debugging but I am not sure whether that won’t be helped by an easier solution of implementing a button that copies debugging data for users in some understandable enough format. Then the control is still on the user side but interface admins can ask for that data.

I've had situations come in VPT or on Discord where having access to the list of gadgets would be useful in debugging issues for a user (especially once userscripts are ruled out). To me, it's useful not as an interface admin but as a "should I go create a phab ticket," but I can see how it can be considered interface administrator adjacent for smaller wikis.

implementing a button that copies debugging data for users in some understandable enough format

Great idea! This completely avoids the need for NDAs while keeping the user in full control. While they would still need to find and click the button, it is a significant improvement over the current manual alternative.

By the way, a workaround to extract similar information already exists, but it is clumsy and unintuitive:

1. Go to the gadget preferences list.
2. Change any checkbox, but do not save the page yet.
3. Open the browser's developer console and switch to the Network tab.
4. Save the preferences.
5. In the Network tab, select the first request (Special:Preferences)
6. Navigate to the Payload tab.
7. Click "View source" and copy the data (where 1 indicates enabled and 0 indicates disabled).

what's so private about gadget preferences

I have the same question. To play devil's advocate, there is a text-to-speech gadget on ruwiki. A counter-argument might be that its users could be visually impaired, making them potential targets for harassment. However, a reader might simply prefer listening to articles without having any disability. Even if they do, the community strictly handles harassment via blocks.

I think the gadget preferences are safe to share.

I think the actual use cases for this are described a bit too nebulously.

True. I kept the initial examples brief to avoid taking the thread off-topic, but here is some concrete context:

• Recently, Convenient Discussions (CD) unexpectedly began merging a user's replies with the text under them. It took time to discover that this was an isolated clash with the ruwiki user-rights flags gadget. The issue would have been resolved faster if the affected user could have simply exported a list of their enabled gadgets.
• You are right regarding the other specific gadget scenario. I managed to deploy a local patch inside the script itself. However, the broader problem remains: when complex scripts clash, identifying the culprit without a clear preference log is more difficult.

In T430471#12071690, @Niepodkoloryzowany wrote:

implementing a button that copies debugging data for users in some understandable enough format

Great idea! This completely avoids the need for NDAs while keeping the user in full control. While they would still need to find and click the button, it is a significant improvement over the current manual alternative.

By the way, a workaround to extract similar information already exists, but it is clumsy and unintuitive:

1. Go to the gadget preferences list.
2. Change any checkbox, but do not save the page yet.
3. Open the browser's developer console and switch to the Network tab.
4. Save the preferences.
5. In the Network tab, select the first request (Special:Preferences)
6. Navigate to the Payload tab.
7. Click "View source" and copy the data (where 1 indicates enabled and 0 indicates disabled).

Getting folks to run the following snippet in DevTools is an easier method to get the same output:

JSON.stringify(
  Object.fromEntries(
    Object.entries( mw.user.options.values )
      .filter( ( [ key ] ) => key.startsWith( 'gadget-' ) )
  )
);

Here you go:
https://meta.wikimedia.org/w/index.php?title=User:Nux/CopyMyGadgets.js

Using in common.js:
importScript('meta:User:Nux/CopyMyGadgets.js')
Using in global.js:
importScript('User:Nux/CopyMyGadgets.js')

In T430471#12115966, @stjn wrote:

I’ll assume the closing is accidental because nothing has been ‘done’ in relation to this task (so at best it could be declined with an explanation for it).

Yes, sorry. Silly Phabricator defaults.