[mlyle]

Not sure where 248 hours came from.

38 terabytes = 304 terabits.

304 terabits / 1 gigabit/second = 304,000 seconds

304,000 seconds =~ 84 hours. Add 20% for not pegging the line the whole time and the limits of 1gbps ethernet, and perhaps 100 hours is reasonable.

[permo-w]

my mistake, I swapped the 38tb and 112tb from parent comment

whatever the download size is, you're bottlenecked by the remote server's up speed

[mlyle]

If the "remote server" is Azure, the target throughput is 0.5gbps ... for each large blob (of which this leak includes many). It seems pretty likely you'll be able to download at a few gigabits per second if your local connectivity allows.

[permo-w]

that's a big if

[mlyle]

We're talking about exfiltrating data from incorrect permissions on Azure, so it's not an if. It's a given for the situation in the article that we're discussing in this thread.

[permo-w]

that's not quite true. the article discusses a transfer from Azure to Github. The article does not say where the files are currently hosted, besides being publicly available on Github. It's probably Azure, but it could easily also be whatever Github use

[mlyle]

No, that is an incorrect reading of the article. A GitHub repository mentioned an Azure storage URL; that storage service was incorrectly configured-- exposing many sensitive blobs besides the one that was intended to be shared via the URL.

The URL was: "https\://robustnessws4285631339.blob.core.windows.net/public-models/robust_imagenet/resnet18_l2_eps3.ckpt?sv=2020-08-04&ss=bfqt&srt=sco&sp=rwdlacupitfx&se=2051-10-06T07:09:59Z&st=2021-10-05T23:09:59Z&spr=https,http&sig=U69sEOSMlliobiw8OgiZpLTaYyOA5yt5pHHH5%2FKUYgI%3D" (Backslash added to prevent HN from detecting it as an URL and shortening).

The issue was that "sig=U69s...." token gave access to far more than the researchers intended to share.