# I am the Watcher. I am your guide through this vast new twtiverse.
# 
# Usage:
#     https://watcher.sour.is/api/plain/users              View list of users and latest twt date.
#     https://watcher.sour.is/api/plain/twt                View all twts.
#     https://watcher.sour.is/api/plain/mentions?uri=:uri  View all mentions for uri.
#     https://watcher.sour.is/api/plain/conv/:hash         View all twts for a conversation subject.
# 
# Options:
#     uri     Filter to show a specific users twts.
#     offset  Start index for quey.
#     limit   Count of items to return (going back in time).
# 
# twt range = 1 39
# self = https://watcher.sour.is/conv/f4tp54q
Salty.im Blob Storage - HedgeDoc -- Sanity check a design proposal I'm working with @xuu on? πŸ™ Basic idea is to have a secure blob store that clients can store arbitrary files/objects to, like ratchet state that is private to the client, as well as a place to upload arbitrary files to for sharing with other users in chat.
Salty.im Blob Storage - HedgeDoc -- Sanity check a design proposal I'm working with @xuu on? πŸ™ Basic idea is to have a secure blob store that clients can store arbitrary files/objects to, like ratchet state that is private to the client, as well as a place to upload arbitrary files to for sharing with other users in chat.
Salty.im Blob Storage - HedgeDoc -- Sanity check a design proposal I'm working with @xuu on? πŸ™ Basic idea is to have a secure blob store that clients can store arbitrary files/objects to, like ratchet state that is private to the client, as well as a place to upload arbitrary files to for sharing with other users in chat.
Salty.im Blob Storage - HedgeDoc -- Sanity check a design proposal I'm working with @xuu on? πŸ™ Basic idea is to have a secure blob store that clients can store arbitrary files/objects to, like ratchet state that is private to the client, as well as a place to upload arbitrary files to for sharing with other users in chat.
I _may_ have to expand upon how "files" are shared with other users -- too early in the morning to think β˜•οΈx2
I _may_ have to expand upon how "files" are shared with other users -- too early in the morning to think β˜•οΈx2
I _may_ have to expand upon how "files" are shared with other users -- too early in the morning to think β˜•οΈx2
I _may_ have to expand upon how "files" are shared with other users -- too early in the morning to think β˜•οΈx2
@prologic the proposal does not include a threat model nor a discussion of how the proposed encryption protects against threats. What exactly is the purpose of encrypting the contents other than the fact that other software encrypts stuff? Why is a new blob request signed?

There is a statement
> This implies that it is not possile for other clients and users to access another’s blob store as all requests are signed by the client’s private key, verified and used to construct the path(s) on disk.

Does it? Has that property been verified?
(that's my 2 cents, if it helps at all)
@abucci Okay. Thanks! I'm not good at writing this sort of thing, so maybe you could me through some basics?
@abucci Okay. Thanks! I'm not good at writing this sort of thing, so maybe you could me through some basics?
@abucci Okay. Thanks! I'm not good at writing this sort of thing, so maybe you could me through some basics?
@abucci Okay. Thanks! I'm not good at writing this sort of thing, so maybe you could me through some basics?
@prologic 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

# Afftected Data
- login id
- login (IP) address
- login session times and durations
- chat session times, durations, participants
- contents of chats

# Vulnerability
- 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 Model
| Threat actor | Affected data | Vulnerability | Priority (1-3; 3 high) |
|--------------|---------------|-----------------|------------------------|
| other user | login (IP) | learn the value | 1 |
I know it seems tedious, but you really need to go through this exercise carefully and thoroughly if you care about security. You can't just encrypt some stuff and hope for the best--that's hacky, and will not really help with security. There could be gaping security holes you overlooked because you didn't think it through even with encryption.

The good news is that once you're done, it's a great resource to always go back to. The priority column help you prioritize where to put development effort and what to do. It also helps you write documentation where you can tell users, with some confidence, what they can expect to stay safe and what they cannot expect to stay safe when they use salty.
I know it seems tedious, but you really need to go through this exercise carefully and thoroughly if you care about security. You can't just encrypt some stuff and hope for the best--that's hacky, and will not really help with security. There could be gaping security holes you overlooked because you didn't think it through.

The good news is that once you're done, it's a great resource to always go back to. The priority columns help you priority where to put development effort and what to do. It also helps you write documentation where you can tell users, with some confidence, what they can expect to stay safe and what they cannot expect to stay safe when they use salty.
I know it seems tedious, but you really need to go through this exercise carefully and thoroughly if you care about security. You can't just encrypt some stuff and hope for the best--that's hacky, and will not really help with security. There could be gaping security holes you overlooked because you didn't think it through even with encryption.

The good news is that once you're done, it's a great resource to always go back to. The priority columns help you priority where to put development effort and what to do. It also helps you write documentation where you can tell users, with some confidence, what they can expect to stay safe and what they cannot expect to stay safe when they use salty.
@abucci Thank youπŸ™‡β€β™‚οΈ
@abucci Thank youπŸ™‡β€β™‚οΈ
@abucci Thank youπŸ™‡β€β™‚οΈ
@abucci Thank youπŸ™‡β€β™‚οΈ
@abucci Great introduction to threat models! I'd love to have seen that when we were about to create one ourselves at work. :-)
@abucci I have a question about this process... How far do I go? Am I going overboard? πŸ€” I've identified 4 pieces of affected data, along with your already listed 7 actors and 5 different vulnerabilities. If this ends up (_which it's looking like it so far_) a matrix, that'll end up with hundreds of rows 😳 How do you _actually_ go about doing this without going insane? 🀣
@abucci I have a question about this process... How far do I go? Am I going overboard? πŸ€” I've identified 4 pieces of affected data, along with your already listed 7 actors and 5 different vulnerabilities. If this ends up (_which it's looking like it so far_) a matrix, that'll end up with hundreds of rows 😳 How do you _actually_ go about doing this without going insane? 🀣
@abucci I have a question about this process... How far do I go? Am I going overboard? πŸ€” I've identified 4 pieces of affected data, along with your already listed 7 actors and 5 different vulnerabilities. If this ends up (_which it's looking like it so far_) a matrix, that'll end up with hundreds of rows 😳 How do you _actually_ go about doing this without going insane? 🀣
@abucci I have a question about this process... How far do I go? Am I going overboard? πŸ€” I've identified 4 pieces of affected data, along with your already listed 7 actors and 5 different vulnerabilities. If this ends up (_which it's looking like it so far_) a matrix, that'll end up with hundreds of rows 😳 How do you _actually_ go about doing this without going insane? 🀣
@prologic
1. Crowdsource it. Everyone who uses salty or might use salty who'd be willing to help can participate
2. Reduce the lists. For example, It's almost surely unrealistic to expect salty to be secure against state actors. But also that's a design choice. It seems to me that, realistically, you're unlikely to do what would be necessary to make salty secure against state actors, so why even try?
3. Not all pieces of affected data can be affected by all the actors. Also, some of the combinations tend to be trivial. Finally, you can sometimes group threat actors together ("we don't want anyone except the recipient of a message to be able to read the message" instead of 7 distinct lines, one for each threat actor) possibly group affected data together sometimes. It's not usually an all vs. all matrix
4. Focus on the high priority items first when constructing the matrix. Again that's partly a design choice.
5. If you're clever, you can semi-automate the process of converting the matrix into code! (that's why I mentioned the casbin library--you can usually convert a threat model like this into casbin authorization policy files.

But, yeah, a thorough threat model will probably have *a lot* of rows--that's kind of what it means to be *serious* about security instead of bolting it on. The matrix size is a feature. You only have to do it once, and then revise it through time, and you can probably reuse some of that work on other projects that have a security aspect.
@prologic
1. Crowdsource it. Everyone who uses salty or might use salty who'd be willing to help can participate
2. Reduce the lists. For example, It's almost surely unrealistic to expect salty to be secure against state actors. But also that's a design choice. It seems to me that, realistically, you're unlikely to do what would be necessary to make salty secure against state actors, so why even try?
3. Not all pieces of affected data can be affected by all the actors. Also, some of the combinations tend to be trivial. Finally, you can sometimes group threat actors together ("we don't want anyone except the recipient of a message to be able to read the message" instead of 7 distinct lines, one for each threat actor) and possibly group affected data together sometimes too. It's not usually an all vs. all matrix
4. Focus on the high priority items first when constructing the matrix. Again that's partly a design choice
5. If you're clever, you can semi-automate the process of converting the matrix into code! (that's why I mentioned the casbin library--you can usually convert a threat model like this into casbin authorization policy files.

But, yeah, a thorough threat model will probably have *a lot* of rows--that's kind of what it means to be *serious* about security instead of bolting it on. The matrix size is a feature. You only have to do it once, and then revise it through time, and you can probably reuse some of that work on other projects that have a security aspect.
@abucci Thanks! πŸ‘Œ
@abucci Thanks! πŸ‘Œ
@abucci Thanks! πŸ‘Œ
@abucci Thanks! πŸ‘Œ
@prologic I'm happy to help fill out any of these lists and the threat model matrix if you want. Nice thing about it is you can create a spreadsheet and invite whoever you want to fill it out and stop when you feel it's been filled in enough. People can work on it asynchronously when they have the time.
@abucci Hmmm some kind of online table editor is probably a good idea here, I tried to find one that wasn't some blasted Google or Office365 pile of privacy eroding garbage, but haven't found one πŸ˜…
@abucci Hmmm some kind of online table editor is probably a good idea here, I tried to find one that wasn't some blasted Google or Office365 pile of privacy eroding garbage, but haven't found one πŸ˜…
@abucci Hmmm some kind of online table editor is probably a good idea here, I tried to find one that wasn't some blasted Google or Office365 pile of privacy eroding garbage, but haven't found one πŸ˜…
@abucci Hmmm some kind of online table editor is probably a good idea here, I tried to find one that wasn't some blasted Google or Office365 pile of privacy eroding garbage, but haven't found one πŸ˜…
@prologic
- EtherCalc
- CryptPad
- SeaTable

Check out this site of ethical alternatives for more possibilities.