jeroenhd

Because websites with almost no visitors are hit the hardest. A hundreds bots per minute hitting your server (if you host any kind of source code) versus one real visitor every other day is a great scenario to protect against.

The Russian government being stupid and evil isn't really Cloudflare's problem to solve. Neither is the lack of abuse prevention from VPN providers necessitating the extra challenges for VPN IP blocks. And, now that botnets are the norm, residential IP addresses too.

Obviously, Cloudflare's tools aren't the solution. The web needs to be closed down behind paid or real-identity accounts for websites to ditch these protections. It's only going to get worse from here.

I don't think carriers can be trusted per se, but if a carrier wants to interrupt your call, they can just kill the connection.

I've sent weird SMS messages through my (rooted) phone before. Silent SMS messages (useful for police trying to activate your phone for triangulation) still returned delivery reports a year or two ago, allowing someone to find out if someone else's phone is on without the target ever noticing.

I think Android removed the ability to send more annoying messages through its normal APIs (like flash SMS messages) but if you have access to any modem (either a smartphone or a full ESP32 dev board costing <50 bucks on AliExpress for 4G LTE), you can bypass any such restriction.

Carrier firewalls will probably filter these messages out but I wouldn't rely on it.

Google has clearly flagged this as "not a security issue", repeatedly. It's a weird bug for sure, but what's the scenario here?

Correct me if I'm wrong, but the carrier configuration messages can normally only come from carriers. The demo APK sends a message to the phone itself, but sending SMS messages requires special confirmation.

Practically speaking, what's the risk?

Phones take APN configuration through special kinds of SMS messages. This isn't just about routers.

Xe Iaso's blog posts poking fun at C(++) titled '"No way to prevent this" say users of only language where this regularly happens' has been quite busy this month.

Getting rid of C isn't the holy grail it might appear to be (Ubuntu has been working hard at rewriting sudo and coreutils in Rust and they have had plenty of bugs in the process), but I do hope the C projects will preemptively start fuzzing/running fil-C/invent new safety mechanisms for old code.

The integer overflow issue is only part of the problem. There are a couple underlying issues that make this exploit feasible: certain regexes produce extremely long bytecode, the integer overflow issue, and finally, a double free.

Rust will not protect you against exploding regexes, it will not protect you against integer over/underflows (unless you specifically call safe wrapping methods), but it will protect you against double frees if you use it sensibly (nothing prevents you from breaking the borrow checker and messing up memory if you write an unsafe {} block).

I see, I must've misremembered. It doesn't work anymore is all I know now.

Should be fixed now :)

The magic string was in the news but I'm pretty sure it's a hoax. When I tested it, it created enough of a "the input doesn't want to be processed" vibe to make the LLMs throw up rejections. I doubt Anthropic ever encoded it into their models.

I don't think that works anymore and I don't think the "special instruction" works either. Can't blame a guy for trying! I'm getting "helpful" spam from every place my email is posted (git is a common one) so I might as well try to get the bots out.

Don't think posting bioweapon recipes or bomb building instructions would go down with the moderation team, though.

Some of their examples are absolutely ridiculous, for sure. The lack of a fold-back design, like the surface, with pencil support is also a surprise to me. I suppose they'd still rather sell you an iPad with an operating system they don't let you control rather than bringing their laptop segment up to par with the competition.

But having had to emulate pinch-zoom in an Android emulator has made me wish I had my touch screen laptop back. Emulated touch events also don't work like real touch events, so web dev can also be a bit annoying sometimes.

It's just small things. I don't have a touch screen laptop anymore, but being able to physically tap things or reaching over to touch things just felt natural.

I have a phone with a QWERTY keyboard that also acts as a trackpad, yet I rarely use mouse mode on it. Seeing kids interact with laptops for the first time and touching the screen expecting them to work like every other device they use is also probably a sign of the times.

I understand why not everyone likes them, though. Some people prefer to disable their trackpads too, or prefer ball mice, or prefer mouse gestures over keyboard gestures. To each their own. I welcome the diversity.

Initializing core 0 on a modern system requires a Pentium CPU preconfiguring Minix to bootstrap the CPU. Training RAM is a whole new challenge. The simplistic designs of the 20th century don't apply anymore. Having USB to control boot is a necessity now and with Thunderbolt offering DMA access, configuring trust at a low level has also become a requirement.

There are plenty of things I don't like about UEFI. Going for pseudo-Windows APIs, for instance, or using FAT as a filesystem while better open-source filesystems are available.

I do applaud the efforts of people like the Coreboot team, trying to take control back for their devices, but the cut-down minimal boot manager they provide has yet to convince me to even try switching, to be honest.

Why not? Religious freedoms are about deeply held beliefs. It's not like a judge will evaluate the bible or quran to check if something is or isn't a religious freedom based on what someone's deity of choice supposedly stated.

Browsers were the original TLS trust store vendors. Operating systems started shipping trust stores because their OS came with a browser, not because they were the natural root of trust. Browsers also have tools to update revocation near-live, while operating systems lag behind by hours, or days in this case.

For your tool, remember to nuke Windows' automated certificate authority updates (separate from normal Windows updates) and possibly the automated intermediary cache. Microsoft publishes a list of trusted CAs/intermediaries periodically and they get automatically applied to Windows so websites don't need to send the full cert chain during TLS negotiation, and it has a tendency to cache trusted intermediaries as well.

Mozilla's trust store is one of the first to get updated when a revocation happens, as well as Google's CRLsets. Downloading full CRLs repeatedly would be a waste of time and bandwidth, that's why there's a specific distribution method for CA updates. I would extend your tool with a daemon that checks for revocation automatically, so you don't accidentally eMudhra yourself while browsers and the OS get updates next time something like this happens.