Postgres OR returns true when one side is true, whatever the other side says. That is the entire failure. With no session, `id = auth.uid()` is null [2]. The second term, `not public.blocked_with(id)`, is true, because `blocked_with` is an `exists()` over a table of block pairs and an `exists()` with no identity to match answers false rather than null [3]. `null or not false` is true, for every row [4]. The identity comparison contributes nothing to the result [17].
Write the same check without the negation and it fails the other way. `null or false` is null, the row does not pass, and every anonymous caller gets an empty array [19]. That version gets reported as a bug before lunch. The version that leaks is the one where a helper function returns a clean false and a `not` in front of it turns absence of data into permission.
The diagnostic in the writeup is worth copying for one reason: it selects four columns, not one [5]. `auth_uid`, the equality, the function call, then the whole predicate. Selecting only the predicate tells you the verdict. Selecting the terms tells you which one flipped, which is what you need before you decide where the guard goes.
Two things gate what the publishable key reaches: the table `GRANT` and the policy [10]. Supabase grants `select` on public tables to `anon` by default, which is what makes an anonymous client work at all [10], and the policy evaluated true [4]. Two gates, zero closed [18]. The people directory does bounce signed-out visitors to a login page, but that redirect is JavaScript running in the browser after the page loads [7], and the request that reads the table is a curl to `/rest/v1/profiles?select=*` with the key in a header [8].
The fix is one predicate line [13], and it blanked the marketing page, because the "3 waiting" figure on each learning-path card came from reading `profiles` anonymously and counting rows in the browser [14]. According to the author, the claim "nothing depends on anonymous reads" was written down before the grep that found the caller [15]. Eight cards need eight integers [20], so the replacement is `public.track_counts()`: `security definer`, `stable`, `set search_path = public`, `revoke all ... from public`, then `grant execute` to `anon` and `authenticated` [16]. That is the right shape. The anonymous caller keeps the aggregate it actually consumed and loses the route to the rows.
For this not to be your bug, every anon-reachable policy has to fail closed when `auth.uid()` is null, which rules out negated identity helpers and any bare equality you are trusting to return false rather than null. What the returned rows meant in this case was a weekly availability grid per person, on a product where users meet strangers one-to-one on camera [12]. The author's own description of the outcome is the line I would put in the review comment: `using (true)` with extra steps [21].
