You are conflating the concept and the implementation. PFS is a feature of network protocols, and they are a frequently cited example, but they are not part of the definition. From your second link, the definition is:

Perfect forward secrecy (PFS for short) refers to the property of key-exchange protocols (Key Exchange) by which the exposure of long-term keying material, used in the protocol to authenticate and negotiate session keys, does not compromise the secrecy of session keys established before the exposure.

And your third link:

Forward secrecy (FS): a key management scheme ensures forward secrecy if an adversary that corrupts (by a node compromise) a set of keys at some generations j and prior to generation i, where 1 ≤ j < i, is not able to use these keys to compute a usable key at a generation k where k ≥ i.

Neither of these mention networks, only protocols/schemes, which are concepts. Cryptography exists outside networks, and outside computer science (even if that is where it finds the most use).

Funnily enough, these two definitions (which I’ll remind you, come from the links you provided) are directly contradictory. The first describes protecting information “before the exposure” (i.e. past messages), while the second says a compromise at j cannot be used to compromise k, where k is strictly greater than j (i.e. a future message). So much for the hard and fast definition from “professional cryptographers.”

Now, what you’ve described with matrix sounds like it is having a client send old messages to the server, which are then sent to another client. The fact the content is old is irrelevant - the content is sent in new messages, using new sessions, with new keys. This is different from what I described, about a new client downloading old messages (encrypted with the original key) from the server. In any case, both of these scenarios create an attack vector through which an adversary can get all of your old messages, which, whether you believe violates PFS by your chosen definition or not, does defeat its purpose (perhaps you prefer this phrasing to “break” or “breach”).

This seems to align with what you said in your first response, that Signal’s goal is to “limit privacy leaks,” which I agree with. I’m not sure why we’ve gotten so hung up on semantics.

I wasn’t going to address this, but since you brought it up twice, running a forum is not much of a credential. Anyone can start a forum. There are forums for vaxxers and forums for antivaxxers, forums for atheists and forums for believers, forums for vegans and forums for carnivores. Not everyone running these forums is an expert, and necessarily, not all of them are “right.” This isn’t to say you don’t have any knowledge of the subject matter, only that running a forum isn’t proof you do.

If you’d like to reply, you may have the last word.

I would argue that it is not limited to network traffic, it is the general concept that historical information is not compromised, even if current (including long-term) secrets are compromised.

From my comment earlier:

There is no sharing of messages between linked devices - that would break forward secrecy

This describes devices linked to an account, where each is retrieving messages from the server - not a point-to-point transfer, which is how data is transferred from one Android device to another. If a new device could retrieve and decrypt old messages on the server, that would be a breach of the forward security concept.

From http://support.signal.org/hc/en-us/articles/360007059752-Backup-and-Restore-Messages#desktop_restore:

Signal Desktop does not support transferring message history to or from any device.

You’re describing something very different - you already have the messages, and you already have them decrypted. You can transfer them without the keys. If someone gets your device, they have them, too.

Whether Signal keeps the encrypted the messages or not, a new device has no way of getting the old messages from the server.

“They” is the browser/browser maker. The browser, acting as the client, would have access to the keys and data. The browser maker could do whatever they want with it.

To be clear, I’m not saying they would, only that it defeats the purpose of an E2E chat, where your goal is to minimize/eliminate the possibility of snooping.

Using an E2E chat app in your browser necessarily makes the keys and decrypted messages available to your browser. They would have the ability to read messages, impersonate users, alter messages, etc. It would defeat the purpose of a secure messaging platform.

There is no sharing of messages between linked devices - that would break forward secrecy, which prevents a successful attacker from getting historical messages. See the first bullet of: https://support.signal.org/hc/en-us/articles/360007320551-Linked-Devices

Messages are encrypted per device, not per user (https://signal.org/docs/specifications/sesame/), and forward secrecy is preserved (https://en.m.wikipedia.org/wiki/Forward_secrecy, for the concept in general, and https://signal.org/docs/specifications/doubleratchet/ for Signal’s specific approach).

Yes, as long as you set up the desktop client before sending the message.

Messages sent with Signal are encrypted per device, not per user, so if your desktop client doesn’t exist when the message is sent, it is never encrypted and sent for that device.

When you set up a new client, you will only see new messages.

See https://signal.org/docs/specifications/sesame/ for details.

This is not entirely correct. Messages are stored on their servers temporarily (last I saw, for up to 30 days), so that even if your device is offline for a while, you still get all your messages.

In theory, you could have messages waiting in your queue for device A, when you add device B, but device B will still not get the messages, even though the encrypted message is still on their servers.

This is because messages are encrypted per device, rather than per user. So if you have a friend who uses a phone and computer, and you also use a phone and computer, the client sending the message encrypts it three times, and sends each encrypted copy to the server. Each client then pulls its copy, and decrypts it. If a device does not exist when the message is encrypted and sent, it is never encrypted for that device, so that new device cannot pull the message down and decrypt it.

For more details: https://signal.org/docs/specifications/sesame/

For what it’s worth, I just bought a TCL 55S450F (55 inch 4K HDR FireTV) specifically because it does not ever need an internet connection to function (expressly stated in the manual). It is currently on Amazon for $268 (they have other sizes at other prices). It’s a great TV, considering the price. The only real drawback for me is the remote is Bluetooth, rather than infrared (less compatible with universal remotes).

Note that for full dumb TV effect, you’ll want to go into the settings and tell it to resume the last input, rather than going to the home screen when you turn it on (without connecting it to the Internet, the home screen is basically just a big banner telling you it’s not connected, and when you dismiss that, it just allows you to access inputs and manage settings).

You are falling into a common trap. LLMs do not have understanding - asking it to do things like convert dates and put them on a number line may yield correct results sometimes, but since the LLM does not understand what it’s doing, it may “hallucinate” dates that look correct, but don’t actually align with the source.

Not sure what landscape features you’re looking for, but I’ve been pretty happy with Voyager. I switched from liftoff/jerboa after lemmy.ml took the 0.19 update and they broke. It’s been good enough that I think even if the others hadn’t broken, I’d still choose Voyager over them.

grep -r string .

The flag should go before the pattern.

-r to search recursively, . refers to the current directory.

Why use . instead of *? Because on it’s own, * will (typically) not match hidden files. See the last paragraph of the ‘Origin’ section of: https://en.m.wikipedia.org/wiki/Glob_(programming). Technically your ls command (lacking the -a) flag would also skip hidden files, but since your comment mentions finding the string in ‘any files,’ I figured hidden files should also be covered (the find commands listed would also find the hidden files).

EDIT: Should have mentioned that -R is also recursive, but will follow symlinks, where -r will ignore them.

Brother from Another Series, featuring Kelsey Grammer as Sideshow Bob, and David Hyde Pierce as his brother, Sideshow Cecil (Fraser and Niles Crane, respectively). Bob, out on parole, teams up with Bart and Lisa to thwart Cecil’s plan to blow up a dam, and flood the town.

The pie in the face gag is only funny when the guy’s got dignity.

You can actually sign the F-Droid app yourself, if you use reproducible builds.

There’s reasonable odds the signatures still won’t match though, because Google requires App Bundles now, and then they build and sign the APK, rather than allowing the developer to build and sign their own APK.

Technically you can use the same key (see “Best Practices” of this page), but it’s kind of shady, and requires giving your private key to Google.

I have no personal experience with this company, but I’ve followed them for a few years. I was initially very interested in their laptops, but was also very excited when the phone was announced. In the years since the phone was announced, I’ve heard and read many negative things about build quality and software on their laptops, and I’ve seen the shipment of the phones get repeatedly delayed. More recently, https://youtu.be/wKegmu0V75s showed up in my feed. I would recommend anyone considering purchasing from them watch that video, and do a little research into their security/openess claims, as well as customer satisfaction.

Again, I don’t have the personal experience to say they are bad in anyway, but I don’t want to see anyone get scammed, so I would recommend healthy skepticism and due diligence before making a purchase.

I would imagine the source for most projects is hosted on GitHub, or similar platforms? Perhaps you could consider forks, stars, and followers as “votes” and sort each sub category based on the votes. I would imagine that would be scriptable - the script could be included in the awesome list repo, and run periodically. It would be kind of interesting to tag “releases” and see how the sort order changes over time. If you wanted to get fancy, the sorting could probably happen as part of a CI task.

If workable, the obvious benefit is you don’t have to exclude anything for subjective reasons, but it’s easier for readers of the list to quickly find the “most used” options.

Just an idea off the top of my head. You may have already thought about it, and/or it may be full of holes.