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's a sad day when Arch users are right (again) https://wiki.archlinux.org/title/Firefox/Profile_on_RAM

▲

sheept 6 hours ago | parent | next [-]

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

▲

runako 2 hours ago | parent [-]

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?

	▲	ElProlactin an hour ago \| parent [-]
		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.

▲

kccqzy 3 hours ago | parent | prev | next [-]

> 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.

▲

nozzlegear 2 hours ago | parent [-]

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.

▲

anygivnthursday 36 minutes ago | parent [-]

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?

	▲	nozzlegear 18 minutes ago \| parent [-]
		Just by default - I didn't know you could configure your browser to disallow storage by default.

▲

AlienRobot 6 hours ago | parent | prev [-]

That surprised me as well.

I thought the whole point of cookies, local storage, session storage, and indexed DB were to avoid what origin private file system is doing.

You mean I could have just saved stuff as a file this whole time instead of serializing it to a string? Why didn't we just do this from the start?

	▲	nostrademons 6 hours ago \| parent [-]
		It's still sandboxed and deleted when the user clears private data for the website. The main advantage it has over things like cookies, local storage, etc. is that it provides a byte-oriented, random access API and as a result, you can use third-party libraries like SQLite that expect a file API. Which is more important now that we have tools like Emscripten and WebAssembly that let you use existing C libraries on the web. At the same time it has security guarantees such that webpages cannot write arbitrary files that will be viewed and executed by the user. Also, in theory you could use this side-channel attack on localStorage and sessionStorage. Its only requirement is that it needs an API that writes to disk where you can measure the latency of a synchronous call, since the fingerprinting is just measuring the interference pattern between disk accesses the attacking website does vs. disk accesses that other websites do.