[tor-dev] Proposal: Expose raw bwauth votes

[Tom Ritter]

Sending two replies, with an updated proposal in the second.

On 11 December 2017 at 18:38, teor <teor2345 at gmail.com> wrote:
>> It should make the file available
>> at
>>   http://<hostname>/tor/status-vote/next/bwauth.z
>
> We shouldn't use next/ unless we're willing to cache a copy of the file
> we actually used to vote. If we do, we should serve it from next/ as
> soon as we vote using it, then serve it from current/ as soon as the
> consensus is created.
>
> If we don't store a copy of the file, we should use a different URL,
> like status-vote/now/bwauth, and recommend that the file is fetched at
> hh:50, when the votes are created. This would allow us to implement
> current/bwauth and next/bwauth in a future version.

Sure.

> Have you thought about versioning the URL if we have multiple flavours
> of bwauth file? We could use bwauth-<FLAVOR> like consensuses.

For lack of a better name I'll propose bwauth-legacy?

> Also, Tor has new compression options for zstd and lzma.
>
> Given that this is an externally-controlled file, we could stream it
> from disk and compress it on the fly with something cheap like gzip
> or zstd.

I haven't seen any indicated in dir-spec how to handle those? Or how I
should change the proposal to accommodate them? Should I make the url
.gz and say that the DirAuth should compress it and stream it from
disk?



>> The raw bwauth vote file does not [really: is not believed to] expose
>> any sensitive information.  All authorities currently make this
>> document public already, an example is at
>>   https://bwauth.ritter.vg/bwauth/bwscan.V3BandwidthsFile
>
> How large is the file?
> Maybe we should pre-compress it, to avoid CPU exhaustion attacks.
> If we did this, we could say that it's safe, as long as it is smaller
> than the full consensus or full set of descriptors.

~2.6MB. See above.

-tom