RayJW

joined 2 years ago
[–] [email protected] 23 points 6 days ago* (last edited 6 days ago) (9 children)

I think Ghost might be the best option. They just launched their beta Fediverse integration a few days ago.

[–] [email protected] 26 points 1 month ago (2 children)

Better UX until you have to download or update a game… there is an open bug report where it just doesn't progress but keeps starting new processes until you‘re OOM. Still no fix in months, I've had to boot into Windows for every single update. Really not that good of an UX.

[–] [email protected] 48 points 1 month ago

MITM - Mouse in the Middle

[–] [email protected] 16 points 1 month ago

I think the most common alternatives I see recommended are Mullvad and IVPN. Both have a great track record, but also both lack port forwarding if that is an essential feature for you.

[–] [email protected] 3 points 2 months ago

A SOC that can’t handle more than 8GB of RAM?

Indeed, that's the same upper limit Raspberry Pi had until a few weeks ago and not really that unheard of for SBC chips like this :)

Sorry but that seems worthless to me when there are already raspberries, smartphones, other SOCs with 8GB.

None of those are RISC-V nor laptops, so I don't really see how the two compare? That's a bit like saying there's no use for family cars as we have planes now.

As for “recycled SBC”, well that’s expensive then.

Well, it does offer a lot more than just that. If you want an SBC, then great, get the SBC for cheaper. If you want a RISC-V laptop, well, good luck making one on your own with a cheap SBC for less. It's certainly doable! Just not really something every developer who would like to advance RISC-V wants to do.

I just don’t see the value in this.

Great, then the product is exactly as advertised and serving the market it's made for. I quote the blog post here:

This is very much a developer-focused board to help accelerate maturing the software ecosystem around RISC-V, so we recommend waiting for future RISC-V products if you’re looking for a consumer-ready experience.

[–] [email protected] 3 points 2 months ago (2 children)

This isn’t really a „just solder more of it“ situation. This is the absolute maximum amount this processor can support due to it’s bandwidth etc.

Remember, this is mostly about making a more or less recycled SBC more accessible for development work. If you want to do pretty much anything besides ensuring compatibility of your own software this is not for you.

[–] [email protected] 13 points 2 months ago* (last edited 2 months 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.

[–] [email protected] 3 points 2 months 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.

[–] [email protected] 0 points 4 months 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.

[–] [email protected] 2 points 4 months 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.

[–] [email protected] 1 points 4 months 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.

 

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.
7
submitted 6 months ago* (last edited 6 months ago) by [email protected] 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?

view more: next ›