4 ms·

I think the original post is oversimplifying the new behaviour a little. If you look at the other blog post on ITP 2.3 [1] it says: > ITP 2.3 caps the lifeti

by davweb 7y ago

I think the original post is oversimplifying the new behaviour a little. If you look at the other blog post on ITP 2.3 [1] it says: > ITP 2.3 caps the lifetime of all script-writeable website data after a navigation with link decoration from a classified domain. i.e. the 7 day timeout for local storage only kicks in if you've been redirected from a domain that ITP has classified as one that tracks users. So, for example, web apps that users navigate to directly will be unaffected. [1]: https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ https://webkit.org/blog/9521/intelligent-tracking-prevention...

kevin_thibedeau 7y ago
When will Google Analytics and Google Tag Manager get onto this list of trackers? Lots of web apps are using them.
- t0astbread 7y ago
  As far as I understood this is not a "list of trackers" per se but a "list of websites that track you when you navigate to another website from them" and people don't navigate away from the Google Tag Manager or Google Analytics domains because they don't serve content with links.
  - snazz 7y ago
    So this would apply to t.co links from Twitter, for instance?
    - t0astbread 7y ago
      I don't know if t.co is such a classified domain but if so, if the link contains query parameters or a fragment part, then yes. I'm also not sure if "navigation" means through user action or if redirects count, although for the purpose of tracking prevention I don't see how the latter should not also count. So, if all of this is true the way I understood it now, the restrictions could apply to when someone reaches your site via social media.
pspeter3 7y ago
I think confirmation in the blog post yesterday would have provided a lot of clarity.
t0astbread 7y ago
Okay that's good but still, couldn't a domain on that list be weaponized against legitimate sites this way? For example: - Somehow goodsite.com's user ends up on evil.com - evil.com redirects to goodsite.com?clickID=1234 - goodsite.com's storage gets flagged
noobquestion81 7y ago
This! ^ Could someone please change the title of this post? It's rather inaccurate and spreading FUD... legitimate offline web applications are not going to randomly lose their storage abilities in Safari. Tons of people read this (admittedly hard to follow) blog post quickly and then took a nose-dive into their own hot takes. Hoping Webkit pushes another of these posts later to clear things up.
- saagarjha 7y ago
  They already have–the post referred above is old.
magicalist 7y ago
> If you look at the other blog post on ITP 2.3... why would you look at the old blogpost for the new behavior? It's all web pages, regardless of classification or redirects. The new webkit blog post is quite clear: > 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 https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ https://webkit.org/blog/10218/full-third-party-cookie-blocki... Or straight from the ITP lead's twitter: > Fifth, all script-writeable storage is now aligned with the 7-day expiry Safari already has for client-side cookies. https://twitter.com/johnwilander/status/1242516001939324928 https://twitter.com/johnwilander/status/1242516001939324928 (with follow up replies on what resets the seven day clock)
brlewis 7y ago
You're describing behavior from 2019-09-23 I see the same "oversimplifying" in webkit's 2020-03-24 blog post linked from the original post. See "7-Day Cap on All Script-Writeable Storage" in https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ https://webkit.org/blog/10218/full-third-party-cookie-blocki...
BiteCode_dev 7y ago
> website.example will be marked for non-cookie website data deletion if the user is navigated from a domain classified with cross-site tracking capabilities to a final URL with a query string and/or a fragment identifier, such as website.example?clickID=0123456789. So my guess is you are fine most of the time, except if you allow other sites to embed your content in their page. In that case, you should: - provide the embed on a separate subdomain - remove features requiring identification if the content is view embedded: attempting to use them redirect to the real site. Otherwise ITP will mark your domain as tracking and wipe you after 7 days if your user don't interact directly with the site. I have a hard time deciding if it's a good thing or not. I guess it has the potential to be mostly a good thing, provided that: - I understood it correctly, which I'm not sure, as their wording is not clear - It's implemented correctly. Once the deal is done, it's in the wild years, fix or not. - It's implemented in good faith. Apple wants to promote the app store and has shown to neuter web apps in the past. I still have a strange bad feeling about this.
- pier25 7y ago
  It's very confusing... I still don't understand if Safari will delete a JWT in localStorage used to talk to different microservices.
  - BiteCode_dev 7y ago
    It is confusing indeed. My guess would be that if your user uses service site.com, calling using microservice micro.com, then you have to store the JWT in the localstorage of site.com, but cannot store it on the localStorage of micro.com.
  - drkstr 7y ago
    JWT tokens are irrevocable by design, or it would defeat the purpose. I would advise against issuing JWT token which are long-lived. Using "refresh tokens" are generally more prefered, as this gives an opportunity to revoke a stolen token in active use by the attacker. Even 7 days seems like an excessively large session time. That is 7 days a stolen token can be used to forge an authenticated session.
pier25 7y ago
> So, for example, web apps that users navigate to directly will be unaffected. I don't think that's true. I asked the head of Webkit dev on Twitter and he said: > This time limit affects first-party storage https://twitter.com/othermaciej/status/1242926762029285376 https://twitter.com/othermaciej/status/1242926762029285376

by davweb 7y ago

kevin_thibedeau 7y ago

When will Google Analytics and Google Tag Manager get onto this list of trackers? Lots of web apps are using them.

t0astbread 7y ago
As far as I understood this is not a "list of trackers" per se but a "list of websites that track you when you navigate to another website from them" and people don't navigate away from the Google Tag Manager or Google Analytics domains because they don't serve content with links.
- snazz 7y ago
  So this would apply to t.co links from Twitter, for instance?
  - t0astbread 7y ago
    I don't know if t.co is such a classified domain but if so, if the link contains query parameters or a fragment part, then yes. I'm also not sure if "navigation" means through user action or if redirects count, although for the purpose of tracking prevention I don't see how the latter should not also count. So, if all of this is true the way I understood it now, the restrictions could apply to when someone reaches your site via social media.

pspeter3 7y ago

I think confirmation in the blog post yesterday would have provided a lot of clarity.

t0astbread 7y ago

Okay that's good but still, couldn't a domain on that list be weaponized against legitimate sites this way? For example: - Somehow goodsite.com's user ends up on evil.com - evil.com redirects to goodsite.com?clickID=1234 - goodsite.com's storage gets flagged

noobquestion81 7y ago

This! ^ Could someone please change the title of this post? It's rather inaccurate and spreading FUD... legitimate offline web applications are not going to randomly lose their storage abilities in Safari. Tons of people read this (admittedly hard to follow) blog post quickly and then took a nose-dive into their own hot takes. Hoping Webkit pushes another of these posts later to clear things up.

saagarjha 7y ago
They already have–the post referred above is old.

magicalist 7y ago

> If you look at the other blog post on ITP 2.3... why would you look at the old blogpost for the new behavior? It's all web pages, regardless of classification or redirects. The new webkit blog post is quite clear: > 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 https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ https://webkit.org/blog/10218/full-third-party-cookie-blocki... Or straight from the ITP lead's twitter: > Fifth, all script-writeable storage is now aligned with the 7-day expiry Safari already has for client-side cookies. https://twitter.com/johnwilander/status/1242516001939324928 https://twitter.com/johnwilander/status/1242516001939324928 (with follow up replies on what resets the seven day clock)

brlewis 7y ago

You're describing behavior from 2019-09-23 I see the same "oversimplifying" in webkit's 2020-03-24 blog post linked from the original post. See "7-Day Cap on All Script-Writeable Storage" in https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ https://webkit.org/blog/10218/full-third-party-cookie-blocki...

BiteCode_dev 7y ago

> website.example will be marked for non-cookie website data deletion if the user is navigated from a domain classified with cross-site tracking capabilities to a final URL with a query string and/or a fragment identifier, such as website.example?clickID=0123456789. So my guess is you are fine most of the time, except if you allow other sites to embed your content in their page. In that case, you should: - provide the embed on a separate subdomain - remove features requiring identification if the content is view embedded: attempting to use them redirect to the real site. Otherwise ITP will mark your domain as tracking and wipe you after 7 days if your user don't interact directly with the site. I have a hard time deciding if it's a good thing or not. I guess it has the potential to be mostly a good thing, provided that: - I understood it correctly, which I'm not sure, as their wording is not clear - It's implemented correctly. Once the deal is done, it's in the wild years, fix or not. - It's implemented in good faith. Apple wants to promote the app store and has shown to neuter web apps in the past. I still have a strange bad feeling about this.

pier25 7y ago
It's very confusing... I still don't understand if Safari will delete a JWT in localStorage used to talk to different microservices.
- BiteCode_dev 7y ago
  It is confusing indeed. My guess would be that if your user uses service site.com, calling using microservice micro.com, then you have to store the JWT in the localstorage of site.com, but cannot store it on the localStorage of micro.com.
- drkstr 7y ago
  JWT tokens are irrevocable by design, or it would defeat the purpose. I would advise against issuing JWT token which are long-lived. Using "refresh tokens" are generally more prefered, as this gives an opportunity to revoke a stolen token in active use by the attacker. Even 7 days seems like an excessively large session time. That is 7 days a stolen token can be used to forge an authenticated session.

pier25 7y ago

> So, for example, web apps that users navigate to directly will be unaffected. I don't think that's true. I asked the head of Webkit dev on Twitter and he said: > This time limit affects first-party storage https://twitter.com/othermaciej/status/1242926762029285376 https://twitter.com/othermaciej/status/1242926762029285376