Re: [arch-d] Call for Comment: <draft-iab-privacy-partitioning-03> (Partitioning as an Architecture for Privacy)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Eliot,

Our focus of the document was to give examples in the context of IETF protocols. The examples you list are application layer examples or at least are not directly covered by IETF technology. So I’m actually not quite sure what I should take away from this for the document…?

Also you say in the beginning that the document is not quite ready yet for publishing, however, it hard for me to actually understand what you think is missing. Can you be a bit more concrete?

Mirja



> On 9. Oct 2023, at 09:52, Eliot Lear <[e-mail]> wrote:
> 
> Hi IAB,
> 
> If that was Martin's way of saying that you are on the right track but not quite there, then I agree ;-)  I think the document is delightful and well written, as far as it goes.  Congratulations on that part!
> 
> &TL;DR you should ground your work detailed examples.  I've provided several extreme ones below; beware the incentive models in play.  IMHO don't click the "publish" button quite yet.
> 
> Feel free to use these worked examples (or not, or your own), applying IETF building blocks and identifying missing parts to demonstrate how it might all fit together, and make the document more relatable and thus more consumable to the reader.  You'll need to blow those blocks out.  That, my friends, is my view of what an architecture means ;-)  Such examples can demonstrate the strengths and weaknesses you mention in Sections 4.2 and 5 (as well as others). 
> 
> Here are the examples.  A brief commentary and one nit follows below.
> 
> Goal #1: I Buy a book from Big Book And Other Company (BBAOC) without having to reveal any particulars about yourself.
> 
> This is one of my favorite thought experiments, involving use of tokens for postal addresses, and some sort of blinded payment protocol.  For simplification purposes, let's assume a single postal jurisdiction.  Let's now follow the flow:
> 
> I get a token from my postal company.
> I go to BBAOC web site, presumably using oblivious HTTP and DoH.
> I select a book.
> I now somehow send my postal token to BBAOC.
> BBAOC must now transmit that token to their postal provider, and postal provider must return a shipping + tax value.
> BBAOC contacts payment service with some information I provide, and I am now charged the cost book + shipping and tax; a payment service transaction id is generated.  The transaction is recorded, and a BBAOC transaction id is returned.
> BBAOC prints a label with my token as a QR code (let's say) and delivers it to the post.
> Post as IdP is able to actually decode the token, and ships package to me.
> I receive the book with a copy of the BBAOC transaction id.
> I read the book.
> In the above example, BBAOC does not know who I am, and does not know my address.  I'll note also that BBAOC cannot provide me status information about the shipment unless I provide some identity such as an email address, but that can be somewhat anonymized, as Apple has done.  No login required.
> 
> Next let's add several variants.
> 
> Goal #2: Return book
> 
> Between Steps 9 and 10 from above, I discover that I have received the wrong book.  
> 
> I must now return to BBAOC's web site and generate a label.  
> I use the BBAOC transaction id generated in step 6 above as an index.  
> I enter that, and am able to generate a label.  That too might be a QR code that contains shipping and and perhaps transaction info, perhaps signed.
> I go to the post office and deliver the package, and get a receipt with a postal transaction code bound to QR code.
> Post scans label and ships.
> BBAOC receives package and then contacts payment service with the financial service transaction id generated in step 6 above, saying “reverse it”.
> Payment service issues confirmation, and this too is recorded and a new transaction id generated.
> BBAOC informs me of both.
> I get my money, BBAOC gets the book back.
> Goal #3: Buy a surprise gift for a friend
> 
> The flow from #1 may be used, with the following changes:
> 
> I must retrieve a token from the recipient, which means at least the first gift cannot be a surprise.  But let's say that this happens.
> Now I provide my friend's token instead of my own.
> The process flows as before.
> This addresses a case that repeats itself regularly.  Many years ago, I asked a friend for his address, I drop shipped a book to him, and he was infuriated that his information now rested with the book company.  I did thoughtlessly violate his privacy, even in the act of trying to provide him a gift.
> 
> All of this could be made to work.  A few notes:
> 
> The 3rd example might lead people to believe that privacy advocates are sometimes party poopers ;-)
> If BBAOC offers their own shipping, the postal privacy benefits are entirely nullified.
> If I provide my friend's postal token to others, I have violated their privacy.  I must have permission.
> If BBAOC offers their own payment service, the financial privacy benefits are entirely nullified.
> If BBAOC offers a platform to sellers, then it stands as a middle man in the transaction, must provide the postal token, and presumably will handle the financial matters; but the flow largely holds.
> For electronic services/commerce (e.g., no physical product or service), this flow would dramatically simplify, but for one aspect: taxes.
> There are a great many UX issues in these examples.  Entering tokens and transaction ids?  Bah.  
> I might want BBAOC to keep a search history because I derive value from that.  The key is that it be my choice not theirs, right?  A reasonable question to address: what is the privacy cost of that?
> There is no incentive for BBAOC to employ this model – unless they offer postal and financial service.
> That last point is probably worth a few words.  In particular, if they really are the post, you may be unwittingly advocating more centralization, because the blinding of some may mean aggregation by others.  Those tokens come from somewhere.  This, by the way, is similar, but not identical, to what Google has been accused of doing[1].  @mnot might wish to comment.  IMHO It's important to surface this point so that we understand the societal limits and risks of an architecture.
> 
> Relaxing my constraint about a single postal jurisdiction for a moment, it's probably worth noting that the UPU[2] might need to do some standardization to make all of this work.  What are their incentives?
> 
> As I'm sure many of you know, EKR has spent a good amount of time writing up challenges with age verification[3], which would be another apt example.  He would also do a good job in poking holes in my examples ;-)
> 
> Another example to play out would be how a healthcare provider might use this model without adversely impacting the patient.
> 
> Finally one nit: I find Section 6 point 1 to be unsupported to the point of naivete in an adversarial model.  But my assertion is just as unsupported.  Rather than us spending many emails going round and round on that point, might I suggest that you note that this is an issue to be considered at another time?
> 
> Eliot
> 
> [1] https://www.theverge.com/2023/8/7/23823878/google-privacy-tracking-incognito-mode-lawsuit-summary-judgment-denied
> [2] https://www.upu.int/en/Home
> [3] https://educatedguesswork.org/posts/uk-age-verification/
> 
> 
> On 09.10.2023 02:19, Martin Thomson wrote:
>> This document feels incomplete.  I'll give a few examples of applications of the general concept that aren't covered.
>> 
>> Separating identity from the right to communicate is a major concept that is not as fully explored as it could be.
>> 
>> This is something that the draft does discuss in a way, because it talks about using intermediaries to shield the identity of entities that wish to initiate communication.
>> 
>> The entire class of use for pseudonymous identifiers isn't really given a solid treatment.  I work with people who provide email aliases for privacy purposes.  There, the underlying concept is that an email address typically serves two distinct functions: a) an identifier, and b) authorization to communicate.
>> 
>> When creating temporary email addresses, especially when these are unique for each context, we break the identification part (a).  We give the recipient the means to communicate with us, but deny them the means to identify.  Identification means correlation across multiple contexts.  (As an aside, that's a failing in RFC 6973, which treats identification and correlation as distinct threats rather than facets of the same and distinct only in degree.)
>> 
>> A contextually-bound pseudonymous identifier provides no correlating power. Again, this relies on having intermediaries that can be trusted not to collude and reveal the true identity, so I believe that this qualifies as a partitioning.
>> 
>> The same basic idea also underpins Web Push (RFC 8030).  Websites are given the means to send push messages to user agents, but are denied the means of identification.  Here, the privacy guarantees are stronger than email because the intermediary does not need to be entrusted with viewing the message contents.  End-to-end protected email is possible, but email comes with very different expectations.
>> 
>> I believe that this identity separation concept is also a property that is inherent to ICN architectures, but I'm not as qualified to comment on that as others, including some IAB members.  Similarly, I believe that it would be possible to more fully capitalize on randomized IPv6 ULAs (RFC 4941), but there are folks on the IAB better positioned to handle that as well.
>> 
>> Finally, it is maybe not in scope, but I wonder how the authors perceive the relation between this work and contextual integrity.  It seems like maybe this is a foundational principle that is implied throughout, perhaps along with other principles.  However, it's not really clear which aspects of privacy are potentially responsive to the types of partitioning that are discussed.  There is missed opportunity here, I think. Just looking at specific privacy risks (those listed in Section 5 of RFC 6973 are a good start), it is obvious how partitioning helps (or doesn't) with some, but not all.
>> 
>> Cheers,
>> Martin
>> 
>> On Sat, Oct 7, 2023, at 04:50, IAB Executive Administrative Manager wrote:
>>> This is an announcement of an IETF-wide Call for Comment on 
>>> draft-iab-privacy-partitioning-03.
>>> 
>>> The document is being considered for publication as an Informational 
>>> RFC within the IAB stream and is available for inspection at: 
>>> <https://datatracker.ietf.org/doc/draft-iab-privacy-partitioning/> <https://datatracker.ietf.org/doc/draft-iab-privacy-partitioning/>
>>> 
>>> The Call for Comment will last until 2023-11-03. Please send comments 
>>> to [e-mail] <mailto:[e-mail]> and [e-mail] <mailto:[e-mail]>.
>>> 
>>> Abstract
>>> 
>>>   This document describes the principle of privacy partitioning, which
>>>   selectively spreads data and communication across multiple parties as
>>>   a means to improve privacy by separating user identity from user
>>>   data.  This document describes emerging patterns in protocols to
>>>   partition what data and metadata is revealed through protocol
>>>   interactions, provides common terminology, and discusses how to
>>>   analyze such models.
>>> 
>>> _______________________________________________
>>> Architecture-discuss mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> _______________________________________________
>> Architecture-discuss mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss