5 ms·

You could quantize these with up to 10% padding and cause a very large number of collisions, but that wouldn't be useful without HTTPS. Is the core argument tha

by ynniv 8y ago

You could quantize these with up to 10% padding and cause a very large number of collisions, but that wouldn't be useful without HTTPS. Is the core argument that privacy is not attainable, or that it is not valuable?

brazzy 8y ago
I think the core argument first of all is that it is not attainable trivially by "just using HTTPS". So it's a question of costs vs. benefits, where the costs are pretty big (change the whole infrastructure).
- ynniv 8y ago
  This is wrong. A great deal more privacy is attainable by trivially using HTTPS. Privacy in the presence of stream inspection is more difficult, but attainable by padding files to have quantized lengths.
  - Godel_unicode 8y ago
    You are entirely incorrect in this instance, for all the reasons laid out in this thread. Looking at stream sizes is not "advanced deep packet inspection", it's in fact the opposite of that.
loeg 8y ago
Up to 10% padding likely isn't sufficient to provide privacy. Think of the long tail of large packages.
- ynniv 8y ago
  Quantizing up to 10% collapses 43,000 values into 120. It's not perfect but it removes a huge amount of information.
  - loeg 8y ago
    How do you arrive at 120? I guess that makes sense if the biggest packages is within 92709x (1.1^120) the size of the smallest. But that doesn't seem like enough range, just eyeballing it. If you have a 1kB package at the low end, I'd be surprised if Debian didn't have a package bigger than 92 MB. Presenting it as 120 from 43,000 is a bit of an oversimplification, because the average isn't meaningful. The long tail is going to have the worst privacy and the small packages will (probably) have the most. A scheme like this might be workable but requires being really careful about the security properties you're claiming (i.e., of those 120, probably half are unique, large packages). And obviously, this scheme requires up to 10% additional bandwidth, in the case of the chosen 10% threshold. If buckets change over time, packages moving between buckets may leak a lot of information.

by ynniv 8y ago

brazzy 8y ago

I think the core argument first of all is that it is not attainable trivially by "just using HTTPS". So it's a question of costs vs. benefits, where the costs are pretty big (change the whole infrastructure).

ynniv 8y ago
This is wrong. A great deal more privacy is attainable by trivially using HTTPS. Privacy in the presence of stream inspection is more difficult, but attainable by padding files to have quantized lengths.
- Godel_unicode 8y ago
  You are entirely incorrect in this instance, for all the reasons laid out in this thread. Looking at stream sizes is not "advanced deep packet inspection", it's in fact the opposite of that.

loeg 8y ago

Up to 10% padding likely isn't sufficient to provide privacy. Think of the long tail of large packages.

ynniv 8y ago
Quantizing up to 10% collapses 43,000 values into 120. It's not perfect but it removes a huge amount of information.
- loeg 8y ago
  How do you arrive at 120? I guess that makes sense if the biggest packages is within 92709x (1.1^120) the size of the smallest. But that doesn't seem like enough range, just eyeballing it. If you have a 1kB package at the low end, I'd be surprised if Debian didn't have a package bigger than 92 MB. Presenting it as 120 from 43,000 is a bit of an oversimplification, because the average isn't meaningful. The long tail is going to have the worst privacy and the small packages will (probably) have the most. A scheme like this might be workable but requires being really careful about the security properties you're claiming (i.e., of those 120, probably half are unique, large packages). And obviously, this scheme requires up to 10% additional bandwidth, in the case of the chosen 10% threshold. If buckets change over time, packages moving between buckets may leak a lot of information.