Google and Mozilla are working together on a method to let web apps gain access to users' files.
A group led by Google and Mozilla is working to make it easy to edit files using browser-based web apps but wants advice on how to guard against the "major" security and privacy risks.The idea is to allow users to save changes they've made using web apps, without the hassle of having to download new files after each edit, as is necessary today.[...] the W3C Web Incubator Community Group (WICG), which is chaired by representatives from Chrome developer Google and Firefox developer Mozilla, is working on developing the new Writable Files API, which would allow web apps running in the browser to open a file, edit it, and save the changes back to the same file.However, the group says the biggest challenge will be guarding against malicious sites seeking to abuse persistent access to files on a user's system."By far the hardest part for this API is of course going to be the security model to use," warns the WICG's explainer page for the API."The API provides a lot of scary power to websites that could be abused in many terrible ways.
A group led by Google and Mozilla is working to make it easy to edit files using browser-based web apps but wants advice on how to guard against the "major" security and privacy risks.
The idea is to allow users to save changes they've made using web apps, without the hassle of having to download new files after each edit, as is necessary today.
[...] the W3C Web Incubator Community Group (WICG), which is chaired by representatives from Chrome developer Google and Firefox developer Mozilla, is working on developing the new Writable Files API, which would allow web apps running in the browser to open a file, edit it, and save the changes back to the same file.
However, the group says the biggest challenge will be guarding against malicious sites seeking to abuse persistent access to files on a user's system.
"By far the hardest part for this API is of course going to be the security model to use," warns the WICG's explainer page for the API.
"The API provides a lot of scary power to websites that could be abused in many terrible ways.
What could possibly go wrong?
Provided you don't use such products.
Now, please excuse me while I wipe Firefox and Google from my drives.
The problem with wiping Firefox and Google Chrome from your drives is: What's left? The only major web browsers not based on Chromium or Mozilla Firefox are Microsoft Edge and Apple Safari. Opera? Chromium. Brave? Chromium. Vivaldi? Chromium. Falkon? Chromium.
Now, it may be possible for Opera/Brave/Vivaldi/Falkon developers to disable the Writable Files API, but we'll have to wait and see.
Midori and elinks.
How can I get Midori to list the files on my hard drive in some semblance of alphabetical order?
What's left? To run the browser in a good, secure VM (if such a thing exists) - or on a separate computer. Today it is trivial - tablets, R-Pis, old smartphones, TVs ... this will block access to your files reliably, proportional to security of your network (vpn tunneling + blocking direct access at a separate firewall is always a plus.) For home/recreational use this is all that is needed; plus your browsing device is not cluttered with other applications.
Professional use comes with more expensive precautions. Airgapped LANs are well known in many places. Otherwise establish unidirectional flow of sanitized data from the browsing box into a shared drive that can be read by the more secure computers.
In summary, if they don't science the shit out of this user file access idea, users will have to sandbox the shit out of the browsers.
Probably should've been sandboxing browsers all along anyway.
Or only buy computers capable of running registered memory.
And that is ignoring the speculative execution and other timing/race leaks in modern processors.
Very little hardware can be considered secure from either hackers or state level adversaries largely because of the commercial limitations of available consumer electronics.
The problem with wiping Firefox and Google Chrome from your drives is: What's left?
Firefox with support for script in content documents removed at compile time. Let documents be documents and applications be applications, the latter preferably distributed in source code form under a free software license.
The original question was: "The problem with wiping Firefox and Google Chrome from your drives is: What's left?" And your answer was "Firefox?"
You're not very bright.
Sadly, you're the one who's not too bright. GGP suggested using Palemoon. GP replied that Palemoon is based on Firefox. Since wiping Firefox and Chrome was the topic, installing something based on Firefox would be counter to the stated goal.
More than that, Palemoon is so dependent on Firefox that I am funny convinced that without it, Palemoon would either collapse under its own development weight or become even more of a haven for security holes.
I'm funny convinced that you're uninformed.
What's left?E-mail client and a few good mailing lists. Seriously, I haven't found large amount of practical info (in form of FAQ or documentation) in the Web since 2015. "News" made to manipulate and divide people, trolling fests in forums, all questions answered with "buy more stuff". Turn the TV on for the same content, it'll eat less electricity.
I haven't found large amount of practical info (in form of FAQ or documentation) in the Web since 2015.
You're either looking for the wrong things, or in the wrong places, then. The WWW remains well supplied with with great information, much of it unencumbered by advertising, spam, etc. You do need to be able to use search engines well, though — there's no question there's plenty of spam out there.
"Yes", "I" "still" "use" "Google" "well" -shop -price -sell -site:[snap*!] -site:[snap**!]
* - one of the biggest e-shop putting links to every problem.** - forum aggregator who has stolen search queries database some time ago and is trying to get all people to their ad-infested pages.
I get useful answers, but most of them are in older parts of the WWW, in form of links (now in Archive) or in disappearing niche forums. And yes, these are in sites in which lone GIF banner is the only ad.But since about 2010-2015, I see a significant decline here. And a lot is dependent on the country - I search mostly in English and Russian Internet as I can find answers and suggestions to technical questions there, there are countries in which it's even better (but language is the limit), and there are countries in which it's worse. For my country... this looks like one of these teleshopping TV channels.
There aren't trolling fests in mailing lists as well as forums? That would be news to me. I find that they're both equally useful and trolly.
NetSurf [netsurf-browser.org] & dillo [dillo.org]
I've actually heard of Dillo and used it a bit. It's definitely it's own beast. Had issues displaying some things correctly or at all, so never really took it seriously. I thought it was dead, but apparently their releases are just few and far between? Though, looks like latest release was 2015, so maybe it's truly dead now? Or it's just being Dillo?
In other words, you use Lynx. No need for fancy graphics, you can't relate to me what I need in text or ASCII images, then You Shall Not Pass!
But I could make some great web apps with this...
Days gone by, you could click on an .exe on a webpage and run it. That didn't last too long, and the various sandboxes have gotten smaller and smaller over the years.
Personally, I don't see a problem with establishing a DMZ where files are accessible to the web browser, and it's as simple as that. People who want to leave their life history and financial records in the DMZ get what they deserve, otherwise: if you want to share a file, put it in the exposed folder and explicitly grant access to the folder when a website wants to slurp your file. End of story, what's to develop?
This never actually ended in the IE side of things because DirectX files are no different from EXE's (both are PE's, one is just not ran standalone but technically still has the same level of access if allowed to run).
Bold of you to assume that users know what folders are and won't automatically click the "make it work and stop annoying me" button. I'm all for "fuck it, leave them to crash if they don't learn to drive and use a car anyway" but Google actively courts these idiots as customers as has a duty to them. Making cars safer to crash* and all that.
*crumple zones, airbags, seat belts, testing and caring about performance in crashes, &c
Bold of you to assume that users know what folders are
Oh, no. I taught senior level computer engineering and actually had students tell me "this is a digital design class, I don't have to know how folders work for this subject..." Private university, I was later informed by management that "these are paying customers, as long as they show up they get at least a C." Welcome to quality education in the USA.
If you treat users like idiots they will become and remain greater idiots.
But would they be better enough to reduce harm further than the suite of modern safety features does?
persistent access to files
Why would any site, anywhere, need _persistent_ access to files?
Even supposing Google Docs. Look at MS Word. You _open_ a file, you edit it, then you _save_ changes. Consider what we have now: a button that, when clicked, asks you what file you'd like to open. Every _save_ is currently equivalent to a save-as, but even if it _weren't_, the save wouldn't be _persistent_ access to files. When you close the site, any access to any file is over.
How do you prevent a site from interchanging the "open for edit" dialog and the "upload" dialog? Perhaps we should separate apps out into ones that show you documents from the web, and ones that you download to run code on your local machine. ..... hmm.
Where everything went from the mainframe to being highly modularized and back to the mainframe, everything is going from separating everything out to ChromeOS and will pendulum back to separating everything out, for security and reliability and personal control. The companies seem to never give up on turning the internet into TV, though.
No site should need persistent access to the file system, but I can see how this could be very appealing to the likes of MS Word, Adobe Creative Cloud, in-house/intranet web applications, etc.
I think there are two different types of file access that need to be considered here:
1. Local autosave
2. Local read/write
With restrictions to the amount of local browser storage I think #1 could be useful and (relatively) safe if each autosave directory was site-based (like cookies). It goes without saying that if a site gets infected your existing autosave files are fair game, though removing the autosave files after saving the document to "the cloud" (even sending the autosave files along with the saved document) would remove that security risk.
I'm not sure how #2 can work safely, even with site-based whitelisted directories. If a site gets infected your documents are in a lot of danger.
File access could make for some interesting browser extensions, but it also opens up a portal of doom. Perhaps this feature should be called "Pandora" instead of "Writable Files API"
Given google's business logic is based on spying, this means they will be able to get more information from you.
Because the current method for reading/writing files is uploading/downloading the entire file. If you're editing a 1GB file, that's undesirable. Having direct file access is clearly superior for this use case.
(Also, take a look at the HTTP file transfer protocol at some point, it could be generously described as shit.)
The reason is of course to support web apps, and the reason web apps exist is portability. Web apps are basically the modern POSIX. I'm sure that sounds scary to a lot of people, but POSIX was scary for old school Unix too; it killed them right dead.
The Plan 9 folks probably don't like it, but the modern "Web" is what Plan 9 was trying to achieve, decentralized computation/storage that could be accessed from anywhere. Sure, it's a lot shittier, but it actually exists, and existing turns out to be a very important feature for software.
Why bother speculating on a new secure browser architecture, when you haven't yet achieved an old secure browser architecture? All free browsers are built on design choices based on market conditions rather than technological best practices. They always have they always will.
The thing is, there probably IS a market for a paid-for secure browser at this point. Of course all of the vendors would implement code to diddle an shared libs to fuck it up, so you'd have to compile it as a monolithic product, and have it hash itself on startup. And it would break a lot of sites. But that's the point isn't it? The client side is obligated to preserve the rights of the user, regardless of what the server side expects. Compatability is fundamentally antithetical to privacy in a commercialized user space.
The open source sandstorm.io software has a solution for this kind of thing that might fit. The project developers are not the first people to make a design like this, but it's a good example. https://docs.sandstorm.io/en/latest/using/security-practices/ [sandstorm.io]
I'm not affiliated with the project, I just pay for the hosted version for myself and host my own instance of it for family.
If I remember correctly, one of the reasons for ditching XUL was because the oh so brand new webextensions API was so secure yadda yadda.And now this?Are they stupid?One might say, but XUL was so slow! Well, with multicore being the norm now, the argument is pretty nullified at this point.Then again, why did they ditch XUL for webextensions and now have this shit?Stupid Firefox.
The funny thing is that they never ditched XUL, the entire browser is still XUL. All they did was forbid extensions from making use of it. The whole performance thing was always a red herring.
It could be abused in many terrible ways, but we won't let a little thing like that stop us *high five*
Modern browsers are already big, complicated beasts that have far more functionality than the Web needs or puts to good use. Seriously, show me pages with nice formatting, allow forms entry, and everything after that needs to be argued to hell and back for use cases before even considering adding it back in. No, your web sales portal does not need to be able to query my browser for OS, installed fonts, currently running background programs, which links were hovered over for how long, attempt to scrae pages I've got open in other tabs, or run an e-coin miner for you until I reboot the machine because you held the session open even after the browser window was closed. No, go fuck yourselves for all of that.
allow forms entry
A good user experience for forms entry includes spot-checks on a few constraints without having to take a round trip to the server for authoritative validation every single time. HTML5 added a few declarative constraints on input elements, but in my experience, HTML5 input constraints are not sufficient to express all constraints that a user expects to be checked before submission. For example, there's no way without script to make a field conditionally required or not based on the value of another field. HTML5's image input element also lacks a way to submit drag gestures, which are needed for image input that is more than just a single point. Good luck making whiteboard chat or signature entry without script.
No, your web sales portal does not need to be able to query my browser for OS
Once you decide to purchase a copy of a native application, how should it be able to tell whether to list the Windows version first, list the macOS version first, or list the X11/Linux version first? Detecting the operating system under the assumption that the application will be used on the same platform on which it was purchased reduces the cost of handling tech support tickets from non-technical users who chose the wrong version.