Since the start of February, Rewind seems to have had 3 PRs merged for macOS (they auto deploy on new commits to main for both iOS TestFlight and macOS) and it’s had known bugs that have been around for months so I’m not holding my breath. Hopefully it’s at least updated for new macOS releases but I’m expecting an announcement in the future saying it won’t be supported anymore or it just not getting any updates for a year.
I do think they’re unlikely to sell user data, but it’s important to note that their privacy claims aren’t true and it would be possible for them to[1].
When I saw them compare it to E2EE, since that’s at least a specific thing that can’t really be misinterpreted, I thought they were serious, but turns out it’s not at all[1] and they are advertising themselves as being far more private and secure than they actually are. Considering their investor list[2], maybe this is more common than we realise?
Limitless is encrypting at rest, not using end-to-end encryption.
E2EE suggests that only the user (or at least only people the user knows about in the case of e.g. group chats) is able to see/access the decrypted data, which is false. Limitless does not decrypt data on the client using a key only the user has access to, it decrypts the data on the server (in this case using AWS KMS) and sends it to the client. Even if we remove just decrypting everyone’s data out of the equation using AWS KMS (since the user does not control the key), you could trivially write a Cloudflare Worker (since you use Cloudflare on your API subdomain) that simply sends the (unencrypted) API response along with the email from the Supabase JWT used in the header to a server that accumulates everyone’s recording names, transcripts, generated notes and generated summaries. If someone gained access to your Cloudflare account they could also do this. You’re advertising Limitless as if you aren’t able to see people’s transcripts even if you wanted to, which is false. Even your employer can if they TLS MitM you with their own TLS certificates, which is not rare. On the other hand, Signal cannot see your data unless they modify client code, nor can your employer unless they install a modified Signal client on your device or install spyware on your device, which is reading decrypted data from memory. This is what separates encrypting at rest and E2EE (which you say your solution is just as secure as and is better than) for the end user and it feels like false advertising. Limitless, your employer and a potential hacker can all read your data, at the minimum while you’re using Limitless.
They don't really give any specifics and I'm not sure if they give you the keys or explain how the keys are derived (which I assume must be based on your login if they don't make you enter it otherwise they must be able to decrypt it whenever they want) but they mention they worked with Latacora[1]. Also curious if anyone else has any ideas on how they prevent themselves from being able to decrypt user data while implying they're not using E2EE[1].
Edit: I just tried it. They don't give you encryption keys you need to enter when signing in and the server literally sends you your transcripts with no encryption. Maybe they're including a key somehow derived when signing in with Google/a magic link in the request, but I don't think anything would stop them from just logging API responses even if that was the case. They're definitely not using E2EE. They might just be encrypting at rest and storing their keys in AWS KMS which sounds like false advertising.
