There is only one valid reason for a browser to be accessing the local filesystem (except its own execution) outside of its own program folder, or the users "profile" folder. And that's uploads and downloads.
file:/// protocol should be dead, killed, executed, put out of its misery. There's no reason for it. A lot of web dev tools won't ever work via file:/// anyway, and force you to run a local web server if you want to prototype them (mainly because browser DOMs now - correctly - ban such actions... I know I can't load an Emscripten / Webassembly file from the local filesystem without the browser just throwing up its arms and not executing it).
And uploads are easy to fix:
Browser believe that the user wants to request a file.
Browser executes, in a completely separate and secure context, a single program that can't be run again until the file is actually selected by the user. Said program runs in its own execution space, takes *no* data from the browser whatsoever (if I was being nice, maybe the *title* of the requested window, but you can see how even that could be scammed and you think you're uploading your photo to Facebook but actually you're uploading your photo to a malicious tab in the background!).
Said program lets user select file from local filesystems. Reads said file. Provides contents of said file to browser. (Browser could supply a buffer or, more likely, said program creates a suitably-sized buffer and returns the address of it to the browser). Said program has exactly zero requirement to access the Internet or act upon any data from the browser in any way, shape or form.
Said program terminates, signalling browser that it's done, and where it put the data.
Browser waits for that termination signal, picks up the data from the location, supplies it to whatever mechanism triggered the request (a file upload, or whatever).
Downloads are literally the same in reverse - the browser supplies the data and tells a local helper program "Ask the user where he wants this, and save it there for him".
The problem with modern browser is *not* that they can't be secured. It's that people are dumb and haven't learned the lessons of history. Isolate everything. Have minimal message-passing between contained modules. Don't let even one module get all the privileges. One module to determine users preferences. One module per tab to parse HTML and gather resources. One module per tab to render that content to a video memory area. One module to assemble that content on demand inside a UI (and the tab module doesn't even need to *know* whether it's visible or not!). One module to do file accesses for uploads. One for downloads. And don't let even a single tab be able to control/interface/message/even detect the presence of - any other tab.
Break it down. Erect walls between them all. Strip permissions from everything back to the bare bones (uploads/downloads don't need to touch networking AT ALL, the UI module requests information from the settings module but never queries them directly, etc.). Then the chances of, say, a dodgy bookmark corrupting the browser's stack to provide full filesystem access to a tab on a related site, etc. are nil.
When you are designed the one, primary, major interface between a user, an OS and an untrusted third-party scripting language, you're an idiot to do it any other way at all. When a tab falls over, it falls over, and takes... nothing else with it. I can't tell you how often Chrome/Firefox browsers LOCK UP COMPLETELY because one tab goes a bit mad on the old Javascript. It just shouldn't be happening.
We should have learned this lesson by now. And especially after the "let's put the browser INSIDE the OS and let people poke all the internals!" of the Internet Explorer days.
I will happily take my browser rendering a fraction of second slower, over it ever making possible a remote compromise of my machine with just a single click from an unprivileged user.