Hacker News new | past | comments | ask | show | jobs | submit login

> Apple restricts tracking by limiting browser storage

But the argument that this will protect privacy in the first place seems really weak.

Before this change in Apple's policy, an app could store my config data on my PC.

After this change, they'd need to have me log in and send the config data to their servers.

That seems like I've lost privacy, not gained it.






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!

> they'd need to have me log in and send the config data to their servers

You'd have to log in. That's a hurdle that involves implicit consent.


That's a hurdle that involves de-anonymization of the user.

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.

Respecting someone's privacy doesn't mean forcing them to "consensually" give up their privacy.

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.

Most people don't care about logging into services anymore. just implement a fb login and it takes less than 5 secs

If you've ever looked at user analytics you know this is absolutely not true

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?

I run away from services that only allow social media logins.

1) I don't want social media to track me everywhere

2) If the people developing this app have taken this shortcut, what other bad, leaky implementations do they have on their site/app?

-> No thanks, exit this way


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: