[HN Gopher] Private client-side-only PWAs are hard, but now Appl...
___________________________________________________________________
Private client-side-only PWAs are hard, but now Apple made them
impossible
Author : soapdog
Score : 406 points
Date : 2020-03-25 17:22 UTC (5 hours ago)
(HTM) web link (andregarzia.com)
(TXT) w3m dump (andregarzia.com)
| marta_morena_23 wrote:
| Whoever uses local storage as persistent storage doesn't
| understand what local storage is. 7 days is enough. Local storage
| is supposed to allow your app to temporarily navigate around
| connection issues, to not require "always on". You can never rely
| on this storage to be permanent, there are just too many ways to
| accidentally wipe it all and for the user there is no easy way to
| back it up.
|
| Your offline app should ALWAYS sync to the server whenever
| possible. The only bad thing I can see here is that if you can't
| upload the data in time and the user then doesn't use your app
| for 7 days, he will lose what he last worked on, but such is life
| and why you should rather use real apps. Offline apps needs to
| work differently, they need to get permanent storage just for
| that app but only if the user explicitly choses to install it
| like that. Not every random page should get permanent storage on
| your device. This is the right move, Apple might just lack an
| alternative for apps you actually chose to "install permanently"
| ;).
| dubcanada wrote:
| I don't understand what the problem is.
|
| I can easily go to the settings area and delete my entire browser
| cache (Remove All Website Data), in fact if you are running low
| of space it even tells you to do it.
|
| Why are people assuming things stored on a browser are a good
| place to store things. Nothing stored on a browser should be
| assumed to be forever.
| beering wrote:
| If you read the article, that's the issue the author was
| talking about: it's basically impossible to make an app that
| can store its data locally, instead of on some web server.
|
| All apps that you download from App Store can live offline,
| where they're usable without Internet or trusting some faraway
| web server.
|
| You can't make a web app that can do that, and to some people
| it smells like Apple trying to force developers to release
| through App Store.
| mulmen wrote:
| I don't really understand this. If you want to make something
| local, make an app and distribute through the app store,
| that's what it is for. A _web_ app on the other hand is
| connected by definition, no?
|
| Apple forcing local apps to distribute through the app store
| is a _feature_.
| EvanAnderson wrote:
| You should research the original plan for "apps" on the iOS
| platform. There was no "native app" story originally, and
| Javascript-based applications were expected to be the only
| 3rd party platform on the OS.
| npunt wrote:
| As should you. It's not that an app ecosystem was never
| planned, it's that it was not an early priority. Remember
| they were literally defining everything at the beginning
| - OS, UX, APIs, core features, hardware, first party
| apps, market positioning, etc etc. Needs of third party
| developers weren't nearly as important as nailing the
| basics and ensuring a risky project was a success. The
| html5 app bit was a way to test the waters for developer
| interest and demand but very much an interim solution.
| EvanAnderson wrote:
| How do you square that against all the reported accounts
| (including the Isaacson biography) of Steve Jobs saying
| that he was opposed to third-party native applications on
| the platform?
|
| Yes, they changed direction in 2008. That's just it,
| though. They changed direction.
| npunt wrote:
| Jobs' hot takes aren't the end-all when it comes to
| product intent at Apple. He was basically an embodiment
| of strong opinions weakly held. His superpower was
| focusing teams on what the right set of features would be
| to create a product that made sense to the market, and
| ignoring everything else. The phone / iPod / internet
| communicator trifecta was example of this - nothing but
| nailing those three mattered at launch, and any effort
| elsewhere was wasteful. Without that kind of leadership,
| eng teams will often dither efforts over many things that
| don't matter to success.
|
| The history of Apple is filled with examples of this
| dynamic. iPhone was a group effort among many talented
| and influential people and I doubt Forstall and others
| driving software had same opinion on third party apps.
| They just didn't pick that battle before it made sense
| to. Every other computing platform at the time (including
| Windows Mobile, Palm, and BlackBerry) supported third
| party apps, it's not like the use case was novel or
| difficult to see, and the webs limitations were
| considerable. Adding apps was a default path temporarily
| set aside.
| larkost wrote:
| That was not the plan, that was the stopgap. Apple (and
| even more the networks) were very scared that native apps
| would have unregulated access to the radio, and would
| mess with the cell networks. Web apps were the quick-and-
| dirty way of putting third party apps into a sandbox
| while Apple worked on APIs that would enforce that sort
| of sandbox for native apps (what they have now).
| jariel wrote:
| "Apple forcing local apps to distribute through the app
| store is a feature."
|
| Forcing companies to give Apple 30% is not a feature.
|
| If companies feel they can deliver a net experience in
| webapp that's better than an app, then so be it, it's their
| choice.
|
| App makers are smart enough to know what makes sense for
| them.
| txcwpalpha wrote:
| At one point, Apple was denying some app store reviews
| because they said they should be distributed through PWAs
| instead. If this is supposed to be a "feature", it seems
| like some product manager has their head up their ass.
|
| Also, the _entire point_ of PWAs is that they are supposed
| to have feature parity with local apps, but delivered via
| the browser. This change is obviously counter to that goal.
| ianlevesque wrote:
| People keep wishing for a loophole. There isn't one they
| won't close sooner or later.
| swsieber wrote:
| A feature for who?
|
| Not for users - now there's one less avenue for developers
| to get them something they want.
|
| Not for developers - now they have to jump through
| additional hoops to make something that works cross
| platform.
|
| Who exactly does this benefit?
| snazz wrote:
| Users want to be able to log in and see their data from
| any device. If the whole idea is that there is no server
| that the data is stored on, then you can't have a sync
| function, can you?
|
| Do any of you have an example of a good offline-only PWA
| that will be affected by this?
| veeti wrote:
| It's no less of an issue for an online-based PWA. Where
| do you store login credentials or session tokens? In
| local storage. What happens to them when Apple decides to
| arbitrarily throw it away? The user has to log in again
| and again.
|
| This sounds like a seriously poorly thought out idea.
| Want to clear tracking data from random websites I've
| been to? That's great. But you don't mess with the data
| stored by apps I have specifically _chosen_ to install on
| _my_ device.
| bengale wrote:
| But only if they don't interact with it for a week. I
| wouldn't be surprised if a web app I hadn't used for a
| week required me to login.
| veeti wrote:
| There are many apps on my phone that I only use every
| once in a while, yet every single one of them remembers
| me. No matter how long I've been gone. Technology is
| amazing!
|
| Where is Apple's famous UX here? What legitimate argument
| is there for clearing data of an app the user has added
| to their home screen?
| Dylan16807 wrote:
| I wouldn't be _surprised_ but I would definitely be
| _upset_.
| admax88q wrote:
| And most native apps crash one a week, we should
| therefore automatically crash every app once a week.
|
| Just because current apps are buggy doesn't mean we
| should enforce those bugs at a platform level.
| swsieber wrote:
| The whole point is that you don't need to download a big
| payload just because you haven't used it recently.
|
| There are two ideas that go together well:
|
| * The app can work offline
|
| * The app doesn't need a server to function
|
| Neither of those prevent a sync function from existing.
|
| Right now, apps can do both of those. Why don' we want
| PWA's to be able to do the same? Why do I have to go
| through Apple's walled garden in order to so? Especially
| when said alternative is in a sandbox?
| woodson wrote:
| It means you constantly have to re-login on a PWA (e.g.
| Twitters web client PWA).
| falcolas wrote:
| Constantly being weekly at most frequent in this case.
| vxNsr wrote:
| I roll my eyes every time robinhood makes me login again
| after an app update... though it hasn't happened in a
| while, so maybe they fixed that bug, but it was annoying
| when it's an unexpected hurdle that doesn't follow what
| other apps are doing.
| dktp wrote:
| Games with your personal high scores. Is the one that
| would affect me
|
| Plus a local note-taking app I created a while ago
| eslaught wrote:
| The whole point is that those PWAs probably never got
| built in the first place because the foundations were
| always shaky at best. It's a chilling effect.
|
| But if you look at native apps, especially ones I use on
| desktop OSes, they're dominated (at least in my usage) by
| offline-first or offline-only apps---and for me, this is
| a feature, not a bug. This doesn't have to mean they
| don't have sync, by the way, it just means that's
| separate from the main functionality of the app.
|
| A perfect example of this is Dropbox: it syncs to your
| local disk by default. It's easy to forget how valuable
| this is until you go camping (or similar) and suddenly
| you realize you forgot to star that one directory you
| care about. Now your mobile phone is useless, but your
| laptop works no problem. And due to this being factored
| out into a separate app, all my files now work regardless
| of file type (I don't need separate offline support in
| every app I use, since that's the default).
| carlosdp wrote:
| It doesn't have to be that way though, that's the point of
| PWAs. A way to use web technologies for local applications.
| osrec wrote:
| So you can think of absolutely no situation where a user
| would access a web app, and might want to store state info
| locally?
| falcolas wrote:
| I can personally think of cases (not that PWAs have ever
| been anything but fragile when it comes to locally stored
| data), but as a user, the occasional clearing of super
| cookies is a bigger boon.
| osrec wrote:
| I don't disagree that local data for PWAs has always been
| fragile. I wished browsers were taking steps to make it
| _less_ fragile, as opposed to more fragile. It would
| allow certain use cases to become valid for PWAs, thereby
| circumventing the need to create a 10mb native app for
| something that can be deployed much more easily and
| quickly with 30kb of Javascript.
| brlewis wrote:
| > A _web_ app on the other hand is connected by definition,
| no?
|
| No, it just has to run in a browser.
| fastball wrote:
| Well it needs to be downloaded from the internet at least
| the first time, so it's intrinsically going to be less
| secure than an app that you can guarantee never connects
| to the internet.
| e12e wrote:
| Has to come from _somewhere_. A pwa might have to come
| via http (I 'm not sure) - but html+js+css can come from
| the (from a) filesystem too. Like an USB-c memory stick.
|
| Or from an extracted archive (much like a native app).
| anchpop wrote:
| > A pwa might have to come via http
|
| They can't, PWAs can only be served over https
| osrec wrote:
| Your app needs to be downloaded the first time too. In
| fact, a downloaded app can run riot on your filesystem. A
| web app runs in the "cage" of the browser, and is
| arguably more secure and explicit about permissions it
| requests.
| rstupek wrote:
| "... can run riot on your filesystem"? Citation needed
| because an app is as heavily sandboxed as a web page
| running in a browser. An ios app gets no view into
| anything you as a user don't choose to give it (no access
| to photos, etc).
| osrec wrote:
| I mean, if you give the app access to your filesystem
| (which a lot of non-tech users would, almost without
| thinking), it can potentially access/modify/delete your
| files and folders. With PWAs, that's not really a
| possibility.
| LocalH wrote:
| Stock iOS doesn't allow apps to directly access data from
| other apps afaik
| gnicholas wrote:
| > _If you want to make something local, make an app and
| distribute through the app store, that 's what it is for._
|
| Have you ever gone through the app review process? It can
| be frustratingly capricious, which makes it very expensive.
| We've had features in our app for years, displayed in plain
| sight, and then all of a sudden they decide to block an
| update because of these utterly innocuous features. No
| rhyme or reason, and now we've got to spend dev time fixing
| a "problem" that never was a problem before. And we have to
| delay our entire update because of it.
|
| PWAs offer a way around that uncertainty and added cost.
| There's also the cost of a developer license, and the Apple
| hardware you have to buy to run XCode (and probably iOS
| devices too, so you can test IRL).
| cryptonector wrote:
| Apple's app store is a walled garden. The web isn't a
| walled garden. TFA wants to be able to operate outside the
| walled garden.
|
| EDIT: Also, it's probably cheaper to develop one PWA than a
| PWA + N native apps, even if N=2. Probably lots cheaper.
| Now, perhaps there's a way to build a native app that is
| just a wrapper around WebKit/Safari and a PWA, but you'd
| still be subject to Apple's walled garden. For example,
| think of Gab or some such website whose apps have been
| banned by the various app stores...
| untog wrote:
| > A web app on the other hand is connected by definition,
| no?
|
| No, not in the era of "progressive web apps", which is
| really just a little bit of branding around interconnected
| APIs. The Cache API in particular means that a webapp can
| be downloaded and made available offline on a permanent
| basis. Unless it isn't actually permanent at all, which is
| what Apple are doing here.
|
| The web and the App Store are just delivery mechanisms for
| code with different trade-offs built into them. Apple have
| added an extra trade-off on the web side in the name of
| privacy.
| icedchai wrote:
| Personally I would never expect a web app to be available
| offline on a permanent basis.
| barrkel wrote:
| That's just a failure of your imagination, though. The
| world was not always as it is today, and it is not bound
| to be so in the future.
| untog wrote:
| Okay?
| icedchai wrote:
| I basically assume my phone is nearly useless without
| connectivity. And if I want something to work in that
| sort of environment, it better be a native app.
| rezz wrote:
| To an end user there's an icon on their screen, they tap
| it, the app opens. It didn't matter if they downloaded
| from the AppStore or from a website. This is no longer
| the case which is why the OP is upset.
| icedchai wrote:
| Pretty sure it is still the case if they have
| connectivity...
| dragontamer wrote:
| I actually have an old phone that I used as a remote-
| control for my home-threater PC. No connectivity needed,
| but the phone did everything I needed. Move the mouse,
| act as a keyboard, and mostly raise volume / change
| channel.
|
| Phones are computers. Even if you remote all connectivity
| to the outside world, they still function as well as any
| PC from the early 90s (or earlier). A huge amount of
| compute power, tons of storage, etc. etc.
| LocalPCGuy wrote:
| Let's say you use an app that allows you to add Todos.
| You've added 30 Todos. No internet needed, it's always
| just worked. You go on vacation for 10 days. You get
| back, you open your app. No Todos...all gone. Very simple
| use case that is now broken.
|
| Yes, you as the user could wipe those out. But now Apple
| is doing it just because you didn't use it in 7 days. And
| the user will not blame Apple, they won't even know Apple
| did that. They will blame the app developer, who in the
| interest of privacy didn't want to push your personal
| Todos to a database online.
|
| Again, just a contrived example, please don't go down the
| road of why a server should have been used. Let's stick
| to the use case described.
| vxNsr wrote:
| Its not, at least not based on how the OG article is
| written. If you open your bank app it automatically tries
| to log you in if you saved your credentials in the past.
| This seems to say that if you don't use the app for a
| week it'll wipe that out. No one expects that.
| icedchai wrote:
| That's not how I read it. Odds are my bank isn't using
| local storage for that.
| untog wrote:
| Okay?
|
| ...I guess I don't really see why the current state of
| things should block any future development. Browsers
| shouldn't ever implement new features because users today
| aren't expecting them to exist?
| munk-a wrote:
| Having worked on a cross platform application that
| defined the UI via HTML I'm still kinda confused about
| this use case - it's super trivial to wrap a set of HTML
| + JS in an app that's essentially just a full screen
| webkit/whatever window and distribute this.
|
| The advantage of PWAs then seems to be the ability to
| dodge the app store certification which, while onerous,
| is not a bad thing for your clients.
| vernon99 wrote:
| This is equal to saying "I'm ok with Apple having a
| censorship monopoly of what an iPhone can run". I don't
| think the majority of people here would agree with that.
| I also don't think users buying a device that is supposed
| to support web apps would be happy to find out that in
| fact it doesn't. I'm one of those very unhappy users.
| vially wrote:
| > [...] is not a bad thing for your clients
|
| Except when you have to pass some of the 30% Apple fee on
| to your clients.
| rimliu wrote:
| That's the same era as the "year of the Linux" desktop. I
| keep hearing "PWAs will win" for ten years now. Some
| people just want to use ill-fitted web tech everywhere,
| because that's all they know.
| [deleted]
| ajford wrote:
| No, it's a grab for money. Releasing an iOS app requires
| Apple hardware, X-code, and an Apple developer license
| which is $100/yr.
|
| Where as developing a PWA can be done on any hardware, and
| would be natively cross-platform. An offline PWA does not
| require an active connection, and in fact is the one of the
| reasons behind the idea of developing a PWA instead of a
| general webapp or website.
|
| All other browsers allow the use of local storage to
| optimize and enhance your experience by allowing things
| like pre-loading data or storing your preferences. This
| disappears with the decision Apple made to clear storage.
| jfb wrote:
| I promise you that Apple does not give a shit about the
| revenue from the developer program.
| lliamander wrote:
| Then why not make it free?
| falcolas wrote:
| That's easy. It adds a hurdle for people who make
| malicious or fraudulent apps. It's not free, but neither
| is it MSDN levels of absurdity.
| fomojola wrote:
| I'd counter that: make it a one time tax, like the Play
| Store. Is it reasonable that I need a Dun and Bradstreet
| number to write an application for my computer?
| judah wrote:
| It's not just about the revenues of $100/year. It's also
| the revenue from 30% sharing of profits. And most
| importantly, it's the bigger revenue generated from
| having apps that work only on iOS, which drives users to
| buy iPhones and iPads.
| jfb wrote:
| Yes, and they shouldn't be taking a cut. Their services
| initiatives are bad for them and the users of said
| services. But as someone who did two tours in their
| services arm, it is overwhelmingly likely that the reason
| that WebKit is making these changes is their _stated
| reason_ of making Safari more resilient to the attacks on
| their users vectored in by web badness.
| wpietri wrote:
| Exactly. The app store's gross revenue was $54 billion
| last year. [1] Apple has a very strong incentive to make
| sure the only good way to deliver apps on iOS is the app
| store.
|
| [1] https://www.statista.com/statistics/296226/annual-
| apple-app-...
| lioeters wrote:
| Interesting numbers. I see, "gross revenue" means:
|
| > In the last reported year, customers spent an estimated
| 54.2 billion U.S. dollars on on in-app purchases,
| subscriptions, and premium apps in the Apple App store.
|
| So, roughly 30% cut goes to Apple - which is around 16
| billion; and developers got the rest, around 38 billion.
|
| With PWAs, 100% goes to developers. As you pointed out,
| that's a threat and motivation for Apple to continue
| racheting up their closed ecosystem, and keep PWAs
| crippled on Apple devices.
| rstupek wrote:
| A PWA app isn't going to generate any 30% revenue share
| for Apple since no one is paying for it in the PWA case
| and thus likely won't be paying for it in the pure app
| case either.
| Silhouette wrote:
| Why would no-one be paying for a PWA? There are countless
| paid-for services available via web apps.
|
| Providing even a free native app via the App Store to
| access a service with a subscription model becomes a very
| risky proposition given Apple's rules, though.
| joosters wrote:
| Can you give a few examples of paid-for PWAs? Sure there
| are websites that are paid-for, but I've never seen a
| paid-for PWA.
| Silhouette wrote:
| I'm posting pseudonymously here, so please forgive me for
| not citing personal examples, but the normal web apps for
| accessing quite a few popular services are now PWAs.
| Spotify famously started looking into using a PWA after
| some issues with Apple regarding the cut taken with a
| native app. Uber is another well-known example.
| [deleted]
| billyhoffman wrote:
| (Looks at home screen) Slack, Jira, LastPass, and
| Netflix. All Native apps that are free via the App Store,
| and all with the subscription model that I pay for. And
| for most of those I can't even buy the subscription from
| inside of the native app, so Apple gets no money from
| these
| Silhouette wrote:
| _And for most of those I can't even buy the subscription
| from inside of the native app, so Apple gets no money
| from these_
|
| This is where things get pretty shady with Apple's terms
| for native apps and the App Store. Take a look at
| Spotify's experience for a different version of the
| story.
| fooey wrote:
| They care about they revenue they get by making people
| buy the hardware that gives them access to the developer
| program.
| MikusR wrote:
| I think you missed the "requires Apple hardware". I know
| that rich Americans think everyone has Macbooks, but that
| is not the case.
| Silhouette wrote:
| Does Apple also not care about the huge cut it takes for
| everything sold via the App Store?
|
| As lliamander said, if they don't care, why not make it
| free? I don't for a moment believe the argument about
| creating a barrier for negative actors. They could still
| screen apps before allowing them into the App Store, and
| if that mechanism is working reliably then the charge is
| unnecessary as a deterrent, while if it is not then the
| financial deterrent isn't going to be enough to stop a
| lot of people willing to make these kinds of apps anyway.
| notduncansmith wrote:
| If you read the update from webkit.org, you'll see that it's
| still quite possible to store data locally.
|
| Link: https://webkit.org/blog/10218/full-third-party-cookie-
| blocki...
|
| Relevant quote (emphasis mine):
|
| > 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._
|
| If a website hasn't been used for 7 days, I'm happy for its
| data to disappear and save space on my device.
| RussianCow wrote:
| 7 days is actually a really short period. There are lots of
| apps and websites that I only open on my phone every now
| and then. I would never use them if I had to log in almost
| every time.
| Silhouette wrote:
| _If a website hasn 't been used for 7 days, I'm happy for
| its data to disappear and save space on my device._
|
| You might be, but maybe not everyone is. I've worked on
| apps based around multimedia content where downloading in
| advance to watch or listen later was a big deal, because a
| typical user also travels a lot and might well be going
| away for longer than a week. Even if they can get the same
| data again next time they're online, it might still be much
| slower and more expensive for them to do that on an
| international data plan instead of back home.
| notduncansmith wrote:
| Then wouldn't it be appropriate to offer a native app to
| offer that functionality? A web browser in 2020 is a
| place to run vast swathes of untrusted code safely; it is
| not a digital workstation platform, that is the job of
| the OS. If what I am downloading from you is important
| enough that I want to have it even offline, then I trust
| you enough to install your native app.
| Silhouette wrote:
| _A web browser in 2020 is a place to run vast swathes of
| untrusted code safely; it is not a digital workstation
| platform, that is the job of the OS._
|
| I'm not sure how much that assumption really holds any
| more, nor why it should necessarily continue to do so
| even if it has so far. Technology evolves, and so does
| how we use it. In the case of the web, and web apps in
| particular, they have evolved to satisfy a need for
| convenience in software distribution that many
| traditional desktop OSes had hopelessly neglected for a
| very long time and where the developer experience for
| native mobile apps is less than ideal.
|
| I appreciate your comment about the trust issue, but the
| bottom line is that these technologies do serve a useful
| purpose for some people -- I have the customer feedback
| at my own businesses to make that clear -- and the
| experience web developers can offer on Android with PWAs
| will now be significantly better than what they can offer
| on iOS.
| LocalPCGuy wrote:
| I believe this entire statement is wrong in 2020. There
| are literally OSes now that are just browsers.
| notduncansmith wrote:
| The fact that that is possible does not change the role
| of the web browser in the modern computing experience. If
| you want to build an entire VM that runs in Electron, be
| my guest, but that's orthogonal to the issue of how
| Safari should handle storage by default.
| wtallis wrote:
| That's been true for years, and yet the operating systems
| that _aren 't_ just browsers seem to be getting along
| just fine.
| Aaargh20318 wrote:
| > it's basically impossible to make an app that can store its
| data locally, instead of on some web server.
|
| No, that is trivial to do: just make an actual damn
| application.
|
| What the author is complaining about is that it's impossible
| to make a text document that pretends to be an application
| that stores data in ways they were never intended to be
| stored.
| untog wrote:
| I'm sorry but I find this argument utterly tedious.
|
| A Swift file is no less a "text document" than a JavaScript
| file is. There are APIs available in the browser to store
| data offline, so I have no idea what "in ways they were
| never intended to be stored" means here.
|
| A webapp is "an actual damn application". Can we just
| dispense with the repetitive arguments about this every
| time anyone so much as mentions adding interactivity to a
| web page?
| Silhouette wrote:
| _No, that is trivial to do: just make an actual damn
| application._
|
| So trivial that all it needs is learning a completely new
| skill set and tools, signing up for a gated distribution
| mechanism that can kill your application on a whim if you
| violate any of the rules over which you have no control,
| and then giving a huge cut of your revenues to the rent-
| seeking platform owner?
|
| The web has been more than just text documents since around
| the turn of the millennium. It's probably about time we
| stopped ignoring 20 years of very popular evolution and
| pretending that what might have been "intended" before a
| lot of people reading this comment were born should still
| guide what we build today.
| Fauntleroy wrote:
| "just write an iOS app" versus "my web application can be
| used on Apple devices" is a bit much, don't you think?
| gridlockd wrote:
| > What the author is complaining about is that it's
| impossible to make a text document that pretends to be an
| application that stores data in ways they were never
| intended to be stored.
|
| You must've been not following things. The web platform is
| an application platform and has developed to that end, for
| many years.
|
| Progressive Web Apps are applications based on standard Web
| APIs that are designed with the _intent_ to enable offline-
| capable applications with persistent offline storage of
| significant amounts of data.
| Aaargh20318 wrote:
| > The web platform is an application platform and has
| developed to that end, for many years.
|
| No it's not. Using it like that is a lasagna of dirty
| hacks. The web is for structured text with hyperlinks,
| everything else is bullshit that doesn't belong on the
| web.
| DaniloDias wrote:
| Who are the "some people"?
|
| Are any of them outside of chrome's WebWorker team, or the
| community of devs that were suckered into a model that really
| has never gained traction for iOS?
|
| I'm sort of sympathetic to the devs who bought in to the
| solution, but this looks an awful lot like a pr pressure
| campaign that is unhappy with how this affects googles
| disintermediation goals.
| riquito wrote:
| If you are distribting a PWA through e.g. electron the user
| does not have (easily) the means to delete the cache. Web app
| is a misnomer in that case, they are just applications running
| inside a somewhat hidden browser.
| notduncansmith wrote:
| I also don't understand the alarm.
|
| There is no hard limit on how long things will be stored. Data
| in localStorage might still be stored for weeks/months/years,
| as before.
|
| The only limit is on how long things will be stored _if the
| user does not interact with the site /PWA_.
|
| If you are a website, not a natively-installed app, that I
| haven't "used" in a first-party sense for 7 days or more, I
| don't think your data belongs on my device.
|
| Storage space can be limited, and any app I haven't used in 7
| days should be happy to re-fetch my data from a server or
| convince me to install their native app.
|
| To act like this is some nefarious plan by Apple to get people
| to build native apps instead of PWAs is absurd. If a PWA was
| written properly in the first place, this change will have
| basically 0 impact on it.
| cloverich wrote:
| It is certainly a plan to further relegate PWAs because they
| directly challenge the monetization strategy of apple. Its an
| area where their interests do not align with user interests.
| A "properly written" PWA may offer things like not re-
| fetching data from the internet when you already have it
| locally, and / or not forcing you to create an account just
| to save some basic data (ex: A recipe app, a jobs search app,
| etc). Consider for example, saving a job search website as an
| app, and being able to search and save jobs without having to
| make an account. An account could be offered if you want
| cross device syncing, but is not required just to save jobs.
| Which is great because some users prefer to remain anonymous,
| and PWA's open the door to that type of thing (as a singular
| example).
|
| This move is _an_ example of Apple's (understandable)
| hostility towards PWA's, but you must understand the context
| here: There is a threshold beyond which PWA's become a
| generally acceptable strategy, and the quality and diversity
| rise over time. Apple is preventing that with this move (and
| others). That's why people are upset. Moreover, the outcome
| of this will be more "native" apps that are actually just
| wrappers around web apps, that exist purely because some
| basic functionality is being actively blocked by Apple.
| notduncansmith wrote:
| > Consider for example, saving a job search website as an
| app, and being able to search and save jobs without having
| to make an account. An account could be offered if you want
| cross device syncing, but is not required just to save
| jobs. Which is great because some users prefer to remain
| anonymous, and PWA's open the door to that type of thing
| (as a singular example).
|
| Consider the use-cased of this example. If I am actively
| job-searching, I will probably be using the site at least
| once per week, and the data will be saved throughout the
| process. When I stop using the site, I want that data to
| disappear for my own privacy/security; and if users want to
| save the data indefinitely without signing up for an
| account, then offering an export (e.g. CSV) seems like a
| reasonable way to address that.
|
| Furthermore, non-Apple user agents may retain data as long
| as they like, and PWA's (as well as web trackers) are free
| to utilize that. It's not like this move implements any
| additional vendor lock-in; people who don't like it will
| switch to non-Apple platforms.
|
| > Moreover, the outcome of this will be more "native" apps
| that are actually just wrappers around web apps, that exist
| purely because some basic functionality is being actively
| blocked by Apple.
|
| This doesn't seem problematic. It's great if you can reuse
| some code between your web and native apps. Obviously
| truly-native UIs will be more efficient in many cases, but
| perfect needn't be the enemy of good.
| pier25 wrote:
| Aren't there websites you use less than once a week?
|
| If one of those is using a JWT for auth in localStorage
| (something which is extremely common) you'd need to login
| every time you visit such site.
| notduncansmith wrote:
| Yes, and that's fine with me. Being on an iPhone, I use the
| built-in cloud-backed password manager which makes
| generating and entering credentials near-effortless.
| Furthermore, by not leaving long-lived tokens in my
| browser's storage, I'm less vulnerable to exploits that may
| exfiltrate that data.
| onion2k wrote:
| There's a big difference between a user choosing to clear their
| data and a browser vendor deciding to clear a user's data.
| arendtio wrote:
| The problem is, that it rarely happens under normal
| circumstances. So you might build a logic which synchronizes
| your data to the server but rarely has to download it as most
| of the time it still has a relatively current snapshot. And the
| few times you have to download everything, it is ok for the
| user to wait a while.
|
| But if you have to wait every time your last interaction is
| more than 7 days ago, the whole experience will change. And
| supporting a reliable offline experience will be very hard to
| build.
| ravenstine wrote:
| That's like asking why people store files on disks when they
| could store everything in the cloud.
| daleharvey wrote:
| I can delete data from my hard drive, why are people assuming
| things stored on a computer is a good place to store things.
| Nothing stored on a computer should assumed to be forever
| progx wrote:
| Then data will stored online on servers, i cant see how this is
| better for privacy.
| jjtheblunt wrote:
| Perhaps this style of app, on iOS devices, drains more battery
| power than deemed reasonable?
| rvanmil wrote:
| I do not understand why anyone would want to store anything other
| than temporary/disposable data inside their browser.
| [deleted]
| AndrewBissell wrote:
| Cedric Beust said on an episode of "Talking Kotlin" awhile back
| that he thought the Achilles' Heel for the WebAssembly cross
| platform story would be Apple moving to lock down their devices.
| themihai wrote:
| 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. PWA) that are installed
| on user's desktop should have a bit more permissions than
| websites but people in charge(google, apple etc) seems to think
| otherwise.
|
| https://discourse.wicg.io/t/proposal-full-network-access-in-...
| pier25 wrote:
| Read the article, it's not only about offline PWAs. All local
| storage is deleted after 7 days.
| themihai wrote:
| 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.
| dylan-m wrote:
| I made one of these. We generally expected users to be
| offline for at least a week. Probably using the app
| regularly on their respective devices (but possibly not),
| and syncing data again when they had a good internet
| connection. Uses Dexie and React, syncs with a horrible
| Drupal site. It's always going to be uncertain to rely on a
| database held at arm's length by the browser, but in
| practice it worked _incredibly_ well on all manner of
| devices. I guess it won 't anymore. (Thanks, Apple!).
|
| This is absolutely a necessary change on some level, but I
| think if Apple wasn't in complete control of a web
| monoculture (and obviously uninterested in anything that
| doesn't sell more iPads), it would be possible to steer
| this API towards that without breaking a bunch of peoples'
| stuff.
| pier25 wrote:
| > Why would a website need offline data after 7 days?
|
| JWT for example.
| ocdtrekkie wrote:
| I find localStorage a bad crutch, when storage accessible to any
| browser or computer would be better. I'm totally cool with this
| because magical storage in your browser is just a bad idea,
| especially when it requires developer tools to find and see what
| it is doing.
| fredsted wrote:
| Feels like Apple is just continually making the Safari browser
| worse.
|
| I think they just want to push people towards native apps so they
| have full control. Apple always wants control.
|
| First they prevented plugins like uBlock, made it very expensive
| to create your own plugins, and now they're messing up
| LocalStorage.
| eyesee wrote:
| Would it be possible for Apple to relax the 7 day limit for apps
| that are strictly client side only? I.e. sandbox the apps to not
| allow access to any remote resources? It seems to me the
| opportunity to exploit a user's privacy would be very limited
| without exfil.
| icebraining wrote:
| Maybe, but it would only apply to a subset of PWAs. For example
| OP's RSS reader must access remote resources.
| rconti wrote:
| > What are private client-side PWAs anyway?
|
| (proceeds to not answer the question)
|
| Found the answer: Progressive Web Apps[1]
|
| 1: https://medium.com/@amberleyjohanna/seriously-though-what-
| is...
| soapdog wrote:
| Sorry, I wrote this blog post too fast because I was/am a bit
| angry and didn't notice my usage of jargon without explanation.
|
| It is a "Progressive Web App". Sorry for the jargon usage
| without explanation. Basically it is a marketing term used to
| place some new web APIs and best practices into an umbrella of
| a "near native UX on a Web App". What it usually means is that
| your application is:
|
| * Served from a secure context (a requirement for the other
| APIs anyway).
|
| * Has an application manifest (this contains metadata about
| your web app and is used by browsers and OSs to add icons,
| names, themes, etc)
|
| * Has a service worker (which enables your application to
| potentially work offline beyond what other cache solutions did
| in the past)
|
| So with these in place, browsers can offer a "Install this site
| and an app" feature which allows the site to open in its own
| window, with its own icon and name on the launchers and home
| screens.
| rconti wrote:
| Thanks for your reply :) I recognize often articles are meant
| for a specialized audience and shared here without the author
| even being aware of the site, so it's unreasonable to expect
| that everything be described to a total neophyte, but
| sometimes I have to laugh at the buzzword articles that get
| posted here about how to implement foo in bar on baz, using a
| fizzbuzz framework running blarg, and I have no idea what ANY
| of those things are, having worked in tech for decades :D
| soapdog wrote:
| I going to make sure in the future that I don't fall into
| this behavior again. :-)
| soapdog wrote:
| Also, I just updated the post with a definition and a link
| to learn more about PWAs.
| MaxBarraclough wrote:
| As the article explains, _Offline Web App_ is being used to mean
| Progressive Web Application (the standard terminology).
|
| ( _edit_ Turns out that 's not quite right, see diggan's reply.)
|
| From the article:
|
| > You'd almost think they had an App Store to promote or
| something.
|
| There's certainly a tension here. I'm still not sure why more
| vendors don't make iOS PWAs to get around the App Store payment
| rules.
|
| Perhaps related: Very roughly a year ago, something changed in
| iOS that broke the _2048_ PWA. Its swipe-detection no longer
| works. A pity.
| diggan wrote:
| offline web apps are different than PWA. A PWA doesn't
| necessarily work offline, but more is independent from the
| connection / loading of it. I do think most PWAs do work
| offline, but doesn't mean it's a requirement to call it a PWA.
|
| Similarly, an offline capable web app is not necessarily a PWA,
| as PWA carries a lot of features to it besides being offline
| capable.
| MaxBarraclough wrote:
| Good points. I've edited my comment.
| lonelappde wrote:
| What is an "off-line web app"? If an app _never goes online_
| and is sandboxed from other apps, then it never has any data
| at risk of exfiltration.
| diggan wrote:
| An offline web app is a frontend-only application (just
| HTML+CSS+JS or less) that can be loaded from any medium
| (internet, usb stick, direct TCP via netcat or any other
| transport) and work in your browser without requiring a
| remote connection to allow usage of it's features.
|
| So yes, this would mean it doesn't run the risk of ex-
| filtration or snooping at the transport layer, as the data
| never leaves the specific website context in your browser.
| criddell wrote:
| > I'm still not sure why more vendors don't make iOS PWAs to
| get around the App Store payment rules.
|
| Because users won't use them. For users that don't have a
| technical background: if it isn't in the app store then it
| essentially isn't an app. For techie users: lots of us don't
| want web apps because of the power, memory, and bandwidth usage
| is often higher than a well written native app. The fact that
| there's a gatekeeper who has some control over what shows up in
| the app store is usually a feature and not a bug.
|
| If there were big parts of the app ecosystem that didn't have
| native apps, then eventually users would find web apps. But
| that isn't the case. Think of anything and search for it in the
| app store and there's an app for it (including 2048).
| MaxBarraclough wrote:
| > For users that don't have a technical background: if it
| isn't in the app store then it essentially isn't an app
|
| I'm not convinced of this. If it has an icon like proper
| apps, and feels like an app, I don't think users are going to
| mind if it came from the App Store.
|
| The question is whether the unfamiliar 'installation' process
| is too fiddly for non-technical users. I don't think it is. I
| figure a 10 second _How to install our app_ animation would
| do the job.
| ratww wrote:
| I've seen a lot of news sites and random WordPress blogs
| doing that.
|
| It has become spam, just like news sites asking to send
| notifications.
| chrisfinazzo wrote:
| I think this is a problem of their own creation - done in
| the name of simplicity which has outlived its usefulness,
| but to take it back now would be chaos.
|
| A closed, curated app store gave less technical users the
| confidence to actually download software without concern
| that it would screw up their device. However, things which
| have a different model like web apps or system extensions
| (read: keyboards) were also put into the same distribution
| mechanism.
|
| You can see why as it removes a barrier to using them:
| people just go the same place they've always gone to get
| software on the platform. They make no distinction between
| the native Gmail app and GIF Keyboard because the install
| process is the same and each are displayed prominently.
|
| In reality, 3rd party keyboards and the like should
| probably be handled - from a UI standpoint - like they are
| on macOS, inside System Preferences/Settings, with no app
| icon on the homescreen, they simply aren't as important as
| full blown apps.
|
| ^ People will dispute this and _that 's really nice_...but
| they're wrong.
| vbezhenar wrote:
| > I'm still not sure why more vendors don't make iOS PWAs to
| get around the App Store payment rules.
|
| One reason is because Apple have incentive to break PWAs and
| they will do it. It's not a wise business decision to act
| against big player.
| arghwhat wrote:
| Better title: Apple restricts tracking by limiting browser
| storage, which hurts my particular app.
|
| Browsers _need_ to be severely limited due to them running
| arbitrary code from the web. Doesn 't matter if it's an offline
| web app. If you want more access, make a native app (with or
| without web technologies).
| megous wrote:
| > If you want more access, make a native app (with or without
| web technologies).
|
| How's installing a native app better for a random user privacy
| or security wise, exactly?
| jrockway wrote:
| You have to send every change to Apple before the user can
| run the code. In theory, that allows Apple to do more checks
| than when the code is dynamically loaded from your web
| server.
| hombre_fatal wrote:
| Apple doesn't care if your app logs your usage to Google
| Analytics every 1000ms.
|
| Besides, in the browser you have trivial tools like uBlock
| and the network tab. In native apps, you have to use
| mitmproxy just to see what the app is doing at all.
| kingo55 wrote:
| I'm sure apple catch all privacy violations of their so
| developers.
| IggleSniggle wrote:
| It must go through the App Store vetting process, whereas a
| web app can come from anywhere.
| kingo55 wrote:
| With embedded SDKs and device identifiers that work similarly
| to third party cookies, they're not.
|
| I understand it's changing too, but not as fast as safari.
| Wowfunhappy wrote:
| And, um, any other app which saves local data locally.
| m-p-3 wrote:
| > If you want more access
|
| which is somewhat ironic, because the goal of a web app is to
| break free of the walled garden and become OS-independant.
| akmarinov wrote:
| No way that's happening on iOS as long as Apple takes 30% off
| the top
| scarface74 wrote:
| Yes because think of all the money Apple gets from taking
| 30% all of the free apps that would be free web apps....
| vbezhenar wrote:
| There are very few free apps. Most of apps are paid with
| ads or external subscription. And Apple wants cut there
| as well.
| scarface74 wrote:
| Apple doesn't have an ad network outside of the little
| money it makes from ads on the App Store itself.
|
| Also, Apple may _want_ a cut of the subscription revenue
| but most companies who have significant subscription
| revenue, don't go through Apple's subscriptions payments.
| rstupek wrote:
| Apple doesn't get a cut of ads within apps. A free app
| with ads doesn't make Apple any more then the $99/year
| for being a developer
| FpUser wrote:
| Which in a current situation is running a risk to fall into
| Google's walled garden. It is not there yet but Google's
| working hard on subverting the Internet.
| the_gipsy wrote:
| > If you want more access, make a native app
|
| ...and give apple their cut. Why not add permissions to
| webapps? Like location, or push notification... oh that's
| another feature that _happens_ to be missing only in safari.
|
| Just accepting these moves from apple as "in the interest of
| users" is naive. Apple has a huge vesting in their appstore,
| and every webapp is a potential appstore-app that is some lost
| revenue.
|
| I mean, _maybe_ apple is right, and the web should go back to a
| readonly document-like format, like in the old days. Articles
| and links. Apps for everything else. But let 's not kid
| ourselves that they do it purely in the user's interest.
| fierarul wrote:
| But browsers are severely sandboxed already. What the article
| is talking about is:
|
| > deleting all local storage (including Indexed DB, etc.) after
| 7 days
|
| which I can see how it might help privacy (since you could be
| tracked via local storage too) but also how it might break any
| potential web app that might need data to last more than 7
| days.
|
| > If you want more access, make a native app
|
| But then, everybody will complain about yet another Electron
| app, right? Not to mention that you have to fork over $99 and
| go through the signing / notarization hoops that change from
| one week to the other.
|
| I think in the name of privacy and security only Apple and some
| select few corporations will be allowed to make software in the
| future. macOS / iOS and Windows 10 are evolutionary dead ends
| in many ways.
| DagAgren wrote:
| They do not "change from one week to another". They have
| changed, what, twice ever?
| fierarul wrote:
| Two counterpoints:
|
| * AdoptOpenJDK releases that were notarized some months ago
| are no longer accepted by Apple since they made the rules
| even more stringent. I had releases accepted by Apple that
| are not accepted today using the same AdoptOpenJDK
| binaries.
|
| * Apple's notarization rules are not global. There's
| whitelists for given companies/institutions/apps/files
| which means the same dylib might not have to be notarized
| by a bigger player but will have to be codesigned by you.
|
| The above happened to me in the span of less than 3 months
| I think?
|
| Indeed, the scripts I use per se to do the notarization are
| about the same as originally.
| saagarjha wrote:
| Do you have more details about this?
| fierarul wrote:
| I think I gave quite some details. Do you need the exact
| AdoptOpenJDK version (11.0.5+10 for macOS)?
|
| And I made a test about the non-global rules too (by
| trying to submit the same binary and getting rejected).
| conroydave wrote:
| and to be honest the process has gotten a lot easier.
| janoc wrote:
| Native app != Electron app (fortunately!) The less of that
| bloated slow crap the better.
| vetinari wrote:
| If we had to make non-electron, native version of our app,
| that would mean Windows[1] and Android, because that's
| where the current users are. Forget the rest.
|
| Is that the future you want?
|
| [1] And they would not be happy about that either. For many
| that would mean RDP or Citrix. They prefer webapp right
| now.
| kkarakk wrote:
| I think apple DOES want this. Core markets cleanly
| segmented are probably a better value prop to apple than
| everything working everywhere and users being able to
| freely migrate between platforms
| Gorbzel wrote:
| Sure, keep your (likely crummy if you're OK with Citrix
| as a primary use case) Windows and Android apps.
|
| The market will decide. Your comment is just on the user-
| hostile side of assuming it will prefer your technology
| choices.
| recursive wrote:
| It would only be citrix if it was made a native app. It
| is presently a web app, presumably because it was
| determined to be a better choice. You proposed that it
| should be a native app. It would be the customers that
| would choose Citrix, but they'd probably prefer web apps
| (if they're anything like my customers).
|
| The deployment story is so much better for web apps,
| which is the main reason it seems to be so compelling for
| big enterprises.
| fpoling wrote:
| Apple requires that all code-related assets for an app should
| be included into the app. So the app cannot just be a
| launcher that show a browser with a website.
| simplify wrote:
| That doesn't seem to be completely true. Basecamp has a
| "hybrid" app, where they use native frames to load web
| pages for content
| https://twitter.com/dhh/status/940358921960677376
| george_perez wrote:
| 7 days after Safari use without user interaction on the site.
| kkarakk wrote:
| More likely that apple and the other corporations are also
| evolutionary dead end and this is a temporary hiccup
| pier25 wrote:
| > which hurts my particular app
|
| A big chunk of the web these days uses JWT and localStorage for
| auth.
| codesections wrote:
| > Apple restricts tracking by limiting browser storage
|
| But the argument that this will protect privacy in the first
| place seems really weak.
|
| Before this change in Apple's policy, an app could store my
| config data on my PC.
|
| After this change, they'd need to have me log in and send the
| config data to _their_ servers.
|
| That seems like I've _lost_ privacy, not gained it.
| JumpCrisscross wrote:
| > _they 'd need to have me log in and send the config data to
| their servers_
|
| You'd have to log in. That's a hurdle that involves implicit
| consent.
| kkarakk wrote:
| Most people don't care about logging into services anymore.
| just implement a fb login and it takes less than 5 secs
| sonofaplum wrote:
| If you've ever looked at user analytics you know this is
| absolutely not true
| benetzz wrote:
| I'm interested. As a iOS developer I always found that
| user want to skip the login page soon as possibile, if
| there is an FB button they press it. Do you have
| different experiences of it?
| frandroid wrote:
| I run away from services that only allow social media
| logins.
|
| 1) I don't want social media to track me everywhere
|
| 2) If the people developing this app have taken this
| shortcut, what other bad, leaky implementations do they
| have on their site/app?
|
| -> No thanks, exit this way
| RonanTheGrey wrote:
| Web-wide analytics (and our own, which have almost
| exactly the same stats), show about 30-40% of users still
| rely on email/password (and that's actually growing, as
| password managers become more ubiquitous especially when
| Apple implemented the built in credential manager in apps
| and in Safari on iOS).
|
| We're actually getting rid of social login in our apps.
| And we're not alone, alot of platforms I use have
| recently moved the same direction, and I think for the
| same reasons.
|
| Google, Facebook, Github, Twitter logins proliferated
| because
|
| a) the cost of implementing an auth system is high, and
| those offered a turnkey solution that was cheap and quick
| to implement. This is no longer true, there are lots of
| options now to host your own auth while federating the
| hard work to someone else (e.g. Auth0, Cognito, et al)
|
| b) for awhile, people LOVED the idea of having "an online
| identity" and a single login everywhere. Over time this
| has not really panned out, because it's the prisoner's
| dilemma; for it to work, everyone has to do it (which is
| why G and F have tried so hard to get everyone to use
| them). But also, because privacy questions have reduced
| the shiny appeal of that scenario in the first place.
| Combine that with easy to use password managers now, and
| it's much less necessary.
| shadowgovt wrote:
| That's a hurdle that involves de-anonymization of the user.
| dev_tty01 wrote:
| No, Apple offers anonymous user credential technology.
| Server gets unique identifier and ability to authenticate
| with no actual user info. Server gets an anonymous
| redirected email for sending info to the user. Apple is
| the intermediary. Of course, you can choose not to trust
| Apple, but Apple already has my info and their business
| model is not predicated on tracking and advertising. I'd
| rather continue to trust them than spread my data across
| more orgs, but that's my choice. You might choose
| differently.
| matsemann wrote:
| But that's a solution for a single OS, for a web page
| that should be cross platform by default. And it's not
| really a solution, just additional complexity to what was
| a solved problem.
| shadowgovt wrote:
| I choose differently, but my choice may matter to you if
| I throw up my hands and say "Too much effort; if the user
| visits my site in Safari, I'm just going to toss up a
| banner page that says "this site does not work in your
| browser."
|
| It's a power-play on Apple's part to intermediate
| themselves where their inter-mediation isn't necessary.
| And all kinds of customers (enterprise in particular)
| won't appreciate Apple getting a free "hi hello" signal
| on how much their company uses some service that
| leverages this scheme. Especially if Apple is a potential
| competitor to them.
| RonanTheGrey wrote:
| Same. We momentarily considered adding Apple Login to our
| app when they changed the rules a couple weeks back, but
| instead we are removing all social login and migrating
| all accounts to (email/username)/password. Why?
|
| Because a) it's _even more code_ we now have to support,
| both in our apps _even on android_ and on web -- a huge
| investment we are not prepared to make, and b) because
| for what we do, we actually do need to know the user is
| who they say they are (we offer the ability to contract a
| service between third parties, which means anonymity is
| NOT desired). I was never really comfortable using social
| login at all, for that second reason, but was pressed to
| by my peers; after Apple 's shenanigans we came to the
| mutual decision that it was time to cut the cord. The
| login screen is already busy enough, we don't need yet
| another button. So we'll simplify.
|
| For this latest change, it won't affect us much because I
| have always made it a policy neither to trust, nor to
| rely on, the data in Local Storage, and only to use it
| for performance boosting via caching. If data isn't
| there, it isn't there, and we go get it. This is largely
| due to historical reasons where browsers have always
| borked the LS implementation in one way or another, but
| it's beneficial now in that it won't really change
| anything for us.
|
| I do feel for folks that are using it for genuine storage
| though, I know some apps that use it in order to AVOID
| storing private data on their servers, which will now
| have problems and be forced to reduce privacy in order to
| adapt.
|
| This is definitely a power play on Apple's part to
| further weaken the web ecosystem. Device sales have been
| falling for years, they know their cash cow is their 30%
| cut on app purchases and IAP, and they aren't going to
| let the browser cut into that. Any "privacy" benefit in
| this case is purely incidental (and as noted above I
| believe it will do the opposite in many cases).
| corecoder wrote:
| Respecting someone's privacy doesn't mean forcing them to
| "consensually" give up their privacy.
| RonanTheGrey wrote:
| Thank you. I think this is very often overlooked.
| "Consent" gets thrown around alot but most of the time
| people basically have no choice if they want to, you
| know, participate in modern society. That's one of the
| reasons why an open web is so so so important and why I
| think Tim Berners Lee is working so hard to try to bring
| some part of that back as the "online world" (apps and
| internet) become more and more walled garden.
|
| If you are coerced into giving consent, it isn't consent,
| and most of the time if you're doing it so you can be
| part of the world around you, it is coerced, whether
| people want to recognize that or not.
| chrismarlow9 wrote:
| Wouldn't it be possible to retain the data with privacy by:
|
| - Asking the user client side for a password
|
| - Encrypt data as a blob using some symmetric encryption
| (AES)
|
| - Push encrypted blob to the server with login attached
|
| If you're using SSO the client authenticates and then can
| pull down the encrypted blob based on the SSO auth being
| valid. You can tie 2FA in however you wish. At that point the
| user is prompted for a "data" password for that particular
| site. Or would there be an easy way to build a pki/pin cert
| type of encryption to eliminate the password prompt? (I feel
| like this is essentially what Keyring!? would do but maybe
| not?)
|
| Outside of implementation weaknesses which I feel could be
| mitigated by created standard libs to do this, what am I
| missing?
|
| Bonus points for pushing the data diffs only or even a
| version controlled blob (data stored in a git repo where only
| the diffs are pushed in encrypted form).
|
| Edit: Or how about a local hardware appliance for your
| network that stores all data like this encrypted and pulls
| from there.
| viklove wrote:
| It's very hard to verify that the data is indeed encrypted,
| whereas with local storage you can just monitor your
| network usage and see that no requests are going out. Hell,
| you could airgap your machine and have no problems with
| localstorage.
| TeMPOraL wrote:
| It's not "limiting browser storage", it's making browser
| storage expire. TFA's example is just some random app, but this
| essentially kills the entire concept of an offline-first web
| app, and severely hurts the browser as an application platform.
| fpoling wrote:
| Web apps brings nothing in revenue to Apple.
| manigandham wrote:
| Technically local data is more private than contacting a remote
| server to download it again. I don't see that being a
| controversial stance.
| k__ wrote:
| I know this is ad hominem, but your comment just sounds like "I
| make big money with native apps and don't want web apps to
| catch up!"
| vbezhenar wrote:
| > If you want more access, make a native app (with or without
| web technologies).
|
| Browsers usually ask for an additional permission in this case
| which would be a good approach. Your post sounds like "browsers
| need to be severely limited, so if you want to watch video,
| just launch VLC". It does not work this way.
| alerighi wrote:
| Making a native app is more complicated than making a webapp,
| especially if you want something cross platform. Browsers are
| now an universal virtual machine, what was the JVM years ago,
| and with webassembly we will se more and more things done in
| the browser.
|
| The real 'write once, run everywhere' are webapps, a webapp
| doesn't care if you are using Apple, Windows, Linux, BSD,
| whatever, if you have a compatible browser you use the app.
|
| Sure there is Electron (or React Native), to me it doesn't make
| sense, what is the point that every application needs to ship
| basically a browser? And still Electron apps need to be
| compiled and packaged for every platform, while with webapps
| you enter the URL in the browser and you are done with it.
|
| Doesn't adding APIs to browsers not only to use the local
| storage but also to access the filesystem of your device (of
| course asking the permission to the user) make more sense?
|
| Of course what really Apple fears is loosing the control of the
| apps that gets used on their device, now they control the App
| Store that is the only way to get apps on their devices (beside
| jailbreak), with webapps is different, since you can access
| them directly from the browser.
|
| And the thing that is absurd is that the first iPhone didn't
| have the App Store since Apple decided that the only way to get
| third party apps was trough the browser, now they are aiming
| for the opposite thing.
| badthingfactory wrote:
| My company created a web client for our chat software product
| around 5 years ago. The quality of our product has slowly
| deteriorated as browser vendors continually remove or
| restrict features that once worked fine. Just to name two
| examples: autoplay audio for chat notifications and tab
| throttling killing websocket connections and background
| timers. I understand bad actors are abusing these things, but
| they're breaking totally legitimate use cases.
|
| We've been forced into an electron client and now urge our
| customers to ignore the web client. If we didn't have a small
| number of customers on Macs, we would abandon web tech
| altogether and build a native Windows client.
| zzzcpan wrote:
| _> Browsers need to be severely limited due to them running
| arbitrary code from the web. Doesn 't matter if it's an offline
| web app. If you want more access, make a native app (with or
| without web technologies)._
|
| Native apps have the same problems too and such "severe"
| limiting of apps in web browsers still doesn't solve it. The
| only more or less privacy preserving model I can think of for
| native apps today is open source repositories with app
| distribution not controlled by app developers, like f-droid or
| repositories in various linux distros.
| untog wrote:
| Genuine question: what makes native ad frameworks different
| here? They execute with the same privilege of their containing
| app so surely they're open to similar privacy concerns.
| Shouldn't native apps have their storage cleared?
| kkarakk wrote:
| OR maybe it's apple's responsibility to figure out how that
| usecase can exist without security flaws?
|
| As a customer, I'm tired of devices functionality being limited
| coz "security risks". Functionality that is arguably superior
| to native apps apart from the security risk.
| greggman3 wrote:
| Wouldn't making it first party only cover it? I don't see how
| this has anything to do with privacy/tracking. webpages can
| still leave long term cookies. The only way this is a privacy
| issues is if 3rd party iframes can use localstorage but just
| like 3rd party resources have their cookies blocked so to could
| localstorage.
|
| Otherwise this has absolutely nothing to do with privacy or
| tracking.
| bg0 wrote:
| I really appreciate this link. I would have never seen this
| otherwise. It's kind of a disappointment for us on the enterprise
| side. Our main offering is an offline app where people are
| disconnected from the internet for weeks and we use localStorage
| to validate who they are. It's a bit vague about how this affects
| apps that don't use safari. Nevertheless, we might have to start
| to really think about the user experience here now that this
| update is out.
| roywashere wrote:
| To be honest, HTML5 LocalStorage was always different on iOS
| when compared to other platforms. The iOS browser localstorage
| is stored in /caches so it is cleaned when the device goes low
| on disk space. I found out the hard way, had a cordova app
| which ran on Android and iOS (and web) and saved an account
| token in LocalStorage. Some iOS users kept on getting logged
| out, mostly users with smaller size iPhones!
|
| Now we store the account token in iOS keyring and that works.
|
| ref: https://stackoverflow.com/questions/32927070/complete-
| data-l...
| yohannparis wrote:
| Webkit's website says: "[..] deleting all of a website's
| script-writable storage after seven days of Safari use without
| user interaction on the site."
|
| It is not clear that a user coming to your website before the 7
| days, even offline, is exempt of it.
| bg0 wrote:
| Yea, we actually don't use safari at all in our app. So this
| might not have an effect but it's pretty vague.
| lonelappde wrote:
| If you don't use Safari you can patch webkit to change the
| policy, right? Change 7 to 10000000
| chrisfinazzo wrote:
| You _could_...but it 's a change that the Webkit project
| would never accept and you would be forever diddling this
| value every time an update came along.
|
| Sisyphus says 'Hi!'
| tssva wrote:
| Apple only allows apps to use their webkit
| implementation.
| vbezhenar wrote:
| User not coming to website 7 days can't be invalid use-case.
| Losing important data simply because someone went on vacation
| is unacceptable.
| diegoperini wrote:
| Not allowing important data to be downloaded for cold
| storage is unacceptable.
| aquadrop wrote:
| Ok, allowing, then what? I still don't want to deal with
| export/import as a user.
| cmsj wrote:
| You want all your important apps to migrate to a platform
| where their data is all tucked away in inscrutable
| filesystem locations that don't expire ever?
| diegoperini wrote:
| I have a few suggestions in the comment section you may
| or may not find agreeable.
| macawfish wrote:
| With all due respect, this comes off as apologizing for
| Apple's disagreeable design choice.
|
| If anything, it should be on Apple and the browser
| vendors to make local storage _more_ useful by default,
| not less useful. Your suggestions might as well be aimed
| at browser vendors, who could conceivably offer user
| friendly controls for local storage (e.g. import /export
| without the dev panel). But as is usually the case each
| of the browser vendors has these little annoying ways
| that they cripple the browser to protect their business
| models. Apple is no exception to this. Look at how
| they've hampered the WebGPU process. Look at the history
| of their PWA support.
| diegoperini wrote:
| I strongly oppose Apple's anti-consumer practices in
| their App Store policy, PWA policy (non-existent) and
| similar places. I just believe this (localStorage policy)
| is not one of those cases.
|
| Agreeing with Apple's disagreeable design choices isn't
| an apology, it's an honest opinion. If these choices are
| disagreeable, which I believe they are, they must be also
| agreeable by definition.
| vbezhenar wrote:
| There's one simple thing that Apple could do. Do not
| delete local data if user bookmarked page from that
| website (or pinned it to home screen for mobile devices).
| Now bookmarked website treated like an "app" with
| slightly less restrictions and some random website data
| will be eventually purged (although I believe that 7 days
| should be extended to few months).
| saagarjha wrote:
| > If anything, it should be on Apple and the browser
| vendors to make local storage more useful by default, not
| less useful.
|
| Not if the features allow for increased web tracking.
| vbezhenar wrote:
| I don't think that web tracking must be fought at expense
| of user UI. It's fine to fight web tracking by
| introducing measures that don't break honest websites.
| It's not fine to fight web tracking or anything by
| crippling user experience with honest websites.
| Grue3 wrote:
| > Not if the features decrease the need for the App Store
|
| Fixed it for you. It's all about profit.
| im3w1l wrote:
| So store this data on the server.
| untog wrote:
| 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.
| TomGullen wrote:
| 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.
| tssva wrote:
| 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.
| Touche wrote:
| 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.
| matsemann wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| theamk wrote:
| 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 wrote:
| 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.
| vbezhenar wrote:
| 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.
| theamk wrote:
| Not sure about pinning, but bookmarking should not grant
| any extra rights. Even the useful websites should not be
| able to track me forever.
|
| Look, we already have lots of website prompts, like
| camera and location. The best thing, privacy-wise, would
| be an explicit prompt: "this website wants to store
| information, possibly including tracking identifiers,
| forever. Allow?"
| Turing_Machine wrote:
| > 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.
| theamk wrote:
| 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 wrote:
| There are many legit uses for localStorage.
|
| Storing JWTs, game state data, etc.
| shirshak55 wrote:
| 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 wrote:
| 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).
| danbolt wrote:
| 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.
| SalimoS wrote:
| 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 wrote:
| 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.
| duxup wrote:
| Yeah I've got a lot of users with very shaky internet and
| intermittent involvement with a given application (not using it
| for a month, more). This presents some serious challenges /
| impossibilities for those user's use of a web app when they're
| not online.
|
| I hope they come up with some good options as this news
| settles. It's hard to see this as anything but even just a
| accidental push ('well you should always have written an app
| for the app store') to force folks to write a native app /
| participate in the app store.
| diggan wrote:
| Yeah, as far as I understand, cookies is the only storage
| method that will be left to use for long-term storage of user
| data. If I'm wrong, someone please correct me.
|
| Edit: getting downvoted without any reasoning provided, so I
| assume I'm incorrect, there are more/less ways of storing data
| in the future for Safari users?
| gsnedders wrote:
| Cookies expire in the same way.
| diggan wrote:
| With cookies you can set the expire time yourself, as a
| developer. And looking at the list of the original blogpost
| from webkit (https://webkit.org/blog/10218/full-third-
| party-cookie-blocki...) it shows the following will be
| affected by the 7 day cap:
|
| Indexed DB, LocalStorage, Media keys, SessionStorage,
| Service Worker registrations
|
| Since cookies are not mentioned, I'm assuming it's NOT
| affected by the 7 day cap but will instead continue to work
| as normal (except for the fact that 3rd party cookies will
| stop working, which is a Good Thing)
| tyingq wrote:
| If the cookie is set by http headers, yes. If it's set
| with client side js, though, it's capped at 7 days (since
| ITP 2.1).
| Dylan16807 wrote:
| What if you have a cookie set by http and try to update
| it with js? Will it self-destruct now?
| cosmie wrote:
| Technically, when you update it via js you're overwriting
| the existing cookie with a new one. And, from my
| understanding, it's then subject to the same restrictions
| as any other cookie set client side.
|
| So in order to have a long-lived cookie, you essentially
| need to treat them as read-only client side, and push any
| and all update/write logic to the server such that it'll
| return a set-cookie header with any changes you require.
| tyingq wrote:
| I would guess is works, but expiration is capped at today
| + 7 days.
| XaspR8d wrote:
| Does this mean I'll soon be setting up an dummy "cookie
| maker" endpoint on my server that turns XHR body data
| into HTTPS cookie data as a workaround? :/
| diggan wrote:
| Interesting, I did not know that. Thanks for clarifying!
| tnorthcutt wrote:
| Not sure if this answers that, but:
| https://webkit.org/blog/8613/intelligent-tracking-
| prevention...
|
| _Cookies can either be set in HTTP responses or through the
| document.cookie API, the latter sometimes referred to as
| client-side cookies. With ITP 2.1, all persistent client-side
| cookies, i.e. persistent cookies created through
| document.cookie, are capped to a seven day expiry._
| yesimahuman wrote:
| If you're using Cordova or Capacitor this is why, at Ionic, we
| recommend never using localStorage for storing important data.
| Better to use an explicit filesystem storage solution like
| SQLite.
| nradov wrote:
| Have you considered porting to a native application?
| vetinari wrote:
| 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.
| gridlockd wrote:
| 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.
| vetinari wrote:
| The issue is elsewhere: you need to pay your developers
| to develop the second app. You would most probably need
| to bring in one more team, for each native platform.
|
| Will you get new users from that? If yes, they will pay
| for that (in principle). If not, just some existing users
| would migrate? Then you just increased your cost without
| increasing your revenues. So you would need to gain
| enough new users to make it worthwhile.
|
| * * *
|
| In a nutshell, it is the same reason why Adobe won't port
| their apps to Linux. They already have all the users that
| _need_ their software, and while it would be nice for
| some of their users to migrate, it won 't bring anything
| to Adobe.
| gridlockd wrote:
| You don't need a dedicated developer to ship a WebView
| app. That's the whole selling point behind tech like
| Cordova. Most of your code can stay the same and most
| likely all of it will stay Javascript (or whatever you
| are transpiling to it).
|
| Again, if you are actually affected by this issue right
| now, you have a web app that is more or less trivially
| ported to a web view app. Your user don't have to
| migrate, they already have accounts, they just need to
| download the app again, this time from the App Store.
|
| > In a nutshell, it is the same reason why Adobe won't
| port their apps to Linux.
|
| Linux is a non-market for Adobe apps. On the other hand,
| if you have an offline PWA right now, you most likely
| already _have_ iOS users that you would probably lose if
| you start confronting them with this "7 days and your
| data is gone" bullshit.
| Touche wrote:
| I've considered just not supporting iOS.
| tarkin2 wrote:
| All moves of Apple's towards privacy are tempered with the
| knowledge that smooth, successful webapps hurt the iPhone's
| business proposition.
|
| Apple want to move you closer into their walled garden with the
| prospect of enhanced privacy.
|
| The idea that iPhone apps are more private than web app because
| Apple must approve your apps is troublesome.
| nicoburns wrote:
| I really hope the outcry about this is big enough to get Apple /
| Webkit reconsider. With service workers and improvements in
| browsers/cpus "PWA"s (aka web apps) were just getting to the
| point where they could compete with native apps for a number of
| use cases. And they had much better privacy / security policies.
| This doesn't completely kill that, but it's a big setback.
| pier25 wrote:
| > I really hope the outcry about this is big enough to get
| Apple / Webkit reconsider
|
| I seriously doubt it. Apple has been undermining web dev for
| years.
| JumpCrisscross wrote:
| > _they had much better privacy / security policies_
|
| Why is a PWA better from a privacy or security perspective than
| a native app?
| judah wrote:
| Security: it runs in the browser's sandbox. Native apps by
| contrast generally have (or can request) full access to your
| system.
| threeseed wrote:
| As others have mentioned this is simply not true on
| MacOS/iOS.
|
| Also would add that Apple vets native apps.
| JumpCrisscross wrote:
| > _Native apps by contrast generally have full access to
| your system_
|
| This doesn't accurately describe iOS apps, the pertinent
| comparison with respect to the article.
| nicoburns wrote:
| And Privacy the same: Native apps often have access to e.g.
| microphone. Web apps only have that for the duration that
| you enable it for.
| Klonoar wrote:
| The macOS sandbox exists to mitigate this. The system also
| goes out of its way to let you know you're running an un-
| sandboxed-app.
| mr_toad wrote:
| Not any more. Even the terminal needs to request access to
| parts of the file system.
| soapdog wrote:
| This depends on many factors but a PWA can be inspected by
| third-party using the browser developer tools which makes
| easier to find out about its communication. You can do that
| with proxies and other heavier tools for native apps, but it
| it requires more skills than the former. Also the web
| platform is very private, you don't get access to files and
| many other features without user consent. Native apps might
| not be like that even though Catalina is going crazy with the
| permission dialogs.
| Klonoar wrote:
| I mean... hang on there.
|
| The sandbox, while questionable at first, has slowly been
| improving and at this point gives the same features as the
| web you're describing. If anything I find the APIs more
| feature complete, albeit less well documented as... well,
| let's face it, this is Apple and macOS we're discussing
| here. ;P
|
| I'll also note that "requires more skills" seems like a bit
| of a blanket statement to me. They're just different sets
| of skills.
| vanderZwan wrote:
| I would be OK with 7 days being the default with a permission
| model where I can grant a website longer storage time.
|
| Actually, I'd be even happier if _any_ form of offline storage
| required explicit user permission anyway.
| m-p-3 wrote:
| There's certainly a balance to achieve there. Too few
| permissions prompt and you lose control, and too many and you
| get desensitized or even worse annoyed at them.
| marcosdumay wrote:
| There's no balance. You just let the user set any permission
| and make the prompts unobtrusive.
| brazzy wrote:
| There is no such thing as an "unobtrusive" prompt.
| callmeal wrote:
| Actually there is - firefox does it all the time. It's
| simple really - just add a new obscure configuration
| parameter and tada - the browser starts ignoring your dns
| resolution setting and automatically uses a preconfigured
| one. No need for a prompt, obtrusive or otherwise.
|
| network.trr.mode I'm looking at you.
| vbezhenar wrote:
| I configured my Chrome to block sounds on all websites
| except for a few selected ones. Now if blocked website
| plays sound, I can see tiny icon in right of my URL bad.
| It's absolutely unobtrusive, yet I can enable sound with
| two clicks.
| barnabee wrote:
| Some browsers show an icon in the address bar when an app
| is requesting/can make use of an optional permission or
| feature. Clicking the icon allows you do grant the extra
| permission (i.e. allow cookies, enable, camera, etc.) but
| otherwise no additional prompt is shown.
|
| I think this is an excellent example of such an
| unobtrusive prompt and is how ALL such features should be
| implemented. Sites should get almost no permissions by
| default and certainly not be able to show popup prompts.
| brazzy wrote:
| That is not a prompt at all, just a fancy configuration
| option. Which most users will never notice and just
| assume the app is broken.
|
| When the site tells them to "active X permission" without
| telling them how to (for their specific browser version),
| most will leave instead.
|
| When the site gives super detailed, up-to-date
| instructions on how to activate the feature, a very large
| percentage of users will still leave instead.
|
| When the feature is so useful that many sites go through
| all thouse troubles and it's common enough for users to
| encounter this that they'll follow through, most will do
| so for every site that tells them to and entices them
| with "ACTIVATE X TO RECEIVE YOUR $10,000 PRIZE, LUCKY
| WINNER!!!".
| layoutIfNeeded wrote:
| Both network usage (in native apps) and storage (both for
| native and web apps) should prompt for permission IMO.
| streptomycin wrote:
| Even before this change, data in IndexedDB was kind of volatile
| - if a device was low on space, browsers could delete stored
| data.
|
| https://dexie.org/docs/StorageManager describes the
| StorageManager API which lets you prompt the user to allow your
| IndexedDB data to be stored more reliably. My first thought
| after reading this article was wondering if this would allow an
| exception to the 7 day rule... but then I remembered that
| Safari is the only "modern" browser which does not support the
| StorageManager API
|
| lol, sucks for users of my client side JS video game!
| Aardwolf wrote:
| > Actually, I'd be even happier if any form of offline storage
| required explicit user permission anyway.
|
| Even offline storage that is only used locally? Say a game with
| savegames that has doesn't use online connection to play it.
|
| Another example: a password manager.
| SkyBelow wrote:
| I would say yes. The reason being is that exceptions will be
| abused, so it is better to enforce rules that everyone has to
| follow than to depend upon good behavior which the people we
| are trying to stop won't (almost by definition, because we
| wouldn't be needing to try to stop them with rules if they
| were already respectful of the social contract).
| andrewla wrote:
| If there were a way to enforce that the application has no
| access to any communication system (network, inter-app, maybe
| excluding explicit copy/paste), then I would be happy to give
| it permanent storage.
|
| But as soon as you allow it any access to network resources
| then carrying state becomes a liability.
| pwinnski wrote:
| So Apple can't really care about privacy because:
|
| - They have a News app
|
| - They haven't rejected apps from Google and Facebook
|
| Can you imagine what would happen if Apple rejected apps from
| Google and Facebook? Can you even fathom the outcry?
|
| Apple News uses differential privacy and doesn't track user
| history, but yes, they do provide personalized News I guess? They
| must not care about privacy at all then!
|
| If you're upset about a seven-day limit on local storage, okay. I
| get it. It sucks. But to claim Apple's reasons for this are
| invalid because they allow Facebook apps to exist, that's...
| weird.
| mfer wrote:
| This whole thing is about trade-offs.
|
| If tracking companies cannot use cookies they can use JS and
| local storage instead. Then they can keep tracking people for
| long periods.
|
| So, in the escalating war Apple alters local storage so that non-
| use for more than 7 days doesn't keep data along. It becomes less
| valuable for use with tracking.
|
| The trade-off is that offline web apps become less capable and
| some use cases go away (e.g., completely offline).
|
| Which trade-off is better for whom and in general? I've not
| thought to know. But, the trade-off is worth pondering. Whether
| we agree with Apple or not.
| djsumdog wrote:
| I love that the app he wants to build is an RSS reader. I just
| did a post on why we should be making more use of RSS as
| individuals:
|
| https://battlepenguin.com/tech/rss-the-original-federated-so...
|
| Interesting he ran into the CORS situation with PWAs. It makes
| sense. It feels like even PWAs aren't that far off from Electron.
| Sure you're not launching another browser and can share a browser
| engine, but you hit other limitations.
|
| I'd rather have a real, lightweight, stand alone app most of the
| times honestly. I wish people would write more stuff in Qt5. You
| can bundle Python+PyQt5 together for a reasonable licensing fee.
| A great example is the Resolve color/video editor is written in
| C++/Qt5.
| jwr wrote:
| I have an app which isn't offline, but I wanted to make use of
| IndexedDB and LocalStorage to make things faster for users. Now I
| wonder if it's worth the effort to even try. I think this pretty
| much kills the utility of all local storage initiatives.
|
| My app is an inventory control system used by businesses that
| build electronics (https://partsbox.com/). Deleting client-side
| data after 7 days is ridiculous. You can't assume that people
| will always log in every week, in small businesses or
| design/manufacturing companies there are times when 2-3 weeks can
| pass without building new hardware or touching inventory.
| gok wrote:
| Your demo page is 3.23 MB. ~500KB is javascript, ~500KB is CSS
| and another ~400KB is web fonts. The parts database is 24 KB.
| That's certainly not the first place I would look for an
| optimization target, even for customers with very large parts
| databases.
| jwr wrote:
| With respect, I believe you are mistaken about what my
| important use cases are like.
|
| Not going to go into details, but that JavaScript, CSS and
| fonts are all immutable assets, never to be requested again,
| while the database is _significantly_ larger for clients who
| run their businesses using this software.
| k__ wrote:
| CouchDB and Amplify Datastore do delta syncs, should this get
| around the problem?
|
| If you put data in IDB, it will stay there for 7 days and then
| if it gets deleted the delta sync would just download it again.
| diegoperini wrote:
| Both your and Apple's concerns are valid. This change makes the
| fact (arguably) that these local storages are caches apparent.
|
| Some web apps already saw the danger of having an easily purge-
| able storage on the client side and simply implemented an
| export function for their tools. I admire those tools more than
| the ones who overuse local storage for everything.
|
| One such tool is draw.io, a flowchart maker. You use the app,
| persist everything in local storage and when you are done, you
| export your project into a file, all happening on the client
| side. When you need to edit, you import the file on launch.
| It's portable, it's protected from browser bugs/decisions and
| imho pretty user (privacy) friendly.
| jimpick wrote:
| This is terrible...
|
| I have a copy of my "DAT Shopping List" demo I last opened about
| 6 months ago saved to my iPhone home screen... I opened it, and
| the data was still there. I'll be really sad when I open it again
| after iOS autoupdates and the data will be nuked.
|
| https://github.com/jimpick/dat-shopping-list-tokyo
| fossTheWay wrote:
| >deleting all local storage (including Indexed DB, etc.) after 7
| days
|
| Evil company. How do we fix this? Shame users?
|
| The problem is that the users are so brainwashed from decades of
| Marketing.
| lotsofpulp wrote:
| > The problem is that the users are so brainwashed from decades
| of Marketing.
|
| Is there any other device or ecosystem of devices where my
| parents can fix their problems by turning it off and on? The
| fact that I have 80 years old grandparents who can't read
| English using iPads and iPhones is not just marketing, that's
| "not having to google and download malware bytes and ccleaner
| and go into regedit" to maybe fix issues.
| hu3 wrote:
| Android?
|
| I've had to aid my parents using Apple devices just as much
| as Android (father likes iPhone, mother prefers Samsung
| Galaxy).
|
| edit: so much for anecdotes...
| anon102010 wrote:
| Most of us have caught onto the scam promises of ongoing
| support from android device makers. With an iphone you are
| pretty sure of 3-4 years of good support. Doesn't the
| latest iOS support the iphone SE? And I think iOS 12 is
| still getting updates (Jan 2020).
| hu3 wrote:
| By most of us you're referring to a minority that use
| iPhones?
|
| That's a very US centric view. And even among those, most
| iPhone users aren't tech savvies.
| lotsofpulp wrote:
| My dad downloaded a bunch of malware on his one plus. I
| refused to waste my time helping him uninstall it (he feels
| that it's his god given duty to click on everything, and
| the shadier the source, the more click worthy it is). So he
| tossed it and got an iPhone. Now he can click all he wants.
|
| Also android doesn't have any tablets comparable to iPad,
| and they don't or didn't have any video call app as easy to
| use as FaceTime. Although, whatsapp video may be just as
| good now, but I have a few grandparents and a great
| grandparent who don't have phone numbers, so FaceTime works
| better in our family.
|
| Also, we use our devices until they die. So we need them
| getting security updates as long as possible, which doesn't
| happen on Android. We have 4+ year old iPhones and iPads
| being used, all pretty much up to date on security updates.
|
| My point is whatever marketing Apple does, the product is
| clearly superior in many ways so it's ridiculous to claim
| people are just "brainwashed".
| jmull wrote:
| Ah.. well, ok, but this is pure nonsense.
|
| First of all, the various kinds of browser local storage have
| always been volatile. It has always been a _bad idea_ to treat it
| as permanent storage. Maybe it 's a little more obvious now? Not
| exactly a bad thing.
|
| > the PWAs I was building here might just be dead for iOS users
|
| If so, it was already dead for your users, whether you realized
| it or not. I guess you were going to implicitly promise something
| you could not deliver: that your PWA would keep track of the
| feeds the user was subscribed to (and perhaps also keep track of
| what had been read, and other user state). But you were going to
| _screw your users_ , because a PWA without external persistent
| storage could not do that reliably. It's really luck for your
| users that this caught your attention and has you rethinking your
| app.
|
| A partial list of things completely external to your app (not
| including this change) that could cause your users to lose things
| important to them that you stored in various local storage...
| * user switches browser * user has multiple devices
| * user upgrades phone (or tablet, or workstation, or laptop)
| * phone (or other device) goes in for repair or upgrade *
| major change to browser (like Edge moving to chromium) *
| some OS updates * user clears browser data (as
| innumerable troubleshooting processes suggest)
|
| It's wrong to think browser-based storage used to be stable but
| now isn't. It never was. Browser-based storage was never going to
| be a good place to store your user's important, persistent data.
| taway555 wrote:
| I'd rather use a native app than a PWA any day of the week. The
| experience of a mobile web app is clunky, slow, typically ugly,
| and just a generally bad experience.
| davweb wrote:
| 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...
| magicalist wrote:
| > _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-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
|
| (with follow up replies on what resets the seven day clock)
| brlewis wrote:
| 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-blocki...
| t0astbread wrote:
| 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
| pier25 wrote:
| > _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
| noobquestion81 wrote:
| 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 wrote:
| They already have-the post referred above is old.
| BiteCode_dev wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| kevin_thibedeau wrote:
| When will Google Analytics and Google Tag Manager get onto this
| list of trackers? Lots of web apps are using them.
| t0astbread wrote:
| 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 wrote:
| So this would apply to t.co links from Twitter, for
| instance?
| t0astbread wrote:
| 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 wrote:
| I think confirmation in the blog post yesterday would have
| provided a lot of clarity.
| Aissen wrote:
| There are still people who believe Apple cares about the web
| platform, 12 years after they forbade browser competition on iOS
| ?
| shireboy wrote:
| Does this affect Cordova apps? They use WebKit and may store
| stuff like api tokens in local storage
| wolco wrote:
| It doesn't scale from device to device for settings or items that
| should stay for longer than a week.
|
| Local storage should be treated as cache.. it may get refreshed.
|
| What Apple did was fine. A backend isn't only for storage either.
| soapdog wrote:
| It is not fine if you're creating apps that don't have a
| backend.
| finaliteration wrote:
| Honest question - If you're creating an app like that, is a
| PWA really the right way to go? Aren't there other options
| available (such as creating a native app with a SQLite
| database)?
| untog wrote:
| Well it isn't _now_ , no, because Apple have made the
| platform unsuitable for it. But it was fine.
| soapdog wrote:
| Honest answer, it depends on the app. For some cases sure,
| just throw it in cordova and be happy.
|
| It is my own personal take that PWAs are more powerful than
| we give them credit and that they could be used for private
| apps without backends where you leverage the benefits of
| web distribution while keeping data private. Doing the
| native/hybrid app forces you into dealing with gatekeepers,
| distributing on the web does not.
| Cu3PO42 wrote:
| Sure you can do that. But now you need a Mac, probably an
| iOS device and pay $99/yr to Apple. If you're just
| providing a small one-off solution for a particular problem
| that you're not monetizing, the above may pose a serious
| problem.
|
| For example, I (used to) maintain a tool that is
| essentially a save file viewer, but must store some data
| for decryption of said files. It's an Electron app, but
| could work as a normal website for the most part as well. I
| got a prototype of that up and it stores the required data
| in local storage. I don't want to maintain and host a
| backend for it, and I'm not too hot on paying Apple's
| developer fee for it, either.
|
| You may say it's a fringe use case, and it probably is, but
| it's very much legitimate. I don't know why they couldn't
| have made storage for longer than 7 days with an extra
| permission to be requested.
| [deleted]
| vbezhenar wrote:
| What if I want to create a porn app which Apple does not
| allow to be present in AppStore?
| the_other wrote:
| Can you describe this porn app which also benefits from
| being a PWA and doesn't need a backend?
| jeroenhd wrote:
| There's swathes of apps that will never be allowed on
| popular app stores (gambling, porn, sometimes apps that
| Google or Apple doesn't want competing with their own
| services). You can created a native app but it'll only be
| usable on Android.
|
| Native applications also require acquisition of a Mac and a
| $99/year membership (iOS) and $25 (one-time fee for Google
| Play). A web application is mostly hosting costs which can
| be near free if you use the right cloud services.
|
| I don't know of an alternative that will let me develop a
| small tool that will be free to develop and distribute, is
| not subject to restrictive store policies, works on desktop
| and mobile and is capable of things like accessing the
| device's camera and location when necessary.
|
| I'm personally a fan of PWAs because they can't secretly
| write identifiers to my phone's SD card, they can't extract
| my contracts, they can't monitor my location in the
| background, etc. Sure, modern smartphone operating systems
| allow you to set up proper restrictions, but that puts the
| responsibility of making applications behave on me instead
| of on the phone.
|
| Sure, native applications have their place (geofencing,
| native performance, file system access, system APIs) but in
| my opinion so do PWAs.
| wolco wrote:
| If you don't have a backend and don't want to use sqlite or
| something externally you can't save your data with the
| expectation it won't get erased. Before this change someone
| could manually clear storage, running out of space could
| trigger erasing this, etc. Now things clear after 7 days.
|
| If you care about saving that data forever don't use local
| storage. Just like don't expect cookies you set on the client
| not to be modified by the client.
| gowld wrote:
| It is fine if your apps use only 1st party scripts and not
| 3rd party scripts.
|
| > 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.
| SahAssar wrote:
| A lot of "normal" apps treat local storage this way. A lot of
| those apps are basically a wrapper around a WebView. Why does
| apple accept it there but not for PWA:s?
| WalterSear wrote:
| This sounds like a death-knell for my personal project: a fully
| decentralized collaborative task/wiki, built on ipfs, and
| encrypted against your blockchain wallet. I had just migrated the
| backend from firebase, too, and was ready to re-launch the beta
| next week.
|
| Pretty much any PWA that was using ipfs as anything but a
| caching/distribution layer is no longer viable. This is a huge
| blow to decentralization technology.
|
| Sure, you can make a standalone app, but that is going to cripple
| already difficult adoption.
|
| This sucks :(
| soapdog wrote:
| I'm coming from a decentralization tech background as well and
| was working on similar stuff. That's why I'm so angry at this
| arbitrary decisions by Apple. This is just them breaking
| something that has been working well.
| blauditore wrote:
| Wait, does that mean that the only way to keep a login session
| for more than 7 days will be by using cookies? This seems like a
| terrible idea. Cookie authentication doesn't make sense in
| several scenarios, especially when working in a CORS context.
|
| For webapps that keep a session token stored locally, this will
| be inevitably wiped, so users will have to re-login after that
| time. I can already hear the complaints coming. Should devs now
| build a back end just to keep the token, and connect there with a
| cookie?
| chadlavi wrote:
| If you want to make an app that someone can use offline on their
| device, why are you making it as a website at all?
| rapind wrote:
| It would be nice to eventually have a standard way (OS / browser
| specific) of asking permission to use permanent storage with
| restrictions. Could be locked down by domain etc.
| alexcroox wrote:
| Are we absolutely sure they don't just mean the localstorage
| containers that aren't part of the current domain? In the same
| way they are clearing cookies from a different domain, and not
| the ones that belong to the current domain.
|
| EDIT: Clarification from a Webkit dev
| https://twitter.com/alexcroox/status/1242559843354972161
| dangoor wrote:
| Yeah, if you look at the section in question, they're talking
| about this: "However, as many anticipated, third-party scripts
| moved to other means of first-party storage such as
| LocalStorage."
|
| Basically, the ad tech/tracker folks were using first-party
| site storage to store identifiers, which is what Apple's trying
| to protect against.
| garganzol wrote:
| Pretty much an expected move from Apple in its current state,
| shape and form. Security is such a sweet excuse for a tyranny.
| pat2man wrote:
| Sounds like the solution is to add the app to your home screen. I
| don't think its reasonable for a browser to let any site I ever
| interact with to store data on my device indefinitely
| dwnvoted2hell wrote:
| I don't understand why you wouldn't rely on some other normal
| local storage for an app, except to be super lazy making cross
| device apps with some platform. I think that's what all the
| screaming is about. Low budget cross compatible apps will
| suffer.
| soapdog wrote:
| Even web apps that you add to your home screen are subjected to
| this.
| redindian75 wrote:
| "Web applications added to the home screen are not part of
| Safari and thus have their own counter of days of use."[1]
|
| From WebKit: [1] https://webkit.org/blog/10218/full-third-
| party-cookie-blocki...
|
| A Note On Web Applications Added to the Home Screen
|
| As mentioned, the seven-day cap on script-writable storage is
| gated on after seven days of Safari use without user
| interaction on the site." That is the case in Safari. _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.
| untog wrote:
| > 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.
|
| This is a baffling word salad. So they _are_ tracking days
| of use of home screen web apps... which sounds like it
| means that if you do not use the app for seven days the
| cache _will_ be deleted... but they don 't expect a web app
| to have its data deleted. What?
| iameli wrote:
| The only coherent interpretation I can think of is that
| accessing example.com in a home screen app doesn't reset
| the timer for example.com in Safari. And vice versa. But
| it's still really unclear whether that implies that home
| screen apps get their data wiped or not.
| jsmith45 wrote:
| Home screen installed PWAs are treated as a separate web
| browser.
|
| For all web browsers, content is only deleted after 7
| days in which you use that browser. So if you shut for
| phone off for a month, and then turn it on, and open
| safari, that whole month only counts as one day, since
| you did not use the safari browser during that month.
|
| The same rules apply to PWAs installed to the home
| screen, which are being treated as seperate browsers. Of
| course, the count of days of use of this "browser"
| without using the main site will always remain zero.
|
| But for third party cookies, or third party content from
| an iframe that uses local storage, those would get nuked
| if the home screen installed PWA is used on 7 different
| days without interacting with those domains.
| seanwilson wrote:
| > 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.
|
| Can anyone explain this with an example?
|
| So web apps added to the home screen will have their
| storage wiped under some scenarios? If not, what does "have
| their own counter" mean?
|
| How are web applications added to the home screen not part
| of Safari in a way that's different from a regular URL you
| might visit?
| ardy42 wrote:
| > Can anyone explain this with an example?
|
| Note this is totally based on my reading of the GP:
|
| >> As mentioned, the seven-day cap on script-writable
| storage is gated on after seven days of Safari use
| without user interaction on the site."
|
| I'm understanding this to mean: you access Site A and it
| stores data to your local storage on day 0. Then you use
| Safari for Sites B, C, and D, _but not A_ for the next 7
| days. Since Safari has been used for 7 days without using
| Site A, Site A 's data is cleared.
|
| >> 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.
|
| I'm understanding this to mean there's no distinction
| between Safari and Site A anymore. Since you can't use
| Site A for 7 days without using Site A, Site A's data is
| never cleared.
|
| It would make much more sense for them to just disable
| the counter in this case, or at least just explain it
| that way. It would be less confusing.
| jsmith45 wrote:
| Home screen installed PWAs are treated as a separate web
| browser.
|
| So installed PWA's do have automatic deletion, but that
| basically only applies to third party content (like
| advertiser tracking cookies, or content from other sites
| you show inside an iframe), since the number of days used
| since last interaction counter will stay at zero for the
| main site.
| fiddlerwoaroof wrote:
| If you add the Twitter PWA to the homescreen and don't
| use it for seven days, it's storage will be reset and
| you'll have to log in again.
|
| I think WebKit's handling of local storage is the prime
| example of how optimizing for privacy to the exclusion of
| every other consideration is user-hostile
| CodesInChaos wrote:
| I don't read it like that. It's not about 7 days real
| time, it's about 7 days on which you use the app.
|
| Since you can use Safari without visiting the PWA's
| domain, this feature can delete the data of a PWA which
| runs in Safari.
|
| Since you can't use a homescreened PWA without it
| visiting the associated domain, the data saved by the
| PWA's domain will never be deleted for homescreened
| applications. But data associated saved by other domains
| can still get deleted if you use the application for 7
| days without it opening that domain.
| veeti wrote:
| How is this any better?? I don't expect apps I install -
| native or PWA - to clear their data if I don't use them
| every 7 days. That's crazy!
| slipheen wrote:
| I'm not sure I understand how it is "installed" if you
| aren't adding it to your homescreen?
|
| Isn't that just visiting a webpage?
| soapdog wrote:
| the service worker is installed regardless if you add it
| to the home screen.
| KarlKemp wrote:
| Of not, this also contradicts the article's scenario of
| going on vacation. Only days with _some_ browser use are
| counted.
| iameli wrote:
| > Web applications added to the home screen are not part of
| Safari and thus have their own counter of days of use.
| [...] We do not expect the first-party in such a web
| application to have its website data deleted.
|
| I don't get it. Which of these statements is correct?
|
| 1. "Web applications added to the home screen are not part
| of Safari and thus have their own counter of days of use.
| Of course, that counter doesn't do anything. It just sits
| there, counting, for no particular reason. We just love
| counting things!"
|
| 2. "We do not expect the first-party in such a web
| application to have its website data deleted. Except, of
| course, if they don't use the web application for seven
| days. In that case, that data will be _extremely_ deleted!
| Really just wiped from the face of the earth."
| [deleted]
| kyralis wrote:
| Neither.
|
| The counter is per days of application use, so (2) is
| false. Not using the app does not affect the counter.
|
| The counter is also per domain, and so while the _first
| party_ domain for the PWA (which is likely to, of course,
| be loaded on each PWA launch) is effectively meaningless,
| if you visit other domains from within the PWA they will
| be subject to the counter independently.
| iameli wrote:
| Okay, that makes sense - counter is third-party domains
| only. Thanks!
| Dylan16807 wrote:
| So let's say I launch the zombocom app, then click a link
| inside the app for "zombo updates" that goes to their
| twitter.
|
| Then the next few times I switch to the app, I don't
| launch it from scratch, I just look at the twitter.
|
| Then I've gone seven days inside the zombocom app without
| touching their actual domain.
|
| Does everything except the twitter cookies get deleted?
| iameli wrote:
| I believe the first-party primary domain of the app will
| never have its data wiped -- though the article could
| certainly be clearer on the point. What would be cleared
| in that case would be any _other_ domains -- if there 's
| also a "Visit Zombo Facebook" link in there, and you only
| looked at Twitter for a week, the Facebook cookies would
| be wiped.
| nikkwong wrote:
| It depends on the context.. For example, I use an invoicing web
| app that stores previously created invoices indefinitely in
| localStorage. This gives me the benefit of not having to manage
| login credentials and keeping everything client-side. It also
| gives the site's developers the benefit of not having to manage
| user accounts or server side state.
|
| Without being able to use localStorage as a long term store,
| I'll have to register for an account, have to deal with them
| handling my data, etc. Losing the functionality of localStorage
| as a long term store has disadvantages.
| chrisfinazzo wrote:
| An update from John Wilander would seem to confirm that this
| _could_ happen in Safari - and they consider it a bug.
|
| Of note, John's replies also mention this policy does not apply
| to WKWebView or UIWebView, because they lack ITP.
|
| https://twitter.com/johnwilander/status/1242882202301427712?...
| oefrha wrote:
| The argument would be stronger if the post got into what privacy
| protection in Safari isn't available in the Apple News app.
| Instead there's a seemingly random plug for a content blocker app
| I've never heard about, which upon further inspection happens to
| be sold by the author.
| mathiasrw wrote:
| Why not let users give access to that one site use data older
| than 7 days? So data stays but its only being deleted if you
| click that it can access (first time only - next time it
| remembers)
| megous wrote:
| How does this make sense logically? Obviously the websites that
| you use the most have the biggest potential and opportunity to
| track you. All local storage should be deleted for the most used
| websites at random times, at avg. several times a week, without
| any extensions caused by recent website usage.
|
| If this is done for privacy's sake, that is.
| quotemstr wrote:
| > All local storage should be deleted for the most used
| websites at random times, at avg. several times a week, without
| any extensions caused by recent website usage.
|
| No matter what browser vendors do, it will never be enough for
| "privacy" activists.
| arkanciscan wrote:
| People who use WebKit deserve it
| flixic wrote:
| Safari already was lagging behind Chrome, Chrome forks and
| Firefox in a lot of feature adoption. This will only make it more
| of a "new Internet Explorer", a browser that sites recommend you
| NOT to use.
| realusername wrote:
| As a web developer, I spend as much time to fix stuff for
| Safari as for IE11, I consider them on a similar level.
| twsted wrote:
| Normally when one said "the new Internet Explorer" he meant
| "the browser that was always recommended to use", "the browser
| that stopped innovation because it was almost the only one
| used".
| scarface74 wrote:
| Good luck with telling people not to use Safari (or more
| accurately WebKit) on iOS....
| hesarenu wrote:
| Nothing to tell. They don't have a choice.
| EGreg wrote:
| You're right. Tell people not to use iOS
|
| https://www.forbes.com/sites/gordonkelly/2020/03/14/apple-
| io...
|
| You Apple users will put up with anything!
|
| (disclaimer: iOS user)
| megous wrote:
| Lol, 50GB unexplained mobile data consumption. That'd be 3
| months worth of rent on my mobile data plan. Good luck ever
| getting out of debt if that happened on some more expensive
| international roaming.
| saagarjha wrote:
| By Gordon Kelly, who gained notoriety for his "nasty
| surprise" set of iOS articles he'd put out whenever there
| was a new iOS update. Glad to see he's still at it.
| andy_ppp wrote:
| Am I right in saying this prevents any embedded widgets that need
| to show a logged in version, i.e. comments or whatever...
| Abishek_Muthian wrote:
| I think looking at Apple as saviour of Privacy, is for lack of
| better term just wrong. They have always favoured closed systems
| even if didn't provide privacy advantages or as in this case was
| counter-intuitive for privacy.
|
| I feel the comparison of Apple with data companies such as
| Google, Facebook is by itself at fault. Apple like any computer
| company of 70's was not into data, just because Internet itself
| didn't exist at that point like it does now. 'Apple didn't choose
| to be in data' is projected as altruistic, instead of just a
| marketing ploy(they didn't choose, because it wasn't available).
|
| Apple doesn't receive even the fraction of scrutiny Google,
| Facebook receive (which they should). e.g. iCloud hack, Apple's
| response to iOS vulnerabilities targeted by state actors, Newer
| Safari being incompatible with privacy extensions such as uBO
| etc.
|
| Personally I feel good that Apple is not into data, just because
| I feel if they are into data; they might be more evil than Google
| or Facebook aided by their walled garden.
| Arnt wrote:
| This is webkit, which is open source. Apple took an existing
| HTML/CSS/DOM engine, rewrote it, renamed it, and opensourced
| its version, too.
|
| It's compiled using LLVM, which also contains thousands of
| lines of open source code by Apple.
|
| Of course you might argue that these examples don't prove your
| sweeping statement false, but please read
| https://en.wikipedia.org/wiki/No_true_Scotsman before arguing.
| testtesttest wrote:
| Open source is not the same as open. You can't run Firefox on
| an iPhone.
| Arnt wrote:
| If I understand you correctly, "open source" is not a kind
| of openness and should be disregarded. Assuming that is so,
| for the sake of argument, what _does_ count as openness?
| tekstar wrote:
| Sure you can
|
| https://apps.apple.com/ca/app/firefox-private-safe-
| browser/i...
| summerlight wrote:
| Sure you can't. That's not Firefox, but Firefox-branded
| Safari.
| Abishek_Muthian wrote:
| Before someone says I have Firefox/Chrome on my iPhone;
| they are just skins for Safari. Same vulnerabilities which
| exist on Safari(Webkit) can be exploited there as well
| since they aren't allowed to use their browser engine.
| Jasper_ wrote:
| It was open sourced as WebKit because it derived from KHTML,
| which was copyleft, and it took lawyers getting involved
| before Apple played ball and released it as open source.
| saagarjha wrote:
| > They have always favoured closed systems even if didn't
| provide privacy advantages
|
| Yes.
|
| > or as in this case was counter-intuitive for privacy
|
| I fail to see how this is counter-intuitive for privacy.
|
| > iCloud hack
|
| Targeted spearphising?
|
| > Apple's response to iOS vulnerabilities targeted by state
| actors
|
| https://news.ycombinator.com/item?id=20897368
|
| > Newer Safari being incompatible with privacy extensions such
| as uBO etc.
|
| https://news.ycombinator.com/item?id=21025252
| anchpop wrote:
| > I fail to see how this is counter-intuitive for privacy.
|
| It makes it impossible to have an app that stores data in
| localstorage reliably, instead requiring it to be backed up
| on the app's servers.
| saagarjha wrote:
| In the browser, sure. But it prevents a number of issues
| with advertisements tracking people around the web.
| diggan wrote:
| 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 now they change
| their practices, without informing users.
|
| 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.
|
| I'm eager to hear if someone here does have any solution to
| this problem though.
| thefounder wrote:
| >> 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!
| diggan wrote:
| Exactly, and when they get caught, they get fines or
| prison. Sounds good to me, let's ship it.
| thefounder wrote:
| Let me correct that for you: When they get caught thet
| get a small fine(somewhere close to 1% of their profit)
| or no fine at all.
| diggan wrote:
| Well, we're talking about a hypothetical law here, so we
| don't really know the amount... The low amounts for fines
| when it comes to big companies is a different problem
| that should also be fixed.
| stqism wrote:
| Often, the fines for breaking the law are factored in to
| the cost of choosing to do so in the first place.
|
| This is justified, of course, because the gain for doing
| so vastly exceeds losses due to the fines.
| lcfcjs2 wrote:
| Google is bad, and facebook is worst.
| FreakyT wrote:
| Agreed -- Apple's trying to project a high-minded motivation
| here, but their real motivation is likely to try and limit web
| technologies so that companies must still invest in native iOS
| apps and remain within their walled garden.
| donohoe wrote:
| I think it is worth noting that you can really say "Apple" is
| doing this or "Apple" is doing that with decisions at this level.
|
| The company is just too big and not working in unison.
|
| The Apple Safari Team is killing/hurting offline apps. The author
| asks why they don't take the same approach in Apple News - as if
| it is the same team that is in charge. Different team with
| different priorities and likely not talking to each-other.
|
| I think the larger point is valid - but it better to understand
| that this isn't some cohesive cross-company strategy at play. Its
| size-able teams working on their own priorities within a larger
| roadmap (presumably).
| JustSomeNobody wrote:
| I love these types of comments. They contrast very well with
| the "the reason Apple makes great products is because their
| hardware and software teams work so closely together to bring a
| cohesiveness that other companies can't" comments.
| diggan wrote:
| As Apple is one of the most closed companies, it's hard to put
| blame on anything Apple-related as you don't really know who
| the teams are. Sure, WebKit contributors are visible as it's an
| open source project, but who is the "Apple Safari Team" really?
| And who is the "Apple News" teams?
|
| Easiest is just to put blame on the top-level entity, which is
| Apple. They have control over their teams so they can redirect
| the blame if they feel it's needed.
|
| And if this change is to be able to force more developers to
| build native apps on their platform, then it's for sure a
| cohesive cross-company strategy. But we don't know if that's
| the case.
| diegoperini wrote:
| I already have a comment on this subject in a thread here but I
| believe this should be stressed more explicitly.
|
| Apple didn't kill offline web apps. You can always add an
| interaction to your app which exports the stored data into a file
| which then can be saved by the user. It can be done entirely on
| the client side as well. If anything died here, it is the
| implicit consent by the user for allowing unnoticed storage space
| consumption. Implementing an export function will automatically
| make your app portable, which is always appreciated I believe.
|
| Most data on local storage is some kind of structured tree, table
| or blob. All can be exported with only little effort.
|
| HTML5 games -> Prompt user with a dialog to download saves/assets
| after they play the game for a while.
|
| Productivity apps -> Detect "ctrl/cmd + s" to prompt a save
| dialog. Add save buttons somewhere visible.
|
| Map like apps -> Do nothing. If the user is not visiting the map
| for 7 days, they don't need the map data persisted either. If
| necessary, allow explicit save with UI buttons for people who
| travel often.
|
| Apps/sites which use local storage for auth related artifacts ->
| Notify users if they click "Remember Me" and explain them the
| caveats. Allow for encrypted save if users ask for it.
|
| Kiosks -> Use Electron or a similar tech.
|
| I am open to counter arguments. I don't have any idea about how
| mobile browsers behave for the scenarios stated above.
|
| Edit: I use draw.io since last year and the experience there is
| as refreshing as it can be in this SPA jungle. I use it as a good
| example to learn from for my own web app projects.
| kristiandupont wrote:
| >I don't have any idea about how mobile browsers behave for the
| scenarios stated above.
|
| That's the problem, it won't work there. Apples support for
| PWA's is frustrating to say the least.
|
| It's fair that you might need consent from the user before
| storing and keeping large amounts of data, but by removing the
| option you are forcing a bunch of developers to make a native
| app instead of a webapp which I find quite infuriating.
| duxup wrote:
| >You can always add an interaction to your app which exports
| the stored data into a file which then can be saved by the
| user.
|
| But... why? Drag the user through some dialogue to save a file
| locally / manage / be responsible for that and then deal with
| that whole deal? That seems like very... old / unnecessary.
|
| The fact that applications store some random things locally to
| me is neither surprising nor a hassle. Browsers already cache
| files and etc. Unless I don't know something... LocalStorage
| and other non cookie options seem just fine / safe.
|
| I get the concerns about cookies and such but this seems a step
| beyond what is needed into the realm of unnecessary / a hassle
| for the user.
|
| Maybe I'm missing some bad patterns / dark patterns using
| LocalStorage and etc but it seems to throw them out with the
| bathwater.
| diegoperini wrote:
| This is a valid argument.
|
| Here is a fun idea that just came to me (trying to find
| middle ground here):
|
| - Allow localStorage writes automatically, persist forever
| (choose your favorite definition for "forever").
|
| - Allow localStorage reads automatically for 7 old.
|
| - Prompt permission dialog if last read from localStorage is
| at least 7 days long.
| duxup wrote:
| I think that is reasonable ... maybe if the prompt is ...
| reasonable.
|
| I'm kinda averse to the OMG COOKIES and other super
| technical warning type prompts that worry users, but really
| don't successfully educate them or direct them too good
| outcomes / choices. Granted education / good outcomes
| aren't easy tasks there, but what's the point of a prompt
| if the decision is made by an uneducated and just annoyed
| user?
|
| I like the idea of empowering users, but not so sure about
| how we do it on the web / the best way to do it.
| pier25 wrote:
| These are workarounds for a problem that shouldn't exist in the
| first place.
| alerighi wrote:
| Doesn't make sense, just ask the permission to use the local
| storage to the user if that is the deal.
|
| But that is not the deal, the deal is that they fear that more
| and more developers are moving to webapps instead of developing
| native apps that need to pass trough the App Store and thus be
| approved by Apple, and they don't like that.
| megous wrote:
| - Give user the option whether to enable "unlimited" storage on
| per-domain basis. There's already a standrad API for that.
| aquadrop wrote:
| And for what? To save space? That's ridiculous.
|
| > If anything died here, it is the implicit consent by the user
| for allowing unnoticed storage space consumption
|
| What about explicit consent? It also dies. That's just
| inventing problems.
| donatj wrote:
| This might technically work, but is an absurdly user-
| unfriendly.
|
| Name a modern game that required you to manually manage game
| state files, let alone didn't have autosave. It's a feature
| users expect, and they're going to have a bad time. I don't
| want to play a quick game on my phone and have to remember to
| save and where I am keeping my save files.
|
| I'd argue a far better options would be just to treat local
| storage as a permission like camera or microphones.
| diegoperini wrote:
| Our suggestions are not mutually exclusive options. Both can
| coexist if the developers are ready for the implementation
| burden.
|
| The issue with the permission model is there has to be a
| mechanism to prevent overuse which I believe is always worked
| around by annoying the user with the prompt as often as
| possible until they concede.
| joshspankit wrote:
| While I agree that it's ideal to treat localstorage as a
| permission, as someone who has played a _lot_ of games over
| the years I can tell you that I _wish_ I could manually
| manage game state files.
|
| The current way iOS does it (either keep the game installed
| forever or erase all your progress when deleting it) is a
| huge barrier to me getting invested in iOS games _at all_.
| With "save progress to file" (and loading), I would be a lot
| more comfortable.
|
| I would still want autosave though. No way do I want to go
| back to the era of "oh all my work for the past 6 hours is
| just gone?"
| joshspankit wrote:
| Downvote?
| joeblau wrote:
| I don't even play games but I wouldn't expect a web game to
| store all of its metadata in my local storage. I would expect
| it to store data on their own severs and only store active
| gameplay information locally.
|
| My browser storage is not a game developers long term
| storage, its a cache.
| gridlockd wrote:
| 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.
| lstamour wrote:
| 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 storage they will use
| alternative browsers for those particular sites. And
| while site authors can block Safari with a prompt, it's
| then up to users to change browsers. Presumably for
| developers these will have knobs to tweak so local
| storage can continue working in alternative browsers on
| iOS the way it always has. Presumably Safari will
| eventually get a config toggle for this setting if it
| isn't already there. Users already don't notice when
| browser history is cleared, though advanced users will
| configure this by following instructions on Google. Same
| here.
| gridlockd wrote:
| > 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.
| lstamour wrote:
| I disagree that there's no way to implement an
| alternative to Safari, besides Chrome there's also iCab
| and other browsers that show not only a completely
| different UI but also innovative new features. Even if
| WebKit makes it impossible to remove this restriction, a
| third-party browser could find a way to intercept calls
| and keep its own local storage, read and backup native
| local storage, or provide other means to local storage
| via proprietary JS APIs, and if that browser is Chrome,
| it will gain traction. Especially if Apple changes iOS to
| allow users to change default apps.
| [deleted]
| mattmanser wrote:
| Why? Are you paying for it? To you, it's trivial amount of
| data that you can wipe if you somehow desperately need the
| 1mb, to them it quickly adds up to significant costs.
|
| I find this position absurd, just like the suggestion that
| everyone should start programming complicated user hostile
| save flows.
| dx87 wrote:
| Yes, it's their device, they literally are paying for it.
| What kind of question is that.
| hombre_fatal wrote:
| The above comment was talking about persisting save files
| to someone else's servers.
| lostmsu wrote:
| He was asking about paying for the game.
| donatj wrote:
| The article as well as my concern here is not about the
| browser proper but web apps like you install onto your
| phone and one of the major points of is that they work
| offline despite t
| floatingatoll wrote:
| It seems like the Storage Standard [1] could be combined with
| the writeable-files proposal [2] to permit the same sort of
| behavior for local files-on-disk webapps as mobile apps
| receive, where they can download large asset files and store
| them on disk in a persistent cache:
|
| https://storage.spec.whatwg.org
|
| https://wicg.github.io/native-file-system/
| snemvalts wrote:
| So i can start to manage save files on my disk? in 2020?? this
| is absurd.
|
| apple should fix their safari bugs first before starting with
| this nonsense.
| henriquez wrote:
| After the number of times my Firefox and Chromium profiles
| have been wiped clean due to browser or packaging bugs it's
| become clear to me that localStorage is not the end-all in
| terms of data persistence. It's always been a "best effort"
| rather than a guarantee.
|
| Browsers offer a lot of useful functionality, but people
| increasingly expect them to be a replacement or substitute
| for an operating system, and in terms of being operating
| systems, they're all pretty lacking. Mozilla learned about
| this with Firefox OS (it was pretty cool though, RIP)
| davvolun wrote:
| Not strictly disagreeing with you, but ChromeOS seems to be
| extremely healthy. Not familiar enough with Firefox OS to
| know why the disparity though.
| henriquez wrote:
| Then that's just my ignorance - I've never used Chrome
| OS, though I was heartened to see they were migrating to
| standard PWAs instead of proprietary parts.
|
| I worked with Firefox OS back when Mozilla was seeding
| dev kits to software companies. It was a great concept
| but really seemed marred by bad hardware and then
| organizational paralysis. IMO this is one of the greatest
| missed opportunities of the last decade - an (actually)
| FOSS alternative to Android and iOS. No one else making
| attempts in this space right now has close to the same
| engineering experience as Mozilla.
|
| For Safari, Apple adding any PWA features came off as
| them rolling their eyes, sighing loudly and then putting
| out a half-assed attempt to deliver years-old standards.
| And rather than switch to a unified extension
| architecture like Chrome and Firefox (which they were
| very close to in previous versions), they've gutted
| extension support to the point where you need can only
| bundle very limited extensions with compiled MacOS apps
| distributed on the App Store.
|
| I don't really understand what Apple is even playing at
| by offering features but not taking them seriously. But I
| just don't think the LSO expiry move is _that_ user
| hostile in the scheme of things.
| Dylan16807 wrote:
| Well I've never lost anything other than the list of open
| tabs, and that's despite using alpha versions of firefox
| and chrome half the time. Cookies and localStorage aren't
| guaranteed but they're pretty reliable. I've had more
| trouble from native phone apps losing data than browsers on
| all platforms combined.
| henriquez wrote:
| Also you could sync data to an API and offer a login function.
| If the cookie expires, login and download your data again. This
| could be end-to-end encrypted for privacy, and having remote
| storage enables other clients to login and access the same
| data. Either way it's wise to have some kind of persistence
| option beyond just cookies and localStorage.
|
| It's annoying how far Apple is behind Mozilla and Google when
| it comes to progressive web app functionality, but I don't
| think their action is as user-hostile as is being raised here.
| gridlockd wrote:
| Dear lord, I hope you don't have any UX design responsibilies.
|
| > Apple didn't kill offline web apps.
|
| Yes, they did. For an app to work offline, you need to be able
| to at least cache the app itself. If that gets wiped after
| seven days, you can't call your app "offline capable".
|
| > If anything died here, it is the implicit consent by the user
| for allowing unnoticed storage space consumption.
|
| What about the "implicit consent" that bandwidth is being
| consumed?
|
| > You can always add an interaction to your app which exports
| the stored data into a file which then can be saved by the
| user.
|
| That would be awful. Imagine being prompted to import your data
| every time you launch it.
|
| Maybe that sort of works with document-centric apps that have
| no persistent settings, but even then it wouldn't be possible
| to integrate properly into the file system in the way users
| would expect (file assocations).
|
| > HTML5 games -> Prompt user with a dialog to download
| saves/assets after they play the game for a while.
|
| More like constantly reminding the user that their valuable
| progress gets wiped after seven days, should they make the poor
| choice to run the app offline.
|
| > Productivity apps -> Detect "ctrl/cmd + s" to prompt a save
| dialog. Add save buttons somewhere visible.
|
| Same as above, except the data might be even more valuable.
|
| > Apps/sites which use local storage for auth related artifacts
| -> Notify users if they click "Remember Me" and explain them
| the caveats.
|
| "I'm sorry, we made a decision to write an app with technology
| that, in hindsight, we shouldn't have used. Therefore, your
| user experience will now be more annoying. Thanks for sticking
| with us while we're rewriting the app!"
| diegoperini wrote:
| Your response sound a little angry but maybe the tone is lost
| in the text so I will respond in good faith.
|
| > I hope you don't have any UX design responsibilies.
|
| I don't. We are safe. :)
|
| > For an app to work offline, you need to be able to at least
| cache the app itself.
|
| You can still do it, for a limited time. Your mission
| critical app will work offline if you are not planning to
| isolate your device from the internet forever. I know this
| doesn't solve the issue but I believe it is the lesser evil.
|
| > What about the "implicit consent" that bandwidth is being
| consumed?
|
| This always bugged me as well. This is unexplored territory
| for all browsers if I am not mistaken.
|
| > Imagine being prompted to import your data every time you
| launch it.
|
| I don't have to. I use draw.io excessively and it prompts me
| every single time. I actually appreciate the experience but I
| am a sample size of 1.
|
| > More like constantly reminding the user that their valuable
| progress gets wiped after seven days, should they make the
| poor choice to run the app offline.
|
| If it is valuable, maybe browser is not the best medium for
| it. Here, Apple's anti-consumer practice with its App Store
| becomes more relevant than Safari's localStorage algorithms.
|
| > "I'm sorry, we made a decision to write an app with
| technology that, in hindsight, we shouldn't have used.
| Therefore, your user experience will now be more annoying.
| Thanks for choosing sticking with us while we're rewriting
| the app!"
|
| "In order for 'Remember Me' to work as you expect, please
| visit us every once in while <3"
| gridlockd wrote:
| > If it is valuable, maybe browser is not the best medium
| for it.
|
| Progressive web apps are not "the browser". It's a platform
| to ship apps using web technology that integrate into the
| operating system pretty like any other app, at least from
| the user's perspective. It works well enough on Android.
|
| If you have to explain to your users all the caveats that
| such an app has on their platform, it just becomes
| pointless. If it becomes pointless on iOS, then it becomes
| pointless in general. You might as well go with a Web View
| app then.
|
| Of course Apple has never been all that enthusiastic about
| PWAs, giving half-assed support at best. It was never a
| great platform to begin with, but now it's effectively dead
| in the water, at least for apps that are expected to work
| offline.
| cmsj wrote:
| > deleting all local storage (including Indexed DB, etc.) after 7
| days effectively blocks any future decentralised apps using the
| browser (client side) as a trusted replication node in a peer-to-
| peer network
|
| Sounds good to me, I don't want websites turning my browser into
| a p2p node :)
| thosakwe wrote:
| I don't understand why the title was changed - the focus of the
| article isn't just on the fact that WebKit is changing how it
| handles local storage, but also a criticism of Apple's
| motivations for this decision.
| zeveb wrote:
| _And_ the new title no longer has any relationship to the title
| of the post. And no admin (from what I can see) even bothered
| to let us know why he censored this.
|
| edit: 17 minutes after posting this comment critical of
| moderation, I am unable to submit a new story. Coincidence?
| jwiley wrote:
| Is there anything to stop an application from touching the cache
| periodically (in the Unix sense of updating modification
| timestamps without changing values) on load?
|
| If so, assuming the application is used more than once every 7
| days, this seems like less of an issue.
| meesterdude wrote:
| webkit is open source - can't this be changed (be it by fork, or
| a commit proposal?)
| The_rationalist wrote:
| The PlayStation(s) browser is using webkit BTW (they are a
| decade late to switching to chromium..)
| matkalaukku wrote:
| Sure it can be forked, but the problem is the millions of
| devices running Apple's version of Safari/WebKit on iOS without
| any say in it except switching to Android.
| abrowne wrote:
| Sure, so maybe WebKitGTK will (if this applies to that
| version). But why would Apple choose to include this fork over
| their own version in their OSes? If they don't how do you plan
| on using it with any Apple OS?
| starbugs wrote:
| Is this really that big of a problem? You had to be expecting
| that local storage is deleted without any notice anyway, in every
| web app.
| MatthewPhillips wrote:
| I absolutely don't have that expectation. I built a comic
| reader app that I use on my Android tablet, which saves files
| to IndexedDB. I've been using this for over a year and no files
| have ever been deleted, even after I stopped using the app for
| a month or so.
|
| If Apple provided an alternative this would be ok. An
| alternative such as the native file access API (still a WIP).
| Or a prompt so that the user can allow long-term storage. Or
| supporting the web app manifest so that users confirm they want
| to "install" a web app, granting it greater permissions.
|
| But they've offered no alternatives here, that I can see.
| They've determined that client-side web apps are simply not
| important.
| IvanK_net wrote:
| I have many useful files in my computer, which I don't want to
| be deleted. You are saying, that it is ok, if the OS deletes
| all files in my computer from time to time.
|
| A local storage is the only way webapps can store any data in
| your computer (other than asking you to manually load / save
| some configuration file). Not all webapps can afford cloud
| storage for all user.
| starbugs wrote:
| I am not saying that it is OK to delete all your files. I am
| saying it has always been like that in the case of a
| browser's local storage.
|
| As I said, that use case was out of the window long before.
| From the start, as far as I know.
|
| No browser has ever given you any definite promise on whether
| your local storage data will be kept. That's also true for
| IndexedDB. So you need a mechanism to restore that data, be
| it cloud storage or something else.
|
| If you wanted to support Safari private browsing, you even
| had to deal with local storage not being available _at all_.
| IvanK_net wrote:
| I disagree. The IndexedDB was introduced as a permanent way
| to store data (which is not deleted after closing a
| website). As it is the only available standard for
| permanent storeage, I think it should be deleted only if
| the user asks to delete it (the same way you delete any
| other file in your computer).
|
| Of course, browsers are free to do whatever they want. But
| the user can (and will) switch to the software, which does
| what he or she wants.
| starbugs wrote:
| You disagree with the status quo implemented in browsers
| or you disagree with the decisions that were made years
| ago (by browser vendors), because you basically cannot
| guarantee for that (disk full, privacy settings, private
| browsing, etc.)?
| nicoburns wrote:
| It's different if there is a technical limitation (disk
| full - computer tend to barely function in this state
| anyway), or the user has opted in to ephemeral storage.
| But to not give users the choice to store things
| permanently is quite a severe restriction.
| vbezhenar wrote:
| Browsers keep IndexedDB data indefinitely, they don't
| delete it.
| starbugs wrote:
| There is no guarantee that the data will be persisted
| permanently. Users can erase it by mistake easily using
| privacy settings. There's also quite ambivalent size
| restrictions. And last but not least, Incognito mode,
| which also is implemented in a number of different ways
| in practice, depending on the browser.
|
| Basically, you cannot be sure that you can use it to
| persist data at all.
| vbezhenar wrote:
| Size restriction will cause error at write time, it won't
| silently delete data. User error is user error, that's
| it. I know user who was deleting files in his Windows
| directory to free some space. Incognito mode is not
| intended for web apps usage, it's more for porn and
| things like that, I don't think that it's very relevant.
|
| It works for majority of standard cases and when it does
| not work, user will receive error message, so he'll be
| aware. Not the case for Apple devices anymore.
| silon42 wrote:
| I'd love for browsers to have an opt-in mechanism to
| preserve that data (also snapshot/restore/import/export
| it).
| starbugs wrote:
| I bet there's tickets in both Google's and Apple's bug
| trackers from 2012 asking for that.
| andrewrothman wrote:
| This is a serious problem for modern web experiences.
|
| "After seven days of Safari use without the user interacting with
| a webpage on website.example, all of website.example's non-cookie
| website data is deleted."
| (https://webkit.org/blog/9521/intelligent-tracking-prevention...)
|
| Granted, this could turn out really well if the industry adopts
| another standard which requires user permission, overcomes this
| limitation, overcomes the existing limitation of LocalStorage on
| iOS getting automatically cleared when a device is low on
| storage, and overcomes the problem of sites being able to use up
| a lot of storage on users' devices without their knowledge.
|
| I'd be very welcoming of such a standard. These could be good
| future replacements if the industry can adopt them:
|
| https://chromestatus.com/feature/6428344899862528
|
| https://wicg.github.io/kv-storage/
|
| https://chromestatus.com/feature/5715811364765696
|
| https://storage.spec.whatwg.org/
| floatingatoll wrote:
| Perhaps the author doesn't realize that WebKit is open source.
| They could have used their screed to propose to the WebKit team
| that a first-party page loaded from a file:/// URI not have its
| client-side storage subject to the 7-day purge, by setting the
| "firstPartyWebsiteDataRemovalMode" network connection property to
| "none" -- patch included! But they did not, which is quite
| disappointing.
|
| The new change to ITP is here:
| https://github.com/WebKit/webkit/commit/4db42c1571d821572ea9...
|
| The cookie filtering logic specifically is located here:
| https://github.com/WebKit/webkit/search?q=filtercookies
|
| The file:/// handler is implemented here:
| https://github.com/WebKit/webkit/blob/master/Source/WebCore/...
|
| (I don't have anything to do with Apple or WebKit.)
| DiabloD3 wrote:
| Apple does not use _that_ Webkit branch, however. They maintain
| their own branch internally that cherry picks from upstream.
| Webkit could very well accept a patch, and then Safari never
| ships that patch because they disagreed with it for use in
| Safari.
|
| Also, unrelated fun fact: Did you know Webkit still uses svn?
| That Github repo you linked to is a clone of Webkit's own git
| repo (git.webkit.org), which is a mirror of their actual repo
| (svn.webkit.org).
| soapdog wrote:
| OP here, I just posted an update section on the post that touches
| some of the comments I've been seeing here. English is not my
| first language so I think that sometimes I don't make my ideas
| clear enough or well explained enough.
| IvanK_net wrote:
| It is related only to WebKit (Safari). So I think people will
| just switch to other browsers.
| diggan wrote:
| Except for iPhones/iPads where you don't really have a choice.
| Also most people don't give a shit which browser they use, they
| just use whatever browser is available when they get their
| device, which makes sense. But those users might soon have
| their data removed without really understanding why.
| IvanK_net wrote:
| So I guess more people will switch from iOS to other devices.
|
| I am the creator of a photo editor www.Photopea.com and I
| see, that more and more people care about their browsers.
| They spend a lot of time discussing the issues of their
| browser with me, because they need to do a serious work in
| it.
| foepys wrote:
| You can install other browser frontends on iOS. People just
| don't know that the backend is still Safari.
| est31 wrote:
| Offline web apps are direct competitors to apps from the Google
| play store and Apple app store. You can't expect Apple to be fair
| to them if they are missing out of their 30% for every USD of
| revenue on those web apps.
| gfodor wrote:
| We use local storage for features in hubs.mozilla.com when most
| sites would use a database, because we want to minimize storage
| of data in our servers to increase privacy. This basically will
| now force us to store this data in our database for safari users,
| eroding their privacy.
| p2detar wrote:
| Why 7 days though? Why not 30 or 3? What are Apple basing this
| number on?
| franga2000 wrote:
| Not on the main topic, but since OP mentioned CORS being a pain:
| is there a reason the browser doesn't let sites do cross-origin
| requests, but just without any cookies etc.? Either through a
| separate API or just the default behavior in the absence of CORS
| headers, is there a reason for that not being a thing? I can't
| imagine nobody has thought of it?
| talkingtab wrote:
| A previous HN discussion about PWA's replacing native apps:
| https://news.ycombinator.com/item?id=22554745
| sidhanthp wrote:
| I think this is a good idea. Developers should not be able to
| store something on my computer indefinitely without my consent.
| This doesn't apply to applications users add to their home
| screen.
|
| This doesn't "destroy" the PWA ecosystem. Just makes a user's
| intention explicit when they save a PWA to their home screen,
| rather than continuing to use it within the browser.
|
| From the WebKit Blog (https://webkit.org/blog/10218/full-third-
| party-cookie-blocki...) "Web applications added to the home
| screen are not part of Safari and thus have their own counter of
| days of use."
| duxup wrote:
| Your browser is already caching a whole lot of stuff that you
| don't know about just by visiting a site.
|
| A little LocalStorage isn't going to hurt you.
|
| Cookies I get, but I don't know of any dark patterns with
| localstorage / the benefits are pretty great.
| judge2020 wrote:
| I asked about the dark patterns above and got answers
| confirming it https://news.ycombinator.com/item?id=22687214
| duxup wrote:
| I'm not convinced that actually confirms much.
|
| One of the pages linked there just says local storage is
| used to store stuff... yeah? It's still not as wide open as
| cookies.
|
| You could use local storage while doing other things, but
| i'm not convinced it's a serious issue with tracking or
| etc. ... and if ANY storage is considered an issue I think
| we're in for a big snowball effect on what we should or
| shouldn't allow from ... anything, including native apps,
| etc.
| briandear wrote:
| What's wrong with a "normal" app? No server required and data
| stays only on the device. The argument that the author is
| building a PWA because other people abuse privacy (with apps)
| doesn't make much sense. Why not build the app, respect privacy,
| and be done with it?
|
| LocalStorage is not a substitute for an actual database, it's a
| cache. The problem with the author's technique is that privacy
| minded users clear their browsers from time to time, so they
| would be inadvertently clearing data they actually wanted to keep
| because who uses LocalStorage as a persistent data store? Sure it
| could be used like that as an "off label" use, but generally it's
| used to cache what is persistently stored elsewhere or used as a
| means to avoid multiple network calls in the process of doing
| something (such as saving calculations, the results of which
| would be eventually persisted.) Local Storage should be used as
| if it were a session store rather than something persistent.
| sj4nz wrote:
| The problem with a "normal" app is now you are beholden to the
| rules/regulations/evaluations of a third party that can easily
| decide without recourse that your "app" should not be in their
| store. Even if your app "is fine" every update and upgrade
| incurs a delay through the third party's reviewing process
| before your users receive it.
|
| If the web browsers would provide _some API_ for persistent
| storage without yanking the carpet out from underneath
| developers this wouldn't be such a huge problem. There _used_
| to be a file-access API but it was removed.
|
| Personally, I think web browsers are too large a surface area
| to secure/keep secure and the world is probably going to swing
| the opposite direction to native, downloadable applications
| without the interference of a third-party store.
| danans wrote:
| > Personally, I think web browsers are too large a surface
| area to secure/keep secure and the world is probably going to
| swing the opposite direction to native, downloadable
| applications without the interference of a third-party store.
|
| Wait, you think downloadable native apps without any
| intermediary to validate them is more secure? What you're
| describing is basically the old shareware system, which was
| riddled with security issues.
| The_rationalist wrote:
| Here's the api: https://developer.mozilla.org/en-
| US/docs/Web/API/StorageMana...
| SahAssar wrote:
| A normal app requires a separate build process, users to
| install it, manual review for each update, perhaps the platform
| owner will just deny it without reason, and for Mac/iOS it also
| requires actually owning or "borrowing" (using another
| persons/companies) build machine and software.
|
| I don't understand why an installed PWA should not be able to
| keep their storage just as a "normal" app can. It would clearly
| be better for both developers and users. There are so many apps
| & websites that could be more privacy friendly if they could
| just trust localstorage to actually be "storage".
| alkonaut wrote:
| Those sound like problems for the developer, and not the end
| user.
| SahAssar wrote:
| I don't think you understand what "users to install it"
| means for actual users.
|
| Most users are asked to install multiple apps for the
| normal sites they visit (like news sites, social media,
| imagehosting and more). They usually don't, and that's
| good. Those apps should not be apps, they should be
| websites. Most of those apps can be a simple website. If
| the users want/need more functionality that can be within a
| installed PWA.
|
| I think this is more people and developers fetishizing what
| it means to be in the app store or to be "native". If we
| can run it all in probably the best sandbox we have
| available without having vendor specific builds or vendor
| specific prompts why would we as users _or_ developers want
| anything else?
|
| Some apps should be native. But the majority of them would
| be better as webapps rather than android/iOS apps.
|
| EDIT: Also I'd argue a lot of those problems are
| artificially created by the platforms, not the developers.
| _pius wrote:
| This headline rewrite does a disservice.
|
| It editorializes away the point of the post, which is that,
| according to the author, "Apple just killed offline web apps
| while purporting to protect your privacy [by forcing WebKit to
| delete all local storage after 7 days]."
| things wrote:
| It's not super clear but, if I'm reading it correctly, the 7 days
| are 7 days of use. So if you don't open the site for 3 days, the
| counter is still at 0.
| awinter-py wrote:
| push messaging also doesn't work for PWAs on ios
|
| (it does on android)
|
| I get that controlling the walled garden is apple's mobile
| strategy now, but this is costing developers so much blood sweat
| & tears.
|
| Both xcode and android studio are heavy + horrible compared to
| web, and the fact that you have to use _both_ tools to release at
| scale makes them worse. Shopify wrote a dev post a few months ago
| saying 'we're react native as much as possible now' and claiming
| it makes life easier, but react native is worse than PWA because
| you still have to build for mobile 2x and deal w/ app store
| nonsense.
|
| If PWAs supported push on ios, with or without cookie expiration,
| they'd be the preferred launch strategy for most non-game apps.
| p1necone wrote:
| Hasn't aggressively controlling the walled garden _always_ been
| Apples strategy? I don 't see them changing any time soon. iOS
| didn't even _have_ an app store initially, and it took a lot of
| pushing for that to happen (they realized Android was going to
| eat their lunch if they didn 't).
| goofballlogic wrote:
| While I agree with the concerns regarding arbitrary
| implementation of standard APIs, there are still a bunch of
| useful applications of PWA technology to enable temporary offline
| operation.
|
| The more we use these, the more likely the APIs are to be fully
| implemented (and hopefully have features added to them).
| simion314 wrote:
| Will this affect all browsers that in iOS are forced to use same
| engine?
| chrisshroba wrote:
| Does this also mean you'll have to re-login to websites every 7
| days? (Sorry, not very familiar with web tech!)
| [deleted]
| icebraining wrote:
| No, you'll have to re-login only if you haven't been to the
| site in the last 7 days.
| pier25 wrote:
| Is this also going to affect web views?
|
| For the past couple of years I worked on an education app where
| users are 90% of the time offline. Users can remain offline for
| weeks. There the is no reliable internet in most of the schools
| in Mexico.
|
| I don't work on that company anymore but this is going to be a
| massive headache.
| pgt wrote:
| When suppliers do this, they put customers back into a buying
| position. Instead of defaulting to buying another iPhone, I'm
| back in a buying position. So let me ask: what is a good
| alternative to an iPhone Xs on the market? I was also super close
| to buying an Apple Watch, but now I'll defer that purchase.
|
| I have already stopped building native apps because the App Store
| process is so painful.
| thehappypm wrote:
| Maybe I'm being cynical here -- I'm not a web developer but have
| lots of experiencing managing web-based products -- but if you
| want to have state you should store it in the cloud, because
| local devices are volatile. Xbox Live, for example, uses a fairly
| simple service for cloud saves for games; local saves still
| happen but any developer has the option to push saves to the
| cloud. The author definitely raises good points about how it's
| easier for developers to not have to worry about it, but cloud
| saves have some hefty benefits, like multi device support, user
| getting a new device, etc.
| duxup wrote:
| The problem is (at least for me) offline apps, or for customers
| who have poor or intermittent / unpredictable internet access.
|
| They threw LocalStorage and etc out with the bathwater that are
| cookies.
| deedubaya wrote:
| Yes, you're correct, but have you ever used an app that worked
| offline or performed well with a poor network connection? Or a
| website maybe provided wicked fast data access despite only
| having a 2G connection?
|
| These technologies can be leveraged to improve usability.
| Unfortunately, advertisers and 3rd party trackers make it so we
| can't have nice things.
| z3t4 wrote:
| Apps added to the shelf should keep their data
| coffeefirst wrote:
| Great... So all those "consent to cookie/GDPR/etc/subscribe to
| our newsletter" popups will now reappear every time you go 7 days
| without visiting a site.
|
| I'm 100% on team privacy but this isn't the right way to do it.
| stwrong wrote:
| Does this consider hybrid apps like ionic or Cordova to be part
| of this?
| jchw wrote:
| Actually, Apple has crippled non-PWA apps. I agree that Apple
| does seem to not want PWAs to succeed based on my experiences
| with them on my iPhone, but on the other hand this effectively
| does not apply to PWAs that are added to the user's home screen
| since the counter only runs every day Safari runs but homescreen
| sites have their own counters.
|
| I worry that 7 days is too short of a period even then, but I do
| agree indefinite local storage does not make sense in most cases.
| mattl wrote:
| > By now, most people are aware of the amount of surveillance and
| tracking that their web usage is subject to on a daily basis and
| how this data can be used in ways that do not match their own
| personal values.
|
| Sorry, but no way.
| szc wrote:
| The data for "Local Storage" is stored in
| ~/Library/Safari/Databases -- you will need to give Terminal
| access to the Safari directory as the current Sandboxing works
| both ways, Safari stores security config info in this directory
| and scripted malware could / can exfiltrate data and change
| values in this location.
|
| To violate privacy (aka enable tracking) a sub-iFrame could be
| set up that uses "local storage" with a parent page security
| policy that allows communication across the iFrame boundary.
| Sorry, yes, I am being a bit vague.
|
| Who cleans up ~/Library/Safari/Databases? I personally see crud
| in this directory from 2011 that has been migrated from older
| systems.
|
| Almost not relevant now, but Flash also had a "local storage"
| system that was shared across all Flash Apps. It also allowed
| (before sandboxing) local apps to proxy and communicate (via
| shared memory) with any standalone Flash App on the system
| through any page that used the Flash plugin -- i.e any running
| web browser, violating all attempts to have web
| compartmentalization rules.
| szc wrote:
| I think some threads have been merged. I am now seeing some
| posts that confirm what I say above, but were made earlier in
| time that I had not seen. My experience and perspective is
| from security and privacy defense, rather than "find the
| loophole". [edited for clarity]
| [deleted]
| dennisy wrote:
| This "feature" also invalidates the use case for WebCrypto API,
| since a user's keys would be stored in IndexDB, which now means
| keys cannot be safely persisted.
| synfonaut wrote:
| Exactly this. Most "non-custodial" web wallets will die as a
| result of this change (some may even lose money/assets). Very
| unfortunate Apple!
| diminish wrote:
| Apple is at war against the open web and tries to kill it at all
| cost.
|
| Most apple apps are privacy hogs which don't have any way to turn
| off tracking. In apps, Apple created a prison which noone can
| question and everyone will allow them to do all abuse. Look at
| Apple News.
| sebringj wrote:
| That is terrible if you are working on a pwa game to cache assets
| offline. There should be some opt-in approach similar to location
| tracking in the background like some apps do. That seems way
| worse than simply having local data be relied upon. Not cool.
| icebraining wrote:
| What's the problem with the client having to re-download those
| assets if they don't play for a week? Seems long enough that
| I'd expect a patch download on a typical gaming platform, for
| example.
| bdefore wrote:
| Offline iPad kiosks
| pier25 wrote:
| This won't accomplish much in the long term. Ads networks will
| simply start introducing server side SDKs. Websites that rely on
| ads will gladly use those to keep their revenue even if that
| means more load on their server.
| Jach wrote:
| Workaround: encode your app's state into window.location.hash
| icebraining wrote:
| That works as long as the user keeps the tab open, but if they
| use a bookmark (or just remember the domain), the hash part
| will be lost.
| Jach wrote:
| The hash part is not lost to bookmarks, unless Apple broke
| that too. If it was, no one's MEGA bookmarks would work.
| icebraining wrote:
| I mean, sure, the bookmark would save a snapshot, but the
| user would have to manually replace it every time.
|
| Might be simpler to just give them a file to save / load.
| withinboredom wrote:
| I've seen this before on an ecommerce site :sigh:
|
| Wife: Hey, check out this! [link with embedded state]
|
| Me: Wow, I'm logged in as you and can even see your payment
| information! Let's not buy from this site!
|
| Let's not do this. Ever.
| recursive wrote:
| Not all data is sensitive data.
| stcredzero wrote:
| _Many web developers are turning to Electron in these cases but
| IMHO this is a waste of resources as the Electron runtime is not
| shared among the different apps running and there is only so many
| browser engines your computer can run before it has impact on its
| performance_
|
| Why? Why isn't the case that the code which runs Electron, and
| library code JIT-ted by Electron can't be reused by other
| processes on the same system?
| The_rationalist wrote:
| It can be reused, it's just that nobody actually care enough
| about contributing to upstream electron. There are unofficial
| solutions like electron-shared. Ionic and Carlo also use only
| one chromium for every instance.
| burtonator wrote:
| I ported Polar (https://getpolarized.io/) over to a PWA about a
| year ago.
|
| It's kind of a nightmare due to both Google and Apple messing
| things up.
|
| PWAs could be an amazing platform but both companies are really
| messing it up.
|
| Apple is trying to kill them by giving plausible explanations as
| to why they can't have PWAs. Security this, blah blah blah.
| There's no reason they can't have PWAs work well in Safari other
| than they want you to port your app to the App Store and get
| locked into their native APIs.
|
| Google's problem is, well, they're Google. Meaning things are
| somewhat incoherent, docs are all over the place, they start new
| initiatives then abandon them half way, etc.
|
| Consumers are another problem. They have no understanding of PWAs
| and they go to the app store, don't find us, and then complain we
| don't have an app..
|
| The plan now is to use Google TWAs and port our PWA to Android.
|
| We're going to do the same thing to Apple after we do the Android
| release BUT I think there's a 50% chance that apple will just
| flat out block us.
|
| I think we might have a chance of getting around it if we use
| mobile gestures properly, use platform specific APIs like the
| camera, audio, and GPS that aren't on web and try to really
| integrate into the platform properly.
|
| For example, they have an API to detect dark mode now. IF that's
| on we're just going to magically enable our dark mode in our app.
| Razengan wrote:
| You blame Apple, Google and your consumers, instead of just
| making native apps. Why?
| vosper wrote:
| > There's no reason they can't have PWAs work well in Safari
| other than they want you to port your app to the App Store and
| get locked into their native APIs.
|
| Is it possible they also want you to port your app to the App
| Store to prevent an explosion of garbage and malware that could
| happen if PWAs really took off?
| jamiesonbecker wrote:
| > to prevent an explosion of garbage and malware that could
| happen if PWAs really took off?
|
| You mean, like the Internet. The App Store is a nice, safe
| walled garden, like AOL.
| franga2000 wrote:
| I seriously doubt that. It's a lot more difficult to do
| horrible things with PWAs than it is with native apps. Apple
| has a history of doing everything they can to keep people
| inside their walled garden and this is just another instance
| of that.
| b1tr0t wrote:
| Hi there, I'm the product manager for PWAs on the Chrome team.
|
| Very interested in hearing about pain points you've had
| building out PWAs, especially if there's features you were keen
| on that haven't been released. Easiest way to reach me is on
| Twitter: https://twitter.com/b1tr0t
|
| Fully agree with you that docs are all over the place. We've
| started to consolidate docs under web.dev, and the PWA section
| launched recently (https://web.dev/progressive-web-apps).
| Consolidating and adding docs is an active area of investment,
| and our goal is to create a well lit path for developers to
| succeed with PWAs.
| arendtio wrote:
| What did we expect? I mean how long is it now that Apple refuses
| to implement the Push API properly (which in turn is a basic
| requirement for many PWA use-cases). They clearly try to use
| their influence to defend their App Store revenue. And to make it
| look good, they do it in the name of privacy.
| KarlKemp wrote:
| I don't remember ever seeing this usage pattern in the wild? As
| far as I understand, it would always have resulted in data loss
| whenever users chose to clear browsing data. There also wouldn't
| have been any natural way for backups or synchronization.
|
| A browser plugin might be one way to achieve something like this.
| Personally, I really don't care about the data my feed reader
| has, so I wouldn't mind even public data storage backends, like
| gist. Or steganographically encoding my list of feeds and
| uploading it to porn sites :)
| endorphone wrote:
| Posts like these are much more convincing when they simply make a
| case for some allowance or some functionality, or point out the
| downsides. The moment they go into whataboutism or grander claims
| of conspiracies or ill intentions they fall apart.
|
| Rational readers click back and move on. You end up just
| preaching to the choir.
|
| This particular complaint is paradoxical because Apple birthed
| web apps, and has done more than anyone to make them a reality.
| Unfortunately they remain a _very_ rare beast -- extraordinarily
| rare -- and are dwarfed by the privacy concerns of people using
| iOS just to browse. So the team dealt with that. Seems a fairly
| obvious pros and cons analysis.
|
| Maybe they'll add an exception for installed to desktop webapps.
| Animats wrote:
| _What are private client-side PWAs anyway?_
|
| Good question. The definition of a "progressive web app" is
| vague. What they seem to mean is a web page which, once you visit
| it, is cached locally, and thereafter runs locally. The web page
| accesses various servers, not necessarily ones from the same
| domain as the web page. Persistent state, if any, is stored
| locally. The page gets its own icon on the home screen somehow,
| so it sort of looks like an "app".
|
| Apparently "progressive web apps" are supposed to have a browser
| service worker so they can get notifications pushed to them from
| somewhere, although it's not clear why that's essential. That
| would seem to depend on whether the function performed requires
| being notified of something happening elsewhere.
|
| Apple apparently dislikes this because they don't get to force
| people to use their store, with their big cut of the revenue.
|
| Is that about right?
|
| Does this only apply to pages read through Apple's browser, or
| does it impact Firefox, too?
| judah wrote:
| > Is that about right?
|
| Progressive Web Apps are strictly defined:
|
| 1. The app has an app manifest describing metadata about the
| web app, enabling it to be treated like an app (e.g. it can be
| installed)
|
| 2. The app has a service worker, enabling it to work offline
| like a native app.
|
| 3. It's served over HTTPS.
|
| Those are the 3 technical requirements of a PWA.
|
| There's also the philosophical direction of Progressive Web
| Apps: they're progressive, meaning they offer the app's
| essential experience no matter the device, but enhance
| progressively based on the device they're running on. That is,
| more capable devices let the app offer more functionality
| without blocking out users on lower-end devices.
| JumpCrisscross wrote:
| > _Apple apparently dislikes this because they don 't get to
| force people to use their store_
|
| This is part of the motivation. The other is advertisers using
| persistent local storage to track users [1].
|
| [1] https://clearcode.cc/blog/alternatives-to-cookie-tracking/
| oblio wrote:
| Do they block native apps that track users?
| frenchy wrote:
| Only if you fail to use the Apple advertising ID. Tracking
| users is fine as long as Apple holds the keys.
| soapdog wrote:
| > Does this only apply to pages read through Apple's browser,
| or does it impact Firefox, too?
|
| This applies to WebKit, but if that decision sticks Mozilla
| might follow. Who knows... I hope not. Also be aware that
| Firefox on iOS is WebKit.
| PunksATawnyFill wrote:
| What is a "PWA?"
|
| Would be good to include in the title.
| robenkleene wrote:
| I'm guessing that Apple will start hindering web apps because the
| new mouse support in iPadOS is going to be such a boon to web
| apps. Because of sandboxing, web apps are the only cross-platform
| apps that can run in their full versions on iPadOS. I wrote a
| quick summary of the situation[0].
|
| Therefore, since native apps are more of a platform
| differentiator than web apps, moving forward we can expect Apple
| to start systemically hindering web apps, especially on ones that
| are good on iPadOS, in order to boost native apps.
|
| (I'm not saying this necessarily the start of this, but I am
| saying I'm not surprised. This is exactly the type change,
| targeting the exact type of app I'd expect to be targeted.)
|
| [0]: https://blog.robenkleene.com/2020/03/20/ipadoss-new-mouse-
| su...
| saagarjha wrote:
| The people who work on making websites function better on iPad
| are literally a 20 second walk away from the people who work in
| Intelligent Tracking Prevention-do you really think that they'd
| seek to undermine each other in this way?
| LocalPCGuy wrote:
| Absolutely, do you have evidence they are talking and
| consulting with each other? Obviously lack of evidence isn't
| evidence either, but departments do things all the time that
| are at odds with each other in companies like Apple.
| cageface wrote:
| _moving forward we can expect Apple to start systemically
| hindering web apps_
|
| They have been doing this for quite some time now. Always
| ostensibly to protect users but always also conveniently
| putting webapps at a permanent disadvantage to native apps.
|
| For my part I'm not interested in being a user of a platform so
| hostile to the web that it disallows any third party browsers.
| tomp wrote:
| Technically it's disallowing third-party JITs / executable
| data. Which is a good thing all-in-all.
| saagarjha wrote:
| Eh, I'm not completely sold on that.
| madeofpalk wrote:
| Actually the guidelines specifically ban non-webkit
| rendering engines.
|
| > 2.5.6 Apps that browse the web must use the appropriate
| WebKit framework and WebKit Javascript.
| tyree731 wrote:
| At a minimum we can be thankful that Apple's rules force
| web developers to care about one additional browser.
| TheKarateKid wrote:
| > _Always ostensibly to protect users but always also
| conveniently putting webapps at a permanent disadvantage to
| native apps._
|
| This isn't always a bad thing though. For example, Safari has
| prohibited some obnoxious behavior that Chrome has allowed:
| Autoplaying videos, tab suspension, push notifications. These
| hog CPU and destroy battery life, worsening the user
| experience.
|
| Remember, making _everything_ a web app is Google 's agenda
| because _they_ benefit most from it.
| estreeper wrote:
| I would just point out there are very valid use cases for
| these things, i.e. push notifications are very useful to me
| (from certain apps). The problem is one of consent.
| dzhiurgis wrote:
| MacOS Safari autoplays YouTube videos with now way to
| disable...
| Gaelan wrote:
| Interesting. I can tell Safari to not autoplay videos on
| YouTube in its preferences, but that doesn't seem to do
| anything. Seems more like a bug on Safari's part and/or
| workaround on Google's part than anything deliberate.
| wildduck wrote:
| One can always rely on cordova/phonegap type of app with a
| C++ plugin to address this issue.
|
| Personally, not having web app storing large amount of data
| is a good thing.
| fpoling wrote:
| Apple disallows third-party web rendering engines. Google
| Chrome on iOS uses own networking stack.
|
| It is still a significant restriction, but it is rather
| understandable. Without it it could be just Blink everywhere
| at this point.
| lern_too_spel wrote:
| > Without it it could be just Blink everywhere at this
| point.
|
| In what reality-distortioned universe is that worse than
| having a crippled web?
| saagarjha wrote:
| Please don't call anything that's not Blink "a crippled
| web".
| jamiesonbecker wrote:
| I believe that OP is saying it would be preferable to
| have blink-everywhere than to have a deliberately-
| crippled Apple web browser with all other choices banned.
| cageface wrote:
| So it's not about what's best for the user but what's best
| for Apple? I wouldn't call that "understandable". All this
| is doing is contributing to webkit monoculture.
| Spivak wrote:
| There's some irony that Apple forcing the use of Safari
| on iOS is creating a monoculture when, were the
| restriction lifted, everyone would be using Chrome.
| cageface wrote:
| If so it would be because users chose it and it would
| also help keep Firefox in the game which important to the
| long term health of the web.
| zimpenfish wrote:
| > everyone would be using Chrome.
|
| I'd be amazed if there were more than a tiny fraction of
| iOS/iPadOS users (of which there are hundreds of
| millions) who weren't perfectly ok with Mobile Safari for
| their everyday usage.
|
| [I'm probably the "target market" for Chrome (backend,
| occasionally frontend developer) and there's no way I'd
| have it on my phone. I only suffer the GMail app because
| they've made IMAP usage of gmail unreliable.]
| kitsunesoba wrote:
| It doesn't matter what users choose, devs would badger
| users into using Chrome for their own convenience. It'd
| be the return of the "viewed best in" badges from the
| late 90s and early 00s.
| TheKarateKid wrote:
| Remember, making everything a web app is Google's agenda
| because they benefit most from it.
| ChrisMarshallNY wrote:
| As a native app developer, I can live with this.
| OzzyB wrote:
| As long as you start refering to the "i" in "iPhone" as
| _Intranet_ and not ~Internet~ then we 're cool.
| 72deluxe wrote:
| My iPod Classic has no intranet or internet.
|
| What does the "i" mean in that case???
| ChrisMarshallNY wrote:
| I have nothing against hybrid apps. In many use cases, they
| are the best approach, and I have often declined business,
| in recommending them to others, as opposed to what I can
| do.
|
| My post was not an attack on anyone or anything, and it was
| not being snarky. All I said was that I develop native
| apps, and that this policy does not affect me.
|
| I like developing native apps. I've been writing native
| Apple software for 34 years. It's not really difficult;
| just different. I have also been developing "Internet"
| software, of all kinds (full stack), since before the WWW.
| Using Apple stuff. It certainly can be done.
| Veen wrote:
| If this were true, how would you explain the recent
| improvements to Safari on the iPad that make it as capable as
| desktop Safari. Until last year Google Docs did not work in
| Safari on the iPad. Now it works very well indeed. The same is
| true of most web apps.
| diggan wrote:
| This particular move takes something that is possible in web
| applications today and makes it not possible in the future
| (offline capable frontend-only applications), making the gap
| between native applications and browser applications further,
| so developers who need to build apps that works offline on
| iPhone, will only be able to use Apples own technologies for
| doing so, in a non-cross-platform way. Which in general, is
| what Apple always been favoring.
|
| Google Docs doesn't really work offline, so it's not impacted
| by this change. Could also be a change of heart from Apple,
| since their stance on web applications have changed before.
| Veen wrote:
| It could also be exactly what they say it is: a way to
| prevent the abuse of local storage for tracking.
| diggan wrote:
| 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.
| smnthermes wrote:
| Arbitrary government rules are never the solution for
| issues.
| diggan wrote:
| Now I'm not a native English speaker, but seems
| "arbitrary" means "determined by chance, whim, or
| impulse, and not by necessity, reason, or principle".
| Introducing a law to protect peoples privacy would not be
| arbitrary, especially since most countries have a due
| process for introducing laws.
| cwzwarich wrote:
| > 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...
|
| Isn't the new policy for local storage being copied from
| an existing policy for cookies? How can they switch to
| cookies?
| Touche wrote:
| It's both.
|
| They could restrict these APIs to "installed" web apps
| via the web app manifest file, if they were to adopt
| that. Maybe they will in the future, but for now they've
| just made web apps far less powerful.
| robenkleene wrote:
| This is a great point with a simple explanation: How good
| Safari was on iPad was irrelevant before mouse support.
| Before mouse support, we had apps made with UIKit, which is a
| touch-first app framework, competing with web apps, which are
| keyboard-and-mouse first. So UIKit apps won, because UIKit
| apps are better for touch. With mouse support, that situation
| becomes exactly inverted: In UIKit apps, the keyboard and
| mouse are secondary, so web apps have the advantage in being
| keyboard-and-mouse first.
|
| So now that web apps have the advantage, at least when a
| keyboard and mouse are attached to the iPad, Apple is going
| to be seeking to tip the scales back in native apps favor.
| saagarjha wrote:
| > In UIKit apps, the keyboard and mouse are secondary
|
| Apple _just_ added new APIs to support these.
| Veen wrote:
| We're all speculating about Apple's motivation, but none of
| us really knows why Apple made its decision. Perhaps it's
| best to focus on the trade-offs--privacy vs. functionality
| --and not the speculative Kremlinology.
| robenkleene wrote:
| Respectfully, no. Learning software is a big investment
| in time and effort. Since I'm on Apple's platforms,
| because I think they're the best compromise for running
| the software I want to run, I am going to continue to
| speculate their reasoning to try to predict which
| software will be successful on their platforms in the
| future, because that's how I choose where to invest my
| time and effort.
|
| I respect you have some other motivations here, but I'm
| not doing this for fun. I'm doing this because it's
| important to how I spend my most important resources: my
| time and effort. So no, I'm not going to stop
| speculating, the mere idea is laughable. Like buying an
| individual stock while having no opinion of what
| direction the company might take in the future.
| Veen wrote:
| Of course you are free to speculate, but my point was
| that we lack evidence of Apple's motivations that would
| help us to make predictions of any value. All we can do
| is tell a plausible story, and without evidence your
| story is no more likely to be true than mine.
| brundolf wrote:
| Which is strange, because they're already under scrutiny for
| being anti-competitive WRT their app ecosystem. Having good
| support for web apps could've softened that case a little bit.
| madeofpalk wrote:
| > I'm guessing that Apple will start hindering web apps because
| the new mouse support in iPadOS is going to be such a boon to
| web apps.
|
| As a _web developer_ , I've never believed Apple has hindered
| web development on their platform, purposefully or not. They
| just don't spend their resources adding in WebBluetooth or
| whatever new API-of-the-day Google has decided to come up with.
|
| As I see it, their focus is on the _user_ , which is why
| they've been slow to adopt APIs that are privacy concerns, or
| drain battery, or have other negative implications.
| gear54rus wrote:
| > As I see it, their focus is on the user,
|
| Oh and let me guess, they know better than me that I don't
| need this or that.
|
| Let them suffocate inside their poisonous wall garden as the
| web gets richer and richer.
| untog wrote:
| That's a very rosy way of looking at it. iOS has had bugs
| with its "add to home screen" webapps that kicked around
| literally for _years_. If they were being "user first" they'd
| support it fully or not support it at all. Instead they
| implemented then neglected it.
| machello13 wrote:
| How many users even know or care about that feature?
| untog wrote:
| How is that relevant to the conversation? If it is so
| little-used as to be irrelevant then the user-first thing
| to do would be to remove the functionality but Apple
| haven't.
|
| I can speak from personal experience that users do use it
| when you include specific instructions on how to use it.
| And it's used in a number of corporate settings for
| installing webapps on an iPad.
| [deleted]
| dirkgently wrote:
| Once you take your head out of that iAss, you may see how
| defensive and idiotic your comment is.
| akmarinov wrote:
| To be fair, they've had bugs in iOS they've kicked around
| for years...
| fcarraldo wrote:
| What bugs exactly? Been using this feature for years and
| have never had issues with it.
| saagarjha wrote:
| Until a recent iOS release they had a number of
| undesirable features that made them a bit inconvenient to
| use: they used UIWebView (instead of the faster
| WKWebView), they "restarted" if you ever left them, and
| generally had a number of other quirks.
| jedieaston wrote:
| Probably because Apple giving a crap about web apps was
| depreciated with the release of iPhone OS 2.0 and the App
| Store over a decade ago. I'd bet few users even use the
| "add to home screen" button outside of corporate
| environments that want to add a shortcut to internal sites.
| dzhiurgis wrote:
| Facebook messenger is good use case for web app, but zuck
| want's to track you so you need to install app instead...
| madeofpalk wrote:
| All parts of Apple's platform has had bugs that have kicked
| around for literally _years_. Their native SDK is
| infamously under documented and has all sorts of bugs
| https://twitter.com/caseyliss/status/1171778706878160897
|
| The bugs in Apple's software, whether in web or native or
| in documentation are not part of some nefarious plot, its
| just a part of Apple's mismanagement and relatively minimal
| resources.
| MFLoon wrote:
| > relatively minimal resources
|
| Uh, they're the most well capitalized corporation in the
| world (or hovering in the top 3 plus or minus a few
| quarters). They _have_ the resources to make it work if
| they wanted. There are undoubtedly thousands of
| engineers, hundreds of managers, and at least a handful
| of execs, working for Apple, lurking in this HN thread
| today, not because they 're unaware of their ongoing
| sabotage of web standards on iOS, but because they're
| completely aware of it and want to take the temperature
| on how their latest kick to the shins of PWAs is going
| over.
| wubin wrote:
| The source clarifies that this only applies to websites run
| within the Safari browser.[1] PWAs added to the home screen
| aren't affected.
|
| _> As mentioned, the seven-day cap on script-writable storage is
| gated on "after seven days of Safari use without user
| interaction on the site." That is the case in Safari. 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._
|
| [1] https://webkit.org/blog/10218/full-third-party-cookie-
| blocki...
| iameli wrote:
| "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."
|
| But said timer... does nothing? Why does it exist?
| gridlockd wrote:
| I suppose it would still affect any sites you visit from
| within the PWA, for example through an iframe.
|
| Also, it's simpler to have a timer that effectively does
| nothing than having extra logic to suppress it.
| eyelidlessness wrote:
| Presumably because WebView is available to other applications
| besides Safari and pinned sites, and they want to offer the
| same privacy guarantees to users for WebViews in apps as for
| Safari. Adding an exception for pinned apps is unnecessary
| because it's impossible to meet the criteria for deletion.
| osrec wrote:
| That's a relief. We've built our business on our PWA, which
| also has an offline mode. It would be annoying if we had to
| adjust it for (yet another) Safari quirk.
| gridlockd wrote:
| > _" 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."_
|
| What exactly does that mean? So you use the app for seven
| (perhaps non-consecutive) days, and now all third parties that
| haven't been, uh, interacted with, get their data wiped - but
| not the the first party, because that _has_ been interacted
| with, by virtue of the PWA being launched in the first place?
|
| I guess that solves the problem?
| pcdoodle wrote:
| Thank you for the clarification.
| pier25 wrote:
| Ok but OTOH Apple is not helping PWAs by hiding the "Add to
| home screen" in submenus and not having an official API to show
| a banner like Chrome has on Android.
|
| Edit:
|
| Also what about desktop?
| untog wrote:
| 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 wrote:
| 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.
| emmelaich wrote:
| But .. if you don't use Safari for seven days, what
| happens?
| eyelidlessness wrote:
| 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.
| [deleted]
| untog wrote:
| Ah OK that makes sense. They should really copy and paste
| what you just said into their post!
| rhizome wrote:
| So this is a requirement that all webapps phone home,
| moreover that they have a home to phone?
| untog wrote:
| No, this is all internal to the browser, no requirement
| to send a remote request.
| [deleted]
| pier25 wrote:
| 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".
| PunksATawnyFill wrote:
| It's beyond confusing. It's meaningless, and even
| grammatically nonsensical.
| btown wrote:
| If there is, as they say, a dedicated counter on those home
| screen applications, what is the threshold? Will home page PWA
| apps not used often (say, for infrequent uses like travel) have
| first party data deleted after the icon isn't clicked for some
| time? This is highly unclear and confusing.
| eyelidlessness wrote:
| The deletion occurs if you use the app for seven days and
| don't visit the site. Pinned sites cannot meet those criteria
| and will not trigger deletion.
| finaliteration wrote:
| I'm a little confused by this and maybe I'm missing something.
| Wasn't localStorage always intended to be treated as a volatile
| storage mechanism for non-critical data and caching? The advice
| I've seen for several years says to avoid storing sensitive or
| critical data there.
|
| Can PWAs not switch to using IndexedDB which seems like it's more
| purpose-built for this use case?
|
| No snark intended. I'm legitimately curious what the situation is
| and where any blockers are.
| nicoburns wrote:
| > Can PWAs not switch to using IndexedDB which seems like it's
| more purpose-built for this use case?
|
| IndexedDB is also subject to the 7 day limit. Leaving no
| persistent storage for web apps at all.
| finaliteration wrote:
| Ah, I missed that in the original documentation and most of
| the discussion I've seen has been around localStorage. Thank
| you!
| capableweb wrote:
| It's a bit confusing because there are two similar terms
| being used to describe this. First is "local storage" which
| refers to any of the storage, as long as it's on the local
| device. Second (which you used) is "localStorage", which
| refers to specifically the window.localStorage API (which
| you are right about, has been described as a volatile
| short-term memory for apps).
| judah wrote:
| In the original post from Apple[0] announcing these measures,
| they've listed all script-writable locations are subject to
| cache clearing:
|
| - Indexed DB
|
| - LocalStorage
|
| - Media keys
|
| - SessionStorage
|
| - Service Worker registrations (I guess this means service
| worker caches)
|
| [0]: https://webkit.org/blog/10218/full-third-party-cookie-
| blocki...
| finaliteration wrote:
| Thank you for outlining that! I missed the impact on Indexed
| DB in my original read of the issue. It makes more sense,
| now.
| phkahler wrote:
| IMHO adding more local storage via browsers was a huge step in
| the wrong direction from the users point of view.
| andrewrothman wrote:
| I commented about this in a different thread about the same topic
| earlier today, but I'll post here as well.
|
| I can understand Apple's decision to do this, as there's a lot
| that can be improved about offline storage on the web:
|
| * asking for user permission (i've seen demos try to exhaust the
| users' storage, and trackers can use this to invade privacy) *
| async writes and reads
|
| However, making a change like this with no suitable alternative
| leaves PWA developers stuck in a hard place. I'm not sure what
| can be done in the short term here.
|
| There's a few web specs that address these issues. I'd love to
| see them come further along, and maybe improve things for
| developers and users in the long run. If anyone knows, is there
| anything that members of the community can do to support these
| efforts?
|
| https://chromestatus.com/feature/6428344899862528
|
| https://wicg.github.io/kv-storage/
|
| https://chromestatus.com/feature/5715811364765696
|
| https://storage.spec.whatwg.org/
| throaway9aaaapp wrote:
| Our company has started shaming iOS. We tell users that because
| of a commercial policy aiming to increase their revenue from
| their App Store, iPhones and Ipads "do not support the Web 2.0
| technology enabling powerful experiences for web sites and web
| applications, while Android and Windows devices have been
| supporting this technology since 201x". We briefly explain in one
| sentence that it would not be the best use of our resources to
| try to bypass Apple's technological decisions but that they
| should contact Apple for further information.
|
| We then link them to a $30-$50 Android device that they can buy
| on Amazon and use as a second device to use our services "if they
| are interested in a more powerful web experience". We provide a
| basic version to all users, but put a shamewall for advanced
| features. Best use of our time and resources.
|
| It is time to push back, stop making Apple's problems your
| problems. Educate people without ranting and offer them
| solutions, developers have the bad habit of trying to cover up
| this kind of non-sense and taking the blame while really Apple
| are the ones who should be ashamed. If people love your
| product/service getting a $30 phone to be power users and make
| their life easier and their experience richer will not be a big
| deal for them. It's all about educating them the right way.
| spzb wrote:
| Obviously I have no idea what your product is but if I got that
| message I'd just likely go to one of your competitors (assuming
| they exist). I wouldn't go and buy another device unless it was
| for an absolutely critical application.
| theNarrative24 wrote:
| It's a win win.
|
| OP doesn't need to spend excessive money on developing for a
| Evil company, and those who buy their products can go to a
| competitor with a more expensive product.
|
| Nearly everyone has at least one non apple product, so it
| seems like it would be a problem for a limited number of
| users.
|
| OP, you are doing God's work.
| shadowgovt wrote:
| > assuming they exist
|
| And that's the real nature of the market, isn't it? If enough
| third-parties aren't willing to play by Apple's rules, Apple
| will have to modify the rules.
|
| They're a stubborn company, but it's happened before. They've
| also been burned trying to own a standard when a common
| consensus exists they can't control before.
| freehunter wrote:
| Exactly. It sounds to me like websites that refuse to load in
| GDPR countries. Good, if you can't support me I don't need to
| support you.
|
| 90% of software engineering (or engineering in general) is
| finding solutions for difficult problems. Throwing up your
| hands and saying you refuse to support one of the most
| popular computing platforms is certainly a decision that any
| business is free to make, but then again as a consumer I'm
| free to make my own decisions as well.
| staplers wrote:
| Sounds extremely condescending and off-putting. I'd be annoyed
| if a company said this to me.
|
| There is a lot to love about Apple products outside of a few
| safari restrictions. They're not perfect but better than a lot
| of alternatives.
| jeffhuys wrote:
| > Our company has started shaming iOS
|
| Why isn't our product taking off?!
| Hackbraten wrote:
| Are you aware of the poor security a $30 phone has?
| jbeam wrote:
| I would have to REALLY love your service to want to carry
| around an extra device to use it.
| shadowgovt wrote:
| ... or find it really necessary. Banks, for example, have the
| clout to expect this kind of behavior. The built-up
| reputation and long-term partnerships a company and a bank
| build up can out-value all kinds of IT inconveniences.
| uglycoyote wrote:
| I don't know if you meant from the consumer perspective,
| but if my bank started telling me what kind of a phone or
| computer I needed to have to use their services I would
| definitely find another bank! I'm not sure if clout is the
| right word for what what banks have, it's more like a kind
| of lock-in because of having to sign a million pieces of
| paper to change banks, that makes people put up with a
| certain amount of IT inconvenience, coupled with the fact
| that usually the competition is equally inconvenient.
| shadowgovt wrote:
| You might, but there's a long history of bank websites
| only working in Internet Explorer, and it was only in
| recent years that this changed.
| oefrha wrote:
| 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.
| shadowgovt wrote:
| 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.
| jamil7 wrote:
| Which is included in the cost of opening an account with
| the bank, you're not told to go buy this device off
| Amazon.
| [deleted]
| SifJar wrote:
| In addition to what others have said, I think the effectiveness
| of this likely depends heavily on the target audience - to a
| non-technical user, this will probably come across as lazy.
| From their perspective, everything else works fine on Apple, so
| you must be complaining about nothing.
|
| Of course, if everyone did the same, people would start to
| realise the problem might be with Apple, but the chances of all
| (or most, or even many) big web services deciding to alienate
| such a large portion of their (potential) customers seem slim.
| shadowgovt wrote:
| It very much depends on the market.
|
| In the general case, almost all websites and web apps don't
| need offline storage at all.
|
| But the ones that do often need it for very business-
| enterprise reasons, and here Apple is taking a bit of a risk.
| I've watched companies hang onto old versions of Flash well
| past the sell-by date because for quite some time, it was the
| most practical platform to build a cross-platform
| videoconferencing client in. And once it's built, the
| opportunity cost to throw it away and switch to
| [OTHER_TECHNOLOGY_X] matters.
| jamil7 wrote:
| > If people love your product/service getting a $30 phone to be
| power users and make their life easier and their experience
| richer will not be a big deal for them.
|
| So you're suggesting shifting the development costs of you
| building a native / cross platform app directly to your
| customers? Does this work?
| untog wrote:
| What technologies does Safari not support that you need?
|
| That's a genuine question by the way. I've been frustrated by
| Apple's reluctance in the past but since they implemented
| Service Workers things have gotten better. I still really wish
| they had Web Push but I do understand at least conceptually why
| they'd be hesitant.
| tarkin2 wrote:
| Web recording api. Only works in safari under a flag - they
| won't release the feature to chrome/firefox.
| judah wrote:
| On one hand, I don't like this direction from Apple because it's
| meant to boost Apple's proprietary app store business -- which
| directly competes with the open web -- but masquerades as a
| privacy issue.
|
| On the other hand, this direction keeps web devs honest: local
| storage, service worker, cookies and other script-writable areas
| are meant to be temporary.
| fomojola wrote:
| I see nothing in any of the specs that implies local storage
| was intended to be temporary? You could argue cookies, maybe,
| but even that I'd dispute: it is a user-agent, I should be able
| to tell it "don't delete my stuff". I already have browser
| controls over my local storage: I can go into settings in every
| reasonable browser and flush that down the tubes.
| mr_toad wrote:
| It's _always_ been impossible to rely on local storage for long-
| term use.
|
| Users clear their caches. They swap browsers. They swap machines.
| They use their phone instead of their desktop. They use private
| mode, or sand boxing. They re-install their OS. They buy a new
| machine.
|
| Don't be lazy. Using local storage without a backup is not
| acceptable.
|
| And what kind of 'progressive' web app expects all the features
| in every client? Have we forgotten what progressive means?
|
| Don't be entitled. You are not more important than your users.
| lnanek2 wrote:
| Based on the blog, it sounds like he wants to downloaded RSS
| feeds to the user's device, and not store them on his server to
| speed up development (all those complaints about FAANG being
| able to develop at web scale and him not wanting to run a
| backend).
|
| Then, if the user clears cache or changes computers, they lose
| the stuff they were following and have to wait for new items,
| but it's not the end of the world. They might even expect it if
| you name/describe the app a certain way.
|
| E.g. if you download an app called "Podcast Downloader" that
| says it just downloads any new podcasts from feeds you follow
| for your later offline consumption on your current device - you
| might not expect a podcast on your phone to magically jump to
| your desktop without a re-download from the original site.
|
| Seems like it could be a valid trade off if it lets a front end
| only web dev publish apps he couldn't publish otherwise because
| he can't/won't do backend. Storing user media on the backend is
| not cheap. The company I'm at has spent months of developer
| time moving over from Google to Amazon, for example, just for
| infra cost improvements that come from serving terrabytes of
| data off one instead of the other.
| sandstrom wrote:
| How would static "single-page" apps (HTML/JS/CSS) that store
| session tokens in localStorage avoid 7-day auto-logout?
|
| Perhaps using something like this:
| https://developer.mozilla.org/en-US/docs/Web/API/Credential_...
|
| Anyone know of other Web APIs that could be used?
| aurbano wrote:
| Cookies are a lot safer for authentication than localStorage.
| The only problem with this change is persisting data for
| offline use, not authenticating the user.
| jdxcode wrote:
| might have to use cookies
| saagarjha wrote:
| Related discussion from earlier today:
| https://news.ycombinator.com/item?id=22683535
|
| WebKit blog post from yesterday:
| https://news.ycombinator.com/item?id=22677605
| dang wrote:
| I think we'll merge today's threads. Any reason not to? Edit:
| merged.
| saagarjha wrote:
| I can't think of any, they're all the same topic as far as I
| can see. The WebKit blog post has a little bit about third-
| party cookies being blocked but everyone quickly moved
| discussion to the script-writable storage cap.
| restoreddev wrote:
| I guess this means Safari won't support persistent storage
| anytime soon. I was looking forward to it becoming a standard
| API. https://developer.mozilla.org/en-
| US/docs/Web/API/StorageMana...
| OJFord wrote:
| Based on the table there it seems Edge had but removed support
| anyway?
| heynk wrote:
| I'm an engineer at a platform that makes it easier to build
| privacy-friendly apps. This means that all apps on our platform
| have app-specific private keys stored on the client side (in
| localStorage), and they never touch a server.
|
| With this change, you're essentially "logged out" after 7 days of
| inactivity.
|
| This is pretty a bad user experience. I honestly am not sure how
| to mitigate this. MacOS Safari might not be a massive market, but
| iOS Safari is.
|
| Any thoughts about how we should address this change?
| oefrha wrote:
| Being logged out after 7 days of inactivity could be a little
| bit annoying but I can live with that, as long as I can log in
| again.
|
| I could be misinterpreting your comment but are you saying your
| keys are simply destroyed upon this "log out"? Then I'm not
| really sure why your platform was considered working in the
| first place, if it's tied to a specific browser of a specific
| device and won't survive a clearing of storage which any user
| can do at any time for a variety of reasons?
| pier25 wrote:
| What if you don't have connectivity when localstorage is
| deleted and can't log in?
|
| Eg: in a classroom.
| oefrha wrote:
| What if someone accidentally erases everything because
| that's what they're told when something doesn't work right?
| Answer: it's volatile storage in the first place, and a
| tiny one at that. Heck some browsers can be configured to
| erase everything when closed (when operating in non-
| incognito/private mode).
| pier25 wrote:
| > _What if someone accidentally erases everything because
| that's what they're told when something doesn't work
| right?_
|
| The difference is that one situation is controlled by the
| user and the other is not.
| heynk wrote:
| No, it's not tied to a specific device. You can of course log
| back in, and keys are not "destroyed". We ask users to store
| a 12-word seed phrase, from which all other keys are derived
| from.
| oefrha wrote:
| Okay, I personally wouldn't hate logging in to a seldom
| used app once a week too much.
| true_religion wrote:
| From the article...
|
| > Heck, they could even go further and ban apps from corporations
| like Facebook, Inc., and Alphabet, Inc., that have violating your
| privacy as the core tenet of their business model.
|
| If Apple were to ban the Gmail app (and obviously block web
| access via iOS too because that would be a loophole otherwise), I
| would throw away my iPhone, swear off business with Apple, and
| search dearly for a way to sue them.
|
| I don't love the walled garden iOS represents, I merely live with
| it in exchange for great hardware and UX. If the bargain changes
| to be more restrictive, I would turn against it in a heartbeat.
|
| Thinking about that, is no surprise Apple is striking out early
| to make web apps useless. If they wait too long, they will become
| entrenched, and people will feel like they have lost something if
| access is restricted. Apple really wants to jealously protect its
| control, and more importantly ability to take 30% tax of every
| transaction that they can perceive.
| dang wrote:
| Thread about the webkit.org post from yesterday:
| https://news.ycombinator.com/item?id=22677605
| sneak wrote:
| A bit offtopic, but the following is my basis for interpreting
| privacy-related claims from Apple.
|
| I noticed a text editor I bought from the Mac App Store, iA
| Writer, includes silent spyware that transmits your activity back
| to the developer without notice or consent (thank you, Little
| Snitch). Apparently, I "consented" to this in the Mac App Store
| ToS (right).
|
| When I left a negative review on the app, their response was "we
| aren't doing anything not permitted by Apple in the App Store".
|
| I don't use App Store apps any longer, and I take most of what
| Apple says about privacy with a huge grain of salt.
|
| PS: OSX phones home to Apple in about a dozen different ways even
| with iCloud _entirely_ disabled and _all_ reporting
| /telemetry/feedback options turned off during the OOBE/setup. Try
| doing booting a fresh install of macOS with Little Snitch, but
| _disable the Apple /OS exemption_ in Little Snitch's rules. I was
| _astounded_. _Dozens_ of things.
|
| I wonder if there's any major, widespread GUI OS in a default
| configuration that does not transmit to your ISP and third
| parties (including government snoops) when you open a local text
| file to write. I block all of these requests; most do not.
|
| I am reminded of Winston Smith's paper journal.
| aazaa wrote:
| The article doesn't exactly cut to the chase. Here it is:
|
| > "...But deleting all local storage (including Indexed DB, etc.)
| after 7 days..."
|
| From the Apple announcement:
|
| > Now ITP [Intelligent Tracking Prevention] 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-blocki...
| matlin wrote:
| What we really need is a way for users to store their own data
| that has the simplicity of local storage but the convenience of
| storing data in the cloud.
|
| It does seem that Apple intends to cripple web technologies in
| order to move developers to their native platform but this will
| likely do more damage to privacy than anything. All of the
| alternatives to local storage for simple mobile apps typically
| involve moving data to a third parties like Firebase, AWS, etc.
|
| Simple apps that didn't need a server and could just keep data or
| user-preferences locally would now need to either create their
| own data service or pay for a BaaS which means moving your data
| out of your control.
|
| This behavior leads to companies like Under Armour to house data
| they shouldn't have and puts everyone (150M people) at risk.[0]
|
| [0] https://www.wired.com/story/under-armour-myfitnesspal-
| hack-p...
| [deleted]
| booleanbetrayal wrote:
| I can't seem to find whether or not these policies and storage
| caps are implemented in a WkWebView context. Any idea?
| judge2020 wrote:
| Is there any evidence that local storage is being used as a
| pseudo-cookie way of tracking users? If so, keeping local storage
| saved while regular cookies are being deleted would defeat the
| purpose of deleting cookies for anti-tracking reasons.
| majormajor wrote:
| I was in the adtech world about ten years ago, and localstorage
| was definitely one of the things used for "supercookie" stuff
| (along with Flash, etags, and probably other stuff I'm
| forgetting).
| hosteur wrote:
| This is exactly what it is about. I welcome the move from
| Apple. Web devs can store state server side. They cry because
| tracking will be harder now.
| soapdog wrote:
| I'm the OP and I'm crying because I'm working on apps that
| don't have backend so that your data is yours and never leave
| your computer. This is now impossible for WebKit users.
| vbezhenar wrote:
| So you have to track Apple users now if you would implement
| backend storage. How ironic.
| chickenpotpie wrote:
| Exactly. Now I'm working on PWA that stores address data
| locally and now I have to have a backend db just for
| Apple users.
| JumpCrisscross wrote:
| > _Is there any evidence that local storage is being used as a
| pseudo-cookie way of tracking users?_
|
| Yes [1].
|
| [1] https://clearcode.cc/blog/alternatives-to-cookie-tracking/
| jrs95 wrote:
| Given that PWAs don't work particularly well with iOS anyways
| even if you have a PWA you're probably better off deploying it to
| the App Store via Cordova and prompting users to install it from
| there.
| bradgessler wrote:
| Do any lawyers out there know if Apple's sabotage of PWA's by
| their inaction or "features" like this could be considered anti-
| competitive behavior for an anti-trust lawsuit?
| yaktubi wrote:
| Not a lawyer but probably not. There's many ways to make an App
| for their platforms. Just because people want to use web
| technologies is an implementors decision.
| osrec wrote:
| My comment from a similar article:
|
| Rather than wiping local storage/indexed DB data after 7 days,
| could you not just make it an opt in thing, like the camera or
| mic? For example, ask users "Allow myapp.com to store app related
| data on your computer?". If they allow it, then give access to
| local storage APIs, otherwise don't. That way users can still
| have fully local PWAs if they wish.
|
| As an ardent PWA developer, this change annoys me immensely.
| alkonaut wrote:
| Did PWA's take off? What are some famous/big PWA's now? I can't
| remember ever "installing" anything in a browser as an app, or
| even being asked if I wanted to do it. Am I misunderstanding what
| they are?
| Macha wrote:
| devdocs.io is the most successful example I'm aware of. I've
| never "installed" it as an app, as I don't use a browser that
| supports that (basically Edge, Safari or Android Chrome), but
| I've certainly relied on its ability to load without an
| internet connection for train/plane journeys.
| judah wrote:
| Microsoft will be releasing PWA versions of the Office suite.
|
| Twitter, Instagram, Starbucks, Pinterest and more have PWAs as
| well.
| tsimionescu wrote:
| Given that the OneNote web and Windows 10 apps don't
| implement Find&Replace (just Find), 5-10 years after their
| first release, I wouldn't hold my breath for usable Office
| PWAs.
|
| Edit: the official help page on how to do Find&Replace reads
| like a joke until you realize it is very real:
|
| https://support.microsoft.com/en-us/office/find-and-
| replace-...
| theturtletalks wrote:
| https://appsco.pe/ has popular PWAs. They don't need to be
| installed, they just look and work like an app on the browser.
| lucasmontano wrote:
| they really "look" like an app
| arendtio wrote:
| The look depends on how much effort the developer invests.
| If you take Bootstrap, the resulting PWA looks like a
| website. If you take Framework7 the resulting PWA looks
| more like a native App (including animations and the like).
| shawnz wrote:
| The key is the 'P': Progressive. A PWA is just a web app, but
| one that takes advantage of features you'd typically see in a
| locally installed application like local storage,
| notifications, etc. This might mean it has metadata to make it
| "installable" in browsers that support that, but I wouldn't say
| that's a requirement to be considered a PWA.
| soapdog wrote:
| I'm the OP, I use a lot of PWAs. My main machine is a Surface
| Pro X and I don't have native apps (as in native aarch64
| binaries) for many of the things I'd like to use. So, I'm using
| PWAs for Instagram, Twitter, Kindle, Pinafore (mastodon
| client), Spotify, and some of my own.
|
| I was developing a feed reader that was supposed to be a
| client-side-only PWA but that's tricky.
| xingyzt wrote:
| Do you know a PWA for Kindle? Their browser-based reader
| hasn't been updated for quite a while.
| soapdog wrote:
| Their Kindle Cloud Reader is better than the native windows
| app IMO. I don't know when it was last updated, I first
| used it this year.
| andrewrothman wrote:
| Off topic, but how is this experience using the Surface Pro X
| as a PWA machine? Does Windows / PWAs work well in tablet
| form? I was thinking of switching to a similar setup and
| using it essentially as you describe. Seems like it could be
| a really lightweight and simple computing environment similar
| to Chromebooks but still allows you to run traditional
| Windows apps as well if you need.
| soapdog wrote:
| I really like it but I wish Microsoft would support FOSS
| developers better and provide more support and incentive
| for them to port more developer tools. There are almost no
| native aarch64 programming languages for Windows 10. If you
| keep yourself inside WSL then you're good to go because
| Linux under aarch64 is quite complete. On the windows side
| of things you'll probably running a lot of 32bits x86 apps.
|
| Which is one of the reasons I like PWAs, they are ISA
| independent and are working pretty well here. Unfortunately
| Firefox doesn't support an add to homescreen feature on the
| desktop, so I used Edge to do it for the apps I want to
| have a nice icon for (such as spotify).
|
| If you're going to use it much like a chromebook then it
| might be a tad too expensive to be justifiable. I don't
| regret buying mine at all, I really like it, but I'm sure
| they'll release cheaper ARM64 Surfaces soon, I'm betting on
| a Surface Go with ARM64 at some point.
| alkonaut wrote:
| What is spotify pwa offering that is an improvement over
| their regular web app? Is it offline streaming (downloaded
| playlists)?
| soapdog wrote:
| Their regular web app is a pwa... thats the beauty of it.
| PWAs are not different offer, they are just enhancement on
| top of web apps. Good PWAs are invisible.
| koonsolo wrote:
| Twitter client is a PWA.
| alkonaut wrote:
| Ok I think I'll have to rephrase the question: are there many
| widely used PWAs that actually go one step further than being
| a web app using a few of these APIs (spotify, twitter), and
| actually try to "mimic" desktop apps more (installation,
| icons, fully offline etc)?
| seanabrahams wrote:
| PWAs haven't taken off because Apple won't implement full Push
| API support in Safari thus forcing you to go through the App
| Store if your web site or application needs push notifications.
| The App Store then complains if you try to publish an app that
| just wraps your web site so that you can have push
| notifications. It's... infuriating.
| asadlionpk wrote:
| Seeing all the "enable notifications" popups on every site I
| visit, I am happy that Apple doesn't allow this for websites.
| seanabrahams wrote:
| Sites could easily only prompt this after you've added them
| to the home screen. Browsers could, do?, also allow users
| to set a default of deny all notification requests.
|
| The problem is that developers have to spend a significant
| amount of time and money to get on iPhones because of
| Apple's policy here. If browsers and devices fully
| supported PWAs developers could "write once, run
| everywhere". Instead we have to build separate apps and
| deal with separate release processes. It's a huge
| productivity cost.
| p1necone wrote:
| https://www.ghacks.net/2016/02/19/disable-show-
| notifications...
|
| https://support.mozilla.org/en-US/questions/1208251
| seanabrahams wrote:
| Further, if Apple were truly concerned with the quality of
| the apps in their store they would free developers from
| having to submit apps just to support push notifications.
| Less time reviewing and rejecting apps, less "low quality"
| apps in the store, happier developers, happier users.
| pgt wrote:
| The only long-term solution I can think of is to build a
| competing hardware company, and that's really hard. But I'm
| willing to do it.
| StephenCanis wrote:
| PWAs are also useful where you want visitors to be able to
| access a portion of a website while offline. I run a site that
| hosts audio tours[1] for museums and walking tours. I use PWAs
| to allow visitors to quickly download the tour onto their phone
| in case they don't have a data plan or a portion of the tour
| will not have cell service.
|
| Apple definitely makes it difficult to use them effectively.
| For example you need to use Safari on iOS in order to download
| the PWA - it won't work if you're on chrome or another third
| party browser.
|
| [1]https://www.youraudiotour.com
| arendtio wrote:
| How should PWA take off, when Apple with a high mobile market
| share refuses to implement basic APIs like the Push API and
| other browsers can't run their own engine on iOS? It is
| abusive, but who cares.
| untog wrote:
| There's a chicken/egg issue here. Apple's support for
| progressive web apps has been subpar, so it's difficult to
| justify the extra effort in making a PWA when a major platform
| doesn't fully support it. Which, in turn, means people turn
| around and say "why should Apple support PWAs? No-one uses
| them!"
| woodson wrote:
| Twitter's web client is a PWA
| jagged-chisel wrote:
| I'm confused, or seeing confusion, over some things in the
| comments here. "We don't use Safari in our app..." We're talking
| web apps: you know, web sites with functionality. You don't
| exactly have control over which browser your users use. And in
| iOS, everyone is using 'Safari' even if it's Firefox or Chrome
| wrapped around the rendering control. This means you have to
| assume that the policy affects any visitor from any web browser
| on iOS. Technically, the other browser vendors can siphon the
| data into other storage to their users' benefit, but I don't know
| how likely they are to do that, nor whether Apple would approve
| them with such changes.
|
| Do you mean that you deploy a 'native' app that's really just a
| wrapper around a web view that would also be just Safari? Same
| policy applies, but now, you have the option, in native code, to
| siphon off data and put it into Real Storage.
___________________________________________________________________
(page generated 2020-03-25 23:00 UTC)