Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Writable Files API: Simplifying Local File Access

developers.google.com

Post reply on HN
Print view View original

61–70 of 115 posts

Re: Web Writable Files API: Simplifying Local File Access

#61

Post by iforgotpassword »

the8472 wrote: post #60
joshfraser wrote: post #19

One of the great things about browsers is the way you can trust them to be reasonably sandboxed from the rest of your machine. Features like this chip away at that trust model and open up new attack vectors against unsuspecting users. I get the usability benefits, but the security implications are scary. How easy would it be to trick my mother into uploading her profile picture and have the site change that file into…

You could set the whole directory tree to no-execute via ACLs. Anyway, more interoperability with the native environment is a good thing. Right now browsers are an alien implant in every operating system that can't communicate with anything else.

Which is a good thing and should be kept that way. If you want to interoperate, release a program.

Re: Web Writable Files API: Simplifying Local File Access

#62

Post by why_only_15 »

the8472 wrote: post #60
joshfraser wrote: post #19

One of the great things about browsers is the way you can trust them to be reasonably sandboxed from the rest of your machine. Features like this chip away at that trust model and open up new attack vectors against unsuspecting users. I get the usability benefits, but the security implications are scary. How easy would it be to trick my mother into uploading her profile picture and have the site change that file into…

You could set the whole directory tree to no-execute via ACLs. Anyway, more interoperability with the native environment is a good thing. Right now browsers are an alien implant in every operating system that can't communicate with anything else.

Do ACLs exist in Windows? I suppose you could just forbid the .exe extension to be used, but that doesn't seem like a very foolproof system.

Re: Web Writable Files API: Simplifying Local File Access

#63

Post by icebraining »

politician wrote: post #50
fouc wrote: post #31

Earlier quoted context omitted.

And more than that, I honestly wonder about the motives of an advertising driven company these days. It feels like 5 years later this will come to bite us in the ass as another way of exploiting access to our computer and data. What if websites start requiring specific files to exist before allowing access?

> What if websites start requiring specific files to exist before allowing access? This is certainly going to be immediately abused for encrypted storage of persistent cookies and tracking identifiers. - If my site generates cat pics, I'll put identifiers in the metadata fields of the image format. - If my site generates markdown, I'll put identifiers in an alternate data stream (Windows) or encoded in the whitespace…

Nobody said the sites would have unfettered access to these files like they do with their cookies. Putting an ID on a photo is useless if you then have to ask the user to read it again the next time.

Also, why would they be outside the reach of adblockers? WebExtensions can already intercept and manipulate the use of certain APIs by sites, the same can easily apply here.

Re: Web Writable Files API: Simplifying Local File Access

#64

Post by devwastaken »

Klathmon wrote: post #36
devwastaken wrote: post #21

Earlier quoted context omitted.

Relying upon browser features for native access will be trouble. Google could revoke the feature from chromium at any time. And in any real application you will need to interact with plenty of folders users cannot be expected to know, like Appdata.

By that line of thinking relying on OS APIs will be trouble as Microsoft or Apple could remove features at any time.

If they are shiny new features, absolutely. Browser features, especially from Google, are notorious in being experimental and removed when they want to be. Browsers in general will remove things unless their internal teams find use for them. Browsers do not want to support more features than they have to, as can be seen by subscribing and listening in on the mailing lists for Firefox.

However your equivalence in this case is a completely false one, because file system API's are not going to just be 'removed' as that would break literally every application that uses standard fopen. over 20 years of standard is a pretty good boat to stand on unless there's signals that say otherwise.

Re: Web Writable Files API: Simplifying Local File Access

#65

Post by pjmlp »

xrd wrote: post #49
pjmlp wrote: post #44

Earlier quoted context omitted.

Apparently I can write files in ChromeOS. https://developer.chrome.com/apps/fileSystem

You get access to this if you have written a Chromebook app. If you get a user to install that, there is a clear set of permissions they are accepting. See the section on permissions, which is specified in the app manifest. It is not an open hole for anything running on a Chromebook.

Or a Chrome app, even though they are currently deprecated.

Yes the user needs to install it, and then it is free reign for $HOME.

So it isn't Download location only.

Re: Web Writable Files API: Simplifying Local File Access

#67

Post by icebraining »

EGreg wrote: post #59

I’m wondering how useful it is to save files on the local filesystem in 2018. I can understand syncing Google Drive and saving stuff there. Or Resilio Sync or any number of other solutions such as Dat. You Already have filepickers to open and read files. And you can save files as I indicated - via syncing to a service, where you have control of what goes where and it’s still there if you lose the device. And it can b…

Even in 2018, not everyone is online all the time, or has a connection capable of uploading large files (due to speed or caps). And frankly, it's just wasteful to upload everything.

Re: Web Writable Files API: Simplifying Local File Access

#68

Post by devwastaken »

ballenf wrote: post #48
devwastaken wrote: post #21

Earlier quoted context omitted.

Relying upon browser features for native access will be trouble. Google could revoke the feature from chromium at any time. And in any real application you will need to interact with plenty of folders users cannot be expected to know, like Appdata.

> And in any real application you will need to interact with plenty of folders users cannot be expected to know, like Appdata. I think a lot of what you'd store in Appdata in a "real" application will remain in browser storage or pulled from the server. A single file or folder with app settings, drafts, etc. should suffice. And even settings are probably better stored server side for user convenience so they can easi…

1. Completely unnecessary given native access

2. Native will be much faster

3. Native will allow for features from the kernel that browsers do not impliment.

4. You cannot plan for how people will use such a wide feature as the Filesystem. Saying 'X and Y should fit' requires a significant amount of honest research and testing, with a very good reason as to why the change is necessary.

Re: Web Writable Files API: Simplifying Local File Access

#69

Post by Klathmon »

devwastaken wrote: post #64
Klathmon wrote: post #36

Earlier quoted context omitted.

By that line of thinking relying on OS APIs will be trouble as Microsoft or Apple could remove features at any time.

If they are shiny new features, absolutely. Browser features, especially from Google, are notorious in being experimental and removed when they want to be. Browsers in general will remove things unless their internal teams find use for them. Browsers do not want to support more features than they have to, as can be seen by subscribing and listening in on the mailing lists for Firefox. However your equivalence in this…

Well sure you shouldn't rely on anything new for core aspects of your application without a plan for what happens if they go away. Especially when the API in question isn't even implemented yet...

But that's not how I understood your comment above, which was to not rely on any browser features for native access, which IMO isn't good advice.

Sure, you shouldn't go out and build a business around the "Web Writable Files API" tomorrow, but if it gets standardized, and if it gets implemented in a few major browser engines (which is a requirement for standardization in this context), then yeah go ahead and start to rely on it more.

But this has very little to do with these new proposed APIs, and more with general software development.

Re: Web Writable Files API: Simplifying Local File Access

#70

Post by rkagerer »

nine_k wrote: post #30
joshfraser wrote: post #19

One of the great things about browsers is the way you can trust them to be reasonably sandboxed from the rest of your machine. Features like this chip away at that trust model and open up new attack vectors against unsuspecting users. I get the usability benefits, but the security implications are scary. How easy would it be to trick my mother into uploading her profile picture and have the site change that file into…

As you surely noticed, for last 10 years the browser is actively trying to replace your desktop OS, so that the browser would become the platform, instead of Windows / macOS / Linux / anything else. Imagine the desktop becoming ChromeOS on any computer, not just Chromebooks. For this, the browser must make all the traditional OS interfaces available. It has interfaces for accelerated 2D and 3D graphics, audio, USB, p…

Am I the only crusty old fart who thinks this a lousy trend?

I worry the next talented generation of developers is being alienated from the desktop, and as a result my computing experience will degrade as Chrome's piecemeal attempts to reinvent the OS leave me with an inferior selection of browser-based toys that are awkward and clunky compared to their native counterparts.

I grant the browser fixes a couple things my OS got wrong: installation/uninstallation and updates. But it feels like it does everything else worse.

Post reply on HN