Exercise 2: The Two Problems With a Shared Private Key — Possible Solution
====================================================================

PROBLEM 1: DESTROYED ACCOUNTABILITY
------------------------------
Per this chapter, "it destroys per-user accountability entirely - a
log showing 'the shared key connected' tells you nothing about which
actual person was at the keyboard." Once multiple people use the same
private key, any log or record of "this key connected" can no longer
distinguish which specific person actually performed the action.

PROBLEM 2: ALL-OR-NOTHING REVOCATION
------------------------------
Per this chapter, "it also makes revocation all-or-nothing - if the
key leaks, or one person leaves, everyone's access breaks and has to
be re-issued at once." Because the key is shared, there's no way to
revoke just one person's access without also cutting off everyone else
who legitimately still needs it.

WHY PROBLEM 1 CONNECTS TO log1's EVIDENCE-BASED DIAGNOSIS THEME
------------------------------
Per this chapter, this "directly undermines the same evidence-based
diagnosis this whole subject has built around since log1's own first
chapter." log1 teaches that logs are only useful as evidence when they
accurately record what actually happened - a shared key means the
access log itself becomes unreliable evidence, since "the shared key
connected" doesn't identify who was actually responsible for whatever
happened during that session. It's the same underlying failure log1
warns about (evidence that doesn't actually tell you what happened),
just applied to access logs instead of application logs.

WHY THIS WORKS AS AN ANSWER
------------------------------
It states both distinct problems accurately using the chapter's own
wording, and explains specifically why the accountability problem is
framed as the same category of failure log1 already warned against,
rather than treating the connection as a vague thematic similarity.