> IMO systems should be shipped in "Setup Mode" by default with no keys preinstalled. On first boot which ever OS you decide to install should be able to enroll its keys.
I don’t think this works with the security model of secure boot. The secure boot rom is supposed to sit above the OS - as in, it’s more privileged than the OS. A compromise in the OS can’t lead to a compromise in secure boot. (And if it could, why even bother with secure boot in the first place?)
If the OS could enrol whatever keys it wants, then malware could enrol its own malware keys and completely take over the system like that. And if that’s possible then secure boot provides no value.
The enrolling of the certs happen before the bootloader calls `ExitBootServices()` (I think that is what the function was called). Up until then the bootloader still has elevated priviledges and can modify certain UEFI stuff it can't after, including enrolling certs.
systemd-boot can do that if you force it to (only does it by default on VMs cuz expectedly UEFI implementations in the wild are kinda shit)[1, 2]
No, there's nothing special about the spec secure boot variables as far as boot services goes - you can modify those in runtime as well. We use boot service variables to protect the MOK key in Shim, but that's outside what the spec defines as secure boot.
Yeah I’m curious how much the moat of big software companies will shrink over the next few years. How long before I can ask a chatbot to build me a windows-like OS from scratch (complete with an office suite) and it can do a reasonable job?
And what happens then? Will we stop using each others code?
Yeah I’m having a similar experience. I’ve been wanting a standard test suite for JMAP email servers, so we can make sure all created jmap servers implement the (somewhat complex) spec in a consistent manner. I spent a single day prompting Claude code on Friday, and walked away with about 9000 lines of code, containing 300 unit tests for jmap servers. And a web interface showing the results. It would have taken me at least a week or two to make something similar by hand.
There’s some quality issues - I think some of the tests are slightly wrong. We went back and forth on some ambiguities Claude found in the spec, and how we should actually interpret what the jmap spec is asking. But after just a day, it’s nearly there. And it’s already very useful to see where existing implementations diverge on their output, even if the tests are sometimes not correctly identifying which implementation is wrong. Some of the test failures are 100% correct - it found real bugs in production implementations.
Using an AI to do weeks of work in a single day is the biggest change in what software development looks like that I’ve seen in my 30+ year career. I don’t know why I would hire a junior developer to write code any more. (But I would hire someone who was smart enough to wrangle the AI). I just don’t know how long “ai prompter” will remain a valuable skill. The AIs are getting much better at operating independently. It won’t be long before us humans aren’t needed to babysit them.
So what'd your prompt look like, out of curiosity? I hear about all these things that sound quite impressive, but no one ever seems to want share any info on the prompts to learn or gain insight from.
It was nothing special. I can't seem to pull up the initial prompt, but it was something like this:
> Build a thorough test suite for JMAP in this directory. The test suite will be run against multiple JMAP servers, to ensure each server implements the JMAP spec consistently and correctly. In this directory are two files - rfc8620.txt and rfc8621.txt. These files containing the JMAP core and JMAP email specs. Read these files. Then make a list of all aspects of the specifications. For each, create a set of tests which thoroughly tests all aspects of a JMAP server's behaviour specified by the RFCs, including error behaviour. The test suite should be configurable to point at a jmap server & email account. The account will contain an empty mailbox (error if its not empty). The test suite starts by adding a known set of test emails to the account, then run your tests and clear the inbox again. Write the test suite in typescript. The test runner should output the report into a JSON file. Start with a project plan.
If you haven't tried claude code or openai's codex, just dive in there and give it a go. Writing a prompt isn't rocket science. Just succinctly say the same things you'd say to a very competent junior engineer when you want to brief them on some work.
Sorry just asking. I used to review CVs part time. It used to be pretty clear who was embellishing their CV with AI and who was not. There was also a writing style that came with using AI.
:( I get this from time to time, where people think my writing is at least partially AI generated. I wonder if it’s worth trying to change my writing style to avoid the stigma. If I hand wrote a CV, it would suck to be dumped in with AI generated slop. More small pithy sentences? or throw in some spelling and grammar mistakes? Bleh.
Eh. I worked at a company which made an extension which scraped LinkedIn. We provided a service to recruiters, who would start a hiring process by putting candidates into our system.
The recruiters all had LinkedIn paid accounts, and could access all of this data on the web. We made a browser extension so they wouldn’t need to do any manual data entry. Recruiters loved the extension because it saved them time.
I think it was a legitimate use. We were making LinkedIn more useful to some of their actual customers (recruiters) by adding a somewhat cursed api integration via a chrome extension. Forcing recruiters to copy and paste did’t help anyone. Our extension only grabbed content on the page the recruiter had open. It was purely read only and scoped by the user.
Doesn't sound like your operation was particularly questionable, but I can imagine there must be some of those 3,000 extensions where the data flow isn't just "DOM -> End User" but more of a "Dom -> Cloud Server -> ??? -> Profit!" with perhaps a little detour where the end user gets some value too as a hook to justify the extension's existence.
I started their but it felt like a dodgy way (as it could be seen to be illegal).
We then just went aloffical and went through Google search API’s with LinkedIn as the target.
Worked a treat and was cheaper than recruiter!!!
So when pay the highest scraper, it’s ok! Same data, different manner.
Yeah, but thinking with an LLM is different. The article says:
> By “thinking hard,” I mean encountering a specific, difficult problem and spending multiple days just sitting with it to overcome it.
The "thinking hard" I do with an LLM is more like management thinking. Its chaotic and full of conversations and context switches. Its tiring, sure. But I'm not spending multiple days contemplating a single idea.
The "thinking hard" I do over multiple days with a single problem is more like that of a scientist / mathematician. I find myself still thinking about my problem while I'm lying in bed that night. I'm contemplating it in the shower. I have little breakthroughs and setbacks, until I eventually crack it or give up.
YMMV, but I've found that I actually do way more of that type of "thinking hard" thanks to LLMs. With the menial parts largely off my plate, my attention has been freed up to focus on a higher density of hard problems, which I find a lot more enjoyable.
Yup, there is a surprisingly high amount of boilerplate in programming, and LLMs definitely can remove this and let you focus on the more important problems. For a person with a day job, working on side projects actually became fun with LLMs again, even with the limitation of free time and mental energy to invest in.
I feel this too. I suspect its a byproduct of all the context switching I find myself doing when I'm using an LLM to help write software. Within a 10 minute window, I'll read code, debug a problem, prompt, discuss the design, test something, do some design work myself and so on.
When I'm just programming, I spend a lot more time working through a single idea, or a single function. Its much less tiring.
I've been arguing for this for years. There's no reason every random binary should have unfettered, invisible access to everything on my computer as if it were me.
iOS and Android both implement these security policies correctly. Why can't desktop operating systems?
The short answer is tech debt. The major mobile OSes got to build a new third party software platform from day 0 in the late 2000s, one which focused on and enforced priorities around power consumption and application sandboxing from the getgo etc.
The most popular desktop OSes have decades of pre-existing software and APIs to support and, like a lot of old software, the debt of choices made a long time ago that are now hard/expensive to put right.
The major desktop OSes are to some degree moving in this direction now (note the ever increasing presence of security prompts when opening "things" on macOS etc etc), but absent a clean sheet approach abandoning all previous third party software like the mobile OSes got, this arguably can't happen easily over night.
Mobile platforms are entirely useless to me for exactly this reason, individual islands that don't interact to make anything more generally useful. I would never use any os that worked like that, it's for toys and disposable software only imo.
Mobile platforms are far more secure than desktop computing software. I'd rather do internet banking on my phone than on my computer. You should too.
We can make operating systems where the islands can interact. Its just needs to be opt in instead of opt out. A bad Notepad++ update shouldn't be able to invisibly read all of thunderbird's stored emails, or add backdoors to projects I'm working on or cryptolocker my documents. At least not without my say so.
I get that permission prompts are annoying. There are some ways to do the UI aspect in a better way - like have the open file dialogue box automatically pass along permissions to the opened file. But these are the minority of cases. Most programs only need to access to their own stuff. Having an OS confirmation for the few applications that need to escape their island would be a much better default. Still allow all the software we use today, but block a great many of these attacks.
Both are true, and both should be allowed to exist as they serve different purposes.
Sound engineers don't use lossy formats such as MP3 when making edits in preproduction work, as its intended for end users and would degrade quality cumulatively. In the same way someone working on software shouldn't be required to use an end-user consumption system when they are at work.
It would be unfortunate to see the nuance missed just because a system isn't 'new', it doesn't mean the system needs to be scrapped.
> In the same way someone working on software shouldn't be required to use an end-user consumption system when they are at work.
I'm worried that many software developers (including me, a lot of the time) will only enable security after exhausting all other options. So long as there's a big button labeled "Developer Mode" or "Run as Admin" which turns off all the best security features, I bet lots of software will require that to be enabled in order to work.
Apple has quite impressive frameworks for application sandboxing. Do any apps use them? Do those DAWs that sound engineers use run VST plugins in a sandbox? Or do they just dyld + call? I bet most of the time its the latter. And look at this Notepad++ attack. The attack would have been stopped dead if the update process validated digital signatures. But no, it was too hard so instead they got their users' computers hacked.
I'm a pragmatist. I want a useful, secure computing environment. Show me how to do that without annoying developers and I'm all in. But I worry that the only way a proper capability model would be used would be by going all in.
There is a middle ground (maybe even closer to more limited OS design principles) exist. It is not just toys. Otherwise neither UWP on Windows nor Flatpaks or Firejail would exist nor systemd would implement containerization features.
In such a scenario, you can launch your IDE from your application manager and then only give write access to specific folders for a project. The IDE's configuration files can also be stored in isolated directories. You can still access them with your file manager software or your terminal app which are "special" and need to be approved by you once (or for each update) as special. You may think "How do I even share my secrets like Git SSH keys?". Well that's why we need services like the SSH Agent or Freedesktop secret-storage-spec. Windows already has this btw as the secret vaults. They are there since at least Windows 7 maybe even Vista.
If a sandbox is optional then it is not really a good sandbox
naturally even flatpak on Linux suffers from this as legacy software simply doesn’t have a concept of permission models and this cannot be bolted on after the fact
The containers are literally the "bolting on". You need to give the illusion of the software is running under a full OS but you can actually mount the system directories as read-only.
and you still need to mount volumes and add all sorts of holes in the sandbox for applications to work correctly and/or be useful
try to run gimp inside a container for example, you’ll have to give access to your ~/Pictures or whatever for it to be useful
Compared to some photo editing applications on android/iOS which can work without having filesystem access by getting the file through the OS file picker
What we need is a model similar to Google+ circles if anyone can remember that.
Basically a thing that I could assign 1) apps and 2) content to. Apps can access all content in all circles they are assigned to. Circles can overlap arbitrarily so you can do things like having apps A,B,C share access to documents X,Y but only A,B have access to Z etc.
Top 0.04% here. Apparently I could have written 1.97 volumes of game of thrones with my HN comments (590 000 words). I don't know whether to be proud or embarrassed. I think I'm a little of both.
I'd love to see some opensource projects actually do a good job of this. Its a lot of work, especially if you want:
- Good cross platform support (missing in filepilot)
- Want applications to feel native everywhere. For example, all the obscure keyboard shortcuts for moving around a text input box on mac and windows should work. iOS and Android should use their native keyboards. IME needs to work. Etc
- Accessibility support for people who are blind and low vision. (Screen readers, font scaling, etc)
- Ergonomic language bindings
Hitting these features is more or less a requirement if you want to unseat electron.
I think this would be a wonderful project for a person or a small, dedicated team to take on. Its easier than it ever used to be thanks to improvements in font rendering, cross platform graphics libraries (like webgpu, vulcan, etc) and improvements in layout engines (Clay). And how much users have dropped their standards for UI consistency ever since electron got popular and microsoft gave up having a consistent UI toolkit in windows.
There are a few examples of teams doing this in house (eg Zed). But we need a good opensource project.
I don’t think this works with the security model of secure boot. The secure boot rom is supposed to sit above the OS - as in, it’s more privileged than the OS. A compromise in the OS can’t lead to a compromise in secure boot. (And if it could, why even bother with secure boot in the first place?)
If the OS could enrol whatever keys it wants, then malware could enrol its own malware keys and completely take over the system like that. And if that’s possible then secure boot provides no value.
reply