If his was really true for banks there would be a large number of bankers in jail. This number being close to zero, I guess the courts are very lax at charging bankers for crimes.
Banks are a terrible example for this thread's argument. Banking is essentially the end result of what happens when businesses kowtow to the invasive demands of the government, implement ever-more invasive content policing, becoming de facto arms of the bureaucratic state.
A bank will drop you if they even think you might be doing something (demonstrably on paper) illegal. When opening an account, some of the very first questions a bank asks you are "where did you get this money" and "what do you do for work" - proactively making you responsible for committing to some type of story. All of the illegality you're trying to reference is happening under a backdrop of reams of paperwork that make it look like above board activity to compliance departments. Without that paperwork when shit does hit the fan, people working at the bank do tend to go to jail. But with that paperwork it's "nobody's fault" unless they manage to find a few bank employees to pin it on.
Needless to say, this type of prior restraint regime being applied to free-form communication would be an abject catastrophe.
Banks do a massive amount of tracking and flagging. Even putting a joke “for drugs” in a Venmo field can cause issues. Plus reporting large transactions. There was a massive post on HN yesterday about how often banks close startup accounts due to false positives.
> the real criminals continue doing their business everyday
Any source for that? Media loves to blame banks for everything, but when you go into the details it always seems pretty marginal (e.g. the HSBC Mexico stuff).
It cannot be marginal because drug traffic, just as an example, moves billions of dollars every year. They certainly have schemes and someone in the banking system must be complying with these schemes. Every time the officials uncover one of these schemes, banks are miraculously not charged of anything and they don't even give back the profits of the illegal operation.
If you provide a service that is used for illegal behavior AND you know it’s being used that way AND you explicitly market your services to users behaving illegally AND the majority of your product is used for illegal deeds THEN you’re gonna have a bad time.
If one out of ten thousand people use your product for illegal deeds you’re fine. If it’s 9 out of 10 you probably aren’t.
> If one out of ten thousand people use your product for illegal deeds you’re fine.
This logic clearly makes the prison of someone like the owner of Telegram difficult to justify, since 99.999% of messages in telegram are completely legal.
If 10,000 people out of 10 million are doing illegal things and you know about it or you are going out of your way to turn a blind eye then you’re gonna have a bad time.
Keep in mind that as soon as you store user accounts you keep user data, which is perhaps a trivial form of eavesdropping, but clearly something law enforcement takes an interest in.
Two different implementations might make two different local times out of that, e.g. due to not being aware of changing DST/timezone policies. Hence the recommendation of separating between user/clock/calendar time (which must be exact to a human) and absolute/relative timestamps (which must be exact to a computer).
Also, ads. I guess the shorter the time is between clicking the play button and the ad starting, the more people will have "seen" more of the ad before deciding that the video isn't worth watching the ad.
So the Debian maintainer complains about the upstream project (which they decided to maintain the package for) bringing "crap" and having "utterly misguided" development? And somehow people say that this is the reasonable person here, basing a major change of a software's featureset on such an opinion?
Independent from whether the original change is good or bad, so much of what's wrong with Open Source is people trying to work against each other instead of together...
what leads you to suspect he's wrong? from the quotes in your comment i suspect it's his choice to use plain language and openly disagree with others. in my experience that's how trustworthy, competent people talk
people working together successfully in free software doesn't depend on them having the same values or getting along or wanting the software to do the same thing. it just depends on being clear and open about what the software does and doesn't do, and using licenses that keep them from suing you for distributing versions without their preferred features or antifeatures. remember that this is the movement that not only includes richard stallman but was founded by him. if it depended on getting along it never would have left the cradle
I suspect he's wrong because he's disabled some of KeepassXC's most important security features.
One of the largest security threats to users is phishing websites, getting an email and clicking a link, and then typing your actual password into some fake hacker's webpage.
Having browser integration in your password manager, such that it auto-enters the right password on "real-bank.com", but doesn't enter it on "rel-bank.com", is a strong protection against phishing.
The maintainer disabled the browser integration for KeepassXC, which forces users to copy+paste passwords into webpage's password inputs, making them significantly more vulnerable to phishing.
Their fear-mongering about supply-chain attacks and bugs in more LoC is silly when compared to the very real threat of phishing attacks, which are way more prevalent and a way more severe threat.
I guess you missed the bits on Mastodon where the package maintainer simply didn’t bother reaching out to the upstream whatsoever because he was ‘too busy’ and would only do so over a particular IRC setup. That’s not competent or good faith maintenance.
Yeah, and out of that fear, people often use stacks that require vast amounts of knowledge to actually keep things working at all, at any scale. Kubernetes is the best example where I don't trust me to keep the wheels on because it's scalable.
Communities are moderated based on how good you feel there, if it's the most ad-friendly, how good everyone stays on-topic, or other mostly social & subjective criteria. Judicial systems aren't about any of those things.
Go uses the package name to retrieve the pagacke source - a package named github.com/example/whatever will be downloaded by basically cloning it with git & then checking out the specified version as a tag.
That's in itself a really simple system and doesn't rely on a single third party, but obviously comes with the ownership issue (unless when pinning a specific commit) - in my opinion a good compromise.
I don't really understand how "hosted" and "internal" go together here - does this mean that a) the devices I need certificates for must connect to your servers, and that b) your servers could theoretically sign certificates for devices which do not exist? If so, especially for the latter point, this IMO isn't really useful for any real-world application, as the most important things of a CA is control.
Yes, this is both "hosted" and "internal": we build & manage a CAs per org. It's a bit like having an instance of Let's Encrypt, but just for your org (or per environment). Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names. For example, even if a certificate was issued for gmail.com, it wouldn't be trusted by your clients.
We always build two-tier PKIs, which means your server certificates are issued by intermediate certificates, and those intermediates are issued by a root certificate. In the future, we will let users bring their own root certificate so that we never see your root key material, which you can keep safely in an HSM or KMS.
> Your clients will only trust the certs for your CA, and those CAs have constraints in place so that we could never issue a certificate outside of your set of configured DNS names.
Does this work in practice? I was under the impression that the extensions for restricting which domains a CA can use weren’t widely supported.
It does work, and we've found it to be about as well supported as SAN names, which is pretty extensive these days. It's just not commonly used by public CAs because the real value of these public CAs is that they can issue for any valid domain name, not a predefined set.
