From 09efbbbd801444db73d1a4620cb0568a641a4689 Mon Sep 17 00:00:00 2001 From: Nick Doty Date: Fri, 17 Mar 2023 18:27:45 -0400 Subject: [PATCH 01/16] start a sources doc to collect some references --- principles/sources.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 principles/sources.md diff --git a/principles/sources.md b/principles/sources.md new file mode 100644 index 0000000..70421ac --- /dev/null +++ b/principles/sources.md @@ -0,0 +1,19 @@ +Some sources to consider in documenting advertising-specific privacy principles: + +[Privacy Principles](https://www.w3.org/TR/privacy-principles/), Draft Note from the W3C TAG, prepared by the Web Privacy Principles Task Force + +[PATCG Security Considerations / Threat Model](https://github.com/patcg/docs-and-reports/tree/main/threat-model) + +[User considerations for private measurement](https://gitlab.com/pitg/private-measurement-user-considerations/-/blob/main/private-measurement-user-considerations.md), some questions/topics regarding private measurement, maintained by Nick Doty + +--- + +Some browser vendors have published policies regarding tracking or privacy models: + +[A Potential Privacy Model for the Web](https://github.com/michaelkleber/privacy-model): Sharding web identity, from Michael Kleber + +[Tor Browser Privacy Requirements](https://2019.www.torproject.org/projects/torbrowser/design/#privacy), different unlinkability criteria + +[Mozilla Anti tracking policy](https://wiki.mozilla.org/Security/Anti_tracking_policy) + +[WebKit Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) From d977914bdb3757815baed338585496db7653306f Mon Sep 17 00:00:00 2001 From: Nick Doty Date: Mon, 20 Mar 2023 17:28:18 -0400 Subject: [PATCH 02/16] link to Advertising Use Cases User Needs section, from IWABG --- principles/sources.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/principles/sources.md b/principles/sources.md index 70421ac..a8f58bf 100644 --- a/principles/sources.md +++ b/principles/sources.md @@ -6,6 +6,8 @@ Some sources to consider in documenting advertising-specific privacy principles: [User considerations for private measurement](https://gitlab.com/pitg/private-measurement-user-considerations/-/blob/main/private-measurement-user-considerations.md), some questions/topics regarding private measurement, maintained by Nick Doty +[Advertising Use Cases | User Needs](https://github.com/w3c/web-advertising/blob/main/support_for_advertising_use_cases.md#user-needs-1), from Improving Web Advertising Business Group + --- Some browser vendors have published policies regarding tracking or privacy models: From 5df9a9d0aca3270e7b2ac5503e1d61362129c03f Mon Sep 17 00:00:00 2001 From: Nick Doty Date: Thu, 23 Mar 2023 00:20:50 -0400 Subject: [PATCH 03/16] summary doc to discuss at patcg meeting --- principles/summary_202303.md | 68 ++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 principles/summary_202303.md diff --git a/principles/summary_202303.md b/principles/summary_202303.md new file mode 100644 index 0000000..30f7b28 --- /dev/null +++ b/principles/summary_202303.md @@ -0,0 +1,68 @@ +# private ad tech privacy principles summary + +## Areas to cover + +* consent +* control +* profiling +* distress & intrusion +* relevance +* reporting and context † +* transparency +* security +* trust model +* explainability / comprehensibility +* competition † +* inferences +* identifiers +* accountability † +* + +### Some Privacy Principles (W3C TAG Draft Note) to elaborate on + +#### context / identity + +> A user agent should help its user present the identity they want in each context they are in. + +#### minimization + +> Sites, user agents, and other actors should minimize the amount of personal data they transfer between actors on the Web. + +> Web APIs should be designed to minimize the amount of data that sites need to request to carry out their users' goals and provide granularity and user controls over personal data that is communicated to sites. + +> In maintaining duties of protection, discretion and loyalty, user agents should share data only when it either is needed to satisfy a user's immediate goals or aligns with the user's wishes and interests. + +#### general preferences + +> Sites and user agents should seek to understand and respect people's goals and preferences about use of data about them. + +> Specifications that define functionality for telemetry and analytics should explicitly note the telemetry and analytics use to facilitate modal or general user choices. + +#### intrusion + +> User agents and other actors should take steps to ensure that their user is not exposed to unwanted information. + +> A user agent should help users control notifications and other interruptive UI that can be used to manipulate behavior. + +> Web sites should use notifications only for information that their users have specifically requested. + +## How this fits in + +* Helping to guide and evaluate private advertising technology proposals + +> This document elaborates on the W3C TAG's Privacy Principles [Privacy-Principles]. The latter document is intended to describe principles of privacy that apply across the Web, and therefore leaves the door open to a variety of approaches so that different use cases can be approached with some flexibility. This document is therefore more specific in detailing how the Web's broader privacy principles are to be understood in an advertising context. + +* Not every topic should or could be covered here! + +* [some source documents](https://github.com/npdoty/patcg-docs/blob/principles-sources/principles/sources.md) + +## What's still missing? + +* ... +* + +## How to contribute + +* github issues +* PRs on documents +* biweekly check-in calls? \ No newline at end of file From f31101289295e9dbe020467ceb62b2bd417b4edd Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Tue, 11 Apr 2023 09:56:25 -0500 Subject: [PATCH 04/16] Add links to ARA's cross_device.md proposal --- design-dimensions/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/design-dimensions/README.md b/design-dimensions/README.md index daf1574..c1f7d6f 100644 --- a/design-dimensions/README.md +++ b/design-dimensions/README.md @@ -40,7 +40,7 @@ Additionally, some of these dimensions are influenced entirely by some of the ma | Dimension | Description | Where do existing proposals stand? | |----------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Scope of privacy budgeting | If applicable, the axes along which privacy budgeting applies: time epoch, site, campaign, delegate | PCM: Per device/source-destination site pair. Limited in rate by reporting delay and user interaction.
A-ARA: Per epoch, source ⇔ destination site pair, device.
E-ARA: Per epoch, source ⇔ destination site pair, device
IPA: Per week/epoch, per site, per match key.
SKAN: Per device / source app | -| Cross device & device graph | Can events on device A be linked to events on device B? How is the device graph maintained and used? | PCM: No
E-ARA: Only with cross-device, same-vendor sync (w/ early stage proposal)
A-ARA: Only with cross-device, same-vendor sync (w/ early stage proposal)
IPA: Yes. Graph is maintained by sites setting
SKAN: No | +| Cross device & device graph | Can events on device A be linked to events on device B? How is the device graph maintained and used? | PCM: No
E-ARA: Only with cross-device, same-vendor sync (w/ [archived proposal](https://github.com/WICG/attribution-reporting-api/blob/main/archive/cross_device.md))
A-ARA: Only with cross-device, same-vendor sync (w/ [archived proposal](https://github.com/WICG/attribution-reporting-api/blob/main/archive/cross_device.md))
IPA: Yes. Graph is maintained by sites setting
SKAN: No | | Same device cross environment | Can events on device A be linked to events on device A across different applications? | PCM: App → Web/SFSafariViewController, Web → App
E-ARA: Partial w/ platform support
A-ARA: Partial w/ platform support
IPA: Yes
SKAN: No | | Security guarantees of the agg infra | What kind of aggregation service would we want to support? What security properties would it need it have? | PCM: N/A
E-ARA: N/A
A-ARA: TEE w/ multi-party key holder (previously two-party MPC)
IPA: three-party MPC
SKAN: Trusted platform-owned servers (app store) | | Stance on third party measurement providers / delegation | Can multiple third parties measure the same events ? How are they restricted? Can third party code even invoke the API? | PCM: No, disallowed in iframes, etc.
E-ARA: Each pair of source ⇔ destination sites can delegate to a limited number of delegates.
A-ARA: Each pair of source ⇔ destination sites can delegate to a limited number of delegates.
IPA: Sites can apportion their budget across multiple delegates.
SKAN: No | From e02330cfa16deb773ae6a6ecb3fa9a1d6b9bb33d Mon Sep 17 00:00:00 2001 From: benjaminsavage <52456851+benjaminsavage@users.noreply.github.com> Date: Wed, 14 Jun 2023 17:12:21 +0100 Subject: [PATCH 05/16] Consensus write-up on "Optimization" Use Case In our last meeting we reached general agreement that the group wants to support the "Optimization" use case. This is a write-up of that agreement. --- measurement-use-cases.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 measurement-use-cases.md diff --git a/measurement-use-cases.md b/measurement-use-cases.md new file mode 100644 index 0000000..69e6a8e --- /dev/null +++ b/measurement-use-cases.md @@ -0,0 +1,24 @@ +# Measurement Use Cases + +The group is currently working on developing a privacy preserving ad measurement system. + +There is general agreement that we want such a system to satisfy the following use cases: + +# Advertiser Reporting + +TODO: fill this in + +# Optimization + +Ad selection systems often attempt to estimate the probability that if an ad is shown, it will lead to a conversion event. +More sophisticated systems may also attempt to predict conversion values / counts / categories. + +The information produced by "Advertiser Reporting" is already sufficient to make naive predictions (i.e. just estimate the average conversion rate for all users). +But there is interest in the group to intentionally design the private measurement system to do better than this. + +There is general agreement in the group that: + +1. This is a use case that we explicitly want to support +2. Within our agreed privacy bounds we would like to design outputs which provide as much utility as possible for this use case +3. We are flexible on the mechanism to support this, and potentially envision a private measurement system which supports multiple modalities intended to support this use case. + From f99599f16f5e61881ccc4003701c0713363c55c7 Mon Sep 17 00:00:00 2001 From: Michael Kleber Date: Thu, 15 Jun 2023 19:34:09 -0400 Subject: [PATCH 06/16] Update Dimensions-with-General-Agreement.md Draft consensus on "Can [TEE / MPC] be used as a private computation configuration?" --- design-dimensions/Dimensions-with-General-Agreement.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/design-dimensions/Dimensions-with-General-Agreement.md b/design-dimensions/Dimensions-with-General-Agreement.md index 8c84643..25f922b 100644 --- a/design-dimensions/Dimensions-with-General-Agreement.md +++ b/design-dimensions/Dimensions-with-General-Agreement.md @@ -14,6 +14,10 @@ This document serves to capture the dimensions with general agreement from the C The community group has reached general agreement that the _Private Measurement Technical Specification MVP_ may include server processing dependencies, however any server architecture must achieve both a high level of security (which the editors will align with the ongoing [Threat Model](../threat-model) work) as well as ability to explain the privacy and security properties of the system to end users. +More generally, the community group is willing to engage with proposals that use different mechanisms to protect data while it being processed on servers, explicitly including both Multi-Party Computation (MPC) and Trusted Execution Environment (TEE) server-side components. These cannot be treated as "silver bullets", but rather as tools that act as individual components in larger designs, which must in turn mitigate the vulnerabilities of their components. + +If the _Private Measurement Technical Specification MVP_ supports both an MPC-based and a TEE-based implementation, then every effort should be made to design them to be cross-compatible, to minimize the engineering burden and maximize utility for API users who choose to engage with both implementations. + ## Privacy defined at least by Differential Privacy From 687b8c48a023d3f7d3ed9e41901cc9e1e0f8f890 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Fri, 16 Jun 2023 04:44:59 -0500 Subject: [PATCH 07/16] Add cross-environment section to the areas of general agreement --- design-dimensions/Dimensions-with-General-Agreement.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/design-dimensions/Dimensions-with-General-Agreement.md b/design-dimensions/Dimensions-with-General-Agreement.md index 8c84643..5273900 100644 --- a/design-dimensions/Dimensions-with-General-Agreement.md +++ b/design-dimensions/Dimensions-with-General-Agreement.md @@ -41,3 +41,11 @@ In order to be useful, measurement systems need to produce a continuous release The community group has reached general agreement that the _Private Measurement Technical Specification MVP_ should _at least_ include a time or interaction component to the budget scope. That is, as the user browses the web and interacts with sites more, we would expect that the private measurement system will allow more information about that user to be disclosed. It is worth noting that, at least among existing differential privacy deployments, a time dimension in the privacy unit is very common. See https://desfontain.es/privacy/real-world-differential-privacy.html for a list of examples here. + +## Attribution across environments + +Use-cases like cross-device attribution, cross-app-and-web attribution, and others rely on the capability of the system to measure _joined events_ emitted across different computing environments. The group has reached a general agreement that the _Private Measurement Technical Specification MVP_ can support these kinds of data joins in its design. In particular: +- It may be possible to measure joined events across different applications on a single device +- It may be possible to measure joined events across applications on different devices, owned or used by the same person + +Note: the precise details of _how_ these events are joined and measured needs to be separately agreed upon. The current consensus only documents an agreement that joins across computing environments are not inherently disallowed. From 5dbf0e8587b30fdd37f58901577d7fd8787ccc5c Mon Sep 17 00:00:00 2001 From: Michael Kleber Date: Fri, 16 Jun 2023 06:17:44 -0400 Subject: [PATCH 08/16] Update design-dimensions/Dimensions-with-General-Agreement.md Co-authored-by: Martin Thomson --- design-dimensions/Dimensions-with-General-Agreement.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/design-dimensions/Dimensions-with-General-Agreement.md b/design-dimensions/Dimensions-with-General-Agreement.md index 25f922b..08a8767 100644 --- a/design-dimensions/Dimensions-with-General-Agreement.md +++ b/design-dimensions/Dimensions-with-General-Agreement.md @@ -14,7 +14,9 @@ This document serves to capture the dimensions with general agreement from the C The community group has reached general agreement that the _Private Measurement Technical Specification MVP_ may include server processing dependencies, however any server architecture must achieve both a high level of security (which the editors will align with the ongoing [Threat Model](../threat-model) work) as well as ability to explain the privacy and security properties of the system to end users. -More generally, the community group is willing to engage with proposals that use different mechanisms to protect data while it being processed on servers, explicitly including both Multi-Party Computation (MPC) and Trusted Execution Environment (TEE) server-side components. These cannot be treated as "silver bullets", but rather as tools that act as individual components in larger designs, which must in turn mitigate the vulnerabilities of their components. +More generally, the community group is willing to engage with proposals that use different mechanisms to protect data while it being processed on servers, explicitly including both Multi-Party Computation (MPC) and Trusted Execution Environment (TEE) server-side components. +These technologies each have shortcomings, but they can form part of a larger system of protections that includes mitigations for the different vulnerabilities of its constituent components. +The group could consider both technical and procedural mitigations. If the _Private Measurement Technical Specification MVP_ supports both an MPC-based and a TEE-based implementation, then every effort should be made to design them to be cross-compatible, to minimize the engineering burden and maximize utility for API users who choose to engage with both implementations. From ebfad81d7be1881bc652ac92e915cee2c0fd1f51 Mon Sep 17 00:00:00 2001 From: Charlie Harrison Date: Fri, 16 Jun 2023 12:06:28 +0100 Subject: [PATCH 09/16] Update design-dimensions/Dimensions-with-General-Agreement.md Co-authored-by: Michael Kleber --- design-dimensions/Dimensions-with-General-Agreement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/design-dimensions/Dimensions-with-General-Agreement.md b/design-dimensions/Dimensions-with-General-Agreement.md index 5273900..2d3f672 100644 --- a/design-dimensions/Dimensions-with-General-Agreement.md +++ b/design-dimensions/Dimensions-with-General-Agreement.md @@ -48,4 +48,4 @@ Use-cases like cross-device attribution, cross-app-and-web attribution, and othe - It may be possible to measure joined events across different applications on a single device - It may be possible to measure joined events across applications on different devices, owned or used by the same person -Note: the precise details of _how_ these events are joined and measured needs to be separately agreed upon. The current consensus only documents an agreement that joins across computing environments are not inherently disallowed. +Note: the precise details of _how_ these events are joined and measured needs to be separately agreed upon. The current consensus documents an agreement that the group is open to designs that support joins across environments. From ec19d5bbf684bd051225a0b735a6577fbcd2bb59 Mon Sep 17 00:00:00 2001 From: benjaminsavage <52456851+benjaminsavage@users.noreply.github.com> Date: Mon, 19 Jun 2023 09:38:46 +0100 Subject: [PATCH 10/16] Consensus on server-side data join At the last face-to-face PAT-CG call, we discussed this design dimension: the location of data join (between source and trigger events). There was consensus that the group was potentially open to data join happening server-side, so long as the system was able to achieve our desired privacy and security goals. --- design-dimensions/Dimensions-with-General-Agreement.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/design-dimensions/Dimensions-with-General-Agreement.md b/design-dimensions/Dimensions-with-General-Agreement.md index 8c84643..e285676 100644 --- a/design-dimensions/Dimensions-with-General-Agreement.md +++ b/design-dimensions/Dimensions-with-General-Agreement.md @@ -14,6 +14,10 @@ This document serves to capture the dimensions with general agreement from the C The community group has reached general agreement that the _Private Measurement Technical Specification MVP_ may include server processing dependencies, however any server architecture must achieve both a high level of security (which the editors will align with the ongoing [Threat Model](../threat-model) work) as well as ability to explain the privacy and security properties of the system to end users. +### Location of Data Join + +The community group has reached general agreement that data join could potentially occur off device within a some type of server side architecture. +This is conditional on having adequate protections for any data that leaves a device, in line with our security and privacy goals. ## Privacy defined at least by Differential Privacy From 30e934f941d7a86ee052547dfcc199078fcd9e1f Mon Sep 17 00:00:00 2001 From: benjaminsavage <52456851+benjaminsavage@users.noreply.github.com> Date: Mon, 10 Jul 2023 07:40:49 +0000 Subject: [PATCH 11/16] Adding preface about what data-join refers to. --- design-dimensions/Dimensions-with-General-Agreement.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/design-dimensions/Dimensions-with-General-Agreement.md b/design-dimensions/Dimensions-with-General-Agreement.md index e285676..f542089 100644 --- a/design-dimensions/Dimensions-with-General-Agreement.md +++ b/design-dimensions/Dimensions-with-General-Agreement.md @@ -16,7 +16,7 @@ The community group has reached general agreement that the _Private Measurement ### Location of Data Join -The community group has reached general agreement that data join could potentially occur off device within a some type of server side architecture. +Attribution requires joining data from the site of an impression (source) and the site of a conversion (trigger). The community group has reached general agreement that data join could potentially occur off device within a some type of server side architecture. This is conditional on having adequate protections for any data that leaves a device, in line with our security and privacy goals. ## Privacy defined at least by Differential Privacy From b8c96147202aaf041d7377f9c87071319b047cf7 Mon Sep 17 00:00:00 2001 From: Nick Doty Date: Fri, 8 Sep 2023 16:56:19 -0400 Subject: [PATCH 12/16] capturing notes, potential sources or recommended links, ideas and topics to cover these are primarily notes from 2023-03 meeting and contemporaneous discussion --- principles/sources.md | 32 ++++++++++++++++++++++++ principles/summary_202303.md | 48 +++++++++++++++++++++++++++++++++++- 2 files changed, 79 insertions(+), 1 deletion(-) diff --git a/principles/sources.md b/principles/sources.md index a8f58bf..a26257b 100644 --- a/principles/sources.md +++ b/principles/sources.md @@ -19,3 +19,35 @@ Some browser vendors have published policies regarding tracking or privacy model [Mozilla Anti tracking policy](https://wiki.mozilla.org/Security/Anti_tracking_policy) [WebKit Tracking Prevention Policy](https://webkit.org/tracking-prevention-policy/) + +---- + +Other recommended links, from PATCG discussion: + +https://www.nist.gov/privacy-framework +https://almanac.httparchive.org/en/2022/privacy +https://www.w3.org/wiki/Privacy/Privacy_Considerations +https://darobin.github.io/pup/ +https://www.w3.org/TR/design-principles/ +https://www.w3.org/TR/fingerprinting-guidance/ +https://www.w3.org/blog/2019/06/privacy-anti-patterns-in-standards/ +https://www.rfc-editor.org/rfc/rfc8890.html +https://datatracker.ietf.org/doc/html/rfc7258 + +--- + +Legislation, regulation and governmental principles in different jurisdictions may also be relevant inputs for potential areas to look at, although they don't specifically direct our global standards work: + +[EU Digital Services Act](https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/digital-services-act-ensuring-safe-and-accountable-online-environment_en) includes restrictions on targeting online advertising and requirements for transparency and control + +[EU General Data Protection Regulation](https://commission.europa.eu/law/law-topic/data-protection/reform/rules-business-and-organisations_en) includes principles applying to personal data processed by an organization + +[OECD Guidelines Governing The Protection of Privacy and Transborder Flows of Personal Data](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0188) includes principles + +--- + +Some advertising industry self-regulatory programs may have relevant advertising-specific principles: + +[DAA Self-Regulatory Principles](https://digitaladvertisingalliance.org/principles) includes self-regulatory principles for online behavioral advertising (2009), and applications to some other categories + +[NAI Code of Conduct](https://thenai.org/wp-content/uploads/2021/07/nai_code2020.pdf) includes self-regulatory principles for ad targeting and delivery \ No newline at end of file diff --git a/principles/summary_202303.md b/principles/summary_202303.md index 30f7b28..aa8dad8 100644 --- a/principles/summary_202303.md +++ b/principles/summary_202303.md @@ -65,4 +65,50 @@ * github issues * PRs on documents -* biweekly check-in calls? \ No newline at end of file +* biweekly check-in calls? + +--- + +Suggested topics for principles: + +continuous release of information over time + +whether consent plays into that + +collusion and what is trusted + +aggregation for measurement + +minimize the cross-context data about any user when providing measurement data + +limit the ability of sites to perform cross-context recognition + +separate the context from the user + +privacy definitions (information-theoretic, differential privacy) + + +-- + +Some notes on how PATCG would like principles documentation to work, from March 2023 meeting: + +explain how advertising-related topics may be aligned with user interests, or be an area where a user could have a general preference + shivan: shouldn't be a trade-off or discuss that in *this* doc + martin: explaining to users and others why we are doing what we are doing + why, and how we approached the problem + +aram: less privacy principles, and more our principles as a group about how to deal with proposals. like what tradeoffs we can make and why. what makes a healthy web and a functional user experience across the web, how that interacts with how people understand their privacy. + +mt: we ultimately want here is for the people working on the document to say "we think that we have identified a principle based on our engagement with $proposal, we'd like to discuss how we refine and capture that principle so that we can apply it to other work in the group" + +regular checkin with the patcg, and specific to the technology/specifications under development + +where advertising fits into the priority of constituencies + +james aylett: state that trade-off or compromise is going to be necessary, but don't make the trade-offs or balance itself because that's specific to a proposal. risk management in individual proposals. + +well-lit path to mitigate the demand for covert tracking; make it possible to implement stronger mitigations + +charlie: editorial eye towards what belongs or not. maybe collect/save for later topics that could come up but aren't very specific to current proposals in patcg/individual drafts. specific criteria for inclusion. + +charlie: diff view or where we want to refine more general TAG principles From e1ca03f5080d324f88254f2bd877cf4ed6aa4b1c Mon Sep 17 00:00:00 2001 From: Erik Taubeneck Date: Mon, 23 Jan 2023 15:35:18 -0800 Subject: [PATCH 13/16] fix unclosed subscript tag --- threat-model/readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/threat-model/readme.md b/threat-model/readme.md index d629fe6..0fb9a49 100644 --- a/threat-model/readme.md +++ b/threat-model/readme.md @@ -319,7 +319,7 @@ There are currently two proposed constructions of a private computation environm Multi-party computation is a cryptographic protocol in which distinct parties can collectively operate on data which remains oblivious to any individual party throughout the computation, but allows for joint evaluation of a predefined function. -These protocols typically work with data which is _secret shared_. For example, a three way _additive_ secret share of a value v = s1 + s2 + s3 can be constructed by generating two random values for s1 and s2, and then computing s3 = v - s1 - s2. At this point, each value si individually appears random, and thus v remains oblivious as long as no single entity learns all values of si. A similar secret sharing schemes uses XOR in place of addition; alternatively, [Shamir's secret sharing](https://web.mit.edu/6.857/OldStuff/Fall03/ref/Shamir-HowToShareASecret.pdf) uses polynomial interpolation. +These protocols typically work with data which is _secret shared_. For example, a three way _additive_ secret share of a value v = s1 + s2 + s3 can be constructed by generating two random values for s1 and s2, and then computing s3 = v - s1 - s2. At this point, each value si individually appears random, and thus v remains oblivious as long as no single entity learns all values of si. A similar secret sharing schemes uses XOR in place of addition; alternatively, [Shamir's secret sharing](https://web.mit.edu/6.857/OldStuff/Fall03/ref/Shamir-HowToShareASecret.pdf) uses polynomial interpolation. In terms of our threat model, MPC uses a helper party network composed of aggregators and we assume that an attacker can control some subset of those aggregators. That exact threshold may be different for a given proposal, for example, we may assume that an attacker can only control one out of three aggregators. This would enable, in cryptographic terms, a _maliciously secure_, honest two out of three majority MPC, where the input data remains oblivious even in the fact of an attacker who controls one of the three aggregators and deviates from the protocol. The protocol would always detect this attacker, and typically aborts the computation. From 88d63cc266287a49890ae106c6484c0a9a99410d Mon Sep 17 00:00:00 2001 From: chaals Date: Thu, 22 Sep 2022 20:52:21 +1000 Subject: [PATCH 14/16] Update README.md link the threat model document (directory, because the naming scheme suggests that a specific link might get stale :( ) --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 1140b84..ed2e0a4 100644 --- a/README.md +++ b/README.md @@ -7,6 +7,7 @@ Repository for documents and reports generated by this community group. Please n A list of the current documents and reports follows: [Private Ad Technologies Principles](https://patcg.github.io/docs-and-reports/principles/) +[Threat Model](https://github.com/patcg/docs-and-reports/tree/main/threat-model) ## Work Process From 2b5ffc9d5ffc1ef1ff08c75887279930c45601da Mon Sep 17 00:00:00 2001 From: Lukasz Olejnik Date: Sat, 28 May 2022 07:22:55 +0200 Subject: [PATCH 15/16] Adding myself --- principles/index.html | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/principles/index.html b/principles/index.html index 96d9802..c558109 100644 --- a/principles/index.html +++ b/principles/index.html @@ -15,6 +15,13 @@ companyURL: 'https://nytimes.com/', url: 'https://berjon.com/', w3cid: 34327, + }, + { + name: 'Lukasz Olejnik', + company: 'Independent researcher (Invited Expert)', + companyURL: 'https://lukaszolejnik.com.com/', + url: 'https://lukaszolejnik.com/', + w3cid: 82432, } ], github: 'patcg/docs-and-reports', From 1d7df4c677d78ccb27598c5cbd861740df576e26 Mon Sep 17 00:00:00 2001 From: Erik Taubeneck Date: Mon, 11 Sep 2023 06:12:36 -0700 Subject: [PATCH 16/16] Update README.md change docs to a list --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index ed2e0a4..18018ae 100644 --- a/README.md +++ b/README.md @@ -6,8 +6,8 @@ Repository for documents and reports generated by this community group. Please n A list of the current documents and reports follows: -[Private Ad Technologies Principles](https://patcg.github.io/docs-and-reports/principles/) -[Threat Model](https://github.com/patcg/docs-and-reports/tree/main/threat-model) +* [Private Ad Technologies Principles](https://patcg.github.io/docs-and-reports/principles/) +* [Threat Model](https://github.com/patcg/docs-and-reports/tree/main/threat-model) ## Work Process