| Re: User-Trusted Computing Definition [message #19 is a reply to message #18] |
Wed, 14 February 2018 00:18   |
rk4n3
Messages: 5
Registered: January 2017
Location: Albert Lea, MN
|
Junior Member
Freenix Ninja |
|
|
I'm not quite satisfied with this treatment of the term "anti-feature", in that I think that it conflates two concepts that should be distinct for practical and significant reasons in the context of the clarity being sought in this definition (UTC).
The two concepts I'm referring to are commonly known as "bug" and "malice". The reason the distinction between these concepts is critical, imho, is that one should preclude a qualification of software as "UTC", while the other should not.
The difference between a "bug" and "malice" is primarily one of either intent or neglect. An analogous illustration might be the difference between an "error" and a "lie" ... if one makes a mistake in arithmetic and bases a conclusion on it, with no intent to be incorrect, it could not be called a "lie", as lying requires intent to deceive. Similarly, if software behaves in an unintended way because of an error in the author's logic, despite all intent by the author to implement the desired behavior, it can't be called "malice", because malice requires intent.
My assertion is that a construct can be qualified, and remain qualified, as "UTC" while being afflicted by "bugs", under certain conditions. By contrast, a construct can never be qualified, or remain qualified, as "UTC" while being encumbered with anything malicious at all.
Some "bugs" will be, by nature, particularly immersed in or causal of concerns that the term "anti-feature" is intended to cover, and so could be classified as "anti-features" ... but certainly not all (and I'd content not even a majority of) "bugs".
I'd also like to point out the difference between these concepts and those of "side-effect" and "omission". While the notion of "side-effect" is correctly treated in the definition so far, "omission" deserves similar exclusion from what "anti-feature" covers as well, imho. The changes to a construct required to address an "omission" can be described as simply doing work that hasn't been undertaken yet. I'd assert that "omissions" deserve treatment identical to "bugs", in that some may, in light of certain criteria, deserve classification as "anti-features", but certainly not all (or even many) would.
I suggest that the term "anti-feature" thus becomes a bit more complicated because it should refer an overlap between anything malicious and SOME other forms of deficiencies. If the qualification of "UTC" is to be based on what the term "anti-feature" means, then aligning the term with the intended/desired outcome should be of self-evident value - and I'd assert that alignment to be as I've described here, which would resemble something like:
The term "anti-feature" includes:
- Anything malicious
- Some kinds of bugs, as qualified by certain criteria
- Some kinds of omissions, as qualified by certain criteria
With all this said, I do believe insightful and "correct" sets of criteria for what the term "anti-feature" covers can be arrived at, so that the term can be used as a cornerstone for assignment of a "UTC" endorsement/certification that aligns with intended outcomes - it will just take a bit of crafting to get there, imho.
[Updated on: Wed, 14 February 2018 00:31] Report message to a moderator |
|
|
|
Freenix
Search
Help
Members
Register
Login
Home
