4 ms·

So store this data on the server.

by im3w1l 7y ago

tssva 7y ago
The original comment referenced an app where the users are offline for weeks at a time. Storing data on a server is not really possible in this use case.
matsemann 7y ago
But wouldn't that make it have less privacy? Now my webapp cannot be used offline and anonymously, user has to be logged in and tracked
- im3w1l 7y ago
  It doesn't change the status quo. Important data wasn't put in cookies before, and it wont be after. It was always a recipe for data loss. Server side, or if you need privacy, have the user export to / import from a local file.
  - felixfbecker 7y ago
    This is also about IndexedDB. Imagine native apps had all their data wiped if you don't open them (with an active internet connection) every 7 days. Not just on an iPhone, but also on macOS.
    - Grimm1 7y ago
      This impacts an app I've built for reading academic papers but I imagine the work around here is to write to a file periodically and then load the file in if you don't detect indexedDB having the data you think it should. Obviously this has error cases all its own and makes it more difficult to manage but it doesn't seem like Apple is killing it to me, just making us jump through hoops and add extra complexity. Don't mistake me though this seems like an anti-competitive move from them to prevent people from circumventing the app store.
      - cmsj 7y ago
        I apologise for being rude, but IMO you didn't build an app, you built a web page. Web pages are things people look at one time or maybe many times, but they are just web pages that exist in a web browser for the lifetime of the tab they're in, and then they're gone. They shouldn't expect to have any persistent storage from the browser, and if the browser does make small affordances for storage, it's not reasonable to have that persist indefinitely. Apps are bundles of code/assets that people choose to install on a computer because they want to use them over time to do something. They have a clear lifecycle of installation and deletion that the user has complete control over. I know the web app, PWA, offline app, etc. stuff is very popular, but it will never be as good as native apps, and it creates an expectation that every browser will expand its functionality until it is effectively a full operating system. I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle, but I would still honestly prefer that people just write a native application.
        6510 7y ago
        I really liked the web when it was just documents. > you didn't build an app, you built a web page "Progressive web apps use modern web APIs" The word application is there twice. I don't have to like it. > they are just web pages that exist in a web browser for the lifetime of the tab they're in Evidently not. My opinion doesn't matter. > They shouldn't expect to have any persistent storage 2016 "With Chrome 52, we're introducing the ability to make storage persistent" > ...a clear lifecycle of installation and deletion that the user has complete control over. I've never asked for 7 days > it will never be as good as native apps I don't develop anything for walled gardens. I cant wait for my linux phone. > it creates an expectation that every browser will expand its functionality until it is effectively a full operating system. This already happened. Again, I don't have to like it. > I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle But the user isn't given control over the life cycle. It's 7 days. No one asked for 7 days. It's just about short enough to be completely worthless? I propose an interface where the pwa provides a picture of a cartoon animal, have fire at the bottom of the screen and each creature tumbling down at its chosen speed. Some 1 day, some 30, some 6 months. The user can opt to drag it up to save it. Notify the user with a soft screaming sound. This is how it should work!
    - theamk 7y ago
      The big difference is native apps require explicit user content to get installed, while localstorage can be used by any website without user consent. If browsers asked approval before using localstorage, we wouldn’t have this decision.
      - roblabla 7y ago
        Apple is actively refusing to implement the standard for installable webapps (PWA). So, Apple is intentionally crippling a feature on the grounds of privacy with no possible remedy. This decision comes from an actor that is protecting their business interests. It might have some positive side-effect for some users, and of course Apple will spin it that way. But in the end Apple is very agressively hampering the web's progress to get their sweet 30% cut.
        tomnipotent 7y ago
        Can you link me to a standard? I checked the W3C, and other than the disparate API's used by PWA's I don't see a "PWA standard" anywhere.
        roblabla 7y ago
        The standard is called "web app manifest". You can find it at https://w3c.github.io/manifest/ https://w3c.github.io/manifest/. Note that Apple does support PWA to some degree. My understanding is that they don't support onbeforeinstallprompt, which means you can't create an ergonomic, in-browser installation flow. You have to manually go in the browser menu to find an "Add to Homescreen" button, or something along those lines.
      - vbezhenar 7y ago
        Installation of web app performed by bookmarking it or by pinning it to home screen. That's performed by explicit user decision and must be honored by browser if it wants to make a distinction between random website and useful website.
        7y ago
  - Turing_Machine 7y ago
    > have the user export to / import from a local file. Exporting to local files does not work on iOS if the app has been saved to the home screen (it does work if it's loaded as a normal web page). This is likely a bug, but that's the way it is right now.
- SalimoS 7y ago
  If it’s your app how not being tracked is an argument ? I mean you just can just not track him (unless I’m not understanding your point)
  - matsemann 7y ago
    Of course, I can make my backend service well-behaving. But offline first is privacy by default, which I'd argue is a better approach.
- theamk 7y ago
  For your app, maybe. But most apps cannot be used offline at all, and instead they use localstorage as another place that can store tracking cookie. So as a user, I fully support this change, because there should not be a loophole like this.
  - pier25 7y ago
    There are many legit uses for localStorage. Storing JWTs, game state data, etc.
    - shirshak55 7y ago
      why to store JWT in local storage. Localstorage can be accessed by CDN scripts also. Please don't put risk on ur users data.
      - dmix 7y ago
        Localstorage is limited to a domain, a common security model in the browser also used by cookies, and prevents cross-origin leaks... (unless a developer volunteers to expose the data via postmessage whose destination can also be limited to specific origins). This is also why it is important to load your apps JS on your domain or same-origin and not offloaded to a 3rd party server which you might not control (libraries like jQuery CDNs and whatnot are still a minor risk, particularly from a privacy perspective, but not as bad, although I never saw the point with the large variety of versions).
        valand 7y ago
        It's sad there are people not aware that cross-origin policies are actually helping them. They are the most misunderstood, hated policies.
    - danbolt 7y ago
      I have an old HTML5 game I made that stores a high score in localStorage. I might have to figure out an alternative solution later down the road.
untog 7y ago
You say that as if it isn’t an absolutely giant extra piece of functionality and ongoing cost. That native apps won’t have to do.
Touche 7y ago
Cool, so now my movie library app has to host terabytes worth of movies and deal with copyright laws, just because Apple assumes that anyone using IndexedDB must have malicious intent.
TomGullen 7y ago
Would make our app non functional for users who have limited internet and also a huge burden of responsibility to store their data securely. We’ve always avoided hosting data as that’s a completely different ballgame.

So store this data on the server.

by im3w1l 7y ago

So store this data on the server.

The original comment referenced an app where the users are offline for weeks at a time. Storing data on a server is not really possible in this use case.

matsemann 7y ago

But wouldn't that make it have less privacy? Now my webapp cannot be used offline and anonymously, user has to be logged in and tracked

im3w1l 7y ago
It doesn't change the status quo. Important data wasn't put in cookies before, and it wont be after. It was always a recipe for data loss. Server side, or if you need privacy, have the user export to / import from a local file.
- felixfbecker 7y ago
  This is also about IndexedDB. Imagine native apps had all their data wiped if you don't open them (with an active internet connection) every 7 days. Not just on an iPhone, but also on macOS.
  - Grimm1 7y ago
    This impacts an app I've built for reading academic papers but I imagine the work around here is to write to a file periodically and then load the file in if you don't detect indexedDB having the data you think it should. Obviously this has error cases all its own and makes it more difficult to manage but it doesn't seem like Apple is killing it to me, just making us jump through hoops and add extra complexity. Don't mistake me though this seems like an anti-competitive move from them to prevent people from circumventing the app store.
    - cmsj 7y ago
      I apologise for being rude, but IMO you didn't build an app, you built a web page. Web pages are things people look at one time or maybe many times, but they are just web pages that exist in a web browser for the lifetime of the tab they're in, and then they're gone. They shouldn't expect to have any persistent storage from the browser, and if the browser does make small affordances for storage, it's not reasonable to have that persist indefinitely. Apps are bundles of code/assets that people choose to install on a computer because they want to use them over time to do something. They have a clear lifecycle of installation and deletion that the user has complete control over. I know the web app, PWA, offline app, etc. stuff is very popular, but it will never be as good as native apps, and it creates an expectation that every browser will expand its functionality until it is effectively a full operating system. I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle, but I would still honestly prefer that people just write a native application.
      - 6510 7y ago
        I really liked the web when it was just documents. > you didn't build an app, you built a web page "Progressive web apps use modern web APIs" The word application is there twice. I don't have to like it. > they are just web pages that exist in a web browser for the lifetime of the tab they're in Evidently not. My opinion doesn't matter. > They shouldn't expect to have any persistent storage 2016 "With Chrome 52, we're introducing the ability to make storage persistent" > ...a clear lifecycle of installation and deletion that the user has complete control over. I've never asked for 7 days > it will never be as good as native apps I don't develop anything for walled gardens. I cant wait for my linux phone. > it creates an expectation that every browser will expand its functionality until it is effectively a full operating system. This already happened. Again, I don't have to like it. > I think the only reasonable case for the web-as-app model, is things that get installed to the home screen, in the sense that the user is then again given control of the lifecycle But the user isn't given control over the life cycle. It's 7 days. No one asked for 7 days. It's just about short enough to be completely worthless? I propose an interface where the pwa provides a picture of a cartoon animal, have fire at the bottom of the screen and each creature tumbling down at its chosen speed. Some 1 day, some 30, some 6 months. The user can opt to drag it up to save it. Notify the user with a soft screaming sound. This is how it should work!
  - theamk 7y ago
    The big difference is native apps require explicit user content to get installed, while localstorage can be used by any website without user consent. If browsers asked approval before using localstorage, we wouldn’t have this decision.
    - roblabla 7y ago
      Apple is actively refusing to implement the standard for installable webapps (PWA). So, Apple is intentionally crippling a feature on the grounds of privacy with no possible remedy. This decision comes from an actor that is protecting their business interests. It might have some positive side-effect for some users, and of course Apple will spin it that way. But in the end Apple is very agressively hampering the web's progress to get their sweet 30% cut.
      - tomnipotent 7y ago
        Can you link me to a standard? I checked the W3C, and other than the disparate API's used by PWA's I don't see a "PWA standard" anywhere.
        roblabla 7y ago
        The standard is called "web app manifest". You can find it at https://w3c.github.io/manifest/ https://w3c.github.io/manifest/. Note that Apple does support PWA to some degree. My understanding is that they don't support onbeforeinstallprompt, which means you can't create an ergonomic, in-browser installation flow. You have to manually go in the browser menu to find an "Add to Homescreen" button, or something along those lines.
    - vbezhenar 7y ago
      Installation of web app performed by bookmarking it or by pinning it to home screen. That's performed by explicit user decision and must be honored by browser if it wants to make a distinction between random website and useful website.
      - 7y ago
- Turing_Machine 7y ago
  > have the user export to / import from a local file. Exporting to local files does not work on iOS if the app has been saved to the home screen (it does work if it's loaded as a normal web page). This is likely a bug, but that's the way it is right now.
SalimoS 7y ago
If it’s your app how not being tracked is an argument ? I mean you just can just not track him (unless I’m not understanding your point)
- matsemann 7y ago
  Of course, I can make my backend service well-behaving. But offline first is privacy by default, which I'd argue is a better approach.
theamk 7y ago
For your app, maybe. But most apps cannot be used offline at all, and instead they use localstorage as another place that can store tracking cookie. So as a user, I fully support this change, because there should not be a loophole like this.
- pier25 7y ago
  There are many legit uses for localStorage. Storing JWTs, game state data, etc.
  - shirshak55 7y ago
    why to store JWT in local storage. Localstorage can be accessed by CDN scripts also. Please don't put risk on ur users data.
    - dmix 7y ago
      Localstorage is limited to a domain, a common security model in the browser also used by cookies, and prevents cross-origin leaks... (unless a developer volunteers to expose the data via postmessage whose destination can also be limited to specific origins). This is also why it is important to load your apps JS on your domain or same-origin and not offloaded to a 3rd party server which you might not control (libraries like jQuery CDNs and whatnot are still a minor risk, particularly from a privacy perspective, but not as bad, although I never saw the point with the large variety of versions).
      - valand 7y ago
        It's sad there are people not aware that cross-origin policies are actually helping them. They are the most misunderstood, hated policies.
  - danbolt 7y ago
    I have an old HTML5 game I made that stores a high score in localStorage. I might have to figure out an alternative solution later down the road.

untog 7y ago

You say that as if it isn’t an absolutely giant extra piece of functionality and ongoing cost. That native apps won’t have to do.

Touche 7y ago

Cool, so now my movie library app has to host terabytes worth of movies and deal with copyright laws, just because Apple assumes that anyone using IndexedDB must have malicious intent.

TomGullen 7y ago

Would make our app non functional for users who have limited internet and also a huge burden of responsibility to store their data securely. We’ve always avoided hosting data as that’s a completely different ballgame.