The die is certainly not multi-terabyte. A more realistic number would be 32k-sided to 50k-sided if we want to go with a pretty average token vocabulary size.
Really, it comes down to encoding. Arbitrarily short utf-8 encoded strings can be generated using a coin flip.
Of course, it's random and by chance - tokens are literally sampled from a predicted probability distribution. If you mean chance=uniform probability you have to articulate that.
It's trivially true that arbitrarily short reconstructions can be reproduced by virtually any random process and reconstruction length scales with the similarity in output distribution to that of the target. This really shouldn't be controversial.
My point is that matching sequence length and distributional similarity are both quantifiable. Where do you draw the line?
> Of course, it's random and by chance - tokens are literally sampled from a predicted probability distribution.
Picking randomly out of a non-random distribution doesn't give you a random result.
And you don't have to use randomness to pick tokens.
> If you mean chance=uniform probability you have to articulate that.
Don't be a pain. This isn't about uniform distribution versus other generic distribution. This is about the very elaborate calculations that exist on a per-token basis specifically to make the next token plausible and exclude the vast majority of tokens.
> My point is that matching sequence length and distributional similarity are both quantifiable. Where do you draw the line?
Any reasonable line has examples that cross it from many models. Very long segments that can be reproduced. Because many models were trained in a way that overfits certain pieces of code and basically causes them to be memorized.
Right, and very short segments can also be reproduced. Let's say that "//" is an arbitrarily short segment that matches some source code. This is trivially true. I could write "//" on a coin and half the time it's going to land "//". Let's agree that's a lower bound.
I don't even disagree that there is an upper bound. Surely reproducing a repo in its entirety is a match.
So there must exist a line between the two that divides too short and too long.
Again, by what basis do you draw a line between a 1 token reproduction and a 1,000 token reproduction? 5, 10, 20, 50? How is it justified? Purely "reasonableness"?
There are very very long examples that are clearly memorization.
Like, if a model was trained on all the code in the world except that specific example, the chance of it producing that snippet is less than a billionth of a billionth of a percent. But that snippet got fed in so many times it gets treated like a standard idiom and memorized in full.
Is that a clear enough threshold for you?
I don't know where the exact line is, but I know it's somewhere inside this big ballpark, and there are examples that go past the entire ballpark.
I care that it's within the ballpark I spent considerable detail explaining. I don't care where inside the ballpark it is.
You gave an exaggerated upper limit, so extreme there's no ambiguity, of "entire repo".
I gave my own exaggerated upper limit, so extreme there's no ambiguity. And mine has examples of it actually happening. Incidents so extreme they're clear violations.
Maybe an analogy will help: The point at which a collection of sand grains becomes a heap is ambiguous. But when we have documented incidents involving a kilogram or more of sand in a conical shape, we can skip refining the threshold and simply declare that yes heaps are real. Incidents of major LLMs copying code, in a way that is full-on memorization and not just recreating things via chance and general code knowledge, are real.
You're the only person I've seen ever imply that true copying incidents are a statistical illusion, akin to a random die. Normally the debate is over how often and impactful they are, who is going to be held responsible, and what to do about them.
To recap, the original statement was, "Llm's do not verbatim disgorge chunks of the code they were trained on." We obviously both disagree with it.
While you keep trying to drag this toward an upper bound, I'm trying to illustrate that a coin with "//" reproduces a chunk of code. Again. I don't see much of a disagreement on that point either. What I continue to fail to elicit from you is the salient difference between the two.
I'm trying to find a scissor that distills your vibes into a consistent rule and each time it's the rebutted like I'm trying to make an argument. If your system doesn't have consistency, just say so.
I have a consistent rule. The rule is that if an LLM meets the threshold I set then it definitely violated copyright, and if it doesn't meet the threshold then we need more investigation.
We have proof of LLMs going over the threshold. So that answers the question.
Your illustrations are all in the "needs more investigation" area and they don't affect the conclusion.
We both agree that 1 token by itself is fine, and that some number is too many.
So why do you keep asking about that, as if it makes my argument inconsistent in some way? We both say the same thing!
We don't need to know the exact cutoff, or calculate how it varies. We only need to find violators that are over the cutoff.
How about you tell me what you want me to say? Do you want me to say my system is inconsistent? It's not. Having an area where the answer is unclear means the system is not able to answer every question, but it doesn't need to answer every question.
If you're accusing me of using "vibes" in a way that ruins things, then I counter that no I give nice specific and super-rare probabilities that are no more "vibes" based than your suggestion of an entire repo.
> What I continue to fail to elicit from you is the salient difference between the two.
Between what, "//" and the threshold I said?
The salient difference between the two is that one is too short to be copyright infringement and the other is so long and specific that it's definitely copyright infringement (when the source is an existing file under copyright without permission to copy). What more do you want?
Just like 1 grain of sand is definitely not a heap and 1kg of sand is definitely a heap.
If you ask me about 2, 3, 20 tokens my answer is I don't care and it doesn't matter and don't pretend it's relevant to the question of whether LLMs have been infringing copyright or not ("verbatim disgorge chunks").
Not widely known but the original Binder, OpenBinder, was not even for Linux or Android It was developed for BeOS.
OpenBinder was one of the few pieces of code which was open sourced in Be Inc’s dying days just before it was acquired by Palm.
Many of the principal Be developers who worked on OpenBinder, Dianne Hackborn, Jean-Baptiste Queru, et al then moved from Palm to Danger, which was developing Android and which was later acquired by Google.
Considering that any new implementation of Binder userspace would realistically also be incompatible with Android Binder, what would really be the gain here? You'd basically have yet another wire protocol that nobody else uses but now also depends on having a obscure Linux feature enabled.
Why would it need to be a new implementation? AOSP is like... right there, and it's not like libbinder has crazy dependencies.
> also depends on having a obscure Linux feature enabled
An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development. With the only real reason it's obscure on desktop linux at all is because upstream blocked it for a long time. If desktop linux embraced it, it certainly wouldn't be obscure anymore, now would it?
Most of binder is in outright Java. Libbinder_ndk is a subset that is unlikely to please anybody. The other libbinder (openbinder) is dead since 2006ish. I actually used this last one in certain commercial product.
> An extremely widely used and battle hardened Linux feature, though, with corporate sponsorship and active development.
Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and also what D-Bus uses, there is just no contest. Even Android uses unix sockets more than Binder.
None of binder is in Java. The Java binder code is just JNI bindings to the native implementation.
Things like permission manager are in Java, but that's not part of binder. It's just a service published on binder, and one that wouldn't translate to current desktop Linux anyway.
> Compared to _unix sockets_ , which is the other transport used by almost every other local IPC mechanism, and what both D-Bus, TFA's proposal, and literally any other reasonable desktop IPC proposal out there, there is just no contest.
unix sockets are not an equivalent, which is why protocols are bolted on top to turn it into dbus, etc...
EDIT:
> The other libbinder (openbinder) is dead since 2006ish.
The libbinder I meant is the one in AOSP hence why I said "AOSP is right there":
This libbinder is still way too Java-centric. It can be used from outside, and even slightly reminds me of openbinder (e.g. sp<> https://cs.android.com/android/platform/superproject/main/+/... ) but it doesn't really change the picture much. You have something which smells Java from a mile, and has a lot of other Android-isms to boot, so still likely requires to reinvent a lot of the wheel to actually use it for most desktop programs.
Even the use of C++ is likely to frown many people. (Not me).
That is a java version of a class from libbinder. Having Java and native versions of classes is a common pattern for things meant to be used from both.
No, it is not. It is the Java class which has native methods that call into the C++ version, as someone said above. But it is still primarily a Java class.
dbus-java exists, does that magically turn dbus into being primarily implemented in Java?
No, of course not, that'd be absurd. Same thing with Parcel & Binder. Java bindings existing does not change the simple fact that binder itself does not have any Java in it. It's regularly used in processes with zero Java at all, this isn't a hypothetical it's a basic reality. That's why binder is used for HALs and similar low-level systems.
> dbus-java exists, does that magically turn dbus into being primarily implemented in Java?
it does if the only other implementation is basically the JNI native methods of dbus-java. This is what libbinder_ndk looks like from the outside. If there's a newer libbinder that does not look like a Java mess , I have not yet seen it.
Not negating that it may exist; the libbinder you quoted above looks similar to openbinder but I have never used it.
The C++ origin of Binder is annoying, but unlike original Binder[1] easily workable around especially given the exact format of messages is left up for implementation to decide outside few standard bits
[1] BeOS, the docs still match what is in Android :D
Hopefully some distro will implement Android's permission on desktop then. Unix permissions were made for a time where we actually had multiple persons running software in the same OS (a use case that today is served by VMs) rather than protecting an app from another app run by the same user. https://xkcd.com/1200/
Can't you guys stop reinventing the wheel every other day? I hate D-Bus like everyone else, even though at least it did bring project Utopia and all such crap. But even if I think it sucks I stay with it for the simple reason that the more alternatives you create the more you annoy other users WAY MORE than any benefit you bring them. D-Bus has been used everywhere from LG TVs to automotives, so at least it f*cking works.
Does it miss a spec? Write one.
Do you really want your secretsd or whatever to only be able to reply to whomever stored the secret? Make clients store a cookie or something and only reply if they prove ownership of it. But I have to ask : what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway. Or read its files in $XDG_CONFIG_DIR. You are just moving around who has the ultimate responsibility, and that looks like security theater. In addition, I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
> 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...
> 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.
KWallet has never provided any security guarantee, so I dunno what is your surprise here. Its entire premise is centralization and sharing (i.e. not having to type each individual password over and over in each program).
It's literally how it's always worked, and not just on Linux - this is standard across desktop operating systems. Except MacOS, and very recently
Kwallet is for encryption at rest, so an attacker can't read your secrets if they steal your computer. It IS NOT protection from your own applications running as the same user.
That's just not how Linux desktop works. It's a desktop operating system, it's not iOS. All apps running as your user have your users permissions.
Is it an outdated security model? Yes, enter sandboxing and newer kernel features. If you're not doing that though then you won't get that.
Just run your shit in flatpak, problem solved. Or better yet, don't install malware and only download trusted open source software from trusted repositories.
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.
> 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.)
> determine the PID of the process that you are talking to and use pidfd to validate where it is coming from.
The pidfd_open() man page doesn't list many things that can be done with a pidfd. What sort of validation do you have in mind?
I would love to have a reasonably snoop-proof secret storage service whose security model works with normal programs (as opposed to requiring Flatpaks or the like).
My reasoning behind the pidfd thing would just be as a way to try to avoid race conditions, though on second thought maybe it's not needed. I think you can take your pick on how exactly to validate the executable. My thought was to go (using /proc/.../exe) check that the file is root owned (and in a root owned directory structure) and then use its absolute path as a key. Seems like it would be a decent start that would get you somewhere on any OS.
I think it would also be feasible to add code signatures if we wanted to, though this would add additional challenges. As I noted elsewhere any scheme that wants to provide a true security boundary here would need to deal with potential bypasses like passing LD_PRELOAD. Still, I think that it has to be taken one step at a time.
> 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. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?
> 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.)
Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.
> 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).
I'm genuinely kind of surprised people are tripping up on this. Obviously, what you validate is up to you, but you can. Why stick to just the base name? Why not the absolute path? Bonus points for ensuring it's a root owned file in root owned paths. You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want. The policy would obviously vary strongly depending on the system, but if you were dealing with a secure booted system with dm-verity, or something similar, well then this mechanism should be fairly watertight. It's not really the end of the world if there are systems with different security characteristics here.
You can really get creative.
(It is worth noting, though, that this could be bypassed various ways trivially, like with LD_PRELOAD, so to be a true security boundary it would need more thought. Still, this could definitely be made improved numerous ways.)
> 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?
Well, the obvious initial benefit is the same thing that DPAPI has had for ages, which is that it's encrypted on-disk. Of course that's good because it minimizes the number of components that will see the raw secret and ensures that even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.
An additional case worth considering is when the home folder is stored elsewhere over a network filesystem, as in some more enterprise use cases.
> 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).
It would be ill-advised to have each application deal with how to encrypt user data. They can store keymatter in the keyring instead of the data itself if they want to handle storage themselves. (I'm pretty sure this is actually being done in some use cases.)
> 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) .
That page exists to explain why they don't bother, but part of that is that there just isn't an option. If there actually was an option, well, it would be different.
> 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. What's the threat vector here, that super-user-that-can-escape-sandbox can read into the sandboxes and extract the password?
The threat vector is whatever you want it to be, there are plenty of things this could be useful for. The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either. This is probably in part because on Linux most of the programs you run are inherently somewhat vetted by your distribution and considered "trusted" (even if they are subject to MAC like SELinux or AppArmor, like in SuSE) so adding a sandbox feels somewhat superfluous and may be inconvenient (i.e. file access in Bottles is a good example.) But, even in a world where all desktop apps are running in bubblewrap, it's still nice to have extra layers of defense that compliment each other. And even if something or someone does manage to access your decrypted home folder data, it's nice if the most sensitive bits are protected.
> Yes sure, another problem resulting from the lack of standarization. But my point was -- standarize (write a spec), instead of adding more to the problem by creating yet another competing standard which will obviously NOT solve the problem of lack of standarization.
The reason why people don't bother doing this (in my estimation) is because DBus is demoralizing to work on. DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.
And therein lies the rub: if you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.
> I'm genuinely kind of surprised people are tripping up on this. Obviously, what you validate is up to you, but you can. Why stick to just the base name? Why not the absolute path? Bonus points for ensuring it's a root owned file in root owned paths.
Because you do not get it: this is not Android. There is no fixed UIDs. There is no fixed absolute paths. The binaries are not always root-owned. There is no central signing authority (thank god!). You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
> You could special case Flatpak, or specific mount points, or go crazy and add signatures to binaries if you want.
Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
> hat even other privileged processes can't just read user secrets. Defense in depth suggests that it is a feature, not a problem, if multiple security mechanisms overlap. Bonus points if they'd both be sufficient enough to prevent attacks on their own.
I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
I do not see why you'd have your "sandboxes apps" store their private data but then have another storage that is "more secure" for whatever your definition of secure is.
You'd just put the data in the "more secure" storage to begin with.
What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
> It would be ill-advised to have each application deal with how to encrypt user data.
Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
> The reality is that Linux desktops do not run all programs under a sandbox and we're not really headed in a direction where we will do that, either.
In which case, my entire remark does not apply and there is some (minor) benefit to a keyring.
> DBus isn't a mess because of one or a couple of issues, it is a mess because from the ground up, it was and is riddled with many, many shortcomings.
This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
> you would like to have influence in how these problems get solved, you are more than welcome to go try to improve the DBus situation yourself. You don't have to, of course, but if you're not interested in contributing to solving this problem, I don't see why anyone should be all that concerned about your opinion on how it should be fixed.
I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
> Because you do not get it: this is not Android. There is no fixed UIDs.
Uhhh... I didn't say anything about fixed UIDs.
> There is no fixed absolute paths.
There is if your distribution says there is.
> The binaries are not always root-owned.
They are if your distribution says they are.
> There is no central signing authority (thank god!).
I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Yeah, fine, the binaries themselves lack a signature attached to them, but if they can sign the packages they sure as shit can sign an ELF binary provided a mechanism to do so.
But anyway. There is if your distribution has one.
> You really do not get it: _anything_ you could validate from a PID would be absolutely pointless in desktop Linux.
There is if your distribution makes there a way to validate something from the PID.
The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not. That's how desktop Linux really works. You're not forced into any specific policy, but that doesn't mean policy is pointless. There are plenty of people running Secure Boot and Lockdown mode too, it's not automatically pointless.
Immutable distros exist right now.
> Or, if you are assuming Flatpak, you could simply do not allow access to the session bus and instead allow access only to a filtered bus that only allows talking to whichever services Flatpak provides. Which is how Flatpak does it and you sideline the entire problem of having to authenticate clients on the bus, which is a nightmare. The entire process tree descending from original Flatpak session gets access to this bus and only to this bus.
This doesn't fix anything. Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
> I really do not see the point of this. Of course I want privileged processes to be able to see my passwords; this is _my_ desktop.
Do you know what "principle of least privilege" is? My printer driver is "privileged" but that doesn't mean it needs to be able to capture my screen and read all of my passwords. It would be much better if Linux was capabilities-based. Hey, maybe someone should attempt to implement an RPC framework that does that.
> What you're describing is not another layer of security, it is just pointless complication. As I said, the more I think of it, the less reason I see for a secret service which does not really share secrets.
That's because your thought process is going in one direction and not taking any new input. You've been running the same exact narrative the entire time. Yes it's true that if you assume the system must be watertight-secure under all circumstances in every single existing desktop Linux setup, then it can't be done. But that's irrelevant. The question is could it be used as a primitive to construct a more secure Linux desktop, and the answer is a resounding, "Well, duh".
Again. Immutable distros exist right now. They already start with many of the necessary security properties, you mostly need to find a way to deal with insecure linker behavior.
> You reach stupid conclusions like having to design a key-value DB server that only returns values to the process that inserted them in the first place, like what TFA is doing. Why? Just why??? Have multiple totally separate, private instances! And you already have one storage for that: the app's private storage. Why do you even need IPC for this?
sigh
You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data. Sometimes it is also used to share data between different programs, but I don't even think that is most of the time.
Checking my kdewallet, I can see the following applications:
- KRDC
- Remmina
- KRDP
- Chromium
- krfb
- xdg-desktop-portal
... And then the "Passwords" folder, which contains the passwords saved for e.g. SMB shares.
Of those... I think the only one that is ever even accessed by anything else is the Chromium one possibly, for browser migration? The rest are only ever stored for themselves. So yes, the wallet is being used as a dumb key-value store. One that is encrypted automatically without needing the application to do key management.
> Why? You do not put the reason why not. Every application does this _today_, and no IPC has ever been needed for this (e.g. openSSL is a library, not a service).
Not cryptography itself, but key management. Although you can do key management by proxy by providing a cryptography API too, sort of how using the TPM for this purpose works. That is the approach taken by DPAPI on Windows, in contrast to the keyring approach taken on Linux and macOS (where you get a key value store from the app perspective and do neither cryptography nor key management in the app.)
And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
> This is a circular argument. D-Bus is a mess because it is a mess. Even if I would agree, it is a pointless argument.
It's not circular at all... man, you really need to learn how to read. What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd. There is no world in which that is logically worth the effort.
> I am answering to a guy that says that D-Bus sucks then proceeds to create an alternative instead of fixing it. I have not only contributed to D-Bus through decades, I am also part of the reason it is used in some commercial deployments outside traditional desktop Linux (or was a decade ago). My opinion is still as important as his, or yours, which is : nothing at all.
Well, it's at least good that you also recognize the value I place in your opinion at this point, so that we can agree on at least one thing.
But honestly outside of being a smarmy dickhead (sorry, but I never have any reservations firing back when someone is doing it to me) the point I'm making is that if you want DBus to get fixed instead, well, good for you. I would like a Threadripper for Christmas, while we're at it. Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
(And it really doesn't matter to me what Windows or macOS does here honestly. I care about the Linux desktop, not how it compares to whatever crapware Microsoft and Apple are pushing. They haven't really meaningfully improved the desktop in the past 10 years anyways.)
You STILL do not get it: This Is Not Android. Even ignoring that most distributions are not going to do what you want them to do (that's the entire point), the distribution has zero power over what users do. Firefox _is_ still distributed as a simple tarball that you can unpack in your home directory and run.
If flatpak or your distribution suddenly start requiring _root_ so that users can run programs that do not really require root, this not only would be a net security degradation rather than improvement, it would prevent me from using that distribution altogether. And yes, these programs need access to the desktop, the theming service, accessibility, input management, etc. for obvious reasons.
This is why even the current method is superior to anything you are proposing here, and the SCM_CREDENTIALS stuff just does not rightly fit in the Linux desktop model.
> I mean, that's not even really 100% true right now. What major distribution doesn't sign packages in some form? Ye
ANY that is source based, for example. Actually, I have not used _any_ distribution that would sign even packages in ages, much less binaries.
Go and check how much love you are going to get if you start asking around for people to sign their own binaries to run them in their machine, to implement a sandboxing mechanism that there are a million other, way less intrusive ways to implement.
> The point is that the mechanism would be different per each system, the same way that OpenSuSE may have a MAC in enforcing mode by default and Arch might not.
It doesn't really matter. A user is then going to mount a $HOME through NFS into a serverbox and expect to run graphical applications from there.
> Like half of the shit I have installed via Flatpak needs direct session bus access anyways.
A problem I fully acknowledge. But how would _any_ D-Bus replacement fix that? You'd need to replace _all_ IPC servers to offer some form of "no longer trust the clients" API (more or less what Wayland supposedly did to X11), and this is a decades-long task _at best_. A different IPC system doesn't really help, and may even delay this!.
> Do you know what "principle of least privilege" is? M
Irrelevant when my point is that I want _my_ privileged process to manage the password keyring itself.
> You do realize that this is how many apps currently use GNOME Keyring, right? They literally use it to store their own passwords for no other purposes. That's literally already a thing. The intent is not so they can share your password across the system, it is to provide a mechanism to securely store data.
The entire raison-d'être for KWallet was to store AND SHARE passwords amongst programs, as a glorified netrc replacement. The "secure" storage part comes later, and few if any people enable the auto-locking mechanism which is the only thing that can offer any sensible protection to it. As you are aware of, KWallet and gnome-keyring have never provided any level of actual secure storage.
> And the "Why?" is very simple. You want a secure key that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap a key; individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key. Having this control centralized could become important if it's ever required by regulation to be handled a certain way.
why do you make this distinction for secrets, and not for literally the rest of extremely critical private data that the app store? Why would user want to backup the passwords but not the private app documents?
"You want a private data storage that doesn't get lost. The user already has a password, ergo it already provides a perfectly good passphrase to wrap such private data; [other] individual applications can't access that. And that way, the OS can take care of whether user data is encrypted with a TPM or using a passphrase-wrapped key."
I mean, from your description, you want KWallet to provide protection so that say the mail client cannot access the browser passwords (something I already disagree with). But don't you also want, in this containerized world, for the mail client to NOT be able to read your browser's history, for example? If you already provide secure, containerized storage for apps, I fail to see any specific distinction between "private app data" and "private app secret" (I would still make the distinction if it was "shared"). You'd want your history to be protected (from other programs) as much as any website password.
I do not even know why you bring up the word "regulation" in here.
> What I am saying is that it is not only a mess, but deeply flawed. Even if you clean it up, what you will wind up with is an aggressively polished turd
This is not a reading problem: you are still saying that it is a mess because it is a mess. If you want to break the circular reasoning, you have to introduce an actual reason into the loop.
> Just don't act like it's weird when someone who is actually doing something about the trainwreck that is the Linux desktop decides to do something else instead given they have no reason to care about the peanut gallery here.
You keep framing this as if we were not improving the Linux desktop too, which just shows your bias.
My point: Just don't act like it's weird when the actions only result in a LARGER and more explosive trainwreck rather than an improvement.
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).
This is the first time I hear that anyone hates D-Bus. I always saw it as a global API Bus that Apps can register to and which enables some sort of interoperability and automation. After all it can even be used from Bash. What is bad about this?
The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. That's not the fault of D-Bus.
Also I'm puzzled that Polkit hasn't been mentioned even once.
> The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything.
The world is moving towards sandboxed applications (through flatpak and friends) more and more. As per the OP, this is one of the things holding sandboxing back.
That's only somewhat true if we are talking about the same sandbox nested (which would be quite dumb to do).
Escaping two different sandboxes are multiple times as hard, and a sane sandbox is not trivially picked, see web browsers and that the fact that the world is not one giant botnet.
The reason you do t hear much about it is because it's not an often discussed topic. Nonetheless the hate is there.
Dbus is a godawful mess. Imagine the windows registry, except it can only be inspected at runtime, contains executable binaries and is exceptionally fragile
> The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. That's not the fault of D-Bus.
Those secret stores (gnome-keyring/kwallet) store the secrets encrypted on disk, so every application can read the encrypted secrets but only the secret store has the encryption key to decrypt them. This is held in memory, not on disk.
I am puzzled by this comment - hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox? That's literally what stuff like Flatpak xdg-desktop-portal and Wayland isolation are built around.
And maybe its time for a reinvention anyway? IPC and efficient and portable formats are very mature nowadays, with protobuf, flatbuffers etc. and the general model of the internet is based around service location, and stuff talking to each other.
I'm kida curious why they didn't go with Unix Sockets in the first place, with named pipes in memory carrying the message transport.
> hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox?
Yes, and the article's author forgot to tell you that their rant doesn't apply to applications running in a sandbox, as their D-Bus access is filtered.
I've never had much luck with it either. A lot of the same pain points as the author.
As for it being used everywhere, sure, we had some bad SOAP stuff being used everywhere at one time, but that's not a good thing...
Regarding secrets etc.. on the one hand, yeah it's not much to worry about people with access to your machine reading stuff on your machine, buut*, it's kinda dumb to have stuff encrypted and left around for a public unsecured protocol. The solution would be, for apps that need security, don't use dbus.
If the API was less loosey goosey (self documentating, not so open ended, less awkward), I agree it's fine for applications at the same level of trust to all access the same thing.
The problem is more random scripts off the internet using browser apis to read stuff out of local storage containers. Forcing local containers to explicitly allow such access, and yes, using a non-dbus protocol, would be a preferred method, while not requiring overly complex authentication schemes locally...
Otherwise the main change I would have made would be to explicitly allow applications to access the bus, vs just a random app having access by virtue of running in memory...
Putting aside the post and whether it's correct or not.
Reinvent what wheel exactly?
D-Bus can't read your mind (yet) and as such it can't generate an API for you, you still need to design a protocol, it's just that it's on top of D-Bus with certain quirks and restrictions.
Doing the same over UDS in 2025 isn't any more work and doesn't have any negative impact on end users. There's nothing unique about D-Bus from a usability standpoint that can't be done with a service listening over UDS.
This is equivalent to saying that you're reinventing the wheel by not using HTTP as a transport.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Maybe you should look at Varlink. The systemd backed D-Bus alternative. It uses JSON.
Regarding secrets management:
My password manager's protocol is handled using exec and command line arguments. Arbitrary applications can ask for passwords, but they won't get them. They won't read them from disk.
The design of the gnome keyring isn't great, but I actually don't think the protocol matters much in this case.
I may be naive, but why not adopt the browsers api development model. 90% shared core apis, experimental ones, for a few years it seems that every group can work on its code without breaking things for user much while new ideas coming regularly.
Perhaps the SecretManager deserves some extra attention, but I concur. We worked long enough on this, please dont split whats left of the linux desktop...
> Can't you guys stop reinventing the wheel every other day?
No, Linux desktop is just an opportunity for a bunch of special snowflakes to enact their "vision", force their niche requirements on other 99.999% of users or create fiefdoms, where they can feel good and safe.
You may be joking but I think seriously that may be a decent idea. The universal RPC/automation mechanism which everybody implements-whatever its warts may be-is superior to a better-designed one which few actually end up supporting. You don’t need an LLM to call MCP tools, there’s nothing stopping you from calling MCP tools from any programming language.
Spoiler: this is Ars Technica. Obviously they suggest you to instead get an Apple TV so that you send your data to Apple and watch Apple ads instead (with the only argument being that "so far they do less ads").
Yup, from the Apple TV article linked in the article[1]:
> According to its privacy policy, the company gathers usage data, such as “data about your activity on and use of” Apple offerings, including “app launches within our services…; browsing history; search history; [and] product interaction.” [...] transaction information, account information (“including email address, devices registered, account status, and age”), device information (including serial number and browser type), contact information (including physical address and phone number), and payment information (including bank details).
Also 'product interaction' is an euphemism to say "if you're sick, we'll sell this information for around 80€" (I think it's close to 200$ for Americans but I don't have any contact in this industry overseas). If you have a cancer and suddenly you see an increase in ads for pseudo-medicine and other scams whose only goal is to extract all the money you have left, and if lucky, your famil's money too, that's from 'product interaction'.
So exactly how do you suppose they sync your browsing history and bookmarks between devices if they don’t store the information? And your browsing history is e2e encrypted by keys on your device. Apple doesn’t have access to your browsing history.
You can give Apple any age you want to. It’s not like it checks.
And I have no idea about the other topics you are going off on and what they have to do with Apple..
Are trying to say it’s not possible to write terms that give them the ability to sync your history without also letting them mine and sell all the insights from it?
From a technical level, exactly how is Apple mining your browsing history and bookmarks if they are end to end encrypted and they don’t have access to it?
I am so curious to learn more about this. Are there any extensive write ups of the mechanics of identification, price points, whatever? Or is it all insider baseball because it is distasteful?
Many tens to hundreds of dollars for that single datapoint is incredible. I have naively assumed we were just packaged up in aggregate and never thought more deeply than that.
What are the most valuable data? Pregnant? Wedding? Divorce? Illness? Home purchase?
What are you going to do with an iPhone without Apple? Yes you can use an Android without Google. But the percentage of people who do so outside of China is meaningless.
It would be a horrible user experience if it didn’t keep track of the series I’ve watched and where I was in shows so I could pick up and watch where I left off on a different device.
This isn’t the iPod days where you would sync your watch history with iTunes.
The entire point of the remark is that you can throw these pseudo-justifications for any and all forms of tracking, since "tracking all the shows you watch" is precisely the issue that motivates TFA.
At the end of the day, they could be taking screenshots of everything you do with your TV and argue it's because of some AI system that will allow you to more easily launch whatever it is you normally do at that time of the day. If you do not see any issue with that, why would you be on this thread?
No the justification for the article is TVs that track your watching no matter what you watching and selling it to advertisers.
Apple tracks what you are watching on AppleTV only.
I’m on this thread because I understand technology.
Are you saying that if you are watching something like “South Park” you wouldn’t want the service that you are watching it on to keep track of where you are in its 25 season run?
> Apple tracks what you are watching on AppleTV only.
So the solution they propose to TVs that track what you're watching is to switch to AppleTV where Apple will track what you're watching? And you still justify this somehow?
So you are justifying it. For the record it's not just what you watch with the streaming service, it is everything you watch through their TV program.
You still do not get it: you can find a pseudo-justification for _every_ type of tracking they do to you. But none of these are really true justifications. You can do _everything_ without any type of tracking -- even the very basic premise: it shouldn't even be true that you need an account _at all_ to use an Apple TV.
AppleTV doesn’t record everything you watch on your TV like the smart TVs. A smart TV can track what you watch no matter which input source you are using.
How could an AppleTV or any device connected to an HDMI port know what you are watching on other input sources?
The AppleTV device doesn’t track what you watch at all. The AppleTV+ service knows what you watch on their service.
Their is no justification for the TV to know anything. There is obviously a reason for each service to know what you watch on their service. What exactly are you arguing? That you should be able to use the AppleTV+ service anonymously?
> AppleTV doesn’t record everything you watch on your TV like the smart TVs.
Obviously it only records what you watch through it.
> A smart TV can track what you watch no matter which input source you are using. How could an AppleTV or any device connected to an HDMI port know what you are watching on other input sources?
I thought the entire point was to _use_ the Apple TV. If you buy the Apple TV, but still use the other HDMI ports for your viewing .... why did you buy the Apple TV in the first place?
> The AppleTV+ service knows what you watch on their service.
And if you use the Apple TV, what you watch through Apple TV's TV program.
> Their is no justification for the TV to know anything.
Of course there is. They will claim this way it remembers your favorite channel, or that then they can send you spam^W updates in the schedule of your favorite programs, or whatever other crap people like you eventually end up thinking as an indispensable feature for which they happily accept tracking for.
> There is obviously a reason for each service to know what you watch on their service. What exactly are you arguing? That you should be able to use the AppleTV+ service anonymously?
That _there is_ a way to do broadcast TV anonymously. You do not need accounts, sync between multiple devices, or anything; and even if you need them, there are alternatives. That you are in error when you think that your pseudo-justifications are worth anything more than the ones Samsung will provide. The fact that that you immediately jump from "I need this" to "Therefore service provider must be able to track everything I do" is telling.
See how much the AppleTV app knows about what you watch on Netflix.
The apps voluntarily integrate what you are currently watching and in the middle of watching with the AppleTV app so you can get a consolidated view. Apple isn’t going in and monitoring any more than it’s monitoring your email when it is sent to you.
How is Apple tracking you when apps are sending information to it? Is Apple also tracking your email when companies send email to your iCloud email address?
Absolutely everyone in the Apple ecosystem complains about Netflix not integrating with the AppleTV app.
Man, how I wish there was a Netflix setting "omit things I've already watched", since I know they already know this.
I can't help wonder if they are just afraid of the offering looking more bare, or is this really such an uncommon desire to want to see "new to me" stuff and not repeat things?
The only way to have privacy from the matrix is to not participate in the matrix. That’s in fact your best option. Does one have to consume the drug of movies/tv? I realize that just suggesting something coming in between the addict and their drug causes consternation, but that also makes the point more salient.
The Apple TV box does not have a microphone and a camera, but beyond that there is absolutely no reason to think it's any more private than a "smart" TV.
There are no ads in the AppleTV operating system itself.
The only Apple “ads” I ever see are inside the Apple TV+ app (yeah, their naming is confusing…) and it’s only for TV shows they’re promoting in their streaming service.
I installed an AppleTV recently, so I don't have much experience. But the first thing I saw after the initial setup was one/third of the display advertising a TV-show on a subscription service I had to purchase. Would that count as an ad?
Apps placed in the top row of the app grid get to display content at the top area, when that app is selected. Most apps use it for things like continue watching or show recommendations.
That’s very different from turning on your TV and seeing an ad for Mercedes or whatever taking up the screen.
On the Apple TV you get ‘ads’ for the apps you have in your top row, with different levels of interactivity. Some are just logos of that streaming service, some show recently watched. The Apple TV app has full-blown ads for Apple TV+ originals.
They won’t actually let you delete the Apple TV app, but if you move it out of the top row you will never see the ads.
My parents have an Amazon Fire TV and when I go to their house and have to use it it drives me insane. Carousels of adds large at the top, banner ads as you scroll, full rows of sponsored apps. Full screen ads for random Amazon products when you pause any show you are watching. Everything you watch on Amazon’s streaming service has minute long unskippable ads. Sometimes when you turn it on Alexa will just verbally read you ads.
what resolution is it that you can drive with "newer HDMI versions" but you cannot drive with DisplayPort 1.4 w/o DSC? The bandwidth difference is not really that much in practice, and "newer HDMI versions" also rely on DSC, or worse, chroma subsampling (objectively and subjectively worse).
I mean, one has been able to drive 5K, 4K@120Hz, etc. for almost over a decade with DP1.4, for the same res you need literally the latest version of HDMI (the "non" TDMS one). It's no wonder that display screens _have_ to use the latest version of HDMI, because otherwise they cannot be driven from a single HDMI port at all.
Having monitors that supported its native resolution through DP but not HDMI used to be a thing until very recently.
reply