Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)CM
Posts
2
Comments
78
Joined
2 yr. ago

  • Only public keys get exchanged via Meta's servers, those keys don't help you with trying to decrypt any messages (you need the corresponding private key to decrypt - and that private key stays on the device).

    Sure, they could just do a man in the middle, but that can be detected by verifying the keys (once, via another channel).

  • Maybe so, but in this case the point was that the protocol used by WhatsApp hasn't changed in that time and it's still what they describe in their security whitepaper. If you want to use that software as is or maybe reimplement it based on that is up to you.

  • In a subpoena case in India, that turned out to be not true.

    Source please.

    WhatsApp admins hold keys to being able to do that under law pressure.

    How do they get the keys?

    They only guarantee it for 1-1 messages and statuses, and against “generic” actors for group chats…

    Who is "they"?

  • yowsup is an Open Source implementation of the WhatsApp protocol. So there is proper end-to-end encryption on the protocol level - that would only leave the possibility of having a backdoor in the "official" WhatsApp client, but none has been found so far. BTW, people do actually (try to) decompile the WhatsApp client (or the WhatsApp Web client which implements the same protocol and functionality) and look what it is doing.

    For anyone really curious, it's not too difficult to hook into the WhatsApp Web client with your web browsers Javascript debugger and see what messages are sent.

  • It’s no secret that WhatsApp adopted Signal’s encryption protocol just before Meta acquired them, but since it’s all closed source we don’t know if they’ve changed anything since the announcement in 2016 that all forms of communications on WhatsApp are now encrypted and rolled out.

    There is an Open Source implementation of the WhatsApp protocol: yowsup

  • At least for memory usage the hypervisor wouldn't be able to tell the difference between memory merely used as cache vs. memory actually used by the software running on the machine (and OSes will usually just use any otherwise unused memory as cache, so you will likely see some inflated memory usage)

  • How do they actually get that information (particularly memory utilization)? Do they rely on their agent that's pre-installed (but can be uninstalled)? At least in their web interface it doesn't show any of that utilization for my instances (one is Ubuntu with their agent uninstalled and the other one is NetBSD).

  • I am actually using a OrangePiPC as:

    • WLAN access point (hostapd)
    • LTE Internet via a E3372 USB dongle
    • radio via DVB-T dongle/Internet
    • USB speakers for the radio
    • Bluetooth dongle to connect to Bluetooth-enabled speaker in another room
    • USB temperature sensor, motion sensors via GPIO
    • VoIP telephone with connected USB headset
    • small LCD display to show the current temperature and incoming call information
  • Did a bit more digging through the mailing list (also looking through the links posted on the HN thread), and to me it looks a bit weird.

    OP came up with an initial patch (Wed, Jun 1, 2022 at 12:36 PM) that wasn't deemed to be good enough to be merged. Maintainer came up with a different patch (Tue, 7 Jun 2022 00:34:56 +1000) saying "but I wanted to fix it differently". OP then posted a reworked patch (Fri Jun 10 17:15:49 AEST 2022) that looks a lot more similar to the maintainer's patch.

    The maintainer's patch and OP's reworked patch look quite similar, but from what I can see from the mailing list, the maintainer actually came up with that approach, and OP didn't then credit the maintainer in his reworked patch. @kairos@programming.dev can you please clarify, what am I missing?

  • I am not really seeing any toxic behaviour here.

    OP's patch was largely based on code in ptrace32.c, but that code actually looks quite bad. So maintainer applied a better fix. Maybe ptrace32.c should be updated to use code that's more similar to ptrace-fpu.c now?