Resolve "handle changed safety numbers"
Closes #100 (closed), Closes #70 (closed), Closes #86 (closed), Closes #87 (closed)
Value
- When a user re-installs signal on a new phone, they should be able to continue using signalboost.
- (Currently they cannot because their safety number changes, signal does not trust it by default, and signald will therefore not read or send messages to them)
- When an admin changes their safety number, we would like them to be blocked from sending by default so that other admins may ensure that they are not being subjected to an impersonation attack before restoring priveleges
Context
- The only possible way to observe that a user's safety number has changed is to try sending them a message and then observe that it has failed, in which case signald emits an error message with a known form.
- (Even if you poll for new safety numbers after you know a user has reinstalled signal, you will not see the new safety number until after signald has attempted to send that user a message and fails.)
Behavior
Self-healing scenario:
GIVEN a subscriber alice on a channel 'foo' who has just reinstalled Signal (thus triggering a safety number change)
- WHEN any admin sends a broadcast message to 'foo'
- THEN signalboost will notice that signald was unable to send the message to alice
- AND THEN signalboost will direct signald to trust alice's new safety number on 'foo'
- AND THEN signalboost will resend the message that originally failed to send to alice on channel 'foo'
- AND THEN all subsequent messages on 'foo' will be delivered to alice as if nothing happened
Admin re-adding other admin scenario (after failed message send):
GIVEN an admin bob with phone number +1-555-555-5555 on channel 'foo' who has just reinstalled Signal
- WHEN any other admin sends a broadcast message to 'foo'
- THEN signalboost will notice that signald was unable to send the message to bob
- AND THEN signalboost will remove bob as an admin on 'foo'
- AND THEN signalboost will send an alert to all other admins that bob has been removed and must be re-added
- WHEN another admin sends the command
ADD +1-555-555-5555
to 'foo'- THEN signalboost will restore bob's admin priveleges on 'foo'
- AND THEN signalboost will direct signald to trust bob's new safety number on 'foo'
- AND THEN signalboost will send a notification to all admins that bob has been made an admin (and by whom)
- AND THEN bob will now be able to send and receive messages as if nothing had happened
Admin re-adding other admin scenario (before failed message send):
GIVEN an admin bob on channel 'foo' who has just reinstalled Signal
- AND GIVEN that no other admin has yet sent a broadcast message on 'foo'
- WHEN another admin sends the command
ADD +1-555-555-5555
to 'foo'- THEN signalboost will restore bob's admin priveleges on 'foo'
- AND THEN signalboost will direct signald to trust bob's new safety number on 'foo'[1]
- AND THEN signalboost will send a notification to all admins that bob has been made an admin (and by whom)
- AND THEN bob will now be able to send and receive messages as if nothing had happened
Maintainer re-adding admin scenario:
GIVEN an admin bob on channel 'foo' who has just reinstalled Signal
- WHEN a maintainers sends the command
boost add -c <foo phone number> -a <bob phone number>
- THEN admin will be re-added and welcomed and other admins alerted as above
Implementation Details
add registrar.safetyNumber
service with #trust
and #deauthorize
-
#trustAndResend
:- consumes a message that a caller knows to have failed sending (b/c of changed safety number)
- calls
signal#trust
(and observes same error-handling/notifying rules) - resends the originally failed message if there were no errors
-
#deauthorize
:- strips a user of their admin privileges on a channel
- alerts the other admins that this has happened
for self-healing scenario:
- filter singald input for error messages flagging failed send attempts (due to changed safety numbers)
- on failed send, forward messages to
dispatcher.trustAndResend
for safety number updating and message resending
for deauthorization:
- filter singald input for error messages as for subscribers
- on failed send, notice that recipient was an admin, triggering removal
for admin re-adding scenarios:
- safety number retrusting for admins is achieved by sending the normal post-ADD welcome message
- sending fails which causes signald to notice the changed safety number (if it hasn't already)
- notice that failed message was a welcome message addressed to a new admin -- signaling that another admin intended to retrust the failed message recipient -- and trigger the same trust-and-resend-message routine used for subscribers in the "self-healing scenario"