Sandpiper

From Bitnami MediaWiki
Revision as of 13:30, 17 October 2021 by Jkoran (talk | contribs) (Created page with "CarbonRMP’s Sandpiper proposal enables shared storage among a network of affiliated organizations.<ref>https://github.com/carbondmp/sandpiper</ref> Sandpiper employs additio...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

CarbonRMP’s Sandpiper proposal enables shared storage among a network of affiliated organizations.[1] Sandpiper employs additional headers in the HTTP protocol with security validation through SSL Certificates.

Overview

CarbonRMP’s Sandpiper proposal “allows a website operator to declare a sandbox that specifies how data can be accessed and shared.”[2]

Sandpiper relies on additional headers in the HTTP protocol with security validation through SSL Certificates to verify the relationship between different participants that are accessing and storing data. The nonrepudiable nature of public/private key encryption provides enhanced transparency and accountability associated with data access and processing.

Sandpiper proposes adding new attributes to Access-Control-Request-Headers that govern which requests can access/update the information linked to an origin by designating the authorized domains:

  • access-control-allow-1p-sandbox
    • access-control-allow-1p-sandbox-domains
  • access-control-allow-3p-sandbox
    • access-control-allow-3p-in-1p-domains
    • access-control-allow-3p-in-3p-domains

The “allow” designates which domains have access or update control over the information stored. These attributes require the browser to send preflight requests from the sandbox element on the site that restricts which domains may interact with the storage linked to this element.

The benefit of this proposal is that a user’s interaction with a single page may update different information for different organizations that support the operations of that same site (e.g., a site analytics vendor receives all events, ad partner receives subset of events).

The site controller designates which organizations may access the information by having an allow list. For example, a marketer may be given access to the ad view data to link to subsequent activity on the marketer website (e.g., shoe purchase) by granting permission to this “network.” This use case can be expanded to an organization that operates multiple domains that the same marketer has purchased a “run of network” campaign, such that each sandbox element allows that marketer access to the data stored in the local client.

Governance of acceptable and unacceptable uses of the data once accessed is governed by Partnership for Responsible Addressable Media (PRAM) principles.

Impact

CarbonRMP is to be commended for using established web standards to improve the transparency and auditability of data access and processing, without adding additional cost by relying on organizations’ existing public/private key certificates to validate which entities are involved in given transactions.

The Sandpiper proposal reduces local client storage of information that would otherwise need to be redundantly stored per origin when used by the same data controller across different origins. However, given the same campaign ad event data must be stored distinctly across all origins in which the user interacts with the ad, this approach will use greater client storage than needed at present. This forces people to absorb the cost of B2B storage and processing, that may require them to update older devices to continue to access ad-funded sites.

Given a site owner does not know which organization may win any given ad auction on first request to the sandboxed element, this element would need to send all possible allowed domains which would greatly slow down the user experience when interacting with a site. If domains were grouped into networks, this limitation would still put an upper limit on the number of network organizations that could compete in the open web and perhaps be a barrier to entry for new startups.

Open Questions

  • How much local storage is required to store pairwise allow lists for every domain (and origin?) that a user interacts with?
  • How many organizations can be allowed from a given sandboxed element without impacting user experience?
  • How are new entrants able to participate in digital markets?
  • Is the "allow" setting at a controller (e.g., marketer) level or at a supply-chain partner (e.g., attribution vendor) level?

See Also

References