Cookies, Pixels, SDKs, and Consent Banners

An SDK is a bundle of someone else’s code dropped into the app so a feature arrives quickly: measuring taps, attributing an install, showing a map. The legal fact is that the bundle often sends device, location, or behaviour data to that someone else as soon as it runs. If the notice does not name it, the silence is the defect. The client who chose the SDK is the one a regulator will look at first.

Cookies, in two cuts

A cookie is a small text file a site stores through the browser.

Cut by source. A first-party cookie is set by the site the user thinks they are on. It keeps a session or a basket. A third-party cookie is set by another domain, often an advertising network, and can follow the user across unrelated sites.

Cut by life. A session cookie dies when the browser closes. A persistent cookie remains for a stated period — thirty days, a year — and recognises the browser on return.

Pixels are the same idea in a different costume: a tiny request to another server that records the visit. If you can explain a cookie, you can explain a pixel. Both are disclosures waiting for a sentence.

The banner is a product decision

Non-essential tracking should not fire before a choice. A banner that offers Accept, Reject, and a way to choose categories is the shape this course treats as the honest one. A banner that paints Accept in brass and hides Reject three menus down is a dark pattern. The NDPA’s dislike of that kind of design is the point of the lesson; the engineering point is that the SDK must be wired to wait.

A banner that ruins the product is still a design problem you can sit in. The fix is not to let the pixel run early. The fix is to decide which cookies are strictly necessary — the sign-in cookie — and which are measurement, and to load only the first set before a yes.