Implement an option to pad HTTPS requests against traffic analysis
One of the tools that dragnet surveillance actors have against both HTTPS and Tor is message length analysis. In general message lengths can be used to determine which paths on a give HTTPS domain a browser might be requesting (summed, but probably extractably so, with the lengths of messages the client might be POSTing to the server), and to perform end-to-end traffic analysis of Tor circuits.
HTTPS Everywhere is in a position to pad requests to servers to some round number of bytes (N byte blocks, powers of two, floors of powers of some number lower than two). We could do this by sticking in a new X-Padding: HTTP header. We could also write an RFC specifying that servers should pad their responses in a similar way if they see the X-Padding header. Perhaps we could persuade some servers to respect this.
Would this be valuable? What padding scheme would we want? Powers of two seems too costly for long messages, maybe we could have a hybrid that used 512 byte blocks for short messages and powers of 1.3 (15% overhead) or something for long messages. Perhaps we could even collaborate with some academics to figure out a good padding scheme based on message length spectra for gmail, wikipedia, or other major sites.