Community Wishlist Survey 2019/Anti-harassment
Anti-harassment
4 proposals, 223 contributors, 233 support votes
The survey has closed. Thanks for your participation :)
Make it possible to not expose email-addresses
- Problem: The email address associated with a wiki user account gets exposed, if the user accepts wikimail and sends answers to received mail. This creates two risks: with the knowledge of the mail address a hacker can try to take over an account, and a stalker can get knowledge of the private email address of a user and then harrass this user outside of wikipedia.
- For password recovery an address with a secure mail provider is a good choice. For wikimail on the other hand a throw-away-mail-address, that can be easily replaced, if it becomes known to a stalker or the public, makes more sense.
- Who would benefit: every user of wikimail.
- Proposed solution: Add the option to specify a second email address in the preferences for all users.
- Add the following global preferences (email and password are already global):
- checkboxes to select what email address to use with wikimail or none at all
- checkboxes to select what email address to use for password recovery or none at all
- if both boxes are checked, different temporary passwords are sent to both addresses and both are needed to login
- checkboxes to select what email address to use for echo and other notifications
- in a more ambitious additional approach the local echo preferences could allow the configuration of every notification type to be sent onwiki, to first address, to second address
- In a given time frame only one email address can be changed. A confirm message is sent to the new address and additionally a "cancel the change" message is sent to the other unchanged address.
- The option of two addresses would allow the use of a throw-away-email-address for wikimail. So if this address becomes known to a stalker, you can simply change this address, while keeping your secret secure email address for all other uses.
- Add the following global preferences (email and password are already global):
-
signup
-
preferences page
-
notfications preferences
-
change a mail address
-
change a mail address
- More comments: Nothing changes for any user who does not specify an email address or stays with one address.
- Two years ago the wishlist survey contained four proposals to address this type of problem. Among these, this proposal got the most votes. This proposal has in the meantime been added to the workboard of the anti-harrasment team as a topic of interest. In last year's wishlist survey the proposal was overtaken in the ending of the voting by proposals that are of most use to very profient users. This email proposal (either as presented here, or alternativly in the way of an anonmous email exchange within Wikimedia) is of use to all users as users are more likely to send mails at all and users are more likely to actually answer to emails.
- Phabricator tickets: phab:T129747
- Proposer: 𝔊 (Gradzeichen Diſk✉Talk) 14:32, 31 October 2018 (UTC)
Discussion
- Note the linked Phabricator discussion has some exiting criticism of this proposal and some counter-suggestions that would make the UI far less complex. Anomie (talk) 15:29, 31 October 2018 (UTC)
- @°: What do you think of the related proposal from 2016? Kaldari (talk) 17:46, 1 November 2018 (UTC)
- That proposal was also entered in 2017 and I repeat, what I said before: I think my idea is the most flexible and easiest to implement, but what really matters to me that something is done. That can be my proposal, or the one with the dummy address, or a system based on flow or talk pages, or something else. If another proposal is entered again this year, I am all for merging the proposals. If this proposal is voted in the top 10, the wishlist team may implent whatever deems the team the best solution, as long as this problem gets addressed. (But I prefer my idea). --𝔊 (Gradzeichen Diſk✉Talk) 15:07, 2 November 2018 (UTC)
- @°: What do you think of the related proposal from 2016? Kaldari (talk) 17:46, 1 November 2018 (UTC)
- This was proposed last year, and it should be linked prominently in this proposal somewhere. I opposed the specific implementation then and I would do the same now--the problem statement does not point to a second email address as a solution, nor an effective solution. --Izno (talk) 03:35, 3 November 2018 (UTC)
- Have you read the paragraph above your message? The proposal is not about a specific implementation, but about an urgently needed solution to a severe problem. For all 10 proposals that will be adopted by the wishlist team, the implemented solution may substantially differ from the proposal text. I have described, how I would solve the problem. And the problem is that Wikipedia is the only maior website, that exposes users email addresses to strangers. This severly hampers the project, as people do not ask questions by email for fear of exposing their address or do not answer questions that need to be answered. --𝔊 (Gradzeichen Diſk✉Talk) 15:04, 4 November 2018 (UTC)
- I don't a second e-mail as a problem, but it consider it a convenience feature, not a security one. 2FA authentication, which has limited implementation, helps a lot more. Tetizeraz (talk) 14:45, 3 November 2018 (UTC)
- 2FA is there, it is used by admins. Opening 2FA for other accounts is not a topic for the wishlist team but for security people. Hiding your email is however not convenience, but a basic requirement for every website with user accounts and many users that do not know each other. --𝔊 (Gradzeichen Diſk✉Talk) 15:04, 4 November 2018 (UTC)
Hi. I'm renaming this proposal to focus on the problem statement instead of the solution. I hope that's okay. We can tweak it if you like. Thank you. -- NKohli (WMF) (talk) 18:00, 13 November 2018 (UTC)
- The obvious solution is just to have a second throw-away email address that you link to wikipedia that auto-redirects to your main email account that you check regularly. My email connected to wikipedia basically is just a redirect to my main email account, so when I get sent or send emails from wikipedia it goes through that account (and people see that account), and when I get replies they also arrive at my regularly checked address. I would think that anyone paranoid enough about personal security *wink* would do the same, and everybody else wouldn't care in the slightest, so I don't much see the point in this proposal and I don't think it should be one of ten things that community tech works on this year. — Insertcleverphrasehere (or here) 00:38, 17 November 2018 (UTC)
- Don't use email unless you are willing to expose both the address and its content. Trying to obfuscate email addresses are simply stupid. If you want a secure communication channel use a really secure channel. — Jeblad 07:57, 18 November 2018 (UTC)
- I don't understand the reason of the last image in the proposal: we can't change an email address for another one hosted on the same domain. May be it's OK for the master email address, but this does not make sense for the secondary email address we want to give to others when sending emails to them via MediaWiki. This secondary email address may be a droppable email address we'd like to change at any time, without being forced to use another provider, which may be more costly and would radically change the way these email addresses are read by their owner, forcing them to change their provider (notably if it's a webmail like Gmail), load another application (on their smartphone or tablet), and so on. In my opinion this is not necessary at all (even if we can limit these changes to only once every 4 days to limit abuses, but the MediaWiki wiki admins also have a private history log in that case to know who owned the previous secondary address; but we can understand that they must not be sollicitated multiple times every day; the 96 hours limit is probably OK to avoid surcharges on admins and allows users to reconfirm their new address easily or change it only when this is necessary, and the 96 hours also gives a small grace period during which an unexpected change may be reverted by their legitimate users, and then allows users better protecting their own account agasint abuses like impersonations and identity thefts, with the possiblity for them to contact admins to see what happened in their account). verdy_p (talk) 21:37, 29 November 2018 (UTC)
- Anyway the multifactor authentication (MFA) in Mediawiki should be available to limit the possibilities of impersonnation: after a change of email adress anyway the new adress must be confirmed from the second email address registered or by other ways proposed by the MFA implementation (SMS to a phone number, OAuth provider, PGP signatures, personnal PKI certificates, fingerprint/biometric authentication, USB key, Microsoft Live/Azure accounts, Amazon accounts, DNS registrar account associated to a secured domain name whose user is the domain owner, personal accounts on password manager clouds storing encrypted wallets protected by strictly personal master password...): there's now many ways to support MFA and users may have several MFA mechanisms activated and could desire to have at least 2 of them verified if they don't trust a single MFA provider whose internal database may have been compromized by external attacks... Users should have the choice of authentication methods and providers to become independant of these providers and improve their privacy so that no provider alone can take control of their online identity. verdy_p (talk) 21:37, 29 November 2018 (UTC)
Voting
- Support MER-C (talk) 19:04, 16 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 03:39, 17 November 2018 (UTC)
- Support Andrew J.Kurbiko (talk) 05:15, 17 November 2018 (UTC)
- Support Jo-Jo Eumerus (talk, contributions) 10:04, 17 November 2018 (UTC)
- Support Libcub (talk) 10:17, 17 November 2018 (UTC)
- Support --Alaa :)..! 10:39, 17 November 2018 (UTC)
- Support —MarcoAurelio (talk) 11:45, 17 November 2018 (UTC)
- Oppose per the criticism on the Phab tickets, from last year's proposals. Winged Blades of Godric (talk) 13:02, 17 November 2018 (UTC)
- As I stated last year, Support the problem statement. Oppose the "two email" solution. --Izno (talk) 18:40, 17 November 2018 (UTC)
- Support Barcelona (talk) 18:55, 17 November 2018 (UTC)
- Support —Thanks for the fish! talk•contribs 19:56, 17 November 2018 (UTC)
- Support Marcelo9987 (talk) 0:55, 18 November 2018 (UTC)
- Support Cohaf (talk) 00:23, 18 November 2018 (UTC)
- Oppose Wrong solution. — Jeblad 07:57, 18 November 2018 (UTC)
- Support فرهنگ2016 (talk) 10:48, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:37, 18 November 2018 (UTC)
- Support Arbeite19 (talk) 18:00, 18 November 2018 (UTC)
- Support Lostinlodos (talk) 01:50, 19 November 2018 (UTC)
- Support Mediatus (talk) 08:44, 19 November 2018 (UTC)
- Support I would like to be able to attach multiple email addresses to my account ·addshore· talk to me! 09:59, 19 November 2018 (UTC)
- Support Elmidae (talk) 14:11, 19 November 2018 (UTC)
- Support - tucoxn\talk 14:14, 19 November 2018 (UTC)
- Oppose the overcomplicated solution described here. Neutral on the general idea of having separate recovery and EmailUser reply-to addresses; I note that each address must be individually confirmed for this to be viable. Anomie (talk) 21:53, 19 November 2018 (UTC)
- Support BugWarp (talk) 00:35, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 23:53, 20 November 2018 (UTC)
- Support Laboramus (talk) 07:24, 21 November 2018 (UTC)
- Support Arian Talk 18:37, 21 November 2018 (UTC)
- Oppose --Krinkle (talk) 01:15, 22 November 2018 (UTC)
- Support Bff (talk) 15:11, 22 November 2018 (UTC)
- Support Andycyca (talk) 19:28, 22 November 2018 (UTC)
- Support for the idea. Oppose due to its complexity to "manage" for a user who is not aware of all of this. Poslovitch (talk) 20:25, 22 November 2018 (UTC)
- Oppose Sargoth (talk) 20:34, 22 November 2018 (UTC)
- Support Sahaquiel9102 (talk) 17:10, 23 November 2018 (UTC)
- Support B20180 (talk) 17:50, 24 November 2018 (UTC)
- Support Wuyouyuan (talk) 20:29, 24 November 2018 (UTC)
- Support — AfroThundr (u · t · c) 01:40, 26 November 2018 (UTC)
- Support --Maimaid (talk) 09:15, 26 November 2018 (UTC)
- Support A garbage person (talk) 17:18, 27 November 2018 (UTC)
- Oppose Ciao • Bestoernesto • ✉ 00:41, 28 November 2018 (UTC)
- Support AnTransit (talk) 10:26, 28 November 2018 (UTC)
- Oppose This doesn't seem like the right solution. --Calvinballing (talk) 14:55, 28 November 2018 (UTC)
- Support 𝔊 (Gradzeichen Diſk✉Talk) 20:11, 28 November 2018 (UTC)
Add gender options to user preferences - how do you prefer to be described
- Problem: Germany will add the third gender option by the end of the year, about a dozen nations in the world already recognize more than two genders
- Who would benefit: everyone who wants to be addressed in another way as he / she / neutral
- Proposed solution: Either add two more radio button to the preferences page (female / male / divers / other). Or allow free text for self determination of one's gender.
- Phabricator tickets: T61643
- Proposer: RyLee Hühne (talk) 22:33, 5 November 2018 (UTC)
Discussion
- See previous discussion at T61643. And I note MediaWiki already supports three options that serve as "male", "female", and "neutral"; wikt:divers#German indicates that "divers" means "various, diverse, miscellaneous" which would seem to correspond to the third. Anomie (talk) 00:23, 6 November 2018 (UTC)
- The three options supported by MediaWiki at the moment are actually "male", "female", "do not disclose". This matches a bit the past german law of having a birth certificate with a gender entry of male or female or to leave the entry open. However the german constitual court ruled last year that there has to be another option apart from having no entry, as persons not male and not female do belong to an own gender, that by now has been named "divers". In english there are the personal pronouns he, she and they. That should be matched in wiki mesaages that address a person with the approbiate personal pronoun. I oppose however the free text option, as this would require large changes to the wiki software. --𝔊 (Gradzeichen Diſk✉Talk) 17:32, 6 November 2018 (UTC)
- The default English description "When mentioning you, the software will use gender neutral words whenever possible" says nothing along the lines of "do not disclose". As far as I can tell the German description doesn't say anything like "do not disclose" either. Anomie (talk) 17:57, 6 November 2018 (UTC)
- But that is the point of the ruling: People belonging to the third gender have a right to be addressed with their correct gender and not to stay neutral (even so some - some - consider themselves as neutral). uselang=qqx displays this:
- (yourgender)
- (parentheses: (gender-unknown))
- (gender-female)
- (gender-male)
- (prefs-help-gender)
- The gender of people belonging to the third gender are not "gender-unknown" (unless voluntary choosing to not disclose their gender)
- --𝔊 (Gradzeichen Diſk✉Talk) 19:40, 6 November 2018 (UTC)
- @Gradzeichen: Would you have an example for "addressing with their correct gender" which is not "neutral" in German? Asking as w:de:MediaWiki:Gender-unknown currently seems to use male forms (while for example w:fr:MediaWiki:Gender-unknown instead says that the software will try to use neutral terms when possible). --AKlapper (WMF) (talk) 03:36, 7 November 2018 (UTC)
- No, I do not have an example, I am not part of the community. But the wishlist is about technical issues. The issue is "adding an option" to conform with law and society. The current text reflects an use of the technical options. This texts can be changed, if the software supports more than two options. You touch a very sensitive situation with this. German wikipedia uses in its texts "Generisches Maskulinum". While I am very in favor of that, german society is changing. The german equivalent of "political correct" is "Geschlechtergerechte Sprache". German Wikipedia might actually change from generic masculinum to gender approbiate language. If that happens, than one thing that could not stand, is that the neutral text (generic maskulinum) is identical to the male text. In such a case it would become unavoidable to have different texts for male, female, divers, unknown. The german parliament will sign the law on the third gender in november, it will become operational before new year. The question is: Will Wikipedia adapt to this, making Wikipedia a forerunner, or will Wikipedia wait for a shitstorm to happen, and than be forced to find a solution fast. --𝔊 (Gradzeichen Diſk✉Talk) 14:41, 7 November 2018 (UTC)
- Wikipedia in German is not only created by German contributors, but anyone who speaks German, including Swiss and Austrians. So I see no reason why Wikipedian should abide to German government decisions. Implementing changes now will not, in itself, prevent controversy. As a rather good German speaker, I really wonder what this "correct address" might look like. I never came across it in Swiss or German newspapers, even left-winged. I'm strongly for a "wait and see" policy. --Braveheidi (talk) 01:01, 17 November 2018 (UTC)
- No, I do not have an example, I am not part of the community. But the wishlist is about technical issues. The issue is "adding an option" to conform with law and society. The current text reflects an use of the technical options. This texts can be changed, if the software supports more than two options. You touch a very sensitive situation with this. German wikipedia uses in its texts "Generisches Maskulinum". While I am very in favor of that, german society is changing. The german equivalent of "political correct" is "Geschlechtergerechte Sprache". German Wikipedia might actually change from generic masculinum to gender approbiate language. If that happens, than one thing that could not stand, is that the neutral text (generic maskulinum) is identical to the male text. In such a case it would become unavoidable to have different texts for male, female, divers, unknown. The german parliament will sign the law on the third gender in november, it will become operational before new year. The question is: Will Wikipedia adapt to this, making Wikipedia a forerunner, or will Wikipedia wait for a shitstorm to happen, and than be forced to find a solution fast. --𝔊 (Gradzeichen Diſk✉Talk) 14:41, 7 November 2018 (UTC)
- @Gradzeichen: Would you have an example for "addressing with their correct gender" which is not "neutral" in German? Asking as w:de:MediaWiki:Gender-unknown currently seems to use male forms (while for example w:fr:MediaWiki:Gender-unknown instead says that the software will try to use neutral terms when possible). --AKlapper (WMF) (talk) 03:36, 7 November 2018 (UTC)
- But that is the point of the ruling: People belonging to the third gender have a right to be addressed with their correct gender and not to stay neutral (even so some - some - consider themselves as neutral). uselang=qqx displays this:
- The default English description "When mentioning you, the software will use gender neutral words whenever possible" says nothing along the lines of "do not disclose". As far as I can tell the German description doesn't say anything like "do not disclose" either. Anomie (talk) 17:57, 6 November 2018 (UTC)
- The three options supported by MediaWiki at the moment are actually "male", "female", "do not disclose". This matches a bit the past german law of having a birth certificate with a gender entry of male or female or to leave the entry open. However the german constitual court ruled last year that there has to be another option apart from having no entry, as persons not male and not female do belong to an own gender, that by now has been named "divers". In english there are the personal pronouns he, she and they. That should be matched in wiki mesaages that address a person with the approbiate personal pronoun. I oppose however the free text option, as this would require large changes to the wiki software. --𝔊 (Gradzeichen Diſk✉Talk) 17:32, 6 November 2018 (UTC)
- There is no gender option in MediaWiki. The current wording of the preference clearly says "how do you want to be described". The distinction is small, but very important. This means the user can choose their preference regardless of their actual gender identity. The current three options are a compromise between what is available in natural languages and what can easily be mapped across languages – this is a cross-language feature. --Nikerabbit (talk) 10:27, 14 November 2018 (UTC)
- The real problem is lack of respect for the existing preference, as use of the gender function or variants of the strings to the gender function are removed or overridden at several projects. Thus I don't believe the solution would be to increase the number of variants. — Jeblad 07:51, 18 November 2018 (UTC)
- As others; everywhere this debate comes up. Gender is biologically unary, binary, or in some rare cases (referring to humans) trinary. Gender is NOT gender identity. it's the terms that cause so many issues. Adding options such an option beyond a potential user page box, is just asking for trouble. A quick google/bing/duck of the Linux CoC situation will show just how messy such processes are.Lostinlodos (talk) 01:48, 19 November 2018 (UTC)
- This request as described cannot be implemented. There is no way translators can work with "divers" or, even worse, free text option. I propose this proposal to be closed and the voting to be stopped. --Nikerabbit (talk) 15:37, 22 November 2018 (UTC)
- @Nikerabbit: some languages support more than one plural. Similarly, it seems trivial to support more than two genders and fall back to unkown in languages which do no have a neutral gender. OTOH are there any languages where the "third gender" (whatever it is) would actually be different from "unkown"? AIUI gender is used for grammatical gender (not pronouns, which seem to be the main focus of political debates, since there is no reason the UI would ever address the current user in third person), and I'm not aware of any language with more than three grammatical genders. --Tgr (talk) 04:37, 25 November 2018 (UTC)
- Note that some languages has variants that does not agree. For example in Norwegian the Nynorsk variant (official) uses maskulinum, femininum, and neutrum. The Bokmål variant (official) uses maskulinum, femininum has become weak, and neutrum, while Riksmål variant (unofficial) uses utrum, femininum has almost disappeared, and neutrum. Note that this is gender, which does not always follow the sex. If you show respect to a female you tend to use utrum in Norwegian, which is opposite of German where you show respect by using femininum. Not sure if there are any specific common form here. Note also that some languages has a concept of a women-man. I'm not sure whether this has propagated into the genus. Some languages has even incorporated the speakers gender into the mix, so what gender has Wikipedia? Has Wikisource the same gender? The speakers gender is fixed, which simplifies this a lot. — Jeblad 11:06, 26 November 2018 (UTC)
- @Tgr and Jeblad: MediaWiki does not currently support talking about groups of people, but cldr has data about it. This is not about grammatical gender of words either, {{GRAMMAR}} is for that. Why do you assume this should (only) affect the person itself? This is exactly for pronouns and verbs (like Russian in past tense) when referring to other users in third person singular, in languages used by other users where gendered forms exists, because using the wrong gender form would be incorrect and rude. Politeness level is also handled elsewhere (using -(in)formal variants, having problems of their own). --Nikerabbit (talk) 15:40, 26 November 2018 (UTC)
- Sorry, but this does not make sense to me. It is about gender, but not about gender? In Norway there were an attempt to create a third gender for third person singular in the 80s. It has not catched on. — Jeblad 20:29, 27 November 2018 (UTC)
- My main concern about this proposal is that I feel like the free text part would be difficult to implement especially when it comes to being able to have it in different languages. Saederup92 (talk) 13:15, 27 November 2018 (UTC)
Voting
- Support Liuxinyu970226 (talk) 03:39, 17 November 2018 (UTC)
- Support Andrew J.Kurbiko (talk) 05:16, 17 November 2018 (UTC)
- Support Libcub (talk) 10:18, 17 November 2018 (UTC)
- Support Jullan3 (talk) 15:25, 17 November 2018 (UTC)
- Support Good inclusive proposal. Abzeronow (talk) 17:20, 17 November 2018 (UTC)
- Support JOAN ~ (Questions?) 20:42, 17 November 2018 (UTC)
- Oppose The current setup is sufficient.Darwinek (talk) 02:05, 18 November 2018 (UTC)
- Support Wunkt2 (talk) 02:49, 18 November 2018 (UTC)
- Support the ideal situation would be allowing users to write their own pronouns in (perhaps we'd want four boxes for subject, object, possessive and reflexive e.g. xe/xem/xir/xyrself; these boxes would only appear once a user has selected "custom"). — Bilorv (talk) 03:02, 18 November 2018 (UTC)
- Oppose fix the existing message strings before new variants are added. — Jeblad 07:51, 18 November 2018 (UTC)
- Support Fixer88 (talk) 08:11, 18 November 2018 (UTC)
- Support Sargoth (talk) 09:43, 18 November 2018 (UTC)
- Support Sebastian Wallroth (talk) 13:09, 18 November 2018 (UTC)
- Oppose Per Jeblad. There are still more important issues to resolve. — Draceane talkcontrib. 17:41, 18 November 2018 (UTC)
- Oppose It is used to form of interface messages. Any "extra" genders do not have defined forms of words for these genders. If someone wants expose special gender, just use userpage. --Wargo (talk) 21:13, 18 November 2018 (UTC)
- Oppose See Wargo. Mediatus (talk) 08:42, 19 November 2018 (UTC)
- Support Demostene119 (talk) 11:52, 19 November 2018 (UTC)
- Oppose Like Wargo. PiotrekD (talk) 21:30, 19 November 2018 (UTC)
- Support Nortix08 (talk) 06:18, 20 November 2018 (UTC)
- Oppose Current status is he/she/wan't say. no need for this, only because some users wants to demontrate “Look at me, I am different.” JAn Dudík (talk) 10:28, 20 November 2018 (UTC)
- Support Lord van Tasm (talk) 14:05, 20 November 2018 (UTC)
- Oppose Per Jeblad. --Vulphere 14:40, 20 November 2018 (UTC)
- Oppose Per Wargo. --Apap04 (talk) 19:04, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 23:52, 20 November 2018 (UTC)
- Weak support As a translator, still to find internationalized terminology. Omotecho (talk) 04:43, 21 November 2018 (UTC)
- Support Irasmus (talk) 09:52, 21 November 2018 (UTC)
- Support Unlimitedknowledge30 (talk) 14:51, 21 November 2018 (UTC)
- Support TheAwesomeHwyh (talk) 12:05, 22 November 2018 (UTC)
- Oppose Per Wargo. ~Cybularny Speak? 15:51, 23 November 2018 (UTC)
- Support GPSLeo (talk) 20:25, 23 November 2018 (UTC)
- Support Could be useful for translation purposes. Mbrickn (talk) 21:38, 23 November 2018 (UTC)
- Support James F. (talk) 22:46, 23 November 2018 (UTC)
- Oppose No to investment in this seasonal and unreasonable pretention. Male, female, I dont want to say, is enough. --Wuyouyuan (talk) 20:33, 24 November 2018 (UTC)
- Support BrownHairedGirl (talk) 01:14, 25 November 2018 (UTC)
- Support Zizi.husain (talk) 01:59, 25 November 2018 (UTC)
- Strong oppose. Male and female covers >99% people's self-identification. We don't need more than one variant for less than 1%. It is inexpedient. "Male", "female" and "other". Фред-Продавец звёзд (talk) 12:32, 25 November 2018 (UTC)
- Support Blue Rasberry (talk) 00:22, 26 November 2018 (UTC)
- Opinionfluid Our !votes shouldn't have to be forced into an arbitrarily determined binary, either. Daniel Case (talk) 05:59, 26 November 2018 (UTC)
- Support I support the idea to favour more options on how the user is referred to by the interface. But on a far broader extent than what this proposal expose it. We should let people tweak the strings used in the interfaces with such a granularity that if no option already available is there, they can create their own and see it applied as soon as they provided their alternative for each string for which they want something different from what is already provided. So one can choose to be talked to in a familiar register or using any option within w:T–V distinction, or anything else. Let's give the users the flexibility on the software architecture side, and let the community take the burden of filing the alternatives. Psychoslave (talk) 17:02, 26 November 2018 (UTC)
- Support - letting people express themselves is a founding principle of the Internet. However, we may have issues implementing due to a wide array of pronouns. Kirbanzo (talk) 18:57, 26 November 2018 (UTC)
- Support Ed g2s (talk) 22:28, 26 November 2018 (UTC)
- Oppose --Silvio Haehner (talk) 22:58, 26 November 2018 (UTC)
- Support It may not be a perfect solution, but it is a good start and can be improved once implemented. ifny (talk) 01:45, 27 November 2018 (UTC)
- Support we've been dragging our feet on this issue for too long already. Braveheart (talk) 10:24, 27 November 2018 (UTC)
- Support paul2520 (talk) 13:05, 27 November 2018 (UTC)
- Support Augusta2 (talk) 16:22, 27 November 2018 (UTC)
- Oppose --Bundesbirne (talk) 18:29, 27 November 2018 (UTC)
- Oppose M.I.S. (talk) 21:03, 27 November 2018 (UTC)
- Support Ciao • Bestoernesto • ✉ 00:23, 28 November 2018 (UTC)
- Oppose The current setup is sufficient. Iich1960 (talk) 10:39, 28 November 2018 (UTC)
- Support Calvinballing (talk) 15:00, 28 November 2018 (UTC)
- Support Why not? Frood (talk) 05:14, 29 November 2018 (UTC)
- Oppose The current setup is good enough, I highly doubt the need for another gender. Denver20 (talk) 15:33, 29 November 2018 (UTC)
- Oppose Not translatable. For example, Ukrainian language has three grammatical genders: male, female and neuter. While in theory we can add a neuter version for localisation, that would not have the intended effect (e.g. using a neuter gender speaking to a woman is more offensive than using a male gender). Any other option comes back to an already existing 'prefer not to say' — NickK (talk) 16:49, 29 November 2018 (UTC)
- Support Ldorfman (talk) 20:45, 29 November 2018 (UTC)
Add an option to require email address and username to reset password
- Problem: Trolls and LTAs have been knocking Special:PasswordReset with the intention of trolling and (currently) this cannot be prevented. Then I get password reset I did not request. While I know I have secure password (and 2FA) on both my SUL accounts and my email, it's annoying so it'd better if I can just prevent them. It sometimes gives the impression to ordinary users that their account is being compromised, which is not a good UX.
- Who would benefit: Those who gets spammed with false password reset
- Proposed solution: Have a OPT-IN checkbox on Preferences, turned off by default. The checkbox will require you to enter your registered email address AND your username to get a password reset. When you set this up, you know your email address, but trolls don't.
- More comments:
- Phabricator tickets: phab:T145952
- Proposer: — regards, Revi 10:38, 4 November 2018 (UTC)
Discussion
- When I can use different mailadresses and I have forgotten which one is necessary for passwort reset? There should be a separate option to send a confirmation mail to the adress used.--Brainswiffer (talk) 07:24, 17 November 2018 (UTC)
- That is not part of this vote. — regards, Revi 07:29, 17 November 2018 (UTC)
- Currently, you just need to know one of the following: "Email address used for the account" OR "user name", so technically you do not need to know email address to send password reset. But this is being actively abused and one steward I know gets 20 passwords per week (or day, I don't recall). With my proposal, people who voluntarily choose to enforce strict requirement will need to know both "email address used for the account" AND "user name". It's a big difference. Since the change is supposed to be opt-in (you have to click a check box on Preferences, and save it - it is not enabled by default when you register or suddenly forced when you sign in) most ordinary users do not need to take any actions. — regards, Revi 08:08, 17 November 2018 (UTC)
- Without going into all reasons why this does not work, this doesn't really work even if it is quite common. A real solution is based upon something an attacker can't know, not something that is just a little bit hard to know. So instead of using a mailaddress as the additional information you use one-time scratch codes, and store them as hash codes on the server. That means only the user knows the real scratch codes, but also that the user requesting the scratch codes must keep them safely. — Jeblad 08:05, 18 November 2018 (UTC)
- Given our position on 2FA expansion and number of people losing 2FA & scratch code, that is not a solution as well. — regards, Revi 08:31, 18 November 2018 (UTC)
- Sorry, but scratch codes are the only solution that works and can be proven to be secure. Email and SMS is not secure, and using those for reacquiring credentials can be circumvented. The ting you use to identify yourself can not be anything an attacker can know or easily regenerate. That include all kinds of smart questioning, means of communication, etc.
- Note that the present implementation of 2FA at WMFs servers are defacto a single factor login. I leave it to the reader to figure out why.
- Anyhow, there are a lot of information available about this, so it should be unnecessary to argue about it. — Jeblad 09:38, 18 November 2018 (UTC)
- Given our position on 2FA expansion and number of people losing 2FA & scratch code, that is not a solution as well. — regards, Revi 08:31, 18 November 2018 (UTC)
- @Jeblad: you seem to be confusing security measures and anti-harrassment measures (and probably many other things too, judging from your single factor remark, but that's off topic here). Security-wise, we are worried about an attacker looking for vulnerable accounts (and not one specific account, as there isn't really any reason for an attacker to limit themselves to one), and it is always easy to find accounts with public email addresses. It does not matter though as the security of password reset does not rely on the email address being secret, or the attacker not being able to request password reset; it relies on the attacker not having access to the target's emails. Harrassment-wise, on the other hand, we are worried about the attacker targeting one specific user, whose email address is not known (if it is known the attacker has more direct ways of harassing them so they need to fix that first), so the idea proposed here works just fine. --Tgr (talk) 22:12, 25 November 2018 (UTC)
- I'm probably quite stupid, but please discuss the facts, not the persons. This proposal is about a concrete implementation, and that implementation does not work. It fails on the assumption that "it relies on the attacker not having access to the target's emails." A determined attacker will only request a password reset by a specific communication system if he has access to that system. Whether that would be email, SMS, or whatever does not matter. — Jeblad 10:02, 26 November 2018 (UTC)
- I don't think Tgr was saying you're stupid. Just confused. After I read your comments I get het impression that you are conflating security (the protection of authentication and access) with anti-harassment (making it difficult for jerks to bother an individual). Both are important. This proposal is in the latter category. It's about stopping people from spamming someone with password reset email notifications over-and-over, not about making the securing of an account stronger. I agree as a security proposal this would not have much impact, but as an anti-harassment proposal it's helpful for a lot of users. I get these false-positive emails with my staff account. Makes my heart jump into my throat a little each time. :) I'd gladly opt-in to this feature to make it a little more difficult for folks to mess with me. CKoerner (WMF) (talk) 16:18, 26 November 2018 (UTC)
- Thank you for pointing out that I'm not stupid, just confused. I'll tell the professor next time that his ideas about tokens that are physical inaccessible for an attacker is a pretty dumb and confused idea. — Jeblad 20:42, 27 November 2018 (UTC)
- I'm sorry my attempt at clarification frustrated you. I was just trying to help. CKoerner (WMF) (talk) 16:40, 29 November 2018 (UTC)
- Thank you for pointing out that I'm not stupid, just confused. I'll tell the professor next time that his ideas about tokens that are physical inaccessible for an attacker is a pretty dumb and confused idea. — Jeblad 20:42, 27 November 2018 (UTC)
- I don't think Tgr was saying you're stupid. Just confused. After I read your comments I get het impression that you are conflating security (the protection of authentication and access) with anti-harassment (making it difficult for jerks to bother an individual). Both are important. This proposal is in the latter category. It's about stopping people from spamming someone with password reset email notifications over-and-over, not about making the securing of an account stronger. I agree as a security proposal this would not have much impact, but as an anti-harassment proposal it's helpful for a lot of users. I get these false-positive emails with my staff account. Makes my heart jump into my throat a little each time. :) I'd gladly opt-in to this feature to make it a little more difficult for folks to mess with me. CKoerner (WMF) (talk) 16:18, 26 November 2018 (UTC)
- I'm probably quite stupid, but please discuss the facts, not the persons. This proposal is about a concrete implementation, and that implementation does not work. It fails on the assumption that "it relies on the attacker not having access to the target's emails." A determined attacker will only request a password reset by a specific communication system if he has access to that system. Whether that would be email, SMS, or whatever does not matter. — Jeblad 10:02, 26 November 2018 (UTC)
- With a caveat: this is not foolproof. Many Wikimedia email addresses are easily guessed, or if you are a list-admin to a Wikimedia mailing list the information is out there. --Rschen7754 07:52, 26 November 2018 (UTC)
- I assume there's no requirement that your list-admin email is the same as your wikimedia account email right? If so, with gmail and any similar systems you could easily use the plus trick to generate an email address that the attacker won't be able to guess unless you've contacted them over wikipedia email before while keeping everything together. e.g. use rschen7754+wikipedia7754@gmail.com for your wikimedia email. You can just replace your email address in wikimedia if it ever becomes public somehow. Of course you will either have to remember it or make sure you keep a record of the address e.g. by making sure you don't delete emails to that address in the account it belongs to. Nil Einne (talk) 12:40, 1 December 2018 (UTC)
Voting
- Support MER-C (talk) 18:59, 16 November 2018 (UTC)
- Support James Martindale (talk) 19:22, 16 November 2018 (UTC)
- Support XXBlackburnXx (talk) 20:15, 16 November 2018 (UTC)
- Support George Ho (talk) 20:30, 16 November 2018 (UTC)
- Support This should definitely be added and would be extremely useful to those of us who receive a good amount of password reset emails. Vermont (talk) 21:33, 16 November 2018 (UTC)
- Support See above. Super Wang on zhwiki (Share your opinions) 23:55, 16 November 2018 (UTC)
- Support Braveheidi (talk) 01:05, 17 November 2018 (UTC)
- Support Dolotta (talk) 01:07, 17 November 2018 (UTC)
- Support New visitor (talk) 02:02, 17 November 2018 (UTC)
- Support Ellery (talk) 02:38, 17 November 2018 (UTC)
- Support Liuxinyu970226 (talk) 03:38, 17 November 2018 (UTC)
- Support Hiàn (talk) 04:44, 17 November 2018 (UTC)
- Support Andrew J.Kurbiko (talk) 05:15, 17 November 2018 (UTC)
- Support 4nn1l2 (talk) 05:27, 17 November 2018 (UTC)
- Support Jimmyshjj (talk) 06:06, 17 November 2018 (UTC)
- Support Kpgjhpjm (talk) 07:37, 17 November 2018 (UTC)
- Support Acamicamacaraca (talk) 08:09, 17 November 2018 (UTC)
- Support –Ammarpad (talk) 08:41, 17 November 2018 (UTC)
- Support Because there is a possibility that it can be misused with only one element. 水瀬悠志 (talk) 09:32, 17 November 2018 (UTC)
- Support --Alaa :)..! 10:39, 17 November 2018 (UTC)
- Support ‐‐1997kB (talk) 11:07, 17 November 2018 (UTC)
- Support Martin Urbanec (talk) 13:45, 17 November 2018 (UTC)
- Support Zoranzoki21 (talk) 13:51, 17 November 2018 (UTC)
- Support Winged Blades of Godric (talk) 16:01, 17 November 2018 (UTC)
- Support Yilku1 (talk) 16:38, 17 November 2018 (UTC)
- Support As Im patrolling recent changes on dewiki, I frequently get such mails from IPs who want to say ironically thanks for reverting their vandalism Victor Schmidt (talk) 16:58, 17 November 2018 (UTC)
- Support Alangi Derick (talk) 17:11, 17 November 2018 (UTC)
- Support Cabayi (talk) 17:22, 17 November 2018 (UTC)
- Support Aristeas (talk) 17:31, 17 November 2018 (UTC)
- Support Amir (talk) 18:49, 17 November 2018 (UTC)
- Strongest possible support Definitely a good idea — pythoncoder (talk | contribs) 19:21, 17 November 2018 (UTC)
- Support Helland (talk) 19:51, 17 November 2018 (UTC)
- Support —Thanks for the fish! talk•contribs 19:55, 17 November 2018 (UTC)
- Support JAn Dudík (talk) 20:00, 17 November 2018 (UTC)
- Support Yamaha5 (talk) 20:34, 17 November 2018 (UTC)
- Support MehdiTalk 20:37, 17 November 2018 (UTC)
- Support Seems to be a great solution to a seemingly long-standing problem on Wikipedia. SshibumXZ (talk) 21:04, 17 November 2018 (UTC)
- Support obviously yes Cohaf (talk) 21:09, 17 November 2018 (UTC)
- Strongest possible support Seems like a great idea. Redactyll (talk) 17:31, 17 November 2018 (UTC)
- Support Bellezzasolo (talk) 21:50, 17 November 2018 (UTC)
- Support --Hadibe (talk) 22:10, 17 November 2018 (UTC)
- Support Wunkt2 (talk) 02:47, 18 November 2018 (UTC)
- Support TonyBallioni (talk) 03:53, 18 November 2018 (UTC)
- Support The fact that it is opt-in makes it very easy to support this. Mz7 (talk) 03:53, 18 November 2018 (UTC)
- Support Temp3600 (talk) 05:49, 18 November 2018 (UTC)
- Support 책읽는달팽 (User talk) 07:47, 18 November 2018 (UTC)
- Strong oppose Wrong solution. [And I'm dumb and confused that say so.] — Jeblad 08:05, 18 November 2018 (UTC)
- Support Jules78120 (talk) 09:50, 18 November 2018 (UTC)
- Support فرهنگ2016 (talk) 10:41, 18 November 2018 (UTC)
- Support Hydriz (talk) 14:25, 18 November 2018 (UTC)
- Support Massimo Telò (talk) 14:46, 18 November 2018 (UTC)
- Support — Draceane talkcontrib. 17:41, 18 November 2018 (UTC)
- Support Bruce1ee (talk) 18:06, 18 November 2018 (UTC)
- Support Fatemi ♪ 18:53, 18 November 2018 (UTC)
- Support Continua Evoluzione (talk) 19:50, 18 November 2018 (UTC)
- Support Poya-P (talk) 20:54, 18 November 2018 (UTC)
- Support Stryn (talk) 21:35, 18 November 2018 (UTC)
- Support Shizhao (talk) 02:36, 19 November 2018 (UTC)
- Support Courcelles 15:03, 19 November 2018 (UTC)
- Support Rschen7754 19:27, 19 November 2018 (UTC)
- Support Kb03 (talk) 00:48, 20 November 2018 (UTC)
- Support Reasonable proposal to enhance account security, opt-in is also a good solution in case some other people don't like it for whatever reason. -★- PlyrStar93 →Message me. ← 01:02, 20 November 2018 (UTC)
- Support – Ajraddatz (talk) 04:00, 20 November 2018 (UTC)
- Support providing it's explicitly opt-in, and that there's still a mechanism to over-ride the "email is required" in extreme circumstances since there are circumstances where people will genuinely lose access to email accounts (the mail provider going bust, a rarely-used account being closed for inactivity, a work email for a job from which you've been fired). Making this the default would be a very bad idea.Iridescent (talk) 10:11, 20 November 2018 (UTC)
- Support Vulphere 14:37, 20 November 2018 (UTC)
- Support Tiputini (talk) 18:04, 20 November 2018 (UTC)
- Support Rachel Helps (BYU) (talk) 19:05, 20 November 2018 (UTC)
- Support Andrewredk (talk) 20:16, 20 November 2018 (UTC)
- Support CAPTAIN RAJU(T) 22:30, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 23:54, 20 November 2018 (UTC)
- Support Ohwowchow (talk) 02:13, 21 November 2018 (UTC)
- Support Omotecho (talk) 03:53, 21 November 2018 (UTC)
- Support Tisfoon (talk) 06:11, 21 November 2018 (UTC)
- Support Bencemac (talk) 08:15, 21 November 2018 (UTC)
- Support JopkeB (talk) 08:51, 21 November 2018 (UTC)
- Support Ayoub Fajraoui (talk) 09:31, 21 November 2018 (UTC)
- Support Fine... Stevenmitchell (talk) 15:57, 21 November 2018 (UTC)
- Support Arian Talk 18:36, 21 November 2018 (UTC)
- Support Framawiki (talk) 19:42, 21 November 2018 (UTC)
- Support Nihlus 22:14, 21 November 2018 (UTC)
- Support Jackmegill (talk) 23:15, 21 November 2018 (UTC)
- Support tOMG 05:37, 22 November 2018 (UTC)
- Support Lirazelf (talk) 12:53, 22 November 2018 (UTC)
- Support Tho I do not suffer from this problem, I see how this is a big issue to some editors. Solving this problem seems to have no downsides. --Œ̷͠²ð·¨´´̢́̕͘³͏¯̞̗ (talk) 17:33, 22 November 2018 (UTC)
- Support This should be easy to do FiliP ██ 20:12, 22 November 2018 (UTC)
- Support ~Cybularny Speak? 15:53, 23 November 2018 (UTC)
- Support James F. (talk) 22:42, 23 November 2018 (UTC)
- Support Sannita - not just another it.wiki sysop 00:27, 24 November 2018 (UTC)
- Support Matěj Suchánek (talk) 08:39, 24 November 2018 (UTC)
- Support Hmxhmx 09:56, 24 November 2018 (UTC)
- Support Gce (talk) 19:03, 24 November 2018 (UTC)
- Support Wuyouyuan (talk) 20:30, 24 November 2018 (UTC)
- Support ~ Seb35 [^_^] 22:22, 24 November 2018 (UTC)
- Support By erdo can • TLK 08:56, 25 November 2018 (UTC)
- Support Easy fix for a longstanding problem. — Insertcleverphrasehere (or here) 11:40, 25 November 2018 (UTC)
- Support It won't solve the problem forever, but it's a great idea to solve the problem. We have suffered from it a lot. Mariogoods (talk) 13:16, 25 November 2018 (UTC)
- Support Tgr (talk) 22:12, 25 November 2018 (UTC)
- Support — AfroThundr (u · t · c) 01:42, 26 November 2018 (UTC)
- Support It's been a while since I got this kind of email, but I've always found them disconcerting. Daniel Case (talk) 06:01, 26 November 2018 (UTC)
- Support --Maimaid (talk) 09:17, 26 November 2018 (UTC)
- Support TheMesquito (talk) 15:06, 26 November 2018 (UTC)
- Support CKoerner (WMF) (talk) 16:21, 26 November 2018 (UTC)
- Support *Youngjin (talk) 17:20, 26 November 2018 (UTC)
- Support Whispering (talk) 21:20, 26 November 2018 (UTC)
- Support - FlightTime (open channel) 21:56, 26 November 2018 (UTC)
- Support -- Amanda (aka DQ) 22:52, 26 November 2018 (UTC)
- Support ifny (talk) 01:45, 27 November 2018 (UTC)
- Support YFdyh000 (talk) 15:26, 27 November 2018 (UTC)
- Oppose --Ciao • Bestoernesto • ✉ 00:42, 28 November 2018 (UTC)
- Support Hwangjy9 (talk) 07:54, 28 November 2018 (UTC)
- Support JaventheAlderick (talk) 10:24, 28 November 2018 (UTC)
- Support Calvinballing (talk) 14:43, 28 November 2018 (UTC)
- Support Pmlineditor (t · c · l) 17:14, 28 November 2018 (UTC)
- Support Kpjas (talk) 10:20, 29 November 2018 (UTC)
- Support Seems quite easy, so hopefully Community Tech will have time to go beyond the top ten whishes. ;) Tacsipacsi (talk) 20:56, 29 November 2018 (UTC)
- Support NicoScribe (talk) 11:25, 30 November 2018 (UTC)
- Support Alucard 16 (talk) 15:32, 30 November 2018 (UTC)
- Support RolandUnger (talk) 16:41, 30 November 2018 (UTC)
Wikipedia mirrored in Tor .onion
- Problem: Surveillance without limitation creates a chilling effect where people can be afraid to read Wikipedia for general information. Also some bad actors, including governments, corporations, and powerful individuals, sometimes block access to Wikipedia at the level of the Internet service provider. Everyone with an Internet connection needs to be able to access Wikipedia but there are safety barriers against them doing so.
- Who would benefit: Everyone who values their right to access Wikipedia articles in private.
- Proposed solution: The Wikimedia Foundation hosts a .onion mirror of Wikipedia which anyone can read with the most privacy which we can provide. This mirror will not permit editing, but at least it provides some private access.
- More comments: We in the Wikimedia community take an activist and political stance that everyone in the world has a right to access Wikipedia and the sum of all human knowledge.
- See also:
- The Wikimedia Foundation already operates a Tor node (not exit). wikitech:Tor relay
- Grants:IdeaLab/Partnership between Wikimedia community and Tor community
- Grants:IdeaLab/A Tor Onion Service for Wikipedia
- Grants_talk:IdeaLab/Partnership_between_Wikimedia_community_and_Tor_community#Proposal:_Create_a_Wikipedia-only_read-only_Tor_exit_node
- Other sites which do this
- Phabricator tickets: T168218
- Proposer: Blue Rasberry (talk) 13:42, 30 October 2018 (UTC)
Discussion
- I think this would be good, but I'm not sure that it would necessarily be useful in fighting surveillance. Operating an .onion service doesn't help those in regions where Tor itself is blocked, and it doesn't improve access for those who can already use Tor. Jc86035 (talk) 14:55, 30 October 2018 (UTC)
- This would be one of the many solutions to the Chinese government in blocking Wikimedia access. It is sure that it is a fundamental right to obtain uncensored knowledge, though I doubt if this is anti-harassment but more of the Miscellaneous side. To the proposer User:Bluerasberry, I have fixed some meaning problem.--1233 | Questions?| This message is left by him at 16:40, 30 October 2018 (UTC)
- Except Tor cannot be reliably used within China. And yes why is this anti-harassment? C933103 (talk) 17:53, 1 November 2018 (UTC)
- @C933103: Whenever the community hears of someone getting persecuted for engagement with Wikipedia we refer that fact to the WMF. They might have records but they have never said. I have no idea if they even file reports. When anyone is threatened over reading Wikipedia then I would call this harassment.
- We had a guy show up to Wikimania some years ago saying that he had to leave his country because of government agents coming to his home about his wiki editing. I would call that harassment. Other people have similarly reported that they feel afraid to read politics, LGBT+, health especially reproductive health, information about illegal activities even for general knowledge, and many other topics. The right to privacy is an established culture and there are people who call a disruption to the right to privacy harassment.
- About China and other countries blocking Tor - the right to privacy is an en:arms race where technology will always increase. I am not saying that a .onion mirror will solve all the problems, but it is part of a solution. It is a relatively inexpensive entry point, there is a userbase which advocates for this heightened sort of privacy, taking any step sooner and now will incite the conversation about when and how to take next steps, and this is a technological step which also makes a social demonstration that we stand for the right to read Wikipedia articles in private.
- If a typical person's browser history were made public against their wishes, they would call that harassment. That is why this proposal fits as "anti-harassment". In 2013 when Snowden said that the government and tech companies watched people's Internet activities some people felt disturbed by the surveillance. I know that sentiment has mostly changed and most people now are happy for multiple entities to have all their online data, but there are still people who feel that privacy of 10 years ago would be nice. This is not a perfect idea but I am looking for the best idea that anyone has for the budget that we have, which is approximately 1 month of staff time from 2-3 WMF workers. Blue Rasberry (talk) 20:14, 1 November 2018 (UTC)
- My understanding is that, while network traffic is one of the tool that can be used by governments to detect browsing activity of people on the Wikipedia site, https encyrpted connection have already reduced the role that can be played by such activity. Social engineering is apparently a more direct threat against Chinese users who're using international websites and is also reasons why they can pinpoint and jail twitter users. Another mean they would use is that they would directly scan the hardware of devices owned/carried by individuals within the country for activity history and files and software exists in the system. Having Tor won't help. Also I heard there're some fake tor nodes setup by the government in the network. C933103 (talk) 20:51, 1 November 2018 (UTC)
- Does it provide any additonal privacy, compared to just accessing wikipedia.org over TOR? MaxSem (WMF) (talk) 20:11, 30 October 2018 (UTC)
- @MaxSem (WMF): Yes. I apologize that our Wikipedia articles are not orderly so I cannot quickly point you to general reference information. I can give an example. Facebook says yes with en:facebookcorewwwi.onion. Blue Rasberry (talk) 13:50, 31 October 2018 (UTC)
- @Bluerasberry: That article is very outadated. The only reason I see is that TOR prevents interception of HTTP between TOR and our servers, however it's not a problem anymore becuase all our domains are secured via HTTPS and we're on HSTS preload list for every major browser so even if a user types http://en.wikipedia.org, no insecure request will be made. Any other security/privacy benefit? MaxSem (WMF) (talk) 20:22, 31 October 2018 (UTC)
- @MaxSem (WMF): A 2016 Facebook initiative at the edge of innovation is outdated less than 2 years later? There are other benefits - let me get back after some time. Blue Rasberry (talk) 20:44, 31 October 2018 (UTC)
- One of the main benefits people often tout, is that exit-bandwidth in the tor network is at a premium. Using a hidden service, users may get better performance, especially for larger files (e.g. Videos on commons). At least in theory. There are probably other factors at play too (
more hops) and I have certainly not measured what the difference is. BWolff (WMF) (talk)
- One of the main benefits people often tout, is that exit-bandwidth in the tor network is at a premium. Using a hidden service, users may get better performance, especially for larger files (e.g. Videos on commons). At least in theory. There are probably other factors at play too (
- @MaxSem (WMF): A 2016 Facebook initiative at the edge of innovation is outdated less than 2 years later? There are other benefits - let me get back after some time. Blue Rasberry (talk) 20:44, 31 October 2018 (UTC)
- @Bluerasberry: That article is very outadated. The only reason I see is that TOR prevents interception of HTTP between TOR and our servers, however it's not a problem anymore becuase all our domains are secured via HTTPS and we're on HSTS preload list for every major browser so even if a user types http://en.wikipedia.org, no insecure request will be made. Any other security/privacy benefit? MaxSem (WMF) (talk) 20:22, 31 October 2018 (UTC)
- @MaxSem (WMF): Yes. I apologize that our Wikipedia articles are not orderly so I cannot quickly point you to general reference information. I can give an example. Facebook says yes with en:facebookcorewwwi.onion. Blue Rasberry (talk) 13:50, 31 October 2018 (UTC)
- What would this be good for? Wikipeda uses SSL and no external trackers. No one can actually find out what article you are reading. If you use a tool likem TOR, a hostile regime might go after you only for using such a tool (like China does with VPN and TOR, or Turkey with an App that is said to belong to Gulen). --𝔊 (Gradzeichen Diſk✉Talk) 14:36, 31 October 2018 (UTC)
- @°: Someone could watch your internet traffic and see what sites you try to connect to. SSL won't stop your ISP from seeing what pages you try to connect to. --Terra ❤ (talk) 11:09, 2 November 2018 (UTC)
- The browser sends a CONNECT request to the http-Server, no one can see the page names you access unless you have a key logger or trojan or other malware on your computer (and Wikipedia can do nothing about that). It may be suspect to access en.wikipeida.org, but in tha case it is even more suspect to use TOR or anything similar at all. --𝔊 (Gradzeichen Diſk✉Talk) 15:43, 2 November 2018 (UTC)
- @°: Someone could watch your internet traffic and see what sites you try to connect to. SSL won't stop your ISP from seeing what pages you try to connect to. --Terra ❤ (talk) 11:09, 2 November 2018 (UTC)
- I'd just like to note that a .onion site is not necessary for accessing Wikipedia through the Tor network, if anyone unfamiliar was unsure about this. Tor can connect to the main Wikipedia site just fine; the purpose of the .onion site would be to allow Tor users to connect to Wikipedia without their request leaving the Tor network. Jc86035 (talk) 16:07, 2 November 2018 (UTC)
- I assume this is meant to be a "read only". We don't need to make it easier for IP vandalism edits. This proposal should be clarified. Thanks! • Sbmeirow • Talk • 19:53, 5 November 2018 (UTC)
- @Sbmeirow: already says "anyone can read with the most privacy which we can provide. This mirror will not permit editing". I will think about how to make this more clear, but I tried to communicate what you describe. Blue Rasberry (talk) 17:06, 7 November 2018 (UTC)
- I'm not opposed to WMF doing this, but anybody could create a .onion clone of Wikipedia since the content is open source. Andrewman327 (talk) 13:27, 7 November 2018 (UTC)
- @Andrewman327: Anyone could and some people have, see where some Facebook guy got media at There’s Now a Dark Web Version of Wikipedia. Here are some problems with being only community based:
- Random third party mirrors lack reliability The stakes are access to Wikipedia. With a third party, access could vanish at any time. With a WMF / community partnership the service is dependable. The cost is low and the benefits are high for making this service dependably accessible.
- We need WMF trustworthiness in addition to technical execution For this to come from a community group and be successful there is a high cost of establishing trust and dependability in addition to the technical execution. The WMF already has trust and dependability, so if the WMF did this, it would not incur the costs to establish those things that a small community group would have to pay. There are various .onion clones but none of them have a community fanbase because they come from sources with challenges for trust and dependability. The existing third-party clones have not achieved a community base of support because this is not just a technical problem, this is a challenge to get hosting at a trusted source.
- Also a model for others We should encourage other people to set up .onion clones of Wikipedia, and if the WMF does this once then that makes for a more inviting workflow for others to do this too and make it more normal. This wishlist is more than getting the task, and also about getting the WMF to do the usual technical documentation for how they did something and what community participation they got. This is not so complicated, and does not require a lot of documentation, but a little documentation and a little community consultation would be a big help for anyone else who wanted to provide the same protection with their own Wiki mirror or a mirror of any other website which would benefit from wiki-style community management.
- Blue Rasberry (talk) 17:06, 7 November 2018 (UTC)
- Random people setting up wikipedia mirrors kind of defeats the point if user privacy is what you care about. Whomever sets up the mirror has full access to everything you view when viewing the mirror. BWolff (WMF) (talk) 13:03, 8 November 2018 (UTC)
- @Andrewman327: Anyone could and some people have, see where some Facebook guy got media at There’s Now a Dark Web Version of Wikipedia. Here are some problems with being only community based:
- Endorse. Feminist (talk) 15:22, 8 November 2018 (UTC)
- Here are the arguments from nos-oignons.net members (an association that offers tor exit nodes). I copy it because they were not able to post this comment by themselves because contributing via Tor even if we are logged in to our user account is not allowed (I opened a Phabricator ticket about that):
- https relies on the CA system, which isn't really trustworthy given how many entities can actually issue certificates for any website on the web. Onion services don't have this issue. Moreover, exit bandwidth is a precious resource for the tor network, running an onion service doesn't consume it, reducing the resources consumption of the network. Also, some exit nodes are doing passive traffic analysis, they wouldn't be able to do that on the onion service: I wouldn't be surprised if some states were running high-speed exit nodes to measure if given censorship method and its chilling effect are efficient.
- In addition, Wikimedia projects are currently accessible via the TCP+HTTPS protocol, using .onion+HTTPS protocol offers other secutiry properties that may be useful for some readers.
- Providing .onion is also a strong political message from the WMF saying that Wikimedia projects will never be censored.
- Finally, you can also read this Cloudfare blog post that gives some arguments.
- Pamputt (talk) 21:59, 11 November 2018 (UTC)
- I respectfully disagree with the certificate authority point. I think the risk of phising via tor (As nobody can memorize those insanely long non-human memorable hashes), far outweighs the benefits of not having to rely on the imperfect CA system. For example, if someone setup a fake version of duck duck go at http://3g2upl4pq2hkl4r.onion would you notice that it is different from http://3g2upl4pq6kufc4m.onion ? AFAIK, the main two solutions to this problem is EV certs, or alt-svc for a (clearnet) https domain, both of which end up relying on WebPKI infastructure anyways. Furthermore, with the advent of certificate-transparency (And hopefully one day we will enable the
expect-ct
header) the risk of a malicious CA is much less as the liklihood of being caught is much higher. BWolff (WMF) (talk) 22:38, 11 November 2018 (UTC)
- I respectfully disagree with the certificate authority point. I think the risk of phising via tor (As nobody can memorize those insanely long non-human memorable hashes), far outweighs the benefits of not having to rely on the imperfect CA system. For example, if someone setup a fake version of duck duck go at http://3g2upl4pq2hkl4r.onion would you notice that it is different from http://3g2upl4pq6kufc4m.onion ? AFAIK, the main two solutions to this problem is EV certs, or alt-svc for a (clearnet) https domain, both of which end up relying on WebPKI infastructure anyways. Furthermore, with the advent of certificate-transparency (And hopefully one day we will enable the
Voting
- Support Liuxinyu970226 (talk) 03:39, 17 November 2018 (UTC)
- Support This proposal is consistent with Wikipedia's mission to increase access to free knowledge, especially for readers in adverse circumstances. — Newslinger talk 07:39, 18 November 2018 (UTC)
- Support Szalax (talk) 09:15, 18 November 2018 (UTC)
- Support Sebastian Wallroth (talk) 13:07, 18 November 2018 (UTC)
- Support Pamputt (talk) 21:01, 18 November 2018 (UTC)
- Support Lostinlodos (talk) 01:55, 19 November 2018 (UTC)
- Support Krokofant (talk) 05:47, 19 November 2018 (UTC)
- Support Mend My Way 23:46, 19 November 2018 (UTC)
- Support BugWarp (talk) 00:28, 20 November 2018 (UTC)
- Support It will also lower exit nodes load. Good idea. Vort (talk) 05:51, 20 November 2018 (UTC)
- Support Great way to increase access to Wikipedia Vulphere 14:42, 20 November 2018 (UTC)
- Support Cohaf (talk) 14:46, 20 November 2018 (UTC)
- Support Vilena66 (talk) 15:53, 20 November 2018 (UTC)
- Support Rachel Helps (BYU) (talk) 19:03, 20 November 2018 (UTC)
- Support Novak Watchmen (talk) 23:54, 20 November 2018 (UTC)
- Support Omotecho (talk) 04:11, 21 November 2018 (UTC)
- Support Laboramus (talk) 07:23, 21 November 2018 (UTC)
- Support Weegaweek (talk) 08:01, 21 November 2018 (UTC)
- Support It may be enabling or empowering... Stevenmitchell (talk) 16:00, 21 November 2018 (UTC)
- Support Skyman gozilla (talk) 20:11, 21 November 2018 (UTC)
- Support Topper13009 (talk) 20:33, 21 November 2018 (UTC)
- Support kocio ✉ 21:28, 21 November 2018 (UTC)
- Support Sahaquiel9102 (talk) 17:10, 23 November 2018 (UTC)
- Support GPSLeo (talk) 20:25, 23 November 2018 (UTC)
- Support Pf1127 (talk) 06:29, 24 November 2018 (UTC)
- Support Hmxhmx 09:55, 24 November 2018 (UTC)
- Support Let's Do It AkselHelp (talk) 12:47, 24 November 2018 (UTC)
- Support Gmli82164 (talk) 13:08, 24 November 2018 (UTC)
- Support JCRZ (talk) 13:30, 24 November 2018 (UTC)
- Support Gce (talk) 19:01, 24 November 2018 (UTC)
- Support Wuyouyuan (talk) 20:28, 24 November 2018 (UTC)
- Support Bunnyfrosch (talk) 15:17, 25 November 2018 (UTC)
- Support We should most definitely implement a read-only tor mirror. This goes directly with the WMF mission of making Wikipedia accessible to as many people as possible. — AfroThundr (u · t · c) 01:37, 26 November 2018 (UTC)
- Support TheAwesomeHwyh (talk) 02:51, 26 November 2018 (UTC)
- Support ifny (talk) 01:42, 27 November 2018 (UTC)
- Support Merhad77 (talk) 14:05, 27 November 2018 (UTC)
- Support YFdyh000 (talk) 15:29, 27 November 2018 (UTC)
- Support Plogeo (talk) 19:31, 27 November 2018 (UTC)
- Support --Nemo 22:42, 27 November 2018 (UTC)
- Support Ciao • Bestoernesto • ✉ 00:44, 28 November 2018 (UTC)
- Support Calvinballing (talk) 14:48, 28 November 2018 (UTC)