Blog Posts

By “understand how it works” I mean could you, if asked to do so, put together a presentation for managers and investors in your AdTech company or your brand’s advertising or privacy groups that can explain in moderate detail how it works today and how it currently is envisioned to work when the specification and the underlying systems are completed?

We are not going to get into flows or “connective tissue” for how the various pieces talk to each other (e.g. OHTTP) for now. We are going to build up the main static elements first, bit-by-painful-bit, exploring all the underlying concepts and technologies that reside within and drive the functionality of these “big pieces”. Then we will show how all the pieces fit together.

This will be a living document, so you can always check back in if you see a new term that I haven’t explained before to see if I define it here. Alternately, please use the comments section below to ask me to define terms here that you would find useful.

The previous post ended with a high-level diagram of the revised Chrome browser that is adapted for the Google Privacy Sandbox (Figure 1). In this article, we will explore in more detail the core products and services that form the browser side of the Privacy Sandbox. In the subsequent article, we will highlight each element in Figure 1 and explain how it supports/ties into the products and services that need to be delivered (Figure 2).

The design of the sandbox is intended to meet these requirements while still allowing for the delivery of effective advertising, whether designed for the top-, middle-, or bottom-of-funnel that can positively lift sales and have a positive return on ad spend.

This post covers the next unique element in the browser that has been adapted for the Google Privacy Sandbox: worklets. Worklets were introduced in Chrome 61 (2017) specifically for performance-critical tasks related to audio processing, video manipulation, and animation. They allow for multi-threaded execution off the main Javascript thread, were designed for tight integration with browser APIs, and have restricted capabilities to ensure security and minimize attack vectors.

Today we dive into the last three elements of the main browser frame before moving into browser storage: navigators, promises and beacons. These elements are not specific to the Privacy Sandbox. Promises are a standard structure in JavaScript; navigators and beacons are core browser elements in HTML5.

We now move into a series of posts about elements of browser-side storage. As discussed in my second post, there are six forms of storage that are standard in browsers today

Cookies Having Independent Partitioned State (CHIPS) is the first of the five adaptations of browser storage for the Privacy Sandbox we will examine. But in order to talk about CHIPS, why it was needed, and what it does, we must talk about the technology it builds upon: cookies.

Now that we have covered cookies in their particular, isolated post (does that mean we have put them into a blog partition?), it is time to explore partitioned storage in more detail.

WebAssembly, also known as Wasm, is an open W3C standard that was first released in 2015. Wasm is a new type of code that allows native applications written in languages like C++ to run efficiently and portably in a web browser. The term ‘portably’, in this case, means the code can run within any browser context using standard browser APIs without requiring any recoding.

Well, here I thought by now I would be getting into the details of the new storage elements that are part of the Privacy Sandbox. But it turns out we have to take one more detour through related material to really understand how these elements fit into the evolution of today’s browsers.

In the last post, we talked about traversable navigables. I said I would delve a little deeper into these concepts to help you understand them at a more technically accurate level. You don’t need to read this post to understand browser storage at the level we need for the Privacy Sandbox. But I know many technical business people and product owners really like to understand the details. So if you are one of those people, this post is for you.

This will be our last post on browser-side storage, thankfully. Thankfully because we can now move on to the core reason I began writing this blog in the first place - understanding the details of the Topics API, Protected Audiences API, and the Attribution Reporting API, along with their companion APIs like the Private Aggregation API. But before we get there, we have to cover three topics:

Private state tokens are a completely invisible, private way to validate that real users are visiting a web site. They allow one website or mobile app (a user agent) to validate in a privacy-compliant way that a particular user agent represents a real viewer, not a bot or other fraudulent entity.

We now move into the last two topics before we leave the browser side of the Privacy Sandbox behind: HTTP headers and browser permissions. We already did a quick review of HTTP headers in the post The Big Picture and Core Browser Elements.

Fingerprinting is a set of techniques for identifying a user agent from characteristics of the browser or the device on which it runs. Some of these techniques are deterministic - for example by reading the user agent header - but many are derived using statistical learning.

In the last post we introduced the basics of browser and device fingerprinting and noted just how much information is available to any website or third-party tag embedded in a served page. The intention was to allow websites to optimize the user experience for the specific combination of device, operating system, browser, screen size, and more on a given viewer’s device.

This will be the last post (for now) on the browser-side before we move into a discussion of the four specific APIs that make up advertising-focused elements of the Google Privacy Sandbox: Topics, Protected Audiences, Attribution Reporting, and Private Aggregation. The topic is browser permissions. Permissions come in two indirectly-related core specifications: the Permissions API specification and the Permissions Policy specification.