Yes, not using cache at all would make everything very slow. I'm now of course talking about using in session memory cache. If it's too small you can reconfigure it using browser.cache.memory.capacity parameter with Firefox. With fiber I never use caching. But yes, with 512kbit/s connection I unfortunately had to use disk caching too, to avoid re-downloading anything I simply could. But of course in that kind of situation and configurate you're really aware that you're not destroying all data between sessions. For privacy virtual machine with hardened configuration + tor is good idea. Otherwise there's no reasonable expectation of privacy anyway, as they're saying. In technical terms, there are so many ways to track users who do not harden those, that there's no reason to expect any privacy. As we have seen with all these NSA discussions, all technical options were pre-known already. You don't know if sites use some techniques or not, but it's reasonable to expect that they do use at least all publicly known techniques. And possibly some unknown. So making attack (or tracking) surface as small as possible, when looking for privacy is reasonable. Maintaining any data between sessions is just stupid if you're looking for privacy. Always boot clean virtual machine, which is similar to other virtual machines, is best approach. Otherwise there are tons of things they can do to track you.
Btw. even if browser keeps cache, you can always clear storage paths.
One of things that doesn't seem to be known to many users is that many databases contain deleted data (marked free) for long time. They just don't think about it. Just go through all files stored by browser, you'll end up finding stuff that you woulnd't expect to be there, if you're naive. Right attitude is to expect everything to be stored always, and take proper care to destroy data when it's required. This is just like the issue with SSD drives. If you write something on drive, you wan't to destroy. There's no sure way to destroy the data from drive, without totally physically destroying the drive. You simply don't know, if the controller has written data to cell XYZ, and then re-mapped XYZ to somewhere else. Just overwrite it approach does not work in this case. And you can't even guarantee that the manufacturer tool could properly erase that cell.
Just final words. Etag doesn't have anything to do with "images", it's not tied to content-type at all. Next week I could release "css" tracking exploit, which uses etags, which is kind of css checksum. Uh...
In these days, privacy and security is hard, it's very hard. Even if you think you're doing things right, there still might be several things that you're not doing right. Even if you have used serveral years to learn how to do things right. Even after that, there's still possibility of bad luck.
But all this stuff is generally known and properly documented, so there's nothing new.
"Yes, not using cache at all would make everything very slow"
That suggests you've not tried it. I have. I've been running with disk and memory cache disabled in Firefox for a couple of years now on my laptop, and it's not anywhere near as slow as you think it would be. It's barely noticable at all.
On my work machine I have the cache enabled, so I even have something to compare against. My laptop is usually sat on an 8Mbit Internet connection. If you're on a much slower Internet connection it would make a bigger difference, but I don't think 8Mbit is particularly fast nowadays.
Btw. even if browser keeps cache, you can always clear storage paths.
One of things that doesn't seem to be known to many users is that many databases contain deleted data (marked free) for long time. They just don't think about it. Just go through all files stored by browser, you'll end up finding stuff that you woulnd't expect to be there, if you're naive. Right attitude is to expect everything to be stored always, and take proper care to destroy data when it's required. This is just like the issue with SSD drives. If you write something on drive, you wan't to destroy. There's no sure way to destroy the data from drive, without totally physically destroying the drive. You simply don't know, if the controller has written data to cell XYZ, and then re-mapped XYZ to somewhere else. Just overwrite it approach does not work in this case. And you can't even guarantee that the manufacturer tool could properly erase that cell.
Just final words. Etag doesn't have anything to do with "images", it's not tied to content-type at all. Next week I could release "css" tracking exploit, which uses etags, which is kind of css checksum. Uh...
In these days, privacy and security is hard, it's very hard. Even if you think you're doing things right, there still might be several things that you're not doing right. Even if you have used serveral years to learn how to do things right. Even after that, there's still possibility of bad luck.
But all this stuff is generally known and properly documented, so there's nothing new.