Raises the obvious question of why not using the wayland protocol (on another socket, not on the compositor socket). It has mature implementations in many languages, an IDL with compilers, and every GUI application is already going to link to libwayland anyway.
> Make clients store a cookie or something and only reply if they prove ownership of it
Unix domain socket authentication is stronger and doesn't require storing cookies on the client side.
> what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway.
Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch.
> I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Then don't use it? Secure defaults matter for most users.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
> Unix domain socket authentication is stronger and doesn't require storing cookies on the client side.
And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands.
> Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch.
In which case they do not connect to the same D-Bus "bus", and the problem is again non-existent. See how flatpak sandoxing does it.
> Then don't use it? Secure defaults matter for most users.
Right until they notice they can no longer view the keyring contents, or any other stupid limitation most desktop users couldn't care about.
In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
Since docker, we know how to do pretty good isolation (some of the tech is shared by Flatpak etc. sandboxes) - just put stuff into different namespaces with some auth api allowing processes to 'mount' the necessary stuff.
The closer you stick to the kernel security model, the more likely your app will be safe and performant, and the less likely other devs will reject it in favor of their hand rolled stuff.
> In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
If I store my secrets in KWallet, which purports to _storage for secrets_, I absolutely do not expect every application on the desktop to have access to those secrets, whether I want to share them or not.
I can't believe you're suggesting this is sanely defensible.
> And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands.
I disagree. With UNIX domain sockets it is absolutely possible to determine the PID of the process that you are talking to and use pidfd to validate where it is coming from. Would be entirely possible to use this for policy.
> In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop. It usually gets keymatter in the form of a user password carried to it from PAM, in order to allow on-disk encryption without needing separate keyring passwords. (And yeah, sure, this could use TPM or something else to avoid the passwords, but the point is literally no different, it shouldn't be each application's job individually to manage their own way of getting secure storage, that's a recipe for data loss and confusion.)
> Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
That's a problem that occurs because the protocols have multiple distinct implementations. Most of the dbus services don't have to deal with that problem at all. (And the ones that do, tend to have problems like this. There are plenty of weird incompatibilities with different XDG desktop portal implementations.)
I'm pretty sure the point of bringing up xdg-shell is because the new bus is inspired by the Wayland protocol. For all of the incessant bitching about Wayland online, Wayland protocols are only about 1000x nicer to use than dbus. You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.)
> With UNIX domain sockets it is absolutely possible to determine the PID of the process that you are talking to and use pidfd to validate where it is coming from.
Validate what? You're just moving the responsibility to whatever answer you give here. If you say "validate the exec name is firefox-bin" then the next person who comes in will say "I hate $your_new_fangled_ipc, you can make it dump all your secrets by renaming your exec to firefox-bin". (This is just an example).
> And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop.
The more I think of it, the less sense this makes. If you already have a system where applications cannot read each other's data, what is the point of secret service? What is the security advantage?
If you want to encrypt with TPM, fingerprint, or anything else, that's encryption, which is separate from storage (you can encrypt the password with say a PCR but the application gets to store the encrypted password in any way they want).
Password encryption in the desktop keyrings are for the situation for when every application can read each other's data files easily (again, as in the desktop). In which case, it may make sense to use encryption so that such data is not (trivially) accessible from any other application (otherwise https://developer.pidgin.im/wiki/PlainTextPasswords applies) .
If your applications are already running sandboxed, a keyring sounds to me like useless complexity? Just make each application store its data into its sandbox.
The funny/sad detail is that the 80s (at the latest) already solved the problem. Have a look as XDR and Sun RPC. It has both strongly typed APIs and versioning built in. You would have to come up with your authentication mechanism for applications e.g. have them send a cookie file (descriptor).
> we started rolling out an increase to our buffer size to 1MB, the default limit allowed by Next.js applications.
Why is the Next.js limit 1 MB? It's not enough for uploading user generated content (photographs, scanned invoices), but a 1 MB request body for even multiple JSON API calls is ridiculous. There frameworks need to at least provide some pushback to unoptimized development, even if it's just a lower default request body limit. Otherwise all web applications will become as slow as the MS office suite or reddit.
Index investors aren't exposed to IPOs, since the common indexes (SPX etc) don't include IPOs (and if you invest in a YOLO index that does, that's on you).
Also:
> The US led a sharp rebound, driven by a surge in IPO filings and strong post-listing returns following the Federal Reserve’s rate cut.
> It's kind of funny, you can ask Rufus for stuff like "write a hello world in python for me" and then it will do it and also recommend some python books.
Interesting, I tried it with the chatbot widget on my city government's page, and it worked as well.
I wonder if someone has already made an openrouter-esque service that can connect claude code to this network of chat widgets. There are enough of them to spread your messages out over to cover an entire claude pro subscription easily.
A childhood internet friend of mine did something similar to that but for sending SMSes for free using the telco websites' built in SMS forms. He even had a website with how much he saved his users, at least until the telcos shut him down.
Well Phreaking in 2003-05 (no clue when anymore), so at the same time you could still get free phone calls on pay phones in the library or hotel lobby.
Not sure for Claude Code specifically, but in the general case, yes - GPT4Free and friends.
I think if you run any kind of freely-accessible LLM, it is inevitable that someone is going to try to exploit it for their own profit. It's usually pretty obvious when they find it because your bill explodes.
Apart from the obvious compatibility disaster, what kind of skeletons does Microsoft have in their printing system that the choice of C library creates those compatibility issues in the first place?
The UCRT is just the newer, Windows-component version of the MSVCRT, the one they’re worried about. It’s even available for XP.
> will intentionally fail to print to remote print servers
Why would a more secure local print driver refuse to talk to _remote_ print servers? What is so untrustable about what comes over the wire, and if it is, how can they trust the print server is or is not one is claims to be and can be talked to?
My guess is it’s riddled with vulnerabilities. I used to write some print management software and found it very easy to crash the spooler just from routine API calls.
Not only that but it seemed every time they fixed a vulnerability some piece of functionality broke.
(Or perhaps even COM)
reply