Security isn’t about protecting everything from everything. It’s knowing what you’re protecting from what (and what you’re not protecting). That’s why we use threat models.
An analogy: you don’t protect food from the environment; you protect different types of food from different factors of the environment. You might design a heat lamp to protect the freshness of your dinner but a freezer for your ice cream. What you don’t do is design a heat lamp and assume it’ll protect your ice cream also.
@aral ...and if one, in your analogy, tries to protect everything from everything, one ends up with a heat lamp in the freezer, keeping everything tepid,
which is pretty much the worst case scenario.
@aral I like the "heat lamp" vs "freezer" analogy... Have to keep it in mind 🙂
@aral spoken like a true politician, with a matching, completely unrelated comparison, that's supposed to conclude the argument.
What threads do we (our phones) face? Physical theft; digital theft? Have you ever considered that over 50% of the world population, live under oppressive governments, that have all resources, to access your phone?
Not to mention that most of these tools, find their way online - so even if I can't access your stuff today, I'll likely tomorrow.
@aral so instead of hailing a $1200 device as more secure (which by the way, some 25% of the world population cannot afford in a lifetime); we should instead raise awareness of howto better protect yourself; or at least, be more aware what happens with your data - and maybe, not to trust your phone to keep it "safe" for you.
So yeah, maybe for an API, you can create a "thread model"; but with our phones, this is a completely different issue.
@franz Yep, I’m a politican, Franz. You really managed to capture my essence. Congratulations, man. As you were…
@aral just proves my point. Cheers :)
Do you know of any threat models for anything in the fediverse?
@bhaugen On the fediverse, in its current incarnation at least (if we’re talking about ActivityPub), there is no expectation of privacy. Everything is public. I don’t know if there’s a formal threat model of ActivityPub in the spec (it’s been a while since I looked at it).
I don't see any mention of "threat" in the spec. But I assume you know that @cwebber is working on AP-related code that is aimed partly (but not only) at privacy: https://gitlab.com/spritely/golem/blob/master/README.org
Threat model? Sorta informal, list of problems...
@aral @bhaugen ActivityPub, from the spec perspective, *IS NOT* everything is public. That's a common misunderstanding due to the most popular instance being a Twitter clone. But that's false. ActivityPub's origins come from trying to bring email-like private addressing (to the extent email really is private) to the fediverse, with public stuff being a special exception.
And that's not even to consider the current stuff I'm exploring in Spritely, which is taking some of that further.
@cwebber @bhaugen When I said “everything is public”, I meant it in the same way that email is public (it’s a post card, not a letter in an envelope). I should have been more precise: it’s not end-to-end encrypted and thus does not have any privacy guarantees. I believe you’re working on that with Spritely? (Skimmed.)
It's a common meme though, and it's not just you. I agree that email is not good enough. The thing that annoys me is that there's a lot of imprecision and it sounds like AP is even *less* directed than email (one exception I will agree with is sharedInbox being a problem, but in a sense delivering to specific inbox endpoints is even more direct than email)
@aral still, both email and ap's "privacy guarantee" is the same: your messages will be private to the servers that receive them. that doesn't preclude the "rogue admin" threat model, but it doesn't make either "public" per se.
even if your measuring stick for privacy is e2ee, you're basically making the mistake of equivocating existing implementations with the spec itself. pgp exists for email, but hasn't been done yet for ap. it's like saying xmpp is public despite omemo
This is my personal Mastodon.