(Before you react: I think these laws are pointless and dumb too, but they're still laws so here we are)
Hi all, I saw a lot of talk about the new California (and pending Colorado) laws about requiring operating systems to provide an API to return a user's age bracket to applications. While I think most people agree that this is asinine, pointless, full of holes, open to abuse, etc. etc., it's also a legal requirement anyway.
I've been playing with Claude Code lately and so I thought this would be a useful experiment - a small, self-contained project with a finite surface area and well-defined requirements. I should say the experiment wasn't whether Claude could do this, but whether I could provide decent instructions for Claude to do this and what level of detail I could get away with.
Anyway, here's my latest project - aged, the age daemon. It's a straightforward app that I could have written myself despite being new to Rust, but the real experiment was in the extra features that I had it create that I might not have gotten around to if I were just doing it myself, such as:
1. Support for three different packaging formats - .deb, RPM, and Arch Linux (which I have never used outside of docker base images)
2. An included systemd service file to run as a user daemon, with as locked-down of permissions as I could manage (I had to remove some restrictions that Claude added because users can't use them but systemd won't just ignore them)
3. Configuration files allowing the definition of multiple legal jurisdictions and separate rules for each
4. Multiple storage backends to store the user's birthday, defaulting to the system's SecretStore (i.e. keychain) but also supporting e.g. just storing it in a local file
5. Multiple frontends, including a D-Bus API and a CLI; it also supports systemd d-bus activation when running on Linux with Systemd, but this is optional.
So, here we are. I would love any feedback people have on anything that isn't how stupid these laws are. Areas of note are:
1. Code quality - I'm not an experienced Rust developer so maybe this code is trash, but it seems better than I would have written.
2. Security and privacy of the implementation. For example, perhaps being able to access the user's age bracket via the CLI should be considered insecure and only the D-Bus interface should be accessible.
3. Legal compliance. Did I or Claude miss anything in the laws that makes this software not compliant? Or is there anything that was implemented but doesn't need to be and should be removed?
4. IIRC there's been discussion but no decisions on any sort of official D-Bus API; if I'm wrong, then the daemon needs to be updated to support those.
5. The packaging! I don't have an RPM or Arch system to test on, so I've been restricted to just testing things locally in docker containers and hoping it's working properly. If not, I would love to fix this. Proper distro packaging is something I'm passionate about so I would love more feedback if anything is done poorly or in a cumbersome way.
TL;DR like it or not, these laws are coming and distros need to be compliant. Maybe this project or others like it will be useful to the Linux community despite everything.
0 comments
—
Show HN: A user daemon to provide an age-bracketing API · HackerTrans
Hi all, I saw a lot of talk about the new California (and pending Colorado) laws about requiring operating systems to provide an API to return a user's age bracket to applications. While I think most people agree that this is asinine, pointless, full of holes, open to abuse, etc. etc., it's also a legal requirement anyway.
I've been playing with Claude Code lately and so I thought this would be a useful experiment - a small, self-contained project with a finite surface area and well-defined requirements. I should say the experiment wasn't whether Claude could do this, but whether I could provide decent instructions for Claude to do this and what level of detail I could get away with.
Anyway, here's my latest project - aged, the age daemon. It's a straightforward app that I could have written myself despite being new to Rust, but the real experiment was in the extra features that I had it create that I might not have gotten around to if I were just doing it myself, such as:
1. Support for three different packaging formats - .deb, RPM, and Arch Linux (which I have never used outside of docker base images)
2. An included systemd service file to run as a user daemon, with as locked-down of permissions as I could manage (I had to remove some restrictions that Claude added because users can't use them but systemd won't just ignore them)
3. Configuration files allowing the definition of multiple legal jurisdictions and separate rules for each
4. Multiple storage backends to store the user's birthday, defaulting to the system's SecretStore (i.e. keychain) but also supporting e.g. just storing it in a local file
5. Multiple frontends, including a D-Bus API and a CLI; it also supports systemd d-bus activation when running on Linux with Systemd, but this is optional.
So, here we are. I would love any feedback people have on anything that isn't how stupid these laws are. Areas of note are:
1. Code quality - I'm not an experienced Rust developer so maybe this code is trash, but it seems better than I would have written.
2. Security and privacy of the implementation. For example, perhaps being able to access the user's age bracket via the CLI should be considered insecure and only the D-Bus interface should be accessible.
3. Legal compliance. Did I or Claude miss anything in the laws that makes this software not compliant? Or is there anything that was implemented but doesn't need to be and should be removed?
4. IIRC there's been discussion but no decisions on any sort of official D-Bus API; if I'm wrong, then the daemon needs to be updated to support those.
5. The packaging! I don't have an RPM or Arch system to test on, so I've been restricted to just testing things locally in docker containers and hoping it's working properly. If not, I would love to fix this. Proper distro packaging is something I'm passionate about so I would love more feedback if anything is done poorly or in a cumbersome way.
TL;DR like it or not, these laws are coming and distros need to be compliant. Maybe this project or others like it will be useful to the Linux community despite everything.