joshka

Could he? To answer properly without possibly committing further possible crimes, he needed a lawyer familiar with whether that's allowable, something he was explicitly denied after asking multiple times. See https://www.courtlistener.com/docket/71998357/21/united-stat...

The problem is that cells don't compose well as an accessibility thing. You need a DOM equivalent in order to realistically do a bunch of things that are meaningful at an app level. TUI libraries are all basically doing that DOM thing already - just custom and treating the final shippable product as the cells, positions and imperative instructions for how to tell a terminal what to do. I' just saying that a more declarative interaction is very likely the sort of simple and boring that helps portability (long term) and speed.

If you're redesigning a protocol layer, then I'd say you still want to target fixed size cells as the unit of rendering. It's just not the central abstraction like it is in the current terminal approach. Because you're one step above here, you have th ability to do better border handling. There's a lot a things you miss trying to force borders through a character set thing (e.g. missing characters depending on your font, missing ability to position borders naturally, interaction with background color, adjustment of size and space of rendered text due to interaction with unicode characters and fixed positioning) ...

But in general, going with a fresh new protocol allows you to do a bunch of things semantically that are currently done as pure graphical stuff and that's useful.

The existence of a key only being somewhere other than your current location during a border search enables you to legally say "I cannot unlock this device" and move on with your day.

See https://www.cbp.gov/document/directives/cbp-directive-no-334...

> The border search will include an examination of only the information that is resident upon the device and accessible through the device's operating system or through other software, tools, or applications. Officers may not intentionally use the device to access information that is solely stored remotely. To avoid retrieving or accessing information stored remotely and not otherwise present on the device, officers will either request that the traveler disable connectivity to any network ( e.g., by placing the device in airplane mode and disabling Bluetooth and Wi-Fi connections) or where warranted by national security, law enforcement, officer safety, or other operational considerations, officers will themselves disable network connectivity. Officers should also take care to ensure, throughout the course of a border search, that they do not take actions that would make any changes to the contents of the device.

and

> Passcodes or other means of access obtained during a border inspection will only be utilized to facilitate the inspection of devices and information subject to border search. Passcodes or other means of access may not be utilized to access information that is only stored remotely. Passcodes or other means of access should only be recorded by the officer in a temporary format and should not be uploaded into CBP systems. Passcodes or other means of access recorded by the officer will be deleted or destroyed when no longer needed to facilitate the search of a given device.

I'm talking specifically about the graphene OS ability for that approach, not the ability to add an external key to some generalized encryption. The threat model here is that the traveler was required to provide a passcode unlocking a key they had with them on their phone. If that threat is not there, then this bypasses problem.

Not really - the government have stated that he's in the US. It's the first sentence of the indictment. [1]

> On or about January 24, 2025, in the Northern District of Georgia...

[1]: https://storage.courtlistener.com/recap/gov.uscourts.gand.35...

But in general, the thing to note here is that the 4th amendment is always applicable and in force. It's how it's interpreted that changes depending on the circumstance.

I really liked this article (despite disagreeing with its conclusion and agreeing with many of the concerns about failures of TUIs). It gave a feeling of "here's a bunch of cool stuff I've done" to help back the claim, which is far more personal than a lot of blog posts tend to be.

As a ratatui library maintainer, NO - please don't stop making TUIs ;)

As a developer outside of that, I love the scratch the itch apps stuff mentioned in here. I have a vibe coded SwiftUI chess repertoire builder app that fits in that same sort of space that I'm currently working on, where I'd probably not have chosen to explore the idea if not for coding agents.

I agree with the article that the terminal is an odd shape which you're fighting against historical specs, etc. The key observation I have though is that the mismatch of terminal apps and libraries to deal with this are all fundamentally built around character cells and cursor movement plus various CSI/OSC/ASC/DEC/xterm/... protocols which are complex and have varying support and interact in weird ways.

To get a good terminal UX, I think the answer to this is probably to throw all that compatibility mess away and redesign a modern terminal protocol that bakes in accessibility, regions, scrolling, selection, proper keyboard, etc.

I know Mitchell Hashimoto has a bit of a different perspective on this, which seems like it's to define some more protocol stuff and continue to build up on things. I think that probably gets to 95% pretty well. But a 100% good is a full replacement.

So the part of this that feels like it triggers the government issue here is that in effect you have a locally stored encryption key which gates access to the device, which was removed from the device due to duress password.

What if we flipped this to instead be something that's explicitly not on the device?

The border search stuff only applies to information on the device. It cannot compel you to provide access to e.g. emails stored in a cloud provider.

If instead of making the process of stopping searches like this be a destructive one, we instead pre-purge the key but store it offsite with the ability to get it from an online location, then this feels like it's probably reasonable here. In the sense that the 4th amendment explicitly allows "The right of the people to be secure in their persons, houses, papers, and effects, ..."

There's probably some sort of technical problem I'm missing here (or maybe this functionality is available already).

I'm just guessing here, but the most problematic word on the 4th amendment to attack from the government's perspective is "unreasonable". It's easy to see how a phone border search could be construed as reasonable, and (without digging into this deeply) I suspect that's where most of the push back on this will be.

I suspect the 5th amendment is probably more valuable to the defense here as the password is effectively testimonial and the give us your password or we'll ... is compelled speech.

Either way, it's gonna be many 10s of thousands of dollars in lawyers fees to fight this. Which sucks.

It's a fairly shallow point that ignores how laws work.

The premise that the law doesn't apply because you're not in the country is false. The constitution applies generally everywhere to all Americans, it's just that what's regarded as reasonable differs during a border search. IANAL, so just my lay opinion on this. Just to validate this, it's only because the constitution exists that the border authorities have any legal basis in doing inspections.

This feels like a really good blog post to write - something I'd really want to read - but the generated AI prose distracts, and makes me lose trust and not want to read this. I'm very AI-pilled, so this is not a criticism of AI as a whole, just this piece.

This feels like the sort of decision that well meaning folks that manage utilities can disagree on. It's frustrating every time it happens because it's usually a fairly reasonable perspective to ask for XDG / operating system specific support for folders to be respected. (e.g. macOS's ~/Library stuff).

Posting a github issue like this though feels like an easy brigading target, so please don't do that.

https://hckrnews.com/ most days, has a good line which tracks what you saw last. Sometimes filter by top 10/20 when I've been more busy and to catch things I may have glossed over as being more popular.

The current thing that comes up regularly is choosing an LLM setup.

lol same :D

This, but I'd say that there is an engineering perspective that you can apply. What the developer world is trying to discover here is how to encode taste concretely - often this is things like really mechanical design system things (space/padding/margins/relative sizes/color contrast/...).

The hard point is doing that well deterministically in a way that is token efficient and which can be iterated on. I suspect it's difficult to encode that into an AI model of what's good taste.

I've done VHS (terminal recording) rewrite in rust built on libghostty called Betamax [1], and then threw it at creating a TUI for jujutsu. This worked pretty well, but is admittedly a much simpler task than a web ui. The harness was able to build out a feature, confirm it worked, find bugs in what it expected vs saw and fix them with evidence. Web is many more pixels and more nuanced things that have to do with how various elements relate.

I speculate that maybe the OpenAI models have the edge here over Claude's (while still being terrible at web UIs), as the training necessary to handle computer use stuff is heavily image processing based. I wouldn't bet on either being bad for much longer though.

[1]: https://www.joshka.net/betamax/

Take a look also at https://tropes.fyi/

I've put in some effort to try to help agentic tools avoid these problems: https://www.joshka.net/practice/rules/documentation/docs-avo....

Some agents have specific tools that the models have been trained to use. E.g. diff formats for editing that aren't the same as the standard unified diff format. Access to specific thread / subagent / etc. tooling or the base prompt can perhaps also impact how the tasks are completed.

Yeah, what bothers me is that the prompt already said using a different vulnerability didn’t count, and the model did it anyway. We’re starting to assume clear instructions act as real constraints, but here the measurable goal seems to have won out and the rest became flexible. That gets pretty worrying once the agent has enough capability and access to find its own shortcuts.

The exploit gym setup explicitly allowed access to package registries and v8 sources. Putting a cache on that doesn't seem like a bad idea generally, except when there's a 0-day in the cache :D But yeah, for this sort of thing I'd be locking down very specific egress things and putting alerts on it that are entirely outside of the red network.

> I would argue that it's negligence and that's aside from the fact that if a human did this there would actually be repercussions.

I’m not sure “negligence” follows just from the controls turning out to be insufficient. Research involves mistakes, especially around novel failure modes. The question is whether the precautions were unreasonable given what they knew at the time, rather than whether hindsight suggests stronger controls would have helped. Doing it twice though would be negligent.

Caveat: I’ve worked with some of the people involved, so I’m probably biased toward a charitable reading.

Thanks for the reply here.

I guess I have some perspectives on a bunch of this. I'm for open sharing of academic work for all (but I'm not an academic, so my perspective is a consumer), so inferring your perspective here I think we agree on that. I maintain many open source (MIT/Apache2 licensed) libraries, and I've also worked in big tech (Amazon, OpenAI). I believe both in the idea of collective commons but also in the ideas that there should be the ability of people to sell software. There's tension in that social contract similarly, and it gets more complex when you look at copyleft.

I guess I'd be disappointed if this was just allowing big labs access and not more broadly allowing access to the ACM library for smaller open source models. Very much in agreement with your last points there.

This is freaking good.

How do you square away the idea that you do science for the increase in knowledge of human kind, but then say that a particular use of that knowledge is verboten?

I get the copyright aspect of this and I'm not arguing that here. I'm more asking about the moral / ethical idea of choosing who can benefit from your science.

Obviously there are the moral / ethical arguments about AI in general here to weigh against - those have been hashed out significantly elsewhere, and I'm not interested in debating them. What I'm asking about here is the impact on science by sharing it with tooling that distributes it in ways not generally considered when originally written.

A quick check of your post history suggests the frame that you work in strongly is privacy related research (observation - may be wrong). I'm curious how that impacts what you wrote here generally.

(Just to be perfectly clear, I'm not arguing your points here, trying to understand them better)

Consider optimizing your demo for laptop user screen sizes and checking contrast of all elements. A lot of things on the demo are difficult to read fast due to low contrast, which makes animations using them less useful to show off what is actually happening.

discussion / article: https://news.ycombinator.com/item?id=49087091

https://huggingface.co/blog/agent-intrusion-technical-timeli... has that side of the write up a bit more

discussion: https://news.ycombinator.com/item?id=49089500

Makes you wonder whether that reality has a left wing bias quote might have some legs after all (though it's probable more likely selection bias for the corpora)