Add privacy considerations section about decoy values. #155
Conversation
msporny
requested review from
davidlehn,
frankhinek,
dlongley,
jandrieu,
longpd,
iherman,
dmitrizagidulin,
andresuribe87,
TallTed,
David-Chadwick,
decentralgabe,
dezell,
brentzundel and
KDean-GS1
and removed request for
mprorock
index.html
Outdated
| <h3>Decoy Values</h3> | ||
|
|
||
| <p> | ||
| The use of decoy values in status lists by <a>issuers</a> can increase the |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
Co-authored-by: David Chadwick <d.w.chadwick@truetrust.co.uk>
index.html
Outdated
| In general, the use of decoys is discouraged as, more often than not, | ||
| random allocation of status list entry indexes provides adequate protection | ||
| for most use cases. If bulk operations can be performed on a status list |
There was a problem hiding this comment.
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.
|
The issue was discussed in a meeting on 2024-04-03
View the transcript3.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. Joe Andrieu: I'll look at the issue and try and understand it and provide feedback.
Manu Sporny: one last issue, 151. |
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com> Co-authored-by: Dave Longley <dlongley@digitalbazaar.com>
|
@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. |
|
Editorial, multiple reviews, changes requested and made, no objections, merging. |
| [=Issuer=] use of decoy values in status lists has been explored as a mechanism | ||
| to increase the privacy of [=subjects=]. While algorithms for employing decoy | ||
| values are out of scope for this specification, implementers are advised that | ||
| the use of decoy values do not provide privacy gains and can harm privacy in | ||
| most cases. |
There was a problem hiding this comment.
Anything merged to main without review is liable to have lingering issues. Now I gotta make another PR...
| that also knew that the bulk update was to be applied to all non-decoy indexes.``` | ||
| When status list entry indexes are allocated in a random fashion, which is the | ||
| suggested mode of operation for this specification, adding decoys harms privacy | ||
| because it reduces the group privacy size by the number of decoys added to the |
There was a problem hiding this comment.
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.
|
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:
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. |
This PR is an attempt to address issue #150 by providing guidance around decoy values.
/cc @zoracon
Preview | Diff