Home » Community » User-Trusted Systems and Components » User-Trusted Computing Definition
| In conversation with Julie Marchant [message #20 is a reply to message #18] |
Sun, 18 February 2018 16:49  |
connie
Messages: 28
Registered: January 2017
|
Junior Member
Freenix Ninja |
|
|
The contents of this post are the edited version of an email thread between me and Julie Marchant. Published by permission, this entire post is licensed under CC0.
connie:
Based on the kinds of topics you usually discuss, I thought you might be interested in our most recent mini-project, where we are brainstorming an alternative to the FSF's free software definition and things like that. To be more precise, while similar to the free software definition, it is intended as an alternative to FSDG; not as a replacement, either, but another take on the task of evaluating and certifying projects such as gnu+linux distributions, which are not mere software products, but come with a whole ecosystem attached to them.
JM:
I think your definition of "anti-feature" is too vague, and I disagree with the conclusion that Adblock Plus has an anti-feature. I suppose that is in reference to the way that extension approves certain ads by default. But that's the point, really: this is only the default behavior. Adblock Plus doesn't stop you from blocking approved ads.
I don't know about Signal, but the description given lends to me disagreeing with the conclusion that Signal has an anti-feature. To not perform encryption at all would have the same effect, and that would not be an anti-feature.
connie:
May be it would help to clarify that any kind of behavior, even emergent behavior, can qualify as an anti-feature; doesn't have to be something we can narrow down to a few lines of source code.
ABP has a traditional feature, which users can disable of course, but I want to see the definition triggered by Palant's ongoing effort to make sure as many users as possible have it enabled, as well as by the fact that he's got a massive conflict of interest, and will probably not hesitate to re-enable it sneakily during update under some bullshit pretense, so no, no one can really hope to disable it completely. I mean, when he announced that the "feature" is in, people were so spooked that several forks emerged within weeks, which shows a near-complete erosion of trust by users.
Signal's insistence on sharing all credentials with Google or Apple is not a feature in a traditional sense, but is an emergent behavior nonetheless, and the one which is pre-determined by the design choices OWS made.
JM:
I understand why it is classified that way, I just disagree with that imperative. I rather like Benajamin Mako Hill's definition of an anti-feature: a feature that is so bad that some users would pay to have it removed. That is to say, "features" that are to the detriment of their users. Faulty encryption is not to users' detriment; they can simply add on their own encryption system (like OTR). Optional whitelisting of ads is not to users' detriment; they can simply toggle the option to not whitelist the ads.
I'm not entirely sure that basing a definition on concepts like this are really useful, however. Not all proprietary programs have anti-features, and such an exclusive appeal to practicality lends itself to non-solutions (like locking up proprietary programs in sandboxes rather than excluding them).
connie:
Thanks for the reference, this is indeed where I got the idea, but I forgot the guy's name I will make sure to cite that video in the forum. And while I do not use his language, I do perceive my current definition as a more circumscribed version of his. While I understand the intent of his definition, it leaves the door wide open to call anything anti-feature as long as there is a user or two who would pay to get it removed. I tried to constrain that somewhat by further stipulating that it should be exploitable or at least detrimental in some sense, and that there should be at least one party capable of removing it without running into severe technical difficulties.
Without these stipulations, one can identify a feature they find unpleasant: say, systemd; declare their desire to pay to remove it, and then run their head against a wall of perfectly free+libre distributions with all kinds of developer communities, all of which adamantly refuse to remove it for what they perceive as technical reasons. And we can agree, I hope, that while systemd is not perfect, there is no compelling reason to consider it malicious or screwing its users somehow.
Sure, there are folks who will say NOOOOO, systemd is cancer, and the damage it does is long-term, EEE and all that, but at least with my definition they have to start building the case and collect the evidence, whereas the naive version allows them to declare it as anti-feature right away, and declare every distro which uses it an anti-feature garden.
JMFaulty encryption is not to users' detriment; they can simply add on their own encryption system (like OTR).
The deviousness of OWS is truly great, it seems, as you still don't seem to understand precisely what they did. Their encryption algorithm, to the best of my knowledge, is as flawless as pidgin's. But there's no point to OTR when an untrusted (really, hostile) party such as Google or Apple has a near-
permanent, direct, and surreptitious channel by which to access private keys, keystrokes, and the screen. Once again, OWS, the maker of Signal, designed it so that every user is forced to set up on a compromised device, compromising xerself at the moment of keygen, and remaining fully compromised ever after. If you read their documentation, you will see that even though they have a chrome plugin, you cannot use it to set up. You *have* to use a spy-phone.
So I would say that Signal will become OTC automagically the moment there is a functional free+libre phone with non-trivial market share. Alternatively, OWS can allow users to use the "desktop" version without ever using a spy-phone. This last option seems like something OWS could implement easily, which is exactly what makes it a full-fledged anti-feature: there is a non-user party with the ability to fix it, but not the desire.
JMOptional whitelisting of ads is not to users' detriment; they can simply toggle the option to not whitelist the ads.
But just the act of whitelisting the parties which pay off the dev team IS to users' detriment, and we can't call it optional in any practical sense when the EDFL in charge of the project is corrupt, and would not hesitate to (re-)enable the feature behind the users' back, or lie to them with the intention of convincing them to enable it. And there is ample, ample documentation to the fact that ABP is developed by scammers.
JMI'm not entirely sure that basing a definition on concepts like this are really useful, however. Not all proprietary programs have anti-features,
I agree. Open-source proprietary software may well be free of anti-features, but since it makes it harder to remove them in the future, it gets the axe. Blobs should be assumed to contain anti-features by any sensible 21st century person.
JMand such an exclusive appeal to practicality lends itself to non-solutions (like locking up proprietary programs in sandboxes rather than excluding them).
As it stands, I argue that all non-free software runs afoul of our definition by virtue of making it harder for the community to remove current and future anti-features. Are you thinking something like a blob which is so well-contained that we would consider it harmless? We definitely can agree on making sure that our definition should continue to exclude all non-free software in most unequivocal terms, regardless of how well it is isolated within the computing system, broadly construed. I would go as far as to argue that a piece of free software which is highly dependent on a proprietary component elsewhere in the ecosystem is already suspect, because my vision of a "computing system" is very holistic. I'd like to think that "computing" really happens within large communities consisting of people, hardware, and software.
Here's a completely off-the-wall question prompted by this last topic:
Is electron (you know, the seemingly elementary so-called-particle) a computational blackbox? It seems to compute alright, but we don't have the source code. Does that mean we should be careful about using it?
JM:
connieSure, there are folks who will say NOOOOO, systemd is cancer, and the damage it does is long-term, EEE and all that ... and declare every distro which uses it an anti-feature garden.
True enough, but I look at it in a different way: this is just an indication to me that this sort of definition is impractical.
connieThe deviousness of OWS is truly great ... You have to use a spy-phone.
So, in other words, Signal is dependent on proprietary software, and that compromises the security of your system.
I think this is a good demonstration of why I think this sort of definition is impractical. See, from your description, I was under the impression that Signal was a libre program, but that the servers it worked with had access to its encryption keys, rendering the encryption useless. If this were a proper definition of the problem, it would be easy to solve: just add another encryption layer, one not accessible by Google or Apple, on top of the built-in encryption. This is why I used OTR as an example; as I'm sure you know, XMPP has no end-to-end encryption by default, so what OTR does is send an encrypted version of the text you told it to send. The XMPP network has no idea that it's encrypted, and it's then up to the opponent's XMPP client to recognized what the encrypted text means.
But since Signal is dependent on proprietary software, it doesn't work that way. It would be possible for the proprietary dependency to subvert any attempt to do this, and even if it weren't because of a sandbox, Signal is not truly libre if it depends on a proprietary program, and that's the important point.
connieBut just the act of whitelisting the parties which pay off the dev team IS to users' detriment ... And there is ample, ample documentation to the fact that ABP is developed by scammers.
Some of these appeals would function identically if you were trying to oppose use of systemd, which I see you agree is unreasonable. Some of it is in reference not to the software, but to its developers. This is a distraction; it doesn't matter who developed a program. A libre program developed by Hitler is still libre, and a proprietary program developed by Jesus is still proprietary.
You don't have to trust a libre software developer. If you don't trust the ABP developers, you're free to fork ABP (which has happened multiple times), or you can simply refuse to upgrade.
connieIs electron ...
No, an electron is a component of our universe. I don't even see how an electron is similar to a computer program in an abstract sense.
The issue at hand with proprietary software is not just that we don't fully understand it. It's that we don't, but someone else does. The issue is not really knowledge itself, but the power dynamics involved.
If, somehow, nature ended up causing a computer to exist on its own with software on it that we have no source code to, that wouldn't be proprietary software. It would be natural software. You could say that natural software might be dangerous (and indeed, nature often is dangerous). But you can't say that one person has unjust power over another person in that situation, so it's not an ethical issue.
References:
Antifeatures article by Benjamin Mako Hill
Antifeatures talk by Benjamin Mako Hill
|
|
|
|
Current Time: Thu May 02 00:39:56 EDT 2024
Total time taken to generate the page: 0.01125 seconds
|
Freenix
Search
Help
Members
Register
Login
Home
