RayJW

joined 2 years ago
[–] RayJW 12 points 2 days ago* (last edited 2 days ago)

I think at this point it should be pretty clear that Signal never had the goal of anonymity which is an orthogonal concept to privacy. While I would support sign-up without phone numbers, it doesn't address the same threat-model and there are many alternatives if anonymity is your goal.

But I want near-perfect privacy with usability, which Signal provides for me and all my contacts. Who cares if my government knows I use Signal, as long as they don't know who I talk to and what we talk about.

Edit: just saw your other response. What you want to achieve, is almost impossible. Even if Signal doesn't log who you talk to, like you assume, there are still methods to unmask this info. There are PoCs for things like timing attacks for notifications etc. which combined can narrow down the list of contacts significantly. But it seems like your threat-model doesn't align with Signal goals which means it's probably best for you to search an alternative instead of hating on Signal for not catering to your needs.

[–] RayJW 2 points 2 weeks ago (2 children)

Are you using GE-Proton? I had this issue when not using the stock Proton. Try switching to Proton 9 and try again.

[–] RayJW -1 points 1 month ago

I'm copying my other response since you both had the same issue with my statements:

As you said, if PFS can be disabled by enabling a feature on the receiving end it's by security practices not enabled, in the industry that's called a downgrade attack and considered very bad practice.

The blog post you linked, is the publicly revised version after they were called out by well known cryptographers for their handling. This was their original response to the researchers, again after the researchers disclosed the vulnerabilities to them and actively helped designing the new protocol, not just giving inspiration. This was their initial tweet: „There’s a new paper on Threema’s old communication protocol. Apparently, today’s academia forces researchers and even students to hopelessly oversell their findings“ which is long deleted, but I did read it while it was still up back then. I can't find a screenshot or anything at the moment, so if you want to call me a liar, go ahead but if you search for that quote you will find many citations.

Also, they claimed „old protocol“ but Ibex was still months from being deployed widespread, so that's another big downplay.

You mention Signals Desktop app issue, Threema claimed the attacks were unrealistic because they require significant computing power or social engineering, both things that are definitely a risk if you're trying to protect yourself from bigger intelligence efforts. The issue with Signal Desktop however, required full file system access to your device at which point, there is nothing stopping the attacker from simply using a key logger, capturing your screen, etc.

This is why no big security researchers called out Signal but many shunned Threema. At the end I don't have a horse in the race for either of them, but I think those are facts people need when making a decision with their private information.

[–] RayJW 1 points 1 month ago (1 children)

As you said, if PFS can be disabled by enabling a feature on the receiving end it's by security practices not enabled, in the industry that's called a downgrade attack and considered very bad practice.

The blog post you linked, is the publicly revised version after they were called out by well known cryptographers for their handling. This was their original response to the researchers, again after the researchers disclosed the vulnerabilities to them and actively helped designing the new protocol, not just giving inspiration. This was their initial tweet: „There’s a new paper on Threema’s old communication protocol. Apparently, today’s academia forces researchers and even students to hopelessly oversell their findings“ which is long deleted, but I did read it while it was still up back then. I can't find a screenshot or anything at the moment, so if you want to call me a liar, go ahead but if you search for that quote you will find many citations.

Also, they claimed „old protocol“ but Ibex was still months from being deployed widespread, so that's another big downplay.

You mention Signals Desktop app issue, Threema claimed the attacks were unrealistic because they require significant computing power or social engineering, both things that are definitely a risk if you're trying to protect yourself from bigger intelligence efforts. The issue with Signal Desktop however, required full file system access to your device at which point, there is nothing stopping the attacker from simply using a key logger, capturing your screen, etc.

This is why no big security researchers called out Signal but many shunned Threema. At the end I don't have a horse in the race for either of them, but I think those are facts people need when making a decision with their private information.

[–] RayJW 0 points 1 month ago (5 children)

If you're seriously concerned about privacy and security I wouldn't look at Threema. They severely mishandled vulnerabilities by insulting the security researchers, then introduced a new protocol they built with the advice given to them for free from the SAME researchers before that, and yet it still doesn't support critical features like full forward secrecy. If all you want primarily is the best security out there Signal is and will be the best for a long time to come by the looks of it.

[–] RayJW 5 points 2 months ago (2 children)

Yea no, CarPlay is definitely supported and works fine on my end. Not sure, any iOS updates perhaps or anything of the sorts? The app shows fine in the customisation menu, but did you ever connect to the car since installing it? I have no idea if the apps maybe only show up once they were „initialised“ for that car.

[–] RayJW 2 points 3 months ago (1 children)

My understanding is, that the 1.0 spec for the extension was basically finalized in 2021 and CPUs using it are already available. Now it's just fully ratified. Also, while it might seem like RISC-V is “behind” compared to AVX-512 for x86_64 or SVE for ARM, this fundamentally differs from these SIMD Instructions. They talk more about it in this article SIMD Instructions Considered Harmful. So, this is not merely RISC-V playing catch-up, but also trying a “new” (the idea is actually old and how things used to be done) ways to make a more sustainable ISA.

3
submitted 3 months ago* (last edited 3 months ago) by RayJW to c/[email protected]
 

Crossposted from https://lemmy.ml/post/21673583

RISC-V International, the global standards organization, today announced that the RVA23 Profile is now ratified. RVA Profiles align implementations of RISC-V 64-bit application processors that will run rich operating systems (OS) stacks from standard binary OS distributions. RVA Profiles are essential to software portability across many hardware implementations and help to avoid vendor lock-in. The newly ratified RVA23 Profile is a major release for the RISC-V software ecosystem and will help accelerate widespread implementation among toolchains and operating systems.

Each Profile specifies which ISA features are mandatory or optional, providing a common target for software developers. Mandatory extensions can be assumed to be present, and optional extensions can be discovered at runtime and leveraged by optimized middleware, libraries, and applications.

Key Components of RVA23 Include:

  • Vector Extension: The Vector extension accelerates math-intensive workloads, including AI/ML, cryptography, and compression / decompression. Vector extensions yield better performance in mobile and computing applications with RVA23 as the baseline requirement for the Android RISC-V ABI.
  • Hypervisor Extension: The Hypervisor extension will enable virtualization for enterprise workloads in both on-premises server and cloud computing applications. This will accelerate the development of RISC-V-based enterprise hardware, operating systems, and software workloads. The Hypervisor extension will also provide better security for mobile applications by separating secure and non-secure components.
 

Crossposted from https://lemmy.ml/post/21673583

RISC-V International, the global standards organization, today announced that the RVA23 Profile is now ratified. RVA Profiles align implementations of RISC-V 64-bit application processors that will run rich operating systems (OS) stacks from standard binary OS distributions. RVA Profiles are essential to software portability across many hardware implementations and help to avoid vendor lock-in. The newly ratified RVA23 Profile is a major release for the RISC-V software ecosystem and will help accelerate widespread implementation among toolchains and operating systems.

Each Profile specifies which ISA features are mandatory or optional, providing a common target for software developers. Mandatory extensions can be assumed to be present, and optional extensions can be discovered at runtime and leveraged by optimized middleware, libraries, and applications.

Key Components of RVA23 Include:

  • Vector Extension: The Vector extension accelerates math-intensive workloads, including AI/ML, cryptography, and compression / decompression. Vector extensions yield better performance in mobile and computing applications with RVA23 as the baseline requirement for the Android RISC-V ABI.
  • Hypervisor Extension: The Hypervisor extension will enable virtualization for enterprise workloads in both on-premises server and cloud computing applications. This will accelerate the development of RISC-V-based enterprise hardware, operating systems, and software workloads. The Hypervisor extension will also provide better security for mobile applications by separating secure and non-secure components.
[–] RayJW 4 points 3 months ago

I'm not sure that Proton can fix your problem. However, I feel like this project would love your help with capturing the USB traffic to get it supported and hopefully upstreamed in the kernel some day :)

[–] RayJW 22 points 3 months ago (3 children)

That's why Tenacity is here to save the day!

[–] RayJW 1 points 4 months ago

Great, that sounds amazing. Let's hope it's also used even if it means less excises for tracking.

[–] RayJW 8 points 4 months ago (2 children)

Could the new CHIPS functionality help websites like Microsoft Teams working without you having to enable third-party cookies for their websites? If I understood it correctly this might be exactly the kinda use case but I couldn't find anything specific online.

7
submitted 4 months ago* (last edited 4 months ago) by RayJW to c/[email protected]
 

I have an issue on my Lenovo Laptop where the Lenovo Active Pen 2 under Arch / CachyOS with GNOME on Wayland always recognises the eraser as pressed. While this is probably a libinput issue, I can’t wait for possibly months to get a fix on that side. While I will report this issue to them, I would like to fix the problem intermediately.

This was never a problem under Fedora with GNOME on Wayland. I think the problem might be that libinput on Arch loads the Wacom driver, while Fedora probably just fell back to the generic libinput driver. I got that idea because in GNOME settings my screen now is configurable in the Wacom settings, that never was the case on Fedora.

I stumbled across this thread, however, that is not viable in Wayland any more since there is no config file available for libinput. Is there any way I can force the libinput driver for the “Wacom HID 52C2 Pen” device under Wayland, while GNOME is not specifically exposing this setting?

Any pointers would be greatly appreciated :)

Edit: Scratch all that, I just tried the live ISO for Fedora 41 and found out it's not related to Arch. After some trial, it seems like this might actually be an issue with the 6.11 Kernel. After downgrading to 6.10.10 everything works fine again. I guess my new question is now where would I report this? Is this still a libinput or a Kernel upstream issue?

 

I finally did it and got an used RX 6950 XT to replace my GTX 1080 Ti. I've been using this card ever since I moved to Linux and now I'm wondering what exactly I have to do. On Windows it's mostly run DDU and install the new AMD drivers, everything else will probably work the same with Afterburner etc.

However, on Linux the only things I know are uninstalling the Nvidia drivers, removing GWE since that obviously won't work and installing Mesa.

What other steps do people recommend? I'm hyped to finally get properly working GPU acceleration in Firefox and other things like Steam, but is there anything I have to do to get that running? Also what tools are currently a must with an AMD card for some undervolting / overclocking and other functionality y'all can recommend?

3
submitted 2 years ago* (last edited 2 years ago) by RayJW to c/[email protected]
 

Hello everybody

Here's hoping I can find an answer on the Fediverse, since I refuse to provide content to Reddit.

I have this issue on my Fedora install, that the boot screen where I enter my disk encryption password doesn't show up. It's not a big deal, because if I press Esc I can still see the text mode to enter my password, but it's still odd since it has been like that for a few months, where I had the same issue with an old fresh install and another fresh installation after switching drives. I couldn't find anything on the internet except that one forum entry from a few years back, but apparently an update fixed that issue.

Any ideas what could be at fault here?

view more: next ›