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.
3 Likes
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.
1 Like
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?
7 Likes
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).
4 Likes
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.
1 Like
@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.
2 Likes
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).
2 Likes
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.
5 Likes
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.
2 Likes
Sounds like a good thing to put on our security screen as an option that is disabled by default.
5 Likes
Well, we might just add a status to plugin that triggers auto-disabling of plugin when it’s flagged. Of course, this would be with some permission from security page.
2 Likes
How serious of a vulnerability are we talking about though?
Only those that have been publicly disclosed and are known to be exploited in the wild?
It is a different matter to have a broken site that is mainly an info site / a marketing / blog site.
It is a very different matter when that site is an e-commerce, membership or e-learning platform.
It can cause a very serious PR fall-out for the site, without any warning.
To use an analogy here: Responsible disclosure includes contacting the developer and giving them a chance to respond before taking action and publishing the information.
If you break someone’s site, that can have the same effect as public disclosure.
In terms of maintaining your customers’ respect and trust, it is much better for them to hear about security issues from you than finding out when they log in and irately start asking why the site isn’t working.
Some plugins may be easy to replace with others. It is MUCH better e-mailing a customer saying “Hey, just to let you know, we had x issue, but it has already been addressed.”
The site owner should be given at least the same consideration as is given to the developer / plugin owner.
2 Likes
It all gets very complex once you start adding settings for automatically disabling plugins. People will have different overall preferences, some plugins can be safely disabled on some sites but not others, some people will only want to disable some plugins for unauthenticated remote exploits, etc etc etc.
Even if we solve all that, we still have the problem of the plugin directory becoming a much more valuable target: if you can toggle the “exploit in the wild” switch you can disable plugins generally, or target one you want your plugin to replace - amongst other things.
So, the first version of the directory isn’t going to have anything like this; we’ll add it at some point, so it’s still a useful thing to define - I just want to manage expectations.
3 Likes
I don’t like the idea of CP disabling plugins. As each piece is supposed to be GPL compatible, and the license says
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I say let them maintain their own site, and expediting a plugin update is the best option.
4 Likes
Yes, but we’re talking about what happens before there’s an update available.
1 Like
Invisnet,
Sort of like a pre-selected fail-over?
I really like that. 
Joy,
That is about limiting legal liability, not building positive customer relationships / a brand image.
I’d say “in the hope that it will be useful” is a very important part of that sentence.
Not everyone has the same level of skill / knowledge in all areas. Personal responsibility is crucial, but so is mutual respect for each other’s competencies. People are unlikely to adopt a product they feel may leave them in the lurch to sort out a mess they don’t understand, even if it is their own mess.
Respecting someone’s autonomy does not preclude providing them with the best options reasonably possible.
Something else just came to mind and thought I should jot it down before I forget.
A number of plugins use custom deactivation hooks.
How would a function to automatically disable a plugin treat custom tables and so forth created by the plugin (that are deleted in by the plugin’s deactivation hook)?
Because if it just triggers the de-activation hook, it can do an incredible amount of damage i.t.o. data loss.
Of course, regular back-ups and all that… But even with those, the potential havoc / business disruption it can cause…
Is there a way to mitigate it?
1 Like
The deactivation hook should never be used to destroy data (or even unset options). That’s what the uninstall hook is for. 
1 Like