This is perhaps the most important point to cover, because it informs every step of every process we do to produce, promote and develop styx.
We don't force choices on the user to further our own goals, because not doing so is Goal One.
Everything else is secondary to this.
The consent and autonomy of an installing user over their system, be infringed.
styx is a consent-first operating system.
Why? Because those don't exist, in a meaningful way; and it is necessary to enter the field with this rule in mind, lest earlier decisions be used as justification to erode this fact.
(This is going to be a long post, just a heads up.)
It is to be a fundamental part of our mission goal and statement - to provide a consent-first operating system, as a user environment and system management tooling, for the person who installs it. Therefore, the installing user has the fullest control over how styx is handled on their systems, not the people in charge of styx.
This doesn't mean we will not allow restrictions, safety or security safeguards over styx, by the installing user, whether they are a sole user on a personal machine, administrators or deployment managers, or a parent setting up a child's computer.
It does mean that the styx project, its maintainership, and its trusted individuals, will not wrest control from the people who use styx, or induce dark patterns or automation or forcible transition or upgrade paths that seeks to harm the user's autonomy over their own deployed system.
styx is, as any large software project, inherently a system borne of decisions. Often, in systems and standards, it is very difficult to change a decision once made. Therefore, Every decision made, takes into account what its impact on user consent is, and minimizes any harm to that consent basis where possible, through careful consideration of, e.g.:
Further, we seek to scope out potentials for abuse, and minimize, eliminate, or mitigate for those as aptly as possible. Any feature that may channel abuse to a user, without the user explicitly accepting the risk in their own scope, is not in scope for implementation in styx.
If the answer is "yes, there is an impact", then we must take very careful consideration on the basis of *benefit to the user,* not the people in charge of styx.
There are beneficial and positive reasons for, e.g., providing a mechanism for automatically expiring dated or vulnerable packages, or giving the choice to automatically upgrade system components or contributed software, and those are points where the user gives consent to styx to perform these actions on their systems.
At no point will styx force a pending operation which requires consent, to happen anyway. No "do or ask me laters" - anything of this sort has a "No. Go away." option, albeit perhaps with less aggressive language.
styx will ask you important questions at install-time. Not a quiz battery of fifty checkboxes and wizards to "NEXT" through, but meaningful and relevant options to allow conveniences to the user which may require, e.g., contacting a first-party service (like, fetching vulnerability information from the styx package repositories) or third-party services (like a weather provider). At your option, you can have styx check with you again on a regular (e.g., monthly, quarterly) basis, to make sure that we reflect your current choices to those questions, because people do change their minds about things.
Regardless of your choices at install-time, you do have the option to change those choices, in a clear and central control space - not scattered across different apps and buried toolboxes in hamburger menus.
We don't want to immediately discount or discredit beneficial user functions, such as "find my device", or theft-resilient lockdown, which can be provided by a central authority such as styx, and which can also be abused to reduce privacy (in that such a central authority will need the ability for monitoring of a device's (and by correlation, a user's) location, or the ability to remotely disable a device.
For example: as a harmful and abusive misuse of these services, a loan-shark may seek to use those two functions to disable and repossess a user's device; but, as a beneficial and desired use, an enterprise may also seek to use these functions to prevent the leakage and loss of information, and facilitate its recovery.
We want to ensure that if any functions like this are provided, that:
By designing the policy basis in this way, we ensure that the system can be both secured and securable, while also ensuring that we do not restrict the user-installer's autonomy over their system.
We will make strides to ensure that, as a policy on styx's end: on any point where data is entered, collected, or submitted, that the UI for that point MUST include a disclosure, or a link to an explanation, for the use, collection, interchange, exchange and potential sharing, access or publicity of that information from styx's own systems; and give the user controls to restrict or modify as much of that as is reasonably possible.
styx should have a well defined privacy policy, for each package maintained by us, which is written in concise, short and human-readable "English" (e.g., not Legalese), and which outlines any opportunity for data to traverse user or machine boundaries, with whom and why it does so, and - if it is communicating to styx servers or services, specifically outline, both as a policy to us and as a covenant to the user, what is to be done with the data in question.
Any unaudited data path or connection in styx core software that we haven't written a policy for, should be considered a bug of high priority.
Further, we should strive to outline in a package's documentation, every consent request that can be made, e.g., for retrieving media metadata from a server, or for automatically upgrading packages.
Further, we want to take a sensible policy approach to GDPR/CCPA type privacy and data legislation. Rather than big popup cookie warning boxes, we instead aim to provide information where necessary, and obtain consent where necessary, unobtrustively and with the least amount of interruption to the actual ongoing work. Rather than prompt for cookies as soon as the user visits, we should inform the user of cookie use at the times where cookies become presented - e.g., at login, or when changing site preferences.
styx will note versions and updates which introduce major changes to individual software, especially in terms of UI, UX, and workflow, for the benefit of users and developers.
styx should, in the context of governance, be proactive in our quality-forward, trustworthy, and consent-first community culture to ensure that we produce in our product what is wanted and needed, and not distract ourselves with questionable, disruptive, or "weird" decisions which may cause people to distrust us.
We don't have to be stoic, boring and suit-and-tie business-dressed, or "awkwardly business-casual" "how do you do, fellow kids?", either - we are us, and we are styx. we should, however, at least give things a professionalism check before they're run out the door.
Lastly: a word from the wise.
Yet unfinished; yet unpublished. We're going to give those a lot of thought and drafting, as they concern governance and bringup of the project.
The user which installs styx onto a system, is referred to as the "installer-user" (for local, single- or multi-user installs), "machine-level administrator" (MLA, for remote, multi-machine deployments) or "machine-level operator" (MLO, for local, independent system deployments) - hereafter, "installer-user" overall.
This is the highest authority in the styx permissions framework, "above or equal to root"; as it is where local, machine-specific roots of cryptographical trust are generated and derived from, for the package manager, bootstrap and firmware (UEFI), and for delegation of user rights from the installer-user.
This includes single-user installations (where the installer-user context acts as full root authority, and said user's own active login account may be limited by themselves for security) and managed deployments (schools, businesses, households, families, and other cooperative situations) with multiple users or multiple computers under a single organization or with shared users and differing user privilege or access control levels.
Referring to styx's community, its systems' or software stewardship or maintainership, its project and/or team leadership, its trusted individuals, organizational members, organizational owners and operators, boards, executives, presidents, or any business, personal or professional partnerships thereof.
Specifically calling out e.g., Google services, where unexpected chat and messaging features are automatically included in Photos, Maps, Docs, Drive and other non-messaging apps, independently of their dedicated messaging apps which do exist (like Messages, Chat, Hangouts, Duo), and without sufficiently informing the user of their presence, leading to surprise invocations of message abuse, and block circumvention.
Calling out... a lot of apps, but Facebook takes the cake for this one. Have other examples? I'd love to hear about them in the comments. 👇
We should also expect to localize the policies where possible and as necessary.
Many such examples, both broad and narrow in scope. Twitter/X as a whole; Meta's fixation on 'the metaverse'; GNOME's ongoing behavior; or (SFW, text) in an early version.
mirrored from our cohost post:
published 2023-10-27 at 2:12AM time
No known replies. Not a reply to another post.
No comments on cohost.
