7 ms·

I don't think that's actually what it clarifies. Or at the very least it's very confusing. > have their own counter of days of use. Their days of use will matc

by untog 7y ago

I don't think that's actually what it clarifies. Or at the very least it's very confusing. > have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer. This makes it sound very much like homescreen apps will have their data wiped after 7 days of non-use. > We do not expect the first-party in such a web application to have its website data deleted. And this does not. It's a very confusing word salad.

gridlockd 7y ago
Yes, it's confusing. It's not 7 days of non-use, it's seven days of application use without visiting the site. Safari is one application, the homescreen app is a separate application. Presumably, all the alt browsers or WebView apps are separate applications as well. Since you can't use a homescreen app without visiting the site, the 7 days of not visiting the site can't happen.
- untog 7y ago
  Ah OK that makes sense. They should really copy and paste what you just said into their post!
- deleted 7y ago
  [deleted]
- emmelaich 7y ago
  But .. if you don't use Safari for seven days, what happens?
  - deleted 7y ago
    [deleted]
  - eyelidlessness 7y ago
    From their description, nothing. Seven days of use without visiting triggers deletion. Failing to satisfy either of those conditions (either by disuse of Safari, or by visiting the site within seven days) doesn't.
- rhizome 7y ago
  So this is a requirement that all webapps phone home, moreover that they have a home to phone?
  - untog 7y ago
    No, this is all internal to the browser, no requirement to send a remote request.
    - deleted 7y ago
      [deleted]
  - manicdee 7y ago
    It’s a requirement that some time within the next seven days of app usage, the user interacts with the web app. This might cause trouble if the web app is simply a list of timers which the user interacts with passively (map of earth showing day/night zones), but if there is any interaction at all the timer resets.
  - numpad0 7y ago
    I'm not getting the semantics clear but wonder whether having the icon on the homescreen counts as "visiting" or whether suspending the app first day and reopening it the next day counts app-subjectively as "continuing day one" or "reopening immediately"
- pier25 7y ago
  will it be "7 days of non-use" for regular websites that use localStorage? You can't really have "seven days of application use without visiting the site".
  - Gaelan 7y ago
    For "regular websites" (visited through Safari) it's 7 days where you use Safari, but don't visit the site. So if you go on vacation for a month and don't touch your computer, or if you switch completely to using Firefox for a month, localStorage will remain untouched.
    - pier25 7y ago
      Where is this explained?
      - saagarjha 7y ago
        https://news.ycombinator.com/item?id=22681370 https://news.ycombinator.com/item?id=22681370
        pier25 7y ago
        Hmm no mention about "regular websites" there...
        saagarjha 7y ago
        I fail to see why you need to see a mention of "regular websites". The comment clarifies the situation of what occurs if a user goes on vacation or switches to another browser: nothing will be deleted, as Safari is not being used.
- Touche 7y ago
  What if you visit a link within the home screen app that takes you to another domain? Presumably if you kept using it with ever returning to the original domain the clock would be ticking.
PunksATawnyFill 7y ago
It's beyond confusing. It's meaningless, and even grammatically nonsensical.
gowld 7y ago
Suffice to say that the author of this blog post should have spent less time congratulating themselves and more time clearly explaining the impact of this change, to avoid scaring off developers and users.
om2 7y ago
Home screen web app data will be deleted onlY be deleted after 7 days of active use of that web app without any user interaction, which is nearly impossible. So the whole premise of the OP is false.
dieulot 7y ago
A clearer explanation has now been delivered by Safari’s evangelist: https://twitter.com/jonathandavis/status/1243228885006708737 https://twitter.com/jonathandavis/status/1243228885006708737 Data isn’t deleted after 7 days for home screen web apps.
- admax88q 7y ago
  Jesus christ. It sounds like there's a time bomb in safari web views just waiting to happen. The timer is supposed to be reset every time you open the app, so there won't ever be seven days of opening the app and not using it. But it sounds like the code path is just there, they just don't ever expect it to be hit because the timer _should_ reset every time the user opens the app. I can't _wait_ to deploy an application where there is literally an "rm -rf" pointed at my users data, with a complex conditional blocking it. That makes it far to easy for a webview bug to nuke my users data. This is shoddy engineering. Could you imagine a filesystem being implemented the same way? You would never include a code path in your "mount" logic the says "if ( some condition ) delete everything;" that would rightfully be viewed as a terrible idea and a disaster just waiting to happen.
  - jchw 7y ago
    I actually suspect the reason the codepath is still enabled is probably to do with third parties running in a PWA context. That said I don’t see how this is actually all that flimsy of a mechanism, it avoids needing a special case. As it is you can’t really count on browser local storage alone for long-term storage; the same is actually true for Android and iOS apps too, who lose all of their local data when they are deleted. (It is possible for at least Android apps to write data to other places like the SD card, but that is a totally different story imo.) Honestly, if my data really matters, I don’t want it to be stored only in a single place. I can get the argument of wanting to have federated syncing, that would give the user freedom to choose where data syncs or doesn’t. But in my opinion you either care about the data or you don’t. Any data stored locally anywhere should be considered lost until proven otherwise. Like, drop your phone in a sewer, leave it in the wash accidentally, have it stolen, or even just have a different software bug obliterate your data and it’s gone. That’s the definition of fragility. This mechanism failing is mostly theoretical, but having ones phone break is not; I would guess those of us who have been using smartphones for 10+ years have, by and large, all experienced data loss when storing data with no backup. To relate to your statement, can you imagine if your data on Dropbox was stored on one harddrive, in one server, in one datacenter? Servers fail constantly. You can of course do whatever you want to improve reliability but without redundancy you are very much pissing in the wind. On the note of “localStorage is temporary,” nothing in the spec defines how long localStorage persists, just that it is not bound to the session. In fact though, Safari already deletes localStorage when disk space is running low. I am very much an advocate for folks being able to control their own data. I personally self host a lot and use a Synology NAS as my own backup for most things. But I think Safari would be wasting time to disable the counter entirely for PWAs. It doesn’t meaningfully change the likelihood that users will lose data. I think users often do want strong durability and privacy, and an API that n apps from needing to implement many remotes would be way more impactful. I’d love to tell an arbitrary notes app, “Go backup to this Synology NAS” without it needing to specifically support Synology NASes or for example, WebDAV. Put the provider on the clientside and you have a place to implement end-to-end encryption. (Of course, Apple has iCloud backup, but I don’t think that covers your localStorage content anyways.)

by untog 7y ago

gridlockd 7y ago

Yes, it's confusing. It's not 7 days of non-use, it's seven days of application use without visiting the site. Safari is one application, the homescreen app is a separate application. Presumably, all the alt browsers or WebView apps are separate applications as well. Since you can't use a homescreen app without visiting the site, the 7 days of not visiting the site can't happen.

untog 7y ago
Ah OK that makes sense. They should really copy and paste what you just said into their post!
deleted 7y ago
[deleted]
emmelaich 7y ago
But .. if you don't use Safari for seven days, what happens?
- deleted 7y ago
  [deleted]
- eyelidlessness 7y ago
  From their description, nothing. Seven days of use without visiting triggers deletion. Failing to satisfy either of those conditions (either by disuse of Safari, or by visiting the site within seven days) doesn't.
rhizome 7y ago
So this is a requirement that all webapps phone home, moreover that they have a home to phone?
- untog 7y ago
  No, this is all internal to the browser, no requirement to send a remote request.
  - deleted 7y ago
    [deleted]
- manicdee 7y ago
  It’s a requirement that some time within the next seven days of app usage, the user interacts with the web app. This might cause trouble if the web app is simply a list of timers which the user interacts with passively (map of earth showing day/night zones), but if there is any interaction at all the timer resets.
- numpad0 7y ago
  I'm not getting the semantics clear but wonder whether having the icon on the homescreen counts as "visiting" or whether suspending the app first day and reopening it the next day counts app-subjectively as "continuing day one" or "reopening immediately"
pier25 7y ago
will it be "7 days of non-use" for regular websites that use localStorage? You can't really have "seven days of application use without visiting the site".
- Gaelan 7y ago
  For "regular websites" (visited through Safari) it's 7 days where you use Safari, but don't visit the site. So if you go on vacation for a month and don't touch your computer, or if you switch completely to using Firefox for a month, localStorage will remain untouched.
  - pier25 7y ago
    Where is this explained?
    - saagarjha 7y ago
      https://news.ycombinator.com/item?id=22681370 https://news.ycombinator.com/item?id=22681370
      - pier25 7y ago
        Hmm no mention about "regular websites" there...
        saagarjha 7y ago
        I fail to see why you need to see a mention of "regular websites". The comment clarifies the situation of what occurs if a user goes on vacation or switches to another browser: nothing will be deleted, as Safari is not being used.
Touche 7y ago
What if you visit a link within the home screen app that takes you to another domain? Presumably if you kept using it with ever returning to the original domain the clock would be ticking.

PunksATawnyFill 7y ago

It's beyond confusing. It's meaningless, and even grammatically nonsensical.

gowld 7y ago

Suffice to say that the author of this blog post should have spent less time congratulating themselves and more time clearly explaining the impact of this change, to avoid scaring off developers and users.

om2 7y ago

Home screen web app data will be deleted onlY be deleted after 7 days of active use of that web app without any user interaction, which is nearly impossible. So the whole premise of the OP is false.

dieulot 7y ago

A clearer explanation has now been delivered by Safari’s evangelist: https://twitter.com/jonathandavis/status/1243228885006708737 https://twitter.com/jonathandavis/status/1243228885006708737 Data isn’t deleted after 7 days for home screen web apps.

admax88q 7y ago
Jesus christ. It sounds like there's a time bomb in safari web views just waiting to happen. The timer is supposed to be reset every time you open the app, so there won't ever be seven days of opening the app and not using it. But it sounds like the code path is just there, they just don't ever expect it to be hit because the timer _should_ reset every time the user opens the app. I can't _wait_ to deploy an application where there is literally an "rm -rf" pointed at my users data, with a complex conditional blocking it. That makes it far to easy for a webview bug to nuke my users data. This is shoddy engineering. Could you imagine a filesystem being implemented the same way? You would never include a code path in your "mount" logic the says "if ( some condition ) delete everything;" that would rightfully be viewed as a terrible idea and a disaster just waiting to happen.
- jchw 7y ago
  I actually suspect the reason the codepath is still enabled is probably to do with third parties running in a PWA context. That said I don’t see how this is actually all that flimsy of a mechanism, it avoids needing a special case. As it is you can’t really count on browser local storage alone for long-term storage; the same is actually true for Android and iOS apps too, who lose all of their local data when they are deleted. (It is possible for at least Android apps to write data to other places like the SD card, but that is a totally different story imo.) Honestly, if my data really matters, I don’t want it to be stored only in a single place. I can get the argument of wanting to have federated syncing, that would give the user freedom to choose where data syncs or doesn’t. But in my opinion you either care about the data or you don’t. Any data stored locally anywhere should be considered lost until proven otherwise. Like, drop your phone in a sewer, leave it in the wash accidentally, have it stolen, or even just have a different software bug obliterate your data and it’s gone. That’s the definition of fragility. This mechanism failing is mostly theoretical, but having ones phone break is not; I would guess those of us who have been using smartphones for 10+ years have, by and large, all experienced data loss when storing data with no backup. To relate to your statement, can you imagine if your data on Dropbox was stored on one harddrive, in one server, in one datacenter? Servers fail constantly. You can of course do whatever you want to improve reliability but without redundancy you are very much pissing in the wind. On the note of “localStorage is temporary,” nothing in the spec defines how long localStorage persists, just that it is not bound to the session. In fact though, Safari already deletes localStorage when disk space is running low. I am very much an advocate for folks being able to control their own data. I personally self host a lot and use a Synology NAS as my own backup for most things. But I think Safari would be wasting time to disable the counter entirely for PWAs. It doesn’t meaningfully change the likelihood that users will lose data. I think users often do want strong durability and privacy, and an API that n apps from needing to implement many remotes would be way more impactful. I’d love to tell an arbitrary notes app, “Go backup to this Synology NAS” without it needing to specifically support Synology NASes or for example, WebDAV. Put the provider on the clientside and you have a place to implement end-to-end encryption. (Of course, Apple has iCloud backup, but I don’t think that covers your localStorage content anyways.)