Ian Dunn 4:03 pm on August 16, 2019
Tags: auto-update ( 24 ), security ( 18 )

Follow-up Discussion on Major Auto Updates

Last week’s proposal to automatically upgrade old sites to 4.7 has garnered a lot of feedback, which has been very helpful in refining the idea and getting a sense of how different parts of the community feel about it.

To follow up on that, I’d like to have a meeting in #core on Tuesday, August 20, 2019, 2100 UTC to continue the discussion. No decisions will be made during the meeting, but I hope that we can have a productive conversation and move closer to some kind of resolution.

To join the meeting, you’ll need an account on the Making WordPress Slack. If you’re not able to attend, but would like to give feedback, please leave a comment on the proposal.

#auto-update, #security

Steve Ryan 4:45 pm on August 16, 2019

I’m going to quote from my own response to the earlier post.

…the combination of a SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. discussion and blogblog (versus network, site) post in a very “technical” space is not enough of a substitute for a process which is inclusive of all represented stakeholders of this project.

Before we go here – and I truly hope that we CAN go here – we need to seek permission. That means buying into the model proposed by the WordPress Governance Project (https://wpgovernance.com) and really engaging with communities and people which represent the journey groups outlined within.

That said, we’re happy to meet you wherever is convenient to continue the conversation.
Rachel Cherry 4:51 pm on August 16, 2019

Ian, thank you for your continued efforts.

Ultimately, these discussions are a great example of the impact (the lack of) governance can have on a project this size.

Right now, our governance seems like all you have to do to propose a policy and plan is to have access to the Make blogblog (versus network, site). But then what?

WordPress needs clear processes for proposing policies and making decisions that affect such a large percentage of the web.
Paul Gilzow 4:56 pm on August 16, 2019

For those of us who are unable to make the slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. meeting, will the conversation be archived and made publicly available?
- Aaron D. Campbell 5:50 pm on August 16, 2019
  
  All discussions in public channels on the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. are logged and can be read through later.
  - Paul Gilzow 5:52 pm on August 16, 2019
    
    +1. Thank you for the clarification. As a suggestion/request, can a link to that archive be posted on this post and on the original?
    - Aaron D. Campbell 6:29 pm on August 16, 2019
      
      I think that’s a good suggestion. I’ll try to remember to bring it up at the meeting to make sure it gets done.
    - Ian Dunn 10:23 pm on August 20, 2019
      
      Here’s the log of the meeting:
      
      https://wordpress.slack.com/archives/C02RQBWTW/p1566334886210300
      - Paul Gilzow 5:32 pm on August 21, 2019
        
        Can you please post the contents of the archive in a space that does not require you to log into SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. for those who are not in slack? I am in slack, but there are many who are not.
  - Ipstenu (Mika Epstein) 6:44 pm on August 16, 2019
    
    Someone should post a summary after, though. SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. Logs (logs of any kind) aren’t generally newbie friendly.
    - emaildano 6:12 pm on August 22, 2019
      
      Also, they get archived/removed after 10k messages if you’re on their free tier. Eventually they’ll be gone unless they’re syndicated elsewhere.
      - Ian Dunn 6:14 pm on August 22, 2019
        
        We’re not on the free tier.
        
        emaildano 4:45 pm on August 23, 2019
        
        🙌🏻
    - Paul Gilzow 5:48 pm on August 23, 2019
      
      I’ll second Ipstenu: The logs aren’t newbie friendly, and they’re currently only available if you log into slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., effectively locking them away from the general public.
Morten Rand-Hendriksen 5:12 pm on August 16, 2019
Cross-comment from the original post, which is equally relevant here:

Point of order: There are some unclarities here about various things that need to be made clear including:
- Where (in what public forum/space) will a decision be made?
- When will that decision be made?
- How will the community be informed about the above?
- Who has … voting power(?) … when the decision is made?
- How will the opinions of people without such power be adequately represented?
- In the case of a tie or significant split in the community, how will such disagreements be resolved?
- By what mechanism will the final decision be made?
- And by whom?
- Who holds responsibility for the final decision (aka where does the “buck” stop)?
- Andrew Nacin 9:28 pm on August 16, 2019
  
  These are fair questions. Currently the goal is to collect as much feedback as possible. I’ve seen some really helpful feedback in the comment threads. Generally, the most useful questions or pieces of feedback seem to recognize a few key points, such as:
  
  1. Auto updates exist today.
  2. Auto updates have existed in WordPress since 2013.
  3. Auto updates are going to exist tomorrow.
  
  I think there have been some excellent comments about communication, consent, site breakage, supported versions/EOL, etc. On the other hand, I’ve already heard just about every argument against the very existence of automatic updates—I was here in 2013 :)—and that feedback is not as useful now. Auto updates are here to stay, and they’ve only gotten more prevalent, both in the WordPress world and out.
  
  The best WordPress decisions are grounded in a set of philosophies and values. For example: great software should work with little configuration and setup, we design for the majority of our users, and we strive to make WordPress easier to use with every release. These were some of the same foundational reasons why auto updates were brought to WordPress originally, and they still hold true today.
  
  So given that, to attempt to answer your questions:
  
  I’d guess a decision would be made sometime in the coming weeks, when the existing proposals and ideas have improved and gelled based on feedback. There will surely be additional conversations in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. and additional posts to this blogblog (versus network, site). Once there is a plan decided upon and put in motion, I’d expect a blog post on the main WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ blog.
  
  As for who makes the decision, as the WordPress 3.7 release leadRelease Lead The community member ultimately responsible for the Release., I think I technically still have standing here, six years later. 🙃
  
  CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers will make the decision, in consultation with the security team, Josepha, Matt, and other teams (especially the support, documentation, and hosting teams). The best way for other people to have their opinions heard and represented in this process is to voice them, either here or on their own blog. Reasonable feedback will always be considered and proposed courses of action can always be adjusted.
elrae 5:13 pm on August 16, 2019

I see no reason this must be opt-out and not opt-in. From what I can discern, the overarching logic here is that call outs in the adminadmin (and super admin), emails, and notifications will be sufficient warning for administrators who care to opt-out. By that same logic, the same notifications should be sufficient to encourage people to OPT-IN if they so choose. I would also love to see the answers to Morten’s questions above, all of those are 100% spot on of what the community deserves.
- Ian Dunn 8:45 pm on August 16, 2019
  
  I don’t think that’s an accurate description of the logic behind the proposal. They’ll likely be a significant portion of site owners who won’t see the warnings, no matter how hard we try.
  
  There’s nothing we can do about that though, so the question becomes, what’s the best way to address that subset of sites, many of which are likely abandoned? Do we let them get hackedhacked and then damage the rest of the Internet, in order to respect their rights; or do we break some of them in order to keep them all secure?
  
  Either way, there are no simple answers. No matter what we do, a significant amount of people will be harmed, and that’s out of our control. The question we’re faced with is, which set of tradeoffs is better?
  - elrae 9:05 pm on August 16, 2019
    
    Simple – yes, we do let them get hackedhacked . WordPress responsibility isn’t to be the security blanket of the internet. You’ll never keep every site secure no matter what. As stated time and time again before, the main security vulnerability point is plugins. If someone’s coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. WP is out of date, there’s a 99.99% chance their plugins are out of date too. If WordPress doesn’t force update one day 1, nothing will be harmed. If they do, something definitely WILL be harmed. All of that IS within our control. The tradeoff is intentionally harming people’s sites for the benefit of MAYBE protecting some sites down the road. In one scenario the harm caused to the site is 100% WordPress’s fault. In the other scenario the harm caused is 100% the site owners fault. Let me state this again: we will intentionally harm people’s sites, and that’s 100% the fault of whoever makes that decision within WordPress. If someone’s site gets hacked because they are out of date, it’s 100% the fault of the site owner. This is a no-brainer choice, we must set it to opt-in.
    - Andrew Nacin 9:34 pm on August 16, 2019
      
      This is a pretty eloquent argument for automatic pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party updates. 😬
      
      I actually don’t think it’s 100% the site owner’s fault for running a piece of software that is out of date and insecure. It was the WordPress community that provided them that software, vulnerability and all, and it was the WordPress community that made it exceptionally easy for them to install it and maintain it and run it all on their own, so easy that they were no longer conditioned to pushing the “Update Now” button.
      - apedog 3:05 pm on August 17, 2019
        
        All else being equal, opt-in is the morally correct choice.
        
        Andrew Nacin 5:14 pm on August 17, 2019
        
        Are you saying that minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. auto updates also needed to be opt-in? I think one reason this is so challenging is either can be defended as the “morally correct” choice. At the end of the day, we already made a choice when we released 3.7 and we’re very comfortable with that choice.
        
        Jon Brown 2:15 pm on August 18, 2019
        
        Site owners opted in to minor updates by updating to 3.7 and not disabling minor auto-updates. That was an action taken by them.
        
        I think most are fine with a future version of s moving to auto-update across major version. Again, with the ability to disable auto-updates.
        
        I think many, like me, however object to changing the behavior of how old versions operate without affirmative consent (some opt-in action) being taken.
        
        I think the ethical answer to this is obvious
        
        Do we let them get hackedhacked and then damage the rest of the Internet, in order to respect their rights; or do we break some of them in order to keep them all secure?
        
        You respect their rights.
      - Doug Cone 12:24 pm on August 19, 2019
        
        Would you also suggest that we remove plugins that don’t have updates and do contain vulnerabilities? What about plugins where someone chooses not to purchase a version that contains a security fix?
Jon Brown 6:06 pm on August 16, 2019
Again… “auto-updating” being a safe process is not an excuse for unexpectedly updating peoples sites and changing the terms laid out.

Silence is not consent.

Those site owners consented to auto-updates within a major version. If you’re going to change that behavior you should get affirmative consent from them to do so.

How do you do that?

Simple, instead of emailing them to warn them that their sites will be auto-updated regardless. You email them to warn them their sites will no longer receive auto-updates _unless_ they”
- manually update to a current version, or
- opt-in to some other more aggressive update scheme (auto-updates between major versions).
I fully support stopping back-porting of security updates for umpteen versions of WP. WordPress should have included a process for notifying site owners when support for a version ended. Simply add that now, and stop playing nanny state.
- Andrew Nacin 10:56 pm on August 16, 2019
  
  These sites are already running a version of WordPress that automatically applies updates as they are released. I think the genie is out of the bottle on that one. We’re just thinking about releasing one such update that takes their probably otherwise unmaintained site from 3.7.29 to 3.8.30. (This would affect only a few thousand sites.)
  - pepe 10:01 am on August 17, 2019
    
    Consent for minor releases (by updating to 3.7 and not disabling the default) is not consent for major updates, especially since non-technical users have no way of easily changing those auto-update settings.
    
    Changing the default for future releases is fine, BTW, just not retroactively.
  - apedog 3:57 pm on August 17, 2019
    
    Your comment makes it quite clear that the genie is NOT out of the bottle. Not by a long shot.
    minor/major version updates != patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. updates.
    This is not only a technical distinction (breaking changes etc.) but a conceptual one as well:
    ie. a user might never want to update to gutty blocks (WP 5+) under any circumstances. Not now, and not in 10 years. Auto-updates (eventual eradication of older versions) signals that a site-maintainer cannot confidently rely on any feature currently available to her.
    
    Also, if the auto-updates are made opt-in by policy, this entire discussion becomes moot. Legally, morally, conceptually. Opt-in removes the dilemma from the wp-developers/governance and leaves it in the hands of the site maintainers. Opt-in caters to both ideological points of view (overall security for the price of a thousand sites breaking vs. individual choice and personal control of installed code).
    - Andrew Nacin 5:19 pm on August 17, 2019
      
      Conceptually, a user who doesn’t want blocks should be installing the Classic Editor pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party,not avoid updating WordPress. (If we got to the point where we wanted to update ancient 4.9 sites to 5.0, then yeah, we could potentially install the Classic Editor plugin as part of the upgrade. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ isn’t an argument to not do this.)
      
      Opt-in also means that this will benefit close to zero existing sites running older versions of WordPress. It’s a convenient answer, but it’s also a cop-out and it’s not something many of us are comfortable with.
      - apedog 7:35 pm on August 17, 2019
        
        I gave the blocks as an example. It could be any other feature. I myself know exactly how to disable blocks if I so wished (by installing a specific pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party). Gutty blocks is not point, and it’s frankly baffling that you would read my comment that way.
        
        Opt-in means that someone who installed a site and has had no reason to maintain/upgrade/change it (or to think it will break some day in the future through no act of her own) can do so.
        
        The fact that MANY (emphasis on NOT ALL) of you would be uncomfortable with opt-in, is exactly the point! It means that a FEW (ie. SOME) are entirely uncomfortable with the opt-out choice.
        
        Opt-in, by definition, is the option that leaves the choice to whomever is effected by that choice. As opposed to moving that choice to some external governing body, which might or might not share that individual/organisation’s philosophy.
        
        Opt-out is the cop-out choice. The choice that wrests control from the site maintainer (or “non-maintainer” in this case), You’re basically saying all those non-maintained sites (supposedly abandoned, though they’re still being hosted) are yours (the wp governing body) to with as you will. And NOT under the control of whoever installed them and chose to leave them functioning exactly as they are today.
        
        Aaron Jorbin 12:06 am on August 18, 2019
        
        The WordPress Philosophies are fairly clearly against opt-in. It’s why there is such a robust pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party system.
        
        Leaving things the way they are isn’t sustainable. Backporting patches to over a dozen versions takes a considerable amount of effort and hurts the ability for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to evolve.
        
        pingram 4:18 am on August 20, 2019
        
        So what exactly can you do with this auto-update feature as it sits now from 3.7 onward?
        
        Are there abuse protections built into the code limiting power?
        
        What is the capability of the function in it’s entirety? Not what it is intended for but full scope of capability here.
        
        Can you rewrite an entire site from wp root to literally anything?
        
        If someone opts out using a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., can you still override that? Not would you, but could you?
        
        If someone opts out using a constant, can you still override that?
        
        How much % of the web do you (as an org) currently have this level of access to?
        
        Is this disclosed anywhere, is it easy to find and is there also instructions on how to remove this functionality if so desired?
        
        Ian Dunn 5:53 pm on August 20, 2019
        
        What is the capability of the function in it’s entirety? Not what it is intended for but full scope of capability here.
        
        Like any update mechanism for any software package, it has the same capabilities that the existing version of the software has. So, it could theoretically do something malicious, like delete your database or install malware; just like an update for Chrome or Ubuntu could do something similarly destructive.
        
        If you distrust the WordPress project that much, you could add a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party like this to prevent your existing version of WP from communicating with WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, which would make it impossible to install an update automatically:
        
        add_filter( 'pre_http_request', function( $preempt, $request, $url ) { if ( 'api.wordpress.org' === wp_parse_url( $url, PHP_URL_HOST ) ) { return new WP_Error( 'Access denied' ); } return $preempt; } );
        
        ( That’s untested, but should be pretty close )
        
        pingram 7:51 pm on August 20, 2019
        
        Thanks for the clarity Ian.
        
        Trusting the WordPress project 100% or 0% doesn’t change the capability of this feature, which is what I was after.
        
        It’s not always about trust, for me it’s about compliance, risk analysis and intimately knowing what I’m offering my clients.
        
        The answer you provided is what I was seeking. I’ll just refer to the code to further answer any remaining questions. Your example is helpful too. Not that I’ll ever need to do something like this but I’ll play around with it just in case I ever have to.
JNashHawkins 10:28 pm on August 16, 2019

My focus is on offline uses of WordPress, using WordPress to generate content for other services, and using WordPress as the backend of static websites.

I like having my sites up to date but I’m not real interested in auto-updates. I don’t want to find a site down or a mission-critical process missed due to an update crash or incompatibility issue.

One of the selling points of the static site concept is the fact the WordPress may run for years without a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. update and with way out of date plugins and themes.

The idea for some of this is WordPress isn’t vulnerable to attack if it’s not actually internet reachable. Yet we would need to concern ourselves with having a decent internet connection for updates we may never need.

I think it’s best to steer away from any auto-updates in favor of user-selectable updates when they are required by the desire to stay updated or to take advantage of new features and technology.

Limiting support to recent versions is fine. That’s easily dealt with.
- Andrew Nacin 10:49 pm on August 16, 2019
  
  Interesting use cases, @JNashHawkins! Thanks for commenting. If your site is configured in an offline manner, such that it can’t reach the internet, then it’s never going to get automatic updates anyway. You’re still going to need to do a manual update, just as before. Am I missing something? At the end of the day, if you’re not interested in automatic updates, that’s fine—it doesn’t sound like it fits your use case; namely, you understand what’s up. 🙂
  - JNashHawkins 11:17 pm on August 16, 2019
    
    I’m concerned about my clients running into issues though…
    
    I’m bragging on today’s WordPress capabilities but anything handed over to those clients would be subject to what they might do or add. A live connection to the web is possible for them to add purposely or inadvertently which then lets an update happen where or when the rest of the system won’t support it.
    
    And there are other use-cases I’m concerned about in the future. We live in wondrous times… I believe in that and plan accordingly.
Heather Burns 3:23 pm on August 17, 2019

I was not expecting to see the discussion referenced by a pre-eminent D.C. tech policy think tank.
https://twitter.com/CenDemTech/status/1162439884910428160?s=19

I’d therefore remind participants, whatever their opinion, that this discussion is being watched in policy and legislative circles, at a time when the regulation of open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. projects is absolutely on the table.
Jarret 9:26 pm on August 18, 2019

Reading some of the comments here along with the ones on the initial proposal it sounds like this is something that WILL happen no matter how many votes against it are cast based upon how those with the power to ultimately decide this are speaking. These “discussions” sound like they’ll just be used as an excuse when old sites are forced to update, then break and people wonder why their sites are no longer working are told…. “Well, we had plenty of discussions about it over the course of a few months and people were allowed to give their input!”

When in reality the vast majority of people that are using a site running WordPress have no clue about the Make blogs, SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. or that public input is even allowed in situations like this.

While we can’t be responsible for those not willing to log into their adminadmin (and super admin) area to check on notices, that issue ultimately falls upon the developer/host/etc that configured the install for them and didn’t stress the importance of keeping up to date on the software they are using.

I’d say, stick a notice in the admin area, make it say something like “Hey! We noticed you’re running an old version and we are thinking about forcing an update to it to help strengthen security that has a chance of breaking your site and causing it to no longer work. If you have any input about this process, please visit {link to proposal here} to discuss further.”

No sugar coating BS in the message, just cut straight to the point and let them decide how they want to respond.
- modus 8:58 pm on August 19, 2019
  
  Reading some of the comments here along with the ones on the initial proposal it sounds like this is something that WILL happen no matter how many votes against it are cast based upon how those with the power to ultimately decide this are speaking. These “discussions” sound like they’ll just be used as an excuse when old sites are forced to update, then break and people wonder why their sites are no longer working are told…. “Well, we had plenty of discussions about it over the course of a few months and people were allowed to give their input!”
  
  I must admit reading the third thread about the topic that this exactly my impression. Not even a statement by Matt Mullenweg promising the absolute opposite of what is being planned here (besides a lot of input by admins) seems to mark a scratch on the idea.
  
  Prepare well for the coming shitstorm and good luck,
- Andrew Nacin 6:43 am on August 20, 2019
  
  While we can’t be responsible for those not willing to log into their adminadmin (and super admin) area to check on notices, that issue ultimately falls upon the developer/host/etc that configured the install for them and didn’t stress the importance of keeping up to date on the software they are using.
  
  For what it’s worth, the WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers do feel responsible. I recognize that you may not agree with that, and that’s fine, but this is our philosophical stance.
  - Mary Baum 4:08 pm on August 20, 2019
    
    I do agree with that.
    
    Course I also think anyone who installs WooCommerce on a site becomes a fiduciary to that client, so YMMV. 😜
  - Reisiger, Angelika 2:45 am on August 21, 2019
    
    I do disagree with that.
    
    If the user wants a managed WordPress, the user can subscribe to WordPress.comWordPress.com An online implementation of WordPress code that lets you immediately access a new WordPress environment to publish your content. WordPress.com is a private company owned by Automattic that hosts the largest multisite in the world. This is arguably the best place to start blogging if you have never touched WordPress before. https://wordpress.com/.
    
    But we are talking about self hosted WordPress. Make the major autoupgrade an OPT-IN and respect the responsitbility and the ownership of these webmasters.
    
    However, it’s the same sad discussion as it was with WordPress 5.0 and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/. So many voices against the early release of gutenberg etc. in november/december 2018 …
    
    Reading some of the comments here along with the ones on the initial proposal it sounds like this is something that WILL happen no matter how many votes against it are cast based.
    
    .
Ian Dunn 10:35 pm on August 20, 2019
A few ideas from the meeting that stood out to me:
- We can try to determine if a site is abandoned (by checking for recent logins, etc), and use that as part of the criteria for if a site should be updated or not.
- We could organize support squads to help people in the forums if they experience any problems.
- We could try getting hosts to send emails too, because they might have a different email address, and hearing from multiple sources would make it seem more serious. IIRC, though, the bulk of abandoned sites are on the long-tail of hosts, so this may not be practical.
- Christopher Churchill 11:01 pm on August 20, 2019
  
  Can we actually detect the Frontend traffic a site is receiving and if its below w certain threshold I. E abandoned then just update it regardless and if its above have a different approach?
  - Ian Dunn 12:59 am on August 21, 2019
    
    At first glance, I’m not seeing a practical/performant way to do that, but I’d also be surprised if there are many sites that have a significant amount of traffic and are running on WP 3.7 and have auto-updates enabled and would ignore all of the email warnings.
    - Christopher Churchill 8:47 am on August 21, 2019
      
      At first glance, I’m not seeing a practical/performant way to do that, but I’d also be surprised if there are many sites that have a significant amount of traffic and are running on WP 3.7 and have auto-updates enabled and would ignore all of the email warnings.
      
      you being surprised is a bit anecdotal, isn’t it? Any way we can actually quantify what the number would be?
      - Aaron D. Campbell 2:49 pm on August 21, 2019
        
        It might be a bit anecdotal, but unfortunately we can’t get numbers for all those things (although we can for some). Walking through the assumptions here:
        
        We don’t have any way of knowing the amount of traffic a site gets outside of “enough to trigger update checks to WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/”.
        
        The TOTAL number on 3.7 is under 30k or about 0.1% of WordPress sites according to BuiltWith.
        
        It looks like about 70-75% of sites reporting as 3.7 are on the latest 3.7.x release, so that’d be my best estimate on how many have auto updates on. This would bring us down to about 0.075% of WordPress sites.
        
        And lastly, we can’t know how many of those will ignore the E-Mail warnings and other posts/social/etc that will happen. Hopefully if we do this well it will be fairly effective.
- Justin DoCanto 12:15 am on August 21, 2019
  
  A recent login doesn’t determine if a site is abandoned.
  
  For example: A client of mine has a portfolio site that is live. It gets regular traffic, requires NO changes so nobody logs in & is updated manually using manageWP, when I have the time to double check everything runs smoothly after the update.
  
  I don’t think Ive logged into the actual site in a year. Maybe longer.
  
  I’m assuming this would fall under your threshold for what you considered abandoned and I absolutely do NOT want it auto-updated because you think it’s “abandoned”.
  - Andrew Nacin 12:20 am on August 21, 2019
    
    It sounds like you’re keeping the site up to date though, right?
  - Ian Dunn 1:02 am on August 21, 2019
    
    That was just a rough example to communicate the gist of the idea, not a fully-fledged proposal. If that kind of idea is incorporated, it would be more sophisticated and incorporate multiple criteria.
Hendrik Luehrsen 11:45 am on August 21, 2019

Silence is not consent.

By configuring and updating our WordPress as it stands today we agreed upon auto-updating minor versions and security patches.

Suddenly reversing this and also allowing major updates not only moves against the clear will of the users, it sets a dangerous precedent about how reliable decisions made in the WordPress project are.

This is one of the very many reasons why we need a transparent and reliable decision making process within this project, now more than ever.
- Paul Gilzow 5:14 pm on August 21, 2019
  
  :claps: and +1
Rachel Cherry 5:53 pm on August 21, 2019

What most people are arguing isn’t actually updating software (of course no one wants someone’s website to be insecure) but, instead, does the project have the right to basically hack people’s websites without their consent.

WordPress needs governance and policies.

We need a policy that states our stance on privacy and how we define consent (implicit vs explicit).

Yes, we decided to auto update minor releases (is this in writing somewhere?) but is that rule retroactive to before the auto update decision was made? Does it include major releases?

There is no clear path for Ian to resolve this discussion because there is no clear path for how these decisions are made, especially when the feedback is so diverse. It’s not even clear if Ian has the authority to resolve the discussion.

So here we are stuck in a debate with a lot of opinions but no governance/policies to cite.

Having clear policies on important topics such as privacy, consent, and autonomy are necessary to move the project forward because decisions are driven by the project’s priorities, and not by individual opinions.

We need to make it clear how the project makes decisions, and where we stand on key issues so people know what they are getting into when they enter the project/decide to use WordPress.
- pepe 6:06 pm on August 21, 2019
  
  The policy on “minor version updates”-only can be found in writing on https://wordpress.org/support/article/configuring-automatic-background-updates/
Jon Brown 11:04 pm on August 22, 2019

Serious question. Has anyone asked legal about this?

I think we all recognize that the “policy” was minor updates. It’s fair to say that site owners consented to minor updates.

However, you’re proposing changing that and doing major updates based on an “opt-out” condition. That may fly in a SASS but self-hosted WordPress is not a SASS. There are legal site owners and you don’t have their authorization to perform major updates.

That seems an obvious case of computer trespass. https://en.wikipedia.org/wiki/Computer_trespass

I don’t see how you can do this safely from a legal perspective without making it opt-in.
- Ian Dunn 1:55 am on August 23, 2019
  
  I have, and they’re looking into it. I’ll post an update there once they’ve had time to form an opinion.
  - Jon Brown 3:53 am on August 23, 2019
    
    TY. Interested in what they say, because this really sounds like it’d be open to litigation.
    
    WP might be without warranty, but this is a deliberate action. My concern remains that in a lot of jurisdictions it does matter if the trespass was malicious. Web devs have been sued for updating sites without authorization to do so. Again, I hold the original authorization was for auto-updates of minor versions, you can’t just change that without their opt-in consent to do so.
    - Ian Dunn 4:35 pm on August 23, 2019
      
      Web devs have been sued for updating sites without authorization to do so.
      
      Do you remember the source for that? I’d be happy to pass it on to the lawyers so they can include it in their review.
- emaildano 4:43 pm on August 23, 2019
  
  Does the warranty section of the license cover that?
  
  https://github.com/WordPress/WordPress/blob/master/license.txt#L297-L307
  
  Also this first bit: https://github.com/WordPress/WordPress/blob/master/license.txt#L10-L13
  
  Do you mean SaaS? (Software as a Service)
Wendy__D 3:35 am on August 23, 2019

Still voicing my vote that this should be opt-in, not opt-out. There must be consent to change the agreement of how updates work, especially since it has been acknowledged this situation carries the potential to break sites, and have non-detectable breakage. Legally, morally, ethically – opt-in is the right choice.

Genuine question: the prevailing thought that this must opt-out due to the possibility that the communication plan may be ineffective and if users are not forced the sites will inevitably be hackedhacked . Is there not still the overwhelming possibility that if sites are not updating CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. they are likely not updating plugins as well and therefore the sites would still be extremely vulnerable? We’ll have broken some sites (which could possibly be considered negligent or malicious action) while leaving others updated in Core but still at risk (also negligent if you’re saying EOL alone is negligent). It would seem like in this scenario we haven’t really fixed anything except maybe felt a little better EOLing old versions.

I would like numbers on how many sites are one old versions of core, have auto-updates on, don’t respond to an email, yet DO update their plugins. I don’t think many will exist.
If they respond to an email they’ve made their choice.
If they don’t update plugins they’re still likely at risk despite this plan.
- Ian Dunn 4:34 pm on August 23, 2019
  
  Is there not still the overwhelming possibility that if sites are not updating CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. they are likely not updating plugins as well and therefore the sites would still be extremely vulnerable?
  
  That’s a good question, and I agree that there will be sites that are still vulnerable due to plugins. But there will also be sites that aren’t, because the particular plugins that they’re running don’t have any known vulnerabilities; or they do, but those vulnerabilities only work under specific circumstances which don’t apply to all sites.
  
  Just because we can’t fix every possible vulnerability doesn’t mean that we shouldn’t fix the ones that we’re able to.
Heather Burns 12:03 pm on August 23, 2019

As long as there is a separate post in this blogblog (versus network, site) concerning conflicts of interest in the WordPress project, is anyone else gobsmacked at the notion that the employees of the project lead’s company can call on their internal corporate counsel for a legal opinion on an idea they themselves devised for the open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project? Does anyone honestly believe that counsel will speak truth to power rather than tell them what they want to hear? What precedent does this establish for contributors to open source projects who have concerns about a plan’s legality, but who do not have a corporate legal team at their disposal? What statement does this send about contributors who have the privilege of being able to mark their own homework vs contributors who do not? What would happen if other contributors wanted a second opinion from genuinely independent counsel: is that crowdfunding time (as with the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) audit)?

And would any of the questions I’ve raised above pass the laugh test in any real-world situation outside this project?
anonymized-21e4dd0abfe8a0337cb8692304d453ea 7:24 am on November 28, 2019

As an SEO and marketer I can tell you that having mandatory auto-updates is a must. Here is why.

When something breaks, you could have a system to roll back an update. But for the majority of the cases what happens is that hackers see the changelog and the security vulnerabilities, then create mass exploits and inject tons of hackedhacked , cloaked and other content.

The end result is that even if you clean up the security issues later, search engines like Google may have issue with your site and decrease your visibility for weeks and even months.

Most of the regular WordPress users are not geeks, they don’t even understand that they are hacked.

You can see tons of demos even from WP developers, marketers and SEOs that do not update their WP and plugins on time and that is visible in the demos.

People who use exploits don’t often do a targeted attack, they have massive scripts to find all people with the outdated version of some pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party as they know there is a security issuesecurity issue A security issue is a type of bug that can affect the security of WordPress installations. Specifically, it is a report of a bug that you have found in the WordPress core code, and that you have determined can be used to gain some level of access to a site running WordPress that you should not have..

Small mom and pop shops loose their revenue because Google decreases visibility of these hacked sites, sometimes it takes months for them to finally resolve the visibility issue.

The collateral damage from the lack of auto-updates on the marketing side are huge.

It will make much more sense for you to force auto-updates by default and have a backup system by default that keeps some of the old versions so that if something is broken, it could be reverted back.

The benefits of having auto-updates are much greater than the cons of having something broken.

Also, again, when you fix a security issue on the site itself, it could take months if ever to be resolved on the search engine side.

WordPress should also introduce Google ReCaptcha on WP login and strong 2FA by default.

We are 2019, get up with the times!

Comments are closed.

Welcome!

Communication

Follow-up Discussion on Major Auto Updates

Welcome!

Communication

Share this: