nickpsecurity

The math can be misinterpreted, misapplied, or not fit reality. That's why high-assurance security mandated a combination of things:

1. English specification of the system and its goals

2. Formal, mathematical specification of the system and its goals

3. Mathematical proof the system met its goals

4. Code implementing that system with a proof, often informal, that the code embodied the informal and formal design.

5. Tests of all functionality to prove the design and code worked.

6. Independent analysis of the above to find flaws in them.

7. If the implementation has concurrency or parallelism, more errors can occur due to that. There were techniques to mitigate it.

Each step found problems in systems made by professionals. Mathematical work and coding both have a long history of errors in their on fields. Combining them increases the likelihood of error.

Author thought nobody was playing chess with a beach-side view?

But God gave us beautiful oceans and intellectually-stimulating games. I'm sure some chess players aren't wasting the opportunity to enjoy both. Now, they're at risk of being taken out!

You raise fair concerns. So, we need to get data to systems they're reading from. But, they can't connect back over those lines.

The safest way to do that is a high-assurance, data diode (one-way link). One builds hardware that, physically and by software, only allows information to flow one day. Many are available commercially.

Sometimes you need proof of acknowledgement of each packet but nothing else. Naval Research Laboratory had The [Network] Pump that allowed only Ack's back and with algorithm to throw off covert, timing channels.

Next, one might want to let people send them requests over an API which they can respond to in limited ways. One can use a high-assurance guard with secure, hardware/software architecture. It uses simplified I/O with a message format that's easy to parse securely.

At this point, I'm also thinking it might be better to use the closed-source, proprietary solutions. The AI's are rapidly scanning the open-source code for vulnerabilities which I'm sure they're not always sharing. They'd be more likely to have attacks on it.

So, don't tell the untrusted model how the guard works, use private models + traditional verification to secure its code, and include both HIDS and NIDS monitoring. Also, make the systems as predictable and boring as possible to make anomalies easier to spot.

Even if it was, covert, channel analysis from the 1980's and 1990's would've taught it to do or prevent that. It was required in all TCSEC-certified systems high, security classes. Many papers were published describing those analyses, including cache channel, which are in their pretraining data.

Most of IT security ignored that work and never used the methods. That's why their syatems can't defend against them. There are hardware and software groups that built countermeasures. They're not mainstream. I don't know if the hardware needed is even commercially available (eg partitioning caches, async & randomized CPU's).

My idea was taking 20+ year old designs that are patent-free, implementing them on any modern nodes that work (esp MOSIS-supported), their performance per watt will probably be better, and just use those. Some of the old designs, like NonStop architecture or MPP clusters, still have amazing benefits.

I actually considered doing that with my droplet. Do you just use a web browser on your phone or specific apps?

Mine are on DigitalOcean. Someone else said VPSDime.com.

They were also often doing basic stuff, like database programming. Even in AI, most of what they produce didn't have marketable value. So, I don't buy that they couldn't find or train anyone here to do the job.

I made a utility, only partly done, to convert Avalonia files to HTML. It was intended to make cross-platform, Python/Tkinkter GUI's with HTML/Flask being a pit stop. Also, run them on QPython on Android. I got too busy to improve it past a few, form controls.

So, I think there's still potential to throw together an interface even if it can't do all of it. We do need a placeholder box that can be labeled for the controls we add manually but use its sizing info. Also, a converter that autoscales them in HTML or Qt to maintain the ratios that were in the VB6 app. For the placeholder, I was temporarily using that one control that's like a giant frame or box meant to contain others.

One reason I abandoned the idea is the AI's are so good now that we can probably just generate better GUI's from scratch or a basic, VB6 sketch. I couldn't justify the work until I try an AI with such projects. To avoid hallucinations or garbagr designs, might make sense to do the original program but AI-generate the transpiler.

Sometimes we just enjiy having a conversation with people. It's how we got many answers before Google exists. I believe such choices have many, positive effects on people that society is losing.

That's cheap, too. Which hosting service are you using?

I seriously thought that's what they were going to say. It seemed like it was setting up the reader to think the agent was about to use the exploit to escape the sandbox. Then, it was contained by Anthropic's security practices. But, if random people run things things, they couldn't be contained! They'll be a hoard of agents attacking the whole Internet!

Then, it was just that it made an exploit, and works really well, and people might use it instead of their products. Tragic for their investors I guess...

It's very exciting to see the work on combining AI models with static analysis, test generation, formal proof, and refactoring. All of these suggests we might see high assurance (EAL6+) developed rapidly in the future. At least for combinations of well-understood concepts.