About that WordPress autoupdates thing.


Estimated reading time: 5 minutes
Musings

There was a call for comments ahead of this weekend’s scheduled panel discussion at WCUS on the autoupdates plan. I’ve been asked to respond to it from my perspective, so I will.

My concerns about the plan remain unchanged from what I said in comments on the first Make post, the second Make post, and the second Tavern article.

What’s the problem?

The autoupdates plan, as it has been described, and by my read, is incompatible with the latest draft of the EU’s ePrivacy Regulation, which is due to be finalised and come into force next year.

“Incompatible with” is diplomat-speak for “completely freaking illegal”.

While my expertise – for sanity’s sake – is in European and UK law, there is a strong case to be made for the proposal to be in violation of various local and national U.S. regulations on computer trespass and systems misuse. There will be many people in attendance at WCUS, including Rian Kinney, who will be able to speak to that.

A privacy impact assessment documentation process would have identified these issues, privately and before they entered the realm of public controversy, but introducing a PIA process into project development was literally laughed down last year when the core-privacy team tried to raise it.

What does the draft say?

Click here for legalese!

The latest draft of the ePrivacy Regulation (8 November compromise text, recital 21a) states (emphasis mine):

Consent should not be necessary either when the purpose of using the processing storage capabilities of terminal equipment is to fix security vulnerablities and other security bugs, provided that such updates do not in any way change the functionality of the hardware or software or the privacy settings chosen by the end-user and the end-user has the possibility to postpone or turn off the automatic installation of such updates. Software updates that do not exclusively have a security purpose, for example those intended to add new features to an application or improve its performance, should not fall under this exception.

Article 8 codifies that without consent, system access is permitted if

(e) it is necessary for a software update provided that:
(i) such updates are necessary for security reasons and does not in any way change the privacy settings chosen by the end-user,
(ii) the end-user is informed in advance each time an update is being installed, and
(iii) the end-user is given the possibility to postpone or turn off the automatic installation of these updates;

That leaves two options for the project:

  1. The autoupdates plan can work within those future legal constraints, or
  2. The autoupdates plan can be in violation of them.

Can we get some clarification on this?

Through my day job, I do have the contacts in the EC team in Brussels behind the draft Regulation. In a healthy project situation I would be able to contact them to open a dialogue on whether the autoupdates plan will, in fact, violate the eventual Regulation.

But this is not a healthy project situation, so I can’t, and I won’t. There are two reasons for that.

The first reason is that I have not been granted the authority, and I do not hold a mandate, from the WordPress community, to act on its behalf in the policy sphere. Seeking clarification from Brussels isn’t like pinging someone a quick question in Slack. There are protocols you must follow first to earn your right to ask. It might take a few months to get a response back, and they’re probably going to want an in-person meeting. By definition, I would be bringing them a problem, not a solution, and they would prioritise the work as such. I am not funded or supported to contribute to WordPress for the privacy work I already do; I have no emotional or financial interest in expanding that to negotiating with policymakers as a charitable endeavour.

The second reason is that even if I had a mandate from the community and some sponsorship to spend my time on it, I would not be allowed to do so. The project leadership is very touchy about anything perceived as political. That’s not just a function of tech bro libertarianism. That is a function of the WP Foundation’s American 501(c)(3) legal registration forbidding any activity which could be construed as political lobbying. That, as ridiculous as it sounds, would include a Scottish woman speaking to Brussels on the project’s behalf.

Neither of those governance issues are, nor should they be, my problems to solve.

What I can do is point out how this plan risks a lot more than botched updates.

Please don’t ruin it for everyone else

I get it. I really do. The WordPress open source project is not interested in making its voice heard and influencing policy, or leveraging the power of 30% of the sites on the open web to being a force for good. It’s not interested in working within policy processes. It’s not interested in building relationships with policymakers. It’s a software project, and nothing more. That has been made crystal clear to me by the project leadership. I get that.

What I don’t get is where the WordPress project decided it has the right to ruin it for everyone else.

The project – whoever “the project” is – has made a political decision here: that’s to push ahead with a plan which is likely to put end users in violation of the law, and to do so knowing that the mantras of open source development will be used to ensure that no one within the project will be held responsible and no decision makers will be held accountable.

None of that will fly with policymakers for a minute. They’re going to want to know who made those decisions. They are going to want to know who approved them. They are going to want to know who wrote the code. They’re going to want to see the legal sign-off. They’re going to want to see the PIA.

And they’ll find two Make blog posts with hundreds of comments, two Tavern articles, this blog post, and some airy hand-waving about “open source freedoms” instead.

So if you want to set up open source development ecosystems as a whole for heavy-handed regulation and hostile scrutiny from policymakers looking for easy prey to take down, going ahead with the autoupgrades plan is a quick and easy way to do it.

Think very carefully about what you’re doing here.

Did you spot what’s missing?

Finally, on to the WCUS panel itself. The description for the panel uses words like responsibility, freedoms, and safety. The actual problem – legal – is not mentioned at all. Does this sound familiar? It should, if you follow my work. Framing the dialogue as a debate about rights and wrongs, rather than a mission-critical evaluation of the legal implications, is ethics washing.

If you need an introduction to ethics washing, Morten and I recently wrote a print article about it. We’re not permitted to redistribute it online, but we defined ethics washing as

What happens with ethics projects are devised and adopted in lieu of a healthy approach to legal compliance. These codes are rarely deployed to complement privacy laws and the rights they grant users; instead, they are often used to circumvent them.

We warned against ethics washing as a means of

Signall[ing] a belief in self-regulation, using arbitrary ethics as the constraint, rather than an adherence to an actual regulation using the rule of law as the constraint. Put another way, it is a declaration that a project, and the people who make it, are above the law.

I don’t want this panel to form part of an evidence trail – along with those Make posts and Tavern pieces – showing that the project thought it was. But until I see or hear differently, I’m looking at a project which is holding itself above the law while looking down at those who work to make it.

You have one shot to change that, and that’s the panel discussion.

So my advice to those of you participating in or attending the panel would be to leave the ethics washing at the door. Drag the l-word onto the stage, and address it face-first and head-on. Don’t leave the stage until you have a plan to solve it. Be as fearless as, well, I would be.

Because open source is counting on it.


The Author

I’m a UK tech policy wonk based in Glasgow. I work for an open web built around international standards of human rights, privacy, accessibility, and freedom of expression. The content and opinions on this site are mine alone and do not reflect the opinions of any current or previous team.

2 Comments

  1. Nice write up about this mess from a legal perspective. I’m curious about 2 things:

    1. “…introducing a PIA process into project development was literally laughed down last year when the core-privacy team tried to raise it.”

    Was it someone specific or a group of people at the top?

    2. “They’re going to want to know who made those decisions.”

    If someone decides to crack down on WordPress, be it GDPR or ePrivacy or some other regulation/law violation, with a formal investigation, they will be looking first at the person/group that declined to have PIA and second at our benevolent dictator Matt. He might not be legally responsible for WordPress, but he does have *almost* sole authority over what happens to open source WordPress. He’s also the reason, if I remember correctly, why the governance project didn’t take off as it should have. That would be enough to make him the guilty party and face the penalties on behalf of WordPress. Don’t you think?

    • On the first question, it was a specific individual. The second question is one I’m quite bored of, to be honest. I’m tired of the dialogue being about Matt. I want the dialogue to be about everyone else.

Comments are closed.