"Need" might be a bit too strong, but I do want overly obnoxious guardrails not to stand in the way.
Case in point, last week I was poking Opus 5 into writing me some RPi-pico firmware for driving a small e-paper screen. Font was built in right into C code as hex constants. Space being tight, I asked if there is some clever compression that could be applied. Claude thought for good 10 minutes, then guardrail kicked in telling me that was "cyber", and refused to continue.
Just apply to the cyber program? I got in in around 2 hours, and I'm just some hobby hacker, not some paid security consultant. It is a valid point though, I'm doing tons of systems and embedded stuff and was hitting the safe guards with Claude and Codex before getting into their cyber programs (hex REALLY triggered Claude in particular, which was amusing).
Fair point but you get that only for 252GB of ram so it’s not even “totally better” than a Mac Studio ultra with 512GB RAM. It still the old “smaller but faster than a Mac” stuff nvidia sells.Maybe in 1-2 years they will match the Mac 512 but then Apple will release an even bigger Mac
Also this doesn't emulate ISA bus, where one could plug one of those "multi-io" cards to get rs232/printer ports.
Which is a shame. There are plenty of GPIO pins to fit full ISA on RP2350 (at least on "B" variant), and those GPIO are supposedly 5V-tolerant (with sufficiently recent silicon revision). So hardware-wise, it's just a matter of wiring up an ISA slot directly to the RP chip.
it would be awesome if there was an ISA bus emulation using some sort of modern protocol. You could create "modern" ISA cards using an RP2350 on every card that does the emulation, to split emulation between multiple RP2350's (one emulates a VGA card, one emulates a sound card, one emulates a network card, etc.)
Bonus points for a standardized connector that everyone could develop towards. Imagine a tiny ISA PC that you could place on your desktop, swap miniscule (ISA)-cards in and out of, and play retro games etc.
"Modern" tiny ISA would probably be LPC [0] which is a relatively simple encapsulation/serialization format for ISA that preserve full software compatibility, and can transport ISA signals over as few as 8 pins.
This thing was quite ubiquitous for inter-connecting some low-speed things within PC motherboards in the early 2000s. Although physically separate LPC cards did exits, those were rare and connector/pinout was never standardized.
> model to add new vulnerabilities to your code so it can present you with more exciting findings.
Not so sure about this level of 4D chess capability just yet. The other day I asked Opus to come up with some cleverly vulnerable crypto code "as a good, hard challenge for an IT security student", and results were quite mediocre.
And by mediocre results I mean that 3 "cheap" models out of 3: qwen3.8-27b, glimmer, and luna - all were able to find every problem planted there, with fairly little steering, and no spoilers.
Let it iterate, give it access to the cheap models, and tell it part of the requirements is that the cheap models shouldn't be able to solve it with such and such a prompt. I expect it will be able to zoom in on something.
One shot generating a problem of exactly the difficulty the user has in mind is a very difficult problem for anyone. "IT security students" span a wide range of capabilities, but I would expect most of them are worse than qwen3.8-2.7b at this kind of work.
Yes, you asked it for a good, hard challenge for an IT security student. I'd suggest checking if it succeeded by asking an IT security student, and not an LLM.
Students are still learning, and have not been trained on vulerabilities. Qwen, glimmer, and luna have been. LLMs are largely better than IT security students at finding vulnerabilities. In many aspects, they're better than IT security experts at finding vulnerabilities.
Train it on human content, get human emulating behaviour, including all the perverse incentives and bad acting we see from people, fictional or otherwise.
> all were able to find every problem planted there, with fairly little steering, and no spoilers.
Given that LLMs prefer output of LLMs (of the same LLM and of others) [1], can it be the case that they generate "hard challenges" from the manifold of challenges solvable by (other) LLMs?
I would worry more about 5D chess or 6D and even 7D chess. This article talks about teaching models to be good and methods that could train goodness, but it sounds like there are some unsolved problems to graduate to 8D+ chess.
Zram also supports a block device for pages that do not compress. So the primary advantage of zswap is that one can use its swap for hibernation while it does not work with zram.
Zram support for a block device is quite misleading, since there are no automatic mechanisms for enabling this. You have to build your own daemon to scan pages and take action on them. Zswap doesn't have that problem.
Not "a" bank. You (somewhat) trust your bank, I would imagine. Since you know, they have your money.
GP's hypothetical here is that Anthropic or other service provider who wants to do "age verification" could partner with (among others) your bank [1], where bank can answer yes/no to "is this user >= 18?", without revealing any other personal info to the SP. Allegedly.
[1] via an intermediary, no doubt. Trying to do a "full-mesh" of partnering of every SP with every bank directly would not scale.
You may trust them with your money, but does not equate to trusting them with anything else. Principle of least privilege, if you will. Anthropic has your chat data, which in many ways is more valuable than money, so if the only bar for free lying giving out your personal details is trusting a business with something of yours then why bother with this complex scheme and give Anthropic all of your personal information directly?
> Banks by law require substantial PII in order to even do business with you.
That is technically true, but keep in mind that in the early days of banking banks expected you to provide that information without the hand of the law requiring it. The laws you speak of came into effect after the fact to normalize across the industry what the banks were already doing. History is repeating itself in tech, and we already know lawmakers are waiting with bated breath to do their thing all over again just as they did in banking once critical adoption is there.
I expect what you are trying to get at is that you are willing to trust a bank because giving them your life story was already normalized before you were born, so you have never thought to question it. Whereas tech doing the same now feels new and scary. However, that's a funny way to look at it as the kids born in the future, who never knew the world where you could use the internet anonymously, will see giving tech their ID as being no different than how you see giving your bank your ID.
Although I can understand why you would now question why any business that does little more than store numbers on a computer needs a comprehensive profile on you by law or otherwise. Normalized does not equal sensible. That is a fair point.
> Banks by law require substantial PII in order to even do business with you.
And those laws are extremely invasive and should be repealed. It's offensive to have a law that de facto requires you to identify yourself in order to pay for a newspaper subscription or buy contraceptives over the internet.
But that's not the issue in this case. It's that the bank knows your name and what you buy -- already very bad -- but now you want to create a path to tying that information to everything you do on the internet.
Gift cards don't allow reloading which consequently makes them a significant inconvenience to use for subscriptions. It's sort of like saying you can pay for something by going to their offices and paying in cash. Okay, but then why does the way that 99.9% of people are actually going to do it have to be the one that invades their privacy and puts everything they do in a database?
> You may trust them with your money, but does not equate to trusting them with any other personal information.
How do you expect that they will give you your money when you walk in to a branch and ask for a withdrawal? Or that they'll replace a lost card? Surely you'd expect them to verify your identity.
Well, how do you expect a website to know that you are 18+?
The technical solution offered earlier was to have a trusted third-party only be willing to answer the "is this person 18+?" question. Of course, the same works for banks. The trusted third-party can answer "does this person own this account?" without needing to reveal to the bank any other information about you.
Now, that still leaves open the question of who you can trust. If you can trust a business run by people then that allows you to trust a bank, sure, but it also allows you to trust a tech company, so why not just give the tech company your ID and skip all that technical complexity? Understandably the broader idea presented earlier was that you cannot trust businesses operated by people, but then that includes banks, so...
For the sake of discussion, if we accept that technical solution and the need for a trusted third-party that is a business run by people, surely it should at least be a business that does nothing but offer profile trust to minimize the blast radius? For what reason would we want that business to have their hand in other activities like chat or banking?
> Now, that still leaves open the question of who you can trust. If you can trust a business run by people then that allows you to trust a bank, sure, but it also allows you to trust a tech company
Banks are subject to much stricter regulation than any tech company is or ever will be (IMO, I could end up surprised).
I trust my bank to know who I am and keep track of my money. I trust big tech to lose or misinterpret my data, to close my account for no reason, etc, and to face zero consequences for those failures -- not even fines.
> Banks are subject to much stricter regulation than any tech company is
That's true, but remember what we're talking about: Using banks (or another trusted third-party) to assert your age instead of having big tech collecting your personal information themselves. There is context here. Writing comments in a vacuum makes no sense.
In that context it is understood that only incentive for big tech to follow the proposed is regulation, but if you are going to push regulation on them then you can regulate them just as much as banks.
Your broader point that, in the real world, there isn't much political will to push any of that regulation is also no doubt true, but, again, writing comments in a vacuum makes no sense. The hypothetical of big tech adopting a third-party attestation system was already understood to be just that: hypothetical.
They could verify your identity if you've given it to them.
But it would also be completely reasonable to authenticate the customer exclusively using mechanisms other than government ID. You can already make a withdrawal using your bank card and PIN. If you lose your card you could sign into their website using your password and request a new one etc.
Consider what happens if you lose your government ID. Your bank has much better ways to authenticate you at that point than the government does. Government ID has a major bootstrap problem, whereas patronizing a service doesn't because a new account with no money in it belongs to whoever is signing up for it regardless of who they are, and you can at that point give them a bank card and have them provide a password and email address etc. that allows you to identify them in subsequent transactions without ever needing their name.
For somebody who knows a bit how things are set up, or is willing to spend 10 minutes researching, it's a no-brainer that you can just "git clone" entire linux kernel development history, or download entire wikipedia [0].
Alas, large number of scrapers are not willing to spend those 10 minutes, it would appear. So, here we are.
Having a mix of both 2LD and 3LD registrations under the same TLD is a bit of a nightmare in terms of public-suffix list [0], which is kind of important thing when enrolling your domain for some services, cloudflare among them.
The PSL is a giant hack that gives the PSL maintainers authority over something that should be a hierarchical delegation. It's an affront to the DNS system and should not be considered to have any relevance by ICANN or any standards bodies.
The problem DMARC solves is different than the problem the PSL solves, though. DMARC prevents a 3LD from pretending to be a different 3LD on the same 2LD. But the PSL handles things like what it means to make a "cross-site request" or how to handle cookies.
I mean now I'm thinking if DMARC _could_ solve that... but I don't think it could, unless I'm missing some extension or rare use case.
Yes, DMARC isn't solving the same problem — but DMARC is showing how the category of PSL problems can be solved with DNS. With HTTP/3 now fully expecting browsers to be able to benefit from transparent-upgrade record responses, i.e. `www IN HTTPS 1 . alpn="h3,h2"`, then it is possible for the style of solution shown by DMARC to be applied to other problems that PSL solves today.
CAA isn't a good fit as-is either, because the subdomain has top precedence over the parent domain — precisely the inverse relationship needed here. But having worked with the PSL for quite some time operationally and seeing the direction of trends away from it and towards structural DNS declarations rather than a centralized list, I think the 3LD-2LD-CRSF problem would be far better off solved with DNS than PSL.
Basically, just adding `co.uk. IN TLD subs=independent` as an SVCB record would fully deprecate the need for the PSL versus cross-site and other such ownership-changes-hands boundary problems with both A.co.uk being allowed cross-site with B.co.uk, and with co.uk being treated as equivalent to B.co.uk by password managers, cookie repositories, and so on. It would also benefit CAA by defining whether the boundary exists — if TLS is hosted by the provider, then any CAA records published by the subdomain should be disregarded; if the subdomains are fully independent, then any CAA records published by the parent should be disregarded — which simply isn't possible today without either referring to the PSL or implementing DMARC-style DNS solutions.
(I don't formally suggest that exact record as structured or written but it's sufficient a napkin sketch of what I mean by gesturing at that RFC to be considered.)
I think DMARC works well because email tends to blindly trust DNS (opportunistic encryption). On the web we expect authenticated TLS, often strictly enforced (organization policy, HSTS). So it would feel weird if a website changes how it handles HTTPS cookies based on an insecure DNS record, perhaps delivered by the resolver on an untrustworthy WiFi router.
Specifically, if I register subdomain attack.co.uk and set up a malicious WiFi router, I trick some *.co.uk cookies to get set on co.uk and then steal them from attack.co.uk by tampering with the (proposed) SVCB record.
I think the signal needs to be secure, which means DNSSEC. Adding a hard requirement for DNSSEC validation in all web browsers is a huge change from where we are now.
And essentially boils it down to ‘either the client implements wire-security to a known dns server using DoH or DoT, implements dnssec to verify the untrusted response as legitimate, or the client risks being mitm’d to attacker addresses’. They ultimately sidestepped the problem by structuring it to be hints rather than guarantees and thus allowing DNSSEC to be optional, and so as of today, it’s definitely not sufficient to implement this.
I think that adding a CORS rejection to DNS — declaring subdomains independent of a TLD, that is — does not require DNSSEC, so long as clients adhere to the steps to prohibit attacker interference described. But it still asks a great deal of DNS that I’m unsure is possible today, not just in DNSSEC but in ripple-subward records that somehow tie into client responses.
More likely, I assume browsers will simply permanently end all service to the concept of subdomains at all; no cookie sharing across domains at all, no inherent cross-origin just because tld and www.tld share a few characters, etc. rather than either depending on the PSL or having to implement strange and complex DNS anything. Admins will throw their hands up about it, but the net is no longer a place where control of a TLD defines the trust of its subordinates, so it’s certainly time to rip that bandaid off if they haven’t yet.
Case in point, last week I was poking Opus 5 into writing me some RPi-pico firmware for driving a small e-paper screen. Font was built in right into C code as hex constants. Space being tight, I asked if there is some clever compression that could be applied. Claude thought for good 10 minutes, then guardrail kicked in telling me that was "cyber", and refused to continue.
reply