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.
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.
I 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.
"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.
What 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.
I 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?
You 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.
I'd say it's way more obvious than using a 3rd party email service.
And that's another thing: if you use a 3rd party e-mail service then you have to trust a 3rd party not to abuse that. If they have control of that email address they can take over your account. If it's a temporary address, who's to say when that address gets reused?
If you don't use a 3rd party service then you have to have your own domain for that e-mail address, that domain name can then also be traced back to you.
If you want it to be anonymous, you shouldn't use e-mail at all and only allow passkeys.
This is all stuff that we'll need to consider. We have to have a valid email address, because the app won't work, otherwise. That's really the only requirement for server-stored information. There's a bit of stuff that stays on the phone. We try to use the Secure Enclave, as much as possible.
The issue is that the demographic we Serve (recovering drug addicts) is a very privacy-sensitive one. Another demographic (that we don't serve) is non-hetero/cisgen folks. Both of these demographics can mean persecution, and even death, in some places, so we are not casual at all about the privacy of our end-users.
At the same time, too much security can render the app useless, so we need to find a balance. The issue with information, is that once it's out; it's not so easy to put back in the bottle, so we tread carefully.
That’s pretty much what Apple does with both the PassKey and push notifications.
The PassKey is a bit better, because there’s no need to go through a broker server, like you do with push notifications, but the key is still connected with an individual user and device, so an association can still be established, with some difficulty.
If you don’t have the key or the ID stored on a server, then even that is not an issue.
I 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.
Used Obsidian (paid for commercial and sync) for years, loved it, and evangelised. Ango and team seem to have genuine integrity.
Am moving to Emacs, org, plus self-built elements, however. With much pain.
You see, what is /not/ self-guaranteeing about a full Obsidian life-organising workflow is the necessary reliance on plugins and their quirky configs. I felt as locked in to the ecosystem as I ever did with services that ‘merely’ used a proprietary storage format.
I know others in the same boat. Obsidian’s long-term legacy may well be primarily as a market-maker for Emacs.
Sure, but the primary difference between what you're talking about is ecosystem lock-in vs file lockin.
both can be postured as a labor-saving measure, exposing user data to users is an additional burden on developers. Designing an extension system that is easy for other products to use is an additional burden on developers (& developer relations! And marketing! Other products won't just adopt your extension system willy-nilly)
But switching from obsidian to something else is so much easier on a file-level than say, google docs or whatever other super-proprietary system that's being used.
I'm very wary about adjusting my workflows to depend on flimsy or proprietary ecosystems. I don't really use vim with any plugins. I don't really use obsidian with any plugins, although I'm slowly trying to ease up to using a couple that would be big QOL improvements.
Striving for standard interfaces/workflows is a good thing, but I don't think emacs is that. vim isn't that. They've just cemented themselves as the de-facto.
I'm using vim bindings in obsidian, for what it's worth. I'm not re-learning a whole other set of keyboard shortcuts (although obsidian's is quite lacking)
On the one hand, the stainless steel example can be generalized to materials. Gold, for instance.
On the other hand there is plenty of fraud in materials. There are different grades of stainless steel and different methods of production that yield differing qualities.
Maybe “immutable, buyer-verifiable” would be stronger? Once you buy and own and verify the gold you bought, it can’t be retroactively degraded by the seller. But at the time of purchase, it’s not at all a sure thing.
Well, "File over app" also needs to be verified. Think of it more as it being permanent. If your data is never sent to a server, a change in TOS can't hurt your privacy. They could still lie and send your data away! But I still feel like this is a good mental model, and I feel like the name fits with this idea of "You can't remove your promise about [privacy, data-ownership, etc]".
304 stainless is pretty stainless with fresh water. Not so much with saltwater. 316 is stainless in saltwater at normal temps, but not high temps. 400 series is both more stainless and less stainless than 300 series depending on conditions. And then there are the exotic ones.
And if all we're verifying is stainless after immersion in water, aluminum counts.
"Self-guaranteeing promise" is just a confusing way of saying "immutable properties after measurement".
I understand you're trying to be more precise, but what the average person cares about is whether the knife rusts easily or not.
I don't think the average person is going to understand what you mean by "immutable properties after measurement", though I'll concede "self-guaranteeing" is probably equally confusing.
"Verifiable and non-reversible" seems clear enough, but a bit long.
I understand keeping applications open to change is for extensibility reasons.
In the privacy case enterprises need to ask for customers consent before changing policies. This includes changing prices too. But usually they take them for granted.
No, not really. You're just assuming they're going to continue displaying your posts on bsky.app. Everyone is reading your posts through bsky.app and it doesn't matter if your post is technically available through a side channel if it's not available through the main channel.
bsky.app is the way that people view bluesky posts. That is a fact and it will continue to be the fact for the useful lifetime of bluesky. If bsky.app dies, so does bluesky because it is bsky.app.
If the promise is: when using the AT Protocol you have control over your own data, then this is self-guaranteeing, since it is a part of the spec that you can self host a PDS.
The promise that Bluesky will always be compliant with the spec, or that the spec won’t ever change to disallow this isn’t self-guaranteeing, but you could say something similar about any of these self guaranteeing promises. For example the promise that Obsidian will always use markdown isn’t self-guaranteeing.
> The promise that Obsidian will always use markdown isn’t self-guaranteeing.
True, but Obsidian doesn't make that promise. The promise is "file over app": you control the files you create. In this way the promise is not reversible, and self-verifiable.
"...will always use markdown" is not something any app can guarantee. At best an open source app can guarantee it for a specific version (assuming it doesn't require a connection, or the user can self-host the server).
...and for decades in IT, I was pretty firm on the topic of "just because we CAN collect that data doesn't mean we should." I imagine the DOGE bros who took over my old agency are still living with that.
"We want to know who asked stupid questions in support so we can fire them!"
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.
This 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.
I 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.
That'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.
"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.
Ditto.
What 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.
What do passkeys require you to store besides a public key? Isn't the whole idea that passkeys don't burden providers with sensitive credentials?
A public key can be associated with an individual user. Same with the pseudo-UDIDs, that are required for push notifications.
I 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?
It 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.
But so can the email address.
To an extent. They can still use a throwaway or redirect address.
With PassKeys and push notifications, there’s no way to do that.
You 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.
You can throw away a passkey just as well as you can throw away an email address.
This is a good point. I'm not sure that it is as obvious to nontechnical users, though.
I suspect that many people's Passwords apps are littered with dead passkeys.
I'd say it's way more obvious than using a 3rd party email service.
And that's another thing: if you use a 3rd party e-mail service then you have to trust a 3rd party not to abuse that. If they have control of that email address they can take over your account. If it's a temporary address, who's to say when that address gets reused?
If you don't use a 3rd party service then you have to have your own domain for that e-mail address, that domain name can then also be traced back to you.
If you want it to be anonymous, you shouldn't use e-mail at all and only allow passkeys.
This is all stuff that we'll need to consider. We have to have a valid email address, because the app won't work, otherwise. That's really the only requirement for server-stored information. There's a bit of stuff that stays on the phone. We try to use the Secure Enclave, as much as possible.
The issue is that the demographic we Serve (recovering drug addicts) is a very privacy-sensitive one. Another demographic (that we don't serve) is non-hetero/cisgen folks. Both of these demographics can mean persecution, and even death, in some places, so we are not casual at all about the privacy of our end-users.
At the same time, too much security can render the app useless, so we need to find a balance. The issue with information, is that once it's out; it's not so easy to put back in the bottle, so we tread carefully.
If they're so privacy-focused, can't they generate a key specific to the app?
That’s pretty much what Apple does with both the PassKey and push notifications.
The PassKey is a bit better, because there’s no need to go through a broker server, like you do with push notifications, but the key is still connected with an individual user and device, so an association can still be established, with some difficulty.
If you don’t have the key or the ID stored on a server, then even that is not an issue.
I 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.
Used Obsidian (paid for commercial and sync) for years, loved it, and evangelised. Ango and team seem to have genuine integrity.
Am moving to Emacs, org, plus self-built elements, however. With much pain.
You see, what is /not/ self-guaranteeing about a full Obsidian life-organising workflow is the necessary reliance on plugins and their quirky configs. I felt as locked in to the ecosystem as I ever did with services that ‘merely’ used a proprietary storage format.
I know others in the same boat. Obsidian’s long-term legacy may well be primarily as a market-maker for Emacs.
Sure, but the primary difference between what you're talking about is ecosystem lock-in vs file lockin.
both can be postured as a labor-saving measure, exposing user data to users is an additional burden on developers. Designing an extension system that is easy for other products to use is an additional burden on developers (& developer relations! And marketing! Other products won't just adopt your extension system willy-nilly)
But switching from obsidian to something else is so much easier on a file-level than say, google docs or whatever other super-proprietary system that's being used.
I'm very wary about adjusting my workflows to depend on flimsy or proprietary ecosystems. I don't really use vim with any plugins. I don't really use obsidian with any plugins, although I'm slowly trying to ease up to using a couple that would be big QOL improvements.
Striving for standard interfaces/workflows is a good thing, but I don't think emacs is that. vim isn't that. They've just cemented themselves as the de-facto.
I'm using vim bindings in obsidian, for what it's worth. I'm not re-learning a whole other set of keyboard shortcuts (although obsidian's is quite lacking)
Not especially well thought out.
On the one hand, the stainless steel example can be generalized to materials. Gold, for instance.
On the other hand there is plenty of fraud in materials. There are different grades of stainless steel and different methods of production that yield differing qualities.
Maybe “immutable, buyer-verifiable” would be stronger? Once you buy and own and verify the gold you bought, it can’t be retroactively degraded by the seller. But at the time of purchase, it’s not at all a sure thing.
Well, "File over app" also needs to be verified. Think of it more as it being permanent. If your data is never sent to a server, a change in TOS can't hurt your privacy. They could still lie and send your data away! But I still feel like this is a good mental model, and I feel like the name fits with this idea of "You can't remove your promise about [privacy, data-ownership, etc]".
Not all materials are a good example of a self-guaranteeing promise because purity can't always be easily verified at home without special equipment.
In the example of stainless steel it is "stainlessness" that is the promise, and that only requires water to test.
> that only requires water to test.
Not really.
304 stainless is pretty stainless with fresh water. Not so much with saltwater. 316 is stainless in saltwater at normal temps, but not high temps. 400 series is both more stainless and less stainless than 300 series depending on conditions. And then there are the exotic ones.
And if all we're verifying is stainless after immersion in water, aluminum counts.
"Self-guaranteeing promise" is just a confusing way of saying "immutable properties after measurement".
I understand you're trying to be more precise, but what the average person cares about is whether the knife rusts easily or not.
I don't think the average person is going to understand what you mean by "immutable properties after measurement", though I'll concede "self-guaranteeing" is probably equally confusing.
"Verifiable and non-reversible" seems clear enough, but a bit long.
How would one go about switching away from Dropbox to something else that would be free, private, and macOS/iOS compatible?
Free? How are the servers going to run?
Syncthing is probably the closest bet. It doesn’t require servers, so it can be free. But it isn’t really a full Dropbox replacement.
Yes, that was boneheaded of me (was just waking up when I wrote that). I should have written "FOSS".
The only real way to do this “for free” that I can think of would be to self-host on an old laptop. Unless you meant free as in open source.
5GB of iCloud storage is free, and if you turn on Advanced Data Protection, it’s end-to-end-encrypted: https://support.apple.com/en-us/108756
I understand keeping applications open to change is for extensibility reasons.
In the privacy case enterprises need to ask for customers consent before changing policies. This includes changing prices too. But usually they take them for granted.
Bluesky/ATProto is a recent example of a self-guaranteeing promise
No, not really. You're just assuming they're going to continue displaying your posts on bsky.app. Everyone is reading your posts through bsky.app and it doesn't matter if your post is technically available through a side channel if it's not available through the main channel.
There is no main channel
bsky.app is the way that people view bluesky posts. That is a fact and it will continue to be the fact for the useful lifetime of bluesky. If bsky.app dies, so does bluesky because it is bsky.app.
Really? What makes the protocol self-guaranteeing?
If the promise is: when using the AT Protocol you have control over your own data, then this is self-guaranteeing, since it is a part of the spec that you can self host a PDS.
The promise that Bluesky will always be compliant with the spec, or that the spec won’t ever change to disallow this isn’t self-guaranteeing, but you could say something similar about any of these self guaranteeing promises. For example the promise that Obsidian will always use markdown isn’t self-guaranteeing.
> The promise that Obsidian will always use markdown isn’t self-guaranteeing.
True, but Obsidian doesn't make that promise. The promise is "file over app": you control the files you create. In this way the promise is not reversible, and self-verifiable.
"...will always use markdown" is not something any app can guarantee. At best an open source app can guarantee it for a specific version (assuming it doesn't require a connection, or the user can self-host the server).
"We will never sell your information!"
Yeah, but whoever buys you or executes your bankruptcy probably will. Much better for you to never have it in the first place.
"You will change your mind, but I won't change mine."
Why I give crap data to everyone unless there is absolutely no other way.
Facebook thinks I live in a ghost town in Utah, and I'm 121 years old.
Also why most of my accounts that want a street address contain an address-line-2 like "JOEBLOW.COM SOLD OUR DATA," so they can't hide.
Piss in the well, y'all.
...and for decades in IT, I was pretty firm on the topic of "just because we CAN collect that data doesn't mean we should." I imagine the DOGE bros who took over my old agency are still living with that.
"We want to know who asked stupid questions in support so we can fire them!"
I saw you coming 30 years in advance, asshole.