Consider improvements to logic for maintaining voter privacy by obfuscating the order in which ballots are cast

[arsalansufi]

See the discussion at the end of #3972

[cjerdonek]

Continuing the discussion in #3972 about the idea of pre-creating the files:

And finally, as you've noted, we'd still need to account for / obfuscate file modification times (which generally are easier to update than creation times, e.g. touch file.txt).

If the file system lets you set the file modification time, after writing the file contents to the pre-existing files, you could manually set the last-modified time of those files equal to the creation times. Then, neither the creation times nor the last-modified times would reveal anything about the order in which the files were written to. This approach would then let you have "perfect privacy" (to use @benadida's phrase) in the sense of a uniform distribution over all orderings.

[arsalansufi]

That makes sense @cjerdonek! I quickly tried updating a file's modification time and ran into one snag, namely the distinction between a file's "Modify" time and "Change" time. While the "Modify" time is easy to update, "Change" time is turning out to be trickier.

Create a file

$ touch file.txt
$ stat file.txt
  File: file.txt
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 802h/2050d	Inode: 414136      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ arsalan)   Gid: ( 1000/ arsalan)
Access: 2023-09-20 14:47:41.386847799 -0400
Modify: 2023-09-20 14:47:41.386847799 -0400
Change: 2023-09-20 14:47:41.386847799 -0400
 Birth: 2023-09-20 14:47:41.386847799 -0400

Write to that file

$ echo abcd > file.txt
$ stat file.txt
  File: file.txt
  Size: 5         	Blocks: 8          IO Block: 4096   regular file
Device: 802h/2050d	Inode: 414136      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ arsalan)   Gid: ( 1000/ arsalan)
Access: 2023-09-20 14:47:41.386847799 -0400
Modify: 2023-09-20 14:47:48.234834395 -0400 # Set to the time the echo command was run
Change: 2023-09-20 14:47:48.234834395 -0400 # Set to the time the echo command was run
 Birth: 2023-09-20 14:47:41.386847799 -0400

Try resetting the file's modification time(s)

$ touch -d '2023-09-20 14:47:41.386847799' file.txt
$ stat file.txt
  File: file.txt
  Size: 5         	Blocks: 8          IO Block: 4096   regular file
Device: 802h/2050d	Inode: 414136      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ arsalan)   Gid: ( 1000/ arsalan)
Access: 2023-09-20 14:47:41.386847799 -0400
Modify: 2023-09-20 14:47:41.386847799 -0400 # ✅ Set back to the original
Change: 2023-09-20 14:48:14.690894360 -0400 # ❌ Set to the time the touch command was run
 Birth: 2023-09-20 14:47:41.386847799 -0400

Still worth further investigation! But wanted to document this hurdle

[cjerdonek]

Thanks for trying that out, @arsalansufi! One question that comes to mind: what happens if the "Change" time starts out in the future? Does it remain the same, or does it get updated to an earlier time?

[arsalansufi]

^ I'm finding that the "Change" time is always updated to the current system time. So even if the "Change" time starts off in the future (I accomplished this by temporarily modifying my system time to be in the future), it gets set to an earlier time if the system time at the time of the update is earlier.

[cjerdonek]

So it looks like pre-creating enough files would likely let you do away with more expensive operations like copying directories of past CVR's, etc, but you would still need to do some lightweight operation on previous files to update the "Change" time (e.g. using touch). A more lightweight operation like touch should let you update a lot more of the previous CVR's without affecting performance (and would also let you reduce some of the complexity of the temp directories, etc).

[arsalansufi]

Agreed - this combo seems like a viable direction!

[adghayes]

We have covered this with a copying strategy - see the TDP for details: https://docs.voting.works/vxsuite-tdp-v4/system-security-auditing-and-logging/system-security-architecture/artifact-authentication/preserving-voter-privacy.

[arsalansufi]

@adghayes This issue was originally about refinements to the current approach (as documented in the TDP), to shuffle even better, i.e., with an even more random distribution. But now that we've seen our current approach in action, I think that it strikes the right balance between preserving privacy and not overcomplicating. So I'm good to close!