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