lemmy_in

And then, because you were never in a classroom and never took a class on security, you probably have no idea what a buffer overflow attack is or how to use tools like valgrind to check for them.

Then you put your C code on the internet and get your server pwned inside of an hour.

Slightly hyperbolic? Yes definitely. But there is a reason we don't teach C to beginners anymore. Generally you want them to understand the mindset of coding before throwing them in the deep end. And I would bet nothing has caused more people to quit programming then Segmentation fault: core dumped

The number is real you guys

For small apps, generating it in the backend, trying to insert it, and then catching the exception should be totally fine. The odds of collision are quite small.

You could also just use a random non-numeric primary key. For example you could generate a string of 8 random characters + numbers. That would give you well over 2 billion possible IDs.

That mismatch between DMARC verification domain and the domain of the "from" header is called DMARC Alignment. Any modern spam filter is going to mark unaligned messages as spam. Especially if one of the domains is completely non-routable like .onion.

And even if you sent the email and it got through with your .onion address, no one would be able to reply to you because the replying mail server can't even look up the MX record for your .onion domain.

TL;DR you can send emails from .onion addresses if you want, but no clearnet server is going to accept them.

So when you send an email, you can actually put whatever you want in the from header. I could send an email that says from "made.this.up@website.doesnotexist". The protocol doesn't care.

Do you know who does care? The email server you're sending messages to, because spammers and scammers love to try and send email with fake from addresses.

So, there's an entire verification system in place that involves looking up public keys from the website that the email claims to be from. (this is a gross over simplification. Look up SPF, DKIM, and DMARC for more info). The problem is you can't even reach .onion sites from the clearnet to do the lookups. So no email servers would be able to validate your address is legitimate and so would drop it as spam.

The OMNY system in NY doesn't require you to install an app on your phone. It's tap to pay with any credit or debit card, even apple or Google pay. If you want you can still get a physical OMNY card and refill it, but it's not required.

Sounds like a skill issue on the author's part tbh.

Also fuck physical checks, online payments are 100x better. Writing all of your baking information on a slip of paper and handing it to someone is probably the least secure way to transfer money.

What a brain-dead take. If your threshold for true safety is "literally no one can force you to decrypt it or affect the system in any way" then of course it's insecure, and so is everything else unless everyone writes their own crypto implementation yourself locally.

"oh I compile my binaries from source so I'm safe"

Someone could compromise the source repo and have it serve a compromised version to your machine. I guarantee you aren't reading the entirety of the open SSL source code before you compile it.

Anyone that takes this article seriously should read On Trusting Trust. It's a very short essay that states the point much more eloquently than the post author that you eventually have to trust someone. Whether that's Apple or Signal or some random maintainer of your crypto implementation library, you have to trust someone that it hasn't been backdoored.

Jetbrains Phpstorm is probably best in class, but you'll have to pay for it.

None of these words are in the Bible

It's perfectly normal for your computer to have daemons.

"I learned participant observation from watching you" is such a phenomenal line