The good thing is you can still use their software without signing in and having to agree.

As much as I like the ideas, this article looks AI generated. This line with the bullet point, bolded label and colon, em-dash, and the second clause "it's about" all point to AI writing.

"Fiber-optic cables: Fiber-optic cables enable higher bandwidth phone lines and television—it’s about getting more television channels to more people."

That part in particular is suspect and I wouldn't be surprised if it was AI-assisted, but the article as a whole feels human-written to me.

I know I'm just adding to the noise here, but it seems like half the time I look at comments on posts (anywhere) I see a claim like this. I think you're probably just trying to warn people so they don't waste their time, but for me this type of comment is not helpful at all.

One problem with private age verification is that because each verification cannot be traced back to a user, it is hard to prevent abuse like credential sharing. Imagine how a single stolen credential can be used by any number of users because the verification step kept the credential private.

One method would be to use the same key that you use to hold some cryptocurrency, so if you share then you risk losing a bond.

Of course it's not ideal to make everybody hold crypto just to use online services, but maybe we can approximate that in other ways. Say, have the private data include name/SSN/DOB and maybe a credit card number, require the user to enter that stuff (or have browser do it), prover checks that it's all correct. Combine that with a challenge/response so proofs can't be reused. User can't share credentials without risking identity theft. Downside is more openings for local malware to succeed in identity theft, but maybe that's better than sending full credentials to big juicy central locations.

A third option would be to give everyone a hardware key that's hard to copy, but that would get expensive.

I think the best idea is to just skip age verification and keep the good ol' internet we've enjoyed for decades.

I assume they are solving this with secure enclaves creating one-time signatures.

To answer your question, ZKPs can enable the verification step to be done privately in your example. Another use case could be allowing cloud computing hosts to prove that they did not tamper with the results of a computation.

In this case, the government service doesn't get to know anything about the service (it only gets to see the salted hash of the service name)? And the service doesn't get to know anything about me, except for the "age certificate".

You can add more layers there, if needed for non-repudiation, all within the bounds of classic asymmetric crypto.

> Another use case could be allowing cloud computing hosts to prove that they did not tamper with the results of a computation.

What is the exact scenario here?

Got it.

The scenario I'm describing there is how a service like AWS has the ability to tamper with your code or its output. If instead, each response came with a ZK proof showing that the inputs you provided lead to the outputs it returned, you could efficiently verify that nothing was modified.

Saying Jane Street caused a $40 billion loss is wrong. Terra caused the loss because it was a Ponzi scheme that claimed to offer 20% APY on a stablecoin that wasn't backed by any real dollars.

It's a bad headline. They used publicly available blockchain transactions and didn't cause the collapse of the Terra ecosystem. Terra collapsed because it was a Ponzi scheme offering 20% APY on a fake stablecoin. The Terra stablecoin was not backed by real dollars, but instead by a cryptocurrency called Luna that did nothing else other than let you issue Terra stablecoins.

I mean they are being sued for insider trading, not exactly a bad headline maybe it could say alleged?

It seems extremely unlikely to me, a casual observer of the shit show that was Luna/Terra, that the suit would be successful

ZKML is a very exciting emerging field, but the math is no where near efficient enough to prove an inference result for an LLM yet. They are probably just trying to sell their crypto token.

It is definitely true across different chips. The best kernel to use will vary with what chip it is running on, which often implies that the underlying operations will be executed in a different order. For example, with floating point addition, adding up the same values in a different order can return a different result because floating point addition is not associative due to rounding.

There are many ways to compute the same matrix multiplication that apply the sum reduction in different orders, which can produce different answers when using floating point values. This is because floating point addition is not truly associative because of rounding.

Is that really going to matter in FP32, FP16 or BF16? I would think models would be written so they'd be at least somewhat numerically stable.

Also if the inference provider guarantees specific hardware this shouldn't happen.

Wait, wouldn't it be more significant in low bit numbers, which is the whole reason they're avoided in maths applications? In any work I've ever done, low bit numbers were entirely the reason exact order was important, where float64 or float128makes it mostly negligible.

"Use after free in CSS" is a funny description to see.

I think they meant something like the CSS parser, or the CSS Object Model (CSSOM).

One of the other commenters wrote a post that said it was related to @font-feature-values

Why ?

To me at least it reads funny because when I think of CSS I think of the language itself and not the accompanying tools that are then running the CSS.

Saying "Markdown has a CVE" would sound equally off. I'm aware that its not actually CSS having the vulnerability but when simplified that's what it sounds like.

Funny you'd mention that, when Notepad had a CVE in it's markdown parsing recently.