Add privacy considerations section about decoy values.

[msporny]

This PR is an attempt to address issue #150 by providing guidance around decoy values.

/cc @zoracon

---

Preview | Diff

[dlongley]

Decoy values, which are known to the issuer, also decrease the size of the group -- which is relied upon for privacy. It might be the case that random assignment of indexes in a list provides sufficient protection against whatever decoys might do, without reducing the size of the group. I'm not convinced that decoys add more value in many cases (such as for revocation status lists for which there are few revocations) than they would take away.

It might be better to say nothing about them here unless there is further analysis / text explaining the threats that they mitigate that pseudo-random assignment of indexes does not.

[msporny]

Yes, I see your point.

I tried some updates in aada152 and efa14d9 to address your concerns.

We need to say /something/ about decoys because they are being proposed as an "obvious solution" in some digital credentials initiatives even though there are known privacy harms when using them.

Any thoughts on the updated text?

[dlongley]

This first sentence is the main thing I agree with in this PR. Don't use decoys, trying to do it seems like you'll probably just end up harming privacy for little to no gain. The second sentence I can't really say I agree with at this point in time. I remain unconvinced by the text that decoys are a good idea in any circumstance when randomness is already employed. I guess if you can't do your index allocation randomly enough, decoys could be of some help, so I wouldn't block the PR on that basis -- but if there's consensus to remove mention of decoys entirely I'd prefer that.

It would be ideal for a "decoy advocate" to offer better text in support of their position; I understand we're trying to approximate here for something that is meant to be obvious but maybe it isn't so obvious in this circumstance. I understand the basic strategy and concept behind using decoys to hide real information in a system, but when this comes into contact with the group privacy problem and other potential solutions here -- I'm not sure it survives analysis. I'm happy to be wrong and would prefer to see the text making it clear to implementers when/why to use them, because that's what this section is for -- and I think a number of them would get a little lost here.

[iherman]

The issue was discussed in a meeting on 2024-04-03

• no resolutions were taken

View the transcript

3.3. Add privacy considerations section about decoy values. (pr vc-bitstring-status-list#155)

See github pull request vc-bitstring-status-list#155.

Manu Sporny: three more issues for bitstring.
… there was a request for talking about decoy values. This was requested by PING.
… based on the discussion in that issue, I think we are coming to the conclusion that decoy values undermine privacy.
… but I'd like to get feedback from the group.
… Consider a list with 100,000 entries. Current guidance is to assign that randomly.
… In that way, any observers won't gain insight into the population.
… but if there are decoys, that reduces the group privacy dynamic.
… this isn't saying decoy values are bad, but in vc status list it undermines randomizing.

Joe Andrieu: I'll look at the issue and try and understand it and provide feedback.

Dave Longley: +1 to getting more feedback on that PR.

Manu Sporny: one last issue, 151.

[msporny]

@dlongley @TallTed I have reworded this PR to discourage the use of decoy values (as randomization seems to be the simplest approach that maximizes privacy). We'll need an advocate for decoy values to provide a use case for why they might be useful in certain use cases. Until then, the specification will encourage the use of randomization and discourage the use of decoy values.

[msporny]

Editorial, multiple reviews, changes requested and made, no objections, merging.

[TallTed]

Anything merged to main without review is liable to have lingering issues. Now I gotta make another PR...

[TallTed]

#166

[TallTed]

What is a "group privacy size"? I could find no suitable definition on the web, making it seem likely to have been invented here, where there also seems to be no definition. Once there is a definition I can refer to, I expect this paragraph to need some rephrasing.

[TallTed]

pick up in #166

[KDean-Dolphin]

Sorry for being late to the game. I did a presentation at IIW on this subject, including a randomization algorithm that provides complete coverage of a bitstring if required.

Decoy values can address risks with issuer and ecosystem privacy, where the size of the bitstring can be used to estimate the number of credentials issued over time. From the presentation:

Volume analysis over time is business intelligence: if the status list is growing at 80% of the rate this year versus last, it’s reasonable to assume that the issuer’s business or the ecosystem is down 20%.

The addition of decoy values, with their statuses changing in ways that are statistically indescernible from changes to legitimate values, can mitigate that kind of analysis.