Wait, wait, wait: browsers allow websites to store junk on my drive? They take up gigabytes of memory and still write to disk on top of this? Without even asking whether the site can use local storage? Years and years back when laptops still had HDDs, I had a script to put the Firefox profile &c on a ramdisk and sync it on reboots so that it didn't spin up the drive constantly. I guess I should have kept doing it. It…
> Without even asking whether the site can use local storage?
Where did you see this in the article? I had some recollection that Firefox at least did require asking the user.
Wait, wait, wait: browsers allow websites to store junk on my drive? They take up gigabytes of memory and still write to disk on top of this? Without even asking whether the site can use local storage? Years and years back when laptops still had HDDs, I had a script to put the Firefox profile &c on a ramdisk and sync it on reboots so that it didn't spin up the drive constantly. I guess I should have kept doing it. It…
> Without even asking whether the site can use local storage? Where did you see this in the article? I had some recollection that Firefox at least did require asking the user.
Firefox doesn't ask permission just to use localstorage, no modern browser does this. The closest thing you get is when a site wants to persist storage with "navigator.storage.persist()", which should prompt you for permission. But localstorage data usually persists anyway, and only gets deleted if the browser's storage is "under pressure", so I've never personally worked on a site or web app that had to use that API.
Wait, wait, wait: browsers allow websites to store junk on my drive? They take up gigabytes of memory and still write to disk on top of this? Without even asking whether the site can use local storage? Years and years back when laptops still had HDDs, I had a script to put the Firefox profile &c on a ramdisk and sync it on reboots so that it didn't spin up the drive constantly. I guess I should have kept doing it. It…
Is this surprising? Websites have long been silently writing to disk, for cache, cookies, and blobs. OPFS just provides a file-system-like API for ultimately the same functionality
Yes? From the paper:
"On Chrome and Safari, OPFS supports very large files, up to 60 % of disk space, which is more than sufficient to avoid the page cache on most typical systems, as even a small disk size of 64 GB would allow us to create a 38.4 GB OPFS file."
I am indeed surprised to learn that a random website can write a file that takes up 60% of my disk. Is this obviously a capability of Web browsers?
Is this surprising? Websites have long been silently writing to disk, for cache, cookies, and blobs. OPFS just provides a file-system-like API for ultimately the same functionality
Yes? From the paper: "On Chrome and Safari, OPFS supports very large files, up to 60 % of disk space, which is more than sufficient to avoid the page cache on most typical systems, as even a small disk size of 64 GB would allow us to create a 38.4 GB OPFS file." I am indeed surprised to learn that a random website can write a file that takes up 60% of my disk. Is this obviously a capability of Web browsers?
Ten movies streaming across that, that Internet, and what happens to your own personal Internet? I just the other day got... an Internet [email] was sent by my staff at 10 o'clock in the morning on Friday. I got it yesterday [Tuesday]. Why? Because it got tangled up with all these things going on the Internet commercially. [...] They want to deliver vast amounts of information over the Internet. And again, the Internet is not something that you just dump something on. It's not a big truck. It's a series of tubes. And if you don't understand, those tubes can be filled and if they are filled, when you put your message in, it gets in line and it's going to be delayed by anyone that puts into that tube enormous amounts of material, enormous amounts of material.
It should be fairly easy to mitigate no? Simply add random access times. Localstorage doesn't need to be that fast. More generally I find it very annoying how much browsers allow by default (javascript, localstorage, gpu access etc.) - there's only a very limited amount of websites I want to be able to run gpu accelerated shaders.
I assume it's something like this: Attacking website periodically makes random reads from a large file in localStorage. Other tabs and websites open have Javascript running that periodically performs operations that will result in SSD traffic. For example, GMail has a certain polling interval to check for new mail, and each request is going to result in a cache write that makes the SSD busy and delays other conflicti…
That's interesting. Thanks for the explanation. If I read this right this isn't as effective against spinning HD-based systems and there is a dependence on the user maintaining more than one tab as they browse? If that's the case then my system which is still HD-based is not threatened and since I tend to close tabs and windows and just spin up a new private window for each site while clearing cookies, etc on exit th…
It'd have some effectiveness against spinning HDDs because it's really just measuring contention for the I/O subsystem, but it'd likely be less because the kernel usually buffers writes to HDDs internally. But then, the kernel also usually buffers writes to SSDs, just with lower latency between the call and the data being written.
I don't think too highly about this particular threat vector - it seems like the kind of attack where you could perhaps get a working proof of concept going in the lab to write a paper and demonstrate some results, but actually using it to attack people at scale seems prohibitively noisy. People that close all their tabs when not at use are not at risk (and the data I had was that most people don't actually use browser tabs, they're very much a power-user feature). People who have disk-intensive other processes like Bittorrent or various file-syncing services aren't really at risk, because those other processes inject similar noise into the data stream. The signal in general seems weak because of buffering and differing SSD latency and so on.
> Without even asking whether the site can use local storage? Where did you see this in the article? I had some recollection that Firefox at least did require asking the user.
Firefox doesn't ask permission just to use localstorage, no modern browser does this. The closest thing you get is when a site wants to persist storage with "navigator.storage.persist()", which should prompt you for permission. But localstorage data usually persists anyway, and only gets deleted if the browser's storage is "under pressure", so I've never personally worked on a site or web app that had to use that API…
You mean by default or it cannot be configured that way? I believe, I had Chrome configured to not allow storage by default, only for sites I added to an exclusion list. I cant remember now, but isnt there also an option to change the default on Firefox to deny or always ask for permission?
Firefox doesn't ask permission just to use localstorage, no modern browser does this. The closest thing you get is when a site wants to persist storage with "navigator.storage.persist()", which should prompt you for permission. But localstorage data usually persists anyway, and only gets deleted if the browser's storage is "under pressure", so I've never personally worked on a site or web app that had to use that API…
You mean by default or it cannot be configured that way? I believe, I had Chrome configured to not allow storage by default, only for sites I added to an exclusion list. I cant remember now, but isnt there also an option to change the default on Firefox to deny or always ask for permission?
Just by default - I didn't know you could configure your browser to disallow storage by default.