edelbitter

> this file was independently reproduced by <name of trusted party>

Sounds risky, unless paired with strong policy about what a verifier should do. e.g. if the verifier just grants network access to the buildbot that then checks what the result should look like, then compromise could remain invisible while the label silently downgrade to "independently downloaded by". And I do not expect there are many parties that would be willing to provide such service beyond their own needs, while simultaneously not already providing that service in places where the infrastructure and policies are already set (such as Debian). Or at least they would already contribute towards build dependencies that do not break reproducibility on every other version bump.

A "vacant plot" in this context might be example.ccTLD not being associated with a sufficiently large share of Example Ltd taxable income declared in CC, or some 3rd country maintaining suitable double-taxation treaties with CC. (While in the same interval not having their registry lock in forfeiture of voluntary ownership transfers, in order to qualify for some appropriately scoped "currently no commercial intent / obviously not a squatter" exemption.)

That way you would be forced to keep it personal.. or suffer reduced sale price, as the new owner would need to backpay the minimums you were exempt from, or take on some risk merely leasing from you until the lock eventually expires - as you remain the true owner and all the payments and paperwork must cross your desk.

dom.event.clipboardevents.enabled=false removes the non-consensual clipboard read access, which is an enhancement but not a strict requisite for attacks of this type. The utility of the other events boils down to mostly convenience: The website can still indirectly observe how you use the clipboard, even when not explicitly notified. The website also remains in control of the CSS properties that can be used to create a meaningful difference between user selection and resulting clipboard content after copying. And, crucially, (blindly) overwriting the clipboard is still permitted.

You have not mentioned the final step, the one that is not certified in the Einbürgerungsurkunde: Becoming less German than many Germans by walking the tightrope between superiority thinking and self-harmingly downplaying legitimately great achievements.

Purposefully making the distinction between things that are merely peculiar about German customs (old and new) on the one side, and things that are objectively the one true/correct/orderly way of doing things, and thus, must forfeit all claims of being "German". Many of the latter fall into the general categories of "rule of law" or "high-trust society", and once you compare how Denmark and Austria are doing, the most productive strategy is probably to stop attributing them to the peoples or states of Germany. And rather, consider them merely things easy to observe in Germany at this particular time. Use Germany as a spotlight to learn how to recognize how it looks and feels when they work, and more importantly: how to spot signs of them failing to work, then apply it globally. Und es mag am deutschen Wesen einmal noch die Welt genesen! Which is easier without bundling it up with customs that.. well.. would better remain localized to free state of thuringia.

Would not count that as 20 years of sticking to that philosophy, though.

We also figured out 20 years ago that SHA1 was not quite as strong as initially estimated, and not quite 10 years ago that generating two colliding documents was merely a matter of some serious computing power. A few projects went ahead and changed the name of their master branch, but SHA256 preference remains elusive.

> To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases

While this may quantify how disruptive the change would be to those projects that are able to and do upload additional binaries to PyPI later, it fails to quantify how many projects already completely circumvent this block before it is even introduced.

e.g. If you tell pip to install from source.. the result may already be that you install a binary that PyPI never saw. A common hack for dealing with NVidia internals, which can explode into a large CUDA major version x GPU arch x platform x implementation x python_version cartesian product. The "extras" mechanism is not quite sufficient to model such combinations.

sample code: https://github.com/Dao-AILab/causal-conv1d/blob/4f6ae4e26ae5... https://pypi.org/project/causal-conv1d/

I wonder if it would have permissible to submit the birds (obviously great) and the buildings as as they could have looked if they embodied the combined architectural prowess of the union.. in place of the vitreous crimes against aesthetics that happened to be cheap enough when construction started.

In any case, the refined version of that admission - the deliberate porcelain/plumbing distinction - is still best explained in the git docs and I wish more tools would copy it. apt(-get) has cautiously started that process, while GnuPG sadly remains a box shock full of surprises in both API and CLI.

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)