System column xmin makes anonymity hard

From: Johannes Linke <johannes(dot)linke(at)posteo(dot)de>
To: pgsql-general(at)postgresql(dot)org
Subject: System column xmin makes anonymity hard
Date: 2020-05-12 18:00:21
Message-ID: aebd001a-44e7-1b11-3f23-2964ccf7032a@posteo.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi!

since 9.4, VACUUM FREEZE just sets a flag bit instead of overwriting xmin with FrozenTransactionId [1]. This makes it harder to build applications with a focus on data reduction.

We have an app that lets people anonymously vote on stuff exactly once. So we save the vote in one table without any explicit connection to the voting user, and separate from that a flag that this person gave their vote. That has to happen in the same transaction for obvious reasons, but now the xmin of those two data points allows to connect them and to de-anonymize the vote.

We can of course obfuscate this connection, but our goal is to not keep this data at all to make it impossible to de-anonymize all existing votes even when gaining access to the server. The best idea we had so far is more of a workaround: Do dummy updates to large parts of the vote table on every insert so lots of tuples have the same xmin, and them VACUUMing.[2]

Does anyone have a suggestion better than this? Is there any chance this changes anytime soon? Should I post this to -hackers?

Any input would be appreciated!

Johannes

[1] See the blue box on this page: https://www.postgresql.org/docs/current/routine-vacuuming.html

[2] The ctid poses a similar problem. We think we have fixed that by making the primary key of the vote table a UUID, after which we periodically cluster the whole table.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tory M Blue 2020-05-12 18:16:44 Re: Is there a significant difference in Memory settings between 9.5 and 12
Previous Message Peter J. Holzer 2020-05-12 17:07:41 Re: Enforcing uniqueness on [real estate/postal] addresses