• 0 Posts
  • 28 Comments
Joined 2 months ago
cake
Cake day: March 25th, 2025

help-circle
  • Because cryptography is hard, especially when you’re trying to do it in a user-friendly manner, with syncing encrypted conversations between devices and whatnot. Like, it’s kinda the whole reason why the classic reply to “how do I make my own encryption algorithm” is “don’t”.

    Also, with proprietary platforms you can’t make sure stuff’s encrypted the way they say it is


  • I guess it can be done relatively securely using both the password and the code to derive the encryption key while not storing it on the servers (while 2fa isn’t of any help here given it’s kinda random with shared seed). I, however, doubt it’s done that way: 1st of all, decryption should then only be possible after one enters their account password for the second time, as well as the conversation password (since the password shouldn’t be stored in plaintext after you’ve entered it), and, secondly, that’ll basically drop the chat history as soon as one changes the password, which is neither convenient nor mentioned.

    Then, if it works how I assume it does, i.e. the actual encryption key is stored on the xitter’s servers and only retrieved once you enter the encryption password, then they can decrypt your messages (either by immediately using that if the password just tells 'em who they should give the key to, or by bruteforcing the password if it decrypts/derives the actual key), which defeats the whole point of e2ee.
















  • A small addition to already mentioned stuff. There are multiple ways to deliver the notifications without google services. 1st and older one is by simply letting the app hang in the background indefinitely and ping the necessary servers from time to time, that one almost always works, since app developers can’t really rely on gapps being installed; 2nd is UnifiedPush (that’s already mentioned sunup [mozilla], but also ntfy [ntfy], nextpush [nextcloud], gCompat-UP [google firebase], NoProvider2Push [fully local]). AFAIK, it works similarly to the way gapps send notifications and uses less battery, but not all apps support it, so you may need to search for forks. For example, the official and, iirc, Foss telegram clients don’t, but mercury, nagram{,x} and momo do.



  • Samsungs mostly, also shift and a few older models. Although, some have a crutch called displaylink, which basically encapsulates video signal over USB in software, while dp alt mode kinda* connects those same wires to the displayport output of the SoC (which is better due to having little to no overhead as well as ~no need for specialized overcomplicated hardware).

    Also, some of the older models, like my beloved oneplus 6, don’t even support USB 3, so dp alt mode is physically impossible for those.

    * iirc, on qualcomms at least the SoC itself multiplexes USB 3 with dp (as in, it can be configured to output usb3 or dp on the same data lines), but I’m not sure how the switching itself is triggered, so there may or may not be a need to add another IC that’ll handle communications over CC lines and tell the SoC when to use which. I personally suppose the SoCs should be able to handle everything themselves, tho.