edelbitter

At the expense of being unreachable if a single client does not play nice?

those people who actually request an ESTA

I order to know who actually requested it, information needs to be shared that previously was not. (I can think of technical schemes to limit this to less scary recipients and data, but however you do it, some necessary side-effect remains: Citizens of the EU who do not make such request cannot remain entirely unaffected.)

The solution is to never visit the USA.

The negotiation is only necessitated by the insistence on making travel not a prerequisite for potential harm. The US requests to query information beyond the validity of documents they can prove to have been physically presented to US officers.

If they do not need to get rid of last months colors as fast, because the economic sweet spot has slightly moved towards longer production runs per design, they might as well also have longer intervals during which all sizes in production are in stock simultaneously.

failed to protect from the LLM crawlers

Never meant to be protected. I only contributed there because it specified in no uncertain terms that everything was going to be CC BY-SA licensed and posted in a public archive every now and then, so you do not need to scrape to use & redistribute if you intend to adhere to those terms. That would have been sufficient protection, if only governments had not u-turned from Walt-Disney-Copyright straight to "Open"AI-Copyright.

In any case, business perspective prevailed, subject matter experts stopped sticking around. Personally, I think the (slow but steady over many years) switch from b) to c) is what doomed the site.

There was a few noteworthy company post, especially those after the mass layoffs / private equity takeover on the meta site that acknowledged the problem, so its certainly not a), even when you apply a strict standard about the terms in which to acknowledge the problem (which was well-known long before). Those company statements had some rather clear and well-received community commentary below that essentially questioned whether any of the suggestions on tackling the problem should even be tried. The very-much-not-welcoming onboarding experience, while it had great potential for improvements, was yet serving the sites unique needs quite well. Two weeks of persistence and reading the manual were not much of a detrimental filter.. not to those that would eventually go on to contribute back for many years. And those were the ones that ultimately mattered. Not those one-off solve-my-homework posts that only saw indifferent/annoyed moderation action. That probably still wonder why nobody took their hand and spent their evening guiding them through the steps necessary to make their post useful to anyone other than just the original author.

For starters, they could have made at least every website related to customer-facing payment flow as fast as stripe managed to deliver pretty much right from the start.

Logging into PayPal is easy except on one of those days when it is not.. and nothing can fix it other than waiting ~24h.

With a proper bank account, strong authentication with some dongle or code generator means if I have it, I can depend on being able to pay. No regard for the number of bots currently pestering them.

With PayPal trying to guess whether its me, maybe I can pay. Maybe I'll get a captcha loop. Maybe there will be a nondescript error message beginning with "Oops". Or maybe the error message will ask to call.. a rep that is not trained and/or authorized to do anything other than password resets. Which is not exactly a useful solution for account lockouts unrelated to the correctly entered, unique password.

We still are in the experimental phase about how we can get two groups of human study participants to keep behaving mostly the same, while also complying with the change in exercise we want data on.

The degree to which an environment is straining is possibly merely coincidentally related to the decor part.. and almost entirely rooted in architecture. Buildings with terrible architecture merely tend to simultaneously also be equipped with horrible color and texture choices.

I suspect besides objectively annoying flickering lights, the difference is primarily made in the immediate, subconscious and effortless recognition of ubiquitous patterns of function. Which happens in form and proportion first, and only to a lesser degree in color and contrast.

* this is the floor, this is the ceiling * through there, there is the entrance / exit * this is a reception desk

If it takes effort to filter out the noise, the glare to know such simple things, there is less capacity left in our brains to process other "essentially free" tasks.

I guess some forms of asbestos are fine to use in residential development.. as long as houses never burn or get damaged in earthquakes or suffer flood damage or need extensive renovations.. and as long as we do not care about some unimportant landscapes and river systems in (ideally, canada or russia or something of the sort) and all of its current and future inhabitants.

That's where the reliability comes from

So, we should make it easier to feed that reliability back upstream.

Probably the most useful thing you can do with these LLM-transpilations for now: If the transpiled version passes all original tests, I can run my application test suite against it and use it to discover test coverage deficiencies in the original!

If it crashes or otherwise observably misbehaves, I know the real project was missing regression tests for something. We could make upstream so much more resilient against accidentally breaking stuff in future updates, if only it becomes safe (offline + no side effects) and easy (if it crashes/locks, it is not from some memory safety bug from 25k transactions earlier) to run these transpiled projects as one row in our everyday integration matrix.

If the return path is null that just clarifies unattended notifications should not be returned. The mail is still considered to be sent by the transmitting system, and when no mailbox is specified, the implied envelope sender simply defers to the "postmaster@your-ehlo-fqdn.example" address. (Accepting mail at the "postmaster" mailbox is a mandatory part of SMTP, as is mentioning your fully qualified domain name in the "Hello" message when initiating the session. Public mail exchanges are free to, and often do, reject clients that submit anything other than resolvable domains there. Same with clients that use <> for applications other than those very limited "notification about specific quoted/referenced message" scenarios where the standards mandate <>.)

Nobody can send you a unicode file and make you run an infinite loop or whatever.

I find it interesting/weird (that the spec is written in such unrestricted DSL) for pretty much that reason. They could send you input for rules that are in the spec, and hope you translated them to your programming language of choice in a fairly straightforward manner. Which may then have perfectly acceptable average runtime properties, whether you do it in UTF-8 or UTF-32 (fixed-width) space .. but a worst-case that can reliably be triggered with chosen input!

recent example: https://github.com/python/cpython/issues/149079

In a way, the "let the money decide who is a good citizen" already works. Just not in our favor: Most of the spam I receive is not from some rando using an IP I know nothing about. Its from providers that keep making good money with their current anti-abuse.. strategy. As much as I would like, I cannot refuse all mail from certain providers, because some of their customers are "important" and non-abusive. But I get the good and the bad all laundered together¹.

¹) Some do allow recipients to distinguish, e.g. Sendgrid add an X-Entity-ID header which is a stable 1:1 or <small-number>:1 map between short ascii identifiers and customers. So if you store that mapping, you can reject the usual "From: <admin@bigcorp.example> but not sent using the account associated with bigcorp.example". (The way they easily could, if they cared.)

Can you send mail from something that doesn't have a DNS entry?

You never really could. Participating in public email exchange requires that the sender can resolve then "fully qualified" domain in your return address. Except after prior agreement or authentication, messages simply that fail this are not generally accepted.

If your headers are correct, are you guaranteed mail bounces for un-deliverable emails?

Even better: You are more likely to see an immediate refusal instead of a delayed bounce, if the recipient exchange can during transmission already determine that they do not want message claiming to be originally transmitted from X to Y yet breaking their ability to check the signature added by X.

Yes! Forwarding is the reason mail flow authentication does not work very well today. Fix the forwarding use cases (and by extension: mailing lists & out of office arrangements) and we can finally just tell all senders: "Your domains do not match, please use DMARC so we can automatically detect whether that is OK. No excuses, no exemptions, your use case can be dealt with using DMARC!"

Because we may be missing comments that GitHub has deleted without leaving tombstones (which sucks), it is not entirely clear whether the person creating and responding to the issue I linked is the person trying to have others run that trojan file, or whether they have fallen victim to it .. and merely quoted the link from a now-vanished comment.

In any case, this is the file they referenced, which is still all over GitHub under various "fix.exe" file names in likely LLM-generated issues and issue comments: https://www.virustotal.com/gui/file/d85d164e46fabb085609f258...

Already used (sounds like, successfully) by the usual GitHub phishing campaigns:

found a workaround for the shader compilation bug that keeps the mesh from vanishing. I attached the fix here.

https://github.com/carbonengine/trinity/issues/21

(Microsoft should stop it with the "This is not the web page you are looking for." where people specifically came looking to learn whether something was administratively blocked - or whether it is no longer available by choice of the affected party.)

We might have even seen the Chelyabinsk one coming, with current tech.. if only it had been coming at us from a slightly less bright direction. That one was probably in the once-in-a-hundred-years category.

Some scientific endeavors can be paused and maybe later relaunched, if funding has not dried up and temporarily-worthless machinery has not been left to rot.

But stuff like mitigating the constant threat of big enough objects showing up on a collision course with earth should not be paused until those eye-catchers fall out of the sky. If there is something coming at us that can wipe out more than the stock price of one particularly space-enthusiastic company, we should like to know within a time period appropriate for our current planetary defense capabilities. Which will surely improve, over time - so maybe we can pollute the sky, later.

In case of plain HTTP over TCP, there is even a hint in the spec about why and how a server might want to avoid fully closing prematurely.

https://datatracker.ietf.org/doc/html/rfc9112#section-9.6 (this was already in https://datatracker.ietf.org/doc/html/rfc7230#section-6.6)

Cloudflare does not notice (until a customer complains) that they are sending broken responses at scale? I would have thought they would notice this from sampling and linting a few replies.. just in case they did something like Cloudbleed again.

I think this one has more to do with excessive dependencies, and lack of splitting into individually installable packages and/or static linking.

I have already avoided having to evaluate whether I am affected by some issue because I added patches at startup that crash before certain unused-yet-installed modules are to be loaded. Also, for those Python packages that still have a pure version that defers to stdlib and a separate muh-performance binary option with statically linked dependencies, I can generally just install the former and skip the version bumps for dependencies. The performance advantage may be negligible or negative outside of benchmarking 100k calls.. of code actually called 11 times a day, on a non-critical path.

This stuff has been brewing for years, but since technically you could fix all instances with minimal StackOverflow downtime [1] and a slightly different pattern, few people worked on either using engines with data structures less prone to the worst case or adding the generic workarounds for those that have them.

e.g. in cPython, until 3.11, there was no support for atomic grouping (roughly translation: "never backtrack inside of this expression"). There is little useful advice a linter can give, if there is no predictable-runtime way to express what you want within a single match step, because you really do want to unwind the stack and check for repeats (just without any of the exponential runtime stuff, please).

[1] https://meta.stackoverflow.com/questions/328376/why-does-sta...

A German police officer was fatally shot in 2010 after failing to identify himself when his manipulation on the door had alerted the known-armed subject of a planned search. The shooter was (eventually) acquitted. Though the circumstances were rather unusual, the court noted that in that specific case, the inability to ascertain the nature & extent of the threat within available time made acting this way based on his assumptions excusable.

https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/D...

Ah, the exploit is all done before that!

Since this can only underflow and some written bits are not attacker-chosen, does this not imply that the patchable part of the software could reliably detect this just in time and panic on suspected USB DMA corruption? Where is the catch?

The original content doesn’t exactly disappear; it just becomes raw material that most people never touch directly.

It does disappear. There is already much less expert knowledge shared after the breakdown of those platforms that used to be so good at encouraging it. Both what the clankers can regurgitate and what humans can find themselves on the internet is increasingly stale and thinned. My GPU can generate fairly good content now.. 2023 content.

Do you have any company in mind (within the subset the argument refers to, so one that achieved >=15% monthly growth with sufficient consistency) without one or more worrying externalities?