forked from data.coop/website
76 lines
3.2 KiB
YAML
76 lines
3.2 KiB
YAML
|
# This determines which badges are active and the order to display them in
|
||
|
|
active_badges:
|
||
|
|
- stability
|
||
|
|
- secure_connection
|
||
|
|
- encrypted_storage
|
||
|
|
- zero_knowledge
|
||
|
|
- backup
|
||
|
|
- logging
|
||
|
|
- anonymity
|
||
|
|
|
||
|
|
badges:
|
||
|
|
stability:
|
||
|
|
name: Stability
|
||
|
|
description: |
|
||
|
|
*Service is always available.*
|
||
|
|
|
||
|
|
This badge describes how stable the service is. For instance if there is a big or small risk that the service may suffer from outages or loss of data. Immediately after launching a service, it might be considered less stable than after it has matured through long-time tests and usage.
|
||
|
|
|
||
|
|
icon: stable.svg
|
||
|
|
|
||
|
|
secure_connection:
|
||
|
|
name: Secure connection
|
||
|
|
description: |
|
||
|
|
*Data can only be seen by you and the service.*
|
||
|
|
|
||
|
|
The traffic between you and the service is encrypted. For instance, the browser will display a padlock in the address bar when the connection is encrypted. This means that it's only you and the service that can see transferred data.
|
||
|
|
|
||
|
|
icon: secure-connection.svg
|
||
|
|
|
||
|
|
encrypted_storage:
|
||
|
|
name: Encrypted storage
|
||
|
|
description: |
|
||
|
|
The service stores data in an ecrypted way, for instance on an encrypted storage media.
|
||
|
|
This ensures that the data is protected in case of a physical breach of security,
|
||
|
|
since it's only the system administrator who has the encryption key that can decrypt storage media.
|
||
|
|
icon: encrypted-data-storage.svg
|
||
|
|
|
||
|
|
zero_knowledge:
|
||
|
|
name: Zero-knowledge
|
||
|
|
description: |
|
||
|
|
*You have the only key.*
|
||
|
|
|
||
|
|
In this case, data.coop's system administrator cannot access data.
|
||
|
|
There is no "main key". This provides more security, but it also means that data will be lost if you lose the key.
|
||
|
|
|
||
|
|
icon: zero-knowledge.svg
|
||
|
|
|
||
|
|
backup:
|
||
|
|
name: Backup
|
||
|
|
description: |
|
||
|
|
The service's data is backed up frequently in order to minimize damages from technical outages or cyber attacks.
|
||
|
|
Backups are stored in another physical location than the server.
|
||
|
|
icon: backup.svg
|
||
|
|
|
||
|
|
# TODO: We should describe how we label logging that isn't fully documented as configured.
|
||
|
|
logging:
|
||
|
|
name: Logging
|
||
|
|
description: |
|
||
|
|
Technical logging is primarily about *meta data*, which can be understood as *data about data*.
|
||
|
|
Who does what and when? On one side, it's relevant for system administrators to see why a server is overloaded, but as with all data this can be abused.
|
||
|
|
For instance, it can be used to prove that what a user was doing at a specific time.
|
||
|
|
|
||
|
|
Note that "positive" status for logging means that the service is performing an expected amount of *minimal* logging of meta data.
|
||
|
|
We strive to document this data for every service. A "negative" status means that unnecessary amounts of logging take place.
|
||
|
|
icon: logging.svg
|
||
|
|
|
||
|
|
anonymity:
|
||
|
|
name: Anonymous access
|
||
|
|
description: |
|
||
|
|
Services with anonymous access can be used without registration and authentication.
|
||
|
|
This means that the service can be used anonymously without sharing personal information.
|
||
|
|
Some services may have limited access for un-registered users.
|
||
|
|
This may be relevant for instance for a service where a registered user can upload a file
|
||
|
|
and an unregistered user can download the file.
|
||
|
|
icon: anonymous-access.svg
|