litchralee

The catch with everything that implements E2EE is that, at the end of the day, the humans at each end of the message have to decrypt the message to read it. And that process can leave trails, with the most sophisticated being variations of Van Eck phreaking (spying on a CRT monitor by detecting EM waves), and the least sophisticated being someone that glances over the person's shoulder and sees the messages on their phone.

In the middle would be cache files left on a phone or from a web browser, and these are the most damning because they will just be laying there, unknown, waiting to be discovered. Whereas the techniques above are active attacks, which require good timing to get even one message.

The other avenue is if anyone in the conversation has screenshots of the convo, or if they're old-school and actually print out each conversation into paper. Especially if they're an informant or want to catalog some blackmail for later use.

In short, opsec is hard to do 100% of the time. And it's the 1% of slip-ups that can give away the game.

Sadly, I'm not familiar enough with Nginx Proxy Manager to know. But I would imagine that there must be a different way to achieve the same result.

BTW, when I read "NPM", I first think of Node.JS Package Manager. The title of your post may be confusing, and you might consider editing it to spell out the name of Nginx Proxy Manager.

I'll take a stab at the question. But I'll need to lay some foundational background information.

When an adversarial network is blocking connections to the Signal servers, the Signal app will not function. Outbound messages will still be encrypted, but they can't be delivered to their intended destination. The remedy is to use a proxy, which is a server that isn't blocked by the adversarial network and which will act as a relay, forwarding all packets to the Signal servers. The proxy cannot decrypt any of the messages, and a malicious proxy is no worse than blocking access to the Signal servers directly. A Signal proxy specifically forwards only to/from the Signal servers; this is not an open proxy.

The Signal TLS Proxy repo contains a Docker Compose file, which will launch Nginx as a reverse proxy. When a Signal app connects to the proxy at port 80 or 443, the proxy will -- in the background -- open a connection to the Signal servers. That's basically all it does. They ostensibly wrote the proxy as a Docker Compose file, because that's fairly easy to set up for most people.

But now, in your situation, you already have a reverse proxy for your selfhosting stack. While you could run Signal's reverse proxy in the background and then have your main reverse proxy forward to that one, it would make more sense to configure your main reverse proxy to directly do what the Signal reverse proxy would do.

That is, when your main proxy sees one of the dozen subdomains for the Signal server, it should perform reverse proxying to those subdomains. Normally, for the rest of your self hosting arrangement, the reverse proxy would target some container that is running on your LAN. But in this specific case, the target is actually out on the public Internet. So the original connection comes in from the Internet, and the target is somewhere out there too. Your reverse proxy simply is a relay station.

There is nothing particularly special about Signal choosing to use Nginx in reverse proxy mode, in that repo. But it happens to be that you are already using Nginx Proxy Manager. So it's reasonable to try porting Signal's configuration file so that it runs natively with your Nginx Proxy Manager.

What happens if Signal updates that repo to include a new subdomain? Well, you wouldn't receive that update unless you specifically check for it. And then update your proxy configuration. So that's one downside.

But seeing as the Signal app demands port 80 and 443, and you already use those ports for your reverse proxy, there is no way to avoid programming your reverse proxy to know the dozen subdomains. Your main reverse proxy cannot send the packets to the Signal reverse proxy if your main proxy cannot even identify that traffic.

The simple answer is probably no, because even where those experts aren't driven solely by the pursuit of money -- as in, they might actually want to improve the state of the art, protect people from harm, prevent the encroachment of the surveillance state, etc... -- they are still only human. And that means they have only so much time on this blue earth. If they spend their time answering simple questions that could have been found on the first page of a web search, that's taking time away from other pursuits in the field.

Necessarily then, don't be surprised if some experts ask for a minimum consultation fee, as a way to weed out the trivial stuff. If nothing else, if their labor is to have any meaning at all when they do their work professionally, they must value it consistently as a non-zero quantity. Do not demand that people value their labor at zero.

With that out of the way, if you do have a question that can't be answered by searching existing literature or the web, then the next best is to ask in an informal forum, like here on Lemmy. Worst case is that no one else knows. But best case is that someone works in the field and is bored on their lunch break, so they'll help point you in the right direction. They may even connect you to a recognized expert, if the question is interesting enough.

Above all, what you absolutely must not do is something like emailing a public mailing list for cryptography experts, gathered to examine the requirements of internet security, to look at your handmade data encryption scheme, which is so faulty that it causes third-party embarrassment when read a decade later.

You were in fact lucky that they paid any attention at all to your proposal, and they've already given you many hundreds if not thousands of dollars worth of free consultancy between them

Don't be the person that causes someone to be have to write this.

There are separate criminal and civil offenses when it comes to copyright infringement, assuming USA. Very generally, under criminal law, it is an offense to distribute copyrighted material without the right or license to do so. Note the word "distribute", meaning that the crime relates to the act of copying and sharing the work, and usually does not include the receiving of such a work.

That is to say, it's generally understood that mere possession of a copyrighted work is not sufficient to prove that it was in your possession for the purpose of later distribution. A criminal prosecution would have to show that you did, in fact, infringe the copyright by distributing a copy to someone or somewhere else.

Separately, civil penalties can be sought by the copyright owner, against someone found either distributing their work, or possessing the work without a license. In this case, the copyright owner has to do the legwork to identify offenders, and then would file a civil lawsuit against them. The government is uninvolved with this, except to the extent that the court is a branch of the federal government. The penalty would be money damage, and while a judgement could be quite large -- due to the insanity of minimum damages, courtesy of the DMCA -- there is no prospect of jail time here.

So as an example, buying a bootleg DVD for $2 and keeping it in your house would not accrue criminal liability, although if police were searching your house -- which they can only do with a warrant, or your consent -- they could tip-off the copyright owner and you could later receive a civil lawsuit.

Likewise, downloading media using Megaupload, usually also doesn't meet the "distribution" requirement in criminal law, but still opens the door to civil liability if the copyright owner discovers it. However, something like BitTorrent which uploads to other peers, that would meet the distribution requirement.

To that end, if officers searching your home -- make sure to say that you don't consent to any searches -- find a running BitTorrent server and it's actively sharing copyrighted media, that's criminal and civil liability. But if they only find the media but can't find evidence of actual uploading/distributing, and can't get evidence from the ISP or anyone else, then the criminal case would be non-existent.

That said, in a bygone era, if multiple physical copies of the same copyrighted media were found in your house, such as officers finding a powered-off DVD copy machine that has sixty handwritten discs all labeled "Riven: The Sequel to Myst" next to it, then the criminal evidence is present. Prosecutors can likely convince a jury that you're the one who operated the machine to make those copies -- because you had the ability (the machine) -- and that nobody would make so many copies as personal backups. The quantity can only suggest an intent to distribute. This is not unlike how a huge amount of marijuana is chargeable as "possession with intent to distribute", although drug laws have a different type of illogical-ness.

This logic does not apply up when dealing with digital files, because computers naturally keep copies as part of handling files. A cache file temporarily created by VLC does not turn people into copyright criminals.

TL;DR: when the police are searching your house, tell them: 1) you do not consent to any searches, 2) you want a copy of their warrant, which should be signed by a judicial judge, and 3) do not volunteer info to the police; call and talk to a lawyer

Since that whole vibe-coded Cloudflare Matrix nonsense and associated attempted retcon -- see here for context -- I am looking forward to a talk on how Matrix actually works.

Specifically, I'd like to know what aspects of a secure, decentralized message platform are particularly hard. That's in the context of whether Matrix can ever grow into a bona fide Signal competitor (nb: Signal remains the gold standard), and also whether Matrix would function well as a Discord replacement, even if it doesn't have as strong of group chat privacy and encryption protections.

You might also consider !nostupidquestions@lemmy.world for general questions

There can be, although some parts may still need to be written in assembly (which is imperative, because that's ultimately what most CPUs do), for parts like a kernel's context switching logic. But C has similar restrictions, like how it is impossible to start a C function without initializing the stack. Exception: some CPUs (eg Cortex M) have a specialized mechanism to initialize the stack.

As for why C, it's a low-level language that maps well to most CPU's native assembly language. If instead we had stack-based CPUs -- eg Lisp Machines or a real Java Machine -- then we'd probably be using other languages to write an OS for those systems.

The other commenters correctly opined that encryption at rest should mean you could avoid encryption in memory.

But I wanted to expand on this:

I really don't see a way around this, to make the string searchable the hashing needs to be predictable.

I mean, there are probabilistic data structures, where something like a Bloom filter will produce one of two answers: definitely in the set, or possibly in the set. In the context of search tokens, if you had a Bloom filter, you could quickly assess if a message does not contain a search keyword, or if it might contain the keyword.

A suitably sized Bloom filter -- possibly different lengths based on the associated message size -- would provide search coverage for that message, at least until you have to actually access and decrypt the message to fully search it. But it's certainly a valid technique to get a quick, cursory result.

Though I think perhaps just having the messages in memory unencrypted would be easier, so long as that's not part of the attack space.

If this is about that period of human history where we had long-distance transportation (ie railroads) but didn't yet have mass communication infrastructure that isn't the postal service -- so 1830s to 1860s -- then I think the answer is to just plan to meet the other person at a certain place every month.

To use modern parlance, put a recurring meeting on their calendar.

It can be, although the example I've given where each counter is a discrete part is probably no longer the case. It's likely that larger ICs which encompass all the requisite functionality can do the job, at lower cost than individual parts.

But those ICs probably can't do 4:20:69, so I didn't bother mentioning that.

I have a UniFi EdgeRouter (old, and I'm looking into replacing it with a FreeBSD box) and I have a similar issue where the router -- but maybe the ISP? -- misses a DHCP renewal, resulting in the wholesale loss of connectivity. It's even more annoying because the ISP simultaneously rejects follow-up DHCP requests, on the theory that if the renewal was missed, the device cannot possibly exist anymore, at least for a few minutes.

Since this router takes 12 minutes to manually reboot, that's usually enough time for the ISP to clear their cache and everything comes back up properly. But it's terribly annoying, hence why I'm looking to finally replace this router.