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).
But the argument that this will protect privacy in the first place seems really weak.
Before this change in Apple's policy, an app could store my config data on my PC.
After this change, they'd need to have me log in and send the config data to their servers.
That seems like I've lost privacy, not gained it.
You'd have to log in. That's a hurdle that involves implicit consent.
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.
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).
1) I don't want social media to track me everywhere
2) If the people developing this app have taken this shortcut, what other bad, leaky implementations do they have on their site/app?
-> No thanks, exit this way
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.
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.
- 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.
> 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.
And I made a test about the non-global rules too (by trying to submit the same binary and getting rejected).
My notes are here: https://www.patreon.com/posts/34472331
You can take the same Apache-NetBeans-11.3-bin-macosx.dmg and see how you could submit it with your own key.
I guess there may be different rules on a .pkg vs .app in a DMG but it seems silly since the user gets the same bits on disk.
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.
The market will decide. Your comment is just on the user-hostile side of assuming it will prefer your technology choices.
The deployment story is so much better for web apps, which is the main reason it seems to be so compelling for big enterprises.
which is somewhat ironic, because the goal of a web app is to break free of the walled garden and become OS-independant.
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.
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 %.
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.
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?
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.
Hulu for instance allows in app purchases for the regular Hulu service but not Hulu Live
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.
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.
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.
that’s not been my experience*
* unless you use some huge web framework to abstract everything and patch all the differences between the browsers
How's installing a native app better for a random user privacy or security wise, exactly?
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.
I understand it's changing too, but not as fast as safari.
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.
Otherwise this has absolutely nothing to do with privacy or tracking.
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.
A big chunk of the web these days uses JWT and localStorage for auth.