Gerrit change 107389[1] adds RevDel support to various API query modules, so for example a user with the 'deletedhistory' right will be able to retrieve the user and summary from prop=revisions.
This will cause some changes:
- list=deletedrevs, list=filearchive, list=recentchanges, and list=watchlist formerly would not return any information at all for entries where any field was revision-deleted. These entries will now be returned. "hidden" indicators will be provided as is done for modules such as prop=revisions. - prop=imageinfo, list=logevents, prop=revisions, and list=usercontribs will now return field values in addition to the "hidden" indicators, if the user has the necessary user rights. - When "hidden" indicators are returned, a new indicator "suppressed" may also be returned to indicate whether suppression was activated. - prop=imageinfo will now return info for revision-deleted files. - list=logevents, when searching by user or title, will no longer skip revisions where the user or title was revision-deleted if the requesting user has the deletedhistory right. - list=usercontributions will now look at the correct user rights (deletedhistory and suppressrevision, not hideuser) to determine whether to hide revision-deleted contributions.
All clients should be updated to expect rows with hidden fields for deletedrevs, filearchive, recentchanges, and watchlist, and clients with advanced permissions should be updated to properly handle (and to not publicly reveal) the data for revision-deleted fields from these modules as well as imageinfo, logevents, revisions, and usercontribs.
These changes will be deployed to WMF wikis with 1.23wmf11, see https://www.mediawiki.org/wiki/MediaWiki_1.23/Roadmap for the schedule.
[1]: https://gerrit.wikimedia.org/r/#/c/107389/
Replying via gmane as I was not on-list before.
Brad Jorsch (Anomie <bjorsch <at> wikimedia.org> writes:
Gerrit change 107389[1] adds RevDel support to various API query modules,
so for example a user with the 'deletedhistory' right will be able to retrieve the user and summary from prop=revisions.
This will cause some changes:
(...)
All clients should be updated to expect rows with hidden fields for
deletedrevs, filearchive, recentchanges, and watchlist, and clients with advanced permissions should be updated to properly handle (and to not publicly reveal) the data for revision-deleted fields from these modules as well as imageinfo, logevents, revisions, and usercontribs.
I think this change is being rolled out without enough discussion on its technical and privacy aspects. In addition, it's being rolled out way too quickly (two weeks for a breaking change is insane, as far as I'm concerned).
A few points I'm surprised by:
First of all, was a breaking change strictly necessary? I see no mention of this in you e-mail, and I can find no discussion on this on either mediawiki-api, wikitech-l, the bugs or the gerrit patch.
Secondly, is making this a breaking change the smart thing to do? This opens a possibility for leaking private data if existing applications are not adapted. Of course, by large, they will *not* be adapted. Why would they? They are still functioning correctly - at least on simple inspection.
I think a more sensible option would be to add a parameter to explicitly request hidden revisions. No breaking change necesary, and no information leakage potential.
Then there's documentation. I have no clue what the changes in the actual returned data look like, and there are no examples as far as I can see. I also have no clue how I should test correctly hiding information. I don't have a test wiki set up, and I don't have the deletedhistory right on any wmf wikis.
I would suggest to postpone deployment, and to reconsider making an (as far as I can see unnecessary) breaking change.
Merlijn
I did consider adding a parameter (to each of these several modules) for explicitly requesting the hidden data. But considering the likely uses, I thought this would be overkill: * Most clients don't have the necessary user rights to retrieve the privacy-sensitive information anyway. * Those that do (e.g. user scripts used by admins) are likely not using this information publicly.
Given the above, it seems to me that the number of clients that actually have to be fixed is very small. On the other hand, adding the parameter requires additional documentation and logic to check this parameter everywhere.
As for examples, it's described: instead of getting "commenthidden" or "comment", you might get both if you have the needed rights. And for certain modules you might start getting results that have "commenthidden" where those result elements would be completely omitted in the past.
On Thu, Jan 23, 2014 at 1:45 PM, Merlijn van Deen valhallasw@arctus.nlwrote:
Replying via gmane as I was not on-list before.
Brad Jorsch (Anomie <bjorsch <at> wikimedia.org> writes:
Gerrit change 107389[1] adds RevDel support to various API query modules,
so for example a user with the 'deletedhistory' right will be able to retrieve the user and summary from prop=revisions.
This will cause some changes:
(...)
All clients should be updated to expect rows with hidden fields for
deletedrevs, filearchive, recentchanges, and watchlist, and clients with advanced permissions should be updated to properly handle (and to not publicly reveal) the data for revision-deleted fields from these modules as well as imageinfo, logevents, revisions, and usercontribs.
I think this change is being rolled out without enough discussion on its technical and privacy aspects. In addition, it's being rolled out way too quickly (two weeks for a breaking change is insane, as far as I'm concerned).
A few points I'm surprised by:
First of all, was a breaking change strictly necessary? I see no mention of this in you e-mail, and I can find no discussion on this on either mediawiki-api, wikitech-l, the bugs or the gerrit patch.
Secondly, is making this a breaking change the smart thing to do? This opens a possibility for leaking private data if existing applications are not adapted. Of course, by large, they will *not* be adapted. Why would they? They are still functioning correctly - at least on simple inspection.
I think a more sensible option would be to add a parameter to explicitly request hidden revisions. No breaking change necesary, and no information leakage potential.
Then there's documentation. I have no clue what the changes in the actual returned data look like, and there are no examples as far as I can see. I also have no clue how I should test correctly hiding information. I don't have a test wiki set up, and I don't have the deletedhistory right on any wmf wikis.
I would suggest to postpone deployment, and to reconsider making an (as far as I can see unnecessary) breaking change.
Merlijn
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
mediawiki-api@lists.wikimedia.org