I'm currently comparing it with pangolin and headscale for my small scale company infrastructure access. Been running headscale for my own setup for a while but maybe netbird or pangolin might be better for real production.
Pangolin recently added desktop clients for win/mac/linux[0] and the Private Resource feature (similar to Netbird's Network Routes/DNS), so it's starting to overlap with Netbird more and more.
That said, it seems focused on client-to-site (newt) connections, and I don't see support for client-to-client connections like Netbird’s SSH access. Also, their Private Resources don't seem to support TLS termination yet. (Correct me if I’m wrong!)
In my case, I have a k3s cluster running on Netbird with a Traefik ingress for TLS termination inside my home network. Thanks to netbird's P2P nature, traffic stays entirely local as long as I'm on my home WiFi. (I suppose one could achieve the same with a Netbird + Caddy + DNS-01 setup, too.)
I am in the same position but currently using Tailscale and realize how important and critical it has become for my whole family infrastructure. A self-hosted solution which allowed me to use Nameservers and TLS termination as I currently do would be awesome.
Could you get charged with destroying evidence if you provided the duress password wiping the device when asked for a password ?
You technically followed orders and didn't even touch the device.
Yes, that would be "spoliation of evidence" and probably "obstruction of justice". Also, I believe duress passwords are only a "thing" on GrapheneOS, not iOS or stock Android.
If what you are being charged with carries a larger penalty than simple perjury or destruction of evidence, it makes complete sense to do techniques such as this. Perjury is one of the harder and least prosecuted charges in the USA.
An example from people that I know who have gone through the corrupt courts more than once said the feedback from the last case was the prosecutor felt like a fish flopping outside of water.
The court stands no chance when someone uses techniques that require the government agencies to use their secret programs and tactics. They will rather drop and lose the case. Most of the time they are also extremely incompetent when it comes to technology and have to hire many outside consultants, which gives you more chances to fight. An easy win for the citizen.
Email is the prime example of federated communication. From protocol inception to painful expansion and aging protocol all until corporate apropriaton. But I still think federation is the way forward, absolute centralisation is bad I'll let you figure why, but absolute decentralization is also bad, limitations due to its nature, unusual working for most users... Meanwhile federation is right in the middle, and users already use it with email without even noticing!
Email is by far the least secure form of communication in common use right now. It's trivial to impersonate others over email, and every MTA that processes your email has access to the full contents, because they are never encrypted except in flight (and except by a few tiny disparate groups using PGP, and even these groups can't authenticate one another). And not for lack of trying, I should add.
Comes across as an ad hominem. Email is insecure due to being dated, having a massive amount of inertia, and being essentially impossible to upgrade in the necessary ways without breaking backwards compatibility. None of that has anything to do with federation vs p2p vs centralization.
If you want a fair comparison for reasoning about security related challenges and tradeoffs you should probably go with matrix.
I don't agree with this at all. There are fundamental tradeoffs, and the reason no one has added e2e encryption to email, while we did add it to the web, is not because of backwards compatibility, it's because there was no compelling solution to some of these trade-offs.
Matrix simply doesn't solve some of the problems that email solves, or at least not in an e2e encrypted manner. For example, I can't send a document to a public institution's Matrix account, not in a manner that either (a) isn't e2e encrypted with no realistic risk of a MITM, or (b) doesn't require an out-of-band pre-approval, such as someone from the institution adding my account to some encrypted room.
Also, even if Matrix did find a way to make it easy to send e2e encrypted data to someone else without out-of-band communication, it would then suffer from the problem of spam. Every client would have to filter all incoming messages for spam, instead of being able to centralize this work at the server level.
Doesn't the spam filtering complaint apply in equal measure to _any_ E2EE messaging solution? Signal can't implement content based filtering either.
Out of band confirmation is similarly universal unless you're okay with either TOFU or delegation. (Delegation being recursively subject to the same choice.) TLS on the web goes with delegation and a root certificate store obviously.
My point being that none of this is specific to either email or federation more generally.
Even the web suffers from problems of trust to some extent, with the PKI being a huge vulnerability and relying on the collective action of all browser vendors to act as a check on any CA trying to break the agreed guarantees. But in a world where you would have a hundred, or even 20, different popular browsers, with different geopolitical assignments, it would be far harder to punish a CA that decided to sign certificates improperly, e.g. to allow some government or criminal enterprise to MITM communication.
Establishing identity in a non-centralized manner, and without requiring a second, already secure, communication method than the one you're trying to authenticate, such as an in-person key exchange, is in fact impossible, not just hard. There are partial solutions, with different trade-offs, such as the PKI for the web, the TOFU with optional verification options used in Matrix or SSH, or the web-of-trust model of PGP.
People often mention email as an example of federated communication, but the way email works in practice doesn't entirely live up to that ideal. Good luck getting your own self-hosted email server to send emails that actually reach anyone using a major email provider; they'll just be blocked as spam.
In practice, email is much less federated than it seems. A significant proportion of people are just using gmail. You probably don't have to include that many providers to cover a majority of people in the US.
I think federation has promise, but federation in itself is not a solution. Technical approaches do not address the more fundamental issue that, regardless of the mechanics of the system, big players will have more influence on its operation and evolution. Thus we will always need sociopolitical mechanisms to restrict big players.
But in practice in doesn't always give you a choice, because the biggest providers will embrace and extend and start providing things other providers don't. Or they'll just make it difficult to export your data, etc.
French gov open source is a joke, single repo dump once from a zip file given by the contractor and then nothing. And that's when the source is provided, France Identité is closed source and Play Integrity dependent.
If there is a single policy change I could pick for public spending on IT it would be to forbid outsourcing to “contractors” and thinking of software delivery as “projects”
The "old" model is the best IMO. Sell the software once with like 1 year of updates, and then the user can keep their software at an old version or can pay some amount to get the new version / another year of updates. If you wanna make it look like a subscription ask for a fixed fee first and then a small amount every month but then you don't get to keep the software on unsubscribe (or if you really want to play nice allow to keep using "old" version after defined subscription time like a year or smth)
What it does really well is set expectations upfront:
you’re buying a version and a defined update window,
not an open-ended promise.
Where I think many products stumble is skipping that clarity
and retroactively redefining what users thought they bought.
If users know from day one:
“this includes X months of updates, after that you can keep using it or pay for more”,
most of the trust issues simply don’t exist.
Tried moving there something like a year ago, the service didn't work at all, iirc the UI was awful and confusing and once I got around it, there was a lot of my tracks that couldn't be imported. I hate that Spotify is the one service I still can't part with, self-hosting nextcloud emails and such.
reply