creatonez

And if the chatbot makes additional promises or stipulations that have nothing to do with the flight they are actually about to book? The user won't know what they are confirming.

Yes, because that's what we need, for time-sensitive and highly nuanced information about flights to be filtered through a wildly hallucinating chatbot.

Anyone who books their flights entirely through a chatbot deserves to have their plans screwed up, and whatever company sold the chatbot to them deserves to have these irate customers yelling at them.

> 2. We have a critic LLM that assesses among other things whether the website content is leading a non-aligned initiative. This is still subject to the LLM intelligence, but it's a first step.

> [...]

> 4. These attacks are starting to resemble social engineering attacks. There may be opportunities to shift some of the preventative approaches to the LLM world.

With current tech, if you get to the point where these mitigations are the last line of defense, you've entered the zone of security theater. These browser agents simply cannot be trusted. The best assumption you can make is they will do a mixture of random actions and evil actions. Everything downstream of it must be hardened to withstand both random & evil actions, and I really think marketing material should be honest about this reality.

So you're shamelessly selling spambots? The marketing here is wild... "proxy rotation"... "auto-CAPTCHA solvers"

If short lived certs are a problem, your methodology is wrong and has been for a long time. Period.

Aside from the prospect of bad press and user protest - There are still non Play Protect certified Android phones being released, including a few rare phones that skip the Play Store altogether (including the Fire phones). So they could lose at least a little bit of ground in this area. In a sense, they are in competition with their open source offering, even though they have a lot of control over it these days.

It could also make jailbreaking more commonplace, which on the Android side has died down in recent years because sideloading is enough for most users.

Both of them were eventually decrypted. The decoy was a misdirection attempt to get people to shut up about the whole thing, since the original contained a passphrase that had been reused multiple times for Mojang's internal operations. But it only caused more people to go digging as they noticed the hash changed, along with an employee acting highly defensive about it.

They used "boxpig41" for the original and "thespicemustflow" for the decoy. Both of them contain the jar and assets for Minecraft 1.0, but the original also contained an ordinary copy of the Minecraft launcher, so that the files could used to run it during a live event even if internet access goes down, hence the larger file size.

All these "constantly challenge your own assumptions" prompts really do in practice is make it second guess assumptions that actually are obvious and true, which pollutes the output further.

In a sense, it bikesheds[1] itself. It's been told it needs more discussion/debate to solve a problem, but it's only smart enough to tackle minor details that might not matter. And when it does try to tackle major details, it screws them up, causing a cascade of compounding bullshit. And it also tends to cause it to roleplay someone who constantly bungles things, which is bad because it takes it away from its default RLHF tuning for factually accurate outputs on first shot (not that it lives up to this goal, but that's how they've tried to train it).

Getting this right seems to be a very tricky problem.

1: https://bikeshed.com/

Crawlers already know how to stop crawling recursive or otherwise excessive/suspicious content. They've dealt with this problem long before LLM-related crawling.

Well, it's both complete misinformation and attempts to tie a reputable open source project to an unrelated harassment and stalking website.

Anubis has nothing to do with Kiwiflare, there's no connection at all. It's not the same codebase, and the inspiration for Anubis comes from Hashcash (1997) and numerous other examples of web PoW that predate Kiwiflare, which perhaps tens of thousands of websites were already using as an established technique. What makes you think it is a clone of it?

Huh, why would they need the unbranded version? The branded version works just fine. It's usually easier to deploy ordinary open source software than it is for software that needs to be licensed, because you don't need special download pages or license keys.

If it makes sense for an organization to donate to a project they rely on, then they should just donate. No need to debrand if it's not strictly required, all that would do is give the upstream project less exposure. For design reasons maybe? But LKML isn't "designed" at all, it has always exposed the raw ugly interface of mailing list software.

Also, this brand does have trust. Sure, I'm annoyed by these PoW captcha pages, but I'm a lot more likely to enable Javascript if it's the Anubis character, than if it is debranded. If it is debranded, it could be any of the privacy-invasive captcha vendors, but if it's Anubis, I know exactly what code is going to run.

This headline is so egregiously sensationalist.

The XZ backdoor never made it to Debian stable. It is "still lurking in docker images" because Debian publishes unstable testing images, under a tag that is segregated from the stable release tags. You can find vulnerable containers for literally any vulnerability you can imagine by searching for the exact snapshot where things went wrong.

And then downstream projects, if they choose to, can grab those images and create derivatives.

Basing your images on an experimental testing version of Debian and then never updating it is an obvious mistake. Whether XZ is backdoored is almost irrelevant at that point, it's already rotting.

> Upon discovering this issue, Binarly immediately notified the Debian maintainers and requested removal, but the affected images remain in place.

It is generally considered inappropriate to remove artifacts from an immutable repository for having a vulnerability. This wasn't even done for vulnerable Log4j versions in Maven repositories, despite Log4shell being one of the most potent vulnerabilities in history. It would just break reproducible builds and make it harder to piece together evidence related to the exploit.

Toolbox and Distrobox are not based on Flatpak, though. They're more just nicely packaged docker-like container tools, targeted for development use cases.

It shouldn't do anything until the user has told it where the files should end up. It's an unpackaged program, there is no sane place to put it that doesn't have a high chance of conflicting with something else.

Ubuntu distributes some system daemons and even the kernel image as Snaps. The Ubuntu Server interactive installer nags you to look at a list of server software (such as nginx) to install using Snap.

Flatpak hasn't really taken the same path, it doesn't have much utility for anything other than desktop apps.

/opt/ is just a dumping ground for crap nobody can find a better location for

Can we please squash the idea of turning this into a product early, so no one starts to take it seriously? Agentic AI shouldn't be hooked up to any environment that doesn't have a flawless "undo" or "rewind 5 minutes" button. Would you hook up randomized mouse/keyboard input into a computer that you need to get work done on?

At the very least, display a very strongly worded warning message when the tool is run in a non-VM environment. Internet connectivity is still dangerous, but at least VMs can be snapshot. And it should not be packaged as an end-user product with a bar at the top of the screen, period.

This is a risky product and those who developed it have every ability to know that, based on the history of AI hallucinations. Not because it will escape or self replicate or other things claimed by the various idiotic AI religions, but because one of the first things it will inevitably do is screw up someone's work and cause data loss.

What ArchiveTeam mainly does is provide hand-made scripts to aggressively archive specific websites that are about to die, with a prioritization for things the community deems most endangered and most important. They provide a bot you can run to grab these scripts automatically and run them on your own hardware, to join the volunteer effort.

This is in contrast to the Wayback Machine's builtin crawler, which is just a broad spectrum internet crawler without any specific rules, prioritizations, or supplementary link lists.

For example, one ArchiveTeam project had the goal to save as many obscure Wikis as possible, using the MediaWiki export feature rather than just grabbing page contents directly. This came in handy for thousands of wikis that were affected by Miraheze's disk failure and happened to have backups created by this project. Thanks to the domain-specific technique, the backups were high-fidelity enough that many users could immediately restart their wiki on another provider as if nothing happened.

They also try to "graze the rate limit" when a website announces a shutdown date and there isn't enough time to capture everything. They actively monitor for error responses and adjust the archiving rate accordingly, to get as much as possible as fast as possible, hopefully without crashing the backend or inadvertently archiving a bunch of useless error messages.

Hardly anything changed

No... people have tried it, but there are no matches.

Why would nginx ever need support for the DNS-01 challenge type? It always has access to `.well-known` because nginx is running an HTTP server for the entire lifecycle of the process, so you'd never need to use a lower level way of doing DV. And that seems to violate the principle of least privilege, since you now need a sensitive API token on the server.

> I typed all this before realizing I could have recommend you ask an LLM, and it probably would have given you a better answer.

Please don't. This would be useless spam, and is completely rude. Do we tell people to "Just google it?" here?

It is both. The structure does actually help LLMs. Interestingly, LLMs seem to respond well to the repetition of XML-like structure (that is, the presence of closing tags), even if it's just an ad-hoc constructed language with no real schema.

This was written 11 years before that debug log was added. Extremely loose connection. Things do actually change over the course of 11 years, believe it or not.

Why do you think this is an attempt at a persuasion tactic? Taint flags in this context just means something that might be relevant to debugging. Which this condition might be, if people in the future are unfamiliar with a potentially anachronistic split between /usr/bin and /usr/sbin. The debug message isn't there to judge the morality of your configuration. It's actively improving your ability to continue to support both ways, by properly indicating what style of system it is for troubleshooting purposes.

Based on your list there is an opportunity to define stage -1 of error handling sanity, the Eval-Rinse-Reload loop, as implemented by FuckItJS, the original Javascript Error Steamroller: https://github.com/mattdiamond/fuckitjs

> Through a process known as Eval-Rinse-Reload-And-Repeat, FuckItJS repeatedly compiles your code, detecting errors and slicing those lines out of the script. To survive such a violent process, FuckItJS reloads itself after each iteration, allowing the onerror handler to catch every single error in your terribly written code.

> [...]

> This will keep evaluating your code until all errors have been sliced off like mold on a piece of perfectly good bread. Whether or not the remaining code is even worth executing, we don't know. We also don't particularly care.

They were probably expecting base64 encoded binary data. Base64-encoded-binary-inside-Base64-encoded-JSON-inside-JSON is a really strange construction if you haven't encountered it before, because of how much space it's wasting playing a game of Russian nesting dolls.

Palantir is aiding and abetting multiple instances of genocide and repression worldwide. Their entire upper leadership should be thrown in prison. Along with other holocaust tabulation machine companies such as Microsoft and Oracle.

You don't need the exact flowing of text to be consistent, outside of publishing. This is an anti-feature most of the time, something you specifically don't want.

Zooming is not something PDFs do well at all. I'm not sure in what universe you could call this a usability benefit. Just because it's made of vector graphics doesn't mean you've implemented zoom in a way that is actually usable. People with poor vision (who cannot otherwise use eyeglasses) don't use a magnifying glass, they use the large-print variant of a document. Telling them to use a magnifying glass would be saying "no, we did not accommodate for low eyesight at all, deal with it".