what about abuse by administrators and stewards ?
From: Moriel Schottlender
Sent: Monday, January 7, 2019 7:53 PM
To: Wikimedia developers ; Wikitech-ambassadors(a)lists.wikimedia.org
Subject: [Wikitech-l] Changes to the Block
paradigm
Greetings,
Have
you written code that deals with or depends on user blocks? Read on.
=
TL;DR: =
The new “Partial Blocks” feature has fundamentally changed the
way MediaWiki
considers what “block” means; any code that handles blocks
should consider
whether the questions it is asking are still valid or should
adjust its
expectations. Please read for more details.
= Preamble
=
A couple of months ago, as part of the Anti Harassment Tools
team’s
continued work on improving the general experience of our users
and
providing more robust tools to administrators, an RFC to enable
“Partial
Blocks[1]” has passed and has been implemented in MediaWiki,
affecting the
way blocking users operates.
While the actual feature,
enabling the blocking of users for specific pages
and namespaces, will be
slowly rolled out as part of our rollout and
testing plans, the change has
resulted in a complete change of paradigm for
what “block” means throughout
our code.
= Change of paradigm =
Until recently, Block was fairly
straight forward; whether a block was done
on an IP range or a specific user,
the question the code would ask is “is
the user blocked from this action” and
the answer will be a boolean yes or
no, depending on whether the user was
blocked from the wiki and whether the
action was a blockable
action.
With the new Partial Blocks feature, that question is now more
elaborate.
We are giving admins and wikis in general much more robust options
when
deciding to block IPs or users. “Sitewide” block is no longer the
only
option. Now, a user can be blocked from editing a specific page, and
soon
from a specific namespace. There are also blocks that prevent a
specific
action, such as uploading files or creating new pages.
This
means that the question “is the user blocked” is no longer accurate.
In most
cases, the question should be “is the user blocked from the action
on this
page”, because users may receive a block that is not sitewide, but
from a
specific page or set of pages.
= What we worked on =
The Anti
Harassment Tools team has been working diligently on making sure
that the new
blocking behavior does not produce obvious regressions in
production, and
does not add to any still existing inconsistencies. In
cases where we
identified a clear mismatch, we’ve tried to either fix it
outright or alert
the code owners to adjust.
If we have missed any iteration or use-case,
please open a Phabricator
ticket and add the ‘anti-harassment’[2] tag to it.
If the use-case is
sensitive or identifies a current loop-hole in the way
blocks work, please
make it a security ticket and alert us and the relevant
team immediately.
= General steps forward =
While the team is
following up on making the code clear and robust and
fixing what we’ve
identified as paradigm-changes to deal with, there are
still many instances
where the changes required to the code are not
straight-forward or clear.
Some extensions ask whether a user is blocked
and may need to change the way
that the product’s “business logic” behaves.
These are cases where we
cannot make the decision for the codebase. We
encourage you to look at your
product and consider adjusting if necessary.
= General guidance
=
We’ve identified some areas that may help code owners adjust their
products
to properly take advantage of the new feature and adjust to the
new
paradigm change. This list is not exhaustive, but may help you spot
areas
in your code that can easily be changed:
* User::isBlocked() has
changed its meaning, and its use cases should be
re-examined depending on
what your code intends to check.
For the most part, if there’s a Title object
available,
User::isBlockedFrom() is a good option. Otherwise, consider
using
User::getBlock() and Block::isSitewide()
* Block::prevents( ‘edit’ )
is an operation that doesn’t make sense
anymore, because a block on the
‘edit’ action now depends on context (the
title).
* Determining whether a
block prevents a user from editing their own user
talk page has
changed.
For a sitewide block, if the $wgBlockAllowsUTEdit config is false,
then the
block prevents the user editing their user talk page, but if it is
true,
then whether they can edit their user talk page depends on
the
ipb_allow_usertalk flag on the block. For a partial block to a page
or
pages, these flags are not taken into account: if the user’s talk page
is
specified as a blocked page, then they cannot edit their user talk page;
if
it is not, then they can edit it. Block::prevents( ‘editownuserpage’
)
should therefore not be checked for a partial page block[3]. We plan
to
deprecate that parameter officially, please consider if this affects
your
code.
* Please check that any classes that extend Action or
FormSpecialPage
return the correct value for requiresUnblock().
To
summarize, in general, the meaning of asking whether a block exists
has
changed, and any code piece that needs this information should
adjust
itself to account for partial blocks, depending on its
goals.
Thank you,
Moriel, on behalf of the Anti Harassment Tools
Team
References:
[1] Partial
blocks:
https://meta.wikimedia.org/wiki/Community_health_initiative/Per-user_page,_…
[2]
Anti Harassment tools
board:
https://phabricator.wikimedia.org/project/view/2660/
[3] For a
discussion of this, see: https://phabricator.wikimedia.org/T210475
--
Moriel
Schottlender (she/her)
Senior Software Engineer, Tech
Lead
Community Tech and Anti Harassment Tools
@mooeypoo (IRC /
Phabricator)
_______________________________________________
Wikitech-l
mailing
list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
There's been some comments on some old tasks such as T27707
<https://phabricator.wikimedia.org/T27707> about problems with uploading
files that include text metadata that looks like HTML elements.
Years ago, we added security checks for IE 5/6/7 to work around IE's mime
type sniffing: if you went to view a .png file directly in IE (as opposed
to in an <img>) the browser would check the first few bytes of the file to
detect its type, overriding the HTTP Content-Type header. HTML would be
detected with a higher priority than the actual image formats, making it
possible to create an actual .png image which when viewed as an image
looked like an image, but when viewed as a web page was interpreted as
HTML, including any embedded JavaScript.
(This was defense in depth in addition to hosting files on a separate
domain; among other things, we sometimes serve files out from the main
domain when dealing with archived (deleted) versions, and third-party
installs are not guaranteed to have a second domain.)
Browsers have moved on, but the code remains and it trips up legitimate
files containing links in metadata, or sometimes just random compressed
data that looks like an element!
I've done a quick research check on feasibility:
* IE 6 and earlier can no longer access Wikimedia sites due to lack of SNI
and TLS 1.0 or later
* IE 7 on Windows XP can no longer access Wikimedia sites due to lack of SNI
* IE 7 on Windows Vista **can** access Wikimedia sites.
* IE 8 and higher support X-Content-Options: nosniff to disable sniffing,
which we already use on all MediaWiki requests.
At some point Microsoft dropped the sniffing, but I'm not sure if it was a
later IE version or an Edge version. No other browsers in reasonably
current versions seem to have this problem.
So the only remaining browser version that might be affected is IE 7 on
Windows Vista, which supports SNI and TLS 1.0. It might or might not still
work once we drop TLS 1.0 some time in the future. (Per our TLS dashboard
<https://grafana.wikimedia.org/d/000000458/tls-ciphersuite-explorer?orgId=1>
about
1.2% of our connections still use TLS 1.0, but this isn't broken down
between logged-in-user views and anon views.)
Open questions:
* Should we drop the anti-sniff checks on upload?
* If we do, should we forbid logins with IE 7, or something else to protect
the occasional IE 7 logged-in user from a hypothetical targeted drive-by
attack? (Is it actually worth doing work and testing it for this?)
* Should we add X-Content-Options: nosniff on files served from
upload.wikimedia.org too?
-- brion
Hi all,
as some of you might know, HHVM has decided some time ago to drop support
for PHP, choosing to only support Hack (Facebook's own PHP-derivative
language)[1].
This forced us to consider alternatives. In particular the last major
upgrade to PHP, PHP 7, was supposed to have greatly improved the
performance of the runtime, guaranteeing performance on par with HHVM.
Given that early tests[2] showed promising performance, we decided to work
on PHP7 support and on its rollout in production.
I'm happy to announce that PHP 7 is now available as a beta feature on all
wikis, and I encourage everyone to try it out and report bugs using the
#php7.2-support tag.
After this period of beta testing, we will proceed with a progressive
rollout to a growing percentage of users, and hopefully we'll complete the
transition in the next four months.
A huge thank you to all the people who worked hard to reach this goal!
Thanks,
Giuseppe
[1] https://hhvm.com/blog/2017/09/18/the-future-of-hhvm.html
[2]
https://lists.wikimedia.org/pipermail/wikitech-l/2017-September/088854.html
--
Giuseppe Lavagetto
Principal Site Reliability Engineer, Wikimedia Foundation
Reminder: Technical Advice IRC meeting **today (Wednesday) 4-5 pm UTC** on
#wikimedia-tech.
Question can be asked in English, German & Persian.
The Technical Advice IRC Meeting is a weekly support event for volunteer
developers. Every Wednesday, two full-time developers are available to help
you with all your questions about Mediawiki, gadgets, tools and more! This
can be anything from "how to get started" over "who would be the best
contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for the Technical Advice IRC Meeting crew)
--
Michael F. Schönitzer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
Unsere Vision ist eine Welt, in der alle Menschen am Wissens der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
For those who weren't aware, Jack Phoenix and I have drafted a Request
for Comment[1] and related initial patch[2] proposing to merge the logic
from the Theme extension[3] into MediaWiki core.
From the RfC: This will provide built-in functionality that skins can
implement in a simple and consistent manner, enabling user- or
site-selection of css variations of a given skin, such as a dark version
or a layout with more colours.
The RfC itself covers in detail the distinction between skins and themes
as well as several use cases and issues surrounding the current
situation, but the key point here is thus: with this functionality, we
will be able to not just more easily implement night[4], winter, and
accessibility[5] modes in skins such as Vector and Timeless, but also
much more consistently, and in a manner that can then be developed to
better and more consistently use the variables defined by the skins even
outside of the themes themselves.
Currently, the Theme functionality is limited to the extension itself
and a few skins that replicate key parts with varying amounts of
fidelity, which not only results in a bit of a mess in terms of code
fragmentation, but also limits what we can do with the skins themselves
due to the added dependency. We would like to fix this, and thus invite
everyone interested to review our proposal and please, comment if you
have concerns or see any issues.
-I
See:
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Themes_in_core
[2] https://gerrit.wikimedia.org/r/#/c/465451/
[3] https://www.mediawiki.org/wiki/Extension:Theme
[4]
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Reading/Nigh…
[5]
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Reading/Acce…
Hi developers,
This is Kaushik Reddy. I am currently working on few data science tools,
naming few pandas, seaborn, Matplotlib,NumPy etc with python.
Can I propose projects for wikimedia dealing with data science?
If you people agree to have projects in data science, I would like to
propose few within 3 days.
Will be waiting for your response.
Regards,
Kaushik.
Hi people,
This is Kaushik again. I have gone through the proposed GSoC'19 project
ideas, they are all good.
https://m.mediawiki.org/wiki/Google_Summer_of_Code/2019
But , I am looking for something which can be done with python. I also
think the above projects can be done with python befriended with java
script.( Just suggesting, no offense).
I am really optimistic that wikimedia would propose some projects dealing
with Data science or python for GSoC'19.
I actually have many ideas regarding the above mentioned topics.
I would bring them in a good form and would like to propose before you
people soon.
with regards,
Kaushik.
Hello,
Per CoC[1], the appealing processes follows like this:
"Only resolutions (such as bans) that last more than one week may be
appealed by people who were sanctioned. Reported victims can always appeal.
To appeal a decision of the Committee, the reported offender or reported
victim may contact the Technical Collaboration team's Community Health
group at techconductappeals(a)wikimedia.org and they will review the case.
Until an appeal is resolved, the prior resolution remains fully in effect. "
The problem is that "Community Health group" doesn't exist anymore[2] [3],
Technical collaboration team is also reorganized, leaving us in a situation
that we don't have an appeal body anymore. All people in the old group are
still active so if they receive an appeal, they can handle it but this is
not sustainable.
Hereby we need to determine an appealing body. Please comment on
https://www.mediawiki.org/wiki/Topic:Uay0vz6no8ayac3m about this matter.
[1] https://www.mediawiki.org/wiki/Code_of_Conduct/Cases
[2] https://meta.wikimedia.org/wiki/Community_Relations/Community_health
[3] https://phabricator.wikimedia.org/T199086
Best
--
Amir
Hi, i am pleased to say that gerrit.wikimedia.org PolyGerrit theme has been updated to match timeless (blue/red/green) instead of the plain grey.
this is what it looks like: https://phabricator.wikimedia.org/F28019595 in 2.15 and in 2.16: https://phabricator.wikimedia.org/F28019604
Thanks to thcipriani who played with my original change and made it look much much better (awesome), addressing feedback from Volker E.
Also thanks to Luca from upstream which came up with a original theme for GerritHub which my change is based on!