netik

This is highly dangerous, right? If a bad actor possess centrifuge technology and can divert this <20% enriched uranium, they are essentially days or weeks away from achieving weapons-grade material.

This severely reduces the "breakout time" the international community relies on to detect and stop nuclear proliferation.

How much of this is AI?

I agree with this assessment but for many applications it's a viable approach, until the attacker goes off and writes their own shader to solve the PoW. We go to back to threat modeling here, and looking at the amount of effort vs gain here.

They're now integrating Argon2ID in an attempt to squash GPU hacks but it places ridiculous demands on the client being Memory hard.

So this is a basically a shill advertisement ending in "Your AI Agents can avoid captchas if you pay us."

The last example is a false narrative, that captchas will only happen if the "browser looks suspicious". Systems like Altcha put an end to this argument. They don't care if the browser looks suspicious, only that the browser can perform a proof-of-work to get past a captcha designed to slow down the request rate.

When applied consistently, it will effectively block and slow down AI crawlers, which is what this company wants to promote.

Until you scale past one machine…

This sure sounds like a marketer spending far too many words crying that they've lost surveillance on their customers. Boo hoo, don't care.

One other thing to add to the story is that the merchants can’t select what level of security they want from the credit card processor. For example, with authorize.net, you can accept the payment with the address doesn’t matter it doesn’t match.

I guess the real question here is how are they able to steal from you? Were they purchasing gift cards from a merchant with lax security?

It’s one thing to guess a number it’s another thing to get the money out of the system

Yet another “I cant’t parent so I’ll show my kids what a surveillance state looks like” post.

Caveat: I was employee 13 at Twitter and I spent a long time dealing with random failure modes.

At extremely high scale you start to run into very strange problems. We used to say that all of your "Unix Friends" fail at scale and act differently.

I once had 3000 machines running NTP sync'd cronjobs on the exact same second pounding the upstream server and causing outages (Whoops, add random offsets to cron!)

This sort of "dogpile effect" exists when fetching keys as well. A key drops out of cache and 30 machines (or worker threads) trying to load the same key at the same time, because the cache is empty.

One of the solutions around this problem was Facebook's Dataloader (https://github.com/graphql/dataloader), which tries to intercept the request pipeline, batch the requests together and coalesce many requests into one.

Essentially DataLoader will coalesce all individual loads which occur within a single frame of execution (a single tick of the event loop) and then call your batch function with all requested keys.

It helps by reducing requests and offering something resembling backpressure by moving the request into one code path.

I would expect that you'd have the same sort of problem at scale with this system given the number of requests on many procs across many machines.

We had a lot of small tricks like this (they add up!), in some cases we'd insert a message queue inbetween the requestor and the service so that we could increase latency / reduce request rate while systems were degraded. Those "knobs" were generally implemented by "Decider" code which read keys from memcache to figure out what to do.

By "pushes to connected SDKs": I assume you're holding a thread with this connection; How do you reconcile this when you're running something like node with PM2 where you've got 30-60 processes on a single host? They won't be sharing memory, so that's a lot of updates.

It seems better to have these updates pushed to one local process that other processes can read from via socket or shared memory.

I'd also consider the many failure modes of services. Sometimes services go catatonic upon connect and don't respond, sometimes they time out, sometimes they throw exceptions, etc...

There's a lot to think about here but as I said what you've got is a great start.

This a great idea, but it's a great idea when on-prem.

During some thread, some where, there's going to be a roundtrip time between my servers and yours, and once I am at a scale where this sort of thing matters, I'm going to want this on-prem.

What's the difference between this and checking against a local cache before firing the request and marking the service down in said local cache so my other systems can see it?

I'm also concerned about a false positive or a single system throwing an error. If it's a false positive, then the protected asset fails on all of my systems, which doesn't seem great. I'll take some requests working vs none when money is in play.

You also state that "The SDK keeps a local cache of breaker state" -- If I've got 50 servers, where is that local cache living? If it's per process, that's not great, and if it's in a local cache like redis or memcache, I'm better off using my own network for "sub microsecond response" vs the time to go over the wire to talk to your service.

I've fought huge cascading issues in production at very large social media companies. It takes a bit more than breakers to solve these problems. Backpressure is a critical component of this, and often turning things off completey isn't the best approach.

Great, so now my eyes and back are going to be f'd. Just step away from the screen and take regular breaks.

Didn’t we solve this already with slab allocators in memcached? The major problem with fixed allocation like this is fragmentation in memory over time, which you then have to reinvent GC for.

The trivial defense against this is time limited passwords for Wifi access. Deny all access until a valid password is entered, only permit that password and MAC address pair for n minutes.

Buy a coffee, get a new password, etc.

Two racists make a right (winger) I guess.

full of lies. for example, in downtown SF the options are few and far between.

there is comcast for high speed, and well… there is comcast.

If you want slow bonded DSL you can go to Sonic. Or At&T.

Only recently has LTE become fast enough to make home Internet over LTE an acceptable alternative

Buy our product !

Great idea but yet another blog post, which is actually marketing, which ends with “they did it buy our product so you can too”, which is probably not what Meta did.

not sure if this matters?

probably the hardest thing here is people read faster than they write.

in the 1990s I helped build a dating site where people put their profiles on small voicemails. This is very reminiscent of that and I think the engagement was low because it was a lot to listen to

fantastic! I’ve been building game show buzzers and various PCBs for them for about ten years and used them at a lot of events.

any chance you’ll open source this?

My boards and code live here:

https://github.com/netik/rpi_gameshow

Articles like these which blame technology as the great evil, with a “what about the children! think of the children!” bent, are biased and troubling.

The article starts by blaming then iPhone and social media and goes on to show how the child is a victim of poor parenting and divorce.

Maybe the child’s depression, anxiety, and longing for acceptance comes straight out of the broken home and not social media.

it’s batshit insane reading an article about privacy and surveillance while a request for tracking cookies sits at the bottom of the screen

The gold standard for this Druid at very large scale, or ClickhouseDB. Clickhouse has a lot of problems as far as modifying/scaling shards after the fact, while Druid handles this with ease (and the penalty of not being able to update after the fact.)

back in my day we did this with discrete TTL or CMOS shift registers and no PICs. they are a luxury ;)

advertisement pretending to be helpful.

Authy makes the user enter this on a periodic basis to refresh their memory, which is a good thing imho

I’ve always referred to biometrics as a “non revokable username” and not a “password.”

100% agree with you here.

and of course, it’s ugly. sigh.

Why is it that every OSS desktop has to look like a demo from the 70’s?

absolutely wrong approach. fix this at the carrier level and not client device level.

What does this remotely offer that Consul and Vault already do, in an extremely good, Highly-available way?