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).
Wouldn't it be possible to retain the data with privacy by:
- Asking the user client side for a password
- Encrypt data as a blob using some symmetric encryption (AES)
- Push encrypted blob to the server with login attached
If you're using SSO the client authenticates and then can pull down the encrypted blob based on the SSO auth being valid. You can tie 2FA in however you wish. At that point the user is prompted for a "data" password for that particular site. Or would there be an easy way to build a pki/pin cert type of encryption to eliminate the password prompt? (I feel like this is essentially what Keyring!? would do but maybe not?)
Outside of implementation weaknesses which I feel could be mitigated by created standard libs to do this, what am I missing?
Bonus points for pushing the data diffs only or even a version controlled blob (data stored in a git repo where only the diffs are pushed in encrypted form).
Edit: Or how about a local hardware appliance for your network that stores all data like this encrypted and pulls from there.
It's very hard to verify that the data is indeed encrypted, whereas with local storage you can just monitor your network usage and see that no requests are going out. Hell, you could airgap your machine and have no problems with localstorage.
You can implement end-to-end encrypted applications e.g. with the subtle crypto API, though there’s always a debate of whether this really provides good privacy as the website owner or an adversary who can inject code can still change the JS and steal the data. Personally I think it’s still much better as the data at rest is encrypted and only the user can decrypt it. Now the problem is of course that if the user forgets his/her password the data is gone. To alleviate that you can again think up some schemes like encrypting the encryption key with an asymmetric scheme where the private key is kept secure by the website owner, but that then requires a process for securely using this key... So it’s possible but not trivial I would say!
No, Apple offers anonymous user credential technology. Server gets unique identifier and ability to authenticate with no actual user info. Server gets an anonymous redirected email for sending info to the user. Apple is the intermediary. Of course, you can choose not to trust Apple, but Apple already has my info and their business model is not predicated on tracking and advertising. I'd rather continue to trust them than spread my data across more orgs, but that's my choice. You might choose differently.
I choose differently, but my choice may matter to you if I throw up my hands and say "Too much effort; if the user visits my site in Safari, I'm just going to toss up a banner page that says "this site does not work in your browser."
It's a power-play on Apple's part to intermediate themselves where their inter-mediation isn't necessary. And all kinds of customers (enterprise in particular) won't appreciate Apple getting a free "hi hello" signal on how much their company uses some service that leverages this scheme. Especially if Apple is a potential competitor to them.
Same. We momentarily considered adding Apple Login to our app when they changed the rules a couple weeks back, but instead we are removing all social login and migrating all accounts to (email/username)/password. Why?
Because a) it's even more code we now have to support, both in our apps even on android and on web -- a huge investment we are not prepared to make, and b) because for what we do, we actually do need to know the user is who they say they are (we offer the ability to contract a service between third parties, which means anonymity is NOT desired). I was never really comfortable using social login at all, for that second reason, but was pressed to by my peers; after Apple's shenanigans we came to the mutual decision that it was time to cut the cord. The login screen is already busy enough, we don't need yet another button. So we'll simplify.
For this latest change, it won't affect us much because I have always made it a policy neither to trust, nor to rely on, the data in Local Storage, and only to use it for performance boosting via caching. If data isn't there, it isn't there, and we go get it. This is largely due to historical reasons where browsers have always borked the LS implementation in one way or another, but it's beneficial now in that it won't really change anything for us.
I do feel for folks that are using it for genuine storage though, I know some apps that use it in order to AVOID storing private data on their servers, which will now have problems and be forced to reduce privacy in order to adapt.
This is definitely a power play on Apple's part to further weaken the web ecosystem. Device sales have been falling for years, they know their cash cow is their 30% cut on app purchases and IAP, and they aren't going to let the browser cut into that. Any "privacy" benefit in this case is purely incidental (and as noted above I believe it will do the opposite in many cases).
But that's a solution for a single OS, for a web page that should be cross platform by default. And it's not really a solution, just additional complexity to what was a solved problem.
Thank you. I think this is very often overlooked. "Consent" gets thrown around alot but most of the time people basically have no choice if they want to, you know, participate in modern society. That's one of the reasons why an open web is so so so important and why I think Tim Berners Lee is working so hard to try to bring some part of that back as the "online world" (apps and internet) become more and more walled garden.
If you are coerced into giving consent, it isn't consent, and most of the time if you're doing it so you can be part of the world around you, it is coerced, whether people want to recognize that or not.
Any time you see the phrase "implicit consent", it can be helpful to stop and ask how that consent could be withheld without changing anything else. If it can't be, then it's not really consent at all.
I'm interested. As a iOS developer I always found that user want to skip the login page soon as possibile, if there is an FB button they press it.
Do you have different experiences of it?
Web-wide analytics (and our own, which have almost exactly the same stats), show about 30-40% of users still rely on email/password (and that's actually growing, as password managers become more ubiquitous especially when Apple implemented the built in credential manager in apps and in Safari on iOS).
We're actually getting rid of social login in our apps. And we're not alone, alot of platforms I use have recently moved the same direction, and I think for the same reasons.
Google, Facebook, Github, Twitter logins proliferated because
a) the cost of implementing an auth system is high, and those offered a turnkey solution that was cheap and quick to implement. This is no longer true, there are lots of options now to host your own auth while federating the hard work to someone else (e.g. Auth0, Cognito, et al)
b) for awhile, people LOVED the idea of having "an online identity" and a single login everywhere. Over time this has not really panned out, because it's the prisoner's dilemma; for it to work, everyone has to do it (which is why G and F have tried so hard to get everyone to use them). But also, because privacy questions have reduced the shiny appeal of that scenario in the first place. Combine that with easy to use password managers now, and it's much less necessary.
But browsers are severely sandboxed already. What the article is talking about is:
> deleting all local storage (including Indexed DB, etc.) after 7 days
which I can see how it might help privacy (since you could be tracked via local storage too) but also how it might break any potential web app that might need data to last more than 7 days.
> If you want more access, make a native app
But then, everybody will complain about yet another Electron app, right? Not to mention that you have to fork over $99 and go through the signing / notarization hoops that change from one week to the other.
I think in the name of privacy and security only Apple and some select few corporations will be allowed to make software in the future. macOS / iOS and Windows 10 are evolutionary dead ends in many ways.
* AdoptOpenJDK releases that were notarized some months ago are no longer accepted by Apple since they made the rules even more stringent. I had releases accepted by Apple that are not accepted today using the same AdoptOpenJDK binaries.
* Apple's notarization rules are not global. There's whitelists for given companies/institutions/apps/files which means the same dylib might not have to be notarized by a bigger player but will have to be codesigned by you.
The above happened to me in the span of less than 3 months I think?
Indeed, the scripts I use per se to do the notarization are about the same as originally.
Apple may have stepped up notarization requirements, but I never heard them be inconsistent across developers. Are you sure you submitted the same binary? Nothing different about the signing or bundle layout?
Apple requires that all code-related assets for an app should be included into the app. So the app cannot just be a launcher that show a browser with a website.
If we had to make non-electron, native version of our app, that would mean Windows[1] and Android, because that's where the current users are. Forget the rest.
Is that the future you want?
[1] And they would not be happy about that either. For many that would mean RDP or Citrix. They prefer webapp right now.
It would only be citrix if it was made a native app. It is presently a web app, presumably because it was determined to be a better choice. You proposed that it should be a native app. It would be the customers that would choose Citrix, but they'd probably prefer web apps (if they're anything like my customers).
The deployment story is so much better for web apps, which is the main reason it seems to be so compelling for big enterprises.
I think apple DOES want this. Core markets cleanly segmented are probably a better value prop to apple than everything working everywhere and users being able to freely migrate between platforms
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.
Yeah, cause everything in the browser is free, right?
Clearly it's A LOT of money for apple. If they didn't care about the money then they would just allow it so everyone could avoid receiving payments using apple and giving them 30 %.
That still doesn’t answer the question. How many websites were required to be apps because of limitations of Safari?
What makes you think users would willy nilly put their credit card on every random website.
Everyone can avoid using Apple for subscriptions. There are existence proofs of apps on the store that require payments outside of the store - like all digital content from Amazon.
Most of the money that people spend on the App Store are from games and in app consumables. Especially since the major services like Netflix and Spotify don’t allow in app subscriptions.
Seeing that most major subscription services on the App Store are already forcing users to subscribe outside of the App Store, Apple isn’t getting a cut of subscriptions from the most popular service.
How many apps require a subscription and cannot be a web app because of limitations of Safari?
How many paid apps would be websites if it weren’t for limitations of Safari?
The moment you offer in-app payment, apple gets a cut. This goes as far as not allowing apps that link to payment outside of the appstore's payment system.
There is a huge number of cordova apps out there. These are webapps inside a native wrapper, to access exactly those features that are crippled in safari. Reliable storage, push notifications, and not much more.
ACloudGuru does not allow you to pay for subscriptions via in app purchases, Udemy allows both. A company can decide whether it is right for their business model to allow in app purchases exclusively or along side their own payment options.
Hulu for instance allows in app purchases for the regular Hulu service but not Hulu Live
Which in a current situation is running a risk to fall into Google's walled garden. It is not there yet but Google's working hard on subverting the Internet.
It's not "limiting browser storage", it's making browser storage expire. TFA's example is just some random app, but this essentially kills the entire concept of an offline-first web app, and severely hurts the browser as an application platform.
> If you want more access, make a native app (with or without web technologies).
Browsers usually ask for an additional permission in this case which would be a good approach. Your post sounds like "browsers need to be severely limited, so if you want to watch video, just launch VLC". It does not work this way.
Making a native app is more complicated than making a webapp, especially if you want something cross platform. Browsers are now an universal virtual machine, what was the JVM years ago, and with webassembly we will se more and more things done in the browser.
The real 'write once, run everywhere' are webapps, a webapp doesn't care if you are using Apple, Windows, Linux, BSD, whatever, if you have a compatible browser you use the app.
Sure there is Electron (or React Native), to me it doesn't make sense, what is the point that every application needs to ship basically a browser? And still Electron apps need to be compiled and packaged for every platform, while with webapps you enter the URL in the browser and you are done with it.
Doesn't adding APIs to browsers not only to use the local storage but also to access the filesystem of your device (of course asking the permission to the user) make more sense?
Of course what really Apple fears is loosing the control of the apps that gets used on their device, now they control the App Store that is the only way to get apps on their devices (beside jailbreak), with webapps is different, since you can access them directly from the browser.
And the thing that is absurd is that the first iPhone didn't have the App Store since Apple decided that the only way to get third party apps was trough the browser, now they are aiming for the opposite thing.
My company created a web client for our chat software product around 5 years ago. The quality of our product has slowly deteriorated as browser vendors continually remove or restrict features that once worked fine. Just to name two examples: autoplay audio for chat notifications and tab throttling killing websocket connections and background timers. I understand bad actors are abusing these things, but they're breaking totally legitimate use cases.
We've been forced into an electron client and now urge our customers to ignore the web client. If we didn't have a small number of customers on Macs, we would abandon web tech altogether and build a native Windows client.
You have to send every change to Apple before the user can run the code. In theory, that allows Apple to do more checks than when the code is dynamically loaded from your web server.
Apple doesn't care if your app logs your usage to Google Analytics every 1000ms.
Besides, in the browser you have trivial tools like uBlock and the network tab. In native apps, you have to use mitmproxy just to see what the app is doing at all.
> Browsers need to be severely limited due to them running arbitrary code from the web. Doesn't matter if it's an offline web app. If you want more access, make a native app (with or without web technologies).
Native apps have the same problems too and such "severe" limiting of apps in web browsers still doesn't solve it. The only more or less privacy preserving model I can think of for native apps today is open source repositories with app distribution not controlled by app developers, like f-droid or repositories in various linux distros.
Wouldn't making it first party only cover it? I don't see how this has anything to do with privacy/tracking. webpages can still leave long term cookies. The only way this is a privacy issues is if 3rd party iframes can use localstorage but just like 3rd party resources have their cookies blocked so to could localstorage.
Otherwise this has absolutely nothing to do with privacy or tracking.
OR maybe it's apple's responsibility to figure out how that usecase can exist without security flaws?
As a customer, I'm tired of devices functionality being limited coz "security risks". Functionality that is arguably superior to native apps apart from the security risk.
...and give apple their cut. Why not add permissions to webapps? Like location, or push notification... oh that's another feature that happens to be missing only in safari.
Just accepting these moves from apple as "in the interest of users" is naïve. Apple has a huge vesting in their appstore, and every webapp is a potential appstore-app that is some lost revenue.
I mean, maybe apple is right, and the web should go back to a readonly document-like format, like in the old days. Articles and links. Apps for everything else. But let's not kid ourselves that they do it purely in the user's interest.
Genuine question: what makes native ad frameworks different here? They execute with the same privilege of their containing app so surely they’re open to similar privacy concerns. Shouldn’t native apps have their storage cleared?
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).