Which doesn't scale to office workstations or workplaces with network drives, where users needing to search and update hundreds of files at a time is the norm.
Developers with 1 project open have potentially hundreds to thousands of open, quite valuable files.
Now of course, we generally expect developers to have backups via VCS but that's exactly the point: snapshotting filesystems with append semantics for common use cases is an actual, practical defense.
I'm the old days we had mechanical write protect. I find it hard taking modern security seriously.
It should be pretty simple to [say] make a hardware solution to allow only writing out new files.
I also find it comical that my production database has instructions to conveniently delete or modify all rows in my table. That would be at the top of the list of features I don't want.
I have backups of course, backups on writable usb drives.
Like, when I lose everything it is really nice to be able to delete files from my backup drive. This is such a great idea.
Excuse my ignorance but is one really updating hundreds of files the day round? On some factory machines that do dangerous things you have to hold down two buttons.
About tge two buttons thing in factorys. The reason is, you don't have a hand in the machine. So it's not just two buttons, it's two buttons with such distance you have to use two hands. And, usually one of the two buttons, you have to hold in a middle position, if you push the button to much, it does also not work.
Something else, how many times, because of a bad mousepad, whole directorys got moved somewhere. Often you don't even know what you moved, so you can't even search. Special in my last company, we had for sure once a month such a "new" in our data.
The two buttons also make sure you really want to be doing what you are doing and are not doing other things at the same time. Perhaps multiple keys to launch the nuke would be a better comparison.
I did that drag and drop trick too. I don't even know what I did but a lot of system files and folders ended up on the desktop.
It isn't hard to imagine how features like this came to be and why the product was considered finished. We can obviously do better.
Again: define "explicit"? Does clicking a file count? Asking for code reformatting across the project? How long does access last? How is it revoked?
If the user runs "reformat project" once, then gets a new version, are try going to have any warning that "reformat project" is about to encrypt every file it touches?
Explicit as in when you run a new app it does not have access to any of your files and there is no way for it to gain access without you, the user, giving it.
>Does clicking a file count?
Yes, clicking a file from the file picker counts.
>Asking for code reformatting across the project?
You can grant access to a directory in that case.
>How long does access last? How is it revoked?
It can last forever or until the application is closed. There is room to choose how exactly it could work.
>If the user runs "reformat project" once, then gets a new version, are try going to have any warning that "reformat project" is about to encrypt every file it touches?
Developers with 1 project open have potentially hundreds to thousands of open, quite valuable files.
Now of course, we generally expect developers to have backups via VCS but that's exactly the point: snapshotting filesystems with append semantics for common use cases is an actual, practical defense.