Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Mozilla Chrome Firefox Google

Google, Mozilla Working on Letting Web Apps Edit Files Despite Warning That it Could Be Abused (techrepublic.com) 112

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."

This discussion has been archived. No new comments can be posted.

Google, Mozilla Working on Letting Web Apps Edit Files Despite Warning That it Could Be Abused

Comments Filter:
  • ActiveX, anyone? (Score:5, Insightful)

    by 93 Escort Wagon ( 326346 ) on Friday November 23, 2018 @04:27PM (#57690056)

    Nah, I’ve tried and tried - but I really can’t see how this could possibly go wrong...

    • by fred911 ( 83970 )

      "canâ(TM)t see how this could possibly go wrong..."
      Ah... here's how..

      Microsoft Silverlight

    • by AHuxley ( 892839 )
      Microsoft Chrome https://en.wikipedia.org/wiki/... [wikipedia.org] expanded deep in to the OS from the browser :)
      • OK lets be brutally honest here. Are we concerned about security in the sense that Jimmy Fallon might not want his jokes stolen by his audience? Or is it more like NBC doesn't want to be responsible if a joke offends someone? C'mon, we're all friends, you can tell us hehe.
    • Re:ActiveX, anyone? (Score:5, Interesting)

      by nazsco ( 695026 ) on Friday November 23, 2018 @05:28PM (#57690326) Journal

      You forget one thing: Google!

      Google is microsoft plus advertising.

      When IE was pushing internet specs over W3c, it had nothing but the OS carrot pulling in users. If the website didn't like IE, it could just ask the user to change browsers, and the user did.

      Now we have Google, who controls both the users via chrome (and access to their own products, just like microsoft --try to use hangouts, which is required for interviews etc, without chrome!) but besides that, it also controls the websites via their Ad business.

      Now you have someone who have a monopoly on both user and site choices. Pushing one webstandard after another over everyone's heads. E.g. http2, http3... which is actually UDP...

      Here how it is going down: they will convince all the good engineers that could block this abusive idea that the feature will have lots of UI alerts. The first use case will be something like photoshopOnline. Then, when those smart people are not looking, they will make every site request the permission because they will use it for data persistence on their analytics code! then they will make this the default on chrome, because users complain about too many popups! then they will move this to data persistence for adWords et al. And at this point it is end game trying to not be tracked among devices and accounts on google ecosystem.

      • In a way it sounds good. Because if they drop turds in my filesystem, I can just delete them. Or even change/corrupt them.

        Perhaps we can even come up with a 'wrench in the works' utility for people to run.

      • by mentil ( 1748130 )

        How is 'local persistent tracking data' different from cookie files? That functionality already exists. There will be addons that delete these, if all that were to happen. Most people currently get 0 prompts for cookies, so it's unlikely Google would go to all that trouble.

    • by Anonymous Coward

      I think it's odd that literally every major comment in this discussion on /. is about security.
      Isn't there a much more important problem?
      This is a push to make sure that the software you'll use in the future isn't running (completely) on your system. Proprietary desktop software can at least in theory be reverse engineered or perhaps copied even if that means going against the law. But when part of the software is running on a server somewhere, what then?
      If this is going to go ahead, it will be yet another

    • by q4Fry ( 1322209 )

      Yeah, and it wasn't limited to files, either. Did you ever hit someone's website and have your CD tray physically eject from your tower?

  • by Anonymous Coward

    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 be

  • by Anonymous Coward

    and even more when the inevitable bugs in this api are exploited.

    file this under #whatweretheythinking and #donotwant

  • #doNotWant (Score:5, Insightful)

    by phantomfive ( 622387 ) on Friday November 23, 2018 @04:35PM (#57690108) Journal

    "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.

    • by AmiMoJo ( 196126 )

      What is this mound of security bugs you refer to? Modern Firefox and Chrome are both incredibly secure, especially considering they spend all day handling arbitrary data and running arbitrary scripts.

      We have had this panic several times before. Remember the Web USB API? That was going to be a security nightmare, massively abused and used to take over every poor sap's PC the moment it was deployed. Yet here we are, it's been around for years now, and somehow, presumably by blind luck rather than skill, they

      • What is this mound of security bugs you refer to?

        Just look here. [cvedetails.com]

        The main thing I would be looking to see here is if they can find a way to stop XSS exploits, because this API is going to have similar attack vectors.

      • What is this mound of security bugs you refer to?

        Probably this one..

        https://www.cvedetails.com/vul... [cvedetails.com]

        Modern Firefox and Chrome are both incredibly secure

        You got the "Incredible" part right.

        We have had this panic several times before. Remember the Web USB API?
        That was going to be a security nightmare,

        Um no Firefox does NOT support Web USB... Chrome is alone in this madness.

        It very much has been a security nightmare.
        https://pwnaccelerator.github.... [github.io]

        massively abused and used to take over every poor sap's PC the moment it was deployed. Yet here we are, it's been around for years now, and somehow, presumably by blind luck rather than skill, they managed to make it secure.

        What does Web USB have to do with granting web sites write access to local filesystem? I fail to see the linkage. They are two separate features with separate security properties. Each must be evaluated on the merits not by some ridiculous unfalsifiable false equivale

    • 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

      • 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.

        Yeah, I tend to agree. The best Google can hope for here is an API that lets them constantly answer criticism by saying, "Developers are using the API wrong! That's why it's insecure!" While ignoring the fact that the very nature of the API makes it practically impossible to not use 'wrong'

    • Of course it will be abused in many terrible ways. But at some point you have to ask yourself to what extend do you wish to restrict what a user can do with their own machine. I mean this web-app thing is no different than a normal app downloaded from the web. Do we go the Apple way and curate the entire experience while blocking file system access through insane APIs?

      There's a reason the computer has survived the age of the iPad, it's because it's useful.

      • Do we go the Apple way and curate the entire experience while blocking file system access through insane APIs?

        Yeah I think blocking access to the filesystem is the right way to go here.

        Again, if you can stop XSS problems, then give this a try. Otherwise it's just going to be a mess.

  • by Anonymous Coward

    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.
  • by Opportunist ( 166417 ) on Friday November 23, 2018 @04:39PM (#57690148)

    Total job security coming our way, let the champagne bottles roll in!

    Yours,
    Infosec department

  • 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?
    • 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?

      The Microsofts and Googles of the world have long, long wanted to blur the lines between what's on your machine, and what's elsewhere. ("Web desktop", anyone?)

      I can totally see them wanting web apps to seamlessly edit files on your computer.

    • 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 indicati

  • by Anonymous Coward

    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...

  • by Sigma 7 ( 266129 ) on Friday November 23, 2018 @05:02PM (#57690226)

    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".

    navigating the directory structure to find the original folder and file.

    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.

    • by AmiMoJo ( 196126 )

      Actually, third party scripts can't trigger a redirect. It's part of the standard.

      Also most browsers don't allow downloads to be triggered by redirects or Javascript, only direct user interaction. That's why sites started trying to trick users into clicking stuff rather than auto-downloading. And even that doesn't work very well because once you tricked the user they still have to click through multiple warnings and their AV software has to fail before your code gets to run.

      The argument that modern browsers

      • 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.

      • by Sigma 7 ( 266129 )

        Actually, third party scripts can't trigger a redirect. It's part of the standard.

        I've had this standard violated within the past month when listening to Internet radio. Leave radio running in the background, then suddenly the page is redirected to some virus alert. Another person i help with tech support also reports getting redirected to a virus alert page as well.

        We used to have fun crashing mail clients and IRC clients and even FTP servers with some dodgy data.

        More often than not, such crashing is an e

    • 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 yo

  • 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.
    • 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.

  • by Anonymous Coward on Friday November 23, 2018 @05:29PM (#57690330)

    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? :) ).

    • by Luthair ( 847766 )
      Which browser would that be, Edge? One imagines Microsoft might want this for Office so maybe Internet Explorer 11?
    • by Anonymous Coward

      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-in 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.

      FTFY.

      No-one should have something like this turned on by default. Especially in a program who's entire purpose is downloading random stuff from the internet. No sane person would suggest this as a good thing to add dur

  • Can't just be a browser, can it?
  • 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.

    • I was just thinking.. isn't this the sort of "functionality" that was installed by various Java(TM) plugins years ago? And for which the same plugins were condemned for being insecure? Seems like a poor idea to bundle this with the browser now..
    • 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-specifi

      • Both of these points directly highlight the real issue: it's about control.

        Technically, nobody forces you to use a plugin, and everything can be disabled by default unless you turn it on. It's a user choice. By banning plugins and using only "standard" APIs implemented by the browser developers, they ensure everything is under their control. Same reason for forcing signed extensions, which was always a bad idea. They'll allow it only if they like it. Users can't be allowed to make choices we think are

  • 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

    • by Anonymous Coward

      But at least... even if it is compromised, it is not the worst thing. Just a file location.


      X-File-Upload-Local-Source: C:\Users\Anon Y. Mous\Documents\Work\Old Jobs\Data\Totally NOT PORN\kinky\Personal Fetishes\34028492094204.jpg

      Yeah, gives a whole new meaning to sanitizing the meta-data now doesn't it?

    • 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.

  • by RhettLivingston ( 544140 ) on Friday November 23, 2018 @11:29PM (#57691422) Journal

    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.

    • 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.

      Most browsers support local storage for applications. Websites are able to store data on your local computer in a local file store that only the site can access. Websites are currently also able to prompt you to upload files from your computer and save files to your computer.

      Security has been compromised the moment my data isn't stored on my machine.

      More likely it was compromised before that when software was loaded / executed from someone else's machine.

      Virtually every internet service today is a major security breach.

      People who don't want to be owned run software from vendors they trust and don't let it screw around on the Internet.

      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.

      The reason

  • 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

  • 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 p

  • 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

  • Not "could be abused", but rather "will be abused".
    There is zero doubt of this, so why try to make it seem otherwise
  • An API to gain root access?

news: gotcha

Working...