3 ms·

Combining these two approaches would let you get rid of the IndexedDB abomination.

by wngr 5y ago

samwillis 5y ago
I believe FileSystemAccessAPI, as implemented in browsers, does not yet support block level access and locking. Both required to make this work, the developer behind Absurd SQL is working with the team designing the API to ensure it will have support. IndexedDB is the only way of doing this on browsers currently. https://github.com/WICG/file-system-access/issues/323 https://github.com/WICG/file-system-access/issues/323
- dmitriid 5y ago
  Unless I'm mistaken, FileSystemAccessAPI is only implemented in Chrome. Both Safari and Firefox are not implementing until four different file proposals (all from Chrome) can be reduced to one.
  - tehbeard 5y ago
    I thought Firefox flat out didn't want to implement FileSystem APIs on grounds of "security" and protecting their users?
    - ildon 5y ago
      Yes, many are refusing to implement it due to security concerns. A notable one is Brave, which is based on Chromium, and yet refuses to enable it (https://github.com/brave/brave-browser/issues/11407 https://github.com/brave/brave-browser/issues/11407). I'm skeptical that reducing access to the FS actually protects users. Those that would be fooled by scams based on FileSystemAccess APIs would very likely be fooled also with other less intricate tactics. So I doubt that the overall security of users is in practice affected. At least, browsers that refuse to implement the FileSystemAccess APIs could implement them, but leave them disabled by default, and require some non-trivial action to enable them. So users with a very basic understanding of how things work in the browser would not be able to enable them.
      - dmitriid 5y ago
        > 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.
    - samwillis 5y ago
      I wouldn't be surprised if some (or most) browsers don't implement the parts of the FileSystem API that are designed to access the users home directory (with permission). But the parts that are for a "sandboxed virtual drive" will be, that is what's needed for web apps and PWAs for saving their own data in a local block level storage (rather that IndexedDB or LocalStorage). That part of the api is very much designed for enabling things like WASM Sqlite. https://developer.mozilla.org/en-US/docs/Web/API/FileSystem https://developer.mozilla.org/en-US/docs/Web/API/FileSystem "This interface will not grant you access to the users filesystem. Instead you will have a "virtual drive" within the browser sandbox."
ildon 5y ago
If you need to use IndexedDB and you do not want to have to handle the absurdities of IndexedDB, give Dexie a try (https://dexie.org/ https://dexie.org/). It really makes using IndexedDB a breeze.

Combining these two approaches would let you get rid of the IndexedDB abomination.

by wngr 5y ago

Combining these two approaches would let you get rid of the IndexedDB abomination.

I believe FileSystemAccessAPI, as implemented in browsers, does not yet support block level access and locking. Both required to make this work, the developer behind Absurd SQL is working with the team designing the API to ensure it will have support. IndexedDB is the only way of doing this on browsers currently. https://github.com/WICG/file-system-access/issues/323 https://github.com/WICG/file-system-access/issues/323

dmitriid 5y ago
Unless I'm mistaken, FileSystemAccessAPI is only implemented in Chrome. Both Safari and Firefox are not implementing until four different file proposals (all from Chrome) can be reduced to one.
- tehbeard 5y ago
  I thought Firefox flat out didn't want to implement FileSystem APIs on grounds of "security" and protecting their users?
  - ildon 5y ago
    Yes, many are refusing to implement it due to security concerns. A notable one is Brave, which is based on Chromium, and yet refuses to enable it (https://github.com/brave/brave-browser/issues/11407 https://github.com/brave/brave-browser/issues/11407). I'm skeptical that reducing access to the FS actually protects users. Those that would be fooled by scams based on FileSystemAccess APIs would very likely be fooled also with other less intricate tactics. So I doubt that the overall security of users is in practice affected. At least, browsers that refuse to implement the FileSystemAccess APIs could implement them, but leave them disabled by default, and require some non-trivial action to enable them. So users with a very basic understanding of how things work in the browser would not be able to enable them.
    - dmitriid 5y ago
      > 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.
  - samwillis 5y ago
    I wouldn't be surprised if some (or most) browsers don't implement the parts of the FileSystem API that are designed to access the users home directory (with permission). But the parts that are for a "sandboxed virtual drive" will be, that is what's needed for web apps and PWAs for saving their own data in a local block level storage (rather that IndexedDB or LocalStorage). That part of the api is very much designed for enabling things like WASM Sqlite. https://developer.mozilla.org/en-US/docs/Web/API/FileSystem https://developer.mozilla.org/en-US/docs/Web/API/FileSystem "This interface will not grant you access to the users filesystem. Instead you will have a "virtual drive" within the browser sandbox."

ildon 5y ago

If you need to use IndexedDB and you do not want to have to handle the absurdities of IndexedDB, give Dexie a try (https://dexie.org/ https://dexie.org/). It really makes using IndexedDB a breeze.