If given a choice, I’ll always prefer that a vulnerable plugin breaks my site (or functionality) over compromising the entire site. There really shouldn’t even be a choice here.
They may have other security measures in place that we don’t and can’t know about that would mitigate the problem.
At that point you’ve just broken a site for no good reason, and potentially lost them a lot of business. That doesn’t seem like a good idea.
In terms of security notifications, there are no good ideas. I suspect that’s why we’re still having this discussion, 15 years after WordPress’ inception.
The original context is missing, but ClassicPress or in fact anyone having the ability to remotely disable plugins on a site they do not host would be a very bad thing. If nothing else you damage the confidence of people in ClassicPress; if you can do this, what else could you do?
You can always keep trying to protect people from themselves, but at some point you need to stop before you build a padded room without a door. You should not automatically deactivate stuff on someone else’s site for any reason without consent.
You could offer a protection option, but that would have to be hard opt-in only. Doing it any other way will make them blame you when something breaks, whereas otherwise they can only blame themselves (or the plugin maker who caused the vulnerability).
Unfortunately not everyone who builds websites understands this responsibility or knows how to fulfill it.
I agree, passing responsibility for security to your customers isn’t right either.
The best way to prevent failure in complex systems is to address the potential failures at multiple layers. A few examples from different roles and perspectives in the context of managing a ClassicPress site:
- Because I own ClassicPress and WordPress websites, I do what I can to stay on top of upgrades, security news etc.
- Because I manage ClassicPress websites for other people, I do the same for their sites.
- Because I am one of the people responsible for the ClassicPress code, I take security seriously and review new and existing code for potential issues. We also are always thinking about ways to “harden” the codebase to prevent common security issues.
- When ClassicPress is responsible for a plugin directory, and a security problem arises with one of the plugins we list, we will need to be able to take steps to ensure our users’ continued security.
I think the best case scenario for a new vulnerability in a plugin is that we can quickly and quietly get a fix out, and for severe vulnerabilities, push the fix as an automatic update. This isn’t always going to be possible though, and sometimes it will fall to us to make hard decisions about these cases.
@Marialena.S here we are debating if ClassicPress as an entity should deactivate vulnerable plugins on CP sites or just warn the user to take action.
There are legal issues with having the access level needed from ClassicPress as a CMS project to be able to deactivate a plugin on a user’s site. Also doing so can result in a broken site due to CP organization and the whole entity could be sued legally for this.
In my opinion we, as an open source project, shouldn’t be allowed to access users’ sites to perform such action of deactivation, but problem remains: is warning them enough? Many users see notices when site is already broken from the vulnerability. We need a way to indicate a plugin is unsafe obliging people to secure their sites.
This is a little bit the wrong way round.
ClassicPress could potentially face a lawsuit if it (a) intentionally or (b) negligently contributed to harming a person’s website. If we know about a vulnerability and do something to mitigate that problem, then we won’t have a problem with (a). The real issue is how to address (b).
The way to avoid liability for (b) is to act reasonably. The law is not so arrogant as to think it knows better than the professionals what reasonable behavior is; it will, by default, defer to the expertise of the professionals.
So the question turns out to be what is the most professional way to deal with such an issue, and that’s for us to work out. The likelihood is that there isn’t a one-size-fits-all answer. In some cases, notifying users of the problematic plugin will be enough. In others, deactivating it might be preferable.
Actually, this debate is really useful in legal terms (as well as in practical terms) because (a) it shows that the ClassicPress community cares about the issue (which demonstrates reasonableness) and (b) it also shows that reasonable people may disagree (which gives us wider latitude in coming to the most appropriate answer).
I never suggested that we have any sort of remote access to sites - I can’t imagine anything worse than trying to secure that; only a Politician would think it’s a good idea.
That said, it doesn’t mean the CP install itself can’t disable a plugin if it’s suitably flagged by the plugin directory, and that could be configurable.
I’m still in 2 minds about whether it’s a good idea.
This is exactly what I referred to. I’d be happy to opt-in. I think of it like this: which will cause more damage… having a broken plugin…or losing trust of my users because (et al) I wasn’t savvy enough about security. There’s no question for which scenario I’d rather be mitigating damages.