FASSAG Wiki - User contributions [en]

TODO

2026-05-27T00:31:02Z

CRYSTL:

This page is a list of projects currently being worked on and references to relevant information.

== Easy first project : ==

* write about the distinction between distro / kernel / init / userspace / DE / windowing system / compositor / package manager

* mpeg container format
**h264
*hardware accelerated media playback

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]

== In Progress Pages : ==
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
**[[LUKS]]
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes

== Needs Research / Implementation ==
* A guide on how to use and navigate around the WIKI would be a very good idea
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** how to use tables
** how to use templates
** how to use the WYSIWYG editor

* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have information about how they are best motivated
*** should have matrix account
*** should describe teams they are in and <s>what roles they want to play in those teams</s>
**** Roles are now defined through [[Template:Add role]] and [[Template:User roles]] in a user page.
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?" ( would be nice to have a directory of all unfinished pages as well )
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)
** tiered information ? as in , there will be a main page which gives a high level overview , and links to pages with more detail , and those pages would need a template to link back to the main page ? or perhaps the " See also " template would be enough , dunno . a graph of the different tiers of depth on the main page may also be a good idea ? probably should also try to figure out some ground rules about what kind of content is even suitable for which tier , how many tiers there should be , etc . for example , on the LUKS page , since that is assuming like , someone is installing linux , that's already like , above the base tier imo , which is just like " the OS that came on your computer "
*** something like :
**** beginner : only talk about installing software via easy methods on a device with its pre-installed OS
**** novice : willing to try safer OSes like linux
**** intermediate : can use a command line shell for simple things , and can edit config files
**** advanced : can write simple scripts and programs and knows their way around a CLI
**** expert : able to understand with low-level concepts like memory management and CPU instructions
*** though this might be too many ? or not enough , i dunno . i guess it would depend on the amount of content we have to talk about for any given subject
**** will try to figure some of this out when working on LUKS
* Unfinished pages :
** [[LUKS]]
** [[Lens]]
** ( the rest of the roles pages have not even been started )

TODO

2026-05-10T18:11:31Z

CRYSTL: added notes for tiers

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
**[[LUKS]]
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** how to use tables
** how to use templates
** how to use the WYSIWYG editor
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have information about how they are best motivated
*** should have matrix account
*** should describe teams they are in and <s>what roles they want to play in those teams</s>
**** Roles are now defined through [[Template:Add role]] and [[Template:User roles]] in a user page.
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?" ( would be nice to have a directory of all unfinished pages as well )
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)
** tiered information ? as in , there will be a main page which gives a high level overview , and links to pages with more detail , and those pages would need a template to link back to the main page ? or perhaps the " See also " template would be enough , dunno . a graph of the different tiers of depth on the main page may also be a good idea ? probably should also try to figure out some ground rules about what kind of content is even suitable for which tier , how many tiers there should be , etc . for example , on the LUKS page , since that is assuming like , someone is installing linux , that's already like , above the base tier imo , which is just like " the OS that came on your computer "
*** something like :
**** beginner : only talk about installing software via easy methods on a device with its pre-installed OS
**** novice : willing to try safer OSes like linux
**** intermediate : can use a command line shell for simple things , and can edit config files
**** advanced : can write simple scripts and programs and knows their way around a CLI
**** expert : able to understand with low-level concepts like memory management and CPU instructions
*** though this might be too many ? or not enough , i dunno . i guess it would depend on the amount of content we have to talk about for any given subject
**** will try to figure some of this out when working on LUKS
* Unfinished pages :
** [[LUKS]]
** [[Lens]]
** ( the rest of the roles pages have not even been started )

LUKS

2026-05-10T18:05:40Z

CRYSTL: simplified ciphers section , linked to the advanced page

THIS PAGE IS A DRAFT ! Information on this page is in need of further research and refinement !

This page will need to be split into " difficulty tiers " and since it's the first page this has been needed on , it makes it an excellent test subject to figure out the best way to do so .

This page is written with [[Tiers|Intermediate]] users in mind, but of course everyone is encouraged to try to understand.

For more more info on this topic, check the cryptsetup FAQ, the Arch Wiki, or the [[Luks (Advanced)|Advanced Guide]]. '''TODO !!! LINK THESE'''

= Guide to Decent LUKS Security on Linux =
If you just want to know the "best" command to run, you can skip to the bottom. But reading this Guide is encouraged, as it will give you a better understand of what the options do, and how they will affect the security of your data!

== Ciphers ==
Ciphers scramble the files that will be saved, so it's important to pick a good one. Computers have had, for many decades now, built in support for AES, making it the fastest and most secure option for pretty much everyone.

== On-disk Format ==
The on-disk format defines how the encrypted data is stored on the disk itself . While you ''could'' just write the encrypted blocks directly to the disk , you would be at risk of a number of different attacks . CBC ( Cipher-block chaining ) is an older on-disk format and should not really be used . It has malleability vulnerabilities ( meaning data can be inserted without knowing the encryption key ) , and also , specially-crafted files can be " fingerprinted " , meaning they can be located on the disk . XTS ( XEX-based tweaked-codebook mode with ciphertext stealing ) is better at mitigating these issues , so it's the recommended default . It's also usually hardware accelerated on x86 . XTS does have its own vulnerabilities , but most of these issues can be mitigated by using a filesystem that can verify and repair corrupted data , like ZFS or BTRFS .

== Initialization Vectors ( IV ) ==
The purpose of IV is to ad some randomness different blocks of the disk , so that overall patterns cannot be discovered . ESSIV ( Encrypted salt-sector initialization vector ) was set as default for CBC to mitigate the fingerprinting issue , but this does not help CBC's issues with malleability . For XTS , plain64 is recommended over plain , since it has no performance impact , and plain has some data leaking vulnerabilities that are viable on disks larger than 2TiB . XTS not being vulnerable to fingerprinitng , does not need the added overhead of ESSIV .

== Password Hashing ==
The hashing algorithm is intended to make weak passwords harder to break , so a very good password does not really need much hashing . Argon2 is optimized to be impossible to brute-force on devices with limited memory , most notably , graphics cards . The point is to force the attacker to use their CPU , which is not usually not nearly as quick as a GPU for this kind of task . Unless you're primarily concerned about some APT trying to break into your device , it is pretty good tradeoff . If your device is very memory constrained ( like under 4GB ), you ''may'' want to consider using PBKDF2 ( Password-Based Key Derivation Function ) . You will almost certainly want to increase the iteration time more though , as it is far weaker to GPU brute-forcing . For a small note on Argon2 , it has a few different variants . Argon2i is weakest to brute-forcing , but has strong side-channel protection . It's generally not safe to use 2i with anything less than 10 iterations . Conversely , while Argon2d is most secure against brute force attacks , it is more susceptible to side channel timing attacks than Argon2id . Unless you are ''really'' not concerned about side-channel attacks , Argon2id is the most well rounded and therefore the best choice .

== Iteration Time ==
This defines how long your computer is going to spend hashing the password . More iteration is generally better , and is mostly a question of how long you willing to spend waiting for your computer to initially decrypt the drive . Do note that it doesn't decrease the speed of the drive after the key is decrypted . To be very clear , high iteration count is not an alternative to a secure password ! 2 seconds ( 2000ms ) is generally the recommended default , though of course you are welcome to set it as high as you are willing to tolerate . Make sure your computer is not set to any " low-power mode " when setting up the disk , as this will affect the time it takes to hash .

Very important note ! Make sure your password is secure ! Using something short is a very bad idea . Using a string of characters from a well known book is also not a great idea ! Something like a diceware password with at least 6 words is generally a good idea !

== Benchmarking ==
If you want to see for yourself how fast these various algorithms will run on your computer, you can use <code>cryptsetup benchmark .</code><blockquote> # Tests are approximate using memory only (no storage IO).

PBKDF2-sha1 1736052 iterations per second for 256-bit key

PBKDF2-sha256 3355443 iterations per second for 256-bit key

PBKDF2-sha512 1096836 iterations per second for 256-bit key

PBKDF2-ripemd160 434733 iterations per second for 256-bit key

PBKDF2-whirlpool 364088 iterations per second for 256-bit key

argon2i 4 iterations, 735656 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

argon2id 4 iterations, 842046 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

# Algorithm | Key | Encryption | Decryption

aes-cbc 128b 594.1 MiB/s 1434.3 MiB/s

serpent-cbc 128b 59.8 MiB/s 371.1 MiB/s

twofish-cbc 128b 123.5 MiB/s 200.0 MiB/s

aes-cbc 256b 423.9 MiB/s 1284.2 MiB/s

serpent-cbc 256b 61.0 MiB/s 394.5 MiB/s

twofish-cbc 256b 136.8 MiB/s 240.4 MiB/s

aes-xts 256b 2196.7 MiB/s 2414.8 MiB/s

serpent-xts 256b 445.6 MiB/s 401.0 MiB/s

twofish-xts 256b 220.3 MiB/s 236.9 MiB/s

aes-xts 512b 2031.5 MiB/s 2117.4 MiB/s

serpent-xts 512b 445.2 MiB/s 437.6 MiB/s

twofish-xts 512b 221.9 MiB/s 249.3 MiB/s</blockquote>As you can see from this sample output , aes-xts is the fastest ! Assuming you're on an x86 machine , this will almost certainly also be the case for you . You'll also notice Argon2i only has 4 iterations here , making it unsafe to use . You can add <code>-i 5000</code> to test 5000ms as an example , to see how many iterations it achieves .

== /dev/urandom ==
Though unlikely , to avoid an entropy-starved situation ( meaning the random numbers are not random enough ) , you can use <code>--use-random</code> when setting up the disk .

There's apparently a lot of debate and conflicting information online about the difference between /dev/random and /dev/urandom online . The main difference is that /dev/random will wait when it estimates that not enough entropy has been gathered . Since it only affects when you initially setup the disk though , waiting for it to gather enough entropy is generally a good idea . Whether its method of ensuring it has gathered enough data is effective , is also somewhat debated , but it certainly doesn't hurt .

= Summary =
Unless you have a strong reason to doubt AES-256 ( which is also post-quantum resistant ) , AES should be used . Using CBC even with ESSIV does not have any compelling reasons for consideration , so XTS likely your best choice , especially since it will be significantly faster to encrypt / decrypt on x86 . These options are the default for good reason , and unless you have a particularly special setup or threat model ; like if for example , if your CPU does not have hardware accelerated AES , or if it had a known vulnerability . Lastly , Argon2id is generally your best option for hashing .

== Disk Setup ==
Assuming your disk is already correctly partitioned , setting up the disk is as simple as :

<code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>

As mentioned previously , these settings are the default on the latest cryptsetup ( with the exception of --use-random ) , but setting them manually ensures that they are correct on older versions . You can also check what the defaults are for your system by running cryptsetup --help . You can then verify that it was setup correctly with :

<code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>

Once it has been setup , it can be opened with :

<code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>

Note that " dm_name " can be set to whatever you like , and the disk will be available at :

<code>/dev/mapper/dm_name</code>

Then you will need to format it , via something like :

<code>mkfs.ext4 /dev/mapper/dm_name</code>

Of course , you'll want to replace mkfs.ext4 with the setup command for your preferred partition type .

Luks (Advanced)

2026-05-10T18:04:05Z

CRYSTL: added ciphers block

{{Main|LUKS}}

This page is written with [[Tiers|Advanced]] users in mind, but of course everyone is encouraged to try to understand.

For more more info on this topic, check the cryptsetup FAQ, the Arch Wiki. '''TODO!!! LINK THESE'''

= Guide to Decent LUKS Security on Linux =
The Main Page gives a high level overview of what different LUKS options can do, but this page intends to go into as much detail as possible about them while still aiming to be easy to understand.

== Ciphers ==
Ciphers are the [[algorithms]] used to [[Encryption|encrypt]] [[data]]. Picking the best algorithm is very important for ensuring your data is secure. If your cipher can be broken, then your data can be accessed without the key.

Of the widely supported options, the two most worth considering are Serpent and AES.

Twofish ''may'' be better in lower-security applications where there's no AES acceleration ''and'' writes happen more often than reads, but generally, not a great option.

Serpent may theoretically be more secure, though in practice its potential advantages seem pretty minimal. It also hasn't been tested as much as AES, so it ''may'' have potential vulnerabilities not yet known about .

Another consideration is the actual implementation. Serpent has potential vulnerabilities depending on the details of the implementation. Without looking into the specific implementation in-depth, it's hard to say how secure it is.

On the other hand, having hardware acceleration for AES has a number of advantages for security, most notably resistance to side channel attacks, and of course, speed. Some chips however, almost always not x86, do not have hardware accelerated AES. It's also possible that your CPU may have a vulnerability, so that's something you may want to look into. As far as we are aware though, no vulnerabilities have been reported on any present or past chip with AES support. Practically speaking, the advantages of having hardware accelerated AES make it more secure than using Serpent in nearly all cases.

LUKS

2026-05-10T17:45:59Z

CRYSTL: intial work to implement tiers

THIS PAGE IS A DRAFT ! Information on this page is in need of further research and refinement !

This page will need to be split into " difficulty tiers " and since it's the first page this has been needed on , it makes it an excellent test subject to figure out the best way to do so .

This page is written with [[Tiers|Intermediate]] users in mind, but of course everyone is encouraged to try to understand.

For more more info on this topic, check the cryptsetup FAQ, the Arch Wiki, or the Advanced page. '''TODO !!! LINK THESE'''

= Guide to Decent LUKS Security on Linux =
If you just want to know the "best" command to run, you can skip to the bottom. But reading this Guide is encouraged, as it will give you a better understand of what the options do, and how they will affect the security of your data!

== Ciphers ==
Ciphers are the algorithms that encrypt the data that will be written to the disk . Picking one that is resistant to attacks is critical , as otherwise your data is potentially vulnerable , even without the key .

Of the widely supported options , generally the two worth considering are Serpent and AES . Twofish ''may'' be better in lower-security applications where there's no AES acceleration ''and'' writes happen more often than reads , but generally , not a great option .

Serpent may theoretically be more secure , though in practice its potential advantages seem pretty minimal . It also hasn't been tested as much as AES , so it ''may'' have potential vulnerabilities not yet known about .

Another consideration is the actual implementation . Serpent has potential vulnerabilities depending on the details of the implementation . Without looking into the specific implementation in-depth , it's hard to say how secure it is .

On the other hand , having hardware acceleration for AES has a number of advantages for security , most notably resistance to side channel attacks , and of course , speed . Some chips however , ( usually not x86 ) , do not have hardware accelerated AES . It's also possible that your CPU may have a vulnerability , so that's something you want to look into . Not currently aware of anything like this , though some Ryzen chips recently had an AES vulnerability that allowed unauthorized microcode to be installed . To be very clear , this has been patched with a microcode update , and is also not directly relevant to use in disk unlocking . Practically speaking , the advantages of having hardware accelerated AES likely make it more secure than using Serpent in nearly all cases .

== On-disk Format ==
The on-disk format defines how the encrypted data is stored on the disk itself . While you ''could'' just write the encrypted blocks directly to the disk , you would be at risk of a number of different attacks . CBC ( Cipher-block chaining ) is an older on-disk format and should not really be used . It has malleability vulnerabilities ( meaning data can be inserted without knowing the encryption key ) , and also , specially-crafted files can be " fingerprinted " , meaning they can be located on the disk . XTS ( XEX-based tweaked-codebook mode with ciphertext stealing ) is better at mitigating these issues , so it's the recommended default . It's also usually hardware accelerated on x86 . XTS does have its own vulnerabilities , but most of these issues can be mitigated by using a filesystem that can verify and repair corrupted data , like ZFS or BTRFS .

== Initialization Vectors ( IV ) ==
The purpose of IV is to ad some randomness different blocks of the disk , so that overall patterns cannot be discovered . ESSIV ( Encrypted salt-sector initialization vector ) was set as default for CBC to mitigate the fingerprinting issue , but this does not help CBC's issues with malleability . For XTS , plain64 is recommended over plain , since it has no performance impact , and plain has some data leaking vulnerabilities that are viable on disks larger than 2TiB . XTS not being vulnerable to fingerprinitng , does not need the added overhead of ESSIV .

== Password Hashing ==
The hashing algorithm is intended to make weak passwords harder to break , so a very good password does not really need much hashing . Argon2 is optimized to be impossible to brute-force on devices with limited memory , most notably , graphics cards . The point is to force the attacker to use their CPU , which is not usually not nearly as quick as a GPU for this kind of task . Unless you're primarily concerned about some APT trying to break into your device , it is pretty good tradeoff . If your device is very memory constrained ( like under 4GB ), you ''may'' want to consider using PBKDF2 ( Password-Based Key Derivation Function ) . You will almost certainly want to increase the iteration time more though , as it is far weaker to GPU brute-forcing . For a small note on Argon2 , it has a few different variants . Argon2i is weakest to brute-forcing , but has strong side-channel protection . It's generally not safe to use 2i with anything less than 10 iterations . Conversely , while Argon2d is most secure against brute force attacks , it is more susceptible to side channel timing attacks than Argon2id . Unless you are ''really'' not concerned about side-channel attacks , Argon2id is the most well rounded and therefore the best choice .

== Iteration Time ==
This defines how long your computer is going to spend hashing the password . More iteration is generally better , and is mostly a question of how long you willing to spend waiting for your computer to initially decrypt the drive . Do note that it doesn't decrease the speed of the drive after the key is decrypted . To be very clear , high iteration count is not an alternative to a secure password ! 2 seconds ( 2000ms ) is generally the recommended default , though of course you are welcome to set it as high as you are willing to tolerate . Make sure your computer is not set to any " low-power mode " when setting up the disk , as this will affect the time it takes to hash .

Very important note ! Make sure your password is secure ! Using something short is a very bad idea . Using a string of characters from a well known book is also not a great idea ! Something like a diceware password with at least 6 words is generally a good idea !

== Benchmarking ==
If you want to see for yourself how fast these various algorithms will run on your computer, you can use <code>cryptsetup benchmark .</code><blockquote> # Tests are approximate using memory only (no storage IO).

PBKDF2-sha1 1736052 iterations per second for 256-bit key

PBKDF2-sha256 3355443 iterations per second for 256-bit key

PBKDF2-sha512 1096836 iterations per second for 256-bit key

PBKDF2-ripemd160 434733 iterations per second for 256-bit key

PBKDF2-whirlpool 364088 iterations per second for 256-bit key

argon2i 4 iterations, 735656 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

argon2id 4 iterations, 842046 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

# Algorithm | Key | Encryption | Decryption

aes-cbc 128b 594.1 MiB/s 1434.3 MiB/s

serpent-cbc 128b 59.8 MiB/s 371.1 MiB/s

twofish-cbc 128b 123.5 MiB/s 200.0 MiB/s

aes-cbc 256b 423.9 MiB/s 1284.2 MiB/s

serpent-cbc 256b 61.0 MiB/s 394.5 MiB/s

twofish-cbc 256b 136.8 MiB/s 240.4 MiB/s

aes-xts 256b 2196.7 MiB/s 2414.8 MiB/s

serpent-xts 256b 445.6 MiB/s 401.0 MiB/s

twofish-xts 256b 220.3 MiB/s 236.9 MiB/s

aes-xts 512b 2031.5 MiB/s 2117.4 MiB/s

serpent-xts 512b 445.2 MiB/s 437.6 MiB/s

twofish-xts 512b 221.9 MiB/s 249.3 MiB/s</blockquote>As you can see from this sample output , aes-xts is the fastest ! Assuming you're on an x86 machine , this will almost certainly also be the case for you . You'll also notice Argon2i only has 4 iterations here , making it unsafe to use . You can add <code>-i 5000</code> to test 5000ms as an example , to see how many iterations it achieves .

== /dev/urandom ==
Though unlikely , to avoid an entropy-starved situation ( meaning the random numbers are not random enough ) , you can use <code>--use-random</code> when setting up the disk .

There's apparently a lot of debate and conflicting information online about the difference between /dev/random and /dev/urandom online . The main difference is that /dev/random will wait when it estimates that not enough entropy has been gathered . Since it only affects when you initially setup the disk though , waiting for it to gather enough entropy is generally a good idea . Whether its method of ensuring it has gathered enough data is effective , is also somewhat debated , but it certainly doesn't hurt .

= Summary =
Unless you have a strong reason to doubt AES-256 ( which is also post-quantum resistant ) , AES should be used . Using CBC even with ESSIV does not have any compelling reasons for consideration , so XTS likely your best choice , especially since it will be significantly faster to encrypt / decrypt on x86 . These options are the default for good reason , and unless you have a particularly special setup or threat model ; like if for example , if your CPU does not have hardware accelerated AES , or if it had a known vulnerability . Lastly , Argon2id is generally your best option for hashing .

== Disk Setup ==
Assuming your disk is already correctly partitioned , setting up the disk is as simple as :

<code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>

As mentioned previously , these settings are the default on the latest cryptsetup ( with the exception of --use-random ) , but setting them manually ensures that they are correct on older versions . You can also check what the defaults are for your system by running cryptsetup --help . You can then verify that it was setup correctly with :

<code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>

Once it has been setup , it can be opened with :

<code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>

Note that " dm_name " can be set to whatever you like , and the disk will be available at :

<code>/dev/mapper/dm_name</code>

Then you will need to format it , via something like :

<code>mkfs.ext4 /dev/mapper/dm_name</code>

Of course , you'll want to replace mkfs.ext4 with the setup command for your preferred partition type .

TODO

2026-05-03T20:38:12Z

CRYSTL: added unfinished pages sections

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
**[[LUKS]]
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** how to use tables
** how to use templates
** how to use the WYSIWYG editor
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have information about how they are best motivated
*** should have matrix account
*** should describe teams they are in and <s>what roles they want to play in those teams</s>
**** Roles are now defined through [[Template:Add role]] and [[Template:User roles]] in a user page.
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?" ( would be nice to have a directory of all unfinished pages as well )
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)
* Unfinished pages :
** [[LUKS]]
** [[Lens]]
** ( the rest of the roles pages have not even been started )

Lens

2026-05-03T20:36:23Z

CRYSTL: create initial pag

{{Hatnote|This article is unfinished}}{{Main|Organization}}

Lenses are critical to the function of a team. Lenses are helpful at different scales as well. A Lens may focus primarily on a specific project they are knowledgeable about, or maybe they are interested in maintaining the focus of FASSAG as a whole. Regardless of their scope, Lenses provide direction and oversight to help the other members focus on their goals without having to worry about where their efforts should be directed.

== Skill Profile ==
There are a few skills Lenses should focus on.

==== Time management ====
{{See|Time management}}
Not only will Lenses need to manage their own time well, but they also need to ensure that others are managing their time well.

As mentioned in [[Organization]], different members will respond to different kinds of support and motivation, so it's also important to help others figure out their needs if they do not know, and to help motivate them using these strategies.

TODO

2026-05-03T19:47:45Z

CRYSTL: added motivation info , and clarified that roles are specific to teams

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
**[[LUKS]]
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** how to use tables
** how to use templates
** how to use the WYSIWYG editor
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have information about how they are best motivated
*** should have matrix account
*** should describe teams they are in and <s>what roles they want to play in those teams</s>
**** Roles are now defined through [[Template:Add role]] and [[Template:User roles]] in a user page.
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?"
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)

TODO

2026-05-03T19:25:29Z

CRYSTL: added link to LUKS page , removed old cryptpad page .

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
**[[LUKS]]
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** how to use tables
** how to use templates
** how to use the WYSIWYG editor
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have matrix account
*** should describe teams they are in and <s>what roles they want to play</s>
**** Roles are now defined through [[Template:Add role]] and [[Template:User roles]] in a user page.
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?"
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)

LUKS

2026-05-03T19:24:29Z

CRYSTL: created LUKS page , made sure to add draft warning , and note about difficulty teirs

THIS PAGE IS A DRAFT ! Information on this page is in need of further research and refinement !

This page will need to be split into " difficulty teirs " and since it's the first page this has been needed on , it makes it an excellent test subject to figure out the best way to do so .

= Beginners Guide to Decent LUKS Security on Linux =
If you just want to know the " best " command to run , you can skip to the bottom . But reading this post is encouraged , as it will give you a better understand of what the options do , and how they will affect the security of your data !

If you want even more info on this topic , check the cryptsetup FAQ , as good amount of this information is pulled from there !

For more information on how to use LUKS tools , the arch wiki is a great resource .

== Ciphers ==
Ciphers are the algorithms that encrypt the data that will be written to the disk . Picking one that is resistant to attacks is critical , as otherwise your data is potentially vulnerable , even without the key .

Of the widely supported options , generally the two worth considering are Serpent and AES . Twofish ''may'' be better in lower-security applications where there's no AES acceleration ''and'' writes happen more often than reads , but generally , not a great option .

Serpent may theoretically be more secure , though in practice its potential advantages seem pretty minimal . It also hasn't been tested as much as AES , so it ''may'' have potential vulnerabilities not yet known about .

Another consideration is the actual implementation . Serpent has potential vulnerabilities depending on the details of the implementation . Without looking into the specific implementation in-depth , it's hard to say how secure it is .

On the other hand , having hardware acceleration for AES has a number of advantages for security , most notably resistance to side channel attacks , and of course , speed . Some chips however , ( usually not x86 ) , do not have hardware accelerated AES . It's also possible that your CPU may have a vulnerability , so that's something you want to look into . Not currently aware of anything like this , though some Ryzen chips recently had an AES vulnerability that allowed unauthorized microcode to be installed . To be very clear , this has been patched with a microcode update , and is also not directly relevant to use in disk unlocking . Practically speaking , the advantages of having hardware accelerated AES likely make it more secure than using Serpent in nearly all cases .

== On-disk Format ==
The on-disk format defines how the encrypted data is stored on the disk itself . While you ''could'' just write the encrypted blocks directly to the disk , you would be at risk of a number of different attacks . CBC ( Cipher-block chaining ) is an older on-disk format and should not really be used . It has malleability vulnerabilities ( meaning data can be inserted without knowing the encryption key ) , and also , specially-crafted files can be " fingerprinted " , meaning they can be located on the disk . XTS ( XEX-based tweaked-codebook mode with ciphertext stealing ) is better at mitigating these issues , so it's the recommended default . It's also usually hardware accelerated on x86 . XTS does have its own vulnerabilities , but most of these issues can be mitigated by using a filesystem that can verify and repair corrupted data , like ZFS or BTRFS .

== Initialization Vectors ( IV ) ==
The purpose of IV is to ad some randomness different blocks of the disk , so that overall patterns cannot be discovered . ESSIV ( Encrypted salt-sector initialization vector ) was set as default for CBC to mitigate the fingerprinting issue , but this does not help CBC's issues with malleability . For XTS , plain64 is recommended over plain , since it has no performance impact , and plain has some data leaking vulnerabilities that are viable on disks larger than 2TiB . XTS not being vulnerable to fingerprinitng , does not need the added overhead of ESSIV .

== Password Hashing ==
The hashing algorithm is intended to make weak passwords harder to break , so a very good password does not really need much hashing . Argon2 is optimized to be impossible to brute-force on devices with limited memory , most notably , graphics cards . The point is to force the attacker to use their CPU , which is not usually not nearly as quick as a GPU for this kind of task . Unless you're primarily concerned about some APT trying to break into your device , it is pretty good tradeoff . If your device is very memory constrained ( like under 4GB ), you ''may'' want to consider using PBKDF2 ( Password-Based Key Derivation Function ) . You will almost certainly want to increase the iteration time more though , as it is far weaker to GPU brute-forcing . For a small note on Argon2 , it has a few different variants . Argon2i is weakest to brute-forcing , but has strong side-channel protection . It's generally not safe to use 2i with anything less than 10 iterations . Conversely , while Argon2d is most secure against brute force attacks , it is more susceptible to side channel timing attacks than Argon2id . Unless you are ''really'' not concerned about side-channel attacks , Argon2id is the most well rounded and therefore the best choice .

== Iteration Time ==
This defines how long your computer is going to spend hashing the password . More iteration is generally better , and is mostly a question of how long you willing to spend waiting for your computer to initially decrypt the drive . Do note that it doesn't decrease the speed of the drive after the key is decrypted . To be very clear , high iteration count is not an alternative to a secure password ! 2 seconds ( 2000ms ) is generally the recommended default , though of course you are welcome to set it as high as you are willing to tolerate . Make sure your computer is not set to any " low-power mode " when setting up the disk , as this will affect the time it takes to hash .

Very important note ! Make sure your password is secure ! Using something short is a very bad idea . Using a string of characters from a well known book is also not a great idea ! Something like a diceware password with at least 6 words is generally a good idea !

== Benchmarking ==
If you want to see for yourself how fast these various algorithms will run on your computer, you can use <code>cryptsetup benchmark .</code><blockquote> # Tests are approximate using memory only (no storage IO).

PBKDF2-sha1 1736052 iterations per second for 256-bit key

PBKDF2-sha256 3355443 iterations per second for 256-bit key

PBKDF2-sha512 1096836 iterations per second for 256-bit key

PBKDF2-ripemd160 434733 iterations per second for 256-bit key

PBKDF2-whirlpool 364088 iterations per second for 256-bit key

argon2i 4 iterations, 735656 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

argon2id 4 iterations, 842046 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)

# Algorithm | Key | Encryption | Decryption

aes-cbc 128b 594.1 MiB/s 1434.3 MiB/s

serpent-cbc 128b 59.8 MiB/s 371.1 MiB/s

twofish-cbc 128b 123.5 MiB/s 200.0 MiB/s

aes-cbc 256b 423.9 MiB/s 1284.2 MiB/s

serpent-cbc 256b 61.0 MiB/s 394.5 MiB/s

twofish-cbc 256b 136.8 MiB/s 240.4 MiB/s

aes-xts 256b 2196.7 MiB/s 2414.8 MiB/s

serpent-xts 256b 445.6 MiB/s 401.0 MiB/s

twofish-xts 256b 220.3 MiB/s 236.9 MiB/s

aes-xts 512b 2031.5 MiB/s 2117.4 MiB/s

serpent-xts 512b 445.2 MiB/s 437.6 MiB/s

twofish-xts 512b 221.9 MiB/s 249.3 MiB/s</blockquote>As you can see from this sample output , aes-xts is the fastest ! Assuming you're on an x86 machine , this will almost certainly also be the case for you . You'll also notice Argon2i only has 4 iterations here , making it unsafe to use . You can add <code>-i 5000</code> to test 5000ms as an example , to see how many iterations it achieves .

== /dev/urandom ==
Though unlikely , to avoid an entropy-starved situation ( meaning the random numbers are not random enough ) , you can use <code>--use-random</code> when setting up the disk .

There's apparently a lot of debate and conflicting information online about the difference between /dev/random and /dev/urandom online . The main difference is that /dev/random will wait when it estimates that not enough entropy has been gathered . Since it only affects when you initially setup the disk though , waiting for it to gather enough entropy is generally a good idea . Whether its method of ensuring it has gathered enough data is effective , is also somewhat debated , but it certainly doesn't hurt .

= Summary =
Unless you have a strong reason to doubt AES-256 ( which is also post-quantum resistant ) , AES should be used . Using CBC even with ESSIV does not have any compelling reasons for consideration , so XTS likely your best choice , especially since it will be significantly faster to encrypt / decrypt on x86 . These options are the default for good reason , and unless you have a particularly special setup or threat model ; like if for example , if your CPU does not have hardware accelerated AES , or if it had a known vulnerability . Lastly , Argon2id is generally your best option for hashing .

== Disk Setup ==
Assuming your disk is already correctly partitioned , setting up the disk is as simple as :

<code>cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-random --verify-passphrase /dev/YOURPARTITIONHERE</code>

As mentioned previously , these settings are the default on the latest cryptsetup ( with the exception of --use-random ) , but setting them manually ensures that they are correct on older versions . You can also check what the defaults are for your system by running cryptsetup --help . You can then verify that it was setup correctly with :

<code>cryptsetup luksDump /dev/YOURPARTITIONHERE</code>

Once it has been setup , it can be opened with :

<code>cryptsetup open /dev/YOURPARTITIONHERE dm_name</code>

Note that " dm_name " can be set to whatever you like , and the disk will be available at :

<code>/dev/mapper/dm_name</code>

Then you will need to format it , via something like :

<code>mkfs.ext4 /dev/mapper/dm_name</code>

Of course , you'll want to replace mkfs.ext4 with the setup command for your preferred partition type .

TODO

2026-05-03T19:20:41Z

CRYSTL: completed table of contents ( MediaWiki:Sidebar )

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
** https://cryptpad.fr/pad/#/2/pad/view/v9+28PcpFVoMr4eVf-NpF64Do35ocDL3tQLbaWq2Bfk/
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** how to use tables
** how to use templates
** how to use the WYSIWYG editor
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have matrix account
*** should describe teams they are in and <s>what roles they want to play</s>
**** Roles are now defined through [[Template:Add role]] and [[Template:User roles]] in a user page.
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?"
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)

Main Page

2026-05-03T19:18:31Z

CRYSTL: add weekly meetup

Welcome to the '''FASSAG Wiki'''. This editable knowledge base contains an ever-changing collection of resources developed by the organization.

== What is FASSAG? ==

====== The Free Accessible Safe Software Advocacy Group ======
Our mission is to reach out and make technology accessible and easy to understand. We seek to provide resources and guidance on computer safety, guides on various software, at whatever level of complexity is right for you. You can get involved as much as you'd like! Whether you want to help out with research, or writing guides, or perhaps you're a developer and want to help improve software, we'd be happy to have your support.

== Getting Started ==

* [https://fassag.dev Home] — Get a top level view on our mission.
* [[TODO]] — What we're currently working on.
* [[Operations]] — Get a detailed look at how we operate.
* [[Organization]] — See how we structure ourselves.
* [[Weekly Meetup]] — Meet up and work on projects together!
* [https://codeberg.org/FASSAG Forge] — The Codeberg organization where all our code is stored.
* [https://matrix.to/#/#fassag-entrance:chat.solarpunk.moe?client=element.io Matrix Space] — Join to chat about FASSAG.

MediaWiki:Sidebar

2026-05-03T19:16:37Z

CRYSTL:

Main Page

2026-05-03T19:15:32Z

CRYSTL:

Welcome to the '''FASSAG Wiki'''. This editable knowledge base contains an ever-changing collection of resources developed by the organization.

== What is FASSAG? ==

====== The Free Accessible Safe Software Advocacy Group ======
Our mission is to reach out and make technology accessible and easy to understand. We seek to provide resources and guidance on computer safety, guides on various software, at whatever level of complexity is right for you. You can get involved as much as you'd like! Whether you want to help out with research, or writing guides, or perhaps you're a developer and want to help improve software, we'd be happy to have your support.

== Getting Started ==

* [https://fassag.dev Home] — Get a top level view on our mission.
* [[TODO]] — What we're currently working on.
* [[Operations]] — Get a detailed look at how we operate.
* [[Organization]] — See how we structure ourselves.
* [https://codeberg.org/FASSAG Forge] — The Codeberg organization where all our code is stored.
* [https://matrix.to/#/#fassag-entrance:chat.solarpunk.moe?client=element.io Matrix Space] — Join to chat about FASSAG.

MediaWiki:Mainpage-description

2026-05-03T19:13:31Z

CRYSTL:

Home

MediaWiki:Sidebar

2026-05-03T19:12:49Z

CRYSTL:

MediaWiki:Sidebar

2026-05-03T19:12:16Z

CRYSTL:

MediaWiki:Sidebar

2026-05-03T19:09:31Z

CRYSTL:

MediaWiki:Help-mediawiki

2026-05-03T19:09:01Z

CRYSTL:

Manual

MediaWiki:Help-mediawiki

2026-05-03T18:52:25Z

CRYSTL: Created page with "Wiki Manual"

Wiki Manual

MediaWiki:Mainpage-description

2026-05-03T18:49:31Z

CRYSTL: Created page with "Home Page"

Home Page

MediaWiki:Sidebar

2026-05-03T18:39:53Z

CRYSTL:

MediaWiki:Sidebar

2026-05-03T18:39:10Z

TODO

2026-05-03T18:06:24Z

CRYSTL: remove document > guidance TODO

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
** https://cryptpad.fr/pad/#/2/pad/view/v9+28PcpFVoMr4eVf-NpF64Do35ocDL3tQLbaWq2Bfk/
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** maybe also a table of contents or something?
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** how to use tables
** how to use templates
** how to use the WYSIWYG editor
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have matrix account
*** should describe teams they are in and <s>what roles they want to play</s>
**** Roles are now defined through [[Template:Add role]] and [[Template:User roles]] in a user page.
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?"
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)

Operations

2026-05-03T18:05:17Z

CRYSTL: document > writing

FASSAG has three [[Organization|main groups]], to facilitate the development of our resources; The guides group, the research group, and the software development group. It's what we think are the three most important aspects to focus on to achieve our goals.

== Guides ==
'''Free''' means that their should be as little costs as possible to everyone involved. Free to contribute, and free to read. Getting permission to contribute is as simple as asking in the [matrix] space. It's important for our community model that we can talk to and discuss changes that people have made if we need to.

'''Accessible''' guides isn't just about screen readers. The text should be written so that it is easy to read, and tries to avoid overly-technical explanations with a lot of jargon. Paragraphs should be capped at 5 or so sentences to avoid the "wall of text" effect. Docs should also try to target different skill/knowledge levels. But besides the guides being accessible, it's important to write about how to *make* computers be more accessible. That means testing things like:

* Screen readers
* High-Contrast modes
* Magnification
* Scaling settings
* Clear design
* Good guides
* Translations
* Low-end hardware

'''Safe''' software focuses not just on privacy and security, though of course those are important, but also things like no user-hostile features. Addictive design patterns for example, are very dangerous for many people. Things like, Infinite scrollers, algorithmic recommendations. It's also important to have guide rails to prevent the user from breaking their system, though of course experienced users should be able to lower them.

== Advocacy ==
It is important that people understand the importance of safe, secure, and private computing, especially now. A general malaise seems to have gripped much of the current populous about this, a feeling that it's not possible or feasible to have these goals. This however, is very important to fight against! Privacy, Security, and Safety are rights that everyone should have, especially when using a computer.

Being safe online is not just about making sure your accounts get stolen, but also thinking about what data you put where, and how that could be used against you. Make sure you are only trusting as much as you have to, and don't assume that a corporation is safe and has your back. Corporations are made of people, and their cloud, or servers, are just computers that they control. Think about where you're sending your data before you post a message or upload an image.

Part of advocacy is making sure that if there is no good solution, that we help to create one. While we're in early stages, our development capacity will be limited, but whenever we have the ability to, we should try to either improve existing software in these regards, or if impossible, make our own. Be reasonable though! Big goals like making an entire OS would be amazing, but we have to keep in mind how much time and effort we have at our disposal.

We'd also love to have some way to share computers with each other. Some of us may not have a laptop, maybe just a tablet, or a phone, and helping them get access to good computing hardware is critical for our mission. Figuring out how to do this safely and respectfully is a very important goal!

== Organization ==
{{Main|Organization}}

To facilitate work being done well, and also to help people figure out what Role to play within FASSAG, we have created several Teams and Roles. These Teams and Roles are fluid, and it's encouraged to switch between them if necessary or desired. These Teams and Roles are also not meant to indicate a power-structure, are goals require us to cooperate as equals.

Remember, it is very important that you do not over-work yourself. Pushing yourself too hard and burning out is the easiest way to hurt yourself while participating in a group like this, and we do not want you to hurt yourself! Also, check on your Teammates, to ensure they are not overworking themselves, but do keep in mind, everyone has different limits.

Different people also respond well to different types of motivation. You are encouraged to describe how you like to be motivated on your wiki profile! If you do not know, then you can ask your Teammates to try out different strategies with you and see how it works for you. For example, some people like reminders/management, and some don't want to be pressured. Some ground-rules though, deadlines are always soft. If you fail to meet a deadline there *must* not be any serious consequences for this. Rushing to meet hard deadlines is an easy way to burn yourself out.

Organization

2026-05-03T18:03:31Z

CRYSTL:

There are both Teams and Roles; Teams function to organize the work that is being done, and Roles are meant to guide how the Teams should organize. Which Roles you take will depend on what skills and experience you have, and what is needed by the Team your are interested in participating. You can have multiple Roles in multiple Teams, if you are able to keep up with the workload.

== Teams ==
There are currently two Teams, but if needs arise, we may create more later, or possible split up existing teams to spread the workload better.

=== R&G : Research and Guidance ===
The main goal of the R&G Team is to create the guides you are currently reading, and to inform the direction of the Development Team. Let's push the boundaries of what it means for software to be friendly and usable! There's no way to know what needs to be worked on without testing of existing tools, and keeping notes on it. But additionally, what we are able to share with the world, is what we have written here, in the wiki.

=== Development ===
The Development Team is for developing software solutions to software problems! We will need designers, artists, writers, translators, and of course, coders, to make this possible. Good software should adhere as much as possible to the goals laid out in [[Operations]]. Let's try to make our work as modular as we can. We want to be able to work in parallel as much as possible to get things done quickly, but we don't want spaghetti code. Cooperation is important! If you're working on something you think might affect what someone else is doing, ask them about it and make sure your not going to step on each others toes.

== Roles ==
Roles are fluid and you are encouraged to try out different roles to see how well you do, and how well you work with your team. You can of course take more than one Role, but do not over-work yourself! Talking to your Team about what roles you think you would do well at, and what types of roles are needed is very important! We all work best when we work together. Remember, the point of these rules is not to create a power structure, but to organize.

=== Role Templates ===
These roles are well documented and therefore are good to pick from. If you think a different role would be helpful or that something is missing here, please bring it up in [https://matrix.to/#/#fassag-general:chat.solarpunk.moe General]! None of these roles are intended to be exclusive to any Team!

* Lens
Lenses help focus the Team. Lenses should encourage, motivate, and direct. Members should have an idea of how they are best motivated, but if not, Lenses should try to help them figure that out. Lenses also function as oversight, to try to catch potential problems before they happen.
* Scribe
Scribes learn and guide. Scribes are heavily encouraged to talk to other members of their team to fill in gaps in their understanding. Whether documenting a project the Development Team is working on, or writing for the R&G team, Scribes should try to write as accessibly as possible. Of course, developer guides will inherently be a bit more technical, but they should aim to not make things any more technical than it has to be.
* Engineer
Engineers focus primarily on software itself. When implementing user-facing components, aim to follow guidelines we have already written! If nothing exists however, this is something to bring up with your team! Engineers are also very useful for research, as they will be able to understand why something is the way it is, in a way that those who cannot read code will not be able to.
* Designer
Designers have a very important job, as they will be focusing now just on what looks nice, but also on what is safe and accessible. Designers can help with style guides for writing, icons, UIs, or whatever else really. The goal here is to be creative!
* Tester
Testers should try to push the limits and find bugs and edge cases with the software we are working on and studying. Testers should try to also work with disabled people, to get a better understanding of what methods they use to interact with software, to test out different software using those methods.
* Outreach
This is for the bigger picture stuff. Whether it's managing social accounts, putting up posters, or whatever else, the goal is to get people involved, or at the very least, make people aware of our guides. Our goal is to help people, and we cannot help them if they do not know about us!

Organization

2026-05-03T17:59:39Z

CRYSTL: replace documentation with guides / guidance

There are both Teams and Roles; Teams function to organize the work that is being done, and Roles are meant to guide how the Teams should organize. Which Roles you take will depend on what skills and experience you have, and what is needed by the Team your are interested in participating. You can have multiple Roles in multiple Teams, if you are able to keep up with the workload.

== Teams ==
There are currently two Teams, but if needs arise, we may create more later, or possible split up existing teams to spread the workload better.

=== R&G : Research and Guidance ===
The main goal of the R&G Team is to create the guides you are currently reading, and to inform the direction of the Development Team. Let's push the boundaries of what it means for software to be friendly and usable! There's no way to know what needs to be worked on without testing of existing tools, and keeping notes on it. But additionally, what we are able to share with the world, is what we have written here, in the wiki.

=== Development ===
The Development Team is for developing software solutions to software problems! We will need designers, artists, writers, translators, and of course, coders, to make this possible. Good software should adhere as much as possible to the goals laid out in [[Operations]]. Let's try to make our work as modular as we can. We want to be able to work in parallel as much as possible to get things done quickly, but we don't want spaghetti code. Cooperation is important! If you're working on something you think might affect what someone else is doing, ask them about it and make sure your not going to step on each others toes.

== Roles ==
Roles are fluid and you are encouraged to try out different roles to see how well you do, and how well you work with your team. You can of course take more than one Role, but do not over-work yourself! Talking to your Team about what roles you think you would do well at, and what types of roles are needed is very important! We all work best when we work together. Remember, the point of these rules is not to create a power structure, but to organize.

=== Role Templates ===
These roles are well documented and therefore are good to pick from. If you think a different role would be helpful or that something is missing here, please bring it up in [https://matrix.to/#/#fassag-general:chat.solarpunk.moe General]! None of these roles are intended to be exclusive to any Team!

* Lens
Lenses help focus the Team. Lenses should encourage, motivate, and direct. Members should have an idea of how they are best motivated, but if not, Lenses should try to help them figure that out. Lenses also function as oversight, to try to catch potential problems before they happen.
* Scribe
Scribes learn and document. Scribes are heavily encouraged to talk to other members of their team to fill in gaps in their understanding. Whether documenting a project the Development Team is working on, or writing for the R&G team, Scribes should try to write as Accessibly as possible. Of course, developer guides will inherently be a bit more technical, but they should aim to not make things any more technical than it has to be.
* Engineer
Engineers focus primarily on software itself. When implementing user-facing components, aim to follow guidelines we have already written! If nothing exists however, this is something to bring up with your team! Engineers are also very useful for research, as they will be able to understand why something is the way it is, in a way that those who cannot read code will not be able to.
* Designer
Designers have a very important job, as they will be focusing now just on what looks nice, but also on what is safe and accessible. Designers can help with style guides for writing, icons, UIs, or whatever else really. The goal here is to be creative!
* Tester
Testers should try to push the limits and find bugs and edge cases with the software we are working on and studying. Testers should try to also work with disabled people, to get a better understanding of what methods they use to interact with software, to test out different software using those methods.
* Outreach
This is for the bigger picture stuff. Whether it's managing social accounts, putting up posters, or whatever else, the goal is to get people involved, or at the very least, make people aware of our guides. Our goal is to help people, and we cannot help them if they do not know about us!

Operations

2026-05-03T17:57:34Z

CRYSTL: replace documentation with guides

FASSAG has three [[Organization|main groups]], to facilitate the development of our resources; The guides group, the research group, and the software development group. It's what we think are the three most important aspects to focus on to achieve our goals.

== Guides ==
'''Free''' means that their should be as little costs as possible to everyone involved. Free to contribute, and free to read. Getting permission to contribute is as simple as asking in the [matrix] space. It's important for our community model that we can talk to and discuss changes that people have made if we need to.

'''Accessible''' guides isn't just about screen readers. The text should be written so that it is easy to read, and tries to avoid overly-technical explanations with a lot of jargon. Paragraphs should be capped at 5 or so sentences to avoid the "wall of text" effect. Docs should also try to target different skill/knowledge levels. But besides the guides being accessible, it's important to document how to *make* computers be more accessible. That means testing things like:

* Screen readers
* High-Contrast modes
* Magnification
* Scaling settings
* Clear design
* Good guides
* Translations
* Low-end hardware

'''Safe''' software focuses not just on privacy and security, though of course those are important, but also things like no user-hostile features. Addictive design patterns for example, are very dangerous for many people. Things like, Infinite scrollers, algorithmic recommendations. It's also important to have guide rails to prevent the user from breaking their system, though of course experienced users should be able to lower them.

== Advocacy ==
It is important that people understand the importance of safe, secure, and private computing, especially now. A general malaise seems to have gripped much of the current populous about this, a feeling that it's not possible or feasible to have these goals. This however, is very important to fight against! Privacy, Security, and Safety are rights that everyone should have, especially when using a computer.

Being safe online is not just about making sure your accounts get stolen, but also thinking about what data you put where, and how that could be used against you. Make sure you are only trusting as much as you have to, and don't assume that a corporation is safe and has your back. Corporations are made of people, and their cloud, or servers, are just computers that they control. Think about where you're sending your data before you post a message or upload an image.

Part of advocacy is making sure that if there is no good solution, that we help to create one. While we're in early stages, our development capacity will be limited, but whenever we have the ability to, we should try to either improve existing software in these regards, or if impossible, make our own. Be reasonable though! Big goals like making an entire OS would be amazing, but we have to keep in mind how much time and effort we have at our disposal.

We'd also love to have some way to share computers with each other. Some of us may not have a laptop, maybe just a tablet, or a phone, and helping them get access to good computing hardware is critical for our mission. Figuring out how to do this safely and respectfully is a very important goal!

== Organization ==
{{Main|Organization}}

To facilitate work being done well, and also to help people figure out what Role to play within FASSAG, we have created several Teams and Roles. These Teams and Roles are fluid, and it's encouraged to switch between them if necessary or desired. These Teams and Roles are also not meant to indicate a power-structure, are goals require us to cooperate as equals.

Remember, it is very important that you do not over-work yourself. Pushing yourself too hard and burning out is the easiest way to hurt yourself while participating in a group like this, and we do not want you to hurt yourself! Also, check on your Teammates, to ensure they are not overworking themselves, but do keep in mind, everyone has different limits.

Different people also respond well to different types of motivation. You are encouraged to describe how you like to be motivated on your wiki profile! If you do not know, then you can ask your Teammates to try out different strategies with you and see how it works for you. For example, some people like reminders/management, and some don't want to be pressured. Some ground-rules though, deadlines are always soft. If you fail to meet a deadline there *must* not be any serious consequences for this. Rushing to meet hard deadlines is an easy way to burn yourself out.

User:CRYSTL

2026-05-03T17:33:22Z

CRYSTL:

Hello , we are CRYSTL !

We are happy to help with whatever problems you may have !

You can reach us on matrix at @crystallinefire:chat.solarpunk.moe

{{User roles}}
{{Add role|lens}}
{{Add role|outreach}}
{{Add role|scribe}}
{{Add role|engineer}}
{{Add role|designer}}
{{Add role|tester}}

Main Page

2026-05-03T17:27:41Z

CRYSTL: add TODO entry , change " -- " to " — " , remove extra space

Welcome to the '''FASSAG Wiki'''. This editable knowledge base contains an ever-changing collection of resources developed by the organization.

== What is FASSAG? ==

====== The Free Accessible Safe Software Advocacy Group ======
Our mission is to reach out and make technology accessible and easy to understand. We seek to provide resources and guidance on computer safety, guides on various software, at whatever level of complexity is right for you. You can get involved as much as you'd like! Whether you want to help out with research, or writing guides, or perhaps you're a developer and want to help improve software, we'd be happy to have your support.

== Getting Started ==

* [https://fassag.dev Home] — Get a top level view on our mission.
* [[TODO]] — What we're currently working on.
* [[Operations]] — Get a detailed look at how we operate.
* [https://codeberg.org/FASSAG Forge] — The Codeberg organization where all our code is stored.
* [https://matrix.to/#/#fassag-entrance:chat.solarpunk.moe?client=element.io Matrix Space] — Join to chat about FASSAG.

User:VV

2026-04-19T20:07:23Z

CRYSTL:

'''This page has been vandalized 1 times.''' ''You can help by vandalizing it.''

ඞ

TODO

2026-04-19T19:41:07Z

CRYSTL:

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
** https://cryptpad.fr/pad/#/2/pad/view/v9+28PcpFVoMr4eVf-NpF64Do35ocDL3tQLbaWq2Bfk/
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** maybe also a table of contents or something?
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** consider whether guide or documentation is a better word to use
*** probably i ended up choosing documentation because R&D ( research and documentation ) was kinda cool but TBH it's also a bit confusing, so guides are probably better
** how to use tables
** how to use templates
** how to use the WYSIWYG editor
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have matrix account
*** should describe teams they are in and what roles they want to play
*** a description of their skills and interests
*** DRAFT : [[User:Everlastingred]]
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?"
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)

User:Everlastingred

2026-04-19T19:31:08Z

CRYSTL:

== About Me ==
{| class="wikitable"
|+
! colspan="2" |Contact
|-
|Matrix
|@everlastingred:chat.solarpunk.moe
|-
!Teams
!Roles
|-
|Super Spahgetti Squadron
|Head Osaka Kasuga image procurer
|-
|MTF Gamma-5 (“Red Herrings”)
|Moral Support girlie
|}

== Skills and Interests ==

=== Skills: ===

* Programming
* Pro Gramming

=== Interests: ===

* Osaka
* Gaming

TODO

2026-04-19T18:43:19Z

CRYSTL: added braille / TTS section

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
** https://cryptpad.fr/pad/#/2/pad/view/v9+28PcpFVoMr4eVf-NpF64Do35ocDL3tQLbaWq2Bfk/
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** maybe also a table of contents or something?
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
** consider whether guide or documentation is a better word to use
*** probably i ended up choosing documentation because R&D ( research and documentation ) was kinda cool but TBH it's also a bit confusing, so guides are probably better
* Braille / TTS support on linux
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$YQue0cGGqU5KXtuNEOPpbZUl_-M25V1fj46S8kJA2q0?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Matrix] reference</nowiki>]
* Templates
** user profile information template (need to flesh out how this will look)
*** should have matrix account
*** should describe teams they are in and what roles they want to play
*** a description of their skills and interests
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?"
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)

TODO

2026-04-19T18:40:24Z

CRYSTL: formatting and such

This page is a list of projects currently being worked on and references to relevant information.

* Write a page describing how matrix works, how it relates to FASSAG, and some client quirks to be aware of.
** Maybe these should be separate pages?
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$9flQpMULrrZ9q3sM1CIKtDdwpHCC_YFOCDbXeAevn7M?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] consider having a dedicated page to matrix</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$B46BEaqrLtxuJ5BvQt_z8qzDZD4VIq2grk2MS1R6F_I?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] the matrix.to page is apparently just broken ,,, the icon is just not viewable .</nowiki>]
** [https://matrix.to/#/!dkSMcP-EtUFhf2SZZR4nwSHGI0RVq1Sr2p-zguVoLNI/$-TvpInGLsJ_8wHilOnuKDYtP8D9T4C5DJIMQRsiAf_U?via=chat.solarpunk.moe&via=matrix.org <nowiki>[Thread] Yeah so it commet receives a thread reply, it inserts the thread parent into the thread body instead of the new thread reply message</nowiki>]
* Finish LUKS guide , and probably split it up into simpler and more advanced guides
** https://cryptpad.fr/pad/#/2/pad/view/v9+28PcpFVoMr4eVf-NpF64Do35ocDL3tQLbaWq2Bfk/
** NOTES:
*** for a bit of context as to why i wanted to write this in the first place, someone asked me "if i want the best security, how do i setup a LUKS partition?" and based on that question, I assume that just telling them "the defaults are fine" would not be a particularly satisfying answer. so i did my best to research everything, and tried to compile an exhaustive list of reasons why the defaults are OK. i went in assuming that there might be like, some algorithm that has a very strong performance cost for better security, but ultimately concluded, that wasn't really the case . but like , only after trying to understand everything.
*** "a good amount of this information is pulled from [link]" by itself sounds kinda weird, like why should someone read your post instead of just going to that link immediately? perhaps "The [cryptsetup FAQ](...) is a great in-depth resource on all the available security options, but it's pretty long and complex. This post will cover the basics so you can get set up quickly with a reasonably secure system."
*** if your system is starved of entropy, one technique I've seen is to use random.org , e.g. <code>curl -Ss <nowiki>https://www.random.org/cgi-bin/randbyte?nbytes=16384&format=f</nowiki> > /dev/random</code>
**** then you should be able to run any programs that would block on /dev/random
*** you should define what "post quantum resistant" means if you're going to mention it, IMO
*** ZFS actually uses an authenticated encryption mode by default (AES-GCM) which is how it can detect tampering. i think this is what you meant, but saying "XTS vulnerabilities can be mitigated with ZFS or BTRFS" is a little less clear than "XTS has vulnerabilities '''under certain threat models''', such as A, B and C [IMO if you're going to mention this you should also explain what the vulnerabilities are, you can't just drop this with no context]. If you are concerned about these issues, you should use an authenticated encryption mode like AES-GCM, which is unfortunately not available with LUKS due to the additional space needed for the authentication tags, but can be accomplished with a supporting filesystem such as ZFS."
**** i don't remember where i read that "ZFS and BTRFS will help with the corruption issues of XTS" they may not have even been talking about LUKS directly and i just got confused (it was probably Wikipedia)
*** i guess to expand on this, if you have a good idea of what your target audience is then you should be evaluating everything in the post from that point of view. suppose you are a beginner who doesn't know anything about crypto. "XTS has vulnerabilities" and "AES-256 is post quantum" are meaningless to u without further context. maybe the context for those things isn't the point of the post, but in that case u could maybe link to further resources or have some further explanation in footnotes
* A guide on how to use and navigate around the WIKI would be a very good idea
** maybe also a table of contents or something?
** TBH I'm not entirely sure how wikis are usually structured, maybe something to look into
*** from what i can remember offhand, usually the home page has some links to more specific topics, which then link out to other articles
**** probably there *shouldn't* be an orphaned articles
** we could also figure out if we want to have a more "document" focused theme for desktop like maybe [[mediawikiwiki:BlueSpice|BlueSpice]]
*** if we have something less functional than [[mediawikiwiki:BlueSpice|BlueSpice]] though, we'll want to explain in the guide how to change the default user theme if someone is interested in doing editing
* consider whether guide or documentation is a better word to use
** probably i ended up choosing documentation because R&D ( research and documentation ) was kinda cool but TBH it's also a bit confusing, so guides are probably better
*
* Templates
** user profile information template (need to flesh out how this will look)
*** should have matrix account
*** should describe teams they are in and what roles they want to play
*** a description of their skills and interests
** TODO item template? probably to gather information from relevant pages but some TODOs will likely not have a page? dunno, something to think about
** "this page is not yet completed" / "this page is a draft?"
** "this page is a placeholder"
** "this page is an accessory to another?" (maybe see or see also cover this, IDK)

TODO

2026-04-19T18:25:42Z

CRYSTL: add more notes to the LUKS article

TODO

2026-04-19T18:22:38Z

CRYSTL: fix punctuation

TODO

2026-04-19T18:21:44Z

CRYSTL: start TODO page

Main Page

2026-03-29T20:38:14Z

CRYSTL: updated link to the fassag entrance

Welcome to the '''FASSAG Wiki'''. This editable knowledge base contains an ever-changing collection of resources developed by the organization.

== What is FASSAG ? ==

====== The Free Accessible Safe Software Advocacy Group ======
Our mission is to reach out and make technology accessible and easy to understand. We seek to provide resources and guidance on computer safety, guides on various software, at whatever level of complexity is right for you. You can get involved as much as you'd like! Whether you want to help out with research, or writing guides, or perhaps you're a developer and want to help improve software, we'd be happy to have your support.

== Getting Started ==

* [https://fassag.dev Home] -- Get a top level view on our mission.
* [[Operations]] -- Get a detailed look at how we operate.
* [https://codeberg.org/FASSAG Forge] -- The Codeberg organization where all our code is stored.
* [https://matrix.to/#/#fassag-entrance:chat.solarpunk.moe?client=element.io Matrix Space] -- Join to chat about FASSAG.

Organization

2026-03-29T18:35:24Z

CRYSTL:

There are both Teams and Roles; Teams function to organize the work that is being done, and Roles are meant to guide how the Teams should organize. Which Roles you take will depend on what skills and experience you have, and what is needed by the Team your are interested in participating. You can have multiple Roles in multiple Teams, if you are able to keep up with the workload.

== Teams ==
There are currently two Teams, but if needs arise, we may create more later, or possible split up existing teams to spread the workload better.

=== R&D : Research and Documentation ===
The main goal of the R&D Team is to create the documentation you are currently reading, and to inform the direction of the Development Team. Let's push the boundaries of what it means for software to be friendly and usable! There's no way to know what needs to be worked on without testing of existing tools, and keeping notes on it. But additionally, what we are able to share with the world, is what we have written here, in the wiki.

=== Development ===
The Development Team is for developing software solutions to software problems! We will need designers, artists, writers, translators, and of course, coders, to make this possible. Good software should adhere as much as possible to the goals laid out in [[Operations]]. Let's try to make our work as modular as we can. We want to be able to work in parallel as much as possible to get things done quickly, but we don't want spaghetti code. Cooperation is important! If you're working on something you think might affect what someone else is doing, ask them about it and make sure your not going to step on each others toes.

== Roles ==
Roles are fluid and you are encouraged to try out different roles to see how well you do, and how well you work with your team. You can of course take more than one Role, but do not over-work yourself! Talking to your Team about what roles you think you would do well at, and what types of roles are needed is very important! We all work best when we work together. Remember, the point of these rules is not to create a power structure, but to organize.

=== Role Templates ===
These roles are well documented and therefore are good to pick from. If you think a different role would be helpful or that something is missing here, please bring it up in [https://matrix.to/#/#fassag-general:chat.solarpunk.moe General]! None of these roles are intended to be exclusive to any Team!

* Lens
Lenses help focus the Team. Lenses should encourage, motivate, and direct. Members should have an idea of how they are best motivated, but if not, Lenses should try to help them figure that out. Lenses also function as oversight, to try to catch potential problems before they happen.
* Scribe
Scribes learn and document. Scribes are heavily encouraged to talk to other members of their team to fill in gaps in their understanding. Whether documenting a project the Development Team is working on, or writing for the R&D team, Scribes should try to write as Accessibly as possible. Of course, developer documentation will inherently be a bit more technical, but they should aim to not make things any more technical than it has to be.
* Engineer
Engineers focus primarily on software itself. When implementing user-facing components, aim to follow guidelines we have already written! If nothing exists however, this is something to bring up with your team! Engineers are also very useful for research, as they will be able to understand why something is the way it is, in a way that those who cannot read code will not be able to.
* Designer
Designers have a very important job, as they will be focusing now just on what looks nice, but also on what is safe and accessible. Designers can help with style guides for writing, icons, UIs, or whatever else really. The goal here is to be creative!
* Tester
Testers should try to push the limits and find bugs and edge cases with the software we are working on and studying. Testers should try to also work with disabled people, to get a better understanding of what methods they use to interact with software, to test out different software using those methods.
* Outreach
This is for the bigger picture stuff. Whether it's managing social accounts, putting up posters, or whatever else, the goal is to get people involved, or at the very least, make people aware of our documentation. Our goal is to help people, and we cannot help them if they do not know about us!

Organization

2026-03-29T17:51:47Z

CRYSTL: add roles meta info

Operations

2026-03-22T18:56:26Z

CRYSTL: fix capitatlization

FASSAG has three main branches, to facilitate the development of our resources; The documentation group, the research group, and the software development group. It's what we think are the three most important aspects to focus on to achieve our goals.

== Documentation ==
'''Free''' means that their should be as little costs as possible to everyone involved. Free to contribute, and free to read. Getting permission to contribute is as simple as asking in the [matrix] space. It's important for our community model that we can talk to and discuss changes that people have made if we need to.

'''Accessible''' documentation isn't just about screen readers. The text should be written so that it is easy to read, and tries to avoid overly-technical explanations with a lot of jargon. Paragraphs should be capped at 5 or so sentences to avoid the "wall of text" effect. Docs should also try to target different skill/knowledge levels. But besides the documentation being accessible, it's important to document how to *make* computers be more accessible. That means testing things like:

* Screen readers
* High-Contrast modes
* Magnification
* Scaling settings
* Clear design
* Good documentation
* Translations
* Low-end hardware

'''Safe''' software focuses not just on privacy and security, though of course those are important, but also things like no user-hostile features. Addictive design patterns for example, are very dangerous for many people. Things like, Infinite scrollers, algorithmic recommendations. It's also important to have guide rails to prevent the user from breaking their system, though of course experienced users should be able to lower them.

== Advocacy ==
It is important that people understand the importance of safe, secure, and private computing, especially now. A general malaise seems to have gripped much of the current populous about this, a feeling that it's not possible or feasible to have these goals. This however, is very important to fight against! Privacy, Security, and Safety are rights that everyone should have, especially when using a computer.

Being safe online is not just about making sure your accounts get stolen, but also thinking about what data you put where, and how that could be used against you. Make sure you are only trusting as much as you have to, and don't assume that a corporation is safe and has your back. Corporations are made of people, and their cloud, or servers, are just computers that they control. Think about where you're sending your data before you post a message or upload an image.

Part of advocacy is making sure that if there is no good solution, that we help to create one. While we're in early stages, our development capacity will be limited, but whenever we have the ability to, we should try to either improve existing software in these regards, or if impossible, make our own. Be reasonable though! Big goals like making an entire OS would be amazing, but we have to keep in mind how much time and effort we have at our disposal.

We'd also love to have some way to share computers with each other. Some of us may not have a laptop, maybe just a tablet, or a phone, and helping them get access to good computing hardware is critical for our mission. Figuring out how to do this safely and respectfully is a very important goal!

== [[Organization]] ==
To facilitate work being done well, and also to help people figure out what Role to play within FASSAG, we have created several Teams and Roles. These Teams and Roles are fluid, and it's encouraged to switch between them if necessary or desired. These Teams and Roles are also not meant to indicate a power-structure, are goals require us to cooperate as equals.

Remember, it is very important that you do not over-work yourself. Pushing yourself too hard and burning out is the easiest way to hurt yourself while participating in a group like this, and we do not want you to hurt yourself! Also, check on your Teammates, to ensure they are not overworking themselves, but do keep in mind, everyone has different limits.

Different people also respond well to different types of motivation. You are encouraged to describe how you like to be motivated on your wiki profile! If you do not know, then you can ask your Teammates to try out different strategies with you and see how it works for you. For example, some people like reminders/management, and some don't want to be pressured. Some ground-rules though, deadlines are always soft. If you fail to meet a deadline there *must* not be any serious consequences for this. Rushing to meet hard deadlines is an easy way to burn yourself out.

Operations

2026-03-22T18:55:30Z

CRYSTL: change organization to be a link

FASSAG has three main branches, to facilitate the development of our resources; The documentation group, the research group, and the software development group. It's what we think are the three most important aspects to focus on to achieve our goals.

== Documentation ==
'''Free''' means that their should be as little costs as possible to everyone involved. Free to contribute, and free to read. Getting permission to contribute is as simple as asking in the [matrix] space. It's important for our community model that we can talk to and discuss changes that people have made if we need to.

'''Accessible''' documentation isn't just about screen readers. The text should be written so that it is easy to read, and tries to avoid overly-technical explanations with a lot of jargon. Paragraphs should be capped at 5 or so sentences to avoid the "wall of text" effect. Docs should also try to target different skill/knowledge levels. But besides the documentation being accessible, it's important to document how to *make* computers be more accessible. That means testing things like:

* Screen readers
* High-Contrast modes
* Magnification
* Scaling settings
* Clear design
* Good documentation
* Translations
* Low-end hardware

'''Safe''' software focuses not just on privacy and security, though of course those are important, but also things like no user-hostile features. Addictive design patterns for example, are very dangerous for many people. Things like, Infinite scrollers, algorithmic recommendations. It's also important to have guide rails to prevent the user from breaking their system, though of course experienced users should be able to lower them.

== Advocacy ==
It is important that people understand the importance of safe, secure, and private computing, especially now. A general malaise seems to have gripped much of the current populous about this, a feeling that it's not possible or feasible to have these goals. This however, is very important to fight against! Privacy, Security, and Safety are rights that everyone should have, especially when using a computer.

Being safe online is not just about making sure your accounts get stolen, but also thinking about what data you put where, and how that could be used against you. Make sure you are only trusting as much as you have to, and don't assume that a corporation is safe and has your back. Corporations are made of people, and their cloud, or servers, are just computers that they control. Think about where you're sending your data before you post a message or upload an image.

Part of advocacy is making sure that if there is no good solution, that we help to create one. While we're in early stages, our development capacity will be limited, but whenever we have the ability to, we should try to either improve existing software in these regards, or if impossible, make our own. Be reasonable though! Big goals like making an entire OS would be amazing, but we have to keep in mind how much time and effort we have at our disposal.

We'd also love to have some way to share computers with each other. Some of us may not have a laptop, maybe just a tablet, or a phone, and helping them get access to good computing hardware is critical for our mission. Figuring out how to do this safely and respectfully is a very important goal!

== [[Organization]] ==
To facilitate work being done well, and also to help people figure out what role to play within FASSAG, we have created several Teams and Roles. These teams and roles are fluid, and it's encouraged to switch between them if necessary or desired. These teams and roles are also not meant to indicate a power-structure, are goals require us to cooperate as equals.

Remember, it is very important that you do not over-work yourself. Pushing yourself too hard and burning out is the easiest way to hurt yourself while participating in a group like this, and we do not want you to hurt yourself! Also, check on your Teammates, to ensure they are not overworking themselves, but do keep in mind, everyone has different limits.

Different people also respond well to different types of motivation. You are encouraged to describe how you like to be motivated on your wiki profile! If you do not know, then you can ask your Teammates to try out different strategies with you and see how it works for you. For example, some people like reminders/management, and some don't want to be pressured. Some ground-rules though, deadlines are always soft. If you fail to meet a deadline there *must* not be any serious consequences for this. Rushing to meet hard deadlines is an easy way to burn yourself out.

Organization

2026-03-22T18:55:03Z

CRYSTL: add teams

Operations

2026-03-22T18:51:26Z

CRYSTL: add section about motivation / management

FASSAG has three main branches, to facilitate the development of our resources; The documentation group, the research group, and the software development group. It's what we think are the three most important aspects to focus on to achieve our goals.

== Documentation ==
'''Free''' means that their should be as little costs as possible to everyone involved. Free to contribute, and free to read. Getting permission to contribute is as simple as asking in the [matrix] space. It's important for our community model that we can talk to and discuss changes that people have made if we need to.

'''Accessible''' documentation isn't just about screen readers. The text should be written so that it is easy to read, and tries to avoid overly-technical explanations with a lot of jargon. Paragraphs should be capped at 5 or so sentences to avoid the "wall of text" effect. Docs should also try to target different skill/knowledge levels. But besides the documentation being accessible, it's important to document how to *make* computers be more accessible. That means testing things like:

* Screen readers
* High-Contrast modes
* Magnification
* Scaling settings
* Clear design
* Good documentation
* Translations
* Low-end hardware

'''Safe''' software focuses not just on privacy and security, though of course those are important, but also things like no user-hostile features. Addictive design patterns for example, are very dangerous for many people. Things like, Infinite scrollers, algorithmic recommendations. It's also important to have guide rails to prevent the user from breaking their system, though of course experienced users should be able to lower them.

== Advocacy ==
It is important that people understand the importance of safe, secure, and private computing, especially now. A general malaise seems to have gripped much of the current populous about this, a feeling that it's not possible or feasible to have these goals. This however, is very important to fight against! Privacy, Security, and Safety are rights that everyone should have, especially when using a computer.

Being safe online is not just about making sure your accounts get stolen, but also thinking about what data you put where, and how that could be used against you. Make sure you are only trusting as much as you have to, and don't assume that a corporation is safe and has your back. Corporations are made of people, and their cloud, or servers, are just computers that they control. Think about where you're sending your data before you post a message or upload an image.

Part of advocacy is making sure that if there is no good solution, that we help to create one. While we're in early stages, our development capacity will be limited, but whenever we have the ability to, we should try to either improve existing software in these regards, or if impossible, make our own. Be reasonable though! Big goals like making an entire OS would be amazing, but we have to keep in mind how much time and effort we have at our disposal.

We'd also love to have some way to share computers with each other. Some of us may not have a laptop, maybe just a tablet, or a phone, and helping them get access to good computing hardware is critical for our mission. Figuring out how to do this safely and respectfully is a very important goal!

== Organization [[Organization|Main Page]] ==
To facilitate work being done well, and also to help people figure out what role to play within FASSAG, we have created several Teams and Roles. These teams and roles are fluid, and it's encouraged to switch between them if necessary or desired. These teams and roles are also not meant to indicate a power-structure, are goals require us to cooperate as equals.

Remember, it is very important that you do not over-work yourself. Pushing yourself too hard and burning out is the easiest way to hurt yourself while participating in a group like this, and we do not want you to hurt yourself! Also, check on your Teammates, to ensure they are not overworking themselves, but do keep in mind, everyone has different limits.

Different people also respond well to different types of motivation. You are encouraged to describe how you like to be motivated on your wiki profile! If you do not know, then you can ask your Teammates to try out different strategies with you and see how it works for you. For example, some people like reminders/management, and some don't want to be pressured. Some ground-rules though, deadlines are always soft. If you fail to meet a deadline there *must* not be any serious consequences for this. Rushing to meet hard deadlines is an easy way to burn yourself out.

Operations

2026-03-22T18:30:35Z

CRYSTL: add note about overwork to organization section

FASSAG has three main branches, to facilitate the development of our resources; The documentation group, the research group, and the software development group. It's what we think are the three most important aspects to focus on to achieve our goals.

== Documentation ==
'''Free''' means that their should be as little costs as possible to everyone involved. Free to contribute, and free to read. Getting permission to contribute is as simple as asking in the [matrix] space. It's important for our community model that we can talk to and discuss changes that people have made if we need to.

'''Accessible''' documentation isn't just about screen readers. The text should be written so that it is easy to read, and tries to avoid overly-technical explanations with a lot of jargon. Paragraphs should be capped at 5 or so sentences to avoid the "wall of text" effect. Docs should also try to target different skill/knowledge levels. But besides the documentation being accessible, it's important to document how to *make* computers be more accessible. That means testing things like:

* Screen readers
* High-Contrast modes
* Magnification
* Scaling settings
* Clear design
* Good documentation
* Translations
* Low-end hardware

'''Safe''' software focuses not just on privacy and security, though of course those are important, but also things like no user-hostile features. Addictive design patterns for example, are very dangerous for many people. Things like, Infinite scrollers, algorithmic recommendations. It's also important to have guide rails to prevent the user from breaking their system, though of course experienced users should be able to lower them.

== Advocacy ==
It is important that people understand the importance of safe, secure, and private computing, especially now. A general malaise seems to have gripped much of the current populous about this, a feeling that it's not possible or feasible to have these goals. This however, is very important to fight against! Privacy, Security, and Safety are rights that everyone should have, especially when using a computer.

Being safe online is not just about making sure your accounts get stolen, but also thinking about what data you put where, and how that could be used against you. Make sure you are only trusting as much as you have to, and don't assume that a corporation is safe and has your back. Corporations are made of people, and their cloud, or servers, are just computers that they control. Think about where you're sending your data before you post a message or upload an image.

Part of advocacy is making sure that if there is no good solution, that we help to create one. While we're in early stages, our development capacity will be limited, but whenever we have the ability to, we should try to either improve existing software in these regards, or if impossible, make our own. Be reasonable though! Big goals like making an entire OS would be amazing, but we have to keep in mind how much time and effort we have at our disposal.

We'd also love to have some way to share computers with each other. Some of us may not have a laptop, maybe just a tablet, or a phone, and helping them get access to good computing hardware is critical for our mission. Figuring out how to do this safely and respectfully is a very important goal!

== Organization [[Organization|Main Page]] ==
To facilitate work being done well, and also to help people figure out what role to play within FASSAG, we have created several Teams and Roles. These teams and roles are fluid, and it's encouraged to switch between them if necessary or desired. These teams and roles are also not meant to indicate a power-structure, are goals require us to cooperate as equals.

Remember, it is very important that you do not over-work yourself. Pushing yourself too hard and burning out is the easiest way to hurt yourself while participating in a group like this, and we do not want you to hurt yourself! Also, check on your Teammates, to ensure they are not overworking themselves, but do keep in mind, everyone has different limits.

Operations

2026-03-22T18:20:02Z

CRYSTL: add organization stub

FASSAG has three main branches, to facilitate the development of our resources; The documentation group, the research group, and the software development group. It's what we think are the three most important aspects to focus on to achieve our goals.

== Documentation ==
'''Free''' means that their should be as little costs as possible to everyone involved. Free to contribute, and free to read. Getting permission to contribute is as simple as asking in the [matrix] space. It's important for our community model that we can talk to and discuss changes that people have made if we need to.

'''Accessible''' documentation isn't just about screen readers. The text should be written so that it is easy to read, and tries to avoid overly-technical explanations with a lot of jargon. Paragraphs should be capped at 5 or so sentences to avoid the "wall of text" effect. Docs should also try to target different skill/knowledge levels. But besides the documentation being accessible, it's important to document how to *make* computers be more accessible. That means testing things like:

* Screen readers
* High-Contrast modes
* Magnification
* Scaling settings
* Clear design
* Good documentation
* Translations
* Low-end hardware

'''Safe''' software focuses not just on privacy and security, though of course those are important, but also things like no user-hostile features. Addictive design patterns for example, are very dangerous for many people. Things like, Infinite scrollers, algorithmic recommendations. It's also important to have guide rails to prevent the user from breaking their system, though of course experienced users should be able to lower them.

== Advocacy ==
It is important that people understand the importance of safe, secure, and private computing, especially now. A general malaise seems to have gripped much of the current populous about this, a feeling that it's not possible or feasible to have these goals. This however, is very important to fight against! Privacy, Security, and Safety are rights that everyone should have, especially when using a computer.

Being safe online is not just about making sure your accounts get stolen, but also thinking about what data you put where, and how that could be used against you. Make sure you are only trusting as much as you have to, and don't assume that a corporation is safe and has your back. Corporations are made of people, and their cloud, or servers, are just computers that they control. Think about where you're sending your data before you post a message or upload an image.

Part of advocacy is making sure that if there is no good solution, that we help to create one. While we're in early stages, our development capacity will be limited, but whenever we have the ability to, we should try to either improve existing software in these regards, or if impossible, make our own. Be reasonable though! Big goals like making an entire OS would be amazing, but we have to keep in mind how much time and effort we have at our disposal.

We'd also love to have some way to share computers with each other. Some of us may not have a laptop, maybe just a tablet, or a phone, and helping them get access to good computing hardware is critical for our mission. Figuring out how to do this safely and respectfully is a very important goal!

== Organization [[Organization|Main Page]] ==
To facilitate work being done well, and also to help people figure out what role to play within FASSAG, we have created several Teams and Roles. These teams and roles are fluid, and it's encouraged to switch between them if necessary or desired. These teams and roles are also not meant to indicate a power-structure, are goals require us to cooperate as equals.

Operations

2026-03-22T17:58:50Z

CRYSTL: add advocacy section

FASSAG has three main branches, to facilitate the development of our resources; The documentation group, the research group, and the software development group. It's what we think are the three most important aspects to focus on to achieve our goals.

== Documentation ==
'''Free''' means that their should be as little costs as possible to everyone involved. Free to contribute, and free to read. Getting permission to contribute is as simple as asking in the [matrix] space. It's important for our community model that we can talk to and discuss changes that people have made if we need to.

'''Accessible''' documentation isn't just about screen readers. The text should be written so that it is easy to read, and tries to avoid overly-technical explanations with a lot of jargon. Paragraphs should be capped at 5 or so sentences to avoid the "wall of text" effect. Docs should also try to target different skill/knowledge levels. But besides the documentation being accessible, it's important to document how to *make* computers be more accessible. That means testing things like:

* Screen readers
* High-Contrast modes
* Magnification
* Scaling settings
* Clear design
* Good documentation
* Translations
* Low-end hardware

'''Safe''' software focuses not just on privacy and security, though of course those are important, but also things like no user-hostile features. Addictive design patterns for example, are very dangerous for many people. Things like, Infinite scrollers, algorithmic recommendations. It's also important to have guide rails to prevent the user from breaking their system, though of course experienced users should be able to lower them.

== Advocacy ==
It is important that people understand the importance of safe, secure, and private computing, especially now. A general malaise seems to have gripped much of the current populous about this, a feeling that it's not possible or feasible to have these goals. This however, is very important to fight against! Privacy, Security, and Safety are rights that everyone should have, especially when using a computer.

Being safe online is not just about making sure your accounts get stolen, but also thinking about what data you put where, and how that could be used against you. Make sure you are only trusting as much as you have to, and don't assume that a corporation is safe and has your back. Corporations are made of people, and their cloud, or servers, are just computers that they control. Think about where you're sending your data before you post a message or upload an image.

Part of advocacy is making sure that if there is no good solution, that we help to create one. While we're in early stages, our development capacity will be limited, but whenever we have the ability to, we should try to either improve existing software in these regards, or if impossible, make our own. Be reasonable though! Big goals like making an entire OS would be amazing, but we have to keep in mind how much time and effort we have at our disposal.

We'd also love to have some way to share computers with eachother. Some of us may not have a laptop, maybe just a tablet, or a phone, and helping them get access to good computing hardware is critical for our mission. Figuring out how to do this safely and respectfully is a very important goal!

Operations

2026-03-22T17:39:59Z

CRYSTL: add documentation summary

Operations

2026-03-18T14:35:52Z

CRYSTL: