Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
The WMF section of the village pump is a community-managed page. Editors or Wikimedia Foundation staff may post and discuss information, proposals, feedback requests, or other matters of significance to both the community and the foundation. It is intended to aid communication, understanding, and coordination between the community and the foundation, though Wikimedia Foundation currently does not consider this page to be a communication venue.
Threads may be automatically archived after 14 days of inactivity. |
« Archives, 1, 2, 3 |
What we've got here is failure to communicate (some mobile editors you just can't reach)
- Summary of overall issues: User:Suffusion of Yellow/Mobile communication bugs ProcrastinatingReader (talk) 03:08, 21 March 2021 (UTC)
Over a year ago, I reported two problems to the WMF:
(1) Logged-in mobile web editors are not given a very strong indication that they have new messages. There's just a little number in a red circle. It's similar to what many other sites use for "Exciting! New! Offers!" and other garbage. There's nothing to say "A human being wants to talk to you."
(2) Mobile web IP editors are given no indication at all that they have new messages. Nothing. Every template warning, every carefully thought out personal message, and everything else just disappears into a black hole, unless the user stumbles across their talk page by accident, or switches to the desktop interface.
But I get it. Bugs happen. They can be fixed. Instead both problems were marked as a "low" priority.
This is baffling. Problem 1 is a serious issue. Problem 2 is utterly unacceptable.
We are yelling at users (or even dragging them to WP:ANI) for "ignoring" our messages that they have no idea exist. We are expecting them learn without any communication all sorts of rules from WP:V to WP:3RR to WP:MOS that don't even apply to most other sites on the web.
Until they get blocked, of course. What a terrible experience. How are we supposed to gain new users when their very first interaction with a human is being told to f--- off, for "ignoring" a message they didn't even know about?
WMF, please explain to this community why this is a "low" priority. One year is long enough. Suffusion of Yellow (talk) 22:55, 16 February 2021 (UTC)
- I'll just note that a majority of our users are accessing us on mobile so this isn't a niche problem either. Best, Barkeep49 (talk) 23:26, 16 February 2021 (UTC)
- Wow. Neglected high-priority phabricator tickets are nothing new, but this is another level. Jimbo Wales, this deserves your attention. {{u|Sdkb}} talk 08:11, 18 February 2021 (UTC)
- I would like to point out that the majority of messages left to IPs will never reach the user in question anyways, ESPECIALLY on mobile connections. Due to shared ips, the chance of someone else viewing the message before the person you are trying to reach is probably about 50/50. I realise that sometimes leaving a message is effective, but there are serious questions about all the cases where it is simply leaving a very confusing and often aggressively toned message to a completely different user just randomly reading an article at the busstop a month later. What we really need is a completely new way to leave messages to anonymous users. Possibly with some sort of very short lived session or something. But as ip users are more or less stateless (the software concept) right now, that is probably hard to implement. —TheDJ (talk • contribs) 09:26, 18 February 2021 (UTC)
- @TheDJ: I would have no objection to expiring the OBOD if the talk page isn't clicked in a few days. Many messages come only a few minutes after the user makes the edit; most mobile carriers aren't that dynamic. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)
- I would like to point out that the majority of messages left to IPs will never reach the user in question anyways, ESPECIALLY on mobile connections. Due to shared ips, the chance of someone else viewing the message before the person you are trying to reach is probably about 50/50. I realise that sometimes leaving a message is effective, but there are serious questions about all the cases where it is simply leaving a very confusing and often aggressively toned message to a completely different user just randomly reading an article at the busstop a month later. What we really need is a completely new way to leave messages to anonymous users. Possibly with some sort of very short lived session or something. But as ip users are more or less stateless (the software concept) right now, that is probably hard to implement. —TheDJ (talk • contribs) 09:26, 18 February 2021 (UTC)
- Equally baffling is that mobile app users do not see any notifications, including no talk page notifications, logged in or out. The link to talk is buried within the settings. Official mobile apps! They don't even see block messages! See T263943 and others. This block review and also this discussion where an editor also tested block messages. The editor was blocked multiple times for something that was not their fault but that of a poorly thought out app. They are not alone. Quote from phab task:
Conclusion: Using the app is like being inside a bubble, without contacts with the exterior. It's no wonder there's so much people complaining here that using the app caused their Wikipedia account to be blocked, for reasons they don't understand.
ProcrastinatingReader (talk) 09:33, 18 February 2021 (UTC)
- I have filed T275117 and T275118. ProcrastinatingReader (talk) 10:22, 18 February 2021 (UTC)
- I'm always surprised that anyone manages to edit with the mobile interface. As another example, if you're not logged in, there is no way to access the talk page of an article, or even any indication that it exists. If an unregistered user makes an edit and is reverted with a common summary like "see talk", I imagine many will have no idea what's going on. – Joe (talk) 09:39, 18 February 2021 (UTC)
- @Joe Roe: Sorry if this is not the right place, but I'm trying to find out why you can't access an article talk page if you're not logged in (on mobile). This was the only mention I could find. Do you know if this issue is being addressed anywhere? Cheers, Fredlesaltique (talk) 07:50, 18 June 2021 (UTC)
- @Fredlesaltique: AFAICT the talk page link is a feature of mw:Reading/Web/Advanced mobile contributions (see § January 14, 2019 - Getting started with Talk page links), which is currently only available to logged in editors (I don't know why, though). See also phab:T54165, though that doesn't seem very active. – Rummskartoffel 11:30, 18 June 2021 (UTC)
- @Joe Roe: Sorry if this is not the right place, but I'm trying to find out why you can't access an article talk page if you're not logged in (on mobile). This was the only mention I could find. Do you know if this issue is being addressed anywhere? Cheers, Fredlesaltique (talk) 07:50, 18 June 2021 (UTC)
- The mobile web, and mobile apps, appear to be designed for readers and not writers. Having used mobile web occasionally, I think it's usable for logged in editing, but I do have to switch to desktop every now and then. I've used the iOS app only for a test - it is not usable for editing imo. ProcrastinatingReader (talk) 09:55, 18 February 2021 (UTC)
- The number of edits I have made with the mobile web or app interface is most likely less than 50 (out of 13,000). Even for reading, the mobile interface is borderline unusable. I do frequently edit from my 4-inch cell phone screen (in fact, I'm doing that right now)... but I use the desktop version. —pythoncoder (talk | contribs) 14:04, 18 February 2021 (UTC)
- I agree with Joe and have always found Cullen328 to be a bit of a superhero for being who he is on a mobile device. Best, Barkeep49 (talk) 18:19, 18 February 2021 (UTC)
- Thanks for the kind words, Barkeep49, but I simply use the fully functional desktop site on my Android smartphone. It's easy. If I was the king of the Wikimedia Foundation, I would shut down the mobile site and apps, because they are an ongoing impediment to serious editing. RoySmith, there is no need to invest more effort (money) on a good editing interface for mobile, because that interface already exists - the desktop site. Just change its name from desktop to universal or something, and the problem will be solved.Cullen328 Let's discuss it 18:34, 18 February 2021 (UTC)
- In some parts of the world, laptops and desktops are common, and people's phones are their second screen. In an environment like that, yes, it makes sense for mobile devices to be thought of as a read-mostly interface. On the other hand, in other parts of the world (particularly India in the context of English language users), mobile is how people access the internet.[1] There's no doubt that building a good editing interface for mobile is a hard thing, but we should be investing more effort there. Poor mobile editing tools disenfranchises a large segment of the world's population. -- RoySmith (talk) 14:41, 18 February 2021 (UTC)
- @Suffusion of Yellow: Thank you for basically expressing exactly the same problem I wanted to. I have blocked a few editors who seem to be editing in good faith but just don't communicate, which eventually end up at ANI and after much agonising, get hit with as friendly a WP:ICANTHEARYOU block as we can muster. In the last instance, Mdd97 (talk · contribs), I specifically made a custom block template that said "CLICK HERE TO READ YOUR MESSAGES" in a way that they surely couldn't miss .... but again, following the block they've not edited again. We have to get to the bottom of this; if it's got to the stage where I've got to block people and the root cause is a software fault, it needs to be fixed. Surely the WMF can't be happy that I've needed to issue blocks on good-faith editors in this manner. Ritchie333 (talk) (cont) 16:10, 18 February 2021 (UTC)
- To address a reaction some might have, yes, the vast majority of users on mobile are readers, not editors, and no, I wouldn't want the community totally in charge of redesigning the mobile interface, since we'd end up with the phenomenon we have at desktop where e.g. the tools section of the sidebar is visible to every user on every page despite it being of zero use to 99.9% of them. But this request is not just editor-centrism; it applies to users who have already edited and who badly need a notification to help them not get lost. {{u|Sdkb}} talk 18:55, 18 February 2021 (UTC)
- I think the mw:Talk pages project, especially now that they are beginning to work on subscribing to notifications for talk page sections, could be interested in this discussion. Pinging User:PPelberg (WMF) and User:Whatamidoing (WMF). It also touches on UCoC Enforcement, highlighting that there needs to be funding for software dev. in addition to other measures. Pinging User:SPoore (WMF) and User:BChoo (WMF) for want of knowing who to contact regarding Phase 2. Pelagic ( messages ) – (09:51 Sat 20, AEDT) 22:51, 19 February 2021 (UTC) ... Adding User:Xeno (WMF) after seeing section above. Pelagic ( messages ) – (09:55 Sat 20, AEDT) 22:55, 19 February 2021 (UTC)
- Pelagic: Thank you for the ping and highlighting how this is a related need for my current project. I've been following this thread and will be including the comments (and phabricator links - thank you for those!) in my work categorized under important requests for additional human or technical resources to assist with on-wiki workflows. Xeno (WMF) (talk) 15:02, 14 March 2021 (UTC)
Question - Is this something that could be cured by bringing back the "Orange Bar of Death"? Mjroots (talk) 16:31, 22 February 2021 (UTC)
- @Mjroots: the orange bar of death never went away. Last I check, it's still there for non mobile IP editors. That's why they get an indication of new messages. AFAIK, it was never there for the mobile web editor, that's probably part of the problem. Nil Einne (talk) 03:06, 23 February 2021 (UTC)
- What no one has ever told me is why it was left out in the first place. Was it a simple oversight? Did someone have such a little understanding of how the sites work that they thought communication was unnecessary? Some other reason, that I'm not thinking of? This is the most confusing part. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)
- This is alarming but not surprising. Since I do a lot of question answering at the Teahouse, I'll point out a random IP's post from yesterday, in the same vein as some of the sentiments noted above: "Also, why don’t they get rid of the mobile view? So terrible!".--Fuhghettaboutit (talk) 00:29, 24 February 2021 (UTC)
- Does anyone with a (WMF) account plan on commenting in this thread? Suffusion of Yellow (talk) 17:21, 8 March 2021 (UTC)
- Don't hold your breath. For most WMF employees, commenting on Wikipedia using a WMF account is a quick way to get yourself fired. You might, if you make enough noise, get a department head to respond by saying that mobile users are very important to us and we will do everything we can to address this, up to but not including doing anything differently that we are doing them now. --Guy Macon (talk) 17:39, 8 March 2021 (UTC)
- @Guy Macon: When they did the same thing with desktop IPs, it was fixed within hours of being pointed out. Serious, not rhetorical question: what's changed about WMF culture since 2013? Suffusion of Yellow (talk) 17:58, 8 March 2021 (UTC)
- Don't hold your breath. For most WMF employees, commenting on Wikipedia using a WMF account is a quick way to get yourself fired. You might, if you make enough noise, get a department head to respond by saying that mobile users are very important to us and we will do everything we can to address this, up to but not including doing anything differently that we are doing them now. --Guy Macon (talk) 17:39, 8 March 2021 (UTC)
When you spend three times as much money without the actual job you were hired to do changing, you start to focus more on spending all of that money instead of on doing your job. When you hire a boatload of new employees when the current bunch are more that enough to do the job, those new employees find something to do, whether that something needs doing or not. I'm just saying. --Guy Macon (talk) 18:31, 8 March 2021 (UTC)
- User:Suffusion of Yellow broadly you have two factors. Firstly there is little incentive for WMF people engage people here were they will get a bunch of people shouting that them (which is not fun). Secondly there has been a longstanding unwritten understanding that mobile is the WMF's turf while the community has more ownership of the desktop.©Geni (talk) 11:21, 11 March 2021 (UTC)
- Well, imagine this. Someone is standing on your foot. You politely ask them to move off of it. They don't. You repeat your request more loudly. They continue to ignore you. It still hurts. At some point, does shouting and shoving come into play?If WMF doesn't like being shouted at, well—certainly, no one does. But people do not like being ignored either, and doing so is an excellent way to get them started shouting just to be heard at all. Seraphimblade Talk to me 21:42, 14 March 2021 (UTC)
- User:Suffusion of Yellow broadly you have two factors. Firstly there is little incentive for WMF people engage people here were they will get a bunch of people shouting that them (which is not fun). Secondly there has been a longstanding unwritten understanding that mobile is the WMF's turf while the community has more ownership of the desktop.©Geni (talk) 11:21, 11 March 2021 (UTC)
- Action from the WMF! One two three new mobile bugs I discovered while investigating this have been triaged as "low" priority, and a fourth was lowered to "medium", after a volunteer developer had raised it to "high". All without a word of explanation. The first (unparsed spam blacklist messages) isn't a huge deal I'll agree. But why is not telling users why they're blocked or falsely telling registered users that they're blocked personally not a major concern? That's how we lose people. Suffusion of Yellow (talk) 22:55, 22 March 2021 (UTC)
- Can we locally block these apps from editing English Wikipedia? That would force the WMF to fix them. Fences&Windows 00:02, 26 March 2021 (UTC)
- @Fences and windows: Yes, this can be done with the edit filter. It could even be limited to users with no confirmed email address. But there's a catch. The apps don't properly display custom edit filter warnings, either! The iOS app just displays the title of the page where the message is stored. And the Android app doesn't display custom messages at all. The mobile web editor does display messages properly, however. Suffusion of Yellow (talk) 00:10, 26 March 2021 (UTC)
- If this were a lower-priority issue, I would say we should come back in a month and see if the WMF fixed it. But this is such a glaring oversight that I feel this may be the only option if we want to fix this. Question: would this apply to just the app, or to the mobile site as well? —pythoncoder (talk | contribs) 15:06, 29 March 2021 (UTC)
- It's app only (the
user_app
variable in the edit filter). ProcrastinatingReader (talk) 15:12, 29 March 2021 (UTC)
- It's app only (the
- Thanks, ProcrastinatingReader. If we prepare an RfC, where would it be held? It would need advertising on cent. Fences&Windows 23:47, 29 March 2021 (UTC)
- @Fences and windows: Any RFC will need some very careful drafting first. If it fails (for any reason) the WMF could interpret the failure as "see the community doesn't really care about this issue". Suffusion of Yellow (talk) 23:51, 29 March 2021 (UTC)
- We might want to move this thread to WP:VPT; this noticeboard is not widely watched. –xenotalk 23:54, 29 March 2021 (UTC)
- I really don't want to rush into an RFC, though. There are many questions. Should we also disallow mobile IP web editors? Should we disallow edits from users with a confirmed email address? Which bugs, exactly, do we want fixed? How long do we give the WMF to fix them? This is a nuclear option. It should not be taken lightly. But please don't move the whole thread to VPT. It's here so it doesn't get buried in the archives. Suffusion of Yellow (talk) 00:33, 30 March 2021 (UTC)
- (edit conflict) Two-question RfC maybe? Initial brainstorm - Question 1: consensus 'letter' to WMF requesting resources be allocated to promptly fix the issues. Question 2: if not done within 90 days, mobile apps blocked from editing enwiki by edit filter. Best to move this particular matter to VPI. ProcrastinatingReader (talk) 00:36, 30 March 2021 (UTC)
- It has to be noted though that disallowing edits, if it comes to it, is really not great and rather bitey, as the editors will hardly have any clue what's going on due to EF messages being iffy. Maybe bugging Jimbo and/or Doc James to contact someone in engineering is a viable option? ProcrastinatingReader (talk) 00:43, 30 March 2021 (UTC)
- As I said. Nuclear. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)
- Yes, IDEALAB is the best place (for a new thread). That will discourage any supporting and opposing until we figure just what we're asking for. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)
- This needs caution—an overly enthusiastic RfC or proposal at WP:VPI is bound to be voted down and that would cause a lot of people to automatically vote down any future proposals of a similar nature. I'm thinking of masked IPs—any proposal to impede or block such users could easily fail if it appeared to be similar to an earlier idea to block "good faith" users who were unaware that communication was even possible, let alone required. Johnuniq (talk) 08:34, 30 March 2021 (UTC)
- It has to be noted though that disallowing edits, if it comes to it, is really not great and rather bitey, as the editors will hardly have any clue what's going on due to EF messages being iffy. Maybe bugging Jimbo and/or Doc James to contact someone in engineering is a viable option? ProcrastinatingReader (talk) 00:43, 30 March 2021 (UTC)
- We might want to move this thread to WP:VPT; this noticeboard is not widely watched. –xenotalk 23:54, 29 March 2021 (UTC)
- @Fences and windows: Any RFC will need some very careful drafting first. If it fails (for any reason) the WMF could interpret the failure as "see the community doesn't really care about this issue". Suffusion of Yellow (talk) 23:51, 29 March 2021 (UTC)
- Thanks, ProcrastinatingReader. If we prepare an RfC, where would it be held? It would need advertising on cent. Fences&Windows 23:47, 29 March 2021 (UTC)
- Can we locally block these apps from editing English Wikipedia? That would force the WMF to fix them. Fences&Windows 00:02, 26 March 2021 (UTC)
- I wish I could say I was surprised by any of this but I've long assumed that something like this was the cause of numerous editors I've come across who display quite clearly that they have never seen their IP/user talk page, and simply have no idea why their edits "aren't going through" (because a human editor keeps undoing them). A thorough waste of thousands of hours of volunteer time, on both ends. There are some countries or regions in which accessing the internet is only financially possible for the everyday person via a mobile phone, so the WMF's inaction here is another built-in systemic bias which prevents some cultures from effectively contributing their knowledge and skills to Wikipedia. — Bilorv (talk) 06:51, 29 March 2021 (UTC)
User:Suffusion of Yellow/Mobile communication bugs seems to be an excellent overview but it would get more attention if it were on phab. I have tried to roughly copy it to https://phabricator.wikimedia.org/T278838 which can probably be used as a parent task for all these issues. – SD0001 (talk) 15:04, 30 March 2021 (UTC)
Hi everyone, thanks for raising these issues, and documenting the problems so thoroughly. We're going to get a group of people from the Product department together next week to talk about these problems, and see what we can do about it. I'll let you know what we figure out. I appreciate you all bringing it up. — DannyH (WMF) (talk) 22:17, 7 April 2021 (UTC)
- Thank you, Danny! I look forward to seeing what you come up with. Suffusion of Yellow (talk) 19:55, 9 April 2021 (UTC)
26 April update
Hi everyone, we talked in the Product department about the issues that are being raised in this conversation.
We're currently showing notifications to logged-in editors on mobile web, which appear as a number in a red circle at the top of the page. It's the standard design on mobile that indicates that there are messages for you.
We've been reluctant to do that for IP editors on mobile web, because mobile IPs shift around so much. Desktop IPs can change as well, so there's some risk of not reaching the right person on desktop, but the risk is a lot greater for mobile. People walk around with their phones and move from one wifi or cell tower to another. We haven't wanted to show a message bar to a mobile reader who happens to be picking up the same cell tower or wifi access point as someone who made an edit a year ago.
On the apps, the Android team has released improvements to the talk page experience in February and March. Echo notifications currently exist in the Android app, and user talk pages are also discoverable through the watchlist. Users can access article talk using a dropdown menu at the top right; you can see how this works in this walkthrough gif. There are some further improvements planned, including enabling in-line replies, and building onboarding features to help people discover both the watchlist and talk pages. You can learn more, and ask the team questions, on their Android communication project page.
The iOS team is also looking at improving the talk experience on their app. They're currently in the initial design and technical planning phase for enabling Echo notifications on iOS. Later this year, they're planning to fill in some of the missing collaboration features on the app, including making editing tools and talk pages more prominent.
There are some different things to discuss here, and I'd like to know what you think. — DannyH (WMF) (talk) 18:47, 26 April 2021 (UTC)
- What are we doing about the block notification messages and the other edit screen notices?? —TheDJ (talk • contribs) 19:02, 26 April 2021 (UTC)
- @DannyH (WMF):
- About IP users: As myself and others have suggested, there's a solution to the "random unrelated reader" problem: Don't show the alert if the new message is over X days old. Or (if the privacy policy permits) set a cookie anytime they click "publish", and only show any new message alert to people who have edited in the past X days. Or even both. I think most people already understand that messages sent to IP users are not guaranteed to reach the user. But we do expect that when 1.2.3.4 edits Foo, we leave them a message, and then an hour later 1.2.3.4 edits Foo again, that they've seen our message. That's the disconnect between expectations and reality that's been bothering us. You're also making the assumption that users on mobile devices are also on mobile connections. What about the phone user on their home WiFi? That could be stable for months.
- About logged in users: No, the red circle is not (only) the standard "you have new messages" alert. It's also the standard "we have some spammy garbage we'd like to sell you" alert. Of course experienced users know Wikipedia doesn't do that, but inexperienced ones are the people we're trying to reach. As matter of habit, I ignore similar-looking notices on unfamiliar websites.
- About the Android app: Again, what about spam-weary users who have turned off push notifications. With no in-app alert, how are they supposed to know that there is an urgent message on their talk page?
- About the iOS app: If users are currently in a total bubble, why enable editing at all? Why not wait until basic communication features are implemented, and keep the app read-only in the meantime?
- I'm really getting the impression that the WMF thinks that user communication is an afterthought. Y'all didn't just forget one communication-related feature, you forgot most communication-related features. How did this happen in the first place? Suffusion of Yellow (talk) 20:15, 26 April 2021 (UTC)
- @DannyH (WMF): Thank you for your time working on and responding to this. I recognize the difficulties in developing a good software product for the diverse projects that rely on MediaWiki software. However, I am deeply frustrated that this has been allowed to occur. Ensuring that existing community mechanisms for communicating with other editors, especially new editors, continue to function is a bare-bones requirement for any Wikimedia minimum viable product. To paraphrase Risker's related thoughts on Wikimedia software development in a different area: the intention behind a lot of this has been good, but sometimes I think engineers have no idea how our projects actually function and how significant some of these problems are. Frankly, if logged-out mobile editors don't have an interface to see messages, then the logged-out mobile interface should not contain editing functionality. Otherwise, this software is wasting many many hours a day of volunteer time tracking down and reverting and warning (not that they'll see the warnings) and blocking good faith IP users who are oblivious to community norms and this software is wasting just as much time spent by new editors trying to help out but unable to access any feedback about their editing. Best, KevinL (aka L235 · t · c) 10:01, 28 April 2021 (UTC)
- Let me make more explicit a position that I suspect a broad swath of the English Wikipedia community may support: If the Foundation feels that it is impractical to build a communication system to communicate with logged-out mobile editors, then logged-out mobile users should be required to log in to edit. Wikipedia is a collaborative project; we simply cannot allow users to edit without being able to communicate with them effectively. KevinL (aka L235 · t · c) 10:05, 28 April 2021 (UTC)
- Absolutely, thank you for the clear description of the situation. I was thinking of going rogue and just blocking any uncommunicative user/IP after a single warning. That would avoid mega-frustration and wasted time and would focus minds on fixing the problem rather than ticking boxes for the number of new edits from new users. Johnuniq (talk) 10:23, 28 April 2021 (UTC)
- Let me make more explicit a position that I suspect a broad swath of the English Wikipedia community may support: If the Foundation feels that it is impractical to build a communication system to communicate with logged-out mobile editors, then logged-out mobile users should be required to log in to edit. Wikipedia is a collaborative project; we simply cannot allow users to edit without being able to communicate with them effectively. KevinL (aka L235 · t · c) 10:05, 28 April 2021 (UTC)
- @DannyH (WMF): If fixing all the issues is going to take some time, and you don't want to disable editing entirely, can you break the Android app a bit more? See this. Using that hack a message can be conveyed to iOS users but the same can't be done for Android. It shouldn't take long to make the tweak, which would at least allow a custom mechanism to communicate a message to Android editors. Perhaps directing them to login via their browser app, for example. ProcrastinatingReader (talk) 03:16, 30 April 2021 (UTC)
Hi everyone, thanks for posting more thoughts. As usual, there's lots to respond to here.
It's true that the apps are late to including talk page features. That's partly because we didn't have a clear strategy for how we could improve talk pages sitewide — we knew that we wanted to improve the usability of talk pages, but the Flow project was not successful, and we knew that we needed to find a new direction. We determined that new direction with the Talk Pages Consultation in mid-2019, and then the Editing team started their Talk pages project to build tools for replying, starting new discussions and being notified when people comment in specific talk page sections. (If you haven't yet, you can turn on the new tools for replying and starting new discussions in the Beta preferences tab.)
As part of that project, the Editing team has developed the ability to break down wikitext conversations into individual comments, and all of that work is now informing the work that both the Android and iOS teams are doing to improve the talk page experience on the apps as well.
Now, one of the things that we do when a product team is working on a feature is to look at both the usage numbers and the revert rate for edits that are made using the feature. If the revert rate is higher than average, then clearly there's a problem with the feature that we need to fix.
Comparing the revert rates across desktop, mobile and apps, we see a similar pattern with both logged-in and logged-out editors. Looking at the last 30 days on English Wikipedia, mobile web edits have a higher revert rate compared to desktop edits. That's true for both logged-in users (10.2% revert on mobile web to 3.7% revert on desktop) and IP editors (35% revert on mobile web to 22% revert on desktop). Edits made through the apps are closer to the desktop revert rate. For logged-in app users, about 6.5% of app edits are reverted, compared to 3.7% on desktop. For IP app users, it's around 24% app edits reverted vs 22% IP edits on desktop. So while every single revert is a waste of time for somebody, we don't see app editing causing significantly more problems than desktop editing, especially compared to mobile web.
As I said earlier, the Android team has recently released improvements for talk pages just last month, and has plans to continue work on it, and iOS will be working on communication features later this year. So while those teams had a late start on these features, they are currently getting attention.
Some more specific points: Suffusion of Yellow, your suggestion about offering a time-limited message is interesting, and started a conversation in a couple of teams, so thanks for bringing that up. For your question about the assumption that mobile devices are used on the go: yes, there are definitely people who use mobile devices on stable IPs. However, it's a lot more likely that any given mobile device will be on an inconsistent IP than a desktop device.
Regarding people who ignore red circles and turn off push notifications, it's true that banner blindness is very strong, and that's a problem for web designers in general. However, we've found that when someone takes a specific step like turning off push notifications, responding with larger and more insistent notifications is not likely to help.
I'm happy to keep talking, if folks have more questions or suggestions. DannyH (WMF) (talk) 18:47, 30 April 2021 (UTC)
- Danny, I'm intrigued and puzzled by your statement here. You have people here (and in many previous conversations) expressing frustrations at an inability to communicate with users. Some prior discussions have been about specific editors who have a mixture of constructive and troubling edits which are the kind of editors who can frequently be helped to stop the troubling edits. Your response, if I'm understanding it correctly, is that because there is no difference in revert rates for these editors compared to those on other platforms that the lack of communication doesn't matter. This might be true but would be a radical shift in culture in terms of how we handle disruptive editing and would be at odds with other foundation sponsored initiatives, including obligations to help new users in the UCoC. Can you help me either understand where I am failing to get what you're saying or if I do understand what you're saying how we, as an enwiki community, can square this circle. Best, Barkeep49 (talk) 19:17, 30 April 2021 (UTC)
- Hi Barkeep49: What I shared about the revert rate was in response to a couple of things. First, Johnuniq commented on the fact that I'd only talked about edits from app users, and didn't acknowledge the impact on the editor community who have to clean up a mess. (The part about "ticking boxes for the number of new edits from new users.") It was also a response to the suggestion made in a few places that the apps shouldn't allow editing if the communication features aren't up to desktop standard. My point is that we do try to take the impact on the community into account, by making sure that features that we build don't result in a mess that's noticeably bigger than the mess that already exists.
- But yes, this conversation is mostly about reaching specific editors who might be helped to stop making troubling edits. I agree that the communication features are important, and both apps teams have been and will continue to work on communication features. Some of the problems that we're talking about have already been addressed on Android; I think that in the case mentioned in the thread on Jimbo's talk page, they would have received talk page notifications as of March 30th — but that was sadly too late to reach that user. These conversations have inspired us to talk more about the communication features as a product team, and I appreciate the folks who have brought it up here. — DannyH (WMF) (talk) 20:37, 3 May 2021 (UTC)
- DannyH (WMF), the desktop site is fully functional on modern mobile devices. The solution to this problem to shut down all apps and sites that are not fully functional, and redirect all users to the desktop site, which should be renamed the "fully functional site". That would save enormous amounts of money and draw a gigantic worldwide pool of new editors into the WMF free knowledge websites. Right now, we are erecting barriers to collaboration with people editing with mobile devices, and that is terribly sad. I speak as an editor who has been editing and more recently administrating with Android smartphones for ten years. 99+% of my edits are on smartphones. The WMF is spending buckets of money on a problem that does not exist, and making matters worse in the process. Cullen328 Let's discuss it
- While this may have been a hypothetical, I would personally oppose such a proposal, solely because while the desktop site is functional on mobile, the text is still really small. The probably-crazy solution that immediately comes to mind is to switch the site skin to the new Responsive MonoBook, because that would display the content at a reasonable size on mobile while presumably allowing IPs to see the Orange Bar of Doom. (I haven't tested this, but I assume it works because unlike Minerva, MonoBook is maintained by the editing community.) Also, there are some plans to make Vector responsive too, but I don't know anything about that. —pythoncoder (talk | contribs) 22:19, 5 May 2021 (UTC)
- At least a couple of us have disagreed with your view a few times, Cullen. The desktop site is not at all well optimised, and the apps are better for reading already. The solution is not to delete everything, rather than fix the issues. It's such an overly simplistic view anyway; compare this to this in terms of page size. I mean, the suggestion just isn't considerate of all the language projects and global users, and is just so unlikely to happen that it distracts from real solutions, which really is to disable editing in the interim / provide a roadmap, or at least allow the community to do that if it wishes to by consensus. ProcrastinatingReader (talk) 01:36, 6 May 2021 (UTC)
- DannyH (WMF), the desktop site is fully functional on modern mobile devices. The solution to this problem to shut down all apps and sites that are not fully functional, and redirect all users to the desktop site, which should be renamed the "fully functional site". That would save enormous amounts of money and draw a gigantic worldwide pool of new editors into the WMF free knowledge websites. Right now, we are erecting barriers to collaboration with people editing with mobile devices, and that is terribly sad. I speak as an editor who has been editing and more recently administrating with Android smartphones for ten years. 99+% of my edits are on smartphones. The WMF is spending buckets of money on a problem that does not exist, and making matters worse in the process. Cullen328 Let's discuss it
- But yes, this conversation is mostly about reaching specific editors who might be helped to stop making troubling edits. I agree that the communication features are important, and both apps teams have been and will continue to work on communication features. Some of the problems that we're talking about have already been addressed on Android; I think that in the case mentioned in the thread on Jimbo's talk page, they would have received talk page notifications as of March 30th — but that was sadly too late to reach that user. These conversations have inspired us to talk more about the communication features as a product team, and I appreciate the folks who have brought it up here. — DannyH (WMF) (talk) 20:37, 3 May 2021 (UTC)
- I agree that just nuking mobile and forcing everyone to use desktop is the wrong solution. What many people don't quite grasp is that not everyone is like them. They assume that because they have a large screen smartphone and a fast connection, then of course everyone does, and if a desktop website works for them then of course it works fine for for everyone else.
- In the real world some people access Wikipedia on old flip phones, satellite phones with huge packet delays, rugged industrial phones with tiny screens, and ancient computers using modems.
- I recently finished a preliminary design for a major toy manufacturer that includes a very low performance web browser with a really cheap display. That one got cancelled (90% of toys that make it to prototype do) but sooner or later you are going to see something similar in the toy aisle at Wal-mart for $29.95 USD. --Guy Macon (talk) 11:02, 6 May 2021 (UTC)
- @DannyH (WMF): is this a joke or am I misunderstanding? You're saying that it's a deliberate design choice that mobile app editors are not seeing the messages being left for them? How do you suggest that we contact CejeroC, or does it not matter that thousands of volunteers' time (both newbie and experienced) are being wasted? — Bilorv (talk) 23:33, 29 May 2021 (UTC)
- Hi @Bilorv: I think that you're misunderstanding slightly. It's a deliberate design choice not to show notifications for IP editors on mobile web, because there's a higher chance that we'll show the notification to the wrong person. It's more likely that a mobile web edit was made by someone who's moving around, so the notification would appear for a random reader who happens to be picking up the same cell tower or wifi access. We are showing notifications for logged-in editors on mobile web, and both logged-in and logged-out editors on the Android and iOS apps.
- CejeroC was an editor on the Android app, which added talk page notifications in some changes made in February-March 2021. This was too late for the people trying to contact CejeroC, unfortunately, but it should be easier to contact Android app editors from now on. — DannyH (WMF) (talk) 18:35, 4 June 2021 (UTC)
- Thanks for the reply, DannyH (WMF). I'm glad that I was misunderstanding, as the other option was deeply undesirable. My new questions are as follows: you're saying that it's a deliberate design choice that unregistered mobile web editors are not seeing the messages being left for them? Where can I see the WMF's data on the percentage of IP talk page messages that would have been seen by someone who was not the intended target, versus the percentage that would have been seen by the intended target? And how should a volunteer attempt to get in contact with an IP editor tagged as making mobile web edits, particularly when the IP has clearly been static for a non-trivial amount of time (based on the length of the editor's contributions)? — Bilorv (talk) 18:57, 4 June 2021 (UTC)
- @Bilorv: I wish we could get data on who sees which notifications; it would make life easier. Unfortunately, we don't know. (There are a lot of stats that are typically collected by other big websites that we don't collect out of respect for users' privacy.) The judgment call that we're making right now is based on our understanding that a large number of IPs move around and are unreachable even on desktop, and that problem is obviously magnified for mobile IPs. For the question of how a volunteer could get in contact with a stable mobile IP editor, one potential workaround would be to leave them a message on the IP's talk page, and then when you revert one of their edits, you put a link to their talk page in the edit summary. That's obviously a hack, but IP editors having a talk page at all is kind of a hack. — DannyH (WMF) (talk) 20:58, 8 June 2021 (UTC)
- I don't believe that the users I'm thinking of are aware that there's a page history—in fact, I often see behaviour that makes me think they are going "my edit didn't go through, why is it not there when I look again a few hours later?" after a revert (and I don't think the layout makes the page history obvious). I need to send a big fuck-off banner saying "SOMEONE IS TRYING TO TALK TO YOU ABOUT THE EDIT YOU DID" in order to engage attention. Unfortunately, no such functionality exists. I do appreciate the privacy afforded to readers and editors, but you're making a judgement call based on not very much—certainly not what the community wants—and using a 2001 IP-based system is not the solid foundation for communication that I need. (I understand the WMF is planning to anonymise IPs but not change them as the method of tracking unregistered contributors.) I don't necessarily want us to start tracking people with cookies, so I know every solution comes with a disadvantage, but this situation is honestly ridiculous. So much of my time is wasted with sending out messages to people who will never see it, and the alternative is just undoing what they did without explanation (what message is that to send to a newcomer? How can we get new editors involved by doing that?). — Bilorv (talk) 21:25, 8 June 2021 (UTC)
- @Bilorv: As you say, the 2001 IP-based communication system is very flawed. The big f'off banner doesn't even work for desktop IP editors all too often, because IPs shift around, or just because the person who's making the edits doesn't understand or doesn't respond to talk page messages. For mobile IP editors, you're even less likely to make a connection. I think that if the folks who created MediaWiki twenty years ago were creating it today, they probably wouldn't use IP addresses as the foundation for communication, but this is the legacy system that we have.
- I do think that the work that the Anti-Harassment Tools team is doing on "IP masking" will help with this, especially if we use cookies on mobile devices to associate the device with an auto-generated user name. There's a lot of planning and discussion left to do on the IP masking project, and figuring out how to communicate with "masked" IP editors will be one of many things to figure out. — DannyH (WMF) (talk) 22:42, 9 June 2021 (UTC)
- I don't believe that the users I'm thinking of are aware that there's a page history—in fact, I often see behaviour that makes me think they are going "my edit didn't go through, why is it not there when I look again a few hours later?" after a revert (and I don't think the layout makes the page history obvious). I need to send a big fuck-off banner saying "SOMEONE IS TRYING TO TALK TO YOU ABOUT THE EDIT YOU DID" in order to engage attention. Unfortunately, no such functionality exists. I do appreciate the privacy afforded to readers and editors, but you're making a judgement call based on not very much—certainly not what the community wants—and using a 2001 IP-based system is not the solid foundation for communication that I need. (I understand the WMF is planning to anonymise IPs but not change them as the method of tracking unregistered contributors.) I don't necessarily want us to start tracking people with cookies, so I know every solution comes with a disadvantage, but this situation is honestly ridiculous. So much of my time is wasted with sending out messages to people who will never see it, and the alternative is just undoing what they did without explanation (what message is that to send to a newcomer? How can we get new editors involved by doing that?). — Bilorv (talk) 21:25, 8 June 2021 (UTC)
- @Bilorv: I wish we could get data on who sees which notifications; it would make life easier. Unfortunately, we don't know. (There are a lot of stats that are typically collected by other big websites that we don't collect out of respect for users' privacy.) The judgment call that we're making right now is based on our understanding that a large number of IPs move around and are unreachable even on desktop, and that problem is obviously magnified for mobile IPs. For the question of how a volunteer could get in contact with a stable mobile IP editor, one potential workaround would be to leave them a message on the IP's talk page, and then when you revert one of their edits, you put a link to their talk page in the edit summary. That's obviously a hack, but IP editors having a talk page at all is kind of a hack. — DannyH (WMF) (talk) 20:58, 8 June 2021 (UTC)
- Thanks for the reply, DannyH (WMF). I'm glad that I was misunderstanding, as the other option was deeply undesirable. My new questions are as follows: you're saying that it's a deliberate design choice that unregistered mobile web editors are not seeing the messages being left for them? Where can I see the WMF's data on the percentage of IP talk page messages that would have been seen by someone who was not the intended target, versus the percentage that would have been seen by the intended target? And how should a volunteer attempt to get in contact with an IP editor tagged as making mobile web edits, particularly when the IP has clearly been static for a non-trivial amount of time (based on the length of the editor's contributions)? — Bilorv (talk) 18:57, 4 June 2021 (UTC)
- @DannyH (WMF):
We are showing notifications for ... both logged-in and logged-out editors on the Android and iOS apps.
Can you link me to the phab task where the the lack of iOS notifications was fixed? I don't have an iOS device handy and phab:T274404 and its subtasks suggest work is just getting started. Also, the Android app still isn't showing me any alerts for logged-out talk page messages. And least no one has responded to my simple question at phab:T95396. So what have I missed? Suffusion of Yellow (talk) 19:37, 6 June 2021 (UTC)- @Suffusion of Yellow: Sorry, you're correct about iOS. I just checked my own post at the top of the section and realized that I made a mistake when I replied to Bilorv. Android has already made the changes; iOS is getting started on that work. I looked at your question on that ticket, which I think was not the correct ticket for that bug report — it looks like that ticket was closed in May 2020, and may not have been the right ticket anyway. I just asked the PM to take a look at it, and tell me where that report should go; I'll let you know when I get an answer. — DannyH (WMF) (talk) 21:06, 8 June 2021 (UTC)
- Ah, I see that you've already made that connection on phab:T276147. At least, I think so. Let me know if I'm not correct. — DannyH (WMF) (talk) 21:22, 8 June 2021 (UTC)
- @Suffusion of Yellow: Sorry, you're correct about iOS. I just checked my own post at the top of the section and realized that I made a mistake when I replied to Bilorv. Android has already made the changes; iOS is getting started on that work. I looked at your question on that ticket, which I think was not the correct ticket for that bug report — it looks like that ticket was closed in May 2020, and may not have been the right ticket anyway. I just asked the PM to take a look at it, and tell me where that report should go; I'll let you know when I get an answer. — DannyH (WMF) (talk) 21:06, 8 June 2021 (UTC)
- @DannyH (WMF): So I understand there is still a subset of logged-out mobile editors not getting talk page notifications, yet they are still editing? This is unacceptable.
- As has been stated above, if an interface does not have basic communication capabilities, then the interface should not have editing capabilities. --DB1729 (talk) 02:17, 8 June 2021 (UTC)
- @DB1729: I understand your dismay; I agree that communication is essential for productive wiki collaboration. I think that at the root, this is actually a flaw in the concept of allowing people to edit without an account on Wikipedia. Twenty years ago, it may have been roughly accurate to assume that IP addresses were mostly stable, because everybody had a desktop and mostly a dial-up connection, so if you posted a message for a particular IP address then you were likely to reach the same person. Today, the use of laptops at wifi hotspots and phones and tablets using cell service has basically broken that model. A few years ago, we reached the point when mobile pageviews hit 50% of our traffic, and by now the majority of Wikipedia readers are accessing our site with a mobile device.
- I think that your suggestion of restricting IP editing on mobile is an interesting one, and it's possible to argue that that should apply to desktop as well as mobile. But that's a much bigger conversation, and I don't think we'd be able to settle it here. — DannyH (WMF) (talk) 21:19, 8 June 2021 (UTC)
- I don't have the data, but edits I make using my phone usually come from the same IP (my home or work wifi) that my desktop edits come from. (I use responsive monobook, so my phone edits count as "desktop"). What's inhibiting communication with some mobile editors is not that their IP changes, it is that the software they use is not fit for purpose. Do you know any of the people who can fix the software? —Kusma (talk) 08:28, 10 June 2021 (UTC)
- @DannyH (WMF): Speaking of notifications Danny, for some reason I never got that ping from your last reply.(ironic) Did you get a confirmation it was sent? Thank you for the reply and for sharing your thoughts. In the meantime, yes I understand the dynamic IP problem, but these users are notified (I hope) when their IP addresses are blocked, are they not? Presumably when they open an edit window? Similarly, a talk page notification could be displayed only when there is an attempt to edit. It could then time-out or become invisible after a set duration, much like I assume a block notice will disappear once the block expires. DB1729 (talk) 15:48, 12 June 2021 (UTC)
#suggestededit-add 1.0
I think it would be a good idea to also bring up what I think is the related issue of the #suggestededit-add 1.0 process, as this seems to a mobile idea. See for example Jomart Allaguliyev (talk · contribs), a new mobile user who has made over 1000 edits exclusively through this process. Most are fine, but some are wrong, and some are almost nonsensical. Sometimes they re-do and worsen their own better work! [2] [3]. They've also a few times made the same edit twice after being reverted [4][5], which feels like something popped up and they simply repeated the action? The only documentation seems to be on Wikidata, so it is unclear how exactly these are happening or where they're happening from. There is an old Phab task (T227623) closed suggesting the process is working as intended. CMD (talk) 02:42, 22 April 2021 (UTC)
- I'm confused about how this is a suggestedit issue. That editor was given exactly one warning, as far as I can tell. If an editor is editing disruptively, the first step is to notify them on their talk page, isn't it? (Also, I have fixed your broken link above.) – Jonesey95 (talk) 04:26, 22 April 2021 (UTC)
- Thanks for the fix. The user is not editing disruptively, on the whole. The point is, this user's edits are being solely guided by some program out there providing editing suggestions to new users, provided by WMF, of which there seems to be little documentation. How is it not a suggested edit issue, when any potential disruptiveness would presumably be due to this feature? It would be nice to have documentation. If the edit summaries are automatically generated, why don't they include a wikilink to such documentation? The Mediawiki FAQ states only that it is to "Add short descriptions to articles that are missing descriptions", which is clearly not the case given these are edits to existing short descriptions. CMD (talk) 09:14, 22 April 2021 (UTC)
Wikimedia Foundation accessibility office hour 20 May (late notice)
We're hosting an open for everyone accessibility office hour on Global Accessibility Awareness Day 20 May 2021 from 8:30, 20 May 2021 (UTC) to 18:30, 20 May 2021 (UTC) --Volker E. (WMF) (talk) 17:04, 20 May 2021 (UTC)
- Making the announcement an hour and a half before ithe office hours closed made it so that nobody had time to bring up the fact that the WMF discriminates against the visually impaired and that this was reported over 15 years ago. I'm just saying. --Guy Macon (talk) 15:16, 24 May 2021 (UTC)
- @Guy Macon: How does it discriminate against the visually impaired and where was it reported? Genuinely curious. Kleinpecan (talk) 18:54, 10 June 2021 (UTC)
- On February 3 2006, it was reported to the WMF that our CAPTCHA system discriminates against blind people. See [ https://phabricator.wikimedia.org/T6845 ]
- This appears to be a direct violation of the Americans with Disabilities Act of 1990 and leaves Wikipedia open to discrimination lawsuits.
- Related:
- Wikipedia:Help desk/Archives/2016 July 20#I am visually impaired and can't edit articles without being asked to fill in the capcha
- https://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037341.html
- https://lists.wikimedia.org/pipermail/wikitech-l/2013-January/065820.html
- https://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037309.html
- Related:
- National Federation of the Blind v. Target Corporation was a case where a major retailer, Target Corp., was sued because their web designers failed to design its website to enable persons with low or no vision to use it. This resulted in Target paying out roughly ten million dollars.
- I have been repeatedly told that the proper way to request that Wikipedia stop discriminating against the blind is through phabricator, but clearly this was not effective in this case. I do not consider 15 years of refusing to answer to be reasonable behavior on the part of the WMF. I have been asking this question since 3 August 2017.
- What I expect from the WMF
- I expect a yes or no answer. Either the WMF makes an official statement saying "No, we have decided not to fix this" or an official statement saying "Yes, we have decided to fix this."
- If the answer is "Yes", I expect a page to be created (preferably on the English Wikipedia, but I will accept a page on Meta) that gives us the requirements (a testable definition of "done"), a schedule with milestones and updates, and budget and staffing information. The WMF has made multiple statements saying that they intend to be more open about these sort of thing, and this is an excellent place to show that the commitment to openness is more than just talk. --Guy Macon (talk) 22:01, 10 June 2021 (UTC)
- @Volker E. (WMF), Raystorm, Jimbo Wales, and Pundit:. Please don't ignore this. If you were pinged and it's not "officially" your job to take care of this, then please make arrangements for the person who's job it is to take care of this see the message and reply to it. And if there's no one who's job it is to take care of this, then please make a arrangements to appoint someone to take care of this. Headbomb {t · c · p · b} 23:01, 10 June 2021 (UTC)
- ...or be straight with me and tell me to my face that you refuse to fix this. Don't stonewall for fifteen years.
- Again, if nobody is assigned the job of fixing this, it won't get fixed. If fixing this isn't in the budget, it won't get fixed. If there is no deadline assigned, it won't get fixed. --Guy Macon (talk) 01:24, 11 June 2021 (UTC)
- @Volker E. (WMF), Raystorm, Jimbo Wales, and Pundit:. Please don't ignore this. If you were pinged and it's not "officially" your job to take care of this, then please make arrangements for the person who's job it is to take care of this see the message and reply to it. And if there's no one who's job it is to take care of this, then please make a arrangements to appoint someone to take care of this. Headbomb {t · c · p · b} 23:01, 10 June 2021 (UTC)
- If the answer is "Yes", I expect a page to be created (preferably on the English Wikipedia, but I will accept a page on Meta) that gives us the requirements (a testable definition of "done"), a schedule with milestones and updates, and budget and staffing information. The WMF has made multiple statements saying that they intend to be more open about these sort of thing, and this is an excellent place to show that the commitment to openness is more than just talk. --Guy Macon (talk) 22:01, 10 June 2021 (UTC)
Proposal that may be of interest to the WMF
Sorry if my English is a little bad. I am Brazilian and I came here just to make a proposal that is being debated in the Lusophone language and that you can move forward with the help of you and the WMF. What do you think of a partnership between Wikipedia and the Kindle? More information can be found on Wikipedia in Portuguese (more specific in the section Esplanade: Proposals). If this is not the right place to make this proposal, I ask you to guide me. Editor Master Plus (talk) 17:15, 24 May 2021 (UTC)
- I'm not part of WMF but I do think this is a good idea. I mean, Amazon Alexa uses Wikipedia for questions! But just out of curiosity, do you own a kindle and is there an encyclopedia on it? Oh and they would have to get deals with Amazon (company) to have it on kindle as it is owned by Amazon Thank you. Yaxops Banter 18:11, 24 May 2021 (UTC)
- So this is about w:pt:Wikipédia:Esplanada/propostas/Parceria entre Kindle e a Wikipédia Lusófona (24mai2021). Editor Master Plus, your proposal is effectively to add the library of the Kindle Store to Wikipedia:The Wikipedia Library. Except who exactly is going to pay for this? The Wikipedia Library can work because the partners primarily publish their own content. So giving accounts away for free costs them hardly anything. Amazon/Kindle however pays authors a per page rate, and those thousands of authors aren't going to waive that rate for Wikipedia. So you expect either the WMF (forget it) or Amazon (most likely forget it) to cough up the dough. — Alexis Jazz (talk or ping me) 08:53, 25 May 2021 (UTC)
@Alexis Jazz:, as I said in Lusófona: “It doesn't hurt to try”, I know it's very optimistic, but Amazon is big, and it sells to the whole world! We are a non-profit organization, and not a company that seeks profit, it would be unethical for them (the authors of the books) to charge for this, we are not gaining (in monetary terms) practically nothing with this. --Editor Master Plus (talk) 13:23, 25 May 2021 (UTC)
- Editor Master Plus, actually it does hurt to try when it's nothing but wishful thinking because it's a waste of time. This is an administrative hellhole and you have no idea how big of a hellhole (it's very, very big) or how to deal with it and you have no idea why Amazon would even consider this. On top of that, I'd actually be concerned that Wikimedia could get a WP:COI for all articles related to Amazon. — Alexis Jazz (talk or ping me) 20:48, 25 May 2021 (UTC)
- Alexis Jazz let me see if I understand, your justification for the proposal to be considered inadequate is because "it would be too complicated". I see, we all hate bureaucracy, but, with all due respect, I think that your argument is unsupported. I understand that we should avoid having to go through bureaucracy as much as possible, nobody likes that. But we can't just run away from bureaucracy and decide not to look for any more bureaucracy because "it would be too complicated". I think that, if necessary, we should go through the bureaucracy to get more partners. You call my proposal "very optimistic" I already said that I was really optimistic I just wanted to propose this idea here and see if the community has an understanding like mine. For the time being, two have manifested themselves. Once again I say that I understand your point of view and respect, but my point of view differs from yours (at least) on that point. I emphasize that I am speaking to you in a respectful tone. Editor Master Plus (talk) 21:23, 26 May 2021 (UTC)
- Editor Master Plus, with all due respect, your proposal is inadequate because it hasn't been thought through. It's like proposing world peace: everyone is in favor, nobody knows how. I already told you there is no incentive for Amazon to do this. That's your first hurdle, you'd have to think of something. But let's say you did it. I told you there's no way to get thousands of authors to agree. Just contacting them would be a challenge! And we can't even do it, Amazon would have to, because permission would have to go to Amazon. So now you have to come up with an incentive for Amazon to go through all that. But let's just say you managed this as well. (no idea how, but for the sake of argument) Since many authors won't respond or won't agree, Amazon would have to make changes to their infrastructure to exclude those authors. That'll be fun. But let's just say you managed this as well. (we are well into fantasy land already) I decided to read slightly more about Kindle Store. As I could have guessed, it uses Digital Restrictions Management. This is the polar opposite of everything Wikimedia stands for, so even if you manage to jump through all the previous hoops, we simply don't want it! It's fine to fantasize about silly things, you might accidentally run into something that turns out not to be entirely silly. But please don't ask others to fantasize for you. Do some research and think it through. Don't propose world peace unless you have already figured out a way to maybe make it work. — Alexis Jazz (talk or ping me) 03:33, 27 May 2021 (UTC)
- Alexis Jazz let me see if I understand, your justification for the proposal to be considered inadequate is because "it would be too complicated". I see, we all hate bureaucracy, but, with all due respect, I think that your argument is unsupported. I understand that we should avoid having to go through bureaucracy as much as possible, nobody likes that. But we can't just run away from bureaucracy and decide not to look for any more bureaucracy because "it would be too complicated". I think that, if necessary, we should go through the bureaucracy to get more partners. You call my proposal "very optimistic" I already said that I was really optimistic I just wanted to propose this idea here and see if the community has an understanding like mine. For the time being, two have manifested themselves. Once again I say that I understand your point of view and respect, but my point of view differs from yours (at least) on that point. I emphasize that I am speaking to you in a respectful tone. Editor Master Plus (talk) 21:23, 26 May 2021 (UTC)
- Editor Master Plus: No opinion about the idea, though I think Meta:Wikimedia Forum would be a better venue for suggestions like this, this noticeboard is specific to EnWiki, and is not well-watched. –xenotalk 13:38, 28 May 2021 (UTC)
IP Masking Update
The IP Masking team have provided an update on IP Masking that can be seen here.
Given this will affect many editor's workflows, as well as a fairly significant WP:PERM change, please take the time to look and comment Nosebagbear (talk) 13:12, 10 June 2021 (UTC)
- Serious issue for SPI, I think. Now, we often post accounts + IPs at SPIs to illustrate the total amount of socking. According to the proposal, "All users with accounts over a year old and at least 500 edits will be able to access partially unmasked IPs without permission. This means an IP address will appear with its tail octet(s) – the last part(s) – hidden. This will be accessible via a preference where they agree not to share it with others who don't have access to this information.": (emphasis mine) it will no longer be allowed to post any IP information, not even with the last octet(s) hidden, to SPI pages (or to other pages like AN/ANI). This will make battling disruptive IP sock editing much harder, and probably will increase IP vandalism. Fram (talk) 14:41, 10 June 2021 (UTC)
- Fram, I think the answer is simple; take ptwiki's lead and outright ban IP editing. -- RoySmith (talk) 15:00, 10 June 2021 (UTC)
- I think how SPI reporting would work is a good question to ask over at meta from this framework. Best, Barkeep49 (talk) 16:48, 10 June 2021 (UTC)
- Barkeep49, see my comments there. -- RoySmith (talk) 20:03, 10 June 2021 (UTC)
- Using my crystal ball, I foresee much more liberal use of semi-protection to protect the encyclopedia. --Malcolmxl5 (talk) 16:48, 10 June 2021 (UTC)
- There will clearly be unintended consequences to this, which could include banning unregistered editing or a large expansion of semi-protection, which will both result in a reduction in editing. If this is what the WMF want then they should go ahead with such a proposal, but I doubt whether they do actually want this, because I am sure there are plenty of employees who will look bad if edit numbers go down. Phil Bridger (talk) 17:18, 10 June 2021 (UTC)
- Without knowing the legal advice its really hard to predict how this is going to work out. Reality is whatever agreements you get people tick through Masks to IP lists will start being created. Only way to avoid it is fairly aggressive mask rotation at that point its essentially an open proxy and we block those on site.©Geni (talk) 17:39, 10 June 2021 (UTC)
- Agree that if the rational is to mask IPs because those editing from IPs don't understand the ramifications of doing so, then IPs need to be banned from editing entirely. Headbomb {t · c · p · b} 22:42, 10 June 2021 (UTC)
- Wow this is horrible. It's incredibly obvious that the authors of this (ill-informed) proposal at the WMF have spent virtually zero time reverting vandalism and/or culling LTAs. Agreed with the sentiments above; it's time to seriously consider following the ptwiki playbook and restrict editing to registered users. -FASTILY 00:38, 11 June 2021 (UTC)
- Before I go off and start writing code, do we have any statistics currently on quality of IP edits vs logged-in edits? I'm not sure how to measure "quality" but the most obvious metric would be what percentage of edits are reverted. -- RoySmith (talk) 01:35, 11 June 2021 (UTC)
- RoySmith: WP:IPHUMAN cites studies saying 80% of total vandalism is from IPs, but >80% of IP edits are not vandalism. Data is from 2004 & 2007 so it may have changed since then, but probably not too much. —pythoncoder (talk | contribs) 13:30, 11 June 2021 (UTC)
- I would expect the data to have significantly changed. In today's hyper-privacy-obsessed world, I think less people would be fine with having their IPs logged, unless they're just vandalising. – SD0001 (talk) 16:09, 11 June 2021 (UTC)
- Also - it was harder to get onto the internet back then -- smartphones didn't exist, and that acted as a filter for childish behavior like vandalism. Now any random person could just hop onto Wikipedia on their phone and make disruptive edits. -- Rockstone[Send me a message!] 01:48, 12 June 2021 (UTC)
- Actually, running this analysis again shouldn't be too hard. Take a 3 minute interval of all edits and see which proportion of them are made by IP users and which proportion of those edits are good. Compare to registered users. Easy peasy. -- Rockstone[Send me a message!] 01:49, 12 June 2021 (UTC)
- Also - it was harder to get onto the internet back then -- smartphones didn't exist, and that acted as a filter for childish behavior like vandalism. Now any random person could just hop onto Wikipedia on their phone and make disruptive edits. -- Rockstone[Send me a message!] 01:48, 12 June 2021 (UTC)
- I would expect the data to have significantly changed. In today's hyper-privacy-obsessed world, I think less people would be fine with having their IPs logged, unless they're just vandalising. – SD0001 (talk) 16:09, 11 June 2021 (UTC)
- RoySmith: WP:IPHUMAN cites studies saying 80% of total vandalism is from IPs, but >80% of IP edits are not vandalism. Data is from 2004 & 2007 so it may have changed since then, but probably not too much. —pythoncoder (talk | contribs) 13:30, 11 June 2021 (UTC)
- Uhh - if they're actually considering implementing this instead of just asking for suggestions, this is so incredibly shortsighted, I don't know what to say. I'm not sure how there's any legal impact to this, anyway. IP addresses are not private. They've NEVER been private. -- Rockstone[Send me a message!] 03:27, 11 June 2021 (UTC)
- I think the current form of IP masking that is to be implemented would turn SPI and AIV work into a logistical nightmare because the current plans for IP masking is that it would direct registered users with access to IPs, wishing to report unregistered editing on SPI and AIV to private mailing lists such as the info-en-v OTRS queue (in a similar way to how presently ArbCom deals with private evidence). As a result, my prediction is that we would see a substantial rise in emails sent to those OTRS queues compared to what the OTRS teams currently deal with.
The worst thing about it all is that the WMF hasn't come up with a credible-enough reason that would allow IP masking to be implemented in the way that they are hoping to achieve, and for the reasons I have mentioned earlier, would give rise for the enwiki community to implement sweeping changes to WP:OUTING which would make it easier for someone to get blocked from editing for simply disclosing an IP on-wiki. While I believe that someday IP masking will be implemented in one form or another, the implementation of IP masking on WMF projects should be deferred until the WMF can provide a satisfactory explanation for needing IP masking that would generate enough support from the Wikimedia community at large. Hx7 08:24, 11 June 2021 (UTC) - +1 to outright banning IP editing. Now is the time. – SD0001 (talk) 10:52, 11 June 2021 (UTC)
- I'm as "anyone can edit" as they come, but if the choice is "ban IP editing" or "some complicated mess", banning IP editing gets my vote. —Kusma (talk) 11:06, 11 June 2021 (UTC)
- I would support a ban on all IP editing, effective right after this change is rolled out to enwiki. The ban would be lifted if the WMF changes their mind. It's disappointing, but in light of the WMF's opacity/stubbornness, it's the only option we have if we don't want to open Wikipedia to floods of vandalism/abuse. —pythoncoder (talk | contribs) 13:27, 11 June 2021 (UTC)
- I sort of agree with WMF Legal's stance, but for slightly different reasons - no other major websites publicly log IPs to the outside world like we do anymore, and privacy laws are catching up. I would personally support disabling IP editing on all namespaces except main. I'm just slightly reluctant to go for complete disabling because I appreciate the argument that you shouldn't need to fill out forms in triplicate to fix a typo, but the way other sides solve this is by having a "log in from Google" or "log in from Facebook" option, which takes a couple of seconds. Now, we can argue about the pros and cons of that method until the cows come home, but remember that option isn't for us - we've already got accounts registered here - it's for the casual editor who wants to change "teh" to "the" on some article somewhere and couldn't give a flying monkeys about what the Wikipedia Adventure is. A general relaxation of when to semi-protect may be the answer as well. Ritchie333 (talk) (cont) 13:58, 11 June 2021 (UTC)
- Thinking a bit more about this I am getting more and more convinced that this will do nothing to increase privacy and may well reduce it. Every web site that you visit knows your IP address - that's simply the way that the Internet Protocol works - so no amount of masking or anything else will prevent you from revealing it. Introducing measures such as masking may well lead to people thinking that they are not revealing it when this is not the case. We should be educating people that every time they visit a web site they are revealing something about themselves, rather than trying to convince them that they are protecting their privacy when they visit Google or Facebook or a political blog or a porn site or Wikipedia or whatever. Phil Bridger (talk) 19:32, 11 June 2021 (UTC)
- Phil Bridger, Actually, "no amount of masking or anything else will prevent you from revealing [your IP address]" is incorrect. See WP:PROXY.
- But, that's not my main concern here. I'm mostly wearing my SPI Clerk's fez and looking at how an already difficult task will be made even more difficult. Even if the full IP information is still visible to authorized users via some new tool, it's another level of complexity to an already complex job. We're already losing the war. This will just be one more thing on their side of the balance. -- RoySmith (talk) 20:37, 11 June 2021 (UTC)
- If you are using a proxy then you reveal your IP address to the proxy. If you want any response to anything you have to reveal it to someone, or it simply doesn't get back to you. Phil Bridger (talk) 20:41, 11 June 2021 (UTC)
- I find that a shortsighted take. There used to be a time, where 'the internet' knew all the sites you came from and went to, all traffic went unsecured over the line etc, and XSS and CSRF issues were the default. .Those are all holes that have been mostly closed. I find it incredibly logical that IP information is being hidden more and more, esp from other visitors of that website. Educate ? ppl don't even read the ToS, and you are going to explain what an IP address is and its privacy implications are to that 99.9% of the masses that didn't used to be online when you yourself were first introduced to the Internet ? For the masses, the Internet is no more than a utility to complete their goal. It's exactly that the technology sector is caring more and more about protecting the privacy of the masses that they still have any privacy left. Some divisions of Google and Facebook might have be dragged into that new reality kicking and screaming, it's undeniable that it is happening and has been happening for years. —TheDJ (talk • contribs) 20:51, 11 June 2021 (UTC)
- I'm not entirely sure why this is Wikipedia's problem. We assume that editors are competent enough to realize that their IP is revealed when they make edits unregistered. -- Rockstone[Send me a message!] 23:30, 11 June 2021 (UTC)
- Can I push the people commenting here to comment on the IP:Masking talk page - viewpoints here don't necessarily get read by the relevant people Nosebagbear (talk) 01:17, 12 June 2021 (UTC)
- That's meta:Talk:IP Editing: Privacy Enhancement and Abuse Mitigation where it is made clear that IP masking is coming, ready or not. Johnuniq (talk) 23:44, 12 June 2021 (UTC)
- It would be interesting to learn more about the impact of IP editing ban on Portuguese Wikipedia. It looks like early after the implementation, vandalism decreased dramatically and daily account creation almost doubled. Also, if we ever get to that point, we would need to coordinate it with the WMF. If this is done through edit filters or range blocks, WP:THEYCANTHEARYOU will ensure that unregistered users on mobile apps will have no clue about what's going on. MarioGom (talk) 17:58, 13 June 2021 (UTC)
- I'd also love to hear about the effect on ptwiki checkuser workload. —Kusma (talk) 18:43, 13 June 2021 (UTC)
- MarioGom, Johan (WMF) is working on compiling that and will be presenting it "in the near future", but I don't know what the exact schedule is. If you're interested in the data, you should add meta:IP Editing: Privacy Enhancement and Abuse Mitigation#Data on Portugese Wikipedia disabling IP edits to your watchlist. -- RoySmith (talk) 18:52, 13 June 2021 (UTC)
- I know this goes against the idea of the "encyclopedia anyone can edit" but the time's come to end IP editing. Things have changed in the time Wikipedia has been around, and at this point, creating an account needs to be the way to go. Will we lose a few editors due to this? Most likely yes. How many of those will be productive though? Any other site I go to at this point, in order to edit, or post a comment, etc. I need an account. It's time we go that way as well. RickinBaltimore (talk) 12:08, 14 June 2021 (UTC)
- This is a ludicrous idea, and the only responsible thing to do now in order to protect the encyclopaedia and good-faith editors is to ban all IP editing. That or we just give up and let the vandals have their playground. DuncanHill (talk) 13:57, 14 June 2021 (UTC)
- I agree with WMF Legal's stance. The reality is that the status quo with publicly logged IPs to all is not really acceptable. Don't really mind whether IP editing stays or goes, but I note that it's really not difficult to register an account here, and if IP editing is disabled then who's to say the problem editors wont just create tons of accounts which are even harder to link together? Pretty indifferent about banning IP editing as a result, but the data from ptwiki (I think?) seems good, and arguably it'll stop the "wanna make this bad edit, but too lazy to register" variety of edits. Arguably IP editing is now a bit archaic and more problem than it's worth. ProcrastinatingReader (talk) 14:02, 14 June 2021 (UTC)
- That said, it would be nice to know why people think this specific plan is bad. It seemed fine to me. ProcrastinatingReader (talk) 14:07, 14 June 2021 (UTC)
- ProcrastinatingReader, I'm looking at this mostly from the point of view of a SPI clerk and a tool developer. This plan obscures information, which means it will make both of those jobs harder. Yes, the information will still be available via a WMF-supplied tool, but that adds another level of complexity to the job of investigating a SPI case.
- It will certainly make it more difficult to build automations of various kinds, and make people more dependent on WMF to add features to their tool rather than just rolling our own. I mean no disrespect to the WMF developers, but their time is limited and WMF priorities don't always line up perfectly with the priorities of enwiki editors. Any time you hide information behind a layer of access control, it adds complexity.
- If the goal is to prevent an editor's full IP address from being publicly visible, making it impossible to edit anonymously meets that goal.
- You asked a legitimate question; I hope I provided a useful answer. There's no doubt that a lot of the comments above reflect a "I hate the WMF and everything they do" mentality, which is sad. That's not where I'm coming from. -- RoySmith (talk) 15:18, 14 June 2021 (UTC)
- If WMF creates permissive API endpoints that provide the raw data, that would alleviate this issue, right? Then developers could create userscripts to use the data in different ways, possibly up to the point of reversing the effects of the masking entirely? (for users who have the required permissions) ProcSock (talk) 15:37, 14 June 2021 (UTC)
- If too many users have the permission, this is likely going to cause IP masking data to leak. Don't know if that is a problem, but this is why I don't expect things to be as easy to use as now. —Kusma (talk) 15:56, 14 June 2021 (UTC)
- ProcSock, To some extent, yes. That would eliminate the need to get WMF developers to update their tool. But it would still be added work on our part. And the set of people with the technical skills to access an authenticated API is smaller than the set of people with the technical skills to grab the text from a wiki page and parse it with whatever local tools they have. Also, SPI clerks often have conversations along the lines of, "I see X, Y, and Z IPs in the archives. To cover that range, it would take blocking the /25, but I'm thinking I'll just block the /28 since that seems to cover the recent activity". It would no longer be possible to have conversations like that in the public forum of SPI. -- RoySmith (talk) 16:03, 14 June 2021 (UTC)
- If too many users have the permission, this is likely going to cause IP masking data to leak. Don't know if that is a problem, but this is why I don't expect things to be as easy to use as now. —Kusma (talk) 15:56, 14 June 2021 (UTC)
- If WMF creates permissive API endpoints that provide the raw data, that would alleviate this issue, right? Then developers could create userscripts to use the data in different ways, possibly up to the point of reversing the effects of the masking entirely? (for users who have the required permissions) ProcSock (talk) 15:37, 14 June 2021 (UTC)
- That said, it would be nice to know why people think this specific plan is bad. It seemed fine to me. ProcrastinatingReader (talk) 14:07, 14 June 2021 (UTC)
- I'd say that the best route to protect the project in this case is going to be to disable IP editing in response. !ɘM γɿɘυϘ⅃ϘƧ 17:54, 14 June 2021 (UTC)
- So as someone who is currently unsure on the logical response re IP-editing remaining, I would highlight a couple of significant negatives: one is that it's not so much the direct positive editing from IP editors that is beneficial. It's the longer-term conversion to registered productive editors that's valuable. Many of us made our initial edits as an IP. The question that none of us can truly know, and it would take at least a year to have any real idea, is what % of that group would have just directly registered accounts. A fairly small difference makes a big impact on the weight of that prong. The other is that banning IP-edits would drive up the number of CU requests. A lot. We already have less coverage than we'd like and it's not something we can just choose to fix without issue. Nosebagbear (talk) 20:10, 14 June 2021 (UTC)
- We are not and never were like other websites, so I do not believe we should require registration just because other sites do. I don't know how popular you all are in your social circles, but I doubt my friends will be clamoring to create a Wikipedia account just because I edit here. I signed up for social media sites because my friends were there and I had to if I wanted to interact with them. I signed up for newspaper websites because it is required to read most content. I sign up for web apps because it is required to use them. Other websites incentivize registration through coercion: if you do not register you miss out on core functionality. That is not true of Wikipedia; our content will always be entirely free and available regardless of whether people create an account or not. Most people don't care about editing Wikipedia at all--they just want to read our content--so eliminating unregistered editing will not entice them to register, but it will stop them from fixing typos they see while reading. For those who are interested in editing, it creates an unnecessary barrier that will only serve to decrease organic editor recruitment.The main concern is that IP masking will make some things harder. That seems based on little more than fear of change since any change will make some things harder; meanwhile no one seems to care about how it will make editing harder for other editors like unregistered editors or checkusers. The proposal will still allow admins to see unmasked IPs so we can still effectively calculate range blocks. There will be a new user right that will allow us to expand this ability to non-administrators meaning that non-admin SPI clerks can still effectively do their job. Similar to autoconfirmed and extended confirmed, all registered users will be able to see parts of an IP address without disclosing the most identifiable parts, allowing most regular editors to determine and check whether a range block will be effective. If we require registration though, all of this will require checkusers since this IP info will be behind an account and we (rightly) have tight controls over when and how that gets accessed. The biggest difference that the IP masking proposal brings is that unregistered editors will have similar privacy protections as registered editors do: deletion of personally identifiable information (IP address) after 90 days. Currently we rarely block IPs for more than a few weeks. Checkusers already have issues connecting registered masters to very old IPs. Why is this? Because IPs change constantly. If we are going back more than 90 days we run a major risk of going off of stale information anyway. In most cases we won't need to look back that far, and even in the cases where we do it's not particularly reliable. Will IP masking make some things harder? Yes, but so will requiring registration to edit. The difference is that one thing requires us to make compromises so that we can accommodate greater privacy for editors, while the other lets us centralize power among established editors to create an even more exclusive editing environment while offloading the hard work to other people.Regardless of IP masking, I'm staunchly opposed to restricting unregistered editing. It creates an unnecessary barrier that undermines our core principles for little net benefit. There are certainly improvements that can be made to the IP masking proposal, but our response to increased privacy protections for unregistered editors should not be to throw out one of the core features of a public wiki. We should be working to bring in more editors, not devising new ways to exclude groups of people we're prejudiced against. — Wug·a·po·des 23:49, 14 June 2021 (UTC)
- I must admit that I did not read that whole comment, but certainly agree that "we are not and never were like other websites". If anything is done because others do it then the sites that we should be following are online free encyclopedias that anyone can edit that have been much more successful than Wikipedia. There are obviously none, so we should be leading, not following. Phil Bridger (talk) 20:02, 15 June 2021 (UTC)
- I say we give it a shot and see what happens before we panic. While I may not be a fan, I also am not sure I see the need to ban all IP editing. Lets just wait and see what actually happens and respond in an informed and responsible manner. PackMecEng (talk) 23:57, 14 June 2021 (UTC)
- Well what's the fun in that? Levivich 00:30, 15 June 2021 (UTC)
- These discussions start too early—initially, people were merely saying that if IP masking proved to be a problem, IP editing might have to be curtailed. I'm not ready to vote but have two observations. First, there is always a significant number of contrarians for any topic and it is likely that many of the constructive IP editors don't create an account because they don't have to and they don't want to change their habit. Requiring them to make an account might actually be doing them a favor because then they can think that they only did it because they had to, and an account has several benefits. Second, vandal accounts are easy to deal with—once detected, all their edits are usually inspected and reverted if necessary. That's not so easy with shifting IPs. I have seen many such IPs who change numbers or other factoids—checking each edit might take an hour and that's not going to happen. You can ask the IP why they made the change but that is usually pointless (example of me trying to reach one person on five different IPs: 1 + 2 + 3 + 4 + 5). If a registered editor makes frequent edits without explanation they are eventually blocked indefinitely. An IP might not be blocked at all because tomorrow a new person could conceivably make a good edit. Johnuniq (talk) 03:48, 15 June 2021 (UTC)
- Playtime is over for the WMF. I'd agree with Kusma's point, and refer you to PythonCoder's list of bad WMF decisions. Ironically, it is their victim Fram who started this thread. Had Jimbo Wales been pinged yet? Firestar464 (talk) 04:01, 15 June 2021 (UTC)
- The process for blocking IPs currently involves the caution against blocking sensitive IP addresses. It's just a matter of time 'til someone unwittingly blocks one of them because we no longer know they're "sensitive". Shall we write the headlines now, "Wikipedia censors Congress/Senate/Parliament/White House"? Cabayi (talk) 11:48, 15 June 2021 (UTC)
- Firstly, admins can still see complete IPs under the WMF's current plan. Secondly, if a person connecting from the WH/Congress is blocked for vandalism or some other form of trolling, then I imagine it would be more embarrassing for that Congressman (or their aides) to tell the media which edits got them blocked, than it would be for the administrator pressing the block button. Afaik there exists no policy that says people from Congress get a pass on problematic editing (and if there does it should be scrapped), so I don't see why it should play be a factor at all anyway. ProcrastinatingReader (talk) 12:32, 15 June 2021 (UTC)
- To Proc, actually there will be admins who don't see IPs, if they don't opt in to view them, but generally yes. I'd also note that I assume that in the information they're raising to editors with the new tool, "sensitive IP" would be a logical category. There are reasons to oppose this, but this isn't really one of them Nosebagbear (talk) 12:46, 15 June 2021 (UTC)
- Cabayi, Totally orthogonal to the IP masking issue, the whole "sensitive IP address" thing is a minefield. We have these nice tools called computers which are very good at answering questions like, "Is this number an element of that set of number ranges". The idea that we're relying on humans to make those lookups every time they block an IP is absurd. I know I don't do it. I suspect the vast majority of admins don't do it either. If we really cared about it happening, the software would do it and give you a warning before you could hit the Confirm button. -- RoySmith (talk) 13:59, 15 June 2021 (UTC)
- RoySmith, As far as I recall, if you try and block an IP on the range of "sensitive" ones, you are asked to confirm if that's really what you want to do. Ritchie333 (talk) (cont) 15:22, 15 June 2021 (UTC)
- Ritchie333, Ah, cool. Now I have to figure out if I want to test that it actually works -- RoySmith (talk) 15:27, 15 June 2021 (UTC)
- @RoySmith, Ritchie333: I get a warning for Special:Block/143.228.0.1, but Twinkle block on Special:Contributions/143.228.0.1 gives no warning. (Didn't try to execute the block, though). Aren't most blocks through Twinkle? —Kusma (talk) 15:30, 15 June 2021 (UTC)
- Kusma, I don't think I've ever used Twinkle for blocking. Most of my blocks these days are by either clicking one of the "block user" or "spi block" links that {{checkuser}} generates (both of which get you to the Special:Block form), or (more frequently) by letting User:GeneralNotability/spihelper do it for me. -- RoySmith (talk) 15:53, 15 June 2021 (UTC)
- RoySmith, As far as I recall, if you try and block an IP on the range of "sensitive" ones, you are asked to confirm if that's really what you want to do. Ritchie333 (talk) (cont) 15:22, 15 June 2021 (UTC)
- When Congress was rangeblocked a few years ago, it was a good thing, as it drew attention to COI editing. Looking at United States congressional staff edits to Wikipedia#References, none of the headlines accuse Wikipedia of censoring anything. Levivich 14:35, 15 June 2021 (UTC)
- Firstly, admins can still see complete IPs under the WMF's current plan. Secondly, if a person connecting from the WH/Congress is blocked for vandalism or some other form of trolling, then I imagine it would be more embarrassing for that Congressman (or their aides) to tell the media which edits got them blocked, than it would be for the administrator pressing the block button. Afaik there exists no policy that says people from Congress get a pass on problematic editing (and if there does it should be scrapped), so I don't see why it should play be a factor at all anyway. ProcrastinatingReader (talk) 12:32, 15 June 2021 (UTC)
- Oppose banning IP editing I do 99% of my editing while logged out, only logging in when I absolutely have to because my setup is such that logging in is a major inconvenience (comfortably logged out right now as the PROJSOCK hurdle has finally been moved out of the way). If IP editing were to be disabled, that's ~2K edits/year lost from me alone. Not the end of the world? Sure, but do you know the difference between a disruptive edit and a good edit that never got made because the person who considered making it decided it was too much hassle to make it? Both result in immediate damage to the project, but the latter also causes long-term latent damage. If the project is to continue past the lifespan of its current contributors, we simply cannot afford to cut off the vital supply of fresh blood that IP editing provides. 78.28.44.31 (talk) 18:25, 15 June 2021 (UTC)
- That's why I support banning IP editing in all mainspaces except main. I've no problem if your 2K edits are spelling or grammar fixes, but if you post here, it's impossible to tell you're not a sockpuppet or a joe job. Ritchie333 (talk) (cont) 11:12, 17 June 2021 (UTC)
- I do not really get the purpose of this project, but it seems as if you want to provide a solution to those who do not want their IP address visible?
- I will simply leave my two cents here as many other people have done so as well. Those who do not want their IP visible can simply register an account. IP addresses also do not do a very good job at identifying people as IPs are really only attached to a particular location or a particular ISP. Wikipedia has done a very good job at protecting people's privacy. WMF does not do fingerprinting or any form of tracking as far as I know, and they only collect information needed to effectively moderate the platform.
- Those that do not want their IP address publicly visible can just create an account, no problem. Also in the privacy policy as it stands, WMF may release such information if they believe it is necessary to protect other users or the projects. I think this project may be a solution looking for a problem. Aasim (talk) 19:29, 15 June 2021 (UTC)
- My understanding is the ip masking is a legal thing, not a because the ip wants it thing. But I could be mistaken. PackMecEng (talk) 20:53, 15 June 2021 (UTC)
- The problem is that the legal has thus far refused to explain why this is needed. IP addresses are not sensitive information, at least not here in the US (where Wikimedia's servers are hosted). -- Rockstone[Send me a message!] 21:22, 15 June 2021 (UTC)
- Their explanation is the first link at the top of this thread. In short: it's a legal requirement. Levivich 21:35, 15 June 2021 (UTC)
- That's not how it reads to me. They're literally refusing to explain their reasoning. -- Rockstone[Send me a message!] 22:01, 15 June 2021 (UTC)
- Rockstone35, They have explained their reasoning here. It's one thing to say you don't like it, or that you don't agree with their reasoning, or that you think the cost to the smooth running of the project exceeds the value, but to say that they are "literally refusing to explain their reasoning" is just plain silly. -- RoySmith (talk) 22:28, 15 June 2021 (UTC)
- RoySmith, Legal explicitly refuses to describe why they thought this is a legal requirement (see their statement, because it isn't. I'm not saying that Wikimedia as a whole isn't explaining why this is needed, but the legal team certainly is not. -- Rockstone[Send me a message!] 22:39, 15 June 2021 (UTC)
- They can't disclose the legal advice they are giving, as doing so would violate attorney-client privilege. If a lawyer tells their client they are or might be out of compliance with the law, neither lawyer nor client would ever disclose that publicly. Same with a lawyer's advice for how best to comply with recent or expected future changes in the law.Anyway, I'm not sure what more of an explanation you'd expect about this: IP addresses are personal data, at least in certain situations, in the EU, California, and elsewhere, according to recent court decisions and legislation. The writing on the wall is clear: privacy protection of IP address is coming to more and more jurisdictions. It's obviously not legally prudent to reveal IP addresses publicly as we do; we may not be breaking any laws by doing so, but we definitely are taking on liability, and if we aren't breaking laws now, the laws are changing in that direction. We are/will be required to comply. IP masking is just a way of complying without entirely scrapping IP editing. If anything, in this instance, I think the WMF and WMF Legal are handling it just about as good as can be under the circumstances. Levivich 22:44, 15 June 2021 (UTC)
- @Levivich: While Johan and NKohli have been nicely communicative throughout, Legal can hardly be said to handling it as well as possible given that they waited until a huge amount of effort had gone into what was being participated by editors as a good-faith consultation before switching out that actually it was needed and they just hadn't been sufficiently clear. There are also a variety of questions asked around 14 weeks ago, some of which would not be answerable but others which would be (noted and accepted in the asking), including a number of "meta-questions". There has been no response despite Johan stating they've been passed on. If you have something restricting transparency then they would need to be nailing it in all the other comms, and that can not be said to be happening Nosebagbear (talk) 09:50, 16 June 2021 (UTC)
- They can't disclose the legal advice they are giving, as doing so would violate attorney-client privilege. If a lawyer tells their client they are or might be out of compliance with the law, neither lawyer nor client would ever disclose that publicly. Same with a lawyer's advice for how best to comply with recent or expected future changes in the law.Anyway, I'm not sure what more of an explanation you'd expect about this: IP addresses are personal data, at least in certain situations, in the EU, California, and elsewhere, according to recent court decisions and legislation. The writing on the wall is clear: privacy protection of IP address is coming to more and more jurisdictions. It's obviously not legally prudent to reveal IP addresses publicly as we do; we may not be breaking any laws by doing so, but we definitely are taking on liability, and if we aren't breaking laws now, the laws are changing in that direction. We are/will be required to comply. IP masking is just a way of complying without entirely scrapping IP editing. If anything, in this instance, I think the WMF and WMF Legal are handling it just about as good as can be under the circumstances. Levivich 22:44, 15 June 2021 (UTC)
- RoySmith, Legal explicitly refuses to describe why they thought this is a legal requirement (see their statement, because it isn't. I'm not saying that Wikimedia as a whole isn't explaining why this is needed, but the legal team certainly is not. -- Rockstone[Send me a message!] 22:39, 15 June 2021 (UTC)
- Rockstone35, They have explained their reasoning here. It's one thing to say you don't like it, or that you don't agree with their reasoning, or that you think the cost to the smooth running of the project exceeds the value, but to say that they are "literally refusing to explain their reasoning" is just plain silly. -- RoySmith (talk) 22:28, 15 June 2021 (UTC)
- That's not how it reads to me. They're literally refusing to explain their reasoning. -- Rockstone[Send me a message!] 22:01, 15 June 2021 (UTC)
- This is not a legal requirement. As they explain, this is an action by the Foundation to ensure the privacy of IP editors
—Publication of these IP addresses compromises the safety and anonymity of these users. In some cases, it may even invite the danger of putting people at risk of government persecution.
and later —Q Is this project the result of a particular law being passed? A: No.
— GhostInTheMachine talk to me 22:18, 15 June 2021 (UTC)- I kind of see the dilemma at hand and thought of a solution. Why not run the IP address through a hash algorithm then have that be the identifier used for anonymous users? If the salt is long enough, then it will take hundreds or thousands of years to figure out the IP address. There will be collisions, but that will only be a small handful of IP addresses.
- It also allows for the full IP to be hidden from everyone except database admins. Checkusers can still view these hashes when attempting to identify sockpuppetry, and if there are legal ramifications, database admins can share the raw IP data with appropriate officials. Admins would be able to see that an anon is in an IP range and block it, but would not be able to view their IP address. Aasim (talk) 23:40, 15 June 2021 (UTC)
- Done naively, that would destroy range information. However Crypto-PAn is a hash algorithm for IP addresses that does preserve ranges. The drawback is that anyone could recognize an IP on their own range, since they have both the original IP and the hash. I don't know if WMF-legal thinks that's a problem. I've brought Crypto-PAn several times with the WMF but never got a response other than "we'll look into it". Suffusion of Yellow (talk) 23:55, 15 June 2021 (UTC)
- They'll never SAY it's a legal thing.. Doesn't anyone understand how legal departments work ? If they confirm it's a legal thing the foundation has automatically
admitted faultcomplicated their own defence in any potential lawsuit and opens itself up to lawsuits being filed (most likely in the EU). —TheDJ (talk • contribs) 08:28, 16 June 2021 (UTC)- TheDJ, no one is expecting them to. I don't think anyone would figure it be wise for them to have "Q: Does this violate the law?" "A: Oh it totally does and we know that." However, that still does not make it acceptable to lie. If your conjecture were true, they should say nothing at all about that subject, not give a false answer. Seraphimblade Talk to me 00:53, 19 June 2021 (UTC)
- Their explanation is the first link at the top of this thread. In short: it's a legal requirement. Levivich 21:35, 15 June 2021 (UTC)
- The problem is that the legal has thus far refused to explain why this is needed. IP addresses are not sensitive information, at least not here in the US (where Wikimedia's servers are hosted). -- Rockstone[Send me a message!] 21:22, 15 June 2021 (UTC)
- My understanding is the ip masking is a legal thing, not a because the ip wants it thing. But I could be mistaken. PackMecEng (talk) 20:53, 15 June 2021 (UTC)
- I don't really understand the rationale that IPs are only useful to tech savvy users. I'm so dumb I got fired from the M&M factory for throwing away all the Ws, but even I can do a range block and a geolocate. GMGtalk 12:02, 17 June 2021 (UTC)
- Not only is this a solution in search of a problem—anyone who is concerned about revealing their IP can register an account—but it will actively prevent those of us who do not jump through hoops to register as "vandal fighters" from treating IP editors as humans by messaging them in welcome or thanks (including pointing out to them the advantages of registering an account) or explaining to them why their edits are being reverted. We want to encourage editors other than "vandal fighters" to interact with new editors or editors who are doing something inadvisable. In fact it seems to me that it will prevent even those who do secure the permission from starting talk pages for IP editors, which is fundamental to treating them as fellow humans.(Seems to me like a very counterproductive way to get out of fixing the WMF mobile apps that leave mobile editors unaware they have talkpage messages.) It also smears together multiple IP addresses on the same network, a particular concern with mobile networks and some countries that funnel internet access through a small number of IPs, thereby ensuring we can't distinguish IPs who make useful edits from others who don't: it effectively announces that they are all the same, which is presumably the opposite of the message the WMF wishes to convey about individual rights. If en.wikipedia reacts by banning IP editing, we lose anyone who would have tipped their toe in by making a first edit or two without registering (and many of us started that way), we violate the principle of "anyone can edit", thereby letting vandals spoil it for non-vandals, and we will lose a whole slew of IP editors, many of them long-term contributors, of whom I know of one ("BOB") who's a tremendously productive vandal-fighter and -reporter. I don't personally understand why anyone would rather reveal their location and possibly more by not registering, and put up with CAPTCHAs, the inability to start or move a page, and widespread anti-IP prejudice. But it's been more than 10 years since I registered my only account, so for all I know there is some intrusive questionnaire that I've forgotten or that the WMF has since introduced. Far more importantly, it's none of my business that someone would have different preferences from me, and this proposal would hurt such people, at the very least by forcing us to treat them all on the same basis as people who drop in from the public library to deface an article (and frequently get library IPs blocked). I can't think of a single justification for this, and can only see further damage from responding by requiring registration. Yngvadottir (talk) 23:25, 17 June 2021 (UTC)
- Where are you seeing the info that non-vandal-fighters will not be able to create IP talk pages, or that users on different IPs in a small range will be mapped to one account and not distinguished between? ProcrastinatingReader (talk) 02:22, 19 June 2021 (UTC)
- @ProcrastinatingReader: According to the Meta page, the proposal is to allow only "[c]heckusers, stewards and admins]" plus "[e]ditors who partake in anti-vandalism activities, as vetted by the community ...[a right that] could be handled in a similar manner as adminship", to see complete IP addresses; which would appear to me to be a requirement for creating or indeed posting to an IP talk page. (Creating or posting to such a talk page might also violate the secrecy that both classes of users would need to promise to uphold.) Other users "with accounts over a year old and at least 500 edits" would be eligible only to apply for the right to see all but the last part of the IP, which amounts to equating the edits from all IPs on a large range; every IP with the same initial parts would be indistinguishable except to the certified "vandal fighters" plus admins/functionaries (and this is expressly stated to be a matter of demonstrating need; they don't see any need other than vandal fighting). Has this since been modified? It's precisely IP editors we need to be able to reach with explanations and advice on-wiki before or as soon as possible after they get into trouble, because they are likely to be new editors and thus unaware they are breaching some rule or guideline, and because there's no way to e-mail them. I can't see any way in which the WMF has accommodated that need. Yngvadottir (talk) 03:45, 19 June 2021 (UTC)
- I think your assumption is not correct. According to the same page:
Q: If we don’t see IP addresses, what would we see instead when edits are made by unregistered users?
A: Instead of IP addresses, users will be able to see a unique, automatically-generated, human-readable username. This can look something like “Anonymous 12345”, for example.
- It seems to me that each unique IP will be passed through some kind of hashing function. e.g. 1.2.3.4. -> "Anonymous 6fagb". 1.2.3.5 -> "Anonymous 9ha1g". Of course anyone will be able to post on "Anonymous 6fagb" or "Anonymous 9ha1g"'s talks, without any extra permissions needed. You'd just need extra permissions to realise that they're both connecting from similar IP addresses, or to realise what their location is. But certainly it's worth clarifying with the WMF if you are concerned; they are responding on the talk of the meta page linked in the OP. ProcrastinatingReader (talk) 11:21, 19 June 2021 (UTC)
- After thinking about it, no thanks. A number of others have raised serious objections to this here, and it is yet another example of the WMF carelessly undermining collegial interactions between editors, not to mention making it harder for those of us who work on the projects. I have raised the issues here, where they will cause damage. If someone else wants to undertake the thankless task of trying to get them to listen to actual volunteers, that would be best. I don't speak the necessary argot and I understand that "negativity" is not welcome there. (Can IP editors post over there? I hope so.) Yngvadottir (talk) 21:18, 20 June 2021 (UTC)
- @ProcrastinatingReader: According to the Meta page, the proposal is to allow only "[c]heckusers, stewards and admins]" plus "[e]ditors who partake in anti-vandalism activities, as vetted by the community ...[a right that] could be handled in a similar manner as adminship", to see complete IP addresses; which would appear to me to be a requirement for creating or indeed posting to an IP talk page. (Creating or posting to such a talk page might also violate the secrecy that both classes of users would need to promise to uphold.) Other users "with accounts over a year old and at least 500 edits" would be eligible only to apply for the right to see all but the last part of the IP, which amounts to equating the edits from all IPs on a large range; every IP with the same initial parts would be indistinguishable except to the certified "vandal fighters" plus admins/functionaries (and this is expressly stated to be a matter of demonstrating need; they don't see any need other than vandal fighting). Has this since been modified? It's precisely IP editors we need to be able to reach with explanations and advice on-wiki before or as soon as possible after they get into trouble, because they are likely to be new editors and thus unaware they are breaching some rule or guideline, and because there's no way to e-mail them. I can't see any way in which the WMF has accommodated that need. Yngvadottir (talk) 03:45, 19 June 2021 (UTC)
- Where are you seeing the info that non-vandal-fighters will not be able to create IP talk pages, or that users on different IPs in a small range will be mapped to one account and not distinguished between? ProcrastinatingReader (talk) 02:22, 19 June 2021 (UTC)
Test IP range for testing the warning you are supposed to get when blocking certain special ranges?
- We need a range of unroutable IPs similar to 192.0.2.16 (talk · contribs · deleted contribs · logs · edit filter log · block user · block log) that is listed as "sensitive" so admins can test for warnings when blocking. I would suggest something in the middle of the 10.*.*.* range, --Guy Macon (talk) 16:02, 15 June 2021 (UTC)
- Guy Macon, I agree that a test range is a good idea, but why in 10/8? 192.0.2.0/24 would be the obvious choice per IPv4#Special-use_addresses. -- RoySmith (talk) 16:15, 15 June 2021 (UTC)
- 192.0.2.0/24 would only give you 256 addresses, many of which are already in use. 10.0.0.0/8 has 16,777,216 addresses. If we picked, say, 10.234.0.0/16 as or test range, that would allow the admins to test blocking up to 65,536 addresses, or let several admins test 256-address /24 blocks at the same time without walking over each other. 192.0.2.0/24 is typically used when testing a single IP, while 10.[something].0.0/16 is the usual choice when testing a range of IPs. --Guy Macon (talk) 17:39, 15 June 2021 (UTC)
- Guy Macon, But, the point is, 192.0.2.0/24 is a reserved range, so you're guaranteed (well, about as much as anything is guaranteed on the internet) that zero addresses in that range are in use. -- RoySmith (talk) 17:47, 15 June 2021 (UTC)
- Surely 256 is far more than enough for testing, so RoySmith is right, and we don't use the 10. addresses, so Guy Macon is right. Does it really matter which we use? Or are we going to get into a techie pissing contest that has no relationship to reality? Phil Bridger (talk) 18:09, 15 June 2021 (UTC)
- I believe the WMF internal network uses IP addresses in the 10.0.0.0/8 range and WMCS uses addresses in the 172.16.0.0/12 range, so for the avoidance of any possible side effects, it would make more sense to go for a range which is actually reserved in a way which makes it improbable that it has any usage, this 190.0.2.0/24, 198.51.100.0/24, and/or 203.0.113.0/24. stwalkerster (talk) 18:29, 15 June 2021 (UTC)
- RFC1918 says
- I believe the WMF internal network uses IP addresses in the 10.0.0.0/8 range and WMCS uses addresses in the 172.16.0.0/12 range, so for the avoidance of any possible side effects, it would make more sense to go for a range which is actually reserved in a way which makes it improbable that it has any usage, this 190.0.2.0/24, 198.51.100.0/24, and/or 203.0.113.0/24. stwalkerster (talk) 18:29, 15 June 2021 (UTC)
- 192.0.2.0/24 would only give you 256 addresses, many of which are already in use. 10.0.0.0/8 has 16,777,216 addresses. If we picked, say, 10.234.0.0/16 as or test range, that would allow the admins to test blocking up to 65,536 addresses, or let several admins test 256-address /24 blocks at the same time without walking over each other. 192.0.2.0/24 is typically used when testing a single IP, while 10.[something].0.0/16 is the usual choice when testing a range of IPs. --Guy Macon (talk) 17:39, 15 June 2021 (UTC)
- Guy Macon, I agree that a test range is a good idea, but why in 10/8? 192.0.2.0/24 would be the obvious choice per IPv4#Special-use_addresses. -- RoySmith (talk) 16:15, 15 June 2021 (UTC)
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets: 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
- If the WMF uses private IP addresses in such a way that a Wikipedia administrator blocking that IP address on the public internet is a problem, then they should [A] change the Wikimedia software to make it impossible to block those IP addresses, and [B] fire the idiots who didn't follow the advice in RFC1918 ("If an enterprise uses the private address space, or a mix of private and public address spaces, then DNS clients outside of the enterprise should not see addresses in the private address space used by the enterprise"). That's the whole point of private IP addresses. The system is designed so that 90% of the people reading this have a router with an IP address of 192.168.0.1 or 192.168.1.1 and yet they don't interfere with each other.
- BTW, has anyone at the WMF ever said that we should not block IP addresses in the 10.0.0.0/8 range? Or is that just a guess? --Guy Macon (talk) 20:52, 15 June 2021 (UTC)
- Back in 2013 I (in my role as an admin here, after some WP:SILENCE) blocked 10.0.0.0/8 to prevent accidental logged-out edits from the then-new Wikimedia Labs like we had done for the Toolserver. WMF people didn't think it would be a problem. But it turned out that blocking an IP also blocks requests that have that that IP in an X-Forwarded-For header, and some ISPs are misconfigured such that they emit private-range IPs to the public internet in X-Forwarded-For and so were caught by that block. Whether anyone still at the WMF would remember that if asked now, I don't know. Anomie⚔ 11:56, 16 June 2021 (UTC)
- Just for fun, I just logged into dev-buster.toolforge.org and (after some fun trying to remember how lynx worked), made this edit. I was half-expecting it to show up with the dev-buster's internal IP of 172.16.6.70, but I guess the toolforge boxes are (as they should be) behind a different NAT gateway.
- The interesting thing I learned is if you go to the contribs page for that IP, you get the "sensitive page" popup there too. Which is nice. It's still concerning that this warning is generated at a level that (apparently) is only visible to the web interface. If you're using some add-on tool that goes directly through the API, as far as I can tell, you could block the entire US government from editing (not sure that wouldn't be a bad thing) without any visible warning (which is certainly a bad thing). -- RoySmith (talk) 12:30, 16 June 2021 (UTC)
- Back in 2013 I (in my role as an admin here, after some WP:SILENCE) blocked 10.0.0.0/8 to prevent accidental logged-out edits from the then-new Wikimedia Labs like we had done for the Toolserver. WMF people didn't think it would be a problem. But it turned out that blocking an IP also blocks requests that have that that IP in an X-Forwarded-For header, and some ISPs are misconfigured such that they emit private-range IPs to the public internet in X-Forwarded-For and so were caught by that block. Whether anyone still at the WMF would remember that if asked now, I don't know. Anomie⚔ 11:56, 16 June 2021 (UTC)
- Please put my request for a test IP range on hold. We have a more serious issue. Having a test range is a convenience. Blocking users when the blocking administrator has no way of knowing who they are blocking is something we need to look into.
- First, we need to test to see if blocking an IP blocks a post with that IP in the X-Forwarded-For or in the similar Forwarded HTTP header specified in RFC 7239.
- If the answer is yes, we need to discuss whether this is desirable behavior.
- I am looking into Trusted X-Forwarded-For as mentioned here[7] Does anyone know anything about this? Are forged X-Forwarded-For headers a common thing? --Guy Macon (talk) 12:42, 16 June 2021 (UTC)
- It appears that there is also a X-Real-IP header. This article[8] talks about spoofingt them both. --Guy Macon (talk) 13:07, 16 June 2021 (UTC)
- @Guy Macon: I'm really befuddled why this is an issue. 192.0.2.0/24 is explicitly designed for exactly this sort of thing, and guaranteed never to be allocated to any real machine, and even if it were, it's also guaranteed never to be routed anywhere. It's designed to avoid exactly this sort of problem. Why are you so worked up over whether 10.0.0.0/8 can be used, when the right answer is simply that we shouldn't be using it for this at all.
- We've also strayed way out of what makes sense to be discussing on WP:VPW. I've started a thread at Template talk:Sensitive IP addresses; you might want to follow up there if you have concerns. If you believe the Wikimedia software in incorrectly processing X-Forwarded-For headers, you should open a phab ticket. -- RoySmith (talk) 13:13, 16 June 2021 (UTC)
- Speaking from experience: blocking 10. addresses can indeed block internal traffic, see for example this oopsie caused by internal XFF issues. Please, if we need to blindly block things for testing, use one of the test ranges: 192.0.2.0/24, 198.51.100.0/24, or 203.0.113.0/24. GeneralNotability (talk) 02:56, 17 June 2021 (UTC)
Editing news 2021 #2
Read this in another language • Subscription list for this newsletter
Earlier this year, the Editing team ran a large study of the Reply Tool. The main goal was to find out whether the Reply Tool helped newer editors communicate on wiki. The second goal was to see whether the comments that newer editors made using the tool needed to be reverted more frequently than comments newer editors made with the existing wikitext page editor.
The key results were:
- Newer editors who had automatic ("default on") access to the Reply tool were more likely to post a comment on a talk page.
- The comments that newer editors made with the Reply Tool were also less likely to be reverted than the comments that newer editors made with page editing.
These results give the Editing team confidence that the tool is helpful.
Looking ahead
The team is planning to make the Reply tool available to everyone as an opt-out preference in the coming months. This has already happened at the Arabic, Czech, and Hungarian Wikipedias.
The next step is to resolve a technical challenge. Then, they will deploy the Reply tool first to the Wikipedias that participated in the study. After that, they will deploy it, in stages, to the other Wikipedias and all WMF-hosted wikis.
You can turn on "Discussion Tools" in Beta Features now. After you get the Reply tool, you can change your preferences at any time in Special:Preferences#mw-prefsection-editing-discussion.
–Whatamidoing (WMF) (talk) 00:27, 16 June 2021 (UTC)
- Ironically, replying to this post using the reply tool isn't possible because there's a line break between your signature and the timestamp :P – Rummskartoffel 11:16, 16 June 2021 (UTC)
- Whatamidoing (WMF): Thanks for the update! I found the reply tool very useful, even as a former user of reply-link. MarioGom (talk) 06:43, 18 June 2021 (UTC)
Privacy policy changes
The WMF is changing the privacy policies.
Looks like mostly inconsequential changes. I'm a bit concerned by the removal of the text "[W]e do not allow tracking by third-party websites you have not visited (including analytics services, advertising networks, and social platforms)", but I think it might be already covered by some text elsewhere? There's already a line saying "We will never use third-party cookies, unless we get your permission to do so." Unsure if this matters. --Yair rand (talk) 22:47, 21 June 2021 (UTC)
- Nice of them to tell us. DuncanHill (talk) 23:48, 21 June 2021 (UTC)
- Most of it is just copyediting. One useful provision has been added, however, relating to access and removal of personal information. It's one of the things I contacted them about a few months ago and IMO a meaningful improvement. Shame they didn't do more about community handling of personal information, though. ProcrastinatingReader (talk) 01:15, 22 June 2021 (UTC)
- I would note that most privacy policies on any site will do copyediting and provisions that restrict data gathering with no notice, as it's assumed that no individuals will complain. It's the fact that the WMF has any time-gap that makes it look odd to our eyes. I don't see anything objectionable Nosebagbear (talk) 12:53, 22 June 2021 (UTC)
- Most of it is just copyediting. One useful provision has been added, however, relating to access and removal of personal information. It's one of the things I contacted them about a few months ago and IMO a meaningful improvement. Shame they didn't do more about community handling of personal information, though. ProcrastinatingReader (talk) 01:15, 22 June 2021 (UTC)
Self-Dealing on the WMF Board
I'm kind of surprised that this isn't already here.
Recently resigned chair of the Board of Trustees, María Sefidari has been immediately transitioned into a paid consulting role with the WMF, which raises some very serious ethical questions about board governance.
When asked, Maggie Dennis and others (including counsel) gave conflicting stories on the sequence of events that led to this breach of ethical governance. This kind of insider self-dealing not only raises ethical questions about how the WMF is run, but could also possibly raise legal issues; the sections of the code talking about private inurement were not written by accident.
But don't take my word for it, read the discussion and judge for yourself. This is a situation that should be discussed by the community, not brushed under the rug as insiders are trying to do.
General Counsel's reply was to completely duck the question and give meaningless boilerplate about doing better in the future, without any roadmap to remedying this situation.
CoffeeCrumbs (talk) 21:18, 25 June 2021 (UTC)
- I can't believe they hired a former board member. This is like nonprofit governance 101: even if it's below commercially-reasonable rates, you just don't do it, because it looks awful. Yikes. Levivich 21:53, 25 June 2021 (UTC)