Exercise 2: Why Good Intentions Don't Make Unauthorized Testing Legal — Possible Solution ==================================================================== THE SCENARIO ------------------------------ A developer notices what looks like an exposed admin panel on a company's public website, and decides to "test" whether it's actually vulnerable, planning to report the issue responsibly if it turns out to be real. WHAT'S LEGALLY WRONG WITH THIS PLAN ------------------------------ Per this chapter's own warn-box, the developer has no written authorization from anyone with actual legal authority over that company's systems — noticing something publicly visible on a website is not the same as being granted permission to actively test it. Per this chapter, accessing a computer system without authorization is criminalized under laws like the Computer Fraud and Abuse Act (CFAA) in the US, and comparable statutes exist in most other jurisdictions. The developer's own stated intention — to help, and to report responsibly — is exactly the kind of "good intentions" this chapter's warn-box explicitly states provide NO legal protection at all. The law is concerned with whether access was authorized, not with why the person doing the testing believed it was justified. WHY THIS REMAINS TRUE REGARDLESS OF INTENT ------------------------------ Per this chapter's own explanation, "people with entirely good motives have been investigated and prosecuted for exactly this." The developer's plan to test "whether it's actually vulnerable" is, mechanically, indistinguishable at the legal level from what an attacker with malicious intent might do to the same admin panel — the law doesn't grant an exception for testing done with the intention of eventually disclosing responsibly. Only genuine, prior, written authorization changes that legal picture; wanting to help is a motivation, not a form of authorization. THE CORRECT COURSE OF ACTION ------------------------------ Per this chapter's own material, the developer would need to obtain actual written authorization first — either directly from the company (if that's realistic), or, more practically for someone outside the company, simply report the observation (that a panel appears publicly exposed) WITHOUT attempting to test or confirm its vulnerability themselves, since even confirming it requires exactly the unauthorized access this chapter identifies as the legal problem. WHY THIS WORKS AS AN ANSWER ------------------------------ It applies the chapter's own stated legal principle (no authorization = no protection, regardless of intent) directly to the specific scenario, explains why the developer's own good intentions don't change the legal analysis, and identifies what would actually need to be true (written authorization) before the planned testing could be done legally.