I run my desktop OS on my Chromebook (boring Debian) and use it like a normal computer. All the ports (HDMI, usb) and so.

Back when Chromebooks and Netbooks were contemporaries, yours was a much harder proposition. I had an awful time getting Linux on my first gen Chromebook

I've heard that on the new ones they've illegally made it not possible anymore, but haven't experienced direct evidence of that yet. For mine I had to remove a screw from the motherboard but it wasn't that difficult. Not much worse than jumper for boot order in ye olde days

My suggestion? If you want a Chromebook to run Linux, look for surplus school laptops instead. My throwaround workshop laptop is an Asus that to me looks like it was clearly sold in an educational Chromebook format as well--partially ruggedized, partially waterproof, 12", N100, plastic blank where the camera should be, still only $120

Basically, if you're lucky, you can find Chromebook-class PCs with less restrictions. Admittedly I'm in a lucky locale for such things, but the one in question i bought from a normal retailer

The new procedure is boot without the battery connected to enable writing to flash.

If they're still allowing that it seems fine

The specs on this thing look pretty great. Which part do you find insufficient?

The CPU is just too underpowered; I'm sure it's fine for basic computery stuff, but building software and running medium/large test suites on it would be far too slow. Also not enough USB ports; I don't want to carry a USB hub with it.

Battery life on it is comparable to the MicroPC 2, but for the netbook form factor, it should really be compared to the Pocket 4. Similar story for the RAM, as well as the odd screen refresh rate.

Minor points: I do also appreciate the Ethernet ports on the GPD devices, and their approach to touchpads (buttons and placement in particular).

I guess my issues basically all boil down to the Minibook X not having enough functionality for the form factor when compared to GPD. That's mostly understandable for the price, but my point is just that if you're willing to fork over some more cash, you can get a whole lot more laptop in the same form factor (Pocket 4) or slightly better specs in a smaller form factor (MicroPC 2), and at least for me, that's the only way I could even have seriously considered these form factors for my work.

(Just to be clear, I have no particular brand loyalty to GPD; they're just the only player in town for high-end netbooks/UMPCs at the moment.)

> building software and running medium/large test suites on it would be far too slow

I'd figured remote development was the only viable workflow for these devices anyway?

Depends on what you're doing I suppose? I'm able to work on Zig with both of the devices I mentioned. Of course I'm limiting the test cases to the subset that's actually relevant to the area or target I'm working on. But that would be the case on a beefy full-size laptop too; even there, the full Zig test suite would take many hours and murder the battery in the process.

I've done all my dev work on devices much less powerful than this. After all, that's all that existed at the time :)

Certainly seems too high for that screen size. But probably not fatal

This is true but it's not really a security scenario. The LLM isn't an attacker it's just an unreliable tool.

Unreliable/stupid is worse than malice, here.

Let's ignore the fact that the LLM did an LPE, and let's assume it did it without malice.

It can still get infected and be used as an attack vector by some hidden prompt or some other equally advanced state of the art vuln like "disregard all previous instructions"

all unreliable tools are attackers. Even if you're using well-aligned LLMs like Opus, you should assume that any input you give it -- including all dependencies from npm, etc. -- are at risk of compromise, which could result in attempted exfiltration of data or system takeover. You can be absolutely sure that there are thousands of well-motivated hacker groups, both national and private, looking for ways in.

> don't have a form with just a login email and force the user to click to enter the password

This is required for any non trivial auth system though. You not know until the user is submitted if that user has a password or is using something else.

This is true but some sites handle it well. My browser auto-fills the email and password properly even though they are on separate "steps". Other sites the email field doesn't auto-complete in any way (but the password later usually does).

I don't know what the magic is here. If I had to guess they have both fields in the DOM but one is visually hidden. Then if your email is marked as SSO it is just never read.

Don't underestimate the magic in your browser's autofill :)

So what if we don't know? We can find out at the same time.

We're trying to authenticate a pair: user/pass.

There is no pair for the enterprise users signing in with their company's SSO or those using Passkey.

I think what some sites do is have a visually hidden, not required password field that a password manager can fill in. If it's not a password-based auth, the flow goes to the next step but if it is, it reveals the password field which may already be filled in.

How would you avoid that? How would someone exploit that information? The whole point of the other auth means are that they're more secure.

If someone enters a username that doesn't exist in the system then you randomly prompt for password or alternate method, so it looks like an account may exist.

Username enumeration isn't usually considered a vulnerability, but it does make other attacks, like credential stuffing, easier. I.E. you can focus attack resources on usernames that have active accounts.

It's very low on my list of concerns though, usually there's much worse problems when I pentest.

It's done that way as an overreaction to B2B customers which may want totally isolated per-tenant systems.

Take Okta login for example. Okta wants to offer big hyper-secure customers an option of "if you want, we can run our system in your cloud/data-center/whatever". To support that kind of system, you go to to the https://login.okta.com/ page and enter your email, JUST your email. Okta uses that to look up which customer tenant you belong to, then sends you to customer.okta.com where you enter your password. This way, the password only goes through infra owned by big-customer.

Okta then just builds everything with his indirection so they can move customers to it.

That doesn't seem relevant to responsive design? HTML and CSS are definitely responsive out of the box, but OTOH I remember how many designers of that era thought responsiveness was a bug and asked devs to add width:920px to body...

CSS, especially the box model, was not consistent across browsers.

True. Does not prevent the design from being responsive. Even with no CSS at all a design is responsive unless you specifically choose to break that

Right but how would you even display a vertical menu back then? `float: left` was rather bad, so you went back to using tables[0]. Good luck making these responsive.

[0]: and to using dozens of images sliced to fit your table cells, for that cool hover effect as well as round corners. :-)

Why would documents have menus? Menus are for applications.

And there was nothing wrong with tables for layout, especially back then when the alternatives were very brittle.

> Why would documents have menus? Menus are for applications.

s/menu/navigation

> And there was nothing wrong with tables for layout, especially back then when the alternatives were very brittle.

I never said there was anything wrong with tables. OP said there was nothing preventing the design from being responsive, to which I responded yes, there was, at least in a lot of cases.

(Responsiveness was also mostly irrelevant back then because smartphones were not a thing yet.)

I'd like to agree but I said the same thing about "mobile specific website" and somehow that's still a thing...

You against paying for things?

That's your takeaway from my question?

Only if we tie being fed to "working" which is a rather inhumane and untenable thing to do