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.nl> wrote:
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



--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation