it doesn’t unravel the underlying complexity of what it does… these alternative syntaxes tend to make some easy cases easy, but they have no idea what to do with more complicated cases

This can be said of any higher-level language, or API. There is always a cost to abstraction. Binary -> Assembly -> C -> Python. As you go up that chain, many things get easier, but some things become impossible. You always have the option to drop down, though, and these regex tools are no different. Software development, sysops, devops, etc are full of compromises like this.

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/

“Desktop publishing” is the category of software you want. I’ve not used it, but I believe Scribus is the standard FOSS tool for this. If you want a simple graphical way to make your album, this is the way.

Many people have metnioned LaTex - I would not recommend it for this purpose. LaTex, while powerful, will have a steep learning curve, and isn’t really made for artistic tasks - its purpose is for writing technical papers. From literally the first two sentences on the project site:

LaTeX is a high-quality typesetting system; it includes features designed for the production of technical and scientific documentation. LaTeX is the de facto standard for the communication and publication of scientific documents.

It’s probably possible to make a beautiful photo album with LaTex, but without a lot of work, it’s more likely to come out looking like a calculator manual.

Yeah, gadgetbtidge was my first thought as well. I’ve never used it, but in theory it would allow you to control devices without the proprietary app. See the link below for supported devices:

https://gadgetbridge.org/

If you’re ok with Jitsi, and you already use Brave, note that Jitsi is baked in. See https://brave.com/talk/ and check the “Who provides the Brave Talk service?” question:

The Brave Talk service is provided in partnership with 8x8. And the service is built on the open-source Jitsi platform.

(Note that 8x8 owns Jitsi)

See also the “How are my calls with Brave Talk encrypted?” question:

To start, all video and audio data transferred through Brave Talk is encrypted via transport layer encryption. This is similar to how many websites use HTTPS to ensure your traffic can’t be captured on public networks (e.g. coffee shop WiFi).

The video and audio from your call are transmitted to other participants with the help of a Video Bridge server that’s run by Brave’s partner, 8x8. When you enable Video Bridge Encryption in Security Options, your browser exchanges keys with other call participants, and these keys are used to encrypt the video and audio streams. Only people with keys can see your calls. Assuming honest but curious behavior, neither Brave nor its partner, 8x8, have this key by default.

However, there are some important limits to Video Bridge Encryption. If you want to include a phone participant in your call, have more than 20 participants, or want to include users with incompatible browsers (Safari, most iOS browsers, and browsers based on Chromium version 83 or below), this encryption setting will not work. If you record a call, 8x8’s servers will receive a set of keys to decrypt the video/audio stream in order to process and store that recording. Brave will continue to improve Brave Talk’s encryption properties and work to remove some of these limitations.

Read a more detailed description of Jitsi encryption (the open source basis for Brave Talk).

I noted in another comment that SearXNG can’t do anything about the trackers that your browser can’t do, and solving this at the browser level is a much better solution, because it protects you everywhere, rather than just on the search engine.

Routing over Tor is similar. Yes, you can route the search from your SearXNG instance to Google (or whatever upstream engine) over Tor, and hide your identity from Google. But then you click a link, and your IP connects to the IP of whatever site the results link to, and your ISP sees that. Knowing where you land can tell your ISP a lot about what you searched for. And the site you connected to knows your IP, so they get even more information - they know every action you took on the site, and everything you viewed. If you want to protect all of that, you should just use Tor on your computer, and protect every connection.

This is the same argument for using Signal vs WhatsApp - yes, in WhatsApp the conversation may be E2E encrypted, but the metadata about who you’re chatting with, for how long, etc is all still very valuable to Meta.

To reiterate/clarify what I’ve said elsewhere, I’m not making the case that people shouldn’t use SearXNG at all, only that their privacy claims are overstated, and if your goal is privacy, all the levels of security you would apply to SearXNG should be applied at your device level: Use a browser/extension to block trackers, use Tor to protect all your traffic, etc.

They are explicitly trying to move away from Google, and are looking for a new option because their current solution is forcing them to turn off ad-blocking. Sounds to me like they are looking for a private option. Plus, given the forum in which we are having the discussion (Lemmy), even if OP is not specifically concerned with privacy, it seems likely other users are.

As for cookies, searxng can’t do any more than your browser (possibly with extensions) can do, and relying on your browser here is a much better solution, because it protects you on all sites, rather than just on your chosen search engine.

“Trash mountain” results is a whole separate issue - you can certainly tune the results to your liking. But literally the second sentence of their GitHub headline is touting no tracking or profiling, so it seems worth bringing attention to the limitations, and that’s all I’m trying to do here.

You mean between their instance and the final search engines? Or between them and a public instance of searxng?

In either case, I’m not sure it buys you anything in terms of privacy you wouldn’t get by using the VPN and going directly to the search engines.

It looks like a few people are recommending this, so just a quick note in case people are unaware:

If you want to avoid being tracked, this is not a good solution. Searxng is a meta search engine, meaning it is effectively a proxy: you search on Searxng, it searches multiple sites and sends all the results back to you. If you use a public instance, you may be protected from the actual search engine*, because many people will use the same instance, and your queries will be mixed in with all of them. If you self host, however, all the searches will be your own - there is then no difference between using Searxng and just going to the site yourself.

*The caveat with using the public instances is while you may be protected from the upstream engine, you have to trust the admins - nothing stops them from tracking you themselves (or passing your data on).

Despite the claims in their docs, I would not consider this a privacy tool. If you are just looking for a good search engine, this may work, and it gives you flexibility and power to tune it yourself. But it’s probably not going to do anything good for your privacy, above and beyond what you can get from other meta search engines like Startpage and DuckDuckGo, or other “private” search engines like Brave.

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 went through this process for the first time recently. I opened the RFP issue, and got a response from Izzy very quickly. They were very helpful and responsive through the whole process. I was nervous it would be a slow tedious process when I started, but it turned out to be pretty quick and easy, largely thanks to Izzy’s help.

Worth noting, they support reproducible builds, which allows developers to sign with their own key:

https://f-droid.org/docs/Reproducible_Builds/

I would definitely recommend going this route if you’re starting with a new app. Having the binary on GitHub (or wherever you’d otherwise publish) match exactly the binary on F-Droid is really good for assuring people nothing in your repo was tampered with during the build process (i.e. that the binary was built from the public code, and nothing else).

It should not take extra work to do this. The project generated by Android Studio should already be reproducible. As long as you don’t change the build setup and break reproducibility yourself, it’ll “just work.” When you submit to F-Droid, just be sure to let them know you want to go the reproducible route (if you make the PR yourself, it’s a flag in the YAML file).