How would you know to go to that url?

conti wrote:

(In reply to comment #1)

How would you know to go to that url?

I found out about it by having a look at all logs about User:Secret (http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=&user=&page=User%3ASecret&year=&month=-1). In the end, you'd have to know what to look for, of course, but it's still something that shouldn't happen in the first place.

rockmfr wrote:

Isn't the point of RevisionDelete to hide the content of logs, and not to hide the fact that there was a logged action? By design, the logs are still visible. There's no bug here.

conti wrote:

It's not a problem that the log entry still exists. The problem is that you can -search- the deleted log entries. If the log entry "XYZ's phone number is 555-12345" is deleted, you can search for "555-12345" at Special:Log and find that (deleted) log entry. That way you can easily find out what a deleted log entry contained, with the use of some brute force.

herd wrote:

That way you can easily find out what a deleted log
entry contained, with the use of some brute force.

Giving this a try, there is (as of this writing) one oversight-level hidden revision on test.wikipedia. With some guessing, I was able to narrow this down to a log entry, in the deletion log, by DerHexer:
http://test.wikipedia.org/w/index.php?title=Special%3ALog&type=delete&user=DerHexer&page=&year=&month=-1

Now, finding the target of this deletion log entry is a bit of work but...

There are less than 10,000 deleted articles in the main namespace (and a few thousand in all the rest combined), and approx 20,000 undeleted pages in all namespaces. As it is a deletion entry, it applies to either a deleted article, a deleted revision, an undeletion, or a visibility change on a revision or log entry.

If it is a log entry, you could brute force which type of log via Special:Log/delete?page=Special:Log/block Special:Log/delete Special:Log/makebot etc.

If it is a deleted page you could brute force by checking the Special:Log?page= of all deleted pages (using deletedrevs via the API to find the titles, which requires a sysop flag, but as this is an oversight-level hidden entry, it should be hidden from sysops). This is shown automatically on action=edit, for example: http://test.wikipedia.org/w/index.php?title=Category:APPER&action=edit&redlink=1 so someone may find it accidentally.

If it is a deleted revision of a non-deleted page, you could find it via action=history of all undeleted pages.

Note that none of these methods seem to expose the comment content of a hidden log entry, but the user and target page/log title can be found.

As for the alternate case, of trying to expose a hidden revision, it doesn't seem you can expose the content or comment of the revision either, just find the user and target page in the same method as above.

Note that deleted log entries are _not_ shown in the API, nor do any of the list=logevents parameters match deleted information. The UI and API should probably match behavior.

(In reply to comment #5)

Note that deleted log entries are _not_ shown in the API, nor do any of the
list=logevents parameters match deleted information. The UI and API should
probably match behavior.

That's because the API uses WHERE log_deleted = 0 (or rev_deleted = 0) for all its queries. Turns out that's for the best right now, since the revisiondelete feature seems to be kind of broken in terms of how well it hides things. I'm waiting for this to be resolved before supporting it in the API.

Fixed in r46807

(In reply to comment #6)

(In reply to comment #5)

Note that deleted log entries are _not_ shown in the API, nor do any of the
list=logevents parameters match deleted information. The UI and API should
probably match behavior.

That's because the API uses WHERE log_deleted = 0 (or rev_deleted = 0) for all
its queries. Turns out that's for the best right now, since the revisiondelete
feature seems to be kind of broken in terms of how well it hides things. I'm
waiting for this to be resolved before supporting it in the API.

Fixed in r46842: API behavior is now consistent with UI behavior.