Full disk encryption is not a solution here. Any application that’s already running which can provide read only file system access to an attacker is not going to be affected by your full disk encryption.
that’s my point
Full disk encryption is not a solution here. Any application that’s already running which can provide read only file system access to an attacker is not going to be affected by your full disk encryption.
that’s my point
upon reading a bit how different wallets work, it seems macos is able to identify the program requesting the keychain access when it’s signed with a certificate - idk if that’s the case for signal desktop on mac, and I don’t know what happens if the program is not signed.
As for gnome-keyring, they ackowledge that doing it on Linux distros this is a much larger endeavor due to the attack surface:
An active attack is where the attacker can change something in your security context. In the context of gnome-keyring an active attacker would have access to your user session in some way. An active attacker might install an application on your computer, display a window, listen into the X events going to another window, read through your memory, snoop on you from a root account etc.
While it’d be nice for gnome-keyring to someday be hardened against active attacks originating from the user’s session, the reality is that the free software “desktop” today just isn’t architected with those things in mind. We need completion and integration things like the following. Kudos to the great folks working on parts of this stuff:
- Trusted X (for prompting) - Pervasive use of security contexts for different apps (SELinux, AppArmor) - Application signing (for ACLs)
We’re not against the goal of protecting against active attacks, but without hardening of the desktop in general, such efforts amount to security theater.
Also
An example of security theater is giving the illusion that somehow one application running in a security context (such as your user session) can keep information from another application running in the same security context.
In other words, the problem is beyond the scope of gnome-keyring. Maybe now with diffusion of Wayland and more sandboxing options reducing this context becomes viable.
let me just highlight that if someone has access only to your signal desktop conversations, they have access to your signal desktop conversations.
if someone has access to your windows recall db, they have access to your signal desktop conversations, the pages you’ve browsed including in private windows, documents you’ve written, games you’ve played, social media posts you’ve seen, and pretty much anything you’ve done using that machine.
perhaps that does demand a slightly different level of concern.
But that’s the thing: I haven’t found anything that indicates it can differentiate a legitimate access from a dubious one; at least not without asking the user to authorize it by providing a password and causing the extra inconvenience.
If the wallet asked the program itself for a secret - to verify the program was legit and not a malicious script - the program would still have the same problem of storing and retrieving that secret securely; which defeats the use of a secret manager.
The power of 21000 homes for advertising.
What’s most impressive is that it is even legal.
privacy != anonymity != security
The whole drama seems to be pushing for Electron’s safeStorage API, which uses a device’s secrets manager. But aren’t secrets stored there still accessible when the machine is unlocked anyway? I’m not sure what this change accomplishes other than encryption at rest with the device turned off - which is redundant if you’re using full disk encryption.
I don’t think they’re downplaying it, it just doesn’t seem to be this large security concern some people are making it to be.
This is like the third time in the past two months I’ve seen someone trying to spread FUD around Signal.
he does mention they “open source everything they do to make housing more attainable and more affordable” at 10:48
but I agree they need to put up a proper license
unless you’re reading ciphertext yourself, this doesn’t make sense
so it’s a concern for the company, not the users, you’re saying?
Exactly. At this point idk why anyone bothers migrating to things that are not backed by open standards. The price of vendor lock-in always comes.
don’t have to tell me that, I even donate to signal
“Without end-to-end encryption, huge numbers of vulnerable targets, and servers located in the UAE? Seems like that would be a security nightmare,” Matthew Green, a cryptography expert at Johns Hopkins University, told TechCrunch. (Telegram spokesperson Remi Vaughn disputed this, saying it has no data centers in the UAE.)
good job Remi, that was the main concern lmao
the same happens with BloomZ, and that is listed as open
neural network weights are just files, collections of numbers forming matrices; how is a partially open collection of weights of any use
the weights are open
$ docker exec -it ollama ollama show gemma:7b
Model
arch gemma
parameters 9B
quantization Q4_0
context length 8192
embedding length 3072
Parameters
stop "<start_of_turn>"
stop "<end_of_turn>"
penalize_newline false
repeat_penalty 1
License
Gemma Terms of Use
Last modified: February 21, 2024
how are the weights partially open?
130,000 units, I don’t know how
grabs popcorn
Well, what’s the problem. They have bacon and they have ice cr… oh I see the error now. Just add a generic response the ice cream machine is broken and move on!
it makes one wonder how well that works; if it’s based on OCR, does it “redact” the bounding box corresponding to the private window? What happens with overlapping windows; how does it handle windows with transparency; I can’t help to think there’s a high probability their solution is flaky.