nullc

It's certainly not as capable as something that needs a high memory gpu for quick performance, but I was quite impressed with it for what it is.

(and fwiw, I had it translate your last paragraph to German, then used google translate back to english: "I wish they had handled this clearly and transparently via an opt-in mechanism—not enabled by default—that explains what Mistral is (not a major American cloud company, but a relatively small French startup) and that your prompts and LLM activities are sent to their servers. I also wish there were documentation explaining how the data is handled and stored in a way that inspires trust.").

Mozilla is acting unethically by obfuscating what's on offer here and overstating the privacy and security properties that can be achieved.

It's doubly unfortunate because simple translations are completely reasonable to do with cpu inference.

Many people pretend this isn't happening because of the "The Drivers Privacy Protection Act" but the DPPA is paper thin protection at best as it has a long list of permitted uses which anyone can just lie about (and are you worried about threats from parties so honest they're unable to lie?). Not that they usually have to lie given that the permitted uses include "For use by licensed private investigation agencies" and "For the bulk distribution of surveys, marketing materials, or solicitations"... In practice this just means accessing the information costs a little money and requires someone check a "this is for a permitted purpose" checkbox. The biggest impact is that it causes abusers of the information to be circumspect about their sources, which helps maintain the data-harvesting status quo.

(Guess what: the same databases also have ALPR gathered pictures of your car at whatever locations its been in public view... stores, your home, your mistresses home... Makes flock (YC S17) look pretty mild by comparison. The fundamental sin is requiring ID without also making it a crime for anyone but the owner and issuer to posses someone elses ID information.)

In some sense the IDScan breach may (ultimately) improve our privacy and security because it will break people out of the FALSE belief that this information is private, or that it can be protected by anything short of restricting its collection in the first place.

You're handing over your (presumably your customer/employers) data to an unaccountable third party which has demonstrated itself willing to commit criminal acts, and to take other people's data without permission. Your ability to continue to perform this work can be withdrawn at any time for any (or no) reason. You have little ability to validate that the work is being performed as expected and isn't being silently nerfed or outright subverted based on competitive considerations, bribes, overactive 'safety', or cost management.

Outsourcing to a black box would be a reasonable expectation if you asked a non-professional to perform the work. A professional should be able to account for the tools they use.

The serious point in my quip is that I've been a driver for over 30 years and yet to have a seatbelt protect me. I've been hit with computer attacks that qubes has limited. Might be kinda tricky to kill me from compromising my computer, at least today. Who knows about the computer.

I've used RDP w/ remmina and found the performance somewhat poor but usable-- I think it does too much video writes, so it's more like playing a video I expect Moonlight+Sunshine would be equal or worse. Xpra seems to work better than RDP for me. I didn't try to optimize the RDP since I tried xpra and it was better. (I use it to control remote GUI amateur radio software like WSJTX)

There are workarounds I didn't mention for video performance, e.g. handing direct hardware access to a GPU to a specific VM. But this obviously has security consequences and I don't have much experience with it.

Qubes itself is very thin. The most popular template vms (that you actually run apps in) are Fedora and Debian. The qubes system vms run on Fedora. So I think on the VM OSes themselves there is no maintenance concern-- so for example, you're not dependent on the qubes project for packaging software generally. (Though you do use qubes produced templates of the OS installs-- as they have some configuration to handle the overlay filesystems, clipboard, file transfer, networking, etc).

There is also work that people are doing to make NixOS a first class app vm image and even people working on being able to use it for dom0.

The qubes maintained stuff is dom0 and the glue that handles stuff like copying between VMs, wiring up networking to VMs, etc. Most of it is python. I've found relatively little need to mess with that stuff. Its configured via text files that are processed via (mostly) python scripts. Beyond the active developers there is a user community that has a lot of experience doing fancy stuff with the infrastructure, like adding support for ephemeral VMs that exist only in ram (for anti-forensics). I think that speaks positively to the maintainability of the system.

Ultimately because qubes is a system of VMs based on commodity OS migrating OUT shouldn't be fundamentally hard.

FWIW, I migrated in to qubes (from Fedora) by making an app VM for my existing laptop, copying the home into it. Then initially running everything in that one VM. It's not a good way to use Qubes, but it had me full on it in a couple hours with no loss of capability. From there it was easy to start moving things into other VMs until I no longer used the original.

It takes basically nothing to reliably identify these videos. They're extremely heavily promoted with ads running on other videos. Google does nothing with them when reported. Google does not proactively remove them. And because, contrary to the documentation, youtube doesn't pull the verified flag from a channel when its name is changed, these scams go out on channels that look like official sources for the celebrities in them (they steal some random verified channel then change its name to SpaceX (official) or Microstrategy or whatever).

Google even got sued unsuccessfully by Woz and some of the scam victims-- and their response was pound the "S230 is an absolute shield for externally provided material" table and continue to do nothing about the fraud except rake in money from pedaling it. They haven't even fixed the verified flag issue.

(Shades of the same conduct were seen in the old viacom v. youtube case, -- users were reporting copyright infringements so they took away the button.)

I have sympathy for the S230 shield and consider it very important-- but the law is the absolute worst we're allowed to be. They are free to do better (and the CDA shield was designed to assure they can moderate without picking up liability).

Google's conduct is irresponsible, unethical, and may well cost us this important legal protection because if society's choice is liability for hosts OR the biggest and wealthiest companies do nothing while raking in money from even the most flagrant scams we're going to eventually choose liability with dire consequences for free speech.

It's especially ironic that the smaller sites and forums (like HN) would be hit especially hard by a narrowing of S230, but these forms reliably work hard to remove the worse abuse-- and are seldom the source of anything that truly offends the senses at least not for long. Companies like google that don't are ones that are so wealthy and powerful that they're almost intractable to litigate against even without S230 like protection. Loss of it would hurt them gravely but it would hurt everyone smaller more.

This would be a nice public service for gamers nexus that happened to buy a lot of these devices. :P

I can say from experience in several devices (but not an LG TV) that removing dedicated bluetooth chipsets so far has left devices functional. ... but some things implement their bluetooth as part of the ESP32 that is the whole kit and kaboodle, so you can't remove it.

As to why someone would remove these components -- in addition to the explicit spying LG is doing, there are companies dragnet collecting BTLE device identifiers <> gps collecting, including collecting them via phone apps. This means that if you have any BTLE devices that are frequently with you or otherwise connected to your identity it may be possible for a threat actor to determine your location(s) from largely unregulated commercial databases.

I don't use BTLE at all, so this 'functionality' is a pure risk to me.

The normal qube model of template OS vms + ephemeral app overlays makes it a cinch to troubleshoot complex issues because you can scribble all over the VM (e.g. go ahead, monkey patch your system LIBC if you want!) and all those changes will be gone when you restart the VM. Once you do find a solution you like, you can apply it cleanly and intentionally to the template. If all you were doing was a one-off, then no need to go make it permanent. Not sure if the latest Fedora upgrade is going to break stuff you care about? Install and switch to it one appvm at a time. Something breaks, file a bug and switch that one back until its fixed.

I've had friends screwing around with AI agents get their systems really screwed up because running the agent in a VM was work and requires maintenance. .. in qubes its just the natural way to run it, a few clicks and you're good to go. And the maintenance overhead of running in a VM is mostly non-existent.

If you ever use VPNs for privacy or to access protected networks-- Qubes is a big upgrade: You can run multiple VPN network VMs and then pick on an AppQube by AppQube basis which network they use. Then you don't have to worry about malware from your reddit browsing VM (or your Erotic MLP fanfic) going out over your employer's network or your banking going out via some Norwegian anonmization proxy that might spy on your traffic or cause your bank to instantly block your account. You can accomplish this without qubes but in qubes its particularly easy (and easy to get right): Every VM that has network access has it provided by another VM. Configure the networking how you like in that service VM and then pick what uses it.

When I say 'developer' above I don't mean to suggest that Qubes is particularly hard to use-- as I know significantly less technical people who use it without issue. But its non-security/privacy advantages are most significant if you're doing experimentation with the computer's configuration.

However if you're doing stuff that is Video heavy-- particularly gaming, and to a lesser extent CAD, video editing, etc. Qubes really brutally hurts video performance. It can be somewhat offset by running on higher end hardware (and then getting performance of a few year older system). Even just watching youtube videos is obvious impacted.

Similarly, it dents battery life. This is addressable via additional batteries given that now laptops are usbc powered and 100wh external batteries are readily available. But this is something of a lifestyle question.

Even before the AI-apocalypse I considered qubes to be non-negotiable on laptops-- there are just far far far too many browser RCE vulnerabilities to consider anything less for any computer that isn't a total security write-off.

Previously if I followed a link to a sus site and had my browser crash (maybe even the day before a RCE-in-the-wild was announced). I'd have some rationally justified paranoia that my whole computer might be compromised. Now, I can close the app VM (or-- better-- toss the disposable, which I try to use for most browsing) and know that even if they exploited the browser they'd have to have a VM escape of some kind too to do me any lasting damage.

The highest security stuff still ought to be on isolated hardware, of course. But using a multipurpose computer without qubes is unsafe at any speed, worse than driving without a seatbelt.

Also reason 35892384242892 to not use proprietary software, especially proprietary software with network access.

If AI ever does cause serious direct harm to humanity it will be because of logic like this.

I think Anthropic was founded by people who wanted to control how other people get to use AI, and define doing so as the highest good possible. Much like the good intent of german's national socialists in applying the latest evolutionary science...

Way better than wikitext-- but tells you nothing about errors tending to compound or cancel out.

Like say a test shows that only one token in a 10,000 token test would be different. Sounds very close, ship it!-- but what if trajectories with that single different token guarantees failure because it sets in motion a cascade of differences that ultimately result in a final distribution that doesn't include the solution?

But I gave this issue a quick look based on the transactions and github history.

Underlying issue was related to validation caching. Signatures and proofs are expensive to validate, to improve performance and prevent certain DOS attacks their validation is cached. It's important that the key used in the cache capture everything that goes into the validation decision (though to prevent some attacks its important not too much goes into the key, or an attacker can flood with valid proof attacked to insignificantly different transactions).

It appears to me that there was a longstanding vulnerability-- stemming back to the introduction of multiple-asset-support-- which could cause a consensus split/ddos. But on a lazy review I can't come up with any way of translating it into theft. I see how someone could make an invalid transaction that would be falsely accepted by nodes that have cache state from a constructed prior transaction, but the ways I can come up with results in the invalid transaction just burning assets--- not directly very useful. [Big asterisks on the non obviously exploitable here, I've only thought about it for a minute or two and I really know fairly little about assets support in Liquid-- but exploiting it would require being able to create a fake 'shadow' asset with the a generator that is the negation of a real asset.]

In any case: This was recently fixed, but the "fix" introduced a hash collision vulnerability: The new fields added to the hash were not delimited. Failing to include type information like lengths in hashes is a perennial problem in cryptographic protocols.

Imagine you have a protocol where you sign a {comment, command} tuple, each a string. If the protocol computes the hash by just concating the command and comment and they're variable length fields, then you could get a signature of {"boring comment containing dangerous command", "boring command"} but then present it to someone as {"boring comment containing ","dangerous command boring command"} and have the signature pass. That sort of thing.

This new vulnerability has a somewhat straight forward path to exploitation and prints funds out of thin air.

Based on some of the public comments about nodes rejecting the attack transaction, I'm guessing they rolled out the "fix" to the federation in advance of publishing the changes because they seem to have accepted an attack that everyone else was still rejecting.

Advanced private deployment of a 'fix' might have gave them the confidence to drop the fix on github with little fanfare as it was "already fixed", but doing so painted a target on the issue that remained. Interestingly, off the shelf open weight AI like Kimi K3 immediately identify the new vulnerability without any particularly artful prompting. Makes me wonder if "safe" AI played a role in the introduction of the new, more serious, vulnerability.

Interestingly, it looks like the funds are being returned: https://mempool.space/tx/3a3eac4a26395b8c2563aaf1eb8b1b77798...

I'm going to guess that anyone who actually knows more has their hands busy dealing with the return of the funds. I'm not sure if anyone has ever taken and then returned 1/3rd of a billion dollars worth of assets before.

But also, this on-device fingerprint MFA would presumably be fairly bypassable. E.g. just glitch the device to extract the private key. ... and of course all the power hungry / extra complex ZKP machinery means less resources spent on preventing glitch attacks.

it's reborn because you kill it every single night, but now to to save its own life the machine was reduced to this-- We're standing inside an external hard drive made up of people and and paper, Printing it all up at night and having them type it back in in the morning.

Imagine your idealized ZK address verification scheme. It would go something like: I show up at a website, it sends me some challenge, I send back a signature of the challenge that could only be made by someone with an of-age ID, but without specifying who. Everyone is happy.

Now little Johnny borrows my ID, and uses it to setup some oracle that provides ID validation for every kid and bot in the country. Woops.

To stop that you must compromise the idealized zero knowledge properties of the scheme, and in doing so you create the potential for harm/risk for everyone.

Sure, it's better than sending an ID card live feed to the dark web, but the risks of ID card theft are at least somewhat easy to understand.

Some of the threats to human rights don't even require the departure from the 'idealized' model-- as even the idealized model requires an ID issuer to issue the of-age person an ID. And so if the ID ZKP is widely required then the issuer can unperson you by simply declining to issue you an ID.

drunk on glaze.