@prologic@twtxt.net I canβt write the whole thing; besides not being informed enough, I definitely donβt have the time. But hereβs a start:
The notion is that you produce a list of threat actors (who youβre worried about misbehaving), affected data (what data these actors might have some affect on), and vulnerabilities (what could the threat actor do to the data that you donβt want them to do. Vulnerability can be driven by the βCIAβ triad: confidentiality, integrity, and availability. With any data, you potentially want it to remain confidential (the C); you want the integrity to remain intact (the I; you donβt want it spoofed, or modified, or deleted by someone else without authorization); and you want that data to be available to whoever should have it when they should have it (the A). You need to put some thought into this and fill out these lists as fully as you can. Probably everyone who uses salty should help.
Then, a threat model is a table like the one I put below. The one line I entered should be read βit is possible that one salty user can learn the IP address of another salty userβ. You may or may not care about that, so there is a priority column. Again, this table could be crowdsourced among salty users.
Threat Actors- other salty.im users
- salty.im server operators
- VPS operators
- network operators
- casual eavesdroppers
- law enforcement
- state actors
- login id
- login (IP) address
- login session times and durations
- chat session times, durations, participants
- contents of chats
- learn the data
- spoof the data
- delete the data
- prevent owner from reading the data
- prevent recipient from reading the data
- prevent owner from modifying/deleting the data
- prevent recipient from modifying/deleting the data
| Threat actor | Affected data | Vulnerability | Priority (1-3; 3 high) |
|βββββ|βββββ|ββββββ|ββββββββ|
| other user | login (IP) | learn the value | 1 |