[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #55 from Gregor Hagedorn g.m.haged...@gmail.com 2012-03-12 07:05:10 UTC --- (In reply to comment #54) Automatically creating accounts should only be done, and logged, with the users permission. I think that part is sensible and can be relatively easily implemented. If a user as a SUL account, there is an existing condition in the code where the wiki presently creates a user account. Insert some dialogue here, asking whether to create an account on this wiki. If you say no, you cannot edit or set preferences. I would not mind being asked this every time. If I visit a wiki regularly, I either can bite the bullet of inconvenience (I would have little motivation to do so) or I just say OK. The really annyoing thing is, as described, to be registered for chance visits and even receiving notifications by mail in languages one does not even read. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #56 from Philippe Verdy verd...@wanadoo.fr 2012-03-12 07:15:21 UTC --- What I propose is simpler: you don't need the dialog. Because users will have to open their user preferences to register the permissions. Eventually, you would get a dialog, asking if you want to really edit a page before setting your preferences. If you say no, the edits will still be logged like anonymous users, and not associated to your account whose user preferences have not been set. Note that when being created as autocreated user account, all permissions (notably emails) are set to NO for almost everyone (except a few selected global admins for handling very specific cases related to security and abuses). That's why you don't need the permission dialog when just visiting a new wiki by following an interwiki link (possibly even not the one that was expected, for example by clicking the wrong language). Those permissions will only pass to YES after the user has opened his preferences and SAVED them to CONFIRM those permissions, effectively changing the status only at that time to a really registered (and logged) user. However there are good reasons for automatically creating accounts: this just serves to reserve the user name, for later use. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Marcin Cieślak marcin.cies...@gmail.com changed: What|Removed |Added CC||marcin.cies...@gmail.com --- Comment #49 from Marcin Cieślak marcin.cies...@gmail.com 2012-03-12 02:08:20 UTC --- Creating an account is not a read-only action. I understand that visiting other wikis creates a potentially annoying effect of being tracked, but if arguments raised in this bug to remove logging are valid, they also apply to a purely local user registration. If somebody registers on a standalone wiki solely for the purpose to set preferences, why should their *first* registration be logged at all, too? Consequently, [[Special:ListUsers]] would become something like [[Special:ListEditors]] and [[Special:Log/newusers]] should be removed. I don't think that this is intended. If you are really interested in finding out if a known global user did ever visit some particular wiki, you can go to [[User:username]] and you will be told if the local user exists or not. Trying to fix all possible information disclosure channels about created-but-otherwise-inactive account is probably not feasible at all. The only concern that remains is the *timing* issue, i.e. that somebody would be able to corelate unsuspecting logged-in wiki user using some third-party network service. It is an equivalent of seeing over the shoulder that somebody registers on any MediaWiki site and later going back to that MediaWiki installation to check timestamps of the new user log. SUL automatic creation is only way easier (one click) and we have many many wikis to try the trick. If this is indeed a problem, the only reasonable solution to this is a confirmation box (similar to what we have when trying to purge the webpage anonymously) to ask for confirmation to add a local instance of a SUL account. But that would be a usability nightmare for many I guess, with a confusing, Checkpoint-Charlie style message that will be very hard to get right and even harder to translate - You are leaving the friendlier part of the Wikimedia cluster. Clicking on this button will create a copy of your account on this wiki instance. This fact will be logged publicly with your username. Do you agree? or Click button number two to continue browsing using you IP address, which, by they way, you will reveal by editing something here. To me it looks worse than those dreaded you are leaving this webstite and entering unfriendly Internet messages that some sites use for external links. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #50 from Philippe Verdy verd...@wanadoo.fr 2012-03-12 02:33:00 UTC --- I confirm that this is still an issue, after I unepectedly staring to receive welcome emails created by bots scanning the list of new users, just because I just visited one page on that wiki written in a language that I absolutely cannot read (it was in the Armenian Wikipedia), just by following an interwiki link only to see if the target page was existing. I was NOT given any chance to set my preferences first, my account was created *without* any notice, and their users (and bots) were allowed to send me any number of emails (directly or by writing to my user page), without my prior authorization. This was very bad, because I could not even decipher the contents of this email (but even if I could, the unlimited automatic authorization was NEVER explicitly granted). For me, any user account that is created automatically by a simple SUL-connected account should not be considered a new registered user it should have a different status. The status should become a true new registered user only when the user will either : - (1) visit his own User Preferences page (and confirmed the registration by STORING the changes after first defining his prefered language, and then found and set the email email options), or - (2) starts creating and editing a page on the wiki (including his own user page, where he will have the possibility to explain on which wiki his main user page is, and which languages he can at least read) and RECORDS his changes in that page. A mere visit of any new wiki without storing any info should NEVER be logged anywhere in any publicly visible area. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #51 from Philippe Verdy verd...@wanadoo.fr 2012-03-12 02:34:14 UTC --- So in summary, what I want is a new user status: autocreated user account. which will be turned into registered user account only when the user will actually STORE something on that wiki or in his preferences. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #52 from Philippe Verdy verd...@wanadoo.fr 2012-03-12 02:47:50 UTC --- And as long as a user account status is autocreated: - *NOBODY* (not even local admins without asking to a global administrator that will decide themselves what to do with unused user accounts with the autocreated status, that someone else would like to use for himself) can use the function to send emails to that user using the wiki as a gateway. This should behave as if the user did not exist for now (even if nobody else can start creating a new account with that same user name). - if someone else writes to the user's talk page, *EVERYTHING* posted will *NEVER* be notified to the user by ANY emails coming from that wiki (even if the user sees that there's something in his user page, and visits it, without answering or modifiying it). Simple, effective, and does not require any complex mechanisms with the SUL account. I just want that SUL only creates account automatically with this new status. No confirmation is needed, users won't be alarmed. This basic security can be implemented locally, it will not hurt server's performances on that local wiki, it will just deny some attempts made by others to use unconfirmed functions (notably sending any kind of emails). This basic security is specially critical for small wikis in languages spoken by a very small community, because these wikis are not enough administrated, and some commercial spammers are also attempting to use this lack of administration to contact a lot of known Wikipedians registered and active on other wikis : they don't need to write to them on these active wikis, they jsut have to find a minority wiki to attempt to write to their user page there, or to use the email to user function of that wiki. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Marcin Cieślak marcin.cies...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||vasi...@gmail.com Component|General/Unknown |CentralAuth Version|unspecified |any Resolution||LATER Product|Wikimedia |MediaWiki extensions Target Milestone|--- |Mysterious future --- Comment #53 from Marcin Cieślak marcin.cies...@gmail.com 2012-03-12 04:58:04 UTC --- Enough said, I think everybody understands what this is about. I would recommend re-opening this bug if there is a major change to the way SUL works or somebody actually proposes some code to fix this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 John Mark Vandenberg jay...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|LATER | --- Comment #54 from John Mark Vandenberg jay...@gmail.com 2012-03-12 05:44:17 UTC --- Browsing a website should not create an account. Automatically creating accounts should only be done, and logged, with the users permission. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 John Mark Vandenberg jay...@gmail.com changed: What|Removed |Added Priority|Lowest |High Target Milestone|Mysterious future |--- -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Gregor Hagedorn g.m.haged...@gmail.com changed: What|Removed |Added CC||g.m.haged...@gmail.com --- Comment #48 from Gregor Hagedorn g.m.haged...@gmail.com 2011-04-05 06:49:23 UTC --- The wikimedia implementation/use of the mediawiki software clearly VIOLATES the wikimedia foundation privacy policy, which says: Reading projects: No more information on users and other visitors reading pages is collected than is typically collected in server logs by web sites. Aside from the above raw log data collected for general purposes, page visits do not expose a visitor's identity publicly. Sampled raw log data may include the IP address of any user, but it is not reproduced publicly. Contrary to the policy, READING a new wiki is PUBLICLY exposed (on those wikis where a bot reads new user accounts and creates welcome pages) when a user has previously signed in to another wikimedia wiki. I do not consider the option to disable single-sign as a practical solution. A single sign-on to commons, en.wikipedia, de.wikipedia, perhaps mediawiki.org may be desired, but recording chance read-only-visits at any number of other wikis would still be surprising. Solutions: a) fix the software so that user creation occurs only after an edit b) change the privacy policy to read: Reading projects: No more information on users and other visitors reading pages is collected than is typically collected in server logs by web sites. However, when using single-sign on, any visit to a wikimedia site you had not previously visited may be recorded publicly. Aside from the above raw log data collected for general purposes, page visits do not expose a visitor's identity publicly. Sampled raw log data may include the IP address of any user, but it is not reproduced publicly. c) prohibit bots that create welcome pages after user creation without corresponding edits. Gregor -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 John Mark Vandenberg jay...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #43 from John Mark Vandenberg jay...@gmail.com 2011-04-01 11:36:04 UTC --- This hasn't solved the problem described. It has been hidden, poorly. I have randomly picked a new autocreated user, Nane2011, to demonstrate. Whereas before the privacy vuln required looking at the user creation log, which is now blank https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Special:Logtype=newusersuser=Nane2011 Now, the exact same information is visible here: https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Special%3AListUsersusername=Nane2011group=limit=1 The information is also available at: http://toolserver.org/~vvv/sulutil.php?user=Nane2011 And it is distributed to the toolserver. Moreover, hiding the new user creation entry is _not_ the solution. That just hides it, and then the wiki database contains information which it needs to keep hidden in order to protect the privacy of its users. Any number of oversights/screw ups with data management can result in accidental release of this information. Avoid creating data that you want to remain hidden. And if you are going to continue with this 'hiding' approach, please revert the current 'fix' until it has been properly built and implemented, otherwise users have the false expectation that this information is hidden. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #44 from Mark A. Hershberger m...@everybody.org 2011-04-01 15:26:33 UTC --- I've opened Bug #28366 and Bug #28367 to address the issues you've raised. If you want the current solution completely reverted, I suggest you open a new bug to that effect. I recommend you look at Bug #542 (fixed, closed) and later bugs like Bug #27527, Bug #28182, etc for an example of how to log issues of problems that fixing a bug creates. Even if you disagree with the fix and think it is the wrong thing to do, reopening this bug is not appropriate. The fix is done. It has been applied and deployed. It is appropriate to *file a new bug* if you think the old behavior should be restored. Re-opening an old bug is not the correct way to address the current situation. Avoid creating data that you want to remain hidden. If you think that is what is needed, I suggest opening a new bug to that effect. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Blocks||28369 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 MZMcBride b...@mzmcbride.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||b...@mzmcbride.com Resolution|FIXED | --- Comment #45 from MZMcBride b...@mzmcbride.com 2011-04-01 15:40:43 UTC --- (In reply to comment #44) I've opened Bug #28366 and Bug #28367 to address the issues you've raised. I've resolved both of those bugs as invalid. If you want the current solution completely reverted, I suggest you open a new bug to that effect. I recommend you look at Bug #542 (fixed, closed) and later bugs like Bug #27527, Bug #28182, etc for an example of how to log issues of problems that fixing a bug creates. No, this is the bug tracking this problem. If this bug hasn't been adequately addressed, it should remain open. Even if you disagree with the fix and think it is the wrong thing to do, reopening this bug is not appropriate. The fix is done. It has been applied and deployed. It is appropriate to *file a new bug* if you think the old behavior should be restored. Re-opening an old bug is not the correct way to address the current situation. Your assumption that the fix is done is flawed. The fix isn't done because it didn't resolve this bug adequately. This bug needs to remain open until this issue is properly addressed. Avoid creating data that you want to remain hidden. If you think that is what is needed, I suggest opening a new bug to that effect. This bug is about limiting what data is propagated and in what circumstances. There's no need for a separate bug. Re-opening this bug. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #46 from Church of emacs church.of.emacs...@gmail.com 2011-04-01 15:48:10 UTC --- (after edit-conflict, post is directed at comment 44) Facts: a) This bug report is about a privacy vulnerability b) The fix fails to solve a) c) The fix has annoying consequences I agree that c) might not be sufficient to reopen this bug, but b) most certainly is. Note that Comment 43 brought a completely new aspect into the discussion – it's not anymore about inconvenient side-effects, it's that the fix fails to do what it claims (i.e. removing the privacy vulnerability). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #47 from Chad H. innocentkil...@gmail.com 2011-04-01 16:20:27 UTC --- Reverted the change in r85128. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Blocks||28227 -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #40 from Mark A. Hershberger m...@everybody.org 2011-03-24 21:19:03 UTC --- (In reply to comment #31) (In reply to comment #29) As all of the information that people have felt necessary to reproducing or describing the problem has been given in this report and it has all been dealt with, this bug should be closed. Sorry, but how has it all been dealt with? A proper fix (login log local account creation only on write actions such as edits) That is one of many fixes. Consider the title of the bug: Auto account creation creates privacy vulnerability. The description of this privacy vulnerability then says that it comes from logging the auto account creation. The solution chosen kept auto account creation but made it so it wasn't logged. What you describe is a new problem: Simply disabling the log has severe consequences for keeping out abusive usernames. I've asked for the opinion of other admins on German Wikipedia and they affirm it hinders their efforts and that there are already trolls taking advantage of the log being removed. Please use Bug #28227 to discuss this new problem. If you think the only proper fix is local account creation should not happen on HTTP GETs, then that, too, is a new bug. You may not like the solution that was provided for this bug, but re-opening it is not likely to change CentralAuth to your liking. This bug was about a privacy concern, and that has been addressed. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Chad H. innocentkil...@gmail.com changed: What|Removed |Added CC||innocentkil...@gmail.com --- Comment #41 from Chad H. innocentkil...@gmail.com 2011-03-25 00:13:20 UTC --- (In reply to comment #40) You may not like the solution that was provided for this bug, but re-opening it is not likely to change CentralAuth to your liking. This bug was about a privacy concern, and that has been addressed. The solution was bad. It should be reverted, and this bug reopened pending a *real* solution. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 John Mark Vandenberg jay...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Component|CentralAuth |General/Unknown Version|any |unspecified Depends on|14950 | Resolution|DUPLICATE | Product|MediaWiki extensions|Wikimedia --- Comment #27 from John Mark Vandenberg jay...@gmail.com 2011-03-23 06:12:06 UTC --- Unless you have read the otrs-wiki page which provides more info about this bug, please don't close it. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com --- Comment #28 from Roan Kattouw roan.katt...@gmail.com 2011-03-23 15:42:41 UTC --- (In reply to comment #27) Unless you have read the otrs-wiki page which provides more info about this bug, please don't close it. You mean the one that's not public so I can't read it? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Highest |Lowest Severity|critical|normal -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #29 from Mark A. Hershberger m...@everybody.org 2011-03-23 16:19:05 UTC --- (In reply to comment #27) Unless you have read the otrs-wiki page which provides more info about this bug, please don't close it. We can only deal with the information in this bug report. Comment #4 summarizes the OTRS wiki, so that is all the information I have. As all of the information that people have felt necessary to reproducing or describing the problem has been given in this report and it has all been dealt with, this bug should be closed. Do not reopen this bug, but feel free to open a new bug with new information. That would be an appropriate action if a problem reported in OTRS has not been dealt with yet and you wanted to report that problem. The problems contained in this bug report have been dealt with. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #30 from Platonides platoni...@gmail.com 2011-03-23 17:44:47 UTC --- You can get an idea on OTRS wiki from the more verbose Comment #4. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Church of emacs church.of.emacs...@gmail.com changed: What|Removed |Added URL|http://otrs-wiki.wikimedia. |https://bugzilla.wikimedia. |org/wiki/User:Church_of_ema |org/show_bug.cgi?id=19161#c |cs/mw_critical_bug |4 --- Comment #31 from Church of emacs church.of.emacs...@gmail.com 2011-03-23 20:05:54 UTC --- The OTRS wiki page does not contain more information than Comment #4. Sorry for the confusion – when I opened this bug almost two years ago, I somehow thought that most Devs would have access to the OTRS wiki. (In reply to comment #29) As all of the information that people have felt necessary to reproducing or describing the problem has been given in this report and it has all been dealt with, this bug should be closed. Sorry, but how has it all been dealt with? A proper fix (login log local account creation only on write actions such as edits) has yet to be written. Simply disabling the log has severe consequences for keeping out abusive usernames. I've asked for the opinion of other admins on German Wikipedia and they affirm it hinders their efforts and that there are already trolls taking advantage of the log being removed. (Trolls create abusive usernames in small WMF wikis (low profile) and then they automatically create accounts on many popular wikis without there being any methods to trace them) -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Chad H. innocentkil...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #32 from Chad H. innocentkil...@gmail.com 2011-03-23 20:09:08 UTC --- Reopening per comment #31. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #33 from Philippe Verdy verd...@wanadoo.fr 2011-03-23 21:23:28 UTC --- So it seems that what is needed is a private log for autocreated accounts, that can be administered from any other large wiki that has enough admins to detect them. Given that accounts are unified by default in SUL now, any abusive username should be administrable from any wiki. May be a new privilege could be created, allowing to view all new SUL accounts wherever they are created, so that even small wikis could be protected by admins working on larger wikis. The main problem of course is how to detect abusive account names : a name could be abusive in an unexpected language, and not at all in another where the account was effectively created. So instead of just denying the creation of the SUL account (not necessarily abusive from the view of the smaller wiki, it could be denied on each wiki where admins are working. After several wikis have rejected the creation, using their own local filters, the SUL account could be deleted, and it would just remain the non-abusive account on the local wiki where it was created). It would also be interesting, if a new SUL account is detected in one major wiki, that a list of potentially abusive account names be posted for review on all other wikis where this user has also been connected, and each time he connects to a new wiki. This list could be automatically updated on each wiki, and could be accessible to specific admins (admins of the local wiki, and global admins). And anyway, if an account is not abusive on the source wiki where it was created, and as long as it has not been rejected there, the user could still appeal from the decision of being deined accesswith the same account on the other wikis. This also reopens something that was highly wanted, but not implemented, in SUL when it was initially released: the possibility of merging under the same SUL account, several user names that are distinct in other wikis: this would mean that the SUL database should be able to store the effective user name used on each wiki. And given that SUL will still continue to autocreate accounts when navigating, if an account is still valid on the origin wiki, the account names that are considered abusive on another wiki should not just be deleted, but just administratively blocked (but still reserved), and linked to another visible account name which could be autogenerated with a numeric pattern, possibly in another namespace like UserId:12345 using only the existing account numeric id, and its talk page becoming Talk UserId:12345 too (the link from the old account name would remain hidden in the list of references for the general public). Then if the user connects to the specific wiki where he has no account accepted username would be offered the option to assign a new acceptable name there. Note that if SUL had implemented distinct usernames on separate wikis, we would have not needed to rename administratively so many existing accounts just to merge them (some unrelated accounts were forced renamed, and I think this was abusive, even if the unrelated user was not active since a few months : it has broken the needed references for tracking licences). The only valable rule to allow unifying several accounts on different wikis would have been to just check that they had a common email address, with a verification by email, to assert that the other account being unified into an existing SUL account from its home wiki, is effectively accessible by the person asking for this unification (so an email confirmation should be sent to both the email address of the account on the source wiki asking for unification, and the email address currently registered on the target wiki to unify, in the case they are different, because not all people will want to receive email notifications from distinct wikis on the same registered email address). And given that we will no longer autocreate accounts with GET requests when just visiting a foreign wiki, if a user ever starts editing any page and his account is still not created, posting would still be possible and visible in the log within the autocreated UserId: namespace. Not everyone would even need to have a user name, registering a user name would be only an option in the user settings of each wiki. Another note: the association between a user id (local on each wiki) and its visible name needs not being kept secret. When a user registers, he still has an immediately accepted numeric user id, and if he asks for a user name, UserId:12345 would be an internal alias/synonym of User:Username. Edit logs from that user could still associate all contributions under the same user id, even if he has changed his username once or several times, or if one of his user name was rejected locally (in that case, the publicly visible logs would replace the rejected/old username by the user id). -- Configure
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #34 from Philippe Verdy verd...@wanadoo.fr 2011-03-23 21:30:39 UTC --- Another idea to complement the previous one: if a user name is rejected, the user should still be offered an option to logon that wiki; instead of using the username, he could as well login using the syntax UserId:12345 with the same registered password. But anyway, if that user insists several times on each local wiki to regenerate a new abusive account name there, that user can still be blocked completely there (blocking the Userid:12345 instead of just the account names locally linked to it). This action should generate an event to SUL admins, and all other wikis where local admins could also inspect what that user has done something, allowing each wiki to take their own decision, or if too many local wikis are complaining to SUL admins, all other accounts on small local wikis blocked as well by SUL admins (and local admins informed in their local log). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #35 from Philippe Verdy verd...@wanadoo.fr 2011-03-23 21:44:34 UTC --- Alos, in the SUL accounts database, that tracks all wikis where a user has an account (autocreated or nor, with a local account name and local user id or just the local user id), there's no need to store an account name. The SUL database just needs its own local user id, that links the SUL:UserId:x to each wiki:User:y where it is a stable reference and that *possibly* links to its local current username. When you are connecting globally on a given wiki with your local user name or user id, only that local user id is looked up in the SUL database, but the SUL:UserId:x could be stored in each local wiki in its local user database (for performance reason, to avoid this lookup). Then the SUL:UserId:x entry in the SUL database contains the complete list of wikis with their local (and stable) wiki:UserId:y for each of them (no need to store local user names in the SUL database), allowing to perform the global logon on all of them without necessarily having the user to type the username for each wiki, given that those wiki:UserId:y are already local aliases for the local user name on each wiki. SUL is just needed to allow using a single password, by conecting from any local wiki, but it's not necessary for all wikis to share the same username. Then it can be used to store global, default preferences, notably the home wiki which should be the first in the list of wiki:userid:. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #36 from Church of emacs church.of.emacs...@gmail.com 2011-03-23 21:50:42 UTC --- Your proposal is quite complex. Here's mine: Put a Login as USERNAME Button on Special:Userlogin (or even on the edit screen) if appropriate. That button creates a local user account (as POST request and with a token, to be sure). Do not create an account without the user explicitly clicking on this button. It'll cost the editor two clicks to create an account, I think that's acceptable. It should be pretty easy to implement. (In reply to comment #33) Given that accounts are unified by default in SUL now, any abusive username should be administrable from any wiki. May be a new privilege could be created, allowing to view all new SUL accounts wherever they are created, so that even small wikis could be protected by admins working on larger wikis. The main problem of course is how to detect abusive account names : a name could be abusive in an unexpected language, and not at all in another where the account was effectively created. There's already #cvn-unifications on freenode. Problem is (and it seems we're agreeing on that one), that user names are usually targeted at a specific wiki and they are written in this wiki's language. It's difficult to tell whether a username is abusive, if it's in a language you don't speak. That's why we need local admins to search for those accounts. Normally admins look out for abusive user names, and if they're really bad, they report them to stewards to get them locked hidden globally. Which is actually a pretty efficient system and has proven to work (more or less). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #37 from Philippe Verdy verd...@wanadoo.fr 2011-03-23 22:03:21 UTC --- It'll cost the editor two clicks to create an account, I think that's acceptable. It should be pretty easy to implement. The same would be true with my proposal. Only usernames, not user accounts, really need to be rejected locally, even if there may be a system for global admins and selected local admins to monitor those accounts where they occur. Yes there's an IRC channel to allow all those admins to cooperate, possibly taking common decisions, to reject the account name everywhere it was already used. But there's no real need to block the account completely if, by accident only, it is found abusive only on a specific wiki. My proposal can be implemented separately anyway and will NOT need more clicks for most users (the second click to ask for the local account name creation when editing/posting for the first time on that wiki would still be used with your solution), but the user would not even have to assign a user name on that specific wiki : he could just use the default userid: autogenerated there, and post there without being publicly logged by his private (possibly temporary) IP. This woudl also allow even those users to have their identity kept for licencing purpose (the local account woudl still be created even if it's just an anonymous Userid: without a local preferred user name). My proposal would also fulfil the demand, notably by users in Asia or speaking a non-Latin-written language, to use a prefered Latin transliteration of their name in their home wiki (for example, many Chinese/Japanese/Arabic writers like to use their native name in their home wiki speaking their home language, but like to have their name correctly read/deciphered/understood in other wikis (notably on Commons and large Latin-written wikis). This is even part of their official national identity, and present on their passport (if they want to use these aliases for foreign countries): just allow distinct usernames on distinct wikis; stability and privacy is kept with the anonymous numeric user id specific to each local wiki. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #38 from Platonides platoni...@gmail.com 2011-03-24 00:03:53 UTC --- (In reply to comment #33) This also reopens something that was highly wanted, but not implemented, in SUL when it was initially released: the possibility of merging under the same SUL account, several user names that are distinct in other wikis: this would mean that the SUL database should be able to store the effective user name used on each wiki. (In reply to comment #37) My proposal would also fulfil the demand, notably by users in Asia or speaking a non-Latin-written language, to use a prefered Latin transliteration of their name in their home wiki (for example, many Chinese/Japanese/Arabic writers like to use their native name in their home wiki speaking their home language, but like to have their name correctly read/deciphered/understood in other wikis (notably on Commons and large Latin-written wikis). This is even part of their official national identity, and present on their passport (if they want to use these aliases for foreign countries): just allow distinct usernames on distinct wikis; stability and privacy is kept with the anonymous numeric user id specific to each local wiki. Multiple usernames merged in a single SUL account was never on the radar, but the database allows that, so such support could be added painlessly if there's consensus. That should be splitted to a different bug, though. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #39 from Platonides platoni...@gmail.com 2011-03-24 00:06:21 UTC --- (In reply to comment #36) Your proposal is quite complex. Here's mine: Put a Login as USERNAME Button on Special:Userlogin (or even on the edit screen) if appropriate. That button creates a local user account (as POST request and with a token, to be sure). Do not create an account without the user explicitly clicking on this button. It'll cost the editor two clicks to create an account, I think that's acceptable. It should be pretty easy to implement. That's not a problem at all. The issue is that we have now a large userbase which get automatically logged in everywhere (more or less) on wikipedia. Having them to do some clicks to login may be hard. Albeit I'd like to do the change. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #25 from Philippe Verdy verd...@wanadoo.fr 2011-03-22 08:42:05 UTC --- Yes, but when just visiting a wiki page, it creates immediately an account, and I have received several times emails notifying me that a Hello, new user was posted immediately by some bots running on this wiki, noting the account creation. This should have never happened, and I should have never been contacted directly without first creating my own page, and verifying the user settings (after changing the user language preference, because the default language of the visited wiki was unreadable for me). I had to manually unsubscribe all these notificitions (and from some wikis, that I had just visited for exampel to check a link, those notifications were really excessive, and completley unreadable for me). In other words, the account creation was effectively auditable after a mere visit *reading* only some page (in fact just deciphering it partly, possibly with the help of an online translator). I have more than 250 wikis registered on my wikis, I cannot manage them all, and in fact I still don't know if some options in one of them does not match my effective preferences (each time I check some of them, they are too much permissive, more permissive than even my home wiki : this should have never happened, because I have NEVER opted in for these options on all these wikis). This has the same impact as spams: bulk undesired and unsollicitated contents posted to my mail box. And this severely degrades the image of Wikimedia sites (and can be a part of the problem occuring now, with people leaving Wikimedia or stopping collborating on it). Be careful, please provide the necessary tools to allow users audit their existing wikis to whcih they were subscribed without notice. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #26 from Mark A. Hershberger m...@everybody.org 2011-03-23 05:01:38 UTC --- (In reply to comment #24) This bug is not about preferences. This bug is about the records created automatically on a wiki when an existing user visits a wiki. *reading* a wiki page should not create an audit-able event. Since MW now has $wgLogAutocreatedAccounts, it is possible to eliminate the privacy concern outlined in this bug that auto-created accounts introduce. If accounts are still being logged on Wikimedia properties, then that is a separate bug. The only other concern mentioned in this bug would be solved with Global preferences. *** This bug has been marked as a duplicate of bug 14950 *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #20 from Philippe Verdy verd...@wanadoo.fr 2011-03-21 18:18:18 UTC --- Yes it is still an issue, because we can still want to have global login, without necesarily autosubscribe to various privacy settings (notably email notifications) just because we randomly visit a new wiki. The global login is there to help autoconnect when we will really need to interact with a wiki, so that we can just reserve the login name. But this autologin feature does not mean that we have ever seen and checked those privacy options on the per-wiki settings page. I'd still like to have the global login enabled, but all wikis set by default with the maximum privacy, instead of the default permissive ones. Ideally, if the global login is enabled, the automatic account creation should immediately create a link to our home wiki on the created account (this means creating a home page automatically with a basic content, including the list of languages that he advertizes on his home wiki, and posting a top message in the user discussion page, stating that the user can be contacted on his home wiki), and all email settings disabled until we explicitly check these settings on specific wikis. And there is still the lack of possibility for changing in one single screen any given privacy option on all wikis, or to know on which wiki it has been enabled/disabled (there should exist a link displaying which wiki has an option enabled or disabled or different from the default global setting). When you have an account enabled with more than 200 wikis, just because you have just visited a few pages found when navigating from our home wiki, it becomes extremely difficult to know when, and how the newly discovered wikis have had a new privacy option implemented and which ones need to be updated. Ideally, all privacy settings should not just display enabled or disabled options, but also a default/shared option indicating that the option will be inherited from the global settings. What this means is that the global settings should act as if it was another wiki, but it could also mean the settings from an existing wiki (our home wiki that we should also be allowed to change within one of those for which we already have an account, preferably a wiki where our account is already verified). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Depends on||14950 --- Comment #21 from Mark A. Hershberger m...@everybody.org 2011-03-21 19:03:02 UTC --- (In reply to comment #20) Ideally, if the global login is enabled, the automatic account creation should immediately create a link to our home wiki on the created account (this means creating a home page automatically with a basic content, including the list of languages that he advertizes on his home wiki, and posting a top message in the user discussion page, stating that the user can be contacted on his home wiki), and all email settings disabled until we explicitly check these settings on specific wikis. Adding Bug #14950 since what you are asking for here would require global preferences. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #22 from Platonides platoni...@gmail.com 2011-03-21 23:44:21 UTC --- I think what he wants is *exactly* Global preferences (bug 14950). I wouldn't consider MediaWiki as having many privacy options. He seems to see many. Perhaps it's just the Allow other people to send me emails? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #23 from Mark A. Hershberger m...@everybody.org 2011-03-22 01:00:07 UTC --- *** This bug has been marked as a duplicate of bug 14950 *** -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 John Mark Vandenberg jay...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Comment #24 from John Mark Vandenberg jay...@gmail.com 2011-03-22 02:02:34 UTC --- This bug is not about preferences. This bug is about the records created automatically on a wiki when an existing user visits a wiki. *reading* a wiki page should not create an audit-able event. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mark A. Hershberger m...@everybody.org changed: What|Removed |Added Priority|Normal |Highest CC||m...@everybody.org -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 p858snake p858sn...@gmail.com changed: What|Removed |Added CC||p858sn...@gmail.com --- Comment #19 from p858snake p858sn...@gmail.com 2011-03-19 05:34:15 UTC --- Is this a issue? we now have a tickbox to disable global login -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #18 from Philippe Verdy verd...@wanadoo.fr 2009-11-14 16:25:46 UTC --- I am NOT speculating about implementation details. I am only refering to the visible effects of these implementations. This is really different. Some recent changes in some wikis have been made recently (even after this bug was discussed here) that caused similar problems: a new functionality was added without notice in some rarely visited wiki which caused that wiki to send emails for each page that was previously just part of the list of pages to monitor ONLINE (whcich was not an option to monitor them offline by email). Think twice when adding new fucntionality that invades user privacy or user's mailboxes and make this option active by default. Anyway thanks for pointing bug 14950 (which is now really old and more urgently needs a fix now). We do need global overrides (independantly of how it will be implemented) and we still need some local overrides that will allow users to bypass some global defaults in some specific wikis (including their home wiki for SUL) that users can trust and that they reagularly visit for participating actively. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #17 from Andrew Garrett agarr...@wikimedia.org 2009-10-16 11:55:17 UTC --- (In reply to comment #16) Or alternatively, common storage, instead of storing the same thing a million times. It is already stored a million times : each wikis already stores these preferences locally, as well as the existing SUL server for these global preferences. But using a single storage ONLY in SUL, but not locally would impact users : they won't be able to have local preferences, when they want to keep them. For example, users may still want to have different email options for specific wikis (such as forwarding or not the messages posted in their discussion page), even if they use the same validated email address on all of them: one good reason for that is that some wikis are handled by teams of local administrators that a user can trust on some wikis, but absolutely not on all wikis. It's simple to have local overrides and still use common storage for defaults. You don't need to speculate about the implementation details, just specify the features that you want. This is way off the topic of this bug. To discuss global preferences, please see bug 14950. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #15 from Andrew Garrett agarr...@wikimedia.org 2009-10-15 09:01:21 UTC --- (In reply to comment #14) I DID NOT speak about a SHARED table. Even if there are preferences in the SUL database, these preferences should remain distinct and separated from the preferences set in specific wikis (which should still override what is set in the SUL account, until the user wants to apply the SUL preferences globally to all wikis). That would be done much better with a shared wiki table than with some crappy bot. It would be simple to select which preferences should be shared. That's why it would require some BOT-like behavior, if and only if, the user wants to apply the SUL preferences to all his wikis (and notably all those that were registered automatically by just visiting them without performing any edit). That could be done *easily* without a bot. In fact I really wonder why an account is created immediately on a wiki, by just visiting it. Mediawiki just needs to track in the session that the user has a subscribed SUL account. This account should then be created only when the user performs an actual edit on the visited wiki, or when he clicks on his preferences. In which case, the account preferences (including the locale parameters like the language and localtime, and privacy parameters like the effective user name confirmed email address) will be automatically imported from the SUL account. Well, if you wanted preferences to be applied across wikis, automatic account creation would be required. [snipped] Applying the global SUL preferences to the local wikis will require a lot of updates on a lot of distinct databases. That's why it cannot be performed by a simple hook, but by a scheduled Bot task on the server. But using the SUL parameters for all wikis will also be a bad option: there will continue to exist some local wikis for which a user does not want to use the default preferences stored in their SUL account. Or alternatively, common storage, instead of storing the same thing a million times. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #13 from Platonides platoni...@gmail.com 2009-10-12 16:42:51 UTC --- No need to do bot tasks. User:getOption() would provide a hook for SUL, which would check the central preferences and decide your effective preferences. You probably want to have your global account parameters as defaults and local preferences override that. It's a bit more complex than setting user_preferences as a shared table (and that would be undesirable, too). I recommend you to open a new bug for that (if it doesn't exist yet). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Philippe Verdy verd...@wanadoo.fr changed: What|Removed |Added CC||verd...@wanadoo.fr Priority|High|Normal --- Comment #12 from Philippe Verdy verd...@wanadoo.fr 2009-10-12 03:24:47 UTC --- The problem with automatic account creation is that it creates an authenticated account but with the wrong preferences : the default preferences that are set on the new wiki allow anyone on that wiki to send an email directly to that person, just by posting a message into his discussion page on that wiki. This should not be the default : sending emails must not be enabled by default, or should be restricted to administrators of that wiki, and not permitted to any visitor of that wiki. In fact, I have now several hundreds of accounts in Wikimedia projects, and I can't control the preferences that have been set on all of them, it is too much ! I'd like to have the privacy parameters globalized too, or at least that the default account parameters for the created account to be those on the origin wiki on which the account was authenticated by SUL ! And it would be great if we had the option to indicate, in the preferences dialog, the privacy parameters that should be saved in the global account (or to have a specific additional preferences pane for these global SUL parameters, and then have the possibility, in that SUL pane, to apply these global parameters to ALL wikis where the SUL account is activated, without having to revisit each wiki, notably when we have hundreds of them now ! To apply the SUL privacy parameters to all wikis, there could be probably some delay, because the SUL server would have to act like a bot on all wikis to update them in a background task, if applying the parameters to all wikis would take too much time (and too many SQL requests on many wikis). The completion status of this update could be displayed update in progress, so that the user will know when the update has been effectively completed. Independantly of that Bot update task, the user could also visit one or several of these wikis during the update in progress: when he will do that on these wikis specifically, these wikis will also be able to see that there's an update requested in the SUL account, and could also perform their own local update immediately. the same will also occur if anyone attempts to reference the user's home page on that wiki: So the SUL update Bot would have the same effect as if the user was visiting successively each wiki registered in his SUL account, except that it would be a bit faster, without forgetting any one of them: the SUL update bot would just have to visit the user's own page on each wiki (it would just need to perform a HTTP STAT on that user's page, without actually reading it, and the update would effectively not be performed by the Bot itself but by each wiki site, just noting that a user's page or subpage is being accessed and then checking the user's SUL account state). -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 チャッピー hoza...@image.ocn.ne.jp changed: What|Removed |Added CC||hoza...@image.ocn.ne.jp --- Comment #11 from チャッピー hoza...@image.ocn.ne.jp 2009-08-27 01:30:07 UTC --- It isn't really necessary if the user is only reading pages. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Brion Vibber br...@wikimedia.org changed: What|Removed |Added CC||br...@wikimedia.org --- Comment #7 from Brion Vibber br...@wikimedia.org 2009-06-23 00:29:11 UTC --- Auto account creation is a side effect of MediaWiki requiring a local user ID. However there's no particular need to be logging them publicly. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #8 from Platonides platoni...@gmail.com 2009-06-23 00:31:52 UTC --- (In reply to comment #7) Auto account creation is a side effect of MediaWiki requiring a local user ID. However there's no particular need to be logging them publicly. It isn't really necessary if the user is only reading pages. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Mike.lifeguard mike.lifegu...@gmail.com changed: What|Removed |Added CC||mike.lifegu...@gmail.com --- Comment #9 from Mike.lifeguard mike.lifegu...@gmail.com 2009-06-23 00:33:30 UTC --- (In reply to comment #7) Auto account creation is a side effect of MediaWiki requiring a local user ID. However there's no particular need to be logging them publicly. Indeed, the whole point of bug 18214 is so we can filter out the automatic account creations and look only at the non-automatic ones. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 church.of.emacs...@gmail.com changed: What|Removed |Added CC||church.of.emacs...@gmail.com Priority|Normal |High -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Platonides platoni...@gmail.com changed: What|Removed |Added CC||platoni...@gmail.com --- Comment #1 from Platonides platoni...@gmail.com 2009-06-11 17:08:31 UTC --- You'd still need to send it to a logged wiki user. Note that if done via irc, just accessing the evil server can be correlated with the irc user (which is usually correlated with the wiki account). If you know the email, you are likely to know the account. You can append a token to the url you make them visit. Where it would be most useful would be when the evil link is at one wiki. Disabling account creation if there's an external referer would drop this concern. Having the user click a link to activate their account there seems sensible, though. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #2 from church.of.emacs...@gmail.com 2009-06-11 17:37:05 UTC --- Disabling account creation if there's an external referer would drop this concern. I'm not so sure about that. What if there is no referer (e.g. link in IRC)? Also, this is confusing for the user: sometimes accounts are created automatically, and sometimes not. What if the user gets both the link to evilserver and the wiki page? Presumably he clicks on both of them in a short space of time, which would mean the same kind of vulnerability. IMHO the best way of fixing this (and the only way that is completely secure) is to disable the feature. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 Andrew Garrett agarr...@wikimedia.org changed: What|Removed |Added CC||agarr...@wikimedia.org --- Comment #3 from Andrew Garrett agarr...@wikimedia.org 2009-06-11 17:38:09 UTC --- The exact scenario is described in the non-public OTRS wiki: http://otrs-wiki.wikimedia.org/wiki/User:Church_of_emacs/mw_critical_bug That's pretty useless, then. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 x127 x...@nic-nac-project.de changed: What|Removed |Added CC||x...@nic-nac-project.de --- Comment #4 from x127 x...@nic-nac-project.de 2009-06-11 22:15:13 UTC --- As it seems there is no wish for secrecy, let me discuss this attack in the open. (Most can be infered from the comments so far, anyway) Basically, an external website could redirect wikimedia users to any of the smaller wikimedia projects where they will likely not have an account yet. This might happen in a hidden frame without the user noticing anything at all. Then, the external website would correlate the timestamps of the account creation log from the smaller wikimedia project with its web server log to obtain a mapping of IP addresses and usernames. This attack assumes that it is possible to lure many wikimedia users to an external site. I can think of two ways to do that. The obvious way would be to add the external URL as a source or citation for various articles. If the attacker does not mind violating the copyrights of third parties, the linked content may even appear relevant. This form of attack would mostly target wikipedian who watch the recent changes to fight vandalism. Another way to do it would be to use a website already in place. There may be websites out there which are openly hostile to some wikimedia projects and interested in figuring out the identity of senior editors. Furthermore, it is possible that some of the senior editors already monitor these websites, so there may not even be a need to lure them there. (Note: all of these assumptions are speculative from what I have read years ago on /. or something.) As others have remarked, there are other ways to determine the IP address of editors. One could put external links on their talk pages or send them via IRC, or one could mail them mails containing web bugs. All these methods target users specifically and scale badly. The attack described above, on the other hand, scales well. There are probably numerous wikimedia projects with a low account creation rate, and to each of them there could be a redirect every few seconds with the time correlation between the logs being maintained. In practice, the attack speed would only be limited by the number of wikimedia users visiting the external website. Assuming attackers are able to lure a significant percentage of the community to their site, I would call the impact of this attack an unofficial checkuser database. Disabling account creation from external referers would certainly complicate the attack. One might try to trick people into clicking an internal link on a wikimedia page loaded in a frame. This would greatly decrease the time correlation, making it more difficult to match users. Also, users would probably have to realize that they are browsing a wikimedia site and some may not click on the desired link. I am not very well versed in web security, but from what I have found with a search engine, there existed exploits in the past for browsers as well as media plugins to redirect users to websites with a fake referer. The general opinion seems to be that it is not good security practice to rely on the referer not being tampered with. From a purely philosophical position, database changes (such as account creation) resulting from a HTTP GET seem to go against the spirit of RFC 1945, where the POST method was specifically created for such purposes. In conclusion, I would call into question whether automatic account creation is a overall good thing from a user point of view. If instead of automatically creating a user account upon detection of cookie information, one would simply put a button (so that on could utilize the POST method) on the page called create account for $USER, the overall usability would not decrease that much. After all, most users do not spend that much time visiting projects they never visited before. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161 --- Comment #5 from Splarka h...@goldrush.com 2009-06-11 22:31:46 UTC --- (In reply to comment #4) From a purely philosophical position, database changes (such as account creation) resulting from a HTTP GET seem to go against the spirit of RFC 1945, where the POST method was specifically created for such purposes. Malicious remote websites could still force visitors to POST to Wikimedia. A simple form with someformelement.click() would do nicely. Also, bug 19006 can be a similar scenario perpetrated locally. Eg: http://www.mediawiki.org/wiki/Special:ExpandTemplates?input=%5Bhttp%3A%2F%2Fsome.dirty.website%2F%3Fuser%3D%7B%7Burlencode%3A%7B%7BREVISIONUSER%7D%7D%7D%7D+some+citation%5D -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 19161] Auto account creation creates privacy vulnerability
https://bugzilla.wikimedia.org/show_bug.cgi?id=19161
--- Comment #6 from Platonides platoni...@gmail.com 2009-06-11 22:33:46 UTC
---
The site http://austinhair.org/guess/ is a good example in-the-wild.
It has been promoted in mailing lists, irc, looks like a funny app and sends
you
to rarely used wikis with the user knowing about it. If the site operator
decides
to correlate the logs, he will get lots of wikimedian ips.
(In reply to comment #4)
I am not very well versed in web security, but from what I have found with a
search engine, there existed exploits in the past for browsers as well as
media
plugins to redirect users to websites with a fake referer. The general opinion
seems to be that it is not good security practice to rely on the referer not
being tampered with.
{{reference-needed}}
An evil guy can easily use a fake referer, but a legitimate user would provide
the
right one (or none at all). It could be bypassed with things like clickjacking,
though.
(In reply to comment #5)
Malicious remote websites could still force visitors to POST to Wikimedia. A
simple form with someformelement.click() would do nicely.
It'd obviously also use a token.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
