4 ms·
As far as privacy goes, I always say that the best way to ensure privacy, is to not take the information in the first place. I manage an app that Serves an ext
by ChrisMarshallNY 1y ago
As far as privacy goes, I always say that the best way to ensure privacy, is to not take the information in the first place.
I manage an app that Serves an extremely privacy-focused demographic. I won't use push notifications or PassKeys, because each requires that the server store information that can be linked to a user. We do require a valid email account, and that's it. The email account can be a throwaway, but it needs to be able to receive email. Other than that, the user can choose to do things like mention their location (even then, we "fuzz it," at the server level), and maybe a couple of strings that can be anything they want.
Even with that, I still find that I need to constantly assuage doubts.
I know that not taking information is heresy, hereabouts, but, if I don't have it, it can't be leaked, and I can't be compelled to divulge it.
- deleted 1y ago[deleted]
- senko 1y agoThis is the way. Or at least it should be, if companies were putting users first (a naive thought, I know). I have a small mobile app for recording expenses (receipts). The usual strategy would be for users to create accounts and store and sync data with my service. Potentially useful data (behavior, spending), which I don't want to touch with 10ft pole. Instead, I keep all the data local (user's device). No registration at all. Nothing to store on the server. Slightly more inconvenient for the users (to move to a new device, you need to export and import the local db), but cheaper and zero-stress for me.
- IgorPartola 1y agoWhat I really would love is a universal sync service that most apps would be built upon. There are apps I have used that basically say “we don’t provide storage service, but you can use your Dropbox, Google Drive, rsync service, etc.” This is really cool because while I love having my files locally I also then am entirely in charge of syncing and backing up stuff.
- brookst 1y agoI work at a Fortune 10 and we routinely avoid collecting PII when there’s no reason to do so. Not out of any noble championship of privacy, just because 1) legal wants less liability, and 2) subpoenas are a PITA for everyone.
- RajT88 1y agoDitto.
- senko 1y agoThat's nice, but "no reason" is often a high bar. There's often a good reason to keep the data (marketing, product, etc), which when weighted against the potential liability, usually wins.
- brookst 1y ago"often" and "usually" are doing a lot of work there. In my experience, in my role, we often forego collection of this data because there usually isn't an obvious upside that makes it worth it. If nothing else it's a ton more privacy and security reviews.
- jimkleiber 1y agoI built a micro-journaling app back in the day and subscribed to this philosophy as much as i could have. On Android, i even didnt let the app have the permission to access the internet. Everything was stored on device, encrypted. However i was still scared that individual phones would be hacked (or the app itself) and the info would get out anyways.
- mpalmer 1y agoWhat do passkeys require you to store besides a public key? Isn't the whole idea that passkeys don't burden providers with sensitive credentials?
- ChrisMarshallNY 1y agoA public key can be associated with an individual user. Same with the pseudo-UDIDs, that are required for push notifications.
- mpalmer 1y agoI guess I don't see a practical way of exploiting that association. UDID, that's unique identifying info for sure. But a public key that's never reused?
- ChrisMarshallNY 1y agoIt can still be associated with a user, the same goes for push notification IDs. It would be difficult, but AI has suddenly made difficult things a lot easier.
- Aaargh20318 1y agoBut so can the email address.
- ChrisMarshallNY 1y agoTo an extent. They can still use a throwaway or redirect address. With PassKeys and push notifications, there’s no way to do that.
- 6yyyyyy 1y agoYou can use KeePassXC for passkeys. It will generate completely unidentifiable public keys, and save the the private keys to a portable KDBX file. It's unfortunate that passkeys have been such a disaster. Attestation should never have been part of the spec, it should never have been presented as a replacement for hardware U2F keys, and a private key file format should have been defined on day 1. But there is useful functionality buried under all the noise and confusion.