4 ms·

The broader spec that OPFS is part of is (was?) suppose to give you just that: https://developer.chrome.com/docs/capabilities/web-apis/file-system-access https

The broader spec that OPFS is part of is (was?) suppose to give you just that: https://developer.chrome.com/docs/capabilities/web-apis/file-system-access https://developer.chrome.com/docs/capabilities/web-apis/file... This is another instance where Apple threw up their rails, and Firefox also seized the opportunity to throw up some rails. I don't think all their concerns were justified because you can control with very fine permissions what is and isn't exposed to the browser, which was the main source of contention. No alternative was presented. I believe this can be done in a privacy friendly way (the main stay of the objections). These are smart engineers, some of the best and the brightest, who supposedly are good at solving thorny problems. Simply, I think Apple didn't want to do it because it was remotely threatening to their iOS App Store and I wonder if some kind of anti-trust litigation may eventually expose their leadership around webkit like this. Then we'll know once and for all if its a grand conspiracy or not, I suppose

threeseed 3y ago
Apple did the right thing by blocking this. Because for every one PWA app there are dozens of websites who would use the local storage to store re-targeting metadata for advertising. It has nothing to do with the App Store and everything to do with basic tracking prevention. You can't block cookies and then allow local storage. Developers aren't stupid.
- no_wizard 3y ago
  There are ways to make sure that doesn’t happen, like making sure only the origin the file was written from can open and see the files. They should have put out a counter proposal. They certainly didn’t show it’s technically infeasible
  - threeseed 3y ago
    Everything has been moving to first party especially during the last year. So the origin is the one storing the tracking data, capturing it and sending it to Meta etc. Which is what makes this so hard as there is no difference between a PWA and a rogue website.
    - no_wizard 3y ago
      Now we're getting into the fundamental fact that some websites have lots of tracking and such, and some don't. This is no different than having to send the files to a server owned by the website. I fail to see any meaningful difference here. Should we also not allow HTTP requests? I don't see how this is different.
      - threeseed 3y ago
        We are talking about storing data on user's computers. If you allow PWA apps to do this. You also allow websites to use it for tracking. Hence why Apple restricted this feature.
        no_wizard 3y ago
        Storing data with user permissions, not permission-less. Its in no way like local storage or indexdb. Those permissions could be scoped to only allowing explict read/write of certain files (IE, the ones the user initiated) and not allow for arbitrary writing of files to the filesystem, for instance. We already do this with the file upload API
- jwells89 3y ago
  Exactly, requiring installation for long term persistence mitigates usage of the API for tracking and prevents storage usage from slowly snowballing over time as sites store random things the user probably doesn’t even care about. Should PWA installation be more obvious/straightforward than it is currently? Sure, but that’s a separate issue.
- alwillis 3y ago
  You can read about the privacy concerts the community group published [1]. [1]: https://wicg.github.io/file-system-access/#privacy-considerations https://wicg.github.io/file-system-access/#privacy-considera...
- JimDabell 3y ago
  > Apple did the right thing by blocking this. In order for a specification to become a web standard, it needs two independent implementations. No single organisation is capable of blocking it – it means that Google couldn’t convince anybody outside of Google to implement it.
JimDabell 3y ago
> I think Apple didn't want to do it because it was remotely threatening to their iOS App Store and I wonder if some kind of anti-trust litigation may eventually expose their leadership around webkit like this What actually happened: Mozilla rejected it on security grounds, then Apple agreed with Mozilla. How are you blaming Apple for Google putting together a bad spec. that no other browser vendor can accept? This happens time and time again. Google publish a specification that is not acceptable, both Mozilla and Apple reject it on privacy or security grounds, Google ships it in Chrome anyway, then people like you complain about Apple being mean. Here is Mozilla’s position: https://github.com/mozilla/standards-positions/issues/154 https://github.com/mozilla/standards-positions/issues/154 Here is Apple’s position: https://github.com/WebKit/standards-positions/issues/28 https://github.com/WebKit/standards-positions/issues/28

threeseed 3y ago

Apple did the right thing by blocking this. Because for every one PWA app there are dozens of websites who would use the local storage to store re-targeting metadata for advertising. It has nothing to do with the App Store and everything to do with basic tracking prevention. You can't block cookies and then allow local storage. Developers aren't stupid.

no_wizard 3y ago
There are ways to make sure that doesn’t happen, like making sure only the origin the file was written from can open and see the files. They should have put out a counter proposal. They certainly didn’t show it’s technically infeasible
- threeseed 3y ago
  Everything has been moving to first party especially during the last year. So the origin is the one storing the tracking data, capturing it and sending it to Meta etc. Which is what makes this so hard as there is no difference between a PWA and a rogue website.
  - no_wizard 3y ago
    Now we're getting into the fundamental fact that some websites have lots of tracking and such, and some don't. This is no different than having to send the files to a server owned by the website. I fail to see any meaningful difference here. Should we also not allow HTTP requests? I don't see how this is different.
    - threeseed 3y ago
      We are talking about storing data on user's computers. If you allow PWA apps to do this. You also allow websites to use it for tracking. Hence why Apple restricted this feature.
      - no_wizard 3y ago
        Storing data with user permissions, not permission-less. Its in no way like local storage or indexdb. Those permissions could be scoped to only allowing explict read/write of certain files (IE, the ones the user initiated) and not allow for arbitrary writing of files to the filesystem, for instance. We already do this with the file upload API
jwells89 3y ago
Exactly, requiring installation for long term persistence mitigates usage of the API for tracking and prevents storage usage from slowly snowballing over time as sites store random things the user probably doesn’t even care about. Should PWA installation be more obvious/straightforward than it is currently? Sure, but that’s a separate issue.
alwillis 3y ago
You can read about the privacy concerts the community group published [1]. [1]: https://wicg.github.io/file-system-access/#privacy-considerations https://wicg.github.io/file-system-access/#privacy-considera...
JimDabell 3y ago
> Apple did the right thing by blocking this. In order for a specification to become a web standard, it needs two independent implementations. No single organisation is capable of blocking it – it means that Google couldn’t convince anybody outside of Google to implement it.

JimDabell 3y ago

> I think Apple didn't want to do it because it was remotely threatening to their iOS App Store and I wonder if some kind of anti-trust litigation may eventually expose their leadership around webkit like this What actually happened: Mozilla rejected it on security grounds, then Apple agreed with Mozilla. How are you blaming Apple for Google putting together a bad spec. that no other browser vendor can accept? This happens time and time again. Google publish a specification that is not acceptable, both Mozilla and Apple reject it on privacy or security grounds, Google ships it in Chrome anyway, then people like you complain about Apple being mean. Here is Mozilla’s position: https://github.com/mozilla/standards-positions/issues/154 https://github.com/mozilla/standards-positions/issues/154 Here is Apple’s position: https://github.com/WebKit/standards-positions/issues/28 https://github.com/WebKit/standards-positions/issues/28