secabeen

Yeah, there's definitely more to the story about exploitability that Anthropic isn't telling us. RHEL didn't release a patch until yesterday either.

The tech sector is the most software-defined and virtual of all sectors, it's natural that they are first to change. Other industries need to make capital investments to adapt to change.

You can see a similar history with electrification. A few industries went quickly, but then it took like a decade of little growth before the true benefits showed up. As an example, take a factory that was built around hyrdo-power like a grain mill. You can't just take an electric motor and drop it in in place of the water wheel. It doesn't fit, the wheel is outside, there isn't room between the mill and the wall, etc. Only when you completely rebuild a new mill building designed around the features and limitations of the electric motor do you see the major benefits.

Same thing here; it will be new factories and new companies that are designed from the ground up around AI and its benefits and limitations that really move the needle.

This appears to have global effect if placed in a <Location> block in the root apache2.conf:

  # PHP 20261020 Remediation (Global)
  <Location />
    <If "req('Content-Type') =~ /multipart/i">
        Require all denied
    </If>
  </Location>

Yeah. The use of the word "scan" in the original article and the title is misleading. It doesn't scan your system looking for passwords and testing them. It appears to take the password you give to HA (either as your HA Password to login to HA, or for an integration) and check those. That is a much smaller impact than is being assumed by many here.

Historically that hasn't been my experience, but it looks like that's because I never enabled the Solr-based Full-Text Search! Thanks for mentioning this, as I'm going to turn this on right away:

https://doc.dovecot.org/2.3/configuration_manual/fts/

Pretty much all the major vendors offer this now.

The problem is that they determine the other apps that are supported. There is no "generic" export.

The problem is this:

> 1Password for iOS exports ... directly to other supported apps, including your passkeys.

They pick the list of other supported apps. There is no ability to export to a standard encrypted file, nor is there a way to develop an open source app that can receive an export over the objections of 1Password Inc.

My read of it is that there won't be an endpoint for an FOSS script to connect to to make the request. All that stuff will be provider2provider on private channels that aren't publicly exposed.

GMail search fundamentally has an advantage over a mobile email client as Google can and does maintain dedicated indexes for your email on their servers. While a mobile client could do the same, it's not really something that you want to do on a battery-powered device.

It would be a great thing for IMAP servers to do, but none of the major open source ones really take on that feature, and Google wants you in their web-client, so searches via IMAP are low-quality at best.

> For passkey export, there is a FIDO specification for both a format and secure protocol for exchanging passwords and passkey information between password managers, with support on all Apple platforms, and implemented by 1Password, Bitwarden, Dashlane, and more:

Note who is excluded from this list: the End User. The protocol only allows exchange between password manager vendors who choose to interconnect.

Bitwarden is the only vendor I'm aware of that currently allows this, and it wouldn't surprise me if their new management takes this away in the medium term.

The FIDO alliance is trying very hard to squash any workflows that a scammer can use to convince an elderly retiree with $1mil in savings to wire their life savings to Russia. Unfortunately, nearly all of the export paths that we want as hackers overlap with these attack vectors. The drafts of the Credential Exchange format or Protocol assume that end-users and open-source tools are not valid targets.

> You have to pay the government rent in perpetuity.

You are paying the government rent in perpetuity for the services they provide, including enforcement of your property rights. If you wish to live on land without paying government rent, you will need to go to a place without effective government. Today, that would be Syria, parts of Sudan, or Mali as examples. I doubt you want to live in those places as a 1st world resident, but if you do, there's little stopping you.

Largely, because books are heavy, and there's limited demand for most used books. If you've ever been at a book sale on the last day, there are always lots of leftover ones that no one wants.

There's a general sense that librarians are preservationists. This is far from the truth. Most books get pulped within a few years of printing. Librarians are constantly discarding books that don't get checked out to make space for new books.

I can imagine a few more. Here's one that is 100% effective:

* Wait until your account was created > 18 years ago.

That may not be enough for you, and that's fine, this is not a governmental service or site, with a mandate to serve everyone. You can chose not to use discord, and discord can choose not to have you as a customer. YMMV.

It's the classic "make your problems worse to fix my problems" that you see across tech. Since they don't care if you get locked out or leave their platform, it's designed to make them maximally profitable. It's the same thing you see when sites "offer" to let you do pre-registration work before an event or transaction, even though doing that work at registration is often trivial.

Want to get a RealID? You can spend 30 minutes scanning and uploading your supporting documents through the website, or you can hand your documents to the person at the desk and they'll evaluate it in 30 seconds. Over thousands of people, it's rational for the organization to optimize away that 30 second review (it also gives people a recovery option if they don't bring the right documents.) For the customer who is competent enough to bring the right documents, the latter approach is way more efficient. I regularly have to put myself in the "I'm old and hate technology, so lets do this the manual way at the desk" flow even though I'm totally capable of doing the electronic flow.

RHEL is EOLing CPU architectures that CERN still relies on heavily.

> RHEL 9 mandated x86-64-v2, requiring instruction sets like SSE4.2 and POPCNT, while RHEL 10 targets x86-64-v3. CERN's accelerator infrastructure manages more than 2,200 specialised front-end computers and 17,000 embedded devices, including legacy Core 2-era and custom industrial boards, engineered for 10- to 15-year lifecycles aligned with long-term accelerator shutdown windows. Upstream microarchitecture mandates threatened to abruptly obsolete thousands of functional, purpose-built control nodes.

> This is just vandalism from badly supervised ‘agents’ which don’t know what they are doing or why. You could set this up with a short perl script, and the human setting it up would be held responsible for the spam - why is this different when it’s AI agents set up by a human and allowed to post to the internet at large?

It's not, but the courts and the legal system move slowly by design. There is absolutely legal risk for OpenAI here that will not close until the Statue of Limitations has expired.

Quicken Desktop (yes, it still exists) just added this as a new feature as well. It's pretty nice.

BSidesLV is still pretty chill, although it's more focused on cybersecurity professionals than on the hacking side of things.

Yes, but it's a different group of Americans, and the ones who are currently thriving in this broken system will fight tooth and nail to preserve their way of life.

And most of that income is salaries to existing healthcare administrators. Quickly ending the employment of the people working those jobs would be a significant shock.

Yeah, the only place I use SLOG is with Optane devices in front of SATA/SAS flash. Anything that needs the speed of SLOG shouldn't be on rust anyways.

I would be in a different world if my system was backing banking or other loss critical data. For all my workloads, losing 5 seconds of writes in a crash is NBD.

I schedule scrubs during idle time (10pm Friday - 6am Monday), so the metadata hit doesn't affect usage, but YMMV if you don't have an idle time. I also don't generally let them get that full.

If I was building the array new, I'd probably use a special VDEV for metadata, but they didn't exist when I built my last one of these.

Every 100+ TB ZFS pool I have is optimized for streaming reads/writes. IOPS are rarely a binding factor at these sizes.

In this case, Fanatic is the long-form version of the word "fan" used in the expression "sports fan".

> Fanatics, Inc. is an American sports platform that consists of several businesses, including licensed sports merchandise, trading cards and collectibles, sports betting, special events, and live commerce.

--Wikipedia

I thought this, but random updates and changes for my apps in dev mode got too annoying; switching to full root has made my apps stable and turned off the prompts to upgrade the OS. It was worth it.

Do they even expose much cross users? One of my sports apps has a Family Plan, and my "family" is three other players who organized ourselves on FB. We split the cost evenly and it saves us like 50% each. I don't even know their names.

That's because Fanatics took over the jersey manufacture and cut the quality. Fanatics sucks in all sort of dimensions.