Sentry's defaults shipped a lifter's shoulder injury while the scrubbing policy passed its tests

The failure sits upstream of the hook, in the fixture. The Kotlin test builds a `SentryEvent`, sets the three extras the author already suspected, and asserts those three come back null ^[4]. It passes, and it could only ever pass, because its input was assembled from the same list as the policy ^[3]. Nothing in that loop ever handled an event the SDK populated for itself, which is exactly where `location.href` arrives ^[7][3].

So both things that went over the wire were defaults. The browser SDK attaches `location.href` to every event, transaction and replay on its own ^[7], and the automatic fetch breadcrumb records request URLs verbatim ^[13]. Neither is an argument to a capture call ^[1]. The one line the author guarded, a `captureMessage` carrying a coarse `reason` tag and nothing else ^[6], behaved exactly as its comment promised. The envelope it travelled in did not: decoded, the intercepted request held `Push Day A`, `Incline Barbell Bench`, and a note reading `left shoulder clicks past parallel` ^[10]. That is two of the six categories the policy declared could never appear in an event ^[3][4], and the second one is a description of somebody's joint.

The waitlist finding is the more instructive of the two, because nothing about it looks like instrumentation. Deduplicating signups by using the email address as the Firestore document id is a defensible design, and it puts the address in the request path ^[12]. Once any library in the page logs request URLs, that design becomes a copier: the email would have been attached to every error occurring later in the session ^[13]. No policy about event fields has an opinion on this, because the address was never a field.

Count the controls. The written policy, the `beforeSend` hook, the unit test and the comment all governed the path from application code into the SDK. One artifact, a request listener that greps outbound `sentry.io` bodies for known-sensitive strings, governed the path from the SDK to the network ^[8][2]. It failed on the first run ^[9].

The cost of that asymmetry is not really the bug, it is the copy. WhyRep's offline, accountless, on-device design is the product claim, not a slogan ^[1], and the page shipping the leak carried a privacy policy stating the site had no third-party trackers ^[2]. Base64 in a URL fragment is not encryption ^[10], so a share link opened by anyone with a decode error handed a third-party service a training log it was written specifically to withhold ^[5]. The author's own summary is the useful part: every guarantee he wrote covered data his code passes to Sentry, and none covered what the SDK collects by itself ^[11].

That is a boundary problem dressed as a scrubbing problem. A unit test on a scrubber proves a function removes the fields you named. Only the bytes prove the product does.