User talk:BDavis (WMF)/Archives/2022

Is it not allowed to add a sponsored link to my application in ToolHub?

I added a link to my application which is a VSCode Extension, but its was immediately reverted by you without any reasons. And I added it again but encountered the same result. So, are there any specific instructions? --Rowe Wilson Frederisk Holme (talk) 09:12, 3 January 2022 (UTC)

@Rowe Wilson Frederisk Holme the "Sponsor" field in a toolinfo record is meant to allow crediting a sponsoring organization (like the Wikimedia Foundation or another grant providing institution) and not for links to donation websites. -- BDavis (WMF) (talk) 16:38, 4 January 2022 (UTC)

OK, I've misunderstood the purpose of this field.--Rowe Wilson Frederisk Holme (talk) 09:36, 11 January 2022 (UTC)

OAuth Discussion Question

Hi Bryan - when approving my development OAuth provider for Teyora you said in the approval comment that "this is a scary collection of rights which may require discussion to become more than localhost". I was wondering what sort of discussion you'd like to see as I am planning to apply for a production provider for user testing in the coming months and there doesn't seem to be any clear documentation on this.

I have posted a detailed description of what each permission does at Teyora/Permissions, and, of course, it will be WMCS hosted and use the FOSS stack as described in my Cloud VPS project request (phab:T298354). Ed6767 (talk) 23:13, 23 January 2022 (UTC)

@Ed6767, I feel like we should pull @Tgr (WMF) into this discussion. Gergő is much better than I am at explaining which OAuth grant permissions invest a larger than normal amount of trust in the connected application. Watchlist access and viewing restricted and suppressed information are the rights that stood out to me as atypical when I reviewed and approved the development grant.

Cloud VPS hosting and public source are both compensating controls which do help increase the transparency and trust of your project. Speculative permission collection ("these permissions are not yet used by Teyora, but are provided for extensions that may want to provide you with this functionality") does not increase trust, at least my trust. -- BDavis (WMF) (talk) 16:46, 24 January 2022 (UTC)

I understand that the permission set is quite large and powerful. However, I think that in my opinion, and from the point of view of Teyora being an extendable web based Huggle alternative with extra features for admins etc., the permissions are perfectly reasonable and the JWT method I've used is an adequate precaution to ensure that tokens aren't stored on the backend, whilst also mitigating Wikimedia account hijacking on the client side.

Regarding "speculative permission collection", as noted these are included for extension developers to use, but as they're not required and I can remove them from a production provider if it is a genuine concern.

As for watchlist access and viewing restricted and suppressed information - users will be able to suppress and delete revisions within Teyora and having to send them out of the app to a Wiki page would be a pretty big continuity and workflow issue for people who may have to deal with a lot of suppressed edits. Watchlist access I think would also be pretty commonplace - many people choose to add user talk pages to their watchlist after warning, or watch a page that is being vandalised and would want to be notified of changes without having to leave the app. I hope this addresses some of your concerns :) Ed6767 (talk) 20:36, 24 January 2022 (UTC)

@Ed6767 thanks for working on Teyora! We could certainly use better and more user-friendly patrol tooling.

Without having seen the implementation, in general the main concern is the application getting hijacked, either via some WMCS problem (it's a shared hosting environment, so necessarily more risky), or some mistake on the side of the maintainers (adding or handing over to a new person who turns out to have bad intentions, low account security, someone gets access to the code repository etc) which is something we have very little insight into as every app uses different development/deployment tooling. So we are trying to prevent the proliferation of apps with potentially dangerous access as much as possible.

T290790 contains a WIP risk hierarchy (very open to feedback). I think in the case of Teyora all the risky permissions, except maybe restricted log access, are in the "provided for extensions" bucket, and it would be preferable to only request those when an extension developer actually asks for them - registering a new application and changing your OAuth keys is easy enough. Specifically:

• import: historically this used to be insecure (you could perform edits you'd otherwise not be allowed to do by importing pages); I'm not sure how much that is still true today. In any case, this doesn't seem relevant for a patrol app.
• viewrestrictedlogs/oversight: I don't think these are dangerous in practice but we require an NDA for people to get access to this data so maybe we should double-check there aren't any legal problems with providing it to an application. Probably fine though. (checkuser would be more concerning both in terms of attacker motivation and potential damage.)
• mergehistory: this might be the only MediaWiki action that's practically impossible to revert, so a hijacked or buggy application could cause huge disruption. Then again, the same goes for delete/undelete (which can be used for poor man's history merge) and that's important and common enough that it's not feasible to restrict it too much, so I think we'll have to live with this one.

I think watchlist access isn't really dangerous - maybe an attacker could use it for doxxing and such, but it does seem pretty unlikely. Tgr (WMF) (talk) 02:10, 25 January 2022 (UTC)

@Tgr (WMF) - Thanks, and those are valid concerns I've been aiming to mitigate as much as possible with the current implementation, but I have some ideas to secure it even more if necessary.

Regarding hijacking, currently the JWT encryption key is held in a file which in theory means if somebody got a hold of the key they could decrypt a JWT and access the data inside (OAuth tokens) - however, it would be possible for the key to be randomly generated and stored in memory every time the backend server is started so code would have to be changed to obtain the tokens, the downside of this (or, another upside depending on how you look at it) being that if the backend crashes or needs to restart everyone would be logged out because all tokens would be invalidated.

For the vast majority of requests, such as viewrestrictedlogs/oversight, Teyora will simply act as a proxy to decrypt the JWT and retrieve the OAuth tokens and no information will be stored, and it would be vastly uneconomical to do so anyway. In cases where data may be stored for caching, analytics and algorithm data like reverting, warning, reporting or blocking, I'd only be storing the Wiki ID, target user, the user completing the action, and revision ID and revert/warning/block reason. There's no reason to collect more information than that functionally speaking and all that information is available on-wiki.

As for WMCS, that is a risk, and ultimately who is added as a maintainer will be at my discretion, but I will ensure I take every step possible to verify trust and also require logging of every change being made on the backend. However, for the time being I see no reason to add anyone else to the maintainers list and instead opt for all changes being made through the GitLab, then requiring that I manually review and push all changes to the server before deploying an update. If there is a better way in your opinion, I'm very open to working with you all to ensure the deployment is secure. Ed6767 (talk) 12:37, 25 January 2022 (UTC)

@Ed6767 thanks, those are very reasonable precautions. I checked the existing providers, and none of these are entirely without precedent (although just barely) - WiDaR has checkuser access, histsearch has oversight access, WikiImporter can import. Nothing has historymerge access but that grant doesn't really give anything new compared to delete (I'm not sure why it even exists). Lots of apps have watchlist read or write access.

So in my (non-authoritative) optinion all of those permissions are acceptable if the application follows best practices (which it sounds like it does) and there's a good use case for them. I don't see a good reason to grant permissions in advance though - extension developers can work with the localhost version to write and test their code, and it's easy to update the app registration when an extension is done and needs extra rights.

I'll ask around about the grants that give access to private information, just in case, but I don't foresee any problems there. Tgr (WMF) (talk) 02:33, 26 January 2022 (UTC)

@Tgr (WMF), that's great, thanks so much for your help. Your suggestion that I come to apply for the production grants I'll only apply for ones necessary at that time seems best especially when the grants can be modified after the fact (which I didn't know of). Keep me in the loop regarding private information grants :) Ed6767 (talk) 15:33, 26 January 2022 (UTC)

@Ed6767: A passing functionary's remark, for what it's worth—it would be a good idea to take a look at Risker's checklist. Although Teyora isn't a "content creation extension" (or an extension at all) there are some considerations which you may find useful 🙂 -- TNT (talk • she/her) 04:57, 27 January 2022 (UTC)

@TheresNoTime, Teyora/Risker's Checklist exists if you're interested :) Ed6767 (talk) 03:27, 28 January 2022 (UTC)

OAuth

Hey! Thank you for approval of my OAuth 2.0 client (42ded93884cf4fac3eaec64cd0909092). But I can't figure out why oauth2/access_token calls keep returning the invalid_client error. Is it possible that my client doesn't have sufficient grant types? I found phab:T297888, and the issue looks very similar. Could I ask you to check it in the database? — putnik 13:40, 23 March 2022 (UTC)

Unfortunately, yes your grant shows the oarc_oauth2_allowed_grants=[] problem. I left a note on the related task. -- BDavis (WMF) (talk) 15:10, 23 March 2022 (UTC)

Thank you. What you think is the best option to do next? Do I need to register a new client or is it worth to wait for a bug fix? — putnik 19:09, 23 March 2022 (UTC)

@Putnik I think that registering again is probably the easiest and quickest way for you to move forward. Per the comment at phab:T297888#7735122 the current guess at a cause for the configuration error is an initial validation failure when submitting the request. -- BDavis (WMF) (talk) 19:23, 23 March 2022 (UTC)

I'm not sure if re-registration helped. I tried to do it without validation failure (after the error I've opened a new tab and filled it out correctly), but it seems that the result is unsuccessful. Could you check it again? — putnik 10:46, 24 March 2022 (UTC)

@Putnik, your 74ec0c483b8d708113ad83a49da413b4 client did end up with the same problem. I have been sneaky and manually edited the database to try and fix it. Hopefully the grant will work for you now. -- BDavis (WMF) (talk) 16:38, 24 March 2022 (UTC)

Update to commentlinks.js gadget

I am about to update my comment links gadget to link the comment's timestamp rather than add a separate [ link ] button. If you prefer the old style, that gadget will be available at commentlinks-v1.js. As before, this gadget is experimental and may stop working at any time, see T275729 for the task to make this a proper feature. Thanks, ESanders (WMF) (talk) 12:11, 30 September 2022 (UTC)