WordPress contributors from around the world joined in a lively meeting yesterday to continue the discussion regarding the proposal to auto-update old sites to version 4.7 in a controlled rollout. The idea is that sites would gradually update from one major version to the next (not all at once). The discussion was led by WordPress 3.7 release lead Andrew Nacin with help from Ian Dunn and security team lead Jake Spurlock.
Based on the participants’ responses during the meeting, there were a handful of dissenters who are not comfortable with updating old sites without the site owner’s explicit consent, which is difficult to acquire when emails and admin notices will not reach everyone affected.
The majority of contributors are leaning towards finding the best implementation for moving forward with the proposal, which essentially makes a bold decision for regular users who may not know that they are not on the latest version of WordPress and those who have abandoned their sites. Site owners who are actively choosing to hang back on older versions have most likely already opted out of auto-updates, and those decisions will be respected by the update system.
Dunn said his goal for the discussion was to “listen for ideas, and hopefully move closer to some kind of decision.” At the beginning, it kicked off with more of a focus on marketing and implementation details, rather than the matter of whether or not WordPress should auto-update sites to major versions.
“I think that a major marketing push is needed around this,” Spurlock said. “We want to be ahead of any news about WordPress breaking sites, and in a position to frame this update as a major benefit for the millions of sites that are being updated.” After encouragement from WordPress Executive Director Josepha Haden, those eager to discuss the rollout process pulled back to engage the more central matter of the auto updates themselves. Spurlock summarized the three options the security team has for older sites:
1. Abandon security updates for older sites
2. Continue security updates, at great cost
3. Manually update sites, leaving older sites without updates.
“It’s worth pointing out that these site owners have already had up to six years of admin notices,” Nacin said. “The oldest sites likely received north of 30 emails. The way we might communicate a new feature (in say 5.3 or 5.4) to add support for major release auto updates might be drastically different than how we might handle an old site running 3.7 that we’d like to move to 3.8 and higher.”
Contributors Weigh the Consequences of Leaving Older Sites Without Updates
Core contributor Zebulan Stanphill was one of the more vocal opponents of auto-updating to major versions without consent.
“The auto-update feature in 3.7 was not advertised as including major updates, so it seems deceptive in my opinion to suddenly change it to include that,” Stanphill said. “It feels like assuming more control over a website than the owner had originally given to WordPress. I’m fine with auto-major-updates becoming the default in new versions of WordPress, but retroactively applying that to old versions seems wrong to me.”
Gary Pendergast, a full-time sponsored contributor to core, countered that the problem is potentially millions of site owners will not see the notice and will be stuck on old versions that will eventually become insecure. Stanphill argued that it’s not WordPress’ responsibility to update people’s sites for them if they did not give permission.
“It is our responsibility to not lay the groundwork for a botnet of a sizeable portion of the internet,” Pendergast said.
WordPress has a much larger footprint on the web than it did in 2013 when the auto-update system was put in place in 3.7. The platform’s marketshare has grown to 34.5% of the the top 10 million websites as of August 2019. Sites running 3.7 have been informally estimated at around 2 million but a definitive count has not been confirmed.
“If we unwittingly give someone a platform to do real evil, we’re big enough that could have consequences,” Core contributor Mary Baum said.
Lack of explicit consent and the possibility for breakage were the top two concerns for those opposed to the plan. Those in favor believe it can be done without breaking millions of websites. Former security team lead Aaron Campbell highlighted the advantages of a tiered update rollout:
Speaking of starting at 3.7 users as a test base (which is part of the plan Ian proposed), one of the great things we can offer users that they have a hard time doing themselves, is a slow update from version to version. The button in the dashboard of a 3.7 site will update the site to 5.2, which is understandably scary. We’d be updating 3.7->3.8, then 3.8->3.9, etc etc until 4.6->4.7. It’ll offer a smoother path from 3.7 to 4.7 AND give us plenty of places to improve on the process along the way if it’s needed.
I think there are some benefits to rolling up. One of those is the DB changes, which would be rolled out in chunks the same as they happened over the last 6 years rather than batched all in one update. It seems like it would cause fewer memory and time limit errors as well.
As he has stated in previous P2 discussions, Nacin reiterated that the core team’s plan has always been to bring auto updates for major versions:
I want to share a bit of history and context: Only the latest version of WordPress is, of course, officially supported. Automatic background updates in 3.7 (October 2013) completely changed the calculus—for the first time, we were able to ship security releases to older branches. But we didn’t announce or document these older versions, offer them for regular download, or expose them to the Dashboard → Updates screen. There was no intention—and still isn’t—to change our often stated policy that only the latest version of WordPress is officially supported. What we realized, though, if we are building the ability to quickly push security fixes to older unsupported sites, we’d be out of our mind to not use that feature.
We expected to make quicker progress on automatic updates for major releases, improving the safety and resiliency of those updates. That would have then enabled us to update these older sites, all the way back to 3.7, to more recent versions of WordPress. That was always the plan. We just didn’t expect it’d take us six years to get there.
Eventually, the long term goal is to change the default for major updates to “opt-out,” once they have proven stability. The proposal for auto-updating older versions to 4.7 would be the next step towards gradually moving in that direction. Nacin contends older sites “are already opted-in by virtue of being on an install of WordPress 3.7+.”
At a certain point in the meeting, the discussion surrounding the ethics of auto-updating older sites to 4.7, broke down into analogies involving car maintenance, vaccinations, rotting corpses, and anything contributors could pull from the real world to make their opinions more relatable to the topic at hand.
“It’s hard to talk about ‘autonomy’ for sites that have effectively been abandoned,” Mark Jaquith said. “Like, if you drop dead on the street, society doesn’t just let you rot there because you haven’t consented to burial.”
Core contributor John James Jacoby said he is not entirely comfortable with the implied consent of opt-out vs. opt-in but ultimately agreed that it is “something that needs to happen.”
“But to paraphrase Mark from earlier, I guess I feel like WordPress shouldn’t be cleaning it’s own carcasses from the web unless it includes a big’ol meta-box in the Dashboard that says ‘Hey we had to do this for you and here is why,’” Jacoby said.
Others are more strongly opposed to WordPress changing files on users’ servers, after having originally communicated that 3.7 would only perform automatic security updates unless they decided to opt into major updates.
“I am very much against pushing an unattended major update to any software,” Gabor Javorszky said. “WordPress Core does not have the authority to change code on my server without my explicit ask. I’m okay with it updating itself for minor versions, because that’s what I signed up for, and that’s how the current auto updater works by default. I can change it to allow major updates, and I can change it to not allow any updates at all, but WP overriding that choice is wrong.”
Michael Panaga contended that users would be more willing to understand that their old websites have been hacked, rather than find out that their sites have broken because of an unauthorized automatic update. Opponents of the proposal do not believe that it is WordPress’ responsibility to keep people’s sites from being compromised, even if millions of sites get hacked. They see this as the user’s problem or something hosting companies should handle.
“Reasonable people can and will disagree on this, but our philosophy is that we do not think it is solely the user’s responsibility if their site is hacked,” Nacin said. “We feel that responsibility too, and we’re going to do absolutely everything we can to make sure their site stays updated and they are running the latest and greatest version of WordPress.”
No official decision has been announced but those who have the power to implement the plan are firmly decided and seem to have gained a consensus through yesterday’s meeting.
“At the end of the day there’s only a few people who have the ability to push the change to the auto-update server to make this opt-out instead of opt-in and sounds like their minds are made up, so no point in continuing P2 [discussions], might as well move into the implementation phase and try to minimize the destruction,” WordPress developer Earle Davies said.
Nacin thanked contributors for lending their voices to the discussion and said there will be some follow-up posts and possibly a roadmap published to make/core in the coming days, documenting previous decisions back to 2007.
“I’m really glad you all showed up to talk about this topic,” Nacin said. “Even after 10 years, I remain deeply impressed with the WordPress community and how much it cares about its users. The web deserves it.”
Original: wptavern.com
