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

[Eliot Lear <[e-mail]>]

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:

 1. I get a token from my postal company.
 2. I go to BBAOC web site, presumably using oblivious HTTP and DoH.
 3. I select a book.
 4. I now somehow send my postal token to BBAOC.
 5. BBAOC must now transmit that token to their postal provider, and
    postal provider must return a shipping + tax value.
 6. 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.
 7. BBAOC prints a label with my token as a QR code (let's say) and
    delivers it to the post.
 8. Post as IdP is able to actually decode the token, and ships package
    to me.
 9. I receive the book with a copy of the BBAOC transaction id.
10. 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.

 1. I must now return to BBAOC's web site and generate a label.
 2. I use the BBAOC transaction id generated in step 6 above as an index.
 3. 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.
 4. I go to the post office and deliver the package, and get a receipt
    with a postal transaction code bound to QR code.
 5. Post scans label and ships.
 6. BBAOC receives package and then contacts payment service with the
    financial service transaction id generated in step 6 above, saying
    “reverse it”.
 7. Payment service issues confirmation, and this too is recorded and a
    new transaction id generated.
 8. BBAOC informs me of both.
 9. 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:

 1. 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.
 2. Now I provide my friend's token instead of my own.
 3. 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/>
>>
>> The Call for Comment will last until 2023-11-03. Please send comments
>> [e-mail]  [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]
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>