4 ms·

I think this will be great for extensions. Currently the only solid choice is to use the dead simple storage.local which only allows to retrieve things by ID.

I think this will be great for extensions. Currently the only solid choice is to use the dead simple storage.local which only allows to retrieve things by ID. There's one problem though, this new API is for the web, so the nature of this storage is temporary - obviously the user must be able to clear it when clearing site data and this what makes it currently an unviable solution for a persistent extensions data storage. https://bugs.chromium.org/p/chromium/issues/detail?id=1383216 https://bugs.chromium.org/p/chromium/issues/detail?id=138321...

dfghjkjhg 4y ago
yeah because full access to the filesystem is only solution. asking for permission to a longer storage.local exemption for the user? noooo let's not even think about giving user control of things. let's the European union pass post-fact legislation after file system access is abused by adnetworks. then they get the blame of being annoying, not the browser vendor who sell ads. let's stop being naive. there are a million ways to fix that bug with better UX and respect for user control, but this is a scape goat to have that feature.
encryptluks2 4y ago
Agreed, people want permission based file system access and so I don't see why a site can't prompt a user to store a file in a user-specified location. If they clear their site settings then giving permission to the same file should retain their data. I don't want to have to worry about losing something important or having my browser act as a file system.
- mr_toad 4y ago
  > I don't see why a site can't prompt a user to store a file in a user-specified location. This is already possible with the file system access API. Clearing site data has no impact on these files. But you do have to re-grant permission every time you reload the page. https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API https://developer.mozilla.org/en-US/docs/Web/API/File_System...
  - encryptluks2 4y ago
    Therein lies the problem, because it should only re-prompt for permission only when you clear the site settings. Additionally, as far as I'm aware or at least last time I checked this doesn't enable directory based permissions, so a web IDE wouldn't be able to browser a directory or sub-directories after given permission.
    - 8n4vidtmkvmk 4y ago
      > Additionally, as far as I'm aware or at least last time I checked this doesn't enable directory based permissions, I haven't tried it yet, but I thought it did.. the first 3 paragraphs of the comment you're responding to all mention directories > This API allows interaction with files on a user's local device, or on a user-accessible network file system. Core functionality of this API includes reading files, writing or saving files, and access to directory structure. > Most of the interaction with files and directories is accomplished through handles. A parent FileSystemHandle class helps define two child classes: FileSystemFileHandle and FileSystemDirectoryHandle, for files and directories respectively. > The handles represent a file or directory on the user's system. You can first gain access to them by showing the user a file or directory picker using methods such as window.showOpenFilePicker() and window.showDirectoryPicker(). Once these are called, the file picker presents itself and the user selects either a file or directory. Once this happens successfully, a handle is returned.
svnpenn 4y ago
> the user must be able to clear it when clearing site data and this what makes it currently an unviable solution What are you suggesting here? That extensions should have some special storage, that can't be (easily) deleted? Noooooooo thank you. Firefox has "forget about this site" and similar tools, which I use near daily. Don't fuck with my ability to do housekeeping.
- kevingadd 4y ago
  You would want storage associated with the extension, not with a website.
oefrha 4y ago
I’m getting Flash flashbacks. Flash apps had filesystem access in a designated area, with some amount of user control, that is not easily wiped from the browser; Flash games used that for saves and data. Years after the demise of Flash, the web platform is still catching up.
- mckravchyk 4y ago
  It's different though, extensions are like local apps and deserve persistent storage, while you are talking about how Flash was being used by remote sources. Also my proposed approach is that this data would be wiped when the extension is removed from the browser - which is what happens for storage.local
  - westurner 4y ago
    Some way to indicate which "WASM contexts" (?) have utilized how much disk space would be great for open source multiple implementations not-Flash, too. From https://news.ycombinator.com/item?id=32953286 https://news.ycombinator.com/item?id=32953286 https://westurner.github.io/hnlog/#story-32950199 https://westurner.github.io/hnlog/#story-32950199 : > - [ ] UBY: Browsers: Vary the {color, size, fill} of the tab tabs according to their relative resource utilization And then that tabs are (sandboxed) subprocesses running as the same user though. Containers may have unique SELinux MCS labels, and browser tab processes probably should too. containers/container-selinux: https://github.com/containers/container-selinux https://github.com/containers/container-selinux https://github.com/kai5263499/awesome-container-security/issues/6 https://github.com/kai5263499/awesome-container-security/iss... > - [ ] ENH,SEC: Browsers: specify per-tab/per-domain resource quotas: CPU, RAM, Disk, [GPU, TPU, QPU] (Linux: cgroups,) Like Flash
m00x 4y ago
Isn't that what the File System Access API is for? It allows you to open files on your own machine near-natively.
- zamadatix 4y ago
  Both APIs are part of the same standard. If you just want to store things for your site/webapp you want the origin private filesystem and you can just go for it. If you want to do something with one of the user's files it requires interaction from the user to select the folder/file since it'd be a security nightmare otherwise. You can also do both e.g. store a bunch of backend stuff for your photo editing webapp in the origin private filesystem but prompt the user to select their images folder so they can start editing them.

dfghjkjhg 4y ago

yeah because full access to the filesystem is only solution. asking for permission to a longer storage.local exemption for the user? noooo let's not even think about giving user control of things. let's the European union pass post-fact legislation after file system access is abused by adnetworks. then they get the blame of being annoying, not the browser vendor who sell ads. let's stop being naive. there are a million ways to fix that bug with better UX and respect for user control, but this is a scape goat to have that feature.

encryptluks2 4y ago

Agreed, people want permission based file system access and so I don't see why a site can't prompt a user to store a file in a user-specified location. If they clear their site settings then giving permission to the same file should retain their data. I don't want to have to worry about losing something important or having my browser act as a file system.

mr_toad 4y ago
> I don't see why a site can't prompt a user to store a file in a user-specified location. This is already possible with the file system access API. Clearing site data has no impact on these files. But you do have to re-grant permission every time you reload the page. https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API https://developer.mozilla.org/en-US/docs/Web/API/File_System...
- encryptluks2 4y ago
  Therein lies the problem, because it should only re-prompt for permission only when you clear the site settings. Additionally, as far as I'm aware or at least last time I checked this doesn't enable directory based permissions, so a web IDE wouldn't be able to browser a directory or sub-directories after given permission.
  - 8n4vidtmkvmk 4y ago
    > Additionally, as far as I'm aware or at least last time I checked this doesn't enable directory based permissions, I haven't tried it yet, but I thought it did.. the first 3 paragraphs of the comment you're responding to all mention directories > This API allows interaction with files on a user's local device, or on a user-accessible network file system. Core functionality of this API includes reading files, writing or saving files, and access to directory structure. > Most of the interaction with files and directories is accomplished through handles. A parent FileSystemHandle class helps define two child classes: FileSystemFileHandle and FileSystemDirectoryHandle, for files and directories respectively. > The handles represent a file or directory on the user's system. You can first gain access to them by showing the user a file or directory picker using methods such as window.showOpenFilePicker() and window.showDirectoryPicker(). Once these are called, the file picker presents itself and the user selects either a file or directory. Once this happens successfully, a handle is returned.

svnpenn 4y ago

> the user must be able to clear it when clearing site data and this what makes it currently an unviable solution What are you suggesting here? That extensions should have some special storage, that can't be (easily) deleted? Noooooooo thank you. Firefox has "forget about this site" and similar tools, which I use near daily. Don't fuck with my ability to do housekeeping.

kevingadd 4y ago
You would want storage associated with the extension, not with a website.

oefrha 4y ago

I’m getting Flash flashbacks. Flash apps had filesystem access in a designated area, with some amount of user control, that is not easily wiped from the browser; Flash games used that for saves and data. Years after the demise of Flash, the web platform is still catching up.

mckravchyk 4y ago
It's different though, extensions are like local apps and deserve persistent storage, while you are talking about how Flash was being used by remote sources. Also my proposed approach is that this data would be wiped when the extension is removed from the browser - which is what happens for storage.local
- westurner 4y ago
  Some way to indicate which "WASM contexts" (?) have utilized how much disk space would be great for open source multiple implementations not-Flash, too. From https://news.ycombinator.com/item?id=32953286 https://news.ycombinator.com/item?id=32953286 https://westurner.github.io/hnlog/#story-32950199 https://westurner.github.io/hnlog/#story-32950199 : > - [ ] UBY: Browsers: Vary the {color, size, fill} of the tab tabs according to their relative resource utilization And then that tabs are (sandboxed) subprocesses running as the same user though. Containers may have unique SELinux MCS labels, and browser tab processes probably should too. containers/container-selinux: https://github.com/containers/container-selinux https://github.com/containers/container-selinux https://github.com/kai5263499/awesome-container-security/issues/6 https://github.com/kai5263499/awesome-container-security/iss... > - [ ] ENH,SEC: Browsers: specify per-tab/per-domain resource quotas: CPU, RAM, Disk, [GPU, TPU, QPU] (Linux: cgroups,) Like Flash

m00x 4y ago

Isn't that what the File System Access API is for? It allows you to open files on your own machine near-natively.

zamadatix 4y ago
Both APIs are part of the same standard. If you just want to store things for your site/webapp you want the origin private filesystem and you can just go for it. If you want to do something with one of the user's files it requires interaction from the user to select the folder/file since it'd be a security nightmare otherwise. You can also do both e.g. store a bunch of backend stuff for your photo editing webapp in the origin private filesystem but prompt the user to select their images folder so they can start editing them.