fdupress

The theorem doesn't exist in a vacuum. It talks about objects that must be formally defined. And if that formal definition (which is part of the API) is not immediately compatible with those others use, and every single theorem comes with its own definitions of the objects they're working on, you're going to be reinventing the wheel over and over again.

Replacing thought and curation with repeated automation is tech debt, pushed down to fundamental knowledge and understanding.

All this means in practice is that anyone who wants to use it for ads needs to get in touch with the devs and negotiate another set of licensing terms and an amount...

Astrology thanks you for your service.

This author disagrees with this take. They are setting a scene here, and explicitly saying that the Block story wasn't about AI at all a few paragraphs later.

If that "bait" caused you to stop reading despite the fact that you probably agree with the author's sentiment, it's not very good bait.

Seeing the server temperatures go up as this gets posted to HN is fun. I'm not sure his server agrees.

You seem to be missing the main point, which is that this is not about your point of view, but about the rightsholder's.

Pretty sure that's 20% of revenue, and I'm assuming that their business plan relies on skimming from settlements, not just taking donations. But they are also paying investigators and lawyers out of all of that.

And don't forget that Sony and Microsoft have compilers teams, working on specialised GCC and LLVM backends, and sometimes upstreaming general improvements.

Transparency logs like [Certificate Transparency](https://datatracker.ietf.org/doc/html/rfc6962) use permissioned chains (and other things) to distribute trust in the internet public key infrastructure.

That's all I can think of, though.

The "keyed SHA-256" in key transparency's leaf_hash is ok in its current state, but limits future evolution (or presents a risk if that evolution is not done carefully): SHA-256 is subject to length extension.

I could not follow where the leaf_hash is used carefully enough to figure out exactly how dangerous this is in the broader context and taking future evolution into account. But it's clearly safe as it is used now because all expected inputs have the same length.

And since you apparently haven't seen, the abstract now includes the following note.

Note: Update on April 18: Step 9 of the algorithm contains a bug, which I don’t know how to fix. See Section 3.5.9 (Page 37) for details. I sincerely thank Hongxun Wu and (independently) Thomas Vidick for finding the bug today. Now the claim of showing a polynomial time quantum algorithm for solving LWE with polynomial modulus-noise ratios does not hold. I leave the rest of the paper as it is (added a clarification of an operation in Step 8) as a hope that ideas like Complex Gaussian and windowed QFT may find other applications in quantum computation, or tackle LWE in other ways.

Self-response: the article does consider this (section 6), argues that the exceptions to restrictions on the use of publicly available data in GDPR are exactly in places where it makes sense to prevent AI usage, and further argues it makes sense to consider AI profiling a more severe breach because of the higher potential for harm.

Yes, and surely the right to not be profiled on publicly available data is already enshrined in GDPR?

You might want to clarify that "It" in the last sentence is Kyber/ML-KEM.

Sorry, just saw this.

Which claim do you disagree with? The claim that the trend I describe exists, or the fact that it is bad?

Note that what you describe is what I advocate: you explain that the question exists and hasn't been answered. This is not an argument that is based on the volume of work that exists.

It is also an argument you cannot (as an author) be trusted to make. Even if you cite everything that has been published that is tangentially related to your claimed contribution, there is no way a reviewer will know all of it, and no way a reviewer will be able to go and read all of it. So they can't determine whether your claim of novelty is correct unless they already know the entire field. The only defense against this is to encourage crisp and clear descriptions of claimed contributions (to knowledge or practice) and violently reject any overinflated claims. It is not to include an entire survey paper in the introduction of every piece of work that pushes the state of the art forward.

It does mean that the average paper is less accessible to the non-expert. It also encourages the regular publication of surveys whose role is solely to critically and exhaustively compare recent advances, and of textbooks whose role is to describe historic developments and their context. This is not something every paper should be doing.

``` python print.py https://www.paulgraham.com/avg.html, https://www.paulgraham.com/determination.html ```

You're arguing against practice in mathematics based on practice in an empirical field, though. Truth in biology is fuzzy in a way truth in most mathematical fields is not.

This is a lot less true in mathematics research, where a question existing and not being trivial is enough motivation to investigate.

I would in fact argue that the trend, in "applied" fields, of justifying the importance of a piece of work by pointing out that a lot of people are doing similar work is in fact self-fulfilling. That makes it somewhat useless as a measure of importance.

Scientific context should be critical, not just descriptive.

You would run browsh on a power unconstrained server that you SSH to from your power-constrained device.

I am slightly confused by this comment in the context of the thread.

Because you choose to give your children freedom to operate their device however they see fit, you are in support of legislation that restricts what they can use their device to access on the internet?

Linear types and handlers are even more inconsistent, given the continuations could be run more than once if not careful.

"gets converted to" and "gets rendered as uploaded by the user" are two different things.

There are no issues with arXiv generating the HTML and sending that over: they control the generation process, and users who visit arXiv already trust it to not be malicious. The issue is with letting the user upload their own and having it sent on to other users as is.

Your comment is asking which of two methods of estimating is correct.

Neither is correct, in that neither gives the actual objective truth. Both are correct, in that they both give you estimates that can only be incorrect if they give a zero probability to the actual objective truth.

Even statistically, assume the true value is 0. Is "2 ±5" or "1 ±7" the better estimate? Assume the methods used to derive them consistently yield similar estimates. Which one is the correct method?

Why do they disagree? Because they are estimates. Which one is correct? Neither and both: they are estimates.

The juxtaposition of "this is how it's done because otherwise those that fight fires impose restrictions that those that build don't like" and "construction workers Vs firefighters" seems to be undermining your point...

In mature industries, there absolutely are plenty of regulations in place to make sure that builders don't make responders' life harder. That doesn't mean that the responders aren't needed, but the fact that the software industry as a whole decided to go all "response is the only thing we need for most things" is evidence that it is not mature.

If you have the option to deny without negative consequences. "They could always jump off the plane."

Give it 20 years, maybe 50.

You can specify an EtM construction that accepts additional authenticated data. However, you can also do it insecurely (as the post I linked above describes) without realizing you did it insecurely. This is why most people prefer to use cryptographer-approved AEAD modes.

Sure, I agree with this. But then the advantage of AEAD over a bespoke EtM is not that AEAD allows the authentication of unencrypted context.

> In fact, you must ensure that the nonce, a piece of unencrypted context, is authenticated.

For CBC mode, sure. For CTR mode? Not really.

If you don't, you do not get ciphertext integrity: decryption will succeed, but mostly yield gibberish, if the adversary changes the nonce in a decryption query. This may expose a padding oracle, with all the nice attacks those things allow, depending on details of the application.

> Nothing stops you from throwing more stuff in there.

What prevents an attacker from shifting bits from the ciphertext field into the AAD field in the decrypt path and yield the same HMAC tag? Unless you have an answer to this question, vanilla "encrypt then MAC" is not sufficient. You need a better-engineered construction than that.

Yes, you need a well-engineered construction.

Please let me know if something wasn't clear, or you feel it was missing.

And yes, your linked post covers all this, but that is not the point: your summary of the linked post just claims superiority of AEAD (which I took as integrated AEAD modes) over EtM because of a functionality you claim is missing from the latter. But in the same way you need a well-engineered integrated AEAD to get any kind of security, you will need a well-engineered Encrypt-then-MAC-with-AD construction to get a secure construction. And here "well-engineered" means "ensure unambiguous parsing of decryption inputs," we're not talking about high-flying stuff that doesn't have standard solutions.

In short: I accept the point of your linked post, and I agree with it. But I reject the claim that a functionality mismatch is what makes integrated AEAD better than a constructed EtM.

Etam absolutely allows you to authenticate an unencrypted context. In fact, you must ensure that the nonce, a piece of unencrypted context, is authenticated. Nothing stops you from throwing more stuff in there.

The only thing you can do with an integrated AEAD that you can't do with a constructed one (with standard interface and security) is include authenticated and unencrypted context halfway through an encryption.

The pattern is the same on every card, but the cards are cut in a way that doesn't align with the pattern, so the two edges of a card don't look the same.

It's still a manufacturing defect, which could be sorted out by paying more for those decks that are to be used in higher stakes games.