Sorry - I missed this thread - we get notifications in the FPF slack for comments on GitHub but not yet Discourse.
However, we already know that adding random padding wouldn’t necessarily hurt—IMO there is no excuse, you should just do it.
Just limiting the conversation here to the paper in question, it states that the most distinguishing feature for SecureDrop was the large size of the site (total incoming packet size). Adding random padding does not address this. Indeed, it may make* the situation worse, as already very large sites with random padding may be even easier to fingerprint.
From the paper on SecureDrop specifically:
In particular, we noted that these pages embed images and use scripts and CSS styles that make them large and therefore distinguishable.
If we want to move toward to goal of making SecureDrop less fingerprintable, we should first decrease the size of the site, which is in line with e.g. https://github.com/freedomofpress/securedrop/pull/1298.
If it was so simple, then we would indeed “just do it”, but this is a complicated problem as evidenced by the many academic computer science researchers working on this problem with suggestions evolving with each paper ;).
[*] note we can’t say definitely, as we have no method for testing. Furthermore, I do not think the SecureDrop engineering team should spend significant effort on developing this testing framework and instead we should focus our limited resources on addressing the much easier attacks on source anonymity that we know are currently happening.