Kuba Suder, disinternected 
developer.apple.com
kSecAttrSynchronizable | Apple Developer Documentation
A key with a value that’s a string indicating whether the item synchronizes through iCloud.
Feed with all replies from Bluesky team members (plz don't ban me)
Feed on BlueskyFeeds Stats
- 💙 Liked by 3 users
- 📅 Updated 3 months ago
- ⚙️ Provider blue.mackuba.eu
Team Watch Likes over time
Like count prediction
The feed Team Watch gains approximately 0 likes per month.
Feed Preview for Team Watch
relay-vps.demo.bsky.dev is a full network relay for $34/month (phil showed me up with his cheaper french relay!)
0
0
1
At the end of the day its a threat model and expected value question. What are the most likely outcomes, multiple that by what are the mitigations that we are most likely to get users to take. My goal is to maximize good outcomes
1
0
6
ahhhh no no. yea you can still view the plain text but the app just has to decrypt the key first.
(this is why it should be stored outside the client!! just, this is still way better than nothing)
1
0
1
if the pds is offline the client can simply show a “hey we can’t log in!!” and a button that lets you retrieve the key
0
0
1
the user can access it though. it’s stored behind faceid, but it’s fully readable by the user once they authenticate
2
0
1
ya i strongly agree. however, trusting a user to not put it in their notes app is imo exactly why the client needs to store it - even though you can still do whatever - because trusting the user to store it safely on their own isn’t possible
1
0
7
why would the key be pointless? you just click “get key” and boom there it is (even if the pds is offline!)
1
0
1
the likelihood of bluesky turning evil and releasing an update to delete your local keys without any buildup or anyone realizing "hmmmm" is significantly lower than the other scenarios imo, and are the much more immediate risks imo.
1
0
7
if the only private keys you have are stored on that server (even if you control the server!) that's no good.
you're also trusting that the server be _secure_. if some bad actor got access to the key, you'd also be screwed.
1
0
3
ya i think for android its a lot rougher.
tbh i think it should be _strongly encouraged_ to stick it in a password manager though (even if it was stored in keychain etc) so maybe thats fine
0
0
1
i disagree that this is the whole point of the key. i believe it is one reason, but far from the only. any time you're trusting another provider (be it bluesky or any other service including your own), you're betting on that service staying online.
1
0
4
Yeah, im definitely all for still letting the user have access to the key, and that should be an easy option (keep in password manager or something) but in the event the bluesky app turns evil overnight with no forewarning then we have other issues
0
0
2
I'll get the ask escalated but the video team is taking a mental health day (unrelated to your posts (probably)) so I'm not sure I could resolve this until tomorrow anyway
14
1
251
i can't wait to see how many cids you have by next week, at this rate
0
0
9
seems this isn't available in expo-secure-store, so you'd either need to roll a smol guy on your own or just patch ess (which wouldn't be very hard)
2
0
0
So the idea IMO is just have a new backup key *per device* and dont ever both moving it from that device.
1
0
5
Hot. Now just gotta shove that in some secure device storage thing
3
0
10
mostly depends on how much you trust your own opsec. i'd trust my own (i.e. sticking it in a password vault) more than letting a third party store a key higher than mine
0
0
4
nice!!! i think i'd actually put the key at the _front_ of the list rather than at the end
1
0
6
