briar issueshttps://code.briarproject.org/groups/briar/-/issues2023-03-15T13:04:32Zhttps://code.briarproject.org/briar/briar/-/issues/2Allow existing contacts to be re-added2023-03-15T13:04:32ZakwizgranAllow existing contacts to be re-addedRe-adding an existing contact currently throws a ContactExistsException. But re-adding a contact may be necessary if transport properties get out of sync, making it impossible to connect via BTP. If we re-add a contact we should keep any...Re-adding an existing contact currently throws a ContactExistsException. But re-adding a contact may be necessary if transport properties get out of sync, making it impossible to connect via BTP. If we re-add a contact we should keep any existing private messages and group subscriptions.
If one contact uses the same identity as last time and the other doesn't, they'll disagree about whether it's a re-add, so we can't re-derive the same transport keys. Can we reuse the contact ID (if any), import the new transport properties, delete the old transport keys (if any), and create new transport keys?https://code.briarproject.org/briar/briar/-/issues/9Support copy and paste2022-10-27T21:53:59ZakwizgranSupport copy and pastehttps://code.briarproject.org/briar/briar/-/issues/22Build external dependencies from source2020-11-21T20:31:32ZakwizgranBuild external dependencies from sourceCreate a build script for building the external dependencies from source. Code should be cloned from git rather than bundled - create a repo on code.briarproject.org if no suitable upstream repo is available.
For Java libraries, ensure ...Create a build script for building the external dependencies from source. Code should be cloned from git rather than bundled - create a repo on code.briarproject.org if no suitable upstream repo is available.
For Java libraries, ensure the target version is set to 6 for Android compatibility.https://code.briarproject.org/briar/briar/-/issues/62Reduce information leaked by polling2022-01-26T13:47:24ZakwizgranReduce information leaked by pollingPolling for connections to contacts may reveal the number of contacts and their identities to a local observer. For example, anyone monitoring Bluetooth traffic near a Briar device will see periodic bursts of connection attempts from the...Polling for connections to contacts may reveal the number of contacts and their identities to a local observer. For example, anyone monitoring Bluetooth traffic near a Briar device will see periodic bursts of connection attempts from the device's MAC address to certain other MAC addresses. The observer will learn how many contacts the device has, and if the observer knows who owns any of the other MAC addresses then contact relationships will be revealed.
There are several techniques we can use to reduce information leaks.
1) Poll at random intervals
Instead of polling all contacts at regular intervals, poll each contact at exponentially distributed intervals.
This should reduce the information about contacts leaked to a local observer. The shorter the observation period, the less likely it is that connection attempts to all contacts will be observed.
2) Don't poll unreachable contacts
Plugins should store contextual information to help them decide which contacts may be reachable, and contacts who are unreachable should not be polled. Contacts who are rarely reachable via a given transport may be polled less frequently.
3) Don't poll at all
Polling probably contributes to Briar's battery and bandwidth consumption, and for short-range transports it may not be the most efficient way of connecting to nearby contacts. The user knows when contacts are nearby, and may be able to connect to them more quickly by triggering a scan manually than by waiting for the next poll.
To reduce the amount of information leaked by a manual or automatic scan, the scan should detect nearby contacts and then try to connect to any that are nearby, as opposed to the current approach of trying to connect to all contacts. The rationale for the current approach is that we can't make an Android device permanently discoverable via Bluetooth, and making the device temporarily discoverable requires confirmation from the user each time. But if the scan is triggered manually, user confirmation may be acceptable. It may be possible to make a device permanently discoverable via Bluetooth LE or Wi-Fi Direct, in which case we could scan multiple transports with a single manual trigger.https://code.briarproject.org/briar/briar/-/issues/319Distinguish between transient, recoverable and permanent DB exceptions2020-11-21T19:08:20ZakwizgranDistinguish between transient, recoverable and permanent DB exceptionsThis would be useful for message delivery hooks and any other operation that should be retried if the failure is temporary, or cancelled if it's permanent.This would be useful for message delivery hooks and any other operation that should be retried if the failure is temporary, or cancelled if it's permanent.https://code.briarproject.org/briar/briar/-/issues/473Private messages: Notification for new message while message screen was open2020-11-21T18:43:10ZMegaloxPrivate messages: Notification for new message while message screen was openA tester noticed that he got a notification about a new message while the screen where this message appeared was open. He tapped the open message and the message screen reloaded.A tester noticed that he got a notification about a new message while the screen where this message appeared was open. He tapped the open message and the message screen reloaded.https://code.briarproject.org/briar/briar/-/issues/479High background data traffic2020-11-21T18:42:17ZMegaloxHigh background data trafficA tester complained that he had briar running over the weekend without communicating (briar mostly in the background) and had a data traffic of 20 MB (17 background, 3 foreground).A tester complained that he had briar running over the weekend without communicating (briar mostly in the background) and had a data traffic of 20 MB (17 background, 3 foreground).https://code.briarproject.org/briar/briar/-/issues/540Sync messages in dependency order2020-11-21T17:43:08ZakwizgranSync messages in dependency orderMessages should be synced in dependency order (i.e. dependencies before their dependents) so they can be delivered to the client as soon as possible.
This can be done by recording the dependency depth of each message in the DB. A messag...Messages should be synced in dependency order (i.e. dependencies before their dependents) so they can be delivered to the client as soon as possible.
This can be done by recording the dependency depth of each message in the DB. A message with no dependencies has a depth of 0. A message with dependencies has a depth one greater than the greatest depth of its dependencies.https://code.briarproject.org/briar/briar/-/issues/550Move timestamps from sync layer to client layer2020-11-21T17:40:50ZakwizgranMove timestamps from sync layer to client layerClients have different requirements for representing time: some don't need timestamps at all, some can use simple timestamps like we currently provide, and in future others may need more complex representations of time, incorporating tim...Clients have different requirements for representing time: some don't need timestamps at all, some can use simple timestamps like we currently provide, and in future others may need more complex representations of time, incorporating timezones, for example. Timestamps should be moved up to the client layer so each client can represent time in its own way.https://code.briarproject.org/briar/briar/-/issues/689Line breaks entered in blog posts aren't displayed2022-11-23T14:44:51ZakwizgranLine breaks entered in blog posts aren't displayedWhen writing a blog post, I can use the enter key to create line breaks that are shown in the composition window. But they aren't shown when the blog post appears in the feed (presumably because it's rendered as HTML).When writing a blog post, I can use the enter key to create line breaks that are shown in the composition window. But they aren't shown when the blog post appears in the feed (presumably because it's rendered as HTML).https://code.briarproject.org/briar/briar/-/issues/716Warn when entered text is too long2020-11-21T16:38:26ZakwizgranWarn when entered text is too longWe do this for forum posts, we should also do it for:
* Private messages
* Introduction messages
* Invitation messages
* Blog posts
* Blog commentsWe do this for forum posts, we should also do it for:
* Private messages
* Introduction messages
* Invitation messages
* Blog posts
* Blog commentshttps://code.briarproject.org/briar/briar/-/issues/725Result handlers may not return results if the screen is rotated2020-11-21T16:36:20ZakwizgranResult handlers may not return results if the screen is rotatedThis issue came to mind while reviewing !354 - `SetupActivity#onClick()` uses the onResultUi() method of a UiResultHandler to start the next activity. If the screen's rotated before the handler returns, the original activity will be dest...This issue came to mind while reviewing !354 - `SetupActivity#onClick()` uses the onResultUi() method of a UiResultHandler to start the next activity. If the screen's rotated before the handler returns, the original activity will be destroyed, so the handler will never call onResultUi(). The outcome, as far as I can see, will be a progress wheel that spins forever.
Similar problems may exist elsewhere. Most of the time we use ResultHandlers to update the state of the current activity or fragment, and we reload everything if the activity or fragment's recreated, so it doesn't matter if results are lost during rotation. But there may be some places like this one where we depend on the result being returned.https://code.briarproject.org/briar/briar/-/issues/753Listener interfaces have mixed responsibilities2021-01-20T12:34:20ZakwizgranListener interfaces have mixed responsibilitiesThe UI makes heavy use of listener interfaces that inherit from either DestroyableContext or BaseFragmentListener. These are used for various purposes:
* Callbacks from a controller to the UI (e.g. `TransportStateListener#stateUpdate()`...The UI makes heavy use of listener interfaces that inherit from either DestroyableContext or BaseFragmentListener. These are used for various purposes:
* Callbacks from a controller to the UI (e.g. `TransportStateListener#stateUpdate()`)
* Injecting dependencies into fragments (`BaseFragmentListener#getActivityComponent()`)
* Manipulating other parts of the UI (e.g. `CreateGroupListener#showSoftKeyboard()`)
* Running tasks (`DestroyableContext#runOnUiThreadUnlessDestroyed()`, `BaseFragmentListener#runOnDbThread()` (deprecated))
These different purposes would ideally be separated into different interfaces. Maybe it would clarify things if communication from controllers back to the UI used the "listener" name and communication between fragments and their activities used some other name.
Listeners are usually provided by casting an Activity or Context (passed to `ActivityLifecycleController#onActivityCreate()` or `Fragment#onAttach()`) to an arbitrary listener interface. This is a bit of a hack - it would be nice if we could provide listeners in a type-safe way, for example by injection.
Related to #752.https://code.briarproject.org/briar/briar/-/issues/775The LanTcpPlugin tries to create a KeyAgreementListener even if Wifi/mobile d...2020-11-21T16:20:28ZJulian DehmThe LanTcpPlugin tries to create a KeyAgreementListener even if Wifi/mobile data is disabledWhen adding a contact with only bluetooth enabled the LanTcpPlugin tries to bind a serversocket, which seems like a useless effort to me.
`org.briarproject I/LanTcpPlugin: Could not bind server socket for key agreement`
Maybe there sh...When adding a contact with only bluetooth enabled the LanTcpPlugin tries to bind a serversocket, which seems like a useless effort to me.
`org.briarproject I/LanTcpPlugin: Could not bind server socket for key agreement`
Maybe there should be a check if Wifi is enabled before attempting to open a socket.https://code.briarproject.org/briar/briar/-/issues/780Temporarily leaked Activities on orientation changes2021-04-26T14:01:29ZErnir ErlingssonTemporarily leaked Activities on orientation changesWhile working on #725, I noticed something: we're leaking Activities temporarily.
We are using anonymous inner classes as callbacks for asynchronous tasks, during their execution it's possible that an orientation change occurs that des...While working on #725, I noticed something: we're leaking Activities temporarily.
We are using anonymous inner classes as callbacks for asynchronous tasks, during their execution it's possible that an orientation change occurs that destroys the old Activity/Fragment. The task stores a reference to the callback, and therefore implicitly to the Activity. This means that the initial Activity will be kept alive until the task finishes execution. Multiple orientation changes will might result in multiple Activities being temporarily leaked, although !415 relieves some of that by ensuring there is only one leaked Activity maximum.
Not sure what the best course of action here is, we could try to handle the orientation changes ourselves which re-uses the initial Activity but will require careful programming.
https://developer.android.com/guide/topics/resources/runtime-changes.html#HandlingTheChangehttps://code.briarproject.org/briar/briar/-/issues/827Transition from private conversation back to contact list affects wrong item2020-11-21T12:39:38ZakwizgranTransition from private conversation back to contact list affects wrong itemI ran into a couple of problems while testing the transition between the contact list and the private conversation. Reproducing them requires API 23 as the transition is disabled on older versions.
The first problem occurs when the cont...I ran into a couple of problems while testing the transition between the contact list and the private conversation. Reproducing them requires API 23 as the transition is disabled on older versions.
The first problem occurs when the contact moves to a new position in the list while the private conversation is open. This can happen if you select any contact except the one at the top of the list, send a message, and return to the contact list. The contact will now be at the top of the list. The problem is that the reverse transition moves the avatar from the toolbar to the contact's old position in the list, which is now occupied by a different contact.
The second problem occurs when you remove the contact, which automatically returns you to the contact list. The transition moves the avatar from the toolbar to the contact's old position in the list, which may now be occupied by a different contact or may be empty.https://code.briarproject.org/briar/briar/-/issues/834Optionally sign out when battery is low or power saving mode is enabled2021-10-27T14:09:40ZakwizgranOptionally sign out when battery is low or power saving mode is enabledListen for power manager events (ACTION_BATTERY_LOW, ACTION_POWER_SAVE_MODE_CHANGED) and [manufacturer-specific events](http://stackoverflow.com/a/25103642) and optionally sign out if the battery is low or power saving mode is enabled an...Listen for power manager events (ACTION_BATTERY_LOW, ACTION_POWER_SAVE_MODE_CHANGED) and [manufacturer-specific events](http://stackoverflow.com/a/25103642) and optionally sign out if the battery is low or power saving mode is enabled and the user's not currently interacting with Briar.https://code.briarproject.org/briar/briar/-/issues/862Blogs: Scrolling with low performance2020-11-19T16:07:38ZMegaloxBlogs: Scrolling with low performanceOne tester scrolled the blog up and down and it wasn't really smooth. @ernir suspected the emojis to be responsible for this.One tester scrolled the blog up and down and it wasn't really smooth. @ernir suspected the emojis to be responsible for this.https://code.briarproject.org/briar/briar/-/issues/873Blogs: Reloading when changing orientation2020-11-19T15:55:20ZMegaloxBlogs: Reloading when changing orientationThe blog seems to reload (blank screen and spinner) when the user changes from portarait to landscape mode. Is this intentional?The blog seems to reload (blank screen and spinner) when the user changes from portarait to landscape mode. Is this intentional?https://code.briarproject.org/briar/briar/-/issues/901Improve key binding in contact exchange protocol2020-11-19T15:35:33ZakwizgranImprove key binding in contact exchange protocolThe contact exchange protocol provides the following guarantees:
* Each party knows that the ephemeral and identity public keys she received are owned by the other party
* Each party knows that the ephemeral and identity public keys she ...The contact exchange protocol provides the following guarantees:
* Each party knows that the ephemeral and identity public keys she received are owned by the other party
* Each party knows that the ephemeral and identity public keys she received were used by the other party in the same run of the protocol - in other words it binds each party's ephemeral key pair to the same party's identity key pair and vice versa
* Each party knows that the ephemeral public key she received was used by the other party in the current run of the protocol - in other words it binds the parties' ephemeral key pairs to each other
To achieve this, each party uses her identity key pair to sign a nonce derived from the ephemeral shared secret, and authenticates the signed nonce using a symmetric key derived from the ephemeral shared secret.
Each party knows that the nonce she received is fresh, as it depends on her own ephemeral key pair, so the nonce itself proves that the other party owns the ephemeral public key received by the first party, while the signature proves that the other party owns the identity public key received by the first party.
The nonce is unique to this combination of ephemeral key pairs, so the signature represents a claim by the owner of the received identity public key that she took part in a protocol run involving both ephemeral key pairs. Authenticating the signed nonce with a symmetric key derived from the ephemeral shared secret represents a claim by the owner of the received ephemeral public keys that she took part in a protocol run involving both ephemeral key pairs and the identity key pair.
As far as I can tell, this construction is secure and achieves what we need, but it's unnecessarily convoluted. The binding and proof of ownership that's achieved by signing nonces could be achieved more straightforwardly by signing public keys:
* Each party signs both parties' ephemeral public keys and timestamps using her identity key pair
* Each party authenticates both parties' identity public keys, ephemeral public keys and timestamps, using a symmetric key derived from the ephemeral shared secret
If we're not concerned with deniability, each party can sign both parties' identity public keys, ephemeral public keys and timestamps. But as far as I can see, we get all the assurance we need without doing this.
Related to #902.