signalboost issueshttps://0xacab.org/team-friendo/signalboost/-/issues2021-04-12T19:22:54Zhttps://0xacab.org/team-friendo/signalboost/-/issues/471replace channel/member phone number w/ uuid upon destruction event2021-04-12T19:22:54Zaguestuserreplace channel/member phone number w/ uuid upon destruction event# context
- currently, we track creation/deltion of members and channels to be able to track growth over time
- since we keep these records indefinitely, and since we want users to be able to remove their data from our system once they l...# context
- currently, we track creation/deltion of members and channels to be able to track growth over time
- since we keep these records indefinitely, and since we want users to be able to remove their data from our system once they leave, we use hashed/salted phone numbers so that when a channel or member is destroyed, it is impossible for an attacker who does not know the salt to recover the phone number (an attacker who *does* know the salt would have to brute force all possible phone number combinations to recover phone numbers from hashes, which is hard but possible)
- we would prefer it to be *impossible* for an attacker (or a signalboost maintainer) to be able to recover phone numbers of destroyed channels or memberships
- in this MR, we will generate a UUID and replace the (hashed) phone number with it upon channel / membership destruction
- this will preserve the property of allowing us to run stats on deleted channels (by uniquely identifying them)
- it will remove the property of it being possible for an attacker to recover deleted channel / member phone numbers by compromising our salt hash
- note: under this schema, a member who deletes their last membership and then rejoins will be double counted, but that seems preferable than keeping their phone number in a way that could be brute forced by an attacker who knows our hash salt!https://0xacab.org/team-friendo/signalboost/-/issues/469signalc: cronjob deletes stale attachment files every hour2021-04-09T18:35:56Zaguestusersignalc: cronjob deletes stale attachment files every hourhttps://0xacab.org/team-friendo/signalboost/-/issues/468support broadcast voice memos (?)2021-04-06T22:19:32Zaguestusersupport broadcast voice memos (?)# context
- unlike attachments, voice memos cannot be sent with captions
- that means admins cannot prefix voice memos with a `!`
- that means admins cannot send voice memos as broadcast messages (subscribers *can* send incoming voice me...# context
- unlike attachments, voice memos cannot be sent with captions
- that means admins cannot prefix voice memos with a `!`
- that means admins cannot send voice memos as broadcast messages (subscribers *can* send incoming voice memos as hotline messages, since these require no text)
- with some work, we could parse incoming messages that throw `NO_COMMAND` parse errors to see if they are voice memos, and -- if so -- treat them like broadcasts...
- should we?
# behavior
todo...https://0xacab.org/team-friendo/signalboost/-/issues/460new users accept invite with HELLO (no DECLINE option)2021-05-04T22:23:04Zaguestusernew users accept invite with HELLO (no DECLINE option)aguestuseraguestuserhttps://0xacab.org/team-friendo/signalboost/-/issues/432admins can TRANSFER subsribers to new channel number2021-02-13T00:11:34Zaguestuseradmins can TRANSFER subsribers to new channel number# context
* having same number on phone can be used to link admins/subscribers to each other
* it would be nice to prevent such network analysis by being able to move channels now and again
* (once federated: the principle of data portab...# context
* having same number on phone can be used to link admins/subscribers to each other
* it would be nice to prevent such network analysis by being able to move channels now and again
* (once federated: the principle of data portability dictates that users should be able to move to other instances!)
# behavior
(stub)
## happy path
GIVEN a user who is admin of both channel A and channel B
* WHEN an admin sends `TRANSFER <B>` to channel A
* THEN they will receive a "are you sure?" message?
* WHEN they issue `CONFIRM TRANSFER <B>`
* THEN all subscribers will be moved to channel B
* AND THEN all subscribers will receive a welcome message on channel B
* AND THEN all admins will receive a notice on the old and new channels of the move
## sad paths
* WHEN an admin sends `TRANSFER garbage` they will get a sensible error message
* WHEN an admin sends `TRANSFER <some number they don't control>` they will get an error messagehttps://0xacab.org/team-friendo/signalboost/-/issues/430ban repeat violators of channel creation rate limit2021-02-13T00:00:47Zaguestuserban repeat violators of channel creation rate limitSTUBSTUBhttps://0xacab.org/team-friendo/signalboost/-/issues/429rate limit channel creation2021-02-12T23:59:57Zaguestuserrate limit channel creation# context
* we can now automatically create channels
* we don't want attackers to abuse this and starve us of resources
# behavior
STUB
* when a phone number tries to create more than 3 channels in 1 week (?)
* then that phone number...# context
* we can now automatically create channels
* we don't want attackers to abuse this and starve us of resources
# behavior
STUB
* when a phone number tries to create more than 3 channels in 1 week (?)
* then that phone number will be blocked from creating any more channels for a week
# open questions:
* should there be a global rate limit (to throttle all channel creation for a week once a certain threshhold has been passed? this would prevent attackers from switching phone numbers to continue abusing. it would also inconvenience users!)
* what should the exact "bucket leak" rate be?
* there are lots of ways to implement rate limits... what way do we want to pick?https://0xacab.org/team-friendo/signalboost/-/issues/422load: measure signalc max capacity2021-05-18T14:16:30Zaguestuserload: measure signalc max capacitystub
at a high level, we want to know what combination of values along the following 3 axes will cause signalc to either crash or begin to experience unacceptably high message lag for over 10% of messages:
- channels
- subscribers
- bro...stub
at a high level, we want to know what combination of values along the following 3 axes will cause signalc to either crash or begin to experience unacceptably high message lag for over 10% of messages:
- channels
- subscribers
- broadcast messages / secsignalc mvphttps://0xacab.org/team-friendo/signalboost/-/issues/418signalc: integration tests against fake signal server2021-04-21T22:54:01Zaguestusersignalc: integration tests against fake signal server(stub)
features that could benefit from integration tests:
- attachments! (see !564 / #466)
- rate limits (see !566 / #402)
- handling changed safety number (see !568 / #400 )(stub)
features that could benefit from integration tests:
- attachments! (see !564 / #466)
- rate limits (see !566 / #402)
- handling changed safety number (see !568 / #400 )signalc mvphttps://0xacab.org/team-friendo/signalboost/-/issues/361make all invite notifications ephemeral (?)2020-10-06T19:41:44Zaguestusermake all invite notifications ephemeral (?)STUB
# value
* to make invitations less confusing, we want to share the full phone number of invitees to their inviters in both command responses and acceptance notifications
* however, we introduce some (very small!) chance of increase...STUB
# value
* to make invitations less confusing, we want to share the full phone number of invitees to their inviters in both command responses and acceptance notifications
* however, we introduce some (very small!) chance of increased likelihood of leaking invitee phone numbers this way [[1](#footnote-1)]
* to avoid this, consider making all invite notifications disappear after some interval (say 30 minutes?) by (1) setting the disappearing message timer to that interval, (2) sending the notification, (3) setting the disappearing message timer back to whatever it was before
<a name="footnote-1"></a>
[1] only scenario in which this happens:
1. disappearing messages are on when alice invites lola
2. disappearing messages are turned off
3. lola accepts
result: the phone number contained in the invite message itself disappears, while the acceptance notification does not. (note: in all other scenarios, sending the full number in the acceptance notification does not decrease chances of leak, because the number was already contained in the invite message itself, which therefore dominates the consideration of likelihood of data leak.)
# behavior
TK-TODO
# implementation
* use `signal.setExpiry` to change timer
* consult `channel.messageExpirtyTime` to set it back to original valuehttps://0xacab.org/team-friendo/signalboost/-/issues/360TECH TASK: eliminate `sdMessage` from "incoming" call stack2020-10-01T20:56:23ZaguestuserTECH TASK: eliminate `sdMessage` from "incoming" call stackSTUB
# context
* right now we parse an outgoing `sdMessage` as the first step of `dispatcher.relay`
* this is outdated. we used to do this because we assumed that in mose cases we'd just pass this along through the broadcast happy path ...STUB
# context
* right now we parse an outgoing `sdMessage` as the first step of `dispatcher.relay`
* this is outdated. we used to do this because we assumed that in mose cases we'd just pass this along through the broadcast happy path and insert some recipietns into it.however, now we construct our own `sdMessages` for every conceivable outgoing message (including broadcast messages)
* so having this lying around is unnecesary. but it is also confusing (it necessitates us treating what is essentially incoming information as outgoing-formatted stuff... and notably: constructing a `sender: channelPhoneNumber` k/v pair at a part of the stack where the sender is still most logically still a person and the channel is still the recipient. (the channel will become the sender only after the execute layer)
# proposed change
* to mirror what is true, we should just eliminate `sdMessage`s altogether until we construct them in execute
* instead of parsing outbound sdmessages in `dispatcher.relay`, we should simply extract the message body and attachments array
* it is unclear whether we should go ahead and transform inbound attachments to outbound attachments at this step, or defer doing that until constructing `sdMessage`s in teh `execute` layer. the most likely thing to sway that decision is how it effects the logic of parsing attachments from signald rate limit errors for resending. (in which the outbound/inbound distinction is already a bit troubled). figuring that out will be the main substance of playing this card.https://0xacab.org/team-friendo/signalboost/-/issues/359TECH TASK: refactor `messenger`2020-10-01T20:50:29ZaguestuserTECH TASK: refactor `messenger`STUB
after changes to `execute`, we can catch up here. some ideas:
* rename to `router`
* completely consume the `dispatchable` in the `execute` layer and only handle a `commandResponse` at this layer
* handle all messages in one flow i...STUB
after changes to `execute`, we can catch up here. some ideas:
* rename to `router`
* completely consume the `dispatchable` in the `execute` layer and only handle a `commandResponse` at this layer
* handle all messages in one flow instead of `handleBroadcast` and `handleCommandResponse`. will mean:
* making the current `handleCommandResponse` the main workhorse of the module and handling all messages in it
* dispatching on whether or not to respond as the main branching logic in taht function
* sending all "relayable message" notifications in sequence
* figuring out what we want to do about expiry times for all caseshttps://0xacab.org/team-friendo/signalboost/-/issues/188zero downtime deploys2020-01-11T03:28:27Zaguestuserzero downtime deployshttps://0xacab.org/team-friendo/signalboost/-/issues/187use 0xacab container registry for docker images2020-01-11T03:25:51Zaguestuseruse 0xacab container registry for docker imageshttps://0xacab.org/team-friendo/signalboost/-/issues/184all-admins channel (for new features and support)2020-02-23T20:03:28Zaguestuserall-admins channel (for new features and support)VALUE
* I think it would be nice to have a channel that all admins are automatically subscribed to
* We could use this to announce new features (and save the repetition of doing so separately in lots of individual signal threads with sup...VALUE
* I think it would be nice to have a channel that all admins are automatically subscribed to
* We could use this to announce new features (and save the repetition of doing so separately in lots of individual signal threads with superusers as i currently do)
BEHAVIOR
* stub
CONTEXT
this will be useful necessary when:
* we have a handful of users that we don't have direct communication lines with
* we have a critical mass of features that will significantly change the experience of using signalboost
Next new features will likely be:
* BAN/REMOVE re: #195 #179 #113
* LOCKED channels #68
* sidechats #96 https://0xacab.org/team-friendo/signalboost/-/issues/176TOOLING: team gopass2020-11-16T19:12:08ZaguestuserTOOLING: team gopasshttps://0xacab.org/team-friendo/signalboost/-/issues/175automatically recycle stale channels2020-04-05T19:02:38Zaguestuserautomatically recycle stale channels# Value
* it's important to recycle unused channels to free up unused resources but also important to do this in a transparent / non-subjective way that is clear to users
* it would also be nice if maintainers didn't have to spend time ...# Value
* it's important to recycle unused channels to free up unused resources but also important to do this in a transparent / non-subjective way that is clear to users
* it would also be nice if maintainers didn't have to spend time doing this manually and instead work on improving the service!
* so... let's automate channel recycling according to a set of published rules! :)
# Behavior
WHEN a channel has not been used in over 3 months
* THEN channel admins will receive a notice that their channel will be recycled if they do not respond within the next 24 hours (and the channel will be enqueued for recycling) as described in #215 https://0xacab.org/team-friendo/signalboost/-/issues/174boost as ssh-only tool2023-03-15T19:46:33Zaguestuserboost as ssh-only toolSTUB
* we get lots of hackery/spammy traffic in our nginx from random IPs probing us for vulns
* but the only reason we even have ports 80 & 443 open is for (1) twilio webhooks and (2) our `boost` tool
* what if we modified the `boost` ...STUB
* we get lots of hackery/spammy traffic in our nginx from random IPs probing us for vulns
* but the only reason we even have ports 80 & 443 open is for (1) twilio webhooks and (2) our `boost` tool
* what if we modified the `boost` tool to ssh onto the box (and make its http calls to localhost) and then only accepted http traffic from twilio.com? (easy way to close lots of vulns!)https://0xacab.org/team-friendo/signalboost/-/issues/173pin registration lock?2020-03-28T15:43:37Zaguestuserpin registration lock?