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, SHALL NOT 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.)

---

Goal One.

It is to be a fundamental part of our mission goal and statement (1) - to provide a consent-first operating system, as a user environment and system management tooling, for the person who installs it. (2) Therefore, the installing user has the fullest control over how styx is handled on their systems, not the people in charge of styx. (3)

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.

Mitigating the impact of our decisions.

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.:

• whether a feature can track the user or their behavior;
• whether a feature enables unsolicited messaging or advertisement from third parties;
• whether a feature or change enables any access or changes to users' data, configuration, or application environment; and
• whether anything is being automated without the direct control of the user, especially if it has impacts on user consent or autonomy.

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. (4)

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. (3)

You have the controls.

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. (5)

styx services are for the users, not us.

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:

• they are backed by a strong ethical basis, centered around the user and installer of styx.
• in the event that the installer of styx is not the user, the consent the user gives to their installer must be clear, fully disclosed, and mutually-agreeable - the user must know that their installer does have powers over their machine.
• in the event that styx provides services which impact the autonomy of a user's relationship with their system (for instance, auto-updates and expired/vulnerable package disablement), they are strictly at the user's/installer's option.
• while we may provide suggestions that enhance a user's security or user experience at a cost of autonomy, we must ensure that the user is fully informed of the impact of these features, with the full option to immediately revoke consent and disable any controls styx may impose over the user's system.
• styx, as an organization, (3) must not collect data that is not functionally essential to its operation, and architecturally should be built around that goal.
• styx, as an operating system, must not divulge data that is not functionally essential to its operation, without full user consent.

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.

The user's privacy is not ours to mess with.

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" (6) (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.

We work on a principle of least surprise.

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.

• Package maintainership is responsible for marking "major changes" like this.
• Because Versioning Is Screwy, especially with Libre/Free Software homebrewed projects, do not assume a "major" SemVer version number correlates to "major changes" by the styx definition.
• Users can report an unannounced "major change" (or a non-"major" change marked as such), and the repository stewardship will address this.
• We hope to be able to have multiple versions of the same software live side-by-side, but consistency in mutable state will need to be tracked, and potentially forked if incompatible.
• A good UI should be presented to the user for this, so that they know when changes impact their workflow, have the option to either switch to the new version, temporarily stick with the old version, or use them side-by-side. Permanently using the older version is possible, not recommended, but our ethics code means that we can't stop the user from trying unless they're confident and consenting to package expiry (see RFC-14).
• Any update, regardless, should snapshot the previous configuration state, to allow the user to revert a specific application and its configuration, a-la-Time Machine.

Finally, we shouldn't surprise ourselves, either.

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 (7) 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.

---

Footnotes:

1. Re: Mission goals and statement:

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.

2. Re: the person who installs styx:

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.

3. Re: the people in charge of styx, as a project:

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.

4. Re: features which may channel abuse to users:

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.

5. Re: privacy options scattered in confusing UI:

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. 👇

6. Re: "In plain English":

We should also expect to localize the policies where possible and as necessary.

7. Re: questionable, disruptive, or "weird" decisions:

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 Ubuntu having "erotic" wallpapers (SFW, text) in an early version.

---

Original post and reply-chain:

mirrored from our cohost post: https://cohost.org/styx-os/post/3104254-styx-is-a-consent-fi
published 2023-10-27 at 2:12AM America/New_York time
No known replies. Not a reply to another post.
No comments on cohost.