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