FAQs

Governance

Elinor Ostrom won a noble prize for her economic work on how to manage resources in common. Inspired by her work, SWAN developed a mechanism to protect your privacy, while enabling your friction-free navigation across the “Digital Commons.”

SWAN enables people’s continued ad-funded access to the diversity of online publishers, which rely on supply chain vendors. The marketers that fund these publishers rely on pseudonymous identifiers that enable marketers to measure and optimize their advertising. SWAN participants are required to keep these identifiers distinct from people’s personal identity.

SWAN is one of the many different Personal Data Management alternatives that the UK Competition and Markets Authority suggests as a remedy to Google’s abuse of its dominant position. The Australian Competition & Consumer Commission similarly recommends the introduction of “Common transaction ID” and “Common user ID” in a way which protects people’s privacy as a remedy to allegations of Google’s anti-competitive behavior.

SWAN's unique identifier is called the "Secure Web ID" or SWID.

You can’t get access to the SWAN data. The Model Terms are a take it or leave it contract. No if's, no but's. If you receive the SWAN data and are not bound by the Model Terms, then the party that send the data to you would be in breach of the Model Terms and must report their breach immediately.

Now is the time to provide feedback and questions by submitting issue via GitHub. Once those participants in the swan.community who wish to form a network are ready to do so, then the Model Terms will become a binding contract between all SWAN data senders and receivers. The Model Terms can then only be changed by the SWAN network according to the rules. This might happen as major privacy laws change. If you use open source today, then you already do this for source code and software. SWAN just extends this principle to data.

Like most documents in swan.community they're available on GitHub. Here's the link.

No. SWAN operators are prohibited from buying and/or selling either media or profile data. Publishers in the SWAN network are free to build profiles to personalize the experiences of those visitors who provide consent.

The demo shows SWAN working with first- and third-party cookies. SWAN will support both, particular for people who wish to reduce consent fatigue by configuring their browser to support the optimum set of features for SWAN. SWAN.community will guide people who wish to benefit from SWAN to choose optimum settings for their browsers.

No. SWAN.community gives people choice and has been designed around people’s needs and the GDPR and ePrivacy laws. It will work with all web browsers. If the web browser has adopted a set of defaults that prevent SWAN from persisting data in cookies, then the user will be informed and provided options to change those defaults. If people are frustrated that they are repeatably asked for SWAN preferences daily, or their stopped adverts are continually being forgotten SWAN.community will help them understand how to configure their browser to reduce this frustration. SWAN.community expects web browser vendors will join SWAN.community to work on physical implementations of SWAN that are embedded into the web browser. Such an implementation must include access control for parties to the model terms and support for the audit log.

SWAN.community has been designed to minimise the frustration people experience when using the web and provide them choice and privacy they can trust.

SWAN.community has been designed specifically for advertising and provides global preference signal and identifiers. It could be extended or adapted for other industries and could include general consent for cookies.

SWAN.community provides a global preference for personalized marketing. Each site that receives that signal is free to the user for a site specific permission. This site specific permission would be considered non SWAN data in the model terms.

SWAN.community currently uses the Offer ID as the root identifier. This has data embedded in it and is cryptographically signed by the publisher or their agent. The Offer ID contains the identifiers and the preference information in a form that is also auditable. Therefore, it is expected the marketer could have access to this information. However, that will ultimately be a policy decision for publishers, advertisers and their suppliers.

Most of SWAN.community is data mechanism and contract. TCF could easily be added to the data model, and could run alongside other mechanism. That is also for the ecosystem to decide.

Privacy

For publishers to be able to use a signal there must be a clear definition concerning the legal meaning of the signal and their obligation to comply with it. SWAN provides this clarity, and a cryptographic audit trail to confirm compliance via the Model Terms. SWAN enables the GPC vision.

A global privacy regulation does not yet exist for the web. However, many regional regulations share many of the same privacy-protecting principles. Among many of these common principles to safeguard people’s privacy are:

  1. The right to have notice and choice about how personal data will be used in clear, concise language. 
  2. Relying on pseudonymous identifiers, rather than a person’s directly-identifiable identity, reduces privacy risks. 
  3. Data minimization to further reduce privacy risks.
  4. Provide people the right to be forgotten.

Under Europe’s GDPR, an organization is required to have a legal basis to collect and process personal data. A common legal basis for GDPR is for an organization (“data controller”) to request consent from the person associated with the personal data. GDPR also has further requirements about being appropriately informed about the future uses of the data. 

Notice and Choice. The SWAN preference dialog clearly explains to users that the SWID will be used to provide them ad-funded access across the websites they visit. This dialog also allows them to opt into personalized marketing.  By simplifying the notice and choice, people can signal their default preferences in a consistent fashion. Of course, people can provide specific organizations additional data outside of the SWAN framework, which publishers and marketers can use to further augment SWID. This opt-in approach to sharing data helps ensure fairness and proportionality, especially when there is robust competition to offer people even greater choice.

European ePrivacy legislation (which applies in tandem with the GDPR) recognizes that consent is not required for strictly necessary cookies that are required for web properties to operate. While this does not extend to personalized marketing, it does cover cookies that remember privacy preferences and many security-related purposes.

Pseudonymization and Data minimization. SWAN’s pseudonymous identifiers minimize how directly identifiable the data is and automatically resets to minimize the length of time it will be useful.  SWAN further minimizes risks by restricting the use of sensitive information associated with SWAN data. 

Right to be Forgotten. This SWAN dialog also allows people to exercise their Right to Be Forgotten.

No (unless the browser wipes cookies). The SWID has a standard lifespan that persists across browsing sessions, but people can reset it at any time.  Additionally, people can receive a temporary SWID by relying on the existing in-private/incognito function of their favourite browser.

The SWID is stored in a browser cookie file and thus works only for a single browser. People can choose to provide an optional email that can persist their preferences across additional browsers and devices they use. Receivers of this hashed email are restricted from re-identifying the individual associated with this pseudonymous identifier.

No technology can be built such that a motivated bad actor could not use it to harm others. For this reason, SWAN improves transparency and enables the creation of an accountable audit trail to provide non-repudiable evidence to hold bad actors accountable while ensuring we follow the rules of due process.

The entire supply chain, and a browser with permission to access the audit log, would know the parties involved. A browser with sufficient volume and opted in users who share the supply chain would also know the popularity of market participants. In order for a breach to have occurred a party will have to have committed a harm.

There is a strong incentive for them not to do so. Innocent breach due to an operational mistake will be quickly rectified and the eco-system informed. Deliberate breach will almost certainly result in the party going out of business as all other parties will cease to work with them. There is a big risk associated with deliberate breach. Given the availability of the SWAN audit data it is likely that with machine learning web browser vendors or other auditors could perform an audit function and show signs of possible breach.

Specifically, those conducting personalised marketing without permission.  SWAN will provide data to enable many new use cases which we find exciting. SWAN does not take anything away.

As long as there is free will in the world there will be bad actors doing bad things. SWAN.community’s approach is to help identify them rather than prohibit all acts. SWAN.community places equal emphasis on laws, economics, engineering and maths.

The user only provides their email and the four icon code to the User Interface Provider (UIP) commonly a CMP. The SWAN Operator will then return the hash of the email address using the four icons as the salt for the hash. SWAN.commnuity only ever provides pseudo anonymous identifiers. If a UIP used the email address for another purpose they would need to get separate permission for that.

No. SWAN.community requires minimum standards of audit, enforced by contract.

There might be different Model Terms for different jurisdictions or even different networks. That will be for the ecosystem to decide. At the moment we think it’s possible to combine most major laws into a general contract governed by contract law with the courts and laws of England and Wales as the fall back.

Yes. The vision behind General Privacy Control (GPC), of a simple privacy signal from people to organizations, was recently supported by the California Attorney General (https://twitter.com/AGBecerra/status/1354850321692934144?s=20). (https://theccpa.org/#1798.135(a)(6)

However, one of the challenges of GPC (and its forerunner Do Not Track) is that it does not mandate a clear definition as to what people are signalling and how they should expect to continue to interact with web properties that rely on interoperable data to provide them their online experience. In contrast, SWAN maintains this same simplicity of design, but adds plain language associated with the signal to ensure both people can signal a legal preference with clear meaning and that receivers have contractual obligations to comply with these signals. SWAN provides this clarity, and a cryptographic audit trail to confirm compliance via the Model Terms. SWAN enables the GPC vision.

Engineering

Yes. All the source code is licensed under the Apache License 2 on GitHub.

We use GitHub issues and Git for issue management and taking pull requests. If you'd like to take a lead on adding features, for example adding support for a particular programming language to make publisher adoption easier please feel free to advise the community via the GitHub issues system and then make a pull requests when you're ready. There are plenty of people ready to review your pull request.

The very first time the web browser is used with SWAN the User Interface Provider (often a CMP) will display a dialogue to capture SWAN's preference for personalised marketing and optionally an email address. This data will then be written to the SWAN Network and setup will be complete.

Both the initial request to retrieve the information and the subsequent write request will require multiple redirects to ensure the data is recorded across sufficient SWAN Operator nodes (internet domains).

Once SWAN preferences are recorded then people need not be bothered for 90 days, or if the browser wipes cookies.

As each web browser will have a home node associated with it most requests to fetch the information will be serviced by the home node in a single request. In this regard SWAN is almost as performant as a single well known domain but with redundancy and multiple operators.

Callers to SWAN can control the maximum number of nodes visited using the nodeCount parameter.

Publishers that use the SWAN data are required to provide a link to a User Interface Provider on every web page. This will typically be displayed in the footer of every web page.

Great question. No it doesn't. Only the simplest components of the internet and web are used.

JavaScript can be optionally used if the PostMessageOnComplete flag is set for an update or fetch storage operation. Rather than redirecting back to the return URL provided a window.postMessage JavaScript command will be used to signal to the parent window that the storage operation is complete and pass the encrypted result string for decrypting. 

The SWAN API end points are described in the API document on GitHub. There is also a reference implementation in the demo written in Go. If you'd like to get involved and write server side reference implementations for other languages like PHP, Java, Ruby, Scala, Python, RUST, .NET, Node, or anything else make a pull request.

Remember SWAN is not just about the engineering. It would be a good idea to review the Model Terms as well to understand how to use the SWAN data.

The SWAN API end points are described in the API document on GitHub. There is also a reference implementation in the demo written in Go. If you'd like to get involved and write server side reference implementations for other languages like PHP, Java, Ruby, Scala, Python, RUST, .NET, Node, or anything else make a pull request.

You'll need to use the decrypt-raw end point to get the raw data out of SWAN. This data can only be used for the purposes of providing the user interface and must never be used for any other purpose. If you want to get access to the SWAN data after it's been updated, then you make a fetch request. See the Model Terms explainer to understand how this works.

SWAN is dependent on the following IETF standard.

SWAN is also dependent on HTML and the meta element’s refresh attributes currently governed by WHATWG.

SWAN operates without requiring JavaScript.

Read more on GitHub to understand how law, economics, privacy and engineering differentiate SWAN from the so called "redirect trackers".

SWAN has been tested on many browsers by the community but is not yet ready for prime time. Bugs are to be expected. Please post issues with the demo on the https://github.com/swan-community/swan-demo-go repository. An extensive set of trials will be needed in August and September to iron out any specific browser issues.

Across the network we would envisage not more than 100 nodes with each storage transaction requiring 10% of the nodes. Each browser is assigned a home node based on some infrequently changing value such as it’s public IP address. In practice most requests to retrieve data are completed by only one node the current home node which will contain the most recent copy of the SWAN raw data. All requests are timestamped for a short period of time so they can’t be replayed. If the timestamp becomes invalid, then the browser is returned to the publisher.

SWAN Network requires specific quality levels to be maintained by participants. Modern hosting platforms provide near 100% uptime. The core SWAN service is a single self-contained binary. Other than configuration settings there is not central persistent storage. All persistent storage is within the web browser.