https://bugzilla.wikimedia.org/show_bug.cgi?id=53069

MZMcBride <b...@mzmcbride.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|Low                         |High
           Severity|enhancement                 |normal

--- Comment #2 from MZMcBride <b...@mzmcbride.com> ---
(In reply to comment #0)
> First and most importantly: editing a wiki "anonymously"  means leaving a
> permanent, searchable trace of your IP address in connection with your edits;
> this is actually a non-trivial and in many cases highly sensitive piece of
> metadata. As a bare minimum requirement to ensure the safety and privacy of
> our users, we would need to build an educational system into the mobile editor
> that alerted users of their logged out status, made them understand the
> implications of this (e.g. if they're in a country where their edits could put
> them in danger, make sure they're aware that they're basically geo-targeting
> themselves by editing without an account), and let them login/signup before
> saving their edit.

This is a red herring, bordering on fear-mongering. This statement tries to
give the impression that anonymous editing is a new, unheard of concept. This
is silly. Anonymous editing has been fully supported in MediaWiki since the
dawn of time. The issues regarding anonymity, actual user privacy, risks
associated with IP editing, etc. are relevant to Wikimedia, but they have
nothing to do with this bug. Philosophical opposition to anonymous editing is
most certainly not an obstacle (or blocker) to re-enabling anonymous editing
via MobileFrontend.

> 1. Mobile devices are quite different from desktop in that it's much easier
> to fat-finger and accidentally do something you didn't intend to do. A highly
> motivated IP editor on desktop who accidentally (or as a test) blanks a page
> might discover the page history and the undo button – that's much harder to
> do on mobile, where the history view is currently so tiny and cluttered that
> undo is barely enough of a target to tap on, let alone see.

The mobile team has been working for years now on re-inventing the user
interface with these considerations in mind. If there are specific issues that
relate to anonymous mobile editing, please file separate bugs that block this
bug. As it is, you seem to be arguing that mobile devices are simply cumbersome
to edit from. I personally agree, but this isn't a blocker to re-enabling
anonymous editing.

> 2. On desktop, it's not as huge a break from your workflow to leave what
> you're editing, log in, and keep editing; on mobile, where everything is so
> focused and zoomed-in, that feels like a huge break.

Ummm, you've intentionally disabled anonymous editing. _That_ is what is
disrupting user workflow. If you re-enable anonymous editing, you'll solve this
issue altogether. You're currently arguing "well we put up this hurdle, but now
there's a hurdle." It's borderline tautological.

> 3. The abuse filter is already a huge problem for mobile, since on many wikis
> it's configured to show a CAPTCHA for certain conditions (non-autoconfirmed
> users adding links, adding/removing large chunks of text, or, on projects
> like Portuguese Wikipedia, making edits of any kind), which in turn causes the
> mobile editor to throw an error. Right now the error rate is hovering at an
> alarming 48% across all projects; making editing available to anons would
> guarantee that the error rate would skyrocket.

I'm not sure what this is about, but it sounds worrying if true. If 48% of
mobile edits are erroring, that would be a very high priority bug to get
resolved. Do you have a link to a bug report tracking this issue? Presumably
this bug report would also include links to the data you're basing these claims
upon.

> 4. A lot of the features we're building on desktop to keep people in the loop
> about what's happening to their edits (like email and Echo notifications) are
> for logged in users only, and those become extra critical communication
> mechanisms on mobile, where it's harder (and, again, a bigger break from your
> workflow) to find and check your talk page.

There's a big orange bar. MediaWiki has made intentional design decisions to
ensure that this big orange bar works for both anons and logged-in users.
You're erecting obstacles and other "I personally don't like anonymous editing"
arguments in the hope that one or some of them will stick. These problems are
_hardly_ unique to mobile editing or anonymous editing. Mentioning in them in
this context is misleading and unhelpful.

> This is already a problem on desktop, but it becomes exponentially more
> problematic with the wildly fluctuating IPs of most mobile devices.

Similar to the opening point, this can and should be discussed separately. It
may make sense to holistically re-evaluate our use of IP addresses for
anonymous users, as Brion, Greg Maxwell, and many others have noted. But this
isn't relevant to this bug. If we one day change from IP addresses to something
else, it has no bearing on anonymous editing being intentionally disabled on
mobile.

> For all these reasons and more, letting IPs edit on mobile is (for now) not a
> great idea [...]

This bug is a tracking bug for obstacles to enabling anonymous editing via
MobileFrontend. This bug report needs associated bug reports describing the
actual issues blocking re-enabling anonymous editing on mobile. Reading through
your lengthy comment, while you're unquestionably thorough, I don't see many
blockers. Perhaps the CAPTCHA issue, but I'd need more info to know for sure.
The philosophical issues about anonymous editing are moot in the context of
mobile editing. Anonymous editing is a [[m:founding principle]] of Wikimedia
wikis that can't simply be brushed aside by a small development team.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to