Not sure exactly how to think about Chrome app lifetimes, so we're
being conservative. We only show the full-application loading screen
once, on first display of the inbox.
FREEBIE
Model operations are vulnerable to exceptions thrown by event handlers.
Because this can interrupt really important data operations, it's better
to let the operation continue and log the error. In all likelihood it's
a view-related problem, and that shouldn't cause any data operation to
fail.
FREEBIE
Fix too-aggressive verification notifications on startup by starting a
conversation with the right initial verified state, and then making sure
to fetch() before setting a new verified state.
FREEBIE
On every click, even when sub-panes were open, we were calling
markRead(), which would save the conversation model with the new
unreadCount. The KeyVerificationPanelView was wired up to the change
event on conversation, so it would render with the results of that
update, then finally the user's intended update.
FREEBIE
This removes our support for the New Key/DEFAULT case, which iOS will
sync to us. Why? Because it ensures that in out of date scenarios, we
don't lose the higher-security state we were in previously.
FREEBIE
Tabbing right after entering the view would cause everythign to go crazy
as focus went back to the pane you were just on. This change both sets
the proper focus on load of that view (on the cancel button) and hides
other panes when they aren't active, only making them visible again when
they are once again the 'top' pane.
FREEBIE
New experience in the Message Detail view when outgoing identity key
errors happen, matching the Android View.
'View' button is only shown on outgoing key errors right now.
When a contact with an outgoing identity key error is clicked, they are
taken to a view like the popup that comes up on Android: an explanation
of what happened and three options: 'Show Safety Number', 'Send Anyway',
and 'Cancel'
Contacts are now sorted alphabetically, with the set of contacts with
errors coming before the rest.
FREEBIE
If the key has changed, saveIdentity will archive sibling sessions, but not the
session for the device it was called on. Therefore we have to archive that one
by hand.
Also switch from saving the identity of an OutgoingIdentityKeyError to just
triggering a profile fetch, mostly for consistency, simplicity, and DRYness.
// FREEBIE
This can happen with unknown groups, where we don't know the list of
members but we're receiving messages. It's generally not a good
experience, but we shouldn't crash.
FREEBIE
These were failing because ByteBuffers from the protobufs need to be converted
to ArrayBuffers. Fixed by useing the existing handler in MessageReceiver to
process verified messages from contact sync messages and dispatch them as their
own events, reducing some complexity on the application side.
// FREEBIE
In some cases, due to promise chaining and error propagation, we were
calling registerError more than once for a given error. This would then
cause the overall callback for the send operation to be called with a
partial set of errors, as well as duplicates.
Note: we do need to find a way to attach identityKey to the
OutgoingIdentityKeyError in the case where it comes directly from the
encrypt() instead of our pre-key operations.
FREEBIE
First construct a null message of random size and contents and send it to the
destination. Then include that same padding in the verification sync.
Note that the sync message is additionally randomly padded like all other sync
messages.
This lets Verified sync messages appear the same as normal sync message traffic.
// FREEBIE
Just log em for debugging. Also update the error messge thrown when we get a
content message with no supported properties. It may be empty or may just have
an unrecognized field.
// FREEBIE
Sessions established with the previous identity should no longer be used for
sending, so we should close them.
Since we've added this call to saveIdentity, we can omit the call to it after
profile fetches.
// FREEBIE
processVerifiedMessage checks the current state of the database against the
identity key from an incoming verification sync message to determine whether or
how to update our local record.
When syncing a DEFAULT status and we have no local record, it's a no-op, but
we'll log it.
When syncing a DEFAULT status and we have non-default record with the same key,
mark it as default.
When syncing a VERIFIED status and either:
1. we have no key on record,
2. we have have a different key on record, or
3. we have the same key on record, but not verified
mark it as verified.
Otherwise do nothing.
References: https://github.com/WhisperSystems/Signal-Android/blob/master/src/org/thoughtcrime/securesms/util/IdentityUtil.java#L129
// FREEBIE
Ensure processVerified resolves
The shield matches the Android app's key change notification, and the
clock icon was easy to do and makes it easier to visually distinguish
those items in the conversation history.
FREEBIE
This adds a new method to message sender for sending verification sync messages
and a new event to message receiver representing incoming verification sync
messages. Currently the event handler just logs the message.
// FREEBIE
We also show more errors than we used to in the MessageDetail screen
to help make it clear what is happening, and why the user would need to
re-send.
FREEBIE
It doesn't run today - it depends on RecipientsInputView, which depends
on Backbone.TypeaheadCollection which doesn't currently exist in the
product.
FREEBIE
Not yet using the new APIs, but ready to. Still to do:
- Send sync messages on trust decisions
- Respond to received trust decision sync messages
- Show trust decisions in the conversation history
- In that rare situation where a sent message ends up with a key error
make it easy to retry the send.
FREEBIE
Also:
- All the necessary wire-up to update things in real time. If you have
a safety number page up via a group member view as well as via a 1:1
conversation with that contact, they'll both be updated as the
underlying model changes. Similarly, the overall group will update
in real-time as members change.
- A bit of special-casing for yourself in a group conversation - you're
shown as 'me' and are not clickable, where normally that would take you
to the Safety Number screen for that contact. You are also not included
in the trust calculations for a given group.
FREEBIE
Reduce ambiguity in between the record itself, which now stores other
information besides the public key, and its `publicKey` attribute, which
contains an ArrayBuffer of key material.
This model is internal to SignalProtocolStore.
// FREEBIE
Previously we would only clear the publicKey since that was the only attribute,
but now we should delete the entire record. This method is currently only called
from tests.
// FREEBIE
saveIdentityWithAtttributes allows directly setting all properties of an
identity key record. In AccountManager we use it to save our own identity
key after a new registration.
Previously we would remove the existing key first in order to coerce firstUse to
true, but now we can simply set it explicitly, along with a VERIFIED status.
// FREEBIE
This will enforce that all identity record attributes are valid and present
before allowing the record to be saved. This is necessary since we will be
exposing a lower-level method to save an identity with explicit values for
firstUse, nonblockingApproval, and verified status.
Previously we only expected these errors to occur when decrypting prekey
messages, so we need to add handling for them in the case of a normal message.
// FREEBIE
Multiple cases here:
1. setting our own key on registration
1. changing identities from a safety number change dialog
Note that removeIdentityKey runs before saveIdentity, so we'll always end up
with firstUse: true on our own key.
// FREEBIE
saveIdentity is now reponsible for determining firstUse, so we must not remove
the existing key before updating it.
Previously, the implementation provided an extra check against overwritting an
existing key, but that should be done via isTrustedIdentity instead.
// FREEBIE
We can use the same padded plaintext across multiple numbers or attempts rather
than re-creating it every time we encrypt to a particular number.
// FREEBIE
Scott Nonnenberg
lilia
Ikarulus