A public-records portal’s GenAI feature shares session cookies with a third-party widget. What integration privacy risk should architecture eliminate?
Select an answer to reveal the explanation.
Short Explanation
Handing your portal session cookie to a third-party GenAI widget is like lending the records-room key to a vendor tour guide. Stop the share — keep sessions first-party. TLS does not need cookie gifts to strangers.
Full Explanation
Sharing session cookies with a third-party GenAI widget on a public-records portal can expose municipal authenticated sessions and associated FOIA or records context to an external party, expanding privacy disclosure and account-takeover risk. Architecture should eliminate cross-site session-cookie sharing—keep sessions first-party, use tokenized or narrowly scoped integrations if third-party assistance is required, and apply cookie partitioning plus Content-Security-Policy controls. Integration privacy design must assume third parties are separate trust domains from the city's portal.
Third-party widgets always improve FOIA response quality is unsupported marketing and irrelevant to session hygiene. Cookie sharing is required for TLS to negotiate successfully is false; TLS handshake and session-cookie scope are independent concerns. Public-records portals should disable all Content-Security-Policy headers removes a defense that can limit unauthorized script and frame integrations that enable cookie theft or silent exfiltration.
Exam caveat: "helpful widget" integrations often request broad cookie access—treat that as a high-risk privacy design flaw for authenticated records portals. Operational check: audit third-party scripts on the portal, set cookies SameSite and host-only appropriately, block third-party access to session cookies, enforce CSP, and verify GenAI features use first-party APIs without cookie passthrough.