Content
@
0 reply
0 recast
0 reaction
Andrei O.
@andrei0x309
It's not only on the device, I just logged in with a fresh emulator. Clearly, it's stored persistently. In the best-case scenario, it's encrypted with the user-provided seed as a password, and the seed is never stored at Merkl. But again, without the full source code of the backend + client, it's just: "trust me, bro", for all we know, even the seed could have been stored.
3 replies
2 recasts
21 reactions
artlu 🎩
@artlu
tysm for this exploration, @andrei0x309. I've just sent you my Warpcast Rewards for this week. (It's not much, but it's 100% .) Based on your best understanding, Andrei, could you speculate on what information you would need from me to be able to retrieve my phone number? My seed phrase, yes, and also would an auth token be enough?
2 replies
0 recast
3 reactions
Andrei O.
@andrei0x309
Thanks, much appreciated. I have not tested if the auth token is enough, but I can look into it. My speculation of this being guarded by the seed is the scenario, I dealt with in the past as an option when dealing with apps that integrate a client-side wallet. That scenario provides better protection for users, as any code that needs your PK needs to be executed by the client, which is more cumbersome for the provider because if users don't update the app, the provider can't take that action, or if the users use an alternative client( in Farcaster case). An example of this is the upcoming authorizing the Warplet address as an Auth address, which can only be executed with the custody PK, and will be fulfilled automatically. If is not accomplished by pushing code to the client it means Warpcast has direct access to your PK which is bad IMO. I'll take a look to see if it can be retrieved by auth token only and come back to this.
1 reply
0 recast
2 reactions
artlu 🎩
@artlu
I cannot square out "we do not store phone numbers" with "we spent eng resources to guard the phone number with the seed in a client-side encrypted best practices user-first secure way" in order to *checks notes* display the user's own phone number back to them plus a badge that says "private". Occam says he spoke an untruth
1 reply
0 recast
2 reactions
Andrei O.
@andrei0x309
100/100, but when I do speculation, I want to think of all possible scenarios and always give the benefit of the doubt. Because there were 3 possible scenarios I could see: 1 They have access to the phone data for everybody, not just a hash of the phone 2 They have access to only older verification data, and newer ones are not stored 3 They used client-side encryption guarded by data that is available only on the client side The last one(3) I invalidated, so to the best of my knowledge, only 1 and 2 are possible now.
0 reply
0 recast
1 reaction
