LinkedIn Professional Network  ·  View 29 of 30  ·  7 · Assurance

Privacy and Authorization

The checks every read of member data passes through, and why a block returns not-found.

Editable source SVG draw.io All views
Request Profile request viewer, target Authenticate Session to principal Relationship Block list cached, both ways Graph degree LIquid Decide Blocked? Visibility rule public to private Shape Field masking per-field settings Response Record Access log recruiter + admin 404, not 403 Privacy and Authorization — Every Read Path Interface / broker Security / platform Data store Decision point Application we own failure / alternate A blocked viewer gets not-found rather than forbidden, so the check itself leaks nothing. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • Blocks are checked first, in both directions. A blocked viewer gets a 404, so the block itself is not revealed
  • Visibility is decided per field, not per profile: public, connections, network, or recruiters only
  • Every recruiter and admin read of member data is logged

Performance

  • The block list is cached in Couchbase; graph degree comes from LIquid in memory
  • Decisions are cached per viewer and target for seconds

Risks

  • Every new read path is a new place to forget the check. The policy is a library each Rest.li resource calls, and a test asserts that it does
  • Derived stores (search, feed) apply privacy at read time, because precomputed data is older than the latest setting
◀  Identity and Access Flow All views Abuse Detection and Content Moderation  ▶
Solution Architecture v1.0 · LinkedIn's own stack in LinkedIn-run colos · Enterprise Architecture · 2026-0929-privacy-authorization