Xover, ACN, and others,
I’m sorry for my slow response – much of the WMCS staff was off for some
of this week.
In 2016 there was an initial public consultation about new terms of
use[0]. The fact that we only now have a document to show for it should
give you an idea of how difficult this process is.
I would definitely prefer to have further community review and
discussion, but we simply aren't resourced for that. To commit to
another round of community review would mean setting this long-needed
update aside for more additional years. As I hate to let the perfect be
the enemy of the good, I've elected to do what's possible rather than
hold out for a process that I do not believe to be possible with current
resourcing.
We may be able to make minor adjustments in wording to the document, but
I remain convinced that this document is an improvement over the
previous version (among other things, because it has buy-in from legal
which the former document lacked).
That said, I do not mean to entirely stifle discussion on this topic. We
need to keep our expectations as low as possible, but I nevertheless
encourage those with concerns to comment on the respective talk pages so
that we have a record for if/when we have the resources to revise the
document.
-Andrew
[0]
I agree with ACN's points, especially the lack of
community review and
discussion.
For example, in section 4.1 on prohibited uses it refers to "Do not
break the law", but fails to specify which law, so as written it
applies to all laws anywhere enacted by a competent legislative body.
Congratulations: it's now a breach of the WMCS ToS to criticise
repressive regimes, comparing heads of state to literary figures, and
any number of things the suppression of which is in contravention of
the movement values.
Section 6.2 says "if WMCS administrators fail to reach you within six
(6) weeks". That's a pretty onerous time limit for volunteers. Being
busy IRL, or in hospital, or… for six weeks is not uncommon and in no
way indicates a stable tool is abandoned. Needing to take emergency
measures more quickly (like shutting down the VMs) for security issues
or the like is an orthogonal concern.
7.2 says Toolforge projects (but not other projects for some reason)
must "Use any user agent information … only for the maintenance of
your Toolforge Project". Maintenance of the project does not include
content negotiation, progressive enhancement, and other functional
aspects. Depending on what definition you apply to "user agent
information" (since "user agent" is not defined anywhere) this could
include authentication headers for e.g. Basic auth, or just the HTTP
User-Agent header field, or any information about the user agent (like
screen resolution, technical capabilities, supported content types or
javascript features).
Section 7.3.1 requires all projects that collect personal information
to post a privacy policy (and other things). Since section 2
(definitions) defines "user agent" to be personal information
equivalent to your password, social security number, real name, and
bank account number and information about the user agent is provided
to all projects by the anonymising proxy, all projects are by
definition collecting personal information. All projects with a web
interface are thus required to post a full privacy policy. The
definition of "End User" does not exclude the developer / project
admin, so all projects without a web interface are also required to
post a full privacy policy. If all projects are actually required to
post a privacy policy it would be much much simpler to have the policy
just say "All projects must post a privacy policy".
There is no definition of "collecting" so what technical operations
actually constitute "collecting personal information" is unclear.
There is no definition of "user agent" so it is unclear whether it is
intended to encompass all information provided by the user's User
Agent (i.e. web browser), all information _about_ the user's User
Agent, or just the content of the User-Agent HTTP header. This also
makes the term "user agent information" ambiguous. (Also, please
please explain to WMF Legal that the HTTP User-Agent header isn't PII
by any reasonable definition. I've tried and failed miserably. This is
more-catholic-than-the-pope privacy IMO, and I work with the GDPR in
my day job).
Deferring a central part of such a policy to a second policy (x-site
policy) that does not yet exist and is explicitly still subject to
change is akin to writing blank checks or signing a blank contract. It
is also quite possibly grounds for invalidating the whole policy as
obviously unreasonable in contract law terms.
All these things are, from my perspective, fairly problematic, and
most of them probably pretty fixable if the community was consulted.
That some of them may possibly be harder to fix is not really a good
reason to not at least discuss them.
Cheers,
Xover
On Sat, May 27, 2023 at 5:29 AM AntiCompositeNumber
<anticompositenumber(a)gmail.com> wrote:
I am disappointed that these Terms went into effect immediately,
without any chance for review or comment by the community. This is
counter to how Wikimedia processes should run, and flies in the face
of the values of the Wikimedia movement.
I am concerned about some of the provisions of these Terms. For
example, 7.3 bullet 3 states
Not collect any other Personal Information and
Wikimedia
Usernames from End Users, other than any user agent information
forwarded by the anonymizing reverse proxy or OAuth provided
usernames and email addresses.
One of my tools,
signatures.toolforge.org
<http://signatures.toolforge.org>, provides data on a user's
signature from their username. The queried username is included in the
path, and is logged by the default uwsgi logging configuration. It is
likely that at least some End Users will check their own usernames, so
therefore the tool is collecting Wikimedia Usernames from End Users.
This *shouldn't* be a violation of the Terms, but by a plain reading
of them, it is.
I am also concerned that
https://wikitech.wikimedia.org/wiki/Wikitech:Cloud_Services_Terms_of_use#5.…
makes reference to a non-existent policy and refers to itself with a
different title.
I am also disappointed that the revised Terms still require tools to
be under an OSI-compliant license, without permitting the use of CC-0
or public domain grants. The requirement to request and be granted an
exemption to run one-off scripts without releasing them also seems too
arduous to be useful. Either free licenses should be required for
everything, or the approval requirement should be dropped.
The warning at the top should also make clear that developer email
addresses are public to the Internet, not merely to other WMCS users
(for example, at <https://ldap.toolforge.org/user/anticomposite>).
The overall layout of the Terms is also confusing, with very short
sections referring to other very short sections on the other side of
the document.
AntiCompositeNumber
(he/him)
On Fri, May 26, 2023 at 9:46 AM Andrew Bogott
<abogott(a)wikimedia.org> wrote:
After nearly a decade of mishap and delay, we have updated the WMCS
terms of use. The updated document for toolforge and cloud-vps
admins
can be found here:
https://wikitech.wikimedia.org/wiki/Wikitech:Cloud_Services_Terms_of_use
and the terms of use for visitors to WMCS sites can be found here:
https://wikitech.wikimedia.org/wiki/Wikitech:Cloud_Services_End_User_Terms_…
There is one significant change in these terms: Cloud-vps
projects which
collect personal data will need to include an
explicit privacy
policy
for their projects. This is section 7.3. For
other WMCS users
and admins
these documents do not represent any significant
change in
policy, but
do clarify and finalize many things that were
poorly-worded in the
previous TOU, or policies that we have enforced informally without
officially stating.
Please feel free to reach out to WMCS staff if you find any part of
these documents concerning or disruptive to your work on our
platforms.
-Andrew
_______________________________________________
Cloud-announce mailing list -- cloud-announce(a)lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/cloud-announce.lists.wikimedia.…
_______________________________________________
Cloud mailing list -- cloud(a)lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
_______________________________________________
Cloud mailing list -- cloud(a)lists.wikimedia.org
List information:
https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
_______________________________________________
Cloud mailing list --cloud(a)lists.wikimedia.org
List
information:https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimed…