Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Private client-side-only PWAs are hard, but now Apple made them impossible

andregarzia.com

Post reply on HN
Print view View original

301–310 of 927 posts

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#301

Post by t0astbread »

snazz wrote: post #286
t0astbread wrote: post #284

Earlier quoted context omitted.

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.

So this would apply to t.co links from Twitter, for instance?

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.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#302

Post by themihai »

pier25 wrote: post #232
themihai wrote: post #85

Offline Web Apps were already weak(i.e. CORS restrictions). Now they are even more useless with this storage limitation. You can't really blame Apple.. after all, Google claimed that offline web apps are nothing more than websites so that's what we have... I don't mind if Safari deletes offline data stored by websites every week so why would I complain about "offline apps" ? My point is that Offline Web Apps (i.e. PW…

Read the article, it's not only about offline PWAs. All local storage is deleted after 7 days.

As for as "persistence" is concerned I really care only about offline PWAs. Why would a website need offline data after 7 days? It would improve performance, that's true but everything else should be "fresh" unless that said website wants to actually behave like an "app". Maybe the "website" should ask the client to be installed as "app" if the user wants to take advantage of persistent storage(and other "app" features) . Asking the user to install(which is actually just a kind of bookmarking for PWAs) isn't that much of an effort if the user is planning to use it regularly.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#303

Post by jamil7 »

shadowgovt wrote: post #278
oefrha wrote: post #274

Earlier quoted context omitted.

My bank logs me out after ten minutes of idling, not seven days. Not sure what kind of crazy bank allows you to persist login session / personal data indefinitely.

I was responding specifically to the question "I would have to REALLY love your service to want to carry around an extra device to use it." Some people's banks require their users to carry around a rotating 2FA key dongle, for example.

Which is included in the cost of opening an account with the bank, you're not told to go buy this device off Amazon.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#304

Post by BiteCode_dev »

davweb wrote: post #250

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 exam…

> 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.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#305

Post by pier25 »

themihai wrote: post #302
pier25 wrote: post #232

Earlier quoted context omitted.

Read the article, it's not only about offline PWAs. All local storage is deleted after 7 days.

As for as "persistence" is concerned I really care only about offline PWAs. Why would a website need offline data after 7 days? It would improve performance, that's true but everything else should be "fresh" unless that said website wants to actually behave like an "app". Maybe the "website" should ask the client to be installed as "app" if the user wants to take advantage of persistent storage(and other "app" featur…

> Why would a website need offline data after 7 days?

JWT for example.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#306

Post by diggan »

thefounder wrote: post #281
diggan wrote: post #257

Earlier quoted context omitted.

I think looking at ANY company as the savior of privacy is a waste of time. Companies have proven time and time again that they are unable to self-regulate this. Only way forward is to introduce legislation that makes it illegal to track users using privacy-invasive practices, otherwise we'll never get rid of it. A company can be privacy-preserving today, but then the leadership changes or acquisition happens, and no…

>> I simply see no technological solution to this problem, it'll always be a cat-and-mouse game, until governments catch up and makes it illegal. Then you we will have privacy-avoidance companies just like we have tax avoidance. Problem solved!

Exactly, and when they get caught, they get fines or prison. Sounds good to me, let's ship it.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#307

Post by gridlockd »

lstamour wrote: post #235
gridlockd wrote: post #209

Earlier quoted context omitted.

It's not about metadata or "web games". It's about apps/games that can be used offline. For that to work, all the data needs to be stored client-side. > My browser storage is not a game developers long term storage, its a cache. IndexedDB is explicitly not a cache, it's long-term data storage for significant amounts of data.

Cookies can be used for storage for up to a year, but it’s commonly accepted that browsers vary in implementation of this based on user settings. So why wouldn’t user settings exist for other kinds of permanent or session storage? Google Chrome is so dominant in both browser-making and standards-making that we’ve forgotten the browser — and user — is always king when it comes to the web. If users want permanent stora…

> Google Chrome is so dominant in both browser-making and standards-making that we’ve forgotten the browser — and user — is always king when it comes to the web. If users want permanent storage they will use alternative browsers for those particular sites.

No, they generally won't. There also aren't really any "alternative browsers" on iOS, they're all Webkit-based.

> So why wouldn’t user settings exist for other kinds of permanent or session storage?

Nobody is saying there shouldn't be any settings or consent in this regard. What we get here is not a setting, we get one major player deciding that there will be no way to properly implement offline web apps on their platform.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#308

Post by smnthermes »

diggan wrote: post #129
Veen wrote: post #123

Earlier quoted context omitted.

It could also be exactly what they say it is: a way to prevent the abuse of local storage for tracking.

People who want to track users will always find a way to do so, it's a endless cat-and-mouse game. Now they will just use cookies instead... The only way to win this is to legislate away the freedom to track users by using privacy-invasive methods. That's the only way that will work long-term. But that'll make half of the internet industry disappear, along with it's shareholders, so it's unlikely to happen.

Arbitrary government rules are never the solution for issues.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#309

Post by theamk »

matsemann wrote: post #76
im3w1l wrote: post #56

Earlier quoted context omitted.

So store this data on the server.

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

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.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#310

Post by gridlockd »

vetinari wrote: post #96
nradov wrote: post #64

Earlier quoted context omitted.

Have you considered porting to a native application?

Users are using other than macOS/iOS devices too. Most of them are not willing to pay extra for native app that runs on only one of the platforms used.

Why would users have to pay extra?

If right now you have a web app with paying users, that means you have an accounting system of paying users.

You could publish a "native" app that simply serves that web app through a web view, using those same accounts.

Post reply on HN