3 ms·

> So I doubt that the overall security of users is in practice affected. The problem is the sheer number of APIs that Chrome ships and wants other browsers to

> So I doubt that the overall security of users is in practice affected. The problem is the sheer number of APIs that Chrome ships and wants other browsers to ship, and what browsers already ship that require access via prompts: camera, location, notifications, file access, bluetooth, usb, motion sensors, serial ports, midi devices, clipboard... Just prompting user to allow stuff is no longer enough, and adding more prompts leads to worse security.

slaymaker1907 5y ago
It's sort of a double prompt scenario since the FileSystemAccessAPI requires users to actually select the file/directory for the web app to use. You can save the file handles into IndexedDB in which case the user will only be prompted if they refresh the page to authorize the web app to continue using that file/directory. From my use of it, the only real vulnerability I see is that Chrome still considers anything from file:// to be the same origin. This means as a developer you absolutely should not be saving file handles to IndexedDB if you are loading your app via file:// instead of https:// https://. This is a pretty niche use case, but I do think static html "apps" are an underappreciated form for distributing software and this new API makes such apps a lot more powerful. I wrote a plugin for TiddlyWiki that lets it operate really smoothly using this API https://github.com/slaymaker1907/TW5-browser-nativesaver https://github.com/slaymaker1907/TW5-browser-nativesaver that demonstrates why this API is worth the trouble.
- tehbeard 5y ago
  I'm not sure any API that requires "secure context" can be run from a file://, for those reasons.
  - slaymaker1907 5y ago
    Nope, I use the file system access API every day from file:// to take notes with Tiddlywiki.