- Specific issue about cardinality and impact unlikability
- Analyzing privacy preserving ecosystems around protocol
- Unlinkability between client redemption and issuance isn't automatic
- Similar to other architecture docs
- Minor changes: token metadata and expiry
- Open issue: Number of issuers allowed in privacy pass ecosystem
- Unlikability rests upon redemptions: if succeeds, was a valid token
- Each issuer creates a distinct class token. Redeem multiple different issuers, anonymity set reduced to people who got all the tokens
- In some cases proxying via third parties, or publically doable
- Example: two issuers, three people. Charlie is the only one who got both tokens, poor him
- Worst case every issuer drops privacy one bit
- Independent of anything else (metadata, key rotation)
- Section 10 generic ecosystem has the exact equation
- metadata hurts more
- Get 17 issuers under reasonable assumptions
- Gets even smallers
- What if we reduce by restricting redemptions?
- Limit issuers client redeems with?
- Client can only redeem for very limited profile wider ecosystem has many, privacy moved to client held tokens
Open questions: How do clients decide, enforcing these contexts, application specific, what architecture guidance is required? Implementors and applications
Multi-context architectures for Privacy Pass (Steven Valdez, 10 min)
Currently all privacy assumes one client giant
- In HTTP top level sites have own context. Cross-context sharing heavily restricted. Mostly boundaries.
- Devices: context is application
- In global context issuers together build fingerprints with collaborating issuers
- Shared redemption contexts fragment issuers, reduces leakage
- Each redemption has privacy implications
- To get this right: strong boundaries, unjoinable, application speciific linkages
- Hard coded limits on issuers that get used
- Whether or not having a token any interaction has to count against context
- Reason: trying can dig out what tokens are available or not
- Can count redemptions, slightly different math. More complexity with metadata and other isser things
- Should write down vs let applications discove privacy math
- Don't want redemption stuck forever, if issuers can't be switched.
- Rotation is complex question
Open questions; protocol vs application, how detailed in the derivation, how much specified about context unlinkability, issuer stickiness.
Centralization Problem Statement (Mark McFadden, 10 min)
Motivation: Charter milestone. Comes from WG establishment, IABOPEN, plenary
- This draft ignores redemption contexts
- Potential privacy issues
- Problem statement and mitigations
- Will be happy to add it
- Fundamental issue: limit issuers to avoid client identifier about what they have
- Number of tokens at client restricted? Requires limiting at the client, harder than servers.
- Arch says max 4 for client to get from
- Traditional centralization issue: part of protocol that enforces it. Not network or economic
- Architectural, engineering, and deployment issues
- Much of this draft talks about what was in the arch draft.
- Mitigations (except redemption contexts) don't seem very attractive. Number of issuers vs privacy
Next steps: -01 after IETF
Open discussion on Issuer consolidation pressure (30 min)
Christian: Problem of anonymity and zero knowledge looks a lot like Oblivious DNS. DNS Oblivious solved with layers of servers. Client auth to first server and then changes tokens out.
- Chris Wood: Seems like privacy pass and obvious FO are very different. Anonymous authorization while ODOH and the like aren't about authorization but hiding client identity
- Christian: it's the split between client location and the server that's issuing that is common. Because identity is known can correlate, if we hide via second level, then client identity is hidden.
- Subodh: Problem could use more formal definition authorization context bound to attributes that might be known and then correlate from making multiple sources. Differential privacy ideas?
- Ben (no hats): Want to emphasize issuer cannot link information to redemption. Concern is number of issuers marking a client. Focus on K from Stevens presentation. In applications Ben's aware of goal is user is not a bot. Don't like formulation think it's useful shorthand. In that case a number of trusted issuers being small should be enough. If redemption context can only get one possible token. That math would say a million issuers. Would go a long way to addressing. Wondering if its more.
- Kirsty Paine: Issue forever, glad being solve. Anonymity set size, even 5000 is pretty difficult. Is this at enough? Fundamental issue that it might not give much privacy. Substantial piece of work. Not simple solution. Too difficult to resolve. Might be separate issue, and then merge in. Lots of solutions with variation. 5,000 arbitrary, but whole discussion.
- Ben (with hat): Chartered to describe risk and ramification and mitigations
- Watson: Weakest link makes you get through. Incentive to be small
- Steven: Sites will want their issuer, best signal. Not clear all can be swapped. K>1 likely
- Richard Barnes: Hard problem. Usual reaction is not work on them. Can we do this here? Huge amount of complexity by having very open interop, while most case very tight redemption issuance context. Even with that not central: Cookies specific to site, but still decentralized. Can avoid by tightness. Didn't see charter requirement for flexibility, am a bit of a tourist.
- Chris Wood: Could instantiate many ways. Core of protocol spec is basically unaffected. Do we want to change that such that protocol constrains decoupling issuing and redemption? If so how, if not higher level concern should talk about and document and maybe only focus on demployments with matching. What tangible thing to do to accept richard's proposal or not?
- Martin Thompson: Sounds tempting think about point Watson made and reminded of cases where Bot Detection run by third party. Token issued on other site maybe via iframe. Still one entity consuming. Framing seems a bit wrong. RP becomes issuer. Concern is with lock-in. Increased transfer between context. K=2 not that worse than K=1
- Chelsea Komlo: issuer cardinality via multiparty signature schemes. Have a draft. Transfers to issuers
- Kirsty Paine: Risk assessment listed with multiple design options. What would it include? Reasonable anonymity set.
- Richard; flexibility different from centralization. Comes up in application contexts