Wow they buried the lede; I'm glad you highlighted this. This is going to be an interesting situation for some Safari users. "Why did your app delete my data?" "If you don't like that you should use Chrome."

Of course Google could do this too, if they had a reason, even if only downstream from Chromium. It's just a commercial decision. Apple have decided they don't want their users to have usable anonymous web apps. Of course, since they don't support beforeinstallprompt, we already know they don't want their users to have web apps, period. Gotta get that sweet 30% cut!

I doubt that this is going to be an issue for applications using ReactNative or other solutions to package websites as applications.

For applications that have you add it to your home screen using the app icon, it may be more of an issue, but why wouldn't you sync that data back up to the server?

Yes of course if you're running a business then you're getting users logged in ASAP. There are other models of software development, however. Even if you're in the commercial sector, some users may be less eager than others to sign up for your fine service. Should you preemptively suck in their data, whoops I mean back up their data, without telling them? It seems there could be several responses to that question...

It's fine that Apple don't want to support this valid mode of app distribution and use. It is a valid mode, however.

Just FYI (If I'm reading you correctly): That's not how react native works. It's a native app, not a wrapped website.

I suspect they just meant regular react

Ok, that's not how React works either. React is not a "solution to package websites as applications".

you know .. you're correct, I misread his original post. He was probably conflating reactnative with something like Electron

so what is the modern version of PhoneGap?

Ionic Capacitor

Cordova?

It’s the usual “this is why we can’t have nice things”. Anything persistent will be turned into a tracking cookie. So eventually everything becomes ephemeral.

Not if there's a proper opt-in permission prompt, just like for GPS or camera/microphone access.

It's not trivial, though, seeing how notification prompts were abused...

Sites would just instruct users to accept permanent storage in exchange for free content.

But then why don't they already force visitors to accept push notifications?

> after seven days of Safari use without user interaction on the site

If it's a PWA that's regularly used you should be fine. But if not, yeah, that's going to be very annoying.

If this is really about protecting users and not about kneecapping web apps shouldn't Apple also wipe user data in native apps that haven't been used in a week?

Outside privacy issues; visiting a website once shouldn't be enough for a website to store as much data as it wants on someone's computer.

Installing a native app is a stronger form of opt-in than simply clicking an URL to a new website.

Chromium (and derivatives such as Edge) allows users to install web apps. You're right that such a facility could be used as a signal for webkit that a particular site's IDB data should be retained for longer than a week.

> install web apps

That's what a PWA is :). Browsers should lift these restrictions for installed PWAs, and probably do.

The browser under discussion in TFA doesn't have PWAs as such. [0] Of course I agree with your restatement of what I said browsers should do upthread. b^)

[0] https://caniuse.com/#search=beforeinstallprompt

Safari still lets you add a web app to the homescreen, though. It could be used as a signal.

Yeah it seems they are encouraging that as a solution. Unless I’m misunderstanding.

“ Web applications added to the home screen are not part of Safari and thus have their own counter of days of use. Their days of use will match actual use of the web application which resets the timer. We do not expect the first-party in such a web application to have its website data deleted.

If your web application does experience website data deletion, please let us know since we would consider it a serious bug. It is not the intention of Intelligent Tracking Prevention to delete website data for first parties in web applications.”

Was that section originally in TFA? It's encouraging, but it certainly contradicts claims that this will only be applied to "3rd party" stuff in iframes...

Native apps don't really have the problem of third-party ad networks storing data intermixed with app data in this way, though.

The regular reports about tracking in random advertising/... SDKs suggest otherwise

Why not though? It seems like third-party SDKs could be included by the developer and stored on my local device.

Every iOS app I ever built for a client had Facebook's SDK and tracking installed, at the client's request. Often Google's and Twitter's too and the user has no awareness of this.

They are much worse.

The seven day wipe is going to encourage further adoption of Facebook or Google centralized logins, since this flow makes state restoration after a cookie wipe least painful. (Even saved login-passwords combinations can become de-synchronized between devices.) I don't think the theoretical benefits of enhanced privacy are worth the concrete costs of internet centralization.

First-party cookies aren't on the list of affected storage, are they?

https://webkit.org/blog/8613/intelligent-tracking-prevention... already limited 1st party cookies set from JS to 7d.

This post is about them extending it to all storage set from JS.

However any cookies set via HTTP, like http secureonly cookies that tend to be used for logging in, are exempt from that seven day limit.

Correct.

I expect companies will start working around this with CNAMEing and proxying, and I'm curious how Apple will handle it.

I would expect the end game of this would be advertising networks injecting content directly into the page as it's rendered on the webserver. If they want tracking, at some point they'll just ask companies to hand over their logs…

Yes. Or sites just CNAMEing entirely over to their ad network, which then proxies the page content and inserts ads. Which are then, as a side effect, are very difficult to block.

And since they can easily correlate logs server side, they can track people between sites.

Oh my, what a grim vision of the future. I'm going to stop recommending ad blockers, on the theory that I don't have to be faster than the bear...

I suspect the EU will just outlaw that kind of collaboration.

I think this is the eventual goal from tracking prevention's side.

Yeah, that seems potentially destructive for apps that want users to have a local only copy. You would need to provide a full import / export option in case someone goes on vacation.

95% of my regularly used websites and applications have had usage gaps that have reached a week.

That is what it means. The only workaround is to require the user to login and to keep a backup of the data on your server.

Exactly. Which to me suggests this could result in more tracking rather than less. At AutoTempest we haven't even bothered to make user accounts thus far, since there's no reason why you should need an account to search for used cars, and we can store user preferences in cookies or localStorage. If those only persist for 7 days though, we're basically forced to have users create accounts and store their preferences on our servers, to avoid a poor user experience.

Blocking 3rd party cookies I'm fully on board with, but I don't want first party cookies deleted unless I actually specify it. Fortunately as a user I can keep using Firefox, but since iOS is always going to be a large percentage of our users, there's not much choice on the provider side.

This is what we do. Store a 1st party httponly secure cookie jwt representing the user, then grab any extra data from the backend. Or just something like session cookie but persist it.

I wouldn't be surprised if this is one of the ways ad tracking tries to rebuild a universal identifier like the old urchin module. Might not be as easy as a cname but those might get blocked. It's always a game of cat and mouse. Could place uuid as 1st party httponly cookie. maybe uuid is domain scoped. then 'echo out' so accessible by 3rd party JS. Like a hash, one would need to know the global pooled uuid already and then combined with knowable domain could tie that uuid into the 2nd party tracking pool.

1st party httponly secure cookies will be erased in seven days.

You need the user to manually provide an identifier (i.e. login) to avoid losing everything.

The user's password safe is now the only non-volatile storage mechanism on Safari.

> 1st party httponly secure cookies will be erased in seven days.

httponly cookies can't be set from JS, and the seven day erasure only applies to cookies set from JS. That's why they're the recommended method for keeping a user logged in.

They explicitly say 1st party httponly secure cookies are exempt and are their first recommended alternative.

Don’t they just mean the localstorage containers for other domains than the current one? Ie your normal app’s storage will be left untouched as it is currently but third party domain localstorage containers will be wiped?

My understanding was that yes, if the user doesn't interact with the site in 7 days then the stored data (in cookies and localStorage) will be deleted.

It is confusingly worded, but DOES NOT mean all browser storage mechanisms will break.

The key phrase is “without user interaction”. Only e.g. invisible nested iframes that scammy ad companies love to use will have their localstorage limits affected. Top level frames are unchanged.

I think you’ve also misread the original text:

“seven days of Safari use without user interaction on the site”

Does not mean that top-level frames are unaffected. Everybody is affected. They specifically call out first party storage as being misused currently. I think the correct interpretation is:

Whenever the user interacts with your page then the clock gets reset to 7 days, also the clock only runs on days the user uses Safari.

I hope you're right! Where TFA has:

Now ITP has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site.

...maybe "script-writable" should be "third-party-in-iframe-script-writable"? If so this document should be edited.

To be clearer; this is a huge win for privacy/antitracking without any? real downsides.

> “chrome will never have this”

Indeed :)

Apple have to put restrictions on websites, otherwise users might break free from AppStore walled garden.