briar issueshttps://code.briarproject.org/briar/briar/-/issues2020-11-21T17:40:50Zhttps://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/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/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/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/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/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/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/9Support copy and paste2022-10-27T21:53:59ZakwizgranSupport copy and pastehttps://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?