Falcon

Privacy-coop’s Falcon proposal describes a bitmap store to determine whether a use of personal data is permitted (“Consent DNA”).

Overview

Falcon stores declarations for the intersection of information across legal data uses (“programs”) by organizations (“business”) by legal jurisdiction (“regulation”) by users (“subjects” by each identifier, such as an email, MAID or cookie ID). The output is binary declaration of yes/no (1 or 0) for a given intersection. Default settings for this intersection can be set by policy or regulations or controllers of the information.

The Falcon proposal focuses on creation, storage and retrieval of the above information.

For storage, the data can be visualized as a 3D cube referenced by a user identifier. The user identifier can be (email, phone, UID2, etc.). The “row” stores the organization (e.g., Acme x email, Acme x MAID), which is lazy provisioned. The “column“ stores the legal data use (e.g., consent for personalized marketing). The “layers” stores the jurisdictions the particular user has interfaced with, also lazy provisioned. For example, if a given user has not visited Brazil, then the Brazilian jurisdiction is not (yet) part of the layers. This helps reduce the physical storage of the information linked to each user x organization intersection. Common metadata is required such that each lazy-provisioned element of the dimension maintains the correct sequence in the bit map.

New organizations, uses or jurisdictions add new rows, columns or layers to the cube respectively. Expired data is not removed, which simplifies the update process, but results in an increasingly sparse data structure over time. Each user can be linked to multiple cubes, such that each when compressed the total bitmap would be less than 100kb. For example, if we have 10 jurisdiction and 50 uses by 1,600 orgs for 1 identifier for a single individual, this would be a bitmap of less than 100kb uncompressed. If we imagine compression to add 4x storage, then we could support 4 identifiers OR 6,400 orgs if we request 4 data cubes (1 for each identifier) of 100kb each.

Missing information (say jurisdiction) can be handled by Boolean AND logic. If jurisdiction is known, then only that layer of the bitmap would be used to generate the output. If the jurisdiction is unknown, then an AND operation can be used across all intersections in that user’s cube.

For retrieval, an organization can submit a user identifier to the system to which the result set from Falcon is a JSON object containing the appropriate information signals linked to the identifiers in its store. That is, Falcon returns a JSON array of permitted/non-permitted uses by the three-dimensional array. The information is returned per user identifier rather than logic to do identity resolution that all identifiers link back to the same directly-identifiable individual. This means the system only returns what it has stored and does not attempt to validate the requested update or read of metadata linked to the identifier belongs to the user (“carbon-based life form”). As stated below, this is not a flaw of the design, but merely a separate scope to address authorized access for updates and retrieval.

Updates can be stored as new cube, such that a timestamped record can be recreated from each cube thus creating a form of audit log of changes. Falcon also supports metering, such that after a given number of requests the answer will be 0 regardless of the true values stored. Such a “metering” feature can be used to support marketer use cases, such as frequency capping.

The project is currently hosted by Privacy Co-op. Privacy-coop’s Falcon proposal is to be commended for providing a simple means to normalize and standardize the approach for setting, updating, accessing information stored in this bitmap.

The project is meant to be a sibling to Domain Name System (DNS), hence the storage of this bitmap is called the “Consent Name Service (CNS)”. Just as the DNS system has appropriate methods to assign ownership of a domain name to an IP address, so too this system can use appropriate methods to enable end users to update preferences by organization and by jurisdiction. For example, email confirmation is required to update preferences linked to an email identifier. The authentication process is not part of the system, as the design is focused on storage, update and retrieval of the information stored in the bitmap.

The same edge-based caching of DNS in envisaged for Falcon’s CNS, with redundant geographic storage for efficiency. Decentralized storage across various operators of the CNS follows the same pub/sub process of DNS updates.

Impact

Falcon aims to provide a neutral technical mechanism to more easily manage consistent preferences across organizations and jurisdictions.

Unlike other proposals that embed policy-laden processes into the technology layer, Falcon refreshingly focuses on cost-effective storage, update and retrieval of information.

Open Questions

• Which organization adds consistent columns or layers or organizations to the storage layer?
• Must the data storage approach be centralized, or can distinctly branded preference management solutions exist and interoperate?
• If centralized, how would the governance of this centralized storage approach be funded?
• If centralized, how would the operational costs of this centralized storage approach be funded?
• How are uses (programs) determined to be the same or different across jurisdictions (e.g., “object” vs “opt out”)?
• If people do not want to link different accounts across different distinctly branded preference management solutions (e.g., Facebook, Google and UID2/OpenPass) would logging into the same website using each of authorization solutions appear to that website as a different user?
• How does the update process update “cubes” that contain the same userID (e.g., email) but are not linked (e.g., Facebook, Google and UID2/OpenPass)?