10 KiB
The AniNIX is not a collection of one-offs. The following considerations should be evaluated before testing or releasing a new project, and quality assurance should report if any of these design principles aren't met.
Meeting the need
Any design should be evaluated against the need it is intended to meet. Ask the following questions:
- Does an existing package fulfill the need better than custom development by the AniNIX? TheRaven is a fairly specialized package, but Yggdrasil was superior to our self-written Siren and an externally-maintained package, which saves the network human hours.
- Is the implementation going to fit the state of the industry? This is a slightly nebulous question, but Bazaar was deprecated in favor of Git for the Foundation project because Git is more widely used and better supported. Following the state of the industry usually means superior features, testing, support, and adoption.
- Will filling this need justify the resource expenditure?
- Will end users adopt this solution and fill their need that way, or will the effort be wasted when a more professional solution will be released and adopted later?
Security-First Design
Remote Access vs. Local Only
Remote access isn't needed in all cases and opens the network to vulnerabilities. The CryptoWorkbench in the Foundation doesn't need to be remotely accessible when users can deploy their own with git; the Foundation itself doesn't need to allow the world to write to it to allow cooperation. These kinds of projects, that are either read-only or non-deliverable, can be safely monitored with filesystem intrusion detection, virus scanning, and existing controls over remote access to the host.
SSH and IRC do allow remote access, and require additional safeguards to those above. Network intrusion detection becomes a need, since this is a means by which attackers can exploit a service. Firewall rules will need to be opened and monitored.
Penetration Testing Planning Before Release
Identify a plan and set aside resources to test the project before release. Failed attempts at open chroot accounts on Core have been identified and shut down before being generally released; these kinds of attempts allow the AniNIX to have confidence in the released projects while not stifling the developer's ideas. Failed ideas that are insufficiently secured are a good exercise in development, and they can be tabled for later when better controls or designs are available.
Appropriate User Rights
Running services as root is generally a bad idea for non-security services. Make sure to have a unprivileged account for any other service, particularly if they allow remote access.
Physical Access
The AniNIX does not believe in the cloud (or, as it is affectionately known, Computers Living On Unknown Datacenters). Cloud computing centralizes storage in a place that is difficult if not impossible for end users to secure and protect; particularly for sensitive information like social security numbers, this is not acceptable. Redundancy of the cloud is also very expensive and hard for small groups to achieve.
In contrast, if any given user can replicate shared data from the AniNIX and each other on storage that they monitor and secure, the network becomes harder to destroy, impede, or rob. This decentralized model ensures that users know where their data lives, and any given user can stand up the network.
For services that are hosting information like passwords, the device should be physically secured and the storage encrypted. While they can be made useless by destruction, this should prevent physical access resulting in an immediate compromise.
Privacy
Guarantees of privacy are a major concern in designs. The AniNIX needs to be able to protect itself while doing its best to provide the same right to others. This ties in with concerns of Remote Access -- remote access that isn't by read-only transport requires an account which can be paired with an individual. This should be used for collaboration with the network and for maintaining user preferences.
However, tools like documentation and source code should be available from behind privacy tools and without identifying a user. When governments can outlaw information, as many repressive regimes in the Middle East and elsewhere have done, the AniNIX seeks to make sure that the people still have power by information.
Furthermore, any communication across a wider network should be encrypted. WebServer controls most of this via the Let's Encrypt SSL certificate for the web apps, but SSH also encrypts its communication. Unencrypted communication is insecure and not private by default and should be prohibited as much as possible.
End User Experience
Services developed in isolation are interesting exercises, but in the end it is the user's comfort and trust in the service that will keep it being used.
Reliability and Stability
Physical devices should have redundant components and power sources as much as possible. Protections against failures in services, such as frequently saving state and quickly restarting after a failure, are highly encouraged.
Projects should crash rarely if ever -- any crash should be investigated immediately and the relevant code revisited. Frequent crashes are perhaps the highest cause of end-user dissatisfaction.
Performance
Performance is second only to stability in terms of the end-user experience. Services should be fast and light to meet the needs of users -- the state of development today doesn't tolerate slow and/or intensive processes for all but the most critical projects.
Ensure that memory is allocated only when needed and deallocated as soon as possible. Processing should use efficient algorithms to meet the goal and should be open to re-evaluation. Network should minimize the use of images in transport -- X11 forwarding and video streaming should only be used in services that the user expects to be noncritical and potentially slow.
Graphical Design
Minimalism is a key principle in the AniNIX design. An uncluttered interface with simple, intuitive options reduce the barrier to entry and improve adoption.
The AniNIX, as you can see by this page, follows a white-on-black color scheme with red for important or interactive elements. White-on-black results in less light emission from screens, and in low-light conditions this means less effect on the night vision. A study in August 2013 found that white and blue light were the most disruptive to the animal test subjects, while red light was the least. A LensCrafters study also found blue disruptive. Red accents, therefore, offer the least disruption while keeping readable text with the highest contrast. The three-color scheme further assists the colorblind, who should still be able to clearly identify the static and interactive elements on the interface.
GUI elements will generally be deployed by a Web page, as this is a cross-platform means of providing access and easy to code. Should packages choose to include a local GUI, they are responsible for meeting these principles with a best-effort approach.
Mobile Access Design
With the rise of the smartphone, remotely accessible services should offer a simple means via some app to reduce network traffic. The app interface should be intuitive and quick to use.
Etymology
The AniNIX attaches a unique name, such as Sora for OpenLDAP or Yggdrasil for Emby, to packages and services it instantiates. The reason for this is that the name defines a scope of functionality the AniNIX expects to rely on -- should the underlying package change, such as replacing Plex Media Server with Emby, documentation and AniNIX packages will use the same name. We also need a naming convention for unique code we are writing, like Uniglot & TheRaven
These names are not intended to supersede the licensing or attribution of other packages -- applications, once installed, should only update the minimal allowable elements to be usable under AniNIX principles. Wherever possible, this should be done via the application's provided interface, such as enabling dark modes. We also should not remove any links that the application provides to its own documentation, licensing, or websites. This means that AniNIX etymology only applies to administrators and is otherwise invisible to end users. Where the AniNIX is deploying services created by others, we should only use the names in two places: DNS and Kapisi roles. This makes it possible for others to look up the service as we swap out tools without overriding the attribution once the service is accessed.
Names given should be chosen for relevance to the function being provided (Singularity being a pull service, Foundation being the basis on which we're built, etc.) and for ease of memory. Only the most basic services, such as IRC, WebServer, and SSH, will be left unnamed. Additionally, these names should be selected from one of the following categories:
- A natural phenomenon that describes the function, such as Singularity or Aether
- Mythological figures that provide wisdom (such as Odin for Yggdrasil, Raven, and Wolfpack), truth (like Wiccan Grimoire), and morality (such as Maat)
- The technological function being served, such as Password or DarkNet
- Cyber-themed science fiction with moral human protagonists
- This last is the most complicated but most fun category.
- Arguments must be clearly made in the etymology how the organization being selected is a commonly-accepted protagonist.
- The human-centric focus is to maintain alignment with the people using the systems.
Maintainability
Make sure that a project can be easily maintained. This means following the Development Best Practices and submitting Markdown documentation for the project.
Ensure that projects are configurable for key elements, particularly for things like passwords that change often, and they should use well-known and understood languages per the Development Best Practices.