Jetpack Threats Detection Page Suggests Paid Malware Removal to WordPress.com Atomic Users

[ash1eygrace]

Quick summary

Navigating to Jetpack > Scan > and clicking the dropdown on alerts shares more details about the alert Jetpack detected, and recommends Codeable for help with resolving the threat. On WordPress.com Atomic sites, we include malware removal as part of hosting services.

Steps to reproduce

1. Start with an Atomic site.
2. Add the test.txt file from Eicar to the site and change it to a PHP extension.
3. Navigate to Jetpack > Scan or directly visit https://wordpress.com/scan/{sitename}
4. Scan the site
5. Click the drop-down to view more information about the malware alert.

What you expected to happen

Since malware removal is a benefit included with WordPress.com hosting, I expect the message to inform users that our team handles malware removal for them. Reference.

What actually happened

I see a recommendation for paid services through Codeable, with this message:

If you need more help to resolve this threat, we recommend Codeable, a trusted freelancer marketplace of highly vetted WordPress experts. They have identified a select group of security experts to help with these projects. Pricing ranges from $70-120/hour, and you can get a free estimate with no obligation to hire.

Impact

One

Available workarounds?

No and the platform is usable

If the above answer is "Yes...", outline the workaround.

Platform (Simple and/or Atomic)

Atomic

Logs or notes

More context here: p1729970443509609/1729934239.609379-slack-CEYCDRUL9

[nateweller]

Related: p7DVsv-lqP-p2

[Robertght]

📌 REPRODUCTION RESULTS

• Tested on Atomic – Replicated

📌 ACTIONS

• Triaged
• Raised priority as this is related to security and how we manage information on our docs vs platform.

@Automattic/waffle-makers I believe this is really important and we should be super consistent with our messaging. If we should update the documentation to reflect what is described in the original report, please let me know.

[ilonagl]

@alexsanford, @bhoop, @nateweller just checking in to see if you need any design or copy help to move this task forward. I see it marked as a high-priority task. Please let me know if there is anything I can help you with.

[bhoop]

I think the issue goes a little deeper than the Codeable copy here - the entire screen allows threats to be managed (viewed, fixed, ignored, etc). Now that all dotcom customers have wp-admin access I think we need to discuss if it makes sense to expose any of this to dotcom customers at all... since, as noted, malware removal is handled by us and not customers.

Would it make more sense to just hide this screen entirely? Or are there elements of malware scanning / detection / history that we still want to show to customers even though they can't take action on anything?

[ash1eygrace]

Yeah, I think it makes the most sense to hide malware alerts entirely for WordPress.com users. Since we handle malware triage and cleanup for all WordPress.com sites, users shouldn't have to worry about malware alerts. From a UX perspective, exposing those alerts may only create unnecessary concern without adding real value (IMO, the value from a customer's POV is piece of mind knowing WordPress.com deals with it so I can focus on my business.)

Initially, the project’s goal was to expose vulnerable plugins only, not malware. In rare cases, vulnerable plugin can lead to malware infections and this project was aiming to solve those few infections by encouraging users to update their Premium plugins. This comment from @JoshuaGoode sums up that project's goal well: pdtR3Z-1YM-p2#comment-1848.

I’m not sure if the scope of this project shifted later on, and showing these alerts for malware is now intentional? Perhaps someone from @Automattic/fusion can offer more insight!

[villanovachile]

I agree that it makes most sense to hide malware alerts. I think the idea was to show value, but it has the potential to cause concern and confusion.

I also think it would be a good idea to only expose vulnerabilities to users as Josh commented. Most of the vulnerable plugins hosted on dotcom are premium plugins or plugins not available on the repo, and would require manual updating from the user's end.

[edequalsawesome]

@ash1eygrace Thank you so much for the team ping on this!

@villanovachile With all due respect to Joshua, a comment from nearly 18 months ago isn't relevant to where things stand today... things like this are something where @serabi and I should be involved 🙂

The scope of the project that is being referenced was changed -- while it was initially intended to only show outdated plugins, with the push for Developers on WordPress.com, we advocated for showing the potential malware on a site to (a) let developers and agencies know what threats might exist on their client's sites without needing to install a third-party solution and (b) provide some context/value for the work we do removing those threats for customers as part of our work. There's more about that here: pdKhl6-3RI-p2

If it were at all possible, changing the "Hire Codable" card to instead talk about how security services are provided as part of their Business plan, and also include a link to contact our support if they have questions, would be a better change (and provide more visibility to our customers as to why they're paying for the Business plan).

[RafaelFunchal]

Just noting that in addition to not being aligned with our focus on developers, hiding the entire screen would undo the work of this project p7DVsv-lqP-p2

Changing the wording for WoA sites would be better, IMHO.

[mgozdis]

My take on it may be worthless 😂, but this is what I think:

1. It is bad to recommend Codeable when fixing or ignoring threats.
2. It is even worse to let user ignore threats - this actually lets users decide to keep malware on their site where we will then never see it in the security queue.
3. Letting users run an auto-fixer has proven to cause problems, even for developers/agencies who have broke their site because they don't read what it does.
4. Letting users scan the site, see the history, and what we do as a service is good.

Overall, I think exposing it is good, but allowing the ability for users to ignore threats is dangerous.

[ash1eygrace]

My take on it may be worthless 😂, but this is what I think:

Those are all logical and valid takes, not worthless! I agree, 100%!

[villanovachile]

The scope of the project that is being referenced was changed -- while it was initially intended to only show outdated plugins, with the push for Developers on WordPress.com, we advocated for showing the potential malware on a site to (a) let developers and agencies know what threats might exist on their client's sites without needing to install a third-party solution and (b) provide some context/value for the work we do removing those threats for customers as part of our work. There's more about that here: pdKhl6-3RI-p2

I should probably clarify my comment a bit better! With all of the context in the above projects and focus on developers and agencies, my opinion is still that active threats shouldn't be exposed to users. I think the current doc prefaces it pretty well: https://wordpress.com/support/malware-and-site-security/#how-wordpress.com-protects-against-malware

It also details how they can see a history of fixed threats (which, I agree with Mike, can show value and is a good thing).

Mike outlined all of the reasons why this might not be the best approach, so I won't repeat them, but they detail many of the concerns we discussed in the thread in the original slack thread.

[serabi]

It is even worse to let user ignore threats - this actually lets users decide to keep malware on their site where we will then never see it in the security queue.

Yes, let's also make sure that we don't allow Dotcom sites to hide malware warnings.

I should probably clarify my comment a bit better! With all of the context in the above projects and focus on developers and agencies, my opinion is still that active threats shouldn't be exposed to users.

As @edequalsawesome and @RafaelFunchal mentioned above, not exposing active threats to users would undo the work of multiple projects and initiatives, so we don't want to hide these threats. We do definitely want to make sure that they can't just hide the malware warnings, and we do not want to send them to Codable 😂

I would second what Ed says here:

If it were at all possible, changing the "Hire Codable" card to instead talk about how security services are provided as part of their Business plan, and also include a link to contact our support if they have questions, would be a better change (and provide more visibility to our customers as to why they're paying for the Business plan).

...but add the clause that we also need to make sure that they aren't able to just ignore these malware warnings. What if we made the blue button say Contact WordPress.com support and hid the Ignore Threat button entirely on sites hosted on Dotcom?

[TPilgs]

Just popping in to add a +1 to the concept of showing folks what we're fixing but they definitely shouldn't be able to ignore them. We're in a unique position amongst hosting environments to show an incredible value built into the Business/Commerce plans, considering what many others charge for basic security work. Don't want to hide it, but being a developer doesn't mean they're a full expert on what some of these threats can do - or what can happen if they're not removed properly. Many of them know enough to be able to alter something...but possibly alter something that doesn't need to be.

[JoshuaGoode]

Howdy! I left some expanded comments on pdtR3Z-3B4-p2