34 ms·

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

• deleted 7y ago
  [deleted]
• MaxBarraclough 7y ago
  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 7y ago
    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 7y ago
      Good points. I've edited my comment.
    • lonelappde 7y ago
      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 7y ago
        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 7y ago
    > 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 7y ago
      > 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.
      • chrisfinazzo 7y ago
        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 7y ago
    > 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 7y ago
  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).
  • m-p-3 7y ago
    > 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 7y ago
      No way that's happening on iOS as long as Apple takes 30% off the top
      • scarface74 7y ago
        Yes because think of all the money Apple gets from taking 30% all of the free apps that would be free web apps....
        • vbezhenar 7y ago
          There are very few free apps. Most of apps are paid with ads or external subscription. And Apple wants cut there as well.
          • scarface74 7y ago
            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 7y ago
• bg0 7y ago
  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.
  • yohannparis 7y ago
    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 7y ago
      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 7y ago
        If you don't use Safari you can patch webkit to change the policy, right? Change 7 to 10000000
        • tssva 7y ago
          Apple only allows apps to use their webkit implementation.
          • tomnipotent 7y ago
            Even for other browsers. Chrome, Edge, Opera etc. on iOS all use webkit under the hood.
        • chrisfinazzo 7y ago
• vanderZwan 7y ago
  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 7y ago
    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 7y ago
      There's no balance. You just let the user set any permission and make the prompts unobtrusive.
      • brazzy 7y ago
        There is no such thing as an "unobtrusive" prompt.
        • callmeal 7y ago
          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 7y ago
          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 7y ago
          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.
• jwr 7y ago
  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/ 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.
  • k__ 7y ago
    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.
    • kreetx 7y ago
      I see two problems: - apps with client-side-only data, i.e PWAs served from static sites - delta sync, although useful, is little help when what the dev wanted was a fast start
  • diegoperini 7y ago
    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.
  • gok 7y ago
    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.
• jimpick 7y ago
  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 https://github.com/jimpick/dat-shopping-list-tokyo
• fossTheWay 7y ago
  >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 7y ago
    > 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 7y ago
      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...
      • lotsofpulp 7y ago
        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”.
      • anon102010 7y ago
• alexcroox 7y ago
  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 https://twitter.com/alexcroox/status/1242559843354972161
  • dangoor 7y ago
    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.
• oefrha 7y ago
  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 7y ago
  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)
• flixic 7y ago
  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.
  • scarface74 7y ago
    Good luck with telling people not to use Safari (or more accurately WebKit) on iOS....
    • EGreg 7y ago
      You’re right. Tell people not to use iOS https://www.forbes.com/sites/gordonkelly/2020/03/14/apple-ios-13-iphone-cellular-data-problem-iphone-11-pro-max-u-iphone-xs-max-xr-update/amp/ https://www.forbes.com/sites/gordonkelly/2020/03/14/apple-io... You Apple users will put up with anything! (disclaimer: iOS user)
      • megous 7y ago
        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 7y ago
        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.
    • hesarenu 7y ago
      Nothing to tell. They don't have a choice.
  • realusername 7y ago
    As a web developer, I spend as much time to fix stuff for Safari as for IE11, I consider them on a similar level.
• donohoe 7y ago
  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).
  • diggan 7y ago
    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.
  • JustSomeNobody 7y ago
    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.
• meesterdude 7y ago
  webkit is open source - can't this be changed (be it by fork, or a commit proposal?)
  • matkalaukku 7y ago
    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 7y ago
    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?
  • The_rationalist 7y ago
    The PlayStation(s) browser is using webkit BTW (they are a decade late to switching to chromium..)
• starbugs 7y ago
  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.
  • IvanK_net 7y ago
    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 7y ago
      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_.
      • silon42 7y ago
        I'd love for browsers to have an opt-in mechanism to preserve that data (also snapshot/restore/import/export it).
        • starbugs 7y ago
          I bet there's tickets in both Google's and Apple's bug trackers from 2012 asking for that.
          • silon42 7y ago
            There should also be an reliable upgrade mechanism, so the app alway upgrades successfully and completely, no intermediate states where a network or other error would prevent offline functionality from working.
• IvanK_net 7y ago
  It is related only to WebKit (Safari). So I think people will just switch to other browsers.
  • diggan 7y ago
    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 7y ago
      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 7y ago
        You can install other browser frontends on iOS. People just don't know that the backend is still Safari.
• things 7y ago
  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.
• simion314 7y ago
  Will this affect all browsers that in iOS are forced to use same engine?
• robenkleene 7y ago
  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-support-will-benefit-web-apps/ https://blog.robenkleene.com/2020/03/20/ipadoss-new-mouse-su...
  • cageface 7y ago
    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.
    • fpoling 7y ago
      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 7y ago
        > 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 7y ago
          Please don't call anything that's not Blink "a crippled web".
• phkahler 7y ago
  IMHO adding more local storage via browsers was a huge step in the wrong direction from the users point of view.
• heynk 7y ago
  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 7y ago
    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?
    • heynk 7y ago
      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 7y ago
        Okay, I personally wouldn’t hate logging in to a seldom used app once a week too much.
    • pier25 7y ago
      What if you don't have connectivity when localstorage is deleted and can't log in? Eg: in a classroom.
      • oefrha 7y ago
        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).
• true_religion 7y ago
  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.
• aazaa 7y ago
  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-blocking-and-more/ https://webkit.org/blog/10218/full-third-party-cookie-blocki...
• booleanbetrayal 7y ago
  I can't seem to find whether or not these policies and storage caps are implemented in a WkWebView context. Any idea?
• jagged-chisel 7y ago
  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.
• themihai 7y ago
  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-progressive-web-apps/3602 https://discourse.wicg.io/t/proposal-full-network-access-in-...
  • pier25 7y ago
    Read the article, it's not only about offline PWAs. All local storage is deleted after 7 days.
    • themihai 7y ago
      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.
      • pier25 7y ago
        > Why would a website need offline data after 7 days? JWT for example.
      • dylan-m 7y ago
        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.
• mfer 7y ago
  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.
• diminish 7y ago
  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.
• est31 7y ago
  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.
• z3t4 7y ago
  Apps added to the shelf should keep their data
• deleted 7y ago
  [deleted]
• dennisy 7y ago
  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 7y ago
    Exactly this. Most "non-custodial" web wallets will die as a result of this change (some may even lose money/assets). Very unfortunate Apple!
• endorphone 7y ago
  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.
• throaway9aaaapp 7y ago
  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.
  • untog 7y ago
    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 7y ago
      Web recording api. Only works in safari under a flag - they won't release the feature to chrome/firefox.
  • spzb 7y ago
    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.
• sandstrom 7y ago
  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_Management_API https://developer.mozilla.org/en-US/docs/Web/API/Credential_... Anyone know of other Web APIs that could be used?
  • jdxcode 7y ago
    might have to use cookies
  • aurbano 7y ago
    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.
• tarkin2 7y ago
  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.
• blauditore 7y ago
  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?
• garganzol 7y ago
  Pretty much an expected move from Apple in its current state, shape and form. Security is such a sweet excuse for a tyranny.
• Abishek_Muthian 7y ago
  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.
  • lcfcjs2 7y ago
    Google is bad, and facebook is worst.
  • Arnt 7y ago
    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 https://en.wikipedia.org/wiki/No_true_Scotsman before arguing.
    • testtesttest 7y ago
      Open source is not the same as open. You can't run Firefox on an iPhone.
      • tekstar 7y ago
        Sure you can https://apps.apple.com/ca/app/firefox-private-safe-browser/id989804926 https://apps.apple.com/ca/app/firefox-private-safe-browser/i...
• diegoperini 7y ago
  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.
  • donatj 7y ago
    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.
    • joeblau 7y ago
      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.
• floatingatoll 7y ago
  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/4db42c1571d821572ea91abe10aedf942b774562 https://github.com/WebKit/webkit/commit/4db42c1571d821572ea9... The cookie filtering logic specifically is located here: https://github.com/WebKit/webkit/search?q=filtercookies https://github.com/WebKit/webkit/search?q=filtercookies The file:/// handler is implemented here: https://github.com/WebKit/webkit/blob/master/Source/WebCore/fileapi/File.cpp https://github.com/WebKit/webkit/blob/master/Source/WebCore/... (I don't have anything to do with Apple or WebKit.)
  • DiabloD3 7y ago
    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).
• talkingtab 7y ago
  A previous HN discussion about PWA's replacing native apps: https://news.ycombinator.com/item?id=22554745 https://news.ycombinator.com/item?id=22554745
• coffeefirst 7y ago
  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.
• sneak 7y ago
  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.
• thosakwe 7y ago
  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 7y ago
    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?
  • thosakwe 7y ago
    Original article was here, in case my comment makes no sense now: https://news.ycombinator.com/item?id=22683535 https://news.ycombinator.com/item?id=22683535 I was confused as to why the page in question had changed, but I realized it was moved.
• gfodor 7y ago
  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.
• pier25 7y ago
  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.
• matlin 7y ago
  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-password-hashing/ https://www.wired.com/story/under-armour-myfitnesspal-hack-p...
  • deleted 7y ago
    [deleted]
• progx 7y ago
  Then data will stored online on servers, i cant see how this is better for privacy.
• ocdtrekkie 7y ago
  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 7y ago
  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.
• pwinnski 7y ago
  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.
• davweb 7y ago
  I think the original post is oversimplifying the new behaviour a little. If you look at the other blog post on ITP 2.3 [1] it says: > ITP 2.3 caps the lifetime of all script-writeable website data after a navigation with link decoration from a classified domain. i.e. the 7 day timeout for local storage only kicks in if you've been redirected from a domain that ITP has classified as one that tracks users. So, for example, web apps that users navigate to directly will be unaffected. [1]: https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/ https://webkit.org/blog/9521/intelligent-tracking-prevention...
  • kevin_thibedeau 7y ago
    When will Google Analytics and Google Tag Manager get onto this list of trackers? Lots of web apps are using them.
    • t0astbread 7y ago
      As far as I understood this is not a "list of trackers" per se but a "list of websites that track you when you navigate to another website from them" and people don't navigate away from the Google Tag Manager or Google Analytics domains because they don't serve content with links.
      • snazz 7y ago
        So this would apply to t.co links from Twitter, for instance?
        • t0astbread 7y ago
          I don't know if t.co is such a classified domain but if so, if the link contains query parameters or a fragment part, then yes. I'm also not sure if "navigation" means through user action or if redirects count, although for the purpose of tracking prevention I don't see how the latter should not also count. So, if all of this is true the way I understood it now, the restrictions could apply to when someone reaches your site via social media.
• Aissen 7y ago
  There are still people who believe Apple cares about the web platform, 12 years after they forbade browser competition on iOS ?
• arkanciscan 7y ago
  People who use WebKit deserve it
• pier25 7y ago
  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.
• shireboy 7y ago
  Does this affect Cordova apps? They use WebKit and may store stuff like api tokens in local storage
• dang 7y ago
  Thread about the webkit.org post from yesterday: https://news.ycombinator.com/item?id=22677605 https://news.ycombinator.com/item?id=22677605
• jwiley 7y ago
  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.
• andrewrothman 7y ago
  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-2-3/ 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://chromestatus.com/feature/6428344899862528 https://wicg.github.io/kv-storage/ https://wicg.github.io/kv-storage/ https://chromestatus.com/feature/5715811364765696 https://chromestatus.com/feature/5715811364765696 https://storage.spec.whatwg.org/ https://storage.spec.whatwg.org/
• osrec 7y ago
  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.
• finaliteration 7y ago
  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 7y ago
    > 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 7y ago
      Ah, I missed that in the original documentation and most of the discussion I've seen has been around localStorage. Thank you!
      • capableweb 7y ago
        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 7y ago
    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-blocking-and-more/ https://webkit.org/blog/10218/full-third-party-cookie-blocki...
• judge2020 7y ago
  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 7y ago
    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 7y ago
    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 7y ago
      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 7y ago
        So you have to track Apple users now if you would implement backend storage. How ironic.
        • chickenpotpie 7y ago
          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.
      • dordoka 7y ago
        Sorry if I sound rude, but my conclusion from your article is that the problem here is you don't want to assume the costs and resources needed to build a backend and blame Apple. Please read the HTML/Web Storage standard [0] and try to find where Apple is not honouring it. Even before this move by Apple, you should already had to consider localStorage to be subjected to being wiped by actors not in your control. On top of that, localStorage privacy concerns were also in the standard. See section 11.4.1 [1]. Nevertheless, I reckon Webkit should expose the option to the user. I feel your pain, I really do, but I can't see how Apple made PWAs impossible. [0] https://html.spec.whatwg.org/multipage/webstorage.html#webstorage https://html.spec.whatwg.org/multipage/webstorage.html#webst... [1] https://html.spec.whatwg.org/multipage/webstorage.html#privacy https://html.spec.whatwg.org/multipage/webstorage.html#priva...
• marta_morena_23 7y ago
  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" ;).
• rconti 7y ago
  > 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-a-progressive-web-app-56130600a093 https://medium.com/@amberleyjohanna/seriously-though-what-is...
  • soapdog 7y ago
    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 7y ago
      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 7y ago
        I going to make sure in the future that I don't fall into this behavior again. :-)
      • soapdog 7y ago
• nicoburns 7y ago
  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.
  • JumpCrisscross 7y ago
    > they had much better privacy / security policies Why is a PWA better from a privacy or security perspective than a native app?
    • judah 7y ago
      Security: it runs in the browser's sandbox. Native apps by contrast generally have (or can request) full access to your system.
      • JumpCrisscross 7y ago
        > 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 7y ago
        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 7y ago
        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.
      • threeseed 7y ago
        As others have mentioned this is simply not true on MacOS/iOS. Also would add that Apple vets native apps.
• wolco 7y ago
  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 7y ago
    It is not fine if you're creating apps that don't have a backend.
    • finaliteration 7y ago
      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)?
      • soapdog 7y ago
        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 7y ago
        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.
• pat2man 7y ago
  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
  • soapdog 7y ago
    Even web apps that you add to your home screen are subjected to this.
    • redindian75 7y ago
      "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-blocking-and-more/ 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.
      • KarlKemp 7y ago
        Of not, this also contradicts the article‘s scenario of going on vacation. Only days with some browser use are counted.
      • seanwilson 7y ago
        > 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?
• andy_ppp 7y ago
  Am I right in saying this prevents any embedded widgets that need to show a logged in version, i.e. comments or whatever...
• sidhanthp 7y ago
  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-blocking-and-more/ 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 7y ago
    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 7y ago
      I asked about the dark patterns above and got answers confirming it https://news.ycombinator.com/item?id=22687214 https://news.ycombinator.com/item?id=22687214
      • duxup 7y ago
        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 7y ago
  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 7y ago
    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 7y ago
      > 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.
    • 7y ago
• chrisshroba 7y ago
  Does this also mean you'll have to re-login to websites every 7 days? (Sorry, not very familiar with web tech!)
  • icebraining 7y ago
    No, you'll have to re-login only if you haven't been to the site in the last 7 days.
  • deleted 7y ago
    [deleted]
• thehappypm 7y ago
  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 7y ago
    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.
    • thehappypm 7y ago
      Rightfully so. We won't have a cookieless world if the entire tracking industry basically just switches to LocalStorage when cookies finally die. Enough whack-a-mole.
  • deedubaya 7y ago
    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.
• mattl 7y ago
  > 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 7y ago
    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 7y ago
      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]
• sebringj 7y ago
  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 7y ago
    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 7y ago
      Offline iPad kiosks
• Jach 7y ago
  Workaround: encode your app's state into window.location.hash
  • withinboredom 7y ago
    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 7y ago
      Not all data is sensitive data.
  • icebraining 7y ago
    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 7y ago
      The hash part is not lost to bookmarks, unless Apple broke that too. If it was, no one's MEGA bookmarks would work.
      • icebraining 7y ago
        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.
• KarlKemp 7y ago
  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 :)
• Animats 7y ago
  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?
  • soapdog 7y ago
    > 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.
  • JumpCrisscross 7y ago
    > 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/ https://clearcode.cc/blog/alternatives-to-cookie-tracking/
    • oblio 7y ago
      Do they block native apps that track users?
      • frenchy 7y ago
        Only if you fail to use the Apple advertising ID. Tracking users is fine as long as Apple holds the keys.
• judah 7y ago
  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 7y ago
    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.
• saagarjha 7y ago
  Related discussion from earlier today: https://news.ycombinator.com/item?id=22683535 https://news.ycombinator.com/item?id=22683535 WebKit blog post from yesterday: https://news.ycombinator.com/item?id=22677605 https://news.ycombinator.com/item?id=22677605
  • dang 7y ago
    I think we'll merge today's threads. Any reason not to? Edit: merged.
    • saagarjha 7y ago
      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.
• eyesee 7y ago
  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 7y ago
    Maybe, but it would only apply to a subset of PWAs. For example OP's RSS reader must access remote resources.
• rapind 7y ago
  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.
• chrisfinazzo 7y ago
  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?s=21 https://twitter.com/johnwilander/status/1242882202301427712?...
• cmsj 7y ago
  > 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 :)
• _pius 7y ago
  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]."
• jchw 7y ago
  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.
• stcredzero 7y ago
  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 7y ago
    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.
• restoreddev 7y ago
  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/StorageManager/persist https://developer.mozilla.org/en-US/docs/Web/API/StorageMana...
  • OJFord 7y ago
    Based on the table there it seems Edge had but removed support anyway?
• bradgessler 7y ago
  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 7y ago
    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.
• alkonaut 7y ago
  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 7y ago
    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.
  • theturtletalks 7y ago
    https://appsco.pe/ 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 7y ago
      they really “look” like an app
      • arendtio 7y ago
        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 7y ago
    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 7y ago
• dubcanada 7y ago
  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 7y ago
    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 7y ago
      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.
      • ianlevesque 7y ago
        People keep wishing for a loophole. There isn’t one they won’t close sooner or later.
      • swsieber 7y ago
        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 7y ago
• jjtheblunt 7y ago
  Perhaps this style of app, on iOS devices, drains more battery power than deemed reasonable?
• megous 7y ago
  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 7y ago
    > 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.
• arendtio 7y ago
  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.
• wubin 7y ago
  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-blocking-and-more/#:~:text=A%20Note%20On%20Web%20Applications%20Added%20to%20the%20Home%20Screen https://webkit.org/blog/10218/full-third-party-cookie-blocki...
  • osrec 7y ago
    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.
    • kstrauser 7y ago
      Except that by "Safari quirk" you mean "the way that all common browsers are heading". Safari is the first here. Firefox is certain to be right behind them. Google, probably not, but I bet Edge does the same thing before too long.
      • Silhouette 7y ago
        I hope not. Apple has had substandard support for modern web technologies in Safari for a long time, to the point where it is often referred to in the industry as the new IE. We've had enough of browsers breaking things that used to work in the name of false progress. Time for the grown-ups to take a careful look and see this for what it is.
• jrs95 7y ago
  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.
• jmull 7y ago
  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.
• WalterSear 7y ago
  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 7y ago
    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.
• chadlavi 7y ago
  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?
• burtonator 7y ago
  I ported Polar (https://getpolarized.io/ 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.
  • vosper 7y ago
    > 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 7y ago
      > 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.
      • edmundsauto 7y ago
        This is one of the primary value props of the platform.
• taway555 7y ago
  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.
• goofballlogic 7y ago
  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).
• pgt 7y ago
  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.
• PunksATawnyFill 7y ago
  What is a "PWA?" Would be good to include in the title.
• mr_toad 7y ago
  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 7y ago
    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.
• rvanmil 7y ago
  I do not understand why anyone would want to store anything other than temporary/disposable data inside their browser.
• AndrewBissell 7y ago
  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.
• djsumdog 7y ago
  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-social-network-protocol/ 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.
• awinter-py 7y ago
  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 7y ago
    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).
• stwrong 7y ago
  Does this consider hybrid apps like ionic or Cordova to be part of this?
• andrewrothman 7y ago
  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://chromestatus.com/feature/6428344899862528 https://wicg.github.io/kv-storage/ https://wicg.github.io/kv-storage/ https://chromestatus.com/feature/5715811364765696 https://chromestatus.com/feature/5715811364765696 https://storage.spec.whatwg.org/ https://storage.spec.whatwg.org/
• soapdog 7y ago
  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.
• p2detar 7y ago
  Why 7 days though? Why not 30 or 3? What are Apple basing this number on?
• franga2000 7y ago
  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?
• rini17 7y ago
  This can't be prosecuted as anti-competitive practice?
• soapdog 7y ago
  OP here, I just posted an update section there with some extra information that I decided to clarify upon after interacting with people here. Thanks a lot for the responses, this has been quite great. I wish more people that are affected by this or that have opinions about it would write more posts. There is no change without applying pressure at Apple. If this is important, we must speak about it, all of us. And yes, I understand that some people feel that this is not important for them, that is OK, we have different values and understandings, but if you have an opinion about this, please go out and post to your blog, dev.to, medium, whatever, but post.
• yeahkapp88 7y ago
  Since when was software freedom synonymous with we should all want to use PWAs? I’d be happy if Spotify gave me an API key and essentially went away except for a monthly bill. But software has to be a product the masses get first to get made in our world. I’m glad some folks are having their itch scratched but free streams are more than enough and I can wrap them for consumption as I choose. Once again building your life around importing someone else’s priorities turns into an exercise of despair from not learning how reality doesn’t stand still no matter how hard you hope it will this time.
• slaymaker1907 7y ago
  I agree, this is really stupid. Data should only be reclaimed when requested by the user or if more storage is needed on the system on a LRU policy per site.
  • olliej 7y ago
    Could you ask all the privacy abusers to stop using them to abuse privacy? Seriously, you should browse the web for a bit and see just how many "client side PWAs" you've used/installed, vs how many tracking identifiers have been installed.
• greyhair 7y ago
  It still comes down to the point that everyone wants you to load an app from an app store. Which drives me nuts. Just give me the web, please. PWA is about the web.
• rs23296008n1 7y ago
  If privacy really is the thing, why can't I have an extension on ios to let me expire various cookies/storages on a per domain name basis, eg so I can write my extension to limit some cookies/storages to minutes or even seconds depending on how hostile or blacklisted such things are. Other domains I'd actually prefer to be indefinite. I've got a notepad thing that uses local storage and doesn't store its data on the server. There's no excuse for deleting its data since its user data. Apple therefore has no permission to delete that data. Do I have a non-cloud workaround for that?
  • hokumguru 7y ago
    Yeah, an App. They’re kneecapping the PWA to make apps more appealing.
    • rs23296008n1 7y ago
      I wonder whether my irritation over this is strong enough to App up JustAnotherIOSWebKitBrowser with an extra API just for per site storage explicitly controlled by user. Literally to run a notepad and some kind of extension thing. Its likely blocked by app store rules. Supporting extensions is probably forbidden. Anyone care to be more authoritative based on their AppStore knowledge/experience?
• dirtylowprofile 7y ago
  I have an app on the App Store that uses WKWebView, should I be worried?
• brainthomson808 7y ago
  it's really confusing
• dirtylowprofile 7y ago
  I have apps using WKWebView should I be worried?
• Andrew_nenakhov 7y ago
  The issue would be not that problematic if I could just run a real Firefox browser on iOS, not a skin over Safari, which leads me to a question that puzzles me for a long time. Why Apple is not facing antitrust charges for not allowing competing browsers on their platform? Microsoft didn't SHIP competing browsers, but allowed them to run just fine on windows, and was fined nonetheless, but Apple somehow gets away with not even allowing competing browsers at all! I'm not from the US, so maybe I'm missing something about these antitrust lawsuits. Can someone please explain?
  • Karunamon 7y ago
    This is a common misconception. 1. Apple is not a monopoly player in the app market. 2. Microsoft's antitrust fine was for forcing OEMs to not include any competing browsers (Netscape) on threat of losing special pricing.
    • Andrew_nenakhov 7y ago
      > 1. Apple is not a monopoly player in the app market. Apple has a 100% monopoly in the app market by running the only AppStore available for iOS devices, and that store review guidelines specifically prohibits use of any other web rendering engine but WebKit [1] > 2. Microsoft's antitrust fine was for forcing OEMs to not include any competing browsers (Netscape) on threat of losing special pricing. That's not the only lawsuit they faced. There was EU case that forced MS to make a special installer [2] for alternative browsers. I really can't perceive the meaningful difference between these cases. And I believe it's about time to force Apple to allow installation of alternative app stores, from where users would be able to install all the apps they want, without being handcuffed by device manufacturer. [1] https://developer.apple.com/app-store/review/guidelines/ https://developer.apple.com/app-store/review/guidelines/ [2] https://cutt.ly/ztn4kxr https://cutt.ly/ztn4kxr
      • Karunamon 7y ago
        The critical bit here is "for iOS devices". The legal definition of monopoly is interested in the broader market, not what the manufacturer of a device with comparatively tiny market share does. iOS with a 13.4% global market share as of 2019 does not even come close to monopolist status. While I'd like to see iOS forced open as well, there is currently no legal method to do so.
• jka 7y ago
  At the time of writing, the first sentence of https://www.apple.com/privacy/ https://www.apple.com/privacy/ states: "Privacy is a fundamental human right."
• gtsop 7y ago
  People complaining about how PWAs haven't taken off yet are extremely ignorant. Go open up your dev tools and see how many websites you've visited make use of at least some PWA features (most likely cache) without you even noticing. PWA features have a lot to offer to the web experience even without installing the app. You've been enjoying these features and you don't even know it.
• tech_dreamer 7y ago
  PWA was an aberration - apple fixed it :)
• deleted 7y ago
  [deleted]
• joeyspn 7y ago
  Well, wouldn't surprise me if Apple is now trying to kill aspects of the "open web" they dislike. Ironic because they used "upcoming" web standards as argument to kill Flash. Apple will do whatever it takes to protect its closed ecosystem, and if that means killing PWAs built with open web technologies they'll provide any dubious excuse to justify it (security, privacy, blahblah). They did the same back in 2010, killing a perfectly valid app platform that was picking up momentum, but they didn't control. A platform that was 5-10 years ahead of the "open web". Looks like this time they won't use HTML5 as piss-poor excuse. https://en.wikipedia.org/wiki/Thoughts_on_Flash https://en.wikipedia.org/wiki/Thoughts_on_Flash
• 40four 7y ago
  This just sounds like a great reason to not use Safari. I switched to iOS recently, but I’m a dedicated Firefox user, so I personally don’t touch it except when I’m forced to by other apps opening links. (I was honestly REALLY disappointed in Apple when I realized that you’re not allowed to set a default browser besides safari, but that’s another story) Forgive me, I’m a long time Android user, but do a lot of people choose to use safari as their main iOS browser, or are the usage numbers inflated because of the vendor lock in?
  • hoten 7y ago
    All browsers on iOS are webkit (read: safari) under the hood. Firefox and Chrome are just skins.
    • 40four 7y ago
      Thanks for correcting my ignorance :) that makes more sense.
      • hoten 7y ago
        np! It's quite a frustrating state of things. To be clear, only the rendering engine is fixed on iOS. Chrome, FF get some leeway to build other bits of the browser themselves on iOS, such as the netstack and the UI. But all new web features are limited to what webkit supports bc, well, it's webkit.
  • sequoia 7y ago
    "do a lot of people chose to use safari" No. On iOS, www = safari to almost all users.
    • 40four 7y ago
      Thanks for pointing this out. Always had Android before, now I see.
• aww_dang 7y ago
  Supporting Safari reminds me of supporting Internet Explorer years ago.
• bitL 7y ago
  The inability to save local files really hinders PWA and just allows all the shady large players to enforce their self-serving rules.
• 40four 7y ago
  Anybody have an idea what the significance of the 7 seven day cutoff is? Can’t imagine this magic number does anything to improve security. Seems kind of arbitrary.
  • chadcmulligan 7y ago
    7 days is the side loading limit I think, so they're regarding these apps as sideloaded? Everything has to go through the App Store as a guess?
• cjc19 7y ago
  Property Wisdom Adminstration
• hawaiian 7y ago
  I know I'm in the minority, but I'm glad this change is happening. I simply don't trust large tech companies to keep user privacy a top priority, and in my mind, this outweighs whatever UX niceties an honest company may provide.
  • jeswin 7y ago
    The solution could be to give that option to users; a way to mark a website or app as trusted or not. Apple's approach on the other hand really sets the web apps back, which I (as a privacy concious individual) am more comfortable using compared to apps. If this encourages more apps to go the native route, we've done more harm than good. Apps can gather a lot more data than websites, such as the dreaded contact list access.
• reilly3000 7y ago
  This is really in response to the irresponsible use of APIs for trackers. Evercookie is a stunning example of how far it can go... From their repo: - Standard HTTP Cookies - Flash Local Shared Objects - Silverlight Isolated Storage - CSS History Knocking - Storing cookies in HTTP ETags (Backend server required) - Storing cookies in Web cache (Backend server required) - HTTP Strict Transport Security (HSTS) Pinning (works in Incognito mode) - window.name caching - Internet Explorer userData storage - HTML5 Session Storage - HTML5 Local Storage - HTML5 Global Storage - HTML5 Database Storage via SQLite - HTML5 Canvas - Cookie values stored in RGB data of auto-generated, force-cached PNG images (Backend server required) - HTML5 IndexedDB - Java JNLP PersistenceService - Java exploit CVE-2013-0422 - Attempts to escape the applet sandbox and write cookie data directly to the user's hard drive. https://github.com/samyk/evercookie https://github.com/samyk/evercookie In short, everything and more can be used for tracking, and that has really killed the party for the many people who have created responsible, useful applications of these browser APIs.
  • schoenobates 7y ago
    “... abusing over a dozen technologies...” is this a proof-of-concept or a real thing ? It just seems too horrendous to be real. I think your comment really hits the nail on the head, IMHO the frustration shouldn’t be directed toward Apple but more toward the groups who have pushed the tracking practice so far to necessitate such draconian measures.
    • wmeredith 7y ago
      This is 100% correct. Being upset at Apple here is exactly like publishers whining about ad blockers when they should direct their frustration and anger directly at the ad creators (or themselves) for foolishly abusing their audience.
      • brlewis 7y ago
        No, the two are different. Ads are only used for ads. localStorage has lots of uses, tracking users being only one of them. Apple is throwing out the baby with the bath water. Ad blockers merely throw out bath water with varying levels of dirtiness.
• bovermyer 7y ago
  Maybe I'm missing something here. Why not just build a native app instead?
• nojvek 7y ago
  Unpopular opinion but this is the kind of shit that makes websites have a banner “Safari browser will experience issues, use Chrome browser for the best experience”. I remember when Edge/IE was crap, I put up a couple of banners that Firefox/Chrome/Safari are officially supported browsers and people did move away from Edge. Had <1% of traffic from there.
• muneeb 7y ago
  Can decentralized (i.e., user owned) storage help here? Instead of keeping data only at user device, it can be backed up in an encrypted and private way. Gaia is one example: https://github.com/blockstack/gaia https://github.com/blockstack/gaia (I've worked on Gaia so I'm biased but there are other such decentralized options as well.)
• homakov 7y ago
  Have a look at data: URI technique we developed to avoid Apple/App Store altogether for critical apps: https://coins.github.io/secure-bookmark/ https://coins.github.io/secure-bookmark/
• Klasiaster 7y ago
  I don't think this will help against tracking because a the tracker has no problem to refresh the identifier multiple times before the 7 day span would kick in.