Dear Dariusz
I quite understand that some members of the Board feel that there are more
important calls on their collective time and resources than engaging
directly with individual members of the community, even though some do feel
that they may be able to as individuals. I note that you feel that it is
possible that returning to this issue next year the Board may be able to
make some improvements (and, we presume, may not). So you propose to park
the issue and maybe do something in the future, but without any sort of
urgency or commitment.
This attitude makes perfect sense if you see engagement with individuals as
a drain on your resources, a communications overhead which can only
distract and detract from the other more important things that you need to
be doing, whatever those may be. It makes sense if the Board regards
itself as lacking in all other resources, human and financial, to invest in
making an engagement productive. It makes sense if the Board regards the
community as a lumpenproletariat of contributors fit only for routine work
but devoid of all strategic capacity, understanding and insight.
I think this is completely mistaken. The community has far more resources,
far better ideas, and far more experience than the Board on its own can
possibly hope to have – if only the Board were willing and able to tap into
it. Constructive engagement would not only pay for itself purely in terms
of avoiding the conflicts which have drained everyone's time and energy in
the past, but also enable the Board to take a more far-sighted and positive
attitude to the future direction of the mission.
The Board's failure to engage effectively with the community until now, and
lack of interest in doing so in the future, is putting the mission at
risk. What a shame.
Yours
"Rogol"
Thanks to C. Scott Ananian for a response which is more informative than
almost all the other communications I have received on the subject of
planning for the future of the editor and parser software. It will not
come amiss, I hope, if I pick up a few points for further discussion.
Firstly, my posting was not "bait" nor does it require the teams and
projects to be defended. It was intended as constructive criticism and as
such I would hope that the people concerned take it in that spirit.
However, I quite understand that no criticism, however well justified or
motivated, is ever entirely welcome.
Secondly, while Scott is a Senior Softwre Engieer in the Parsing team, I
take it that his comments are more a personal point of view than a formal
expression of intention on the part of the Foundation. If I'm wrong, and
he is speaking with full authority for the Foundation on some or all of the
points he makes, it would be helpful to have that noted explicitly.
Thirdly, let's look at the point "WMF has become scared of large scale
projects after the community rejection of Visual Editor,Media Viewer, and
Flow. It has interpreted the community's reaction to these projects as a
directive to "think smaller" and concentrate on simple reactions to user
bug reports." That may be the case, but if so it represents a major
category mistake. The community reaction was against having unwanted and
unworkable changes imposed on them by force majeure without previous
involvement and without consultation, and that is completely and
overwhelmingly obvious from their reaction. The size of the projects was
never the primary issue. If the WMF wanted to know, raher than guess, what
the community's view was, and why they reacted as they did, and if it was
genuiney unsure about those points, and especially if it saw itself as
being directed by the community, then it could and should have engaged with
the community to find out what it was that the community did and did not
want. This did not happen at the time, still does not happen in any way
that can support sensible planning, and very badly needs to happen. Of the
WMF staff view themselves as have been directed by the community to do or
not do anything over the last couple of years, then you and they need to
kow that this is very much the opposite of the view from the community.
Fourthly, there is the issue of wikitext. This is not the place to discuss
the technicalities. The point at issue is that the huge investment by the
community of contributors in extant wikitext, and the major effort and
disruption required to modernise, will have to be balanced against the
benefits of a new system, whatever that might be. This cannot work unless
there is full, clear and open engagement between WMF developers and the
wider community. Currently that simply is not happening. I have
explicitly asked where plans for the future of the editors and the parsr
unification project can be seen, and there has simply been no response. Do
those plans exist? If so, where are they, and why are they not being
shared wth the community. If not, why and how is any work proceeding, and
what process will be used to developt those plans, and in particular, hwow
will the community be involved? These are not questions of idle curiosity
for one particular user's satisfaction, they issues requiring clear and
public articuation as key components of any successful future staraegy to
avoid the disastrous mistakes of the past.
Fifthly I note that there have been repeated assurances over time that the
content of the databases will continue to be wikitext, and that wikitext
will be directly editable, at least for the foreseeable future. Those
assurances came from people who oight to know and who appeared to be
speaking on behalf of, and with the authority of the WMF. The comments
made by Scott do not entirely support those assurances.
Finally I repeat my thanks for what has been one of the more informative
and positive responses I have yet to see in this area. I note that the
message of much improved engagement between WMF staff and volunteer
community is one that it shared to some considerable extent, and I reagrd
that as a step in the right direction,
"Rogol"
Christophe,
Thank you for explaining that there were two meetings involved.
I welcome the assurance that the agenda will be published earlier in future.
"Rogol"
Do any of the volunteers contributing to this list have ideas for
changes that may make a significant difference to security?
Yesterday saw Jimmy Wales' Wikipedia account getting hacked, in the
process appearing to promote an organisation.[1] It was not the only
account compromised. This is being analysed, though as there are
security issues being examined, the analysis has not been made public
so far; plus it's the weekend :-)
Over the last few years, there have improvements on account set-up and
choice of passwords, along with user suggestions for better account
management. Users can also chose to use committed identities[2] to
make account recovery easier, and are encouraged to use more secure
passwords. Two-factor authentication,[3] such as using mobile phone
text messages, has been suggested a few times by volunteers, and this
might be a good moment to encourage the WMF to have better facilities
built into the projects. We could even make two-factor identification
a requirement for trusted users, such as administrators, important
bots, and "high profile" accounts, where they may have special rights
that could cause a fair amount of disruption if a hacked account were
not identified quickly. Considering that some administrator accounts
can lie dormant for many months without the actual user monitoring it,
these could end up being far more disruptive than well-watched
accounts like Jimmy's.
We may want extra security to remain mostly optional, keeping our
projects simple to access. Education of new volunteers and trusted
users may be critical for making it effective, such as avoiding social
hacking. A clearer understanding of what the community would want to
see improved would probably help set development priorities.
Links
1. https://en.wikipedia.org/wiki/User_talk:Jimbo_Wales#Compromised
2. https://en.wikipedia.org/wiki/Template:Committed_identity
3. https://en.wikipedia.org/wiki/Multi-factor_authentication
Thanks,
Fae
--
faewik(a)gmail.com https://commons.wikimedia.org/wiki/User:Fae
Jimmy
Thank you for your views on mailing list etiquette. The broader issue you
refer to, which I raised in the posting to which you took such exception,
is how and where the Board wishes to engage with the community, and whether
it is resourced to do so. It seems that their noticeboard on Meta is not
their preferred answer, but unfortunately we still do not know what the
answer is for the Board collectively.
"Rogol"
>> storing the geolocation of every reader request is not within
>> the letter or the spirit of the Foundation's privacy policy,
>> which explicitly requires consent for the use of geolocation
>
> No, this is not correct. The reasons why this statement is
> incorrect have already been discussed in the already mentioned thread.
The only such discussion I see on the analytics list is:
> The privacy policy talks about client side geo location to offer you
> geo-specific features on the client side, which is an entirely different
> topic of what we are taking about here. IP addresses are going to be
> sent via HTTP regardless with your request and the geo location we
> do (to be able to report for example pages per country, one of the
> reports most sought after by our community) has nothing to do with
> geolocated features.
On the contrary, all geolocation services, processing, and logging
is performed on Foundation servers, not client equipment. Every
reader's request is currently being geolocated without regard to
whether consent has been asked or obtained. If readers' refuse
consent for their GPS information to be used (which is the only
consent we ask even though the Privacy Policy says we require
consent to use any geolocation) we store their IP addresses in
the clear with their associated geolocation anyway, and make
them available to several external researchers at Stanford, the
École polytechnique fédérale de Lausanne, and the Leibniz
Institute for the Social Sciences.
Jimmy
You seem anxious to deflect my question by making an unfounded accusation
of distortion. The plain meaning of the posting I quoted was that Board
members had no more time to devote to engagement with community members
than they were currently allocating, and you clearly have read the entire
thread that made it clear that that particular venue was faling at its
avowed purpose of bringing Board and community together, apparently for the
very reason of lack of time. That seems to me entirely relevant to the
topic under discussion, in which you stated that "it is possible and
welcomed to bring forward issues to board members at any time", which has
not always been my experience in the past. Your knee-jerk antagonism does
not help.
"Rogol"
This announcement was sent out on the 12th, and refers to a meeting on the
13th which would have been just enough time, I suppose, to raise a point
directly with a Board member before the meeting. However, the web page
referred to,
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_board_agenda_2016-11
states that the meeting was on the 11-12th, in other words, before the
announcement was made. So, when exactly was this meeting? And would it
not be helpful to the community to give enough notice to allow for a
resonable probability of bringing forward an issue?
"Rogol"
Thank you, Stephen.
On Nov 12, 2016 6:37 PM, "Stephen LaPorte" <slaporte(a)wikimedia.org> wrote:
> Hi all,
>
> The agenda for the next Wikimedia Foundation Board of Trustees meeting is
> now available on Meta Wiki: https://meta.wikimedia.
> org/wiki/Wikimedia_Foundation_board_agenda_2016-11
>
> Thank you,
> Stephen
>
> --
> Stephen LaPorte
> Senior Legal Counsel
> Wikimedia Foundation
>
> *NOTICE: As an attorney for the Wikimedia Foundation, for legal and
> ethical reasons, I cannot give legal advice to, or serve as a lawyer for,
> community members, volunteers, or staff members in their personal capacity.
> For more on what this means, please see our legal disclaimer
> <https://meta.wikimedia.org/wiki/Wikimedia_Legal_Disclaimer>.*
>
> _______________________________________________
> Please note: all replies sent to this mailing list will be immediately
> directed to Wikimedia-l, the public mailing list of the Wikimedia
> community. For more information about Wikimedia-l:
> https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
> _______________________________________________
> WikimediaAnnounce-l mailing list
> WikimediaAnnounce-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikimediaannounce-l
>
>
Dario Taraborelli wrote, in reply to my question:
>>...
>> Is there any legitimate research or any other need to save IP
>> addresses associated with HTTP GET web logs to disk prior to
>> creating a secure hash of them?
>
> these are considerations that the analytics / ops team are best suited to
> answer, I encourage you to relay them to analytics-l if you want to have a
> more technical discussion.
I asked there, and there have been two detailed answers:
https://lists.wikimedia.org/pipermail/analytics/2016-November/005506.htmlhttps://lists.wikimedia.org/pipermail/analytics/2016-November/005508.html
Since the analytics team considers the justification for storing
personally identifying information such as IP address, proxy
information, and geolocation (which we apparently perform on every
reader request) to be based on the needs of Research and Ops, I would
like to ask two further questions in light of this recent news
article:
https://www.washingtonpost.com/news/the-switch/wp/2016/10/11/facebook-twitt…
1. What are the advantages and disadvantages of storing each reader
request's geolocation?
2. Has Ops ever actually used reader GET request IP addresses to solve
a problem which could not have been solved, for example, with POST
requests for debugging?
3. If a research partner with access to the raw IP addresses, proxy
information, and geolocation of our readers' requests were served with
a subpoena by a US or overseas law enforcement organization, a
national security letter, or were blackmailed or bribed, would the
Foundation have any way to know?
I repeat my request that the IP and proxy information be anonymized
with a secure cryptographic has before being stored to nonvolatile
media, and suggest that storing the geolocation of every reader
request is not within the letter or the spirit of the Foundation's
privacy policy, which explicitly requires consent for the use of
geolocation:
"Some features we offer work better if we know what area you are in.
But it's completely up to you whether or not you want us to use
geolocation tools to make some features available to you. If you
consent, we can use GPS (and other technologies commonly used to
determine location) to show you more relevant content."
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1450006 may be
helpful for understanding my motivations about this issue.