Jump to content

Community Wishlist Survey 2019/Anti-harassment

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2019
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

The user can be protected from account creation on, without knowing about preferences.
  • 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.
  • signup
    signup
  • preferences page
    preferences page
  • notfications preferences
    notfications preferences
  • change a mail address
    change a mail address
  • 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.

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)[reply]
    • @°: What do you think of the related proposal from 2016? Kaldari (talk) 17:46, 1 November 2018 (UTC)[reply]
      • 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)[reply]
  • 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)[reply]
    • 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)[reply]
  • 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)[reply]
    • 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)[reply]

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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    • 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)[reply]

Voting

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.

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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply]
          • @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)[reply]
            • 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)[reply]
              • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • @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)[reply]
  • 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)[reply]
  • @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)[reply]
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)[reply]

Voting

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)[reply]

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)[reply]
    • That is not part of this vote. — regards, Revi 07:29, 17 November 2018 (UTC)[reply]
    • 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)[reply]
  • 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)[reply]
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)[reply]
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)[reply]
  • @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)[reply]
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)[reply]
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)[reply]
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)[reply]
I'm sorry my attempt at clarification frustrated you. I was just trying to help. CKoerner (WMF) (talk) 16:40, 29 November 2018 (UTC)[reply]
  • 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)[reply]
    • 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)[reply]

Voting

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.

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)[reply]
  • 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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
@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)[reply]
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)
  • 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)[reply]
@°: 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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
@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)[reply]
@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:
  1. 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.
  2. 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.
  3. 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)[reply]
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)[reply]
  • Endorse. Feminist (talk) 15:22, 8 November 2018 (UTC)[reply]
  • 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)[reply]
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)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2019/Anti-harassment&oldid=18684596"