Slashdot Mirror
Google, Mozilla Working on Letting Web Apps Edit Files Despite Warning That it Could Be Abused (techrepublic.com)
Google and Mozilla are heading a group that is devising a way for users to save changes they make using web apps. From a report: 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. "Today, if a user wants to edit a local file in a web app, the web app needs to ask the user to open the file," said Google developer advocate Pete LePage. "Then, after editing the file, the only way to save changes is by downloading the file to the Downloads folder, or having to replace the original file by navigating the directory structure to find the original folder and file. This user experience leaves a lot to be desired, and makes it hard to build web apps that access user files."
To this end, 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."
To this end, 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."
Nah, I’ve tried and tried - but I really can’t see how this could possibly go wrong...
#DeleteChrome
If the user is choosing specifically where to navigate to, what is the risk?
This shit gets better and better.
The good news is that there is now a huge opportunity for yet another browser to quickly rise and supplant both Chrome and Firefox.
Take the best form both code bases, throw out the utterly fucking stupid parts like this, Pocket, and reporting every keystroke to Google, and boom Mosaic-NG puts them all to shame.
I'll make an awkward confession: I work on Windows PCs a lot. I've always immediately installed Firefox and more recently Chrome. But, for the past few months, I've been using Edge with success. It's as fast or faster than Chrome and it lacks Google's bullshit.
I know it can't last, but maybe I'll use Edge until Mosaic-NG is ready.
This post made with Firefox 50.1
and even more when the inevitable bugs in this api are exploited.
file this under #whatweretheythinking and #donotwant
"The API provides a lot of scary power to websites that WILL be abused in many terrible ways."
FTFY. Fix your current mound of security bugs to demonstrate you have the ability to make a secure API, and then you might be able to convince people you have the ability to actually make it secure.
"First they came for the slanderers and i said nothing."
Oh crap, this is going to be even worse than WASM.
WASM : Let malicious apps mine crytocurrencies
Writable files API: oh you didn't need that hosts file did you, let's just make it so that bank of america, citibank and wells fargo map to my fake bank website ip address, nobody will notice.
To say nothing of breaking existing ad blocking tech by erasing or whitelisting themselves.
probably much like the one google uses in it browser to take screenshots.
[($)]
Total job security coming our way, let the champagne bottles roll in!
Yours,
Infosec department
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Need software to be an application?
Have the user download the app and let that application have a "browser" GUI.
How deep should any random encrypted web site gat access deep into a user OS? Past ad blocking, past AV software? To move files around? To upload files found? To copy out file names?
Domestic spying is now "Benign Information Gathering"
Imagine the meltdown on /. if *Microsoft* was included in that group of companies trying to put this together.
There'd be no end to the same old tired, recycled jokes.
OTOH, substitute "Microsoft" with "Google" or "Mozilla", and this is pretty much what we're already getting...
Browsers frequently follow the "auto-execute random code" paradigm, where it just takes one rogue ad to redirect you to a page that tries to force a download of "java_update.exe".
Most programs (or the OS) at least remembers the last location at which the file was saved, thus you only have to navigate the directory structure the first time you have to open a specific file. That's why the save window often doesn't revert back to some default folder for each new file.
Not to mention that some of this directory navigation wouldn't be as difficult if apps made it easy to find their files.
I can remember laughing at people who thought it was possible to get a virus through email. And then...yeah, not laughing quite so much anymore. What the hell is this one? Ye gods.
64k memory and no swap space.
I guess all the cases of a faulty decompression valve are over even though many people still use them.
Once they are programming things for no good reason, well it's probably time for a new browser.
Anyone want to invest in one?
I don't feel this is secure and don't need it. If Mozilla implements this API in Firefox and doesn't allow me to opt-out of it and restrict it, I'll find a new web browser. It's not acceptable from a risk-reward perspective for someone who doesn't use web apps to edit files on one's hard drive.
Really, I think this should be blocked on an operating system level if possible, at least showing a dialogue box warning you when a website in your browser is trying to do this and giving the option to accept one-time only, decline one time only, or set to allows allow or always deny. If Windows 10 is going to keep being updates incessantly with questionable features and higher bug counts, they can at least give us this, or the browsers themselves don't.
It might be a good idea to ask some of the smaller browsers like Waterfox, Vivaldi, Pale Moon, and Basilik whether or not they are going to adopt this. Maybe one or more of them will make a good fallback if the more mainstream browsers and big operating system don't want to protect their users.
I kind of get when Google Chrome is doing this- Google wants everything done on the Internet because that's where their ads are and that's where they can get data on your to use to target you ads, and they will ignore obvious significant security concerns to achieve that. Why Mozilla would play follow the leader on this, I'm not sure. I guess they don't want to be perceived as lacking a feature the market leading browser has. However, this isn't a feature, it's a bug (See what I did there? :) ).
Didn't browser makers just spend years trying to isolate browsers in sandboxes as much as possible to protect the rest of your computer? This pretty much destroys the sandboxes for all intents and purposes, if implemented. It gives a malicious webpage the power to reach right through to your file system and edit at will.
Can't just be a browser, can it?
Forget about advancing the state of the art with quantum compute or AI,
Or solving problems like famine in Yemen -
As long as we can have a better user experience - I'm happy.
This is a really bad idea.
Of course the entire 'web' is a bad idea now that its been perverted into a client-heavy JavaScript infected cesspool. Long gone are the days of the original intent, a simple, lightweight display client.
HTML5 is turing-complete without JS. CSS3 and HTML5 is all that's needed.
In any case. You don't need to have Turing-complete code. The risk of security holes for any data that is processed, is proportional to that data's structural complexity. Period. Even simple syntaxes can be can be context-sensitive. Even if not intentionally.
So yes, whenever you receive *anything* from the outside, be very wary, limit the interface and the data's structural complexity as much as you can, and use hardened code, until you have processed it all. And don't forget, that UTF-8 is a quite complex code too.
Hell, this text here is a code to program your brain. What we speak/write, is the language of manipulation. And there is no person without bugs (triggers, ignorance/delusion, illusions, etc).
If the user wants to use a particular web program that messes with the user's files, then they can install a plugin from the webpage.
You know the next step: Someone will add another level of indirection to separate the newly capable browser from data that it must not touch, for example an automatic virtual machine to run the browser in an environment separate from the actual OS. And there go another 20% of the CPU power, wasted on an increasingly deep stack of abstractions which alternately separate things and join things, just because everybody latches onto the thing that everybody uses and tries to make it do their special trick too. It's a web browser, not an OS. It browses the web.
Just what is the real practical use case here?
The vast majority of editors out there are made to work with the storage being in the 'cloud'.
Google docs: you keep the file in Google Drive.
Confluence: you edit in confluence
That's the direction most apps are going. Are the current exceptions? Of course there are. Picture editors tend to work like how they describe in the article with the upload/edit/download phase. But some of these are even moving to cloud platforms.
I can personally think of a much safer/1st draft solution that solves 99% of the headaches that I have when encountering local files.
The problem is when you download a file, it doesn't know where it was on your local PC, so you have to navigate and that is annoying.
So you could have a simple mechanism
1. For the file upload dialog, the browser can pass the local file location to the website.
2. Upon download, the website passes this location back to the browser, so the browser can open the save dialog to that location.
This way the user is still involved at every step, just as they are now. Things like autosave are of course not availalbe, but for websites, this solves the major problem for most files. Mult-file edit problem are another story which can happen, but I think this 1st simple case solves most of it.
The obvious security hole here is the local file location being passed to the website. You wouldn't want that for every file upload, so a new component with security permissions would have to be created. But at least... even if it is compromised, it is not the worst thing. Just a file location.
You could complicate it by having this mechanism be local to the browser. So instead of passing the actual local file location, the browsers stores that in local storage, and passes some token value to the website. When the website passes this back to the browser, the browser does a lookup and starts the file download to that location.
The article raises the question of which security model os needed.
Security has been been studied a lot, and there are many well-defined models, an acronym soup of security models to choose from. Since this is my field, I've studied most all them to varying degrees.
There is a very simple answer to the question of which security model will prevent abuse while allowing the API to be useful. They need the U.N.I.C.O.R.N. security model. It's called UNICORN because it doesn't exist. There is no security they can put on this that will work.
Have the user download the app
We're sorry!
$APPNAME is not yet available for $PLATFORM. We apologize for the convenience.
In what way would a return to OS-specific applications be superior to what we have now? Even if you build your application using Qt or another multi-platform framework, and you cross-compile it, you can't cross-test the application on a machine that you don't have. And even if you can rent a remote desktop of a given platform through the Internet, responsiveness of a remote desktop through the Internet is not indicative of responsiveness when used locally.
Actually, third party scripts can't trigger a redirect. It's part of the standard.
If your claim is true, then most web browsers that I've used violate the standard, as I've seen third-party advertisement scripts on Slashdot redirect the browser to a fraudulent "Urgent Firefox Update" page.
First, you can't install a Chrome extension from a web page unless that web page is Chrome Web Store, and Google has been known to "curate" (i.e. censor) Chrome Web Store to remove extensions that hurt Google's business model.
Second, any platform integration functionality available in an extension has to be implemented in the browser through APIs that it exposes to extensions. What's the meaningful difference between making an API available to a website and making the same API available to a website-specific extension?
The vast majority of editors out there are made to work with the storage being in the 'cloud'.
Good luck with the "cloud" once you have left your wired router's cable range or Wi-Fi router's signal range and/or run out of cellular hotspot data for the month.
I feel like I've entered the twilight zone when I read an argument that storing my work on my machine is dangerous while storing it anywhere else is considered safe. Security has been compromised the moment my data isn't stored on my machine. Virtually every internet service today is a major security breach. And when someone tries to come up with something to reduce the near-requirement that all data be given up from inception, people call it a security threat? WTF? That's some pretty rich spin control.
Don't do it, don't even think about it.
So after all the major browsers went berserk banning all plugins in sight, now they want to bring back the same functionality all over again.
But, hey, now it doesn't come from those nasty, untrustworthy 3rd-party developers. The browser boys will do it right! Trust us!
I've been saying it for a long time. The real reason why plugins were killed is because it was technology that the browser developers couldn't control. It was all politics and security had nothing to do with it.
I foresee two main problems: 1) "hey in order to see the dancing pig, I first need you to upload this .DLL file from a certain directory. I lost mine. pls?"
File access granted, file overwritten with trojan, loaded and executed by Windows/whatever on boot.
2) File out of sync between two devices, old version autosaves over new version, which propagates to every connected device, and the new updates are gone forever everywhere.
An easy-ish solution to both is to never actually overwrite anything -- just make a new file every time changes are saved, and the browser maintains a database for what the most recent version of a file is (or just check timestamp in metadata/filename). DLLs won't get overwritten and loaded, and updated data won't be accidentally lost forever. Of course this does nothing to stop people from uploading sensitive data, but people can already do this.
Corruption is convincing someone that the selfless ideal is the same as their selfish ideal.
But I'm excited. I have apps I wrote for work that I can make function a lot smoother with this API
Actually, I wrote one of the early email viruses.
We just got new terminals with programmable function keys. Put an escape sequence in the text of the subject, and people wondered why they were suddenly locked out.
isn't a web app supposed to use JAVA? ... errr ... remember you, so that if you login with your unique token on another computer
once the java app is downloaded you can run it and give it access to your local storage (HDD).
you can also allow it so serve request from the mothership e.g. the site from which you original got the java web app?
the mothership can then profile
the JAVA web app gets downloaded (again) and it in return downloads all your junk (again)?
i guess, right-clicking on a google-web- app link and then clicking "save as ..." and plopping whatever comes your way into "/srv/www/htdocs" on you local 127.0.0.1 apache instance would be consider stealing?
google chrome engineers were not even ablle to manage CORS for local files (xml file are not allowed to load xsl) and they want to do THAT ?
WTF
If the user has write access to executables, then the OS is already being misused. That goes for every single program which installs itself in the user's directory instead of into Program Files or equivalent. Minecraft, Chrome... And that's where the problem lies. If you're backing up your data and you're using your OS correctly then so what if the browser can write out a file? It's not going to cause you any problems in that case. Unfortunately, users misuse systems, Windows was designed to be misused in particular, and of late a lot of app developers have taken the lazy route and implemented self-download and -update instead of bothering to integrate with package managers. This means that they have to write executables to your profile directory, which is a horrible and terrible mistake only made by lazy pricks who don't care how much they compromise the security of your system.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
why do files need to be edited in a "web app" again?
Well as one of the killers of chatzilla was the lack of a file access method in the conversion to webextentions. (https://bugzilla.mozilla.org/show_bug.cgi?id=1246236)
chroot and jails (https://www.freebsd.org/doc/handbook/jails-build.html) arent a new concept.I don't know what kinda overhead is involved in having each extension or page have a root based on its own namespace, but it doesn't seem impossible. However I do see a couple of things to abuse, filling up the file system with junk accidentally or on purpose, and does the browser dispose of the jailed files on quit, tab closure, some other criteria?
Perhaps another alternative would be a filestore file, like a VM file. The app doesn't actually write to the file system it only commits to its own blob. I also wonder if this could be sufficiently done via the already built in DB engine, which IIRC FF uses SQLite.
Not "could be abused", but rather "will be abused".
There is zero doubt of this, so why try to make it seem otherwise
gweihir KNOWS u IMPERSONATE me https://it.slashdot.org/commen... c6gunner proves it https://linux.slashdot.org/com... he forgot to SUBMIT as AC & using his registered 'lusrname' instead (because he tried to mock me both BEFORE & after I FAIRLY challenged him to show he's done better work - he had ZERO).
& NO WAY I'd "cry" like you "playing victim ne'er-do-wells" on /. (TROLL /.ers, not all) OR post on hosts offtopic.
YOU HELPED ME https://science.slashdot.org/c... (& you quit trying to make me look bad trying to "tell lies" on hosts as "ME" IN YOUR IMPERSONATIONS of me e.g. https://tech.slashdot.org/comm... as regards Intel speculative execution attack? Hosts PREVENT 'EM)
APK
P.S.=> I KNOW the 2nd to last link above's KILLING YOU - YOU ACTUALLY HELPED ME getting me to see if hosts stop more than portsmash (& Meltdown + Spectre too) & "lo & behold" - hosts WORK on 'em - U LOSE... apk
An API to gain root access?