Why Your Security Advice is Probably Just Gardening Advice

TLDR: Security advice often fails because it ignores the specific threat model of the user, treating complex digital risks like generic gardening chores. This talk deconstructs common "best practices" like disabling ad IDs, using VPNs, and covering webcams, revealing that these are often ineffective or counterproductive without context. For researchers and pentesters, the takeaway is clear: stop pushing one-size-fits-all hardening guides and start building defenses that actually match the environment.

Security advice has a massive signal-to-noise problem. Every year, the same tired list of "must-do" hardening steps circulates through social media and corporate training modules. We tell users to disable their ad IDs, cover their laptop cameras, and install a VPN, as if these actions are universal panaceas for digital risk. They aren't. In reality, these steps are often the digital equivalent of planting strawberries in a desert—they ignore the environment, the climate, and the actual threats present.

The Problem with Generic Hardening

When we talk about an "attack surface," we are really talking about a garden plot. You don't plant crops in someone else's garden, and you don't waste resources defending areas that aren't under your control. Yet, most security advice treats every user as if they are facing the same threat landscape.

Take the advice to disable ad ID tracking on mobile devices. For a privacy-conscious user, this is a valid step to limit data harvesting by ad tech ecosystems. But if you are a high-risk target, disabling an ad ID does nothing to stop a sophisticated actor from using browser fingerprinting or other telemetry to track you. The advice is not "wrong," but it is incomplete. It gives users a false sense of security, which is often more dangerous than having no security at all.

When "Best Practices" Become Liabilities

Security researchers often see the fallout of this generic advice during engagements. We see users who have "hardened" their systems with a dozen conflicting extensions and VPNs, only to find that their actual, critical vulnerabilities—like weak authentication or unpatched software—remain wide open.

Consider the common recommendation to use a VPN for all traffic. While a VPN can hide your IP address from a local ISP, it does not provide anonymity against a determined adversary. If you are using a free or low-quality VPN, you are often just shifting your trust from your ISP to a third-party provider that may be logging your traffic or selling your data. If your threat model involves state-level actors, a VPN is not a shield; it is a single point of failure.

Similarly, the advice to cover your laptop camera is a classic example of focusing on the wrong threat. If an attacker has achieved remote code execution (RCE) on your machine, they have already won. They can dump your memory, exfiltrate your keys, and pivot through your network. Whether they can see you through your webcam is a secondary concern. By focusing on the camera, you are ignoring the fact that your system is already compromised.

Context is the Only Metric That Matters

Effective security requires a threat model that is as specific as a plant hardiness zone map. You cannot grow the same plants in Arizona that you grow in Maine. You cannot apply the same security controls to a journalist in a surveillance state that you apply to a developer working on a standard enterprise application.

For those of us in the industry, our job is to stop the spread of "viral" security advice that lacks technical nuance. When you are performing a penetration test or a red team engagement, look at the actual environment. Are the users actually at risk of physical surveillance? Are they handling sensitive PII that requires encryption at rest?

If you are advising a team, start by asking: "What are we actually trying to protect, and who is trying to take it?" If the answer is "everything from everyone," you have already failed.

Moving Beyond the Checklist

We need to stop treating security like a set of chores and start treating it like an engineering problem. If you are a researcher, look for the gaps where generic advice fails. If you are a developer, focus on building systems that are secure by design rather than relying on users to toggle settings they don't understand.

The next time you see a "top 10 security tips" list, look for the context. If it doesn't mention the user's specific environment or threat model, it is noise. We have enough noise in this industry. Let's start focusing on the signal. If you want to build resilient defenses, you have to get your hands dirty in the soil of the actual system, not just read the back of a seed packet.