Last modified: 2014-11-19 10:22:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21161, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19161 - Don't autologin if local account doesn't exist (don't autocreate if user doesn't explicitly login)
Don't autologin if local account doesn't exist (don't autocreate if user does...
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
CentralAuth (Other open bugs)
unspecified
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
https://bugzilla.wikimedia.org/show_b...
:
Depends on:
Blocks: 28369 28227
  Show dependency treegraph
 
Reported: 2009-06-11 17:00 UTC by Church of emacs
Modified: 2014-11-19 10:22 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Church of emacs 2009-06-11 17:00:59 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

I remember having a discussion with Tim Starling and Brion Vibber when Wikimedia began to automatically create accounts on normal GET-requests. Tim and I had some concerns, while Brion rightfully said that the information of user:abc visiting a Wikipedia version on a specific date was a minor privacy concern. However, in the scenario (see URL) it seemed like this feature could lead to much more private information leaking.

Therefore I propose to disable automatic account creation on GET-requests and instead use only POST-requests to create accounts.
Comment 1 Platonides 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.
Comment 2 Church of emacs 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.
Comment 3 Andrew Garrett 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.
Comment 4 x127 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. 
Comment 5 Splarka 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
Comment 6 Platonides 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.
Comment 7 Brion Vibber 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.
Comment 8 Platonides 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.
Comment 9 Mike.lifeguard 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.
Comment 10 Brion Vibber 2009-06-23 00:36:30 UTC
(In reply to comment #8)
> (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.

It is if you need to:
1) determine permissions
2) allow for watchlist
3) allow for editing or anything else that's about to happen

In theory it could be possible to rig up a ghost-user system which gives us the permissions we would have, if we'd been registered locally, without actually doing so, until the time comes that a write has to be made, but that could be an awful lot of trouble. Alternately magic super-large (or negative!? ;) user id numbers could be used for remote accounts. Oooooh that could be wacky... :D
Comment 11 hiroe_14 2009-08-27 01:30:07 UTC
It isn't really necessary if the user is only reading pages.
Comment 12 Philippe Verdy 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).
Comment 13 Platonides 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).
Comment 14 Philippe Verdy 2009-10-14 21:48:14 UTC
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'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).

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.

As long as such edit (or preference settings) has not been performed and effectively saved, the user name shown at top will display a red link but can still display the SUL user name.

Note that I would really like that the language be part of the shared preferences, because it is sometime quite hard to use a foreign language wiki with its default language: you have to guess where are the links to the user page and talk page, and user preferences, and have to decipher the prefernces panel in a language that you possibly cannot even read (despite they are important for effectively managing your privacy options).

Why do I ask a way to apply SUL preferences globally using a delayed, bot-like system? It's mainly because now we have really a lot of accounts created in many languages that most users can't even read. so now they can't change their privacy options that have been imported with the wrong default values in the wikis that they have just visited (for example to check the existence of a page in a interwiki link).

We have now too many accounts in the system that most users can't even manage themselves, because of the languages that they can't even read (or that their system cannot even display properly with appropriate fonts when those languages are using non-Latin scripts).

I think that this is really important to fix: offer them a way to effectively manage their existing local accounts that have already been created automatically under SUL, without forcing them to learn these foreign languages or scripts!

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.
 
Comment 15 Andrew Garrett 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.

Comment 16 Philippe Verdy 2009-10-16 11:48:09 UTC
First of all, I did not speak about a real bot, but about a bot-LIKE feature, but still involving a delayed update, where the various wikis would enforce the applied update each time they encounter a reference to a local user account, before assuming that the locally stored preferences can be safely used.

> Well, if you wanted preferences to be applied across wikis, automatic account
> creation would be required.

Absolutely NOT ! When I refer to preferences to be applied across wikis, it just has to apply to existing accounts, whever they were created automatically or not, the only condition being that these already existing wiki accounts are effectively unified with the SUL account.

> 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.

The other reason being that users are multilingual and will still want, for example, to work on an English Wiki with the English language and localisation parameters, and on a French Wiki with the French language. They will however not want to work on Arabic wikis with the Arabic language, and will want to apply a default language for all languages that they don't want to see in the user interface (and notably not in the user's preferences panel).

If you just share a common table, it will no longer be possible to work on wikis with distinct languages when they want, and they will have to accept forwarded emails from ALL wikis, or from NONE of them.
Comment 17 Andrew Garrett 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.
Comment 18 Philippe Verdy 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.
Comment 19 p858snake 2011-03-19 05:34:15 UTC
Is this a issue? we now have a tickbox to disable global login....
Comment 20 Philippe Verdy 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).
Comment 21 Mark A. Hershberger 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.
Comment 22 Platonides 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"?
Comment 23 Mark A. Hershberger 2011-03-22 01:00:07 UTC

*** This bug has been marked as a duplicate of bug 14950 ***
Comment 24 John Mark Vandenberg 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.
Comment 25 Philippe Verdy 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.
Comment 26 Mark A. Hershberger 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 ***
Comment 27 John Mark Vandenberg 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.
Comment 28 Roan Kattouw 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?
Comment 29 Mark A. Hershberger 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.
Comment 30 Platonides 2011-03-23 17:44:47 UTC
You can get an idea on OTRS wiki from the more verbose Comment #4.
Comment 31 Church of emacs 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)
Comment 32 Chad H. 2011-03-23 20:09:08 UTC
Reopening per comment #31.
Comment 33 Philippe Verdy 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).
Comment 34 Philippe Verdy 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).
Comment 35 Philippe Verdy 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:xxxxx" to each "wiki:User:yyyyy" 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:xxxxx" could be stored in each local wiki in its local user database (for performance reason, to avoid this lookup).
Then the "SUL:UserId:xxxxx" entry in the SUL database contains the complete list of wikis with their local (and stable) "wiki:UserId:yyyyy" 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:yyyyy" 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:yyyy".
Comment 36 Church of emacs 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).
Comment 37 Philippe Verdy 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:xxxx" 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:xxxx" 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.
Comment 38 Platonides 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.
Comment 39 Platonides 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.
Comment 40 Mark A. Hershberger 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.
Comment 41 Chad H. 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.
Comment 43 John Mark Vandenberg 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:Log&type=newusers&user=Nane2011

Now, the exact same information is visible here:

https://secure.wikimedia.org/wikipedia/en/w/index.php?title=Special%3AListUsers&username=Nane2011&group=&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.
Comment 44 Mark A. Hershberger 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.
Comment 45 MZMcBride 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.
Comment 46 Church of emacs 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).
Comment 47 Chad H. 2011-04-01 16:20:27 UTC
Reverted the change in r85128.
Comment 48 Gregor Hagedorn 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
Comment 49 Marcin Cieślak 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.
Comment 50 Philippe Verdy 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.
Comment 51 Philippe Verdy 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.
Comment 52 Philippe Verdy 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.
Comment 53 Marcin Cieślak 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.
Comment 54 John Mark Vandenberg 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.
Comment 55 Gregor Hagedorn 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.
Comment 56 Philippe Verdy 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.
Comment 57 Nemo 2012-03-12 08:41:58 UTC
This bug is becoming more and more useless.
As we don't even agree that what outlined in comment 0 and so on is a severe vulnerability, not to speak of solutions, it's perhaps better to agree on what could reasonably be done and then decide to do it or not.

(In reply to comment #50)
> 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), [...]

Please, let's keep things "simple".
The autocreation is triggered by autologin, so to avoid the former it would be enough to disable the latter. This is probably technically inaccurate, I hope you can forgive me.
I changed the summary to: «Don't autologin if local account doesn't exist (don't autocreate if user doesn't explicitly login)». (Bug 16864 refers to a more specific situation.

If you've never visited a wiki before, you'd need to click the login button to get your local account autocreated and login. This is what already happens on wikis where autologin doesn't work (bug 14407) and it has some problems:
1) you need to remember whether you've visited the wiki before to understand what's going on/remember to login,
2) when you get to the login page, you have to know that you can just login and don't need to register;
so a solution for both or at least (2) should be found.

This seems to be what the bug originally requested:

(In reply to comment #0)
> Therefore I propose to disable automatic account creation on GET-requests and
> instead use only POST-requests to create accounts.
Comment 58 p858snake 2012-03-12 09:06:33 UTC
Previously (for a extended period in 1.18 when it was live on the cluster) we had a check box on the login page so you could choose to not be globally logged in (thus user accounts didn't get extended to involve other projects when you visited them).

{To my knowledge/that I saw}, Only one person complained when that was removed (and they aren't on this bug AFAIK). 

This option based on the ramblings in this bug would seem to have fix all your issues, but since people didn't speak up on it's removal…
Comment 59 Platonides 2012-03-15 22:16:32 UTC
That feature was requested, and later coded by me. Yes, I still consider it valueble (despite not being 'pretty', as already discussed elsewhere).
Sure, few people complained about its removal but don't many people argued to it, either, so that's not a strong reason.

Going back to autocreation, it'd be really easy to stop account autocreation, and instead require a manual clic on login. I think there's even a configuration variable for that.
But then, there would be lots of complaints about edits done as IP because "autocreation isn't working" (which would be worse than this bug). We can reduce it by disabling only autocreation, while keeping global login to sites where you already have an account.
Nonetheless, that would still reveal a number of users IPs. And it would also damage, for instance, the experience of switching to Wikimedia Commons from your home wiki.

Philippe Verdy, can you design an appropiate interface for that?
Comment 60 MZMcBride 2012-03-16 00:05:42 UTC
(In reply to comment #59)
> Going back to autocreation, it'd be really easy to stop account autocreation,
> and instead require a manual click on login. I think there's even a
> configuration variable for that.

Would this be a reasonable use-case for a global user preference? Something like "[  ] auto-create accounts for me"?
Comment 61 Gregor Hagedorn 2012-03-16 08:05:02 UTC
(In reply to comment #59)
> "autocreation isn't working" (which would be worse than this bug). We can
> reduce it by disabling only autocreation, while keeping global login to sites
> where you already have an account.

I think this is what needed. The previously discussed option to remove global login (single-sign-on) is not a valid. If I have accounts on multiple wikis, most people likely do want to remain signed in in all. Especially to shared repositories.

> Nonetheless, that would still reveal a number of users IPs. And it would also
> damage, for instance, the experience of switching to Wikimedia Commons from
> your home wiki.

Could Commons be configured to be an exception? I can think of two modes: (a) The WMF privacy statement explain that commons is always included, and the software keeps the present behavior for commons (b) In the case of commons autocreation is offered but needs confirmation. I prefer (a).

In the case of other wikis I don't care much whether the option (b) or (c): require a manual login the first time to create account is chosen.


Please note that part of this bug is legal: The privacy statement of WMF contradicts the behavior of the software, the software is violating the privacy rules explained to users and therefore a threat of some troll taking legal action against WMF exists.
Comment 62 Philippe Verdy 2012-03-16 22:47:08 UTC
(In reply to comment #57)
> This bug is becoming more and more useless.
> As we don't even agree that what outlined in comment 0 and so on is a severe
> vulnerability, not to speak of solutions, it's perhaps better to agree on what
> could reasonably be done and then decide to do it or not.
> 
> (In reply to comment #50)
> > 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), [...]
> 
> Please, let's keep things "simple".

IT IS REALLY SIMPLE (for users). They don't have to manually login, they are logged in invsibily, their account is created automatically, BUT this is reported nowhere (the creation is NOT logged).

The user can immediately create his page or start editing or change his preferences if he wishes. BUT the full creation (which will be logged) is delayed until the user really SAVES something on the wiki.This requires NO additional action by the user.

I maintain that my solution is the simplest, and offers all the benefits. Except that the "autocreated user account" status blocks all interactions using private emails, or every other actions by others that the user should have been given a chance to define in his preferences.

NO OTHER action or option is needed in the User Preferences dialog. The user just has to save his settings to change its status automatically (almost invisibly) from "autocreated" to "registered".

If the user wants to edit a page (including his own page) while he is logged on but still with the "autocreated" status, only at this time there could be a dialog informing that default options will be set in his account, so the user should be given a chance to define his OWN settings, not those settings that are preselected by default (notably not the preselected email options).

In other words, nothing changes for the user just visiting a new wiki. His privacy is completely protected, the "autocreated" user account will NOT even appear in the list of "registered" users.

All the advantages of SUL, without the bad !!!
Comment 63 Philippe Verdy 2012-03-16 23:12:22 UTC
(In reply to comment #59)
> That feature was requested, and later coded by me. Yes, I still consider it
> valueble (despite not being 'pretty', as already discussed elsewhere).
> Sure, few people complained about its removal but don't many people argued to
> it, either, so that's not a strong reason.
> 
> Going back to autocreation, it'd be really easy to stop account autocreation,
> and instead require a manual clic on login. I think there's even a
> configuration variable for that.
> But then, there would be lots of complaints about edits done as IP because
> "autocreation isn't working" (which would be worse than this bug). We can
> reduce it by disabling only autocreation, while keeping global login to sites
> where you already have an account.
> Nonetheless, that would still reveal a number of users IPs. And it would also
> damage, for instance, the experience of switching to Wikimedia Commons from
> your home wiki.
> 
> Philippe Verdy, can you design an appropiate interface for that?

No need of a new interface. SUL continues to create accounts like now. No new dialog is needed (except if an with "autocreated" account status wants to edit a page, in which case it would be helpful to have a dialog asking the user to first define and SAVE his preferences). No now button.

Eventually, the icon at the top of page that is displayed beside the user name would be different (such as a man with black glasses and a hat, meaning that he is invisible to everyone, and that he is visiting the wiki privately).

Note: No need to hide the user in server logs (admins with "checkuser" can still see all actions performed by that user, including simple visits).

The user will NOT be logged publicly. Because saving any page or saving the preference will automatically convert the status to "registered", there's no risk for that user to appear accidently in any history of any wiki page (the history just records SAVES made by a "registered" user, there will not be any user with the "autocreated" status).

If the user wants to save a page and remain "anonymous", he can logoff first, and his page edits will be saved under his IP, like now.

I repeat: nothing is changed for users, except that nobody will ever attempt to send him any email, because this permission to send mail to a "autocreated" account is granted to NOBODY.

The user keeps the FULL control of WHEN he will (or will not) start editing something and being logged under his account name for his edits.

As long as the user is visiting, and just visiting, he is invisible to anyone (except to "checkuser admins" that can see his actions in the server log: "checkuser admins" must still not attmpt to write any email to that user, they would however need to see these logs in order to identify a user that behaves badly on another wiki, or that abuses the service by too much automated traffic of viewing requests; this would likely include "Bot" users visiting other websites with their autocreated account; this case would be exceptional : bots don't normally don't visit wikis by accident, but they may do that only to see if a page exists there, and "chekuser" admins can see these invisible users and associate them to a user account registered on another wiki).

Nothing is changed in SUL itself: when a wiki sees that the visiting user is not logged, it performs a SUL check (looking at its global SUL cookie), and then retrieves the user name from SUL. it autocreates the account like now. But the only thing changed is that the wiki creates the account with different *initial* status (all private options are disabled, including all emails). This initial status is not definitive, and in fact, it is not even needed to record any default value in that account (those defaults will be set when the user first visits his preferences page, but will become effective only if the user SAVES these default settings).

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links