briar issueshttps://code.briarproject.org/groups/briar/-/issues2021-01-21T13:24:56Zhttps://code.briarproject.org/briar/briar/-/issues/1259User testing for headless desktop/server app2021-01-21T13:24:56ZakwizgranUser testing for headless desktop/server appSubtask of #1254.Subtask of #1254.Headless MVPhttps://code.briarproject.org/briar/briar/-/issues/1266Use OONI data to identify locations where Tor bridges should be used2020-11-18T21:47:03ZakwizgranUse OONI data to identify locations where Tor bridges should be usedThis should be done in a scriptable way so the list can be updated regularly.
Subtask of #647.This should be done in a scriptable way so the list can be updated regularly.
Subtask of #647.https://code.briarproject.org/briar/briar/-/issues/1278Use split APKs to make app available for Android Go2020-11-18T02:38:55ZakwizgranUse split APKs to make app available for Android GoApparently the Play Store doesn't offer APKs larger than 10 MB to Android Go devices. We should provide architecture-specific (ARM and x86) APKs to keep the size below 10 MB.
Idea stolen from Orbot. :-)
https://developer.android.com/st...Apparently the Play Store doesn't offer APKs larger than 10 MB to Android Go devices. We should provide architecture-specific (ARM and x86) APKs to keep the size below 10 MB.
Idea stolen from Orbot. :-)
https://developer.android.com/studio/build/configure-apk-splitshttps://code.briarproject.org/briar/briar/-/issues/1292Test Briar with power management apps2020-11-16T11:01:17ZakwizgranTest Briar with power management appsTest whether Briar is killed, loses connectivity, or is listed as power-intensive by power management apps such as the following:
https://play.google.com/store/apps/details?id=com.oasisfeng.greenify
https://play.google.com/store/apps/d...Test whether Briar is killed, loses connectivity, or is listed as power-intensive by power management apps such as the following:
https://play.google.com/store/apps/details?id=com.oasisfeng.greenify
https://play.google.com/store/apps/details?id=com.avast.android.batterysaver
https://play.google.com/store/apps/details?id=com.battery.power.batterysaverhttps://code.briarproject.org/briar/briar/-/issues/1320Add backpressure to incoming sync sessions2020-11-18T01:34:09ZakwizgranAdd backpressure to incoming sync sessionsIncomingSession reads records from the transport as quickly as possible and queues them to be added to the DB. If the transport is faster than the DB, this will result in an unbounded number of records being queued. This uses an unbounde...IncomingSession reads records from the transport as quickly as possible and queues them to be added to the DB. If the transport is faster than the DB, this will result in an unbounded number of records being queued. This uses an unbounded amount of memory, which is a DoS risk.
Add a backpressure mechanism that limits the amount of queued data and delays reading from the connection when the queue is full.https://code.briarproject.org/briar/briar/-/issues/1321Add backpressure to outgoing duplex sync sessions2020-11-18T01:37:42ZakwizgranAdd backpressure to outgoing duplex sync sessionsDuplexOutgoingSession reads records from the database as quickly as possible and queues them for transmission. If the DB is faster than the transport, this will result in all sendable records being queued. This uses an unbounded amount o...DuplexOutgoingSession reads records from the database as quickly as possible and queues them for transmission. If the DB is faster than the transport, this will result in all sendable records being queued. This uses an unbounded amount of memory and increases the risk of records being lost before they're transmitted, leading to unnecessary retransmissions.
Add a backpressure mechanism that limits the amount of queued data and delays DB reads when the queue is full.
This will be a bit more complex than #1319 because DuplexOutgoingSession can start DB queries in response to events.https://code.briarproject.org/briar/briar/-/issues/1326Prevent old messages from aborting client protocols2020-11-18T01:39:44ZakwizgranPrevent old messages from aborting client protocolsSome client protocols that use an abort message to reset the state machine are vulnerable to a race condition where incoming messages that were already in flight when the abort message was sent are received after resetting, causing furth...Some client protocols that use an abort message to reset the state machine are vulnerable to a race condition where incoming messages that were already in flight when the abort message was sent are received after resetting, causing further aborts. This is harmless if the state machine is still in the start state when the messages are received, but it may cause problems if the state machine has moved out of the start state.
The problem can be avoided by using an abort counter:
* Each party keeps a counter for each other party they sync with
* The counter is part of the session state
* The counter is initialised to zero
* The counter is reset to zero if the other party is removed as a contact
* The counter is included in every outgoing message
* Incoming messages with counters lower than the local counter are ignored
* The counter is incremented after sending or receiving an abort message
If two parties concurrently abort the protocol they may ignore each other's abort messages, but this appears to be harmless: either both will increment their counters once, or both twice.
Client protocols that use abort messages without counters will need to be upgraded to accommodate counters. It may be possible to do this with a minor version upgrade.https://code.briarproject.org/briar/briar/-/issues/1347Annotate UI methods that run on background threads2020-11-17T16:09:10ZakwizgranAnnotate UI methods that run on background threadsWe tend to assume that UI components are only accessed on the UI thread and don't need to be thread-safe, but sometimes this isn't true. Create an annotation for UI methods that run on background threads. (Methods that run on particular ...We tend to assume that UI components are only accessed on the UI thread and don't need to be thread-safe, but sometimes this isn't true. Create an annotation for UI methods that run on background threads. (Methods that run on particular executors can use the existing executor annotations.)https://code.briarproject.org/briar/briar/-/issues/1353Create fake data for automated screenshots2020-11-17T16:08:47ZakwizgranCreate fake data for automated screenshotsCreate fake data that can be inserted into the app by an Espresso test when taking screenshots for the manual or app store.Create fake data that can be inserted into the app by an Espresso test when taking screenshots for the manual or app store.https://code.briarproject.org/briar/briar/-/issues/1387Keep persistent log messages2020-11-17T15:47:48ZTorsten GroteKeep persistent log messagesIt might be useful to have logs that persist across restarts (e.g. to find out why users get signed out). But that would require one of the following solutions:
* write logs to an encrypted file that we can read back after restarting...It might be useful to have logs that persist across restarts (e.g. to find out why users get signed out). But that would require one of the following solutions:
* write logs to an encrypted file that we can read back after restarting
* write logs to the system log, use the `READ_LOGS` permission to read them back after restarting - this results in a scary permission warning at installation time on API < 23
* write logs to the system log, read them back without the `READ_LOGS` permission - this only works on API >= 16, but that's nearly all our users, so we could just live without this feature on API 15. the bigger issue with using the system log is that the logs are stored in plaintexthttps://code.briarproject.org/briar/briar/-/issues/1414Work with Briar users to set up OONI tests in censored locations2020-11-15T20:03:14ZTorsten GroteWork with Briar users to set up OONI tests in censored locationsThis is so we can find out where bridges are needed, so we can enable them automatically.This is so we can find out where bridges are needed, so we can enable them automatically.https://code.briarproject.org/briar/briar/-/issues/1415Develop scripts to use the OONI API to find locations where pluggable transpo...2020-11-15T20:02:27ZTorsten GroteDevelop scripts to use the OONI API to find locations where pluggable transports are neededhttps://code.briarproject.org/briar/briar/-/issues/1429Configure Animal Sniffer to allow try-with-resources2021-08-09T12:30:08ZakwizgranConfigure Animal Sniffer to allow try-with-resourcesThe Animal Sniffer plugin, which we use to check that our code is compatible with the Java 6 API provided by older Android devices, rejects the try-with-resources statement added in Java 7. This is unfortunate, as Android's desugar prepr...The Animal Sniffer plugin, which we use to check that our code is compatible with the Java 6 API provided by older Android devices, rejects the try-with-resources statement added in Java 7. This is unfortunate, as Android's desugar preprocessor converts the statement to Java 6-compatible bytecode, so it's usable on older devices.
We should look for a way to configure Animal Sniffer so the statement isn't rejected.https://code.briarproject.org/briar/briar/-/issues/1432Headless integration tests2020-11-18T17:04:10ZTorsten GroteHeadless integration testsWe should add some integration tests for the REST API endpoints to catch breakage.We should add some integration tests for the REST API endpoints to catch breakage.Headless MVPhttps://code.briarproject.org/briar/briar/-/issues/1447Core API for observing a message graph2020-12-08T12:17:23ZakwizgranCore API for observing a message graphThe core API exposes methods for getting a snapshot of the message graph in a group, such as `DatabaseComponent#getMessageIds()` and `DatabaseComponent#getDependencies()`, and events for learning about changes to the message graph, such ...The core API exposes methods for getting a snapshot of the message graph in a group, such as `DatabaseComponent#getMessageIds()` and `DatabaseComponent#getDependencies()`, and events for learning about changes to the message graph, such as `MessageAddedEvent` and `MessageStateChangedEvent` at the sync layer, or `PrivateMessageReceivedEvent` at the client layer.
The UI uses a combination of asynchronous DB queries and events to maintain a view of the message graph. Using the data attached to events to update the UI is more efficient than triggering a DB query for every event, but it causes a lot of complexity in the UI code because updates may happen concurrently with asynchronous loads (see #705).
All interactions between the UI and the DB are funnelled through the single-threaded DatabaseExecutor, mainly to ensure that queries return their results to the UI in the same order as the queries were started. The database allows read-only transactions to run concurrently, but queries running on the DatabaseExecutor can't take advantage of this because the executor is single-threaded.
If we could provide a better API for observing a message graph then we might be able to simplify the UI code and perhaps even improve DB performance by allowing more queries to run concurrently.
The new API should allow an observer to register an interest in a group's message graph and receive an initial snapshot of the graph, followed by an ordered series of updates when the graph changes. An observer registered from the UI will need to process the observations on the UI thread. As long as the core delivers the observations in order it should be easy to move them onto the UI thread in the same order.
We also need a way to register multiple observers that are ordered with respect to each other, so that we can create UI components that represent multiple groups, such as a conversation containing private messages, invitations, etc.
To ensure ordering, the DB will need to register any changes made by a transaction before releasing the DB lock. Events attached to transactions aren't currently suitable for communicating ordered changes because they're broadcast after releasing the DB lock, so two transactions that commit their changes in the order A, B may broadcast their events in the order B, A. But communicating changes to other components while holding the DB lock would have the potential to cause deadlock.
It might be possible to modify the event broadcasting logic so that events are registered before releasing the lock and broadcast afterwards, ensuring the broadcast order is consistent with the commit order. Alternatively we could create a separate mechanism for registering and communicating ordered changes.https://code.briarproject.org/briar/briar/-/issues/1448Core API for observing group metadata2020-11-15T19:37:03ZakwizgranCore API for observing group metadataSimilarly to #1447, it would be useful if the core allowed an observer to register an interest in a group's metadata and receive an initial snapshot followed by an ordered series of updates. It should be possible to register multiple obs...Similarly to #1447, it would be useful if the core allowed an observer to register an interest in a group's metadata and receive an initial snapshot followed by an ordered series of updates. It should be possible to register multiple observers that are ordered with respect to each other, or alternatively a single observer that specifies multiple groups to watch. This would make it easier to maintain views like the contact list, which is based on metadata from multiple groups per contact.https://code.briarproject.org/briar/briar/-/issues/1474Check for view recycling issues when language is changed2021-02-26T18:39:12ZakwizgranCheck for view recycling issues when language is changedIn a code review discussion (https://code.briarproject.org/briar/briar/merge_requests/997#note_33406) we identified the possibility of views being recycled without being bound to new view holders when the app or system language changes (...In a code review discussion (https://code.briarproject.org/briar/briar/merge_requests/997#note_33406) we identified the possibility of views being recycled without being bound to new view holders when the app or system language changes (especially when it changes from RTL to LTR or vice versa).
This seems to be prevented at the moment because we (always?) clear the adapter when the activity stops, and the language can't be changed without stopping the activity. The issue might become live in the future if we change our adapters, so this ticket exists to remind us to check for the issue if we do that.https://code.briarproject.org/briar/briar/-/issues/1500Check PNGs for exploits before passing them to Android2021-11-04T11:03:44ZakwizgranCheck PNGs for exploits before passing them to AndroidWe need to find out how to detect PNGs that can exploit this vulnerability, so we can avoid passing them to Android:
https://www.zdnet.com/article/opening-this-image-file-grants-hackers-access-to-your-android-phone/
Subtask of #1237.We need to find out how to detect PNGs that can exploit this vulnerability, so we can avoid passing them to Android:
https://www.zdnet.com/article/opening-this-image-file-grants-hackers-access-to-your-android-phone/
Subtask of #1237.Android 1.4https://code.briarproject.org/briar/briar/-/issues/1549Release beta versions via F-Droid2020-11-15T18:45:20ZakwizgranRelease beta versions via F-DroidA user asked for beta versions to be released via F-Droid.
Currently we make releases in two stages. In the first stage (beta tag) the release is made available for direct download, via our F-Droid repo, and to Google Play beta testers....A user asked for beta versions to be released via F-Droid.
Currently we make releases in two stages. In the first stage (beta tag) the release is made available for direct download, via our F-Droid repo, and to Google Play beta testers. In the second stage (release tag) it's made available via the main F-Droid repo and to all Google Play users.
It would be nice if (a) beta releases weren't marked as recommended in our F-Droid repo, and (b) beta releases were made available, but not marked as recommended, in the main F-Droid repo.https://code.briarproject.org/briar/briar/-/issues/1555Factor out BriarActionBarActivity for ActionBar handling2020-11-15T18:31:40ZTorsten GroteFactor out BriarActionBarActivity for ActionBar handlingFrom https://code.briarproject.org/briar/briar/merge_requests/1035#note_36028
Push action bar handling code up into a BriarActionBarActivity and make current activities using it inherit it.
```java
ActionBar ab = getSupportActionBar();...From https://code.briarproject.org/briar/briar/merge_requests/1035#note_36028
Push action bar handling code up into a BriarActionBarActivity and make current activities using it inherit it.
```java
ActionBar ab = getSupportActionBar();
if (ab != null) {
ab.setDisplayHomeAsUpEnabled(true);
}
```
`onOptionsItemSelected()`