Where to store OAuth application information? - Wikitech-l

Pine W

11 Aug 11 Aug

6:43 a.m.

We currently have editable pages on Wikimedia sites with important legal strings, and AFAIK no one has caused a noteworthy incident by editing or vandalizing them. (Cc'ing Maggie to ask for verification.) However, the term "attack vector" gets my attention. Is there a way to keep the pages in wiki format while hardening OAuth against attempted attacks and simple mistakes? By the way, I would support development of more sophisticated access controls for wiki pages in general. Pine On Aug 10, 2015 6:23 PM, "Gergo Tisza" <gtisza(a)wikimedia.org> wrote:

...

tl;dr should OAuth [1] (the system by which external tools can register to be "Wikimedia applications" and users can grant them the right to act in their name) rely on community-maintained description pages or profile forms filled by application authors? --------------- Hi all, I would like to request wider input to decide which way Extension:OAuth should go. An OAuth application needs to provide various pieces of information (a description; a privacy policy; a link to the author; a link to the application; links to the source code, developer documentation and bug tracker; and icons and screenshots). There are two fundamentally different approaches to do this: either maintain the information as editable wiki pages and have the software extract it from there; or make the developer of the application provide the information via some web form on a Special:* page and store it in the database. Extension description pages are an example of the first approach; profile pages in pretty much any non-MediaWiki software are an example of the second one. Some of the benefits and drawbacks of using wiki pages: * they require very little development; * it's a workflow we have a lot of experience with, and have high-quality tools to support it (templates, editing tools, automated updates etc.); * the information schema can be extended without the need to update software / change DB schemas; * easier to open up editing to anyone since there are mature change tracking / anti-abuse tools in MediaWiki (but even so, open editing would be somewhat scary - some fields might have legal strings attached or become attack vectors); * limited access control (MediaWiki namespace pages could be used, as they are e.g. for gadgets, to limit editing of certain information to admins, but something like "owner can edit own application + OAuth admins can edit all aplications" is not possible); * hard to access from the software in a structured way - one could rely on naming conventions (e.g. the icon is always at File:OAuth-<application name>-icon.png) or use Wikidata somehow, but both of those sound awkward; * design/usability/interface options are limited. Some previous discussion on the issue can be found in T58946 [2] and T60193 [3]. Right now OAuth application descriptions are stored in the database, but in a very rough form (there is just a name and a plaintext description), so switching to wiki pages would not be that hard. Once we have a well-refined system, though, transitiong from one option to the other would be more painful, so I'd rather have a discussion about it now than a year from now. Which approach would you prefer? [1] https://www.mediawiki.org/wiki/Extension:OAuth [2] https://phabricator.wikimedia.org/T58946 [3] https://phabricator.wikimedia.org/T60193 _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply

Oliver Keyes

4:38 p.m.

I am familiar with other incidents myself, and would not consider moving away from the existing system "premature optimization". I would consider it "sanity". We exist in a situation where wikis can individually customise, say, the copyright release associated with edits. Changing that is A Good Thing. On 11 August 2015 at 12:29, Luis Villa <lvilla(a)wikimedia.org> wrote:

...

On Mon, Aug 10, 2015 at 11:43 PM, Pine W <wiki.pine(a)gmail.com> wrote:

We currently have editable pages on Wikimedia sites with important legal strings, and AFAIK no one has caused a noteworthy incident by editing or vandalizing them.

There are several cases that I'm aware of where legally-significant text was edited in legally-meaningful ways for varying lengths of time, ranging from hours to (in some cases) months. Without going into details, for example, one edit made us non-compliant with California law in a way that had opened up other large websites to large fines. Thankfully none of them have been used against us, that I know of, so perhaps locking them down would be a case of premature optimization. Luis -- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely share in the sum of all knowledge.* _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Oliver Keyes Count Logula Wikimedia Foundation

Reply

Oliver Keyes

5:04 p.m.

Given that MediaWiki namespace pages are already admin-only, not really. On 11 August 2015 at 12:44, Pine W <wiki.pine(a)gmail.com> wrote:

...

Would keeping sensitive pages in wikitext format under "full protection" (meaning that only local administrators can edit) be sufficient? Pine On Aug 11, 2015 9:38 AM, "Oliver Keyes" <okeyes(a)wikimedia.org> wrote:

I am familiar with other incidents myself, and would not consider moving away from the existing system "premature optimization". I would consider it "sanity". We exist in a situation where wikis can individually customise, say, the copyright release associated with edits. Changing that is A Good Thing. On 11 August 2015 at 12:29, Luis Villa <lvilla(a)wikimedia.org> wrote:

On Mon, Aug 10, 2015 at 11:43 PM, Pine W <wiki.pine(a)gmail.com> wrote:

We currently have editable pages on Wikimedia sites with important legal strings, and AFAIK no one has caused a noteworthy incident by editing or vandalizing them.

There are several cases that I'm aware of where legally-significant text was edited in legally-meaningful ways for varying lengths of time,

ranging

from hours to (in some cases) months. Without going into details, for example, one edit made us non-compliant with California law in a way that had opened up other large websites to large fines. Thankfully none of

them

have been used against us, that I know of, so perhaps locking them down would be a case of premature optimization. Luis -- Luis Villa Sr. Director of Community Engagement Wikimedia Foundation *Working towards a world in which every single human being can freely

share

in the sum of all knowledge.* _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Oliver Keyes Count Logula Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Oliver Keyes Count Logula Wikimedia Foundation

Reply

Pine W

5:25 p.m.

Ok, it sounds like using a Special:* for OAuth info would be prudent. That's unfortunate for usability reasons, but the security considerations appear to be more important. Pine

Reply

Ricordisamoa

6:15 p.m.

Il 11/08/2015 20:10, Risker ha scritto:

...

On 11 August 2015 at 13:07, Mr. Stradivarius <misterstrad(a)gmail.com> wrote:

On Wed, Aug 12, 2015 at 1:44 AM, Pine W <wiki.pine(a)gmail.com> wrote:

Would keeping sensitive pages in wikitext format under "full protection" (meaning that only local administrators can edit) be sufficient?

This is asking for trouble. Even if all our admins acted sensibly all the time - and if you've been around here long enough, you know that's not true - there is still the very real possibility of admin accounts being compromised. I have personally fixed XSS flaws in widely used user scripts, and a determined attacker would be highly likely to find others. This is best kept out of the control of admins so that if an admin account is compromised it will not affect other accounts. _______________________________________________

Just so we're clear here - "locking down" these kinds of pages is pretty much what the Superprotect extension does. It is (to put it mildly) not well-loved by the Wikimedia community; however, it may be possible to persuade them that there are certain key pages that must not even be altered by local admins (copyright being the primary example, but probably some others as well). This would require very diplomatic discussion. And given that this is the 'anniversary' of the introduction of Superprotect, it might be better to wait for a while to really have that conversation. Risker/Anne _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

OAuth applications' details must remain editable by the app's author. Superprotect does not account for them.

Reply

Risker

6:25 p.m.

Well, therein lies the problem. If a "community" goes rogue, and wants to selectively change the copyright terms for their project, stewards (under the current standards of behaviour) would pretty much be obligated to do that - even though it's contrary to a lot of other things. We can't put volunteers into a position where they have to choose between overall WMF policy and direct requests from projects that are within their scope to carry out. Frankly, nobody (stewards or otherwise) should be able to change certain pages without very intense discussion and, in some cases, Board approval. With employees, they'd lose access immediately and be reverted before being shown the door for cause - there is a very strong disincentive to carry out these acts without authorization. For volunteers, the worst that happens is they'll have permissions removed, and even that would be a fight as we have seen with past examples; it's vanishingly unlikely they'd even get blocked, let alone banned. Risker/Anne On 11 August 2015 at 14:17, Pine W <wiki.pine(a)gmail.com> wrote:

...

Yeah, the same thought crossed my mind. Unfortunately, superprotect has such a well-earned negative reputation in the community that I don't think it will ever be welcomed even in situations like this where it might be sensible. An alternative might be to devolve the superprotect right to stewards, who could apply it to certain highly sensitive pages at the request of the community. Pine _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply

Gergo Tisza

9:11 p.m.

To refocus the discussion on OAuth (no superprotect and copyright issues here please :), the field with legal relevance is the privacy policy of the application (and maybe its terms of service if we add such a thing in the future). Any time you use, say, CropTool, the tool operator has access to checkuser-type information. The tool operator publishes a privacy policy (which is legally binding for them), and the OAuth admins approve or reject the tool based on that policy (for example if it contains that the operator can pass private data to any third party, that tool application is going to get rejected). If the tool operator can change the privacy policy without any oversight, that can be problematic. On the other hand, if they can't change it at all, that's also problematic, and we probably won't have the resources to build some kind of complicated change review system anytime soon. As for attack vectors, some of the information (such as the application's icon and short description) is presented on the authorization dialog and users will have to decide based on that dialog whether they trust that application to, say, delete pages in their name. An attacker could create an innocent description, get the tool approved, and then change the description to pretend it is some other, widely trusted tool, and trick users into authorizing it.

Reply

Legoktm

6:11 p.m.

Hi, On 08/10/2015 06:23 PM, Gergo Tisza wrote:

...

tl;dr should OAuth [1] (the system by which external tools can register to be "Wikimedia applications" and users can grant them the right to act in their name) rely on community-maintained description pages or profile forms filled by application authors?

Wiki pages please :)

...

--------------- Some of the benefits and drawbacks of using wiki pages: * they require very little development; * it's a workflow we have a lot of experience with, and have high-quality tools to support it (templates, editing tools, automated updates etc.); * the information schema can be extended without the need to update software / change DB schemas; * easier to open up editing to anyone since there are mature change tracking / anti-abuse tools in MediaWiki (but even so, open editing would be somewhat scary - some fields might have legal strings attached or become attack vectors);

I assume these wiki pages would be some kind of structured ContentHandler pages? We could restrict editing those fields to the application owners then?

...

* limited access control (MediaWiki namespace pages could be used, as they are e.g. for gadgets, to limit editing of certain information to admins, but something like "owner can edit own application + OAuth admins can edit all aplications" is not possible);

If it goes in a separate namespace, you can

...

* hard to access from the software in a structured way - one could rely on naming conventions (e.g. the icon is always at File:OAuth-<application name>-icon.png) or use Wikidata somehow, but both of those sound awkward;

If the data is stored in a structured format, it should be easy to access.

...

* design/usability/interface options are limited.

In what way? ContentHandler lets you override and customize pretty much everything... -- Legoktm

Reply

Dan Garry

12 Aug 12 Aug

3 a.m.

As many OAuth tools are semi-automated, they're prime candidates for being interesting ways to help our most active users make contributions on mobile devices while they're on the go. The OAuth workflow is pretty poorly designed for this at the moment, but it has a lot of potential. Generally, mobile experiences are easier to create if the data backing them is structured data that can be interpreted onto a mobile screen in a way that's mobile friendly. Putting the information into wikipages, practically speaking, makes that much harder. Given the other advantages to this also detailed in this thread, I'd prefer to see us take the more structured approach. A wikipage could be used if necessary as a fallback for more information. Dan On 10 August 2015 at 18:23, Gergo Tisza <gtisza(a)wikimedia.org> wrote:

...

tl;dr should OAuth [1] (the system by which external tools can register to be "Wikimedia applications" and users can grant them the right to act in their name) rely on community-maintained description pages or profile forms filled by application authors? --------------- Hi all, I would like to request wider input to decide which way Extension:OAuth should go. An OAuth application needs to provide various pieces of information (a description; a privacy policy; a link to the author; a link to the application; links to the source code, developer documentation and bug tracker; and icons and screenshots). There are two fundamentally different approaches to do this: either maintain the information as editable wiki pages and have the software extract it from there; or make the developer of the application provide the information via some web form on a Special:* page and store it in the database. Extension description pages are an example of the first approach; profile pages in pretty much any non-MediaWiki software are an example of the second one. Some of the benefits and drawbacks of using wiki pages: * they require very little development; * it's a workflow we have a lot of experience with, and have high-quality tools to support it (templates, editing tools, automated updates etc.); * the information schema can be extended without the need to update software / change DB schemas; * easier to open up editing to anyone since there are mature change tracking / anti-abuse tools in MediaWiki (but even so, open editing would be somewhat scary - some fields might have legal strings attached or become attack vectors); * limited access control (MediaWiki namespace pages could be used, as they are e.g. for gadgets, to limit editing of certain information to admins, but something like "owner can edit own application + OAuth admins can edit all aplications" is not possible); * hard to access from the software in a structured way - one could rely on naming conventions (e.g. the icon is always at File:OAuth-<application name>-icon.png) or use Wikidata somehow, but both of those sound awkward; * design/usability/interface options are limited. Some previous discussion on the issue can be found in T58946 [2] and T60193 [3]. Right now OAuth application descriptions are stored in the database, but in a very rough form (there is just a name and a plaintext description), so switching to wiki pages would not be that hard. Once we have a well-refined system, though, transitiong from one option to the other would be more painful, so I'd rather have a discussion about it now than a year from now. Which approach would you prefer? [1] https://www.mediawiki.org/wiki/Extension:OAuth [2] https://phabricator.wikimedia.org/T58946 [3] https://phabricator.wikimedia.org/T60193 _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation

Reply