4 ms·

> If you really want to mitigate information about downloaded packages you would have to completely revamp apt to randomize package names and sizes, and also ra

> If you really want to mitigate information about downloaded packages you would have to completely revamp apt to randomize package names and sizes, and also randomize read access on mirrors... There isn't a need to randomize package names, or randomize read access on the mirror, given fetching deb files from a remote HTTP apt repository is a series of GET requests. Randomizing order of these requests can be done completely on the client side. Package sizes are still problematic. Here's a suggestion: if each deb file was padded to nearest megabyte, and there was a handful of fixed-size files (say, 1MB, 10MB and 100MB), the apt-get client could request a suitably small number of the padding files with each download. This would improve privacy with a minimum of software changes and bandwidth wastage.

JdeBP 8y ago
If each file were padded to the nearest MiB, the total download size of the packages containing the nosh toolset would increase by almost 3000% from 1.5MiB to 46MiB. No package is greater than 0.5MiB in size. I am fairly confident that this case is not an outlier. Out of the 847 packages currently in the package cache on one of my machines, 621 are less than 0.5MiB in size.
- y4mi 8y ago
  You're arguing with a strawman. He didn't mean these file sizes specifically. it would still apply just the same with different file sizes i.e. create cutoffs every 50 or 100kbyte
  - JdeBP 8y ago
    You're abusing the notion of a straw man, which this is not. I am pointing out the consequences of Shasheene's idea as xe explicitly posited it. Xe is free to think about different sizes in turn, but needs to measure and calculate the consequences of whatever size xe then chooses. No, it would not apply the same with different sizes. Think! This is engineering, and different block sizes make different levels of trade-off. The lower the block size, for example, the fewer packages end up being the same rounded-up size and the easier it is to identify specific packages. (Hint: One hasn't thought about this properly until one has at least realized that there is a size that Debian packages are already blocked out to, by dint of their being ar archives.)
xorcist 8y ago
No, don't do that. Just use tor instead. It's supported on an out of the box Debian install.
- shasheene 8y ago
  It's still useful to be able to connect to the local mirror without tor (and enjoy the fast transfer speeds), but still mitigate privacy leaks from analysis of the transfer and timings. Transferring apt packages over tor is unlikely to ever become the default, so it's worth trying to improve the non-tor default.

JdeBP 8y ago

If each file were padded to the nearest MiB, the total download size of the packages containing the nosh toolset would increase by almost 3000% from 1.5MiB to 46MiB. No package is greater than 0.5MiB in size. I am fairly confident that this case is not an outlier. Out of the 847 packages currently in the package cache on one of my machines, 621 are less than 0.5MiB in size.

y4mi 8y ago
You're arguing with a strawman. He didn't mean these file sizes specifically. it would still apply just the same with different file sizes i.e. create cutoffs every 50 or 100kbyte
- JdeBP 8y ago
  You're abusing the notion of a straw man, which this is not. I am pointing out the consequences of Shasheene's idea as xe explicitly posited it. Xe is free to think about different sizes in turn, but needs to measure and calculate the consequences of whatever size xe then chooses. No, it would not apply the same with different sizes. Think! This is engineering, and different block sizes make different levels of trade-off. The lower the block size, for example, the fewer packages end up being the same rounded-up size and the easier it is to identify specific packages. (Hint: One hasn't thought about this properly until one has at least realized that there is a size that Debian packages are already blocked out to, by dint of their being ar archives.)

xorcist 8y ago

No, don't do that. Just use tor instead. It's supported on an out of the box Debian install.

shasheene 8y ago
It's still useful to be able to connect to the local mirror without tor (and enjoy the fast transfer speeds), but still mitigate privacy leaks from analysis of the transfer and timings. Transferring apt packages over tor is unlikely to ever become the default, so it's worth trying to improve the non-tor default.