ferngodfather

It's the semicolon and the phrasing together. I can't explain but after you use AI a little you just notice the way it 'writes'.

It's not about receiving spam, it's about legitimate messages you send getting filtered as spam.

> The domains didn't disappear; they moved.

I stopped reading at this point. I cannot emphasize how much I HATE this AI writing style.

Most countries have these no call lists but they are fairly useless as there is no enforcement.

I've even heard stories of some scammers exclusively using such lists, as they are pre-verified!

It's not "security theatre", it's blocking the absolute worst, most painfully obvious bots that. These bots also happen to account for a good 85% of bot traffic, so it makes sense to block them.

Yes, of course, if a real threat actor is doing things properly they'll be using residential proxies and legitimate user agents, but we're talking here about blocking "some of the bots" - mainly the script kiddies.

> Blanket IP range bans, in this day and age? Basically a proclamation of incompetence.

I disagree. If I'm getting problematic traffic from even a few of your IPs and they're in a DC/VPS range, I'm blocking it and moving on with my day.

But I suppose none of my clients services typically ever need to be accessible from such countries anyway.

That's fair enough.

I think it's a great article to be fair. We need more of this cheap and quick bot blocking. The fact the solution to unwanted traffic is often "use Cloudflare" is _not_ great for the internet, and nobody really actually likes deploying or managing ModSecurity. Its a nice middleground.

> Obvious proxy is obvious.

> if ($http_x_forwarded_for) {....

This may block schools and libraries that use content blockers. Often the internal client is left to make abuse tracking easier (or because the overworked admin didn't know they could turn it off).

It really depends on the term they're trying to rely on. We have the "red hand rule" in England and Wales that means that unusual and onerous terms will not be incorporated unless it can be expressly shown they were fairly brought to the parties attention.

That's a great idea. What do you use as your family password?

I had the exact same experience. Never used Facebook. Wanted to create a page for a product. Suspended. Did the face scan. Now they have my face and I'm still suspended. Absolute joke. Zuckerberg can go suck a fat one.

So much this. Everyone has their own idea of that the project should do and it's hard to explain that whilst that implementation is great for their specific use case, it's pretty shit for everyone else.

AI has just made this so much worse.

> My brain is melting because I can barely keep up with learning how to figure out if I'm even doing what I'm trying to do.

This is not a good thing. You should understand what your code does. Writing code nobody can understand is not a flex.

Except spellcheck is a reasonably foreseeable part of a word processor. An AI model isn't really a common component of a typical web browser.

We have bailii.org but it doesn't have everything.

And those staff mostly use Westlaw :)

There is also "this code is functionally fine but I absolutely hate it"

> and you fully understand the requirements that contacting “linux-distros” will impose on you

Imposing requirements on the reporter? No.

Fair play!

Your terms:

> You may not use automated tools to scrape, copy, or bulk-download data from our service.

Pot kettle, huh.

But then you just move the security issue elsewhere with more to secure. Now we have to think about securing the automation system, too.

This is the same argument I routinely have with client id/secret and username/password for SMTP. We're not really solving any major problem here, we're just pretending it's more secure because we're calling it a secret instead of a password.

Cloud providers have put a lot of time and effort into making you believe every web app needs 99.9999% availability. Making you pay for auto scaled compute, load balancers, shared storage, HA databases, etc, etc.

All of this just adds so much extra complexity. If I'm running Amazon.com then sure, but your average app is just fine on a single VM.

What I say: I want a pay rise.

What management hears: We want more pizza parties.

"Someone viewed your profile" with a blurred photo of them.

So you know exactly who it is, but you won't just tell me in the email? I have to open the app/site so you can tick your engagement box for the day?

So glad I'm off that shit hole. It's just full of pompous picks anyway.

> If I get a single email after I've unsubscribed I go back in my inbox and mark every single email I ever received as spam.

Fuck me, that is brutal and could absolutely ruin your SES complaint rate - even with the suppression filter on, as the emails are already in your inbox.

"Here's what AI came up with and it mostly worked the one time I tested it. Might need improving".

No. I don't want to test and pick through your shitty LLM generated code. If I wanted the entire code base to be junk, it'd say so in the readme.

I was in the same position as you when I started my law degree!

My solution was:

- Take notes on paper

- Scan with Genius Scan (free) or similar

- Upload to Microsoft Document Intelligence on Azure to get character recognition and a PDF output (standard OCR sucks for handwriting; also free for up to like 50 docs a month)

- Tidy up the text and store in Mediawiki long-term (you can also upload a copy of the OCR enabled PDF) (FOSS)

- File paper notes

- Throw paper notes once module is complete

So you always hold your nose?

Yep... Movie maker, Clippy, MSN Music, Encarta, Office accounting, Money, Response Point, hell TECHNET.

We have just stopped accepting PRs entirely for now. It's been utterly exhausting. We never got many PRs beforehand anyway so the uptick in entirely LLM written PRs was very noticeable.

We do continue to argue with LLM-submitted security disclosures. If these aren't an issue I just instant-close because debating with an LLM what is and isn't an issue is fucking painful.