briar issueshttps://code.briarproject.org/groups/briar/-/issues2021-11-04T12:53:57Zhttps://code.briarproject.org/briar/briar/-/issues/2211Make strict mode warnings configurable2021-11-04T12:53:57ZSebastianMake strict mode warnings configurablehttps://code.briarproject.org/briar/briar/-/issues/2223Improve cleanup after lifecycle startup errors2021-11-17T15:50:26ZakwizgranImprove cleanup after lifecycle startup errorsLifecycleManager#startServices() can return various error values. Currently the Android app doesn't call stopServices() unless startup succeeded, whereas the headless app calls stopServices() regardless.
If the system clock is unreasona...LifecycleManager#startServices() can return various error values. Currently the Android app doesn't call stopServices() unless startup succeeded, whereas the headless app calls stopServices() regardless.
If the system clock is unreasonable, LifecycleManagerImpl#startServices() doesn't release the startStopSemaphore before returning, so stopServices() will block indefinitely - but the semaphore is released in the case of other errors.
We should tidy all of this up so that either stopServices() doesn't need to be called if startup fails, or so that it can be called safely and without blocking indefinitely, and so that services and the DB have a clear contract for whether they will be started and/or stopped if an error happens.
Related to #2222.https://code.briarproject.org/briar/briar/-/issues/2244Reduce bandwidth used by polling2021-12-13T14:23:36ZakwizgranReduce bandwidth used by pollingPolling for connections to contacts via Tor uses a significant amount of bandwidth. We could save bandwidth by polling unreachable contacts less often, or by polling less often (perhaps not at all) if we're confident that contacts can co...Polling for connections to contacts via Tor uses a significant amount of bandwidth. We could save bandwidth by polling unreachable contacts less often, or by polling less often (perhaps not at all) if we're confident that contacts can connect to us when they come online (ie if our hidden service is reachable).
For short-range transports, polling contacts in a batch may use less battery than polling them at contact-specific intervals. It may be possible to meet the needs of Tor and short-range transports by polling in batches, but not including unreachable contacts in every batch.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/303Use Bluetooth LE for peer discovery2022-01-26T13:50:35ZakwizgranUse Bluetooth LE for peer discoverySome newer Android devices support Bluetooth LE peripheral mode, which allows them to send beacons advertising their presence. This could be used as a low-energy and privacy-preserving alternative to polling for device pairs that support...Some newer Android devices support Bluetooth LE peripheral mode, which allows them to send beacons advertising their presence. This could be used as a low-energy and privacy-preserving alternative to polling for device pairs that support it.
https://altbeacon.github.io/android-beacon-library/beacon-transmitter-devices.html
Related to #44, #62.https://code.briarproject.org/briar/briar/-/issues/2282iOS feasibility study2022-03-03T17:03:06ZakwizgraniOS feasibility studyTo know whether Briar can be viable on iOS we need to answer the following questions.
Online:
* Can the app run a Tor hidden service on iOS? (Bearing in mind that this requires a wake lock on Android to prevent Tor's circuits from timin...To know whether Briar can be viable on iOS we need to answer the following questions.
Online:
* Can the app run a Tor hidden service on iOS? (Bearing in mind that this requires a wake lock on Android to prevent Tor's circuits from timing out when the CPU sleeps.)
* Can the hidden service keep running for a limited time when the app goes into the background?
* Can the app wake periodically while running in the background, connect to a mailbox via Tor and check for messages?
* If the app finds messages when checking the mailbox, can it (a) store the messages in the local database, (b) show a notification?
Offline:
* Can the app advertise a UUID/other info via BLE such that nearby iOS/Android devices can discover it?
* Can the app scan for UUIDs/other info advertised via BLE by nearby iOS/Android devices?
* Can the app make/receive GATT connections to/from iOS/Android devices?
* Can the app make/receive L2CAP-CoC connections to/from iOS/Android devices?
* Can the app provide a wifi hotspot (without internet access)? Can it make/receive TCP connections to/from devices connected to the hotspot?
* Can the app connect to a wifi hotspot (without internet access) provided by another device? Can it make/receive TCP connections to/from other devices connected to the hotspot?
For all of the above we need to know:
* Differences between foreground and background behaviour
* API limits such as rate limits, number of UUIDs that can be scanned for
* Any other circumstances that could affect the behaviour, such as screen being off, low battery, device reboot, user not bringing the app to the foreground for a long time
* Whether user interaction is neededhttps://code.briarproject.org/briar/tor-reproducer/-/issues/9Extract code from Android Makefile2022-03-10T14:07:20ZakwizgranExtract code from Android MakefileConvert some of the code in the Android Makefile to Python so we more easily compare the Android, Linux and Windows builds and share code between them.Convert some of the code in the Android Makefile to Python so we more easily compare the Android, Linux and Windows builds and share code between them.https://code.briarproject.org/briar/tor-reproducer/-/issues/10Share more code between platforms2022-03-10T14:07:20ZakwizgranShare more code between platformsRefactor the code to share more code between platforms, perhaps through inheritance. Depends on #9.Refactor the code to share more code between platforms, perhaps through inheritance. Depends on #9.https://code.briarproject.org/briar/tor-reproducer/-/issues/12Investigate whether we can use --enable-static-tor2022-03-10T14:24:04ZakwizgranInvestigate whether we can use --enable-static-torWhen configuring the Tor build, the `--enable-static-tor` flag sets two flags we're not currently using on all platforms: `--enable-static-zlib` and `-static`.
We had some issues with `--enable-static-zlib` on Android, and `-static` may...When configuring the Tor build, the `--enable-static-tor` flag sets two flags we're not currently using on all platforms: `--enable-static-zlib` and `-static`.
We had some issues with `--enable-static-zlib` on Android, and `-static` may cause portability issues with glibc and NSS on Linux. Find out more about these issues and decide whether we should use `--enable-static-tor` on each platform.https://code.briarproject.org/briar/briar/-/issues/2288Check whether Tor complains about absence of ec_nistp_64_gcc_128 optimisation...2022-03-18T14:56:41ZakwizgranCheck whether Tor complains about absence of ec_nistp_64_gcc_128 optimisation on Android x86_64On Windows and Linux x64_64, Tor complains if the `ec_nistp_64_gcc_128` optimisation wasn't enabled at compile time. Check whether this also needs to be enabled on Android x86_64.On Windows and Linux x64_64, Tor complains if the `ec_nistp_64_gcc_128` optimisation wasn't enabled at compile time. Check whether this also needs to be enabled on Android x86_64.https://code.briarproject.org/briar/briar/-/issues/2010Investigate behaviour of recent apps list for various manufacturers2022-03-21T13:49:28ZakwizgranInvestigate behaviour of recent apps list for various manufacturersMany manufacturers have custom implementations of the recent apps list.
On Tecno phones, clearing the recent apps list [kills the Briar process](https://code.briarproject.org/briar/briar/-/issues/992#note_44605) unless the app is [locke...Many manufacturers have custom implementations of the recent apps list.
On Tecno phones, clearing the recent apps list [kills the Briar process](https://code.briarproject.org/briar/briar/-/issues/992#note_44605) unless the app is [locked to the recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49393).
On Xiaomi/Redmi phones, [locking an app to the recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49341) prevents it from being killed by the system's power manager, which would otherwise happen even without clearing the list.
For as many manufacturers as possible, find out:
1. whether clearing the recent apps list kills Briar
2. whether apps can be locked to the recent apps list
3. whether locking prevents Briar from being killed when clearing the list
4. whether locking provides any other protection (e.g. from the system's power manager)https://code.briarproject.org/briar/tor-reproducer/-/issues/5Properly handle enviroment variables2022-04-03T10:52:06ZNicoProperly handle enviroment variablesThis script is growing bigger and bigger and while working on !17 I noticed that the environment variables from the Linux build are causing the Windows build to fail, because `os.environ.copy()` doesn't seem to do what it pretends to do....This script is growing bigger and bigger and while working on !17 I noticed that the environment variables from the Linux build are causing the Windows build to fail, because `os.environ.copy()` doesn't seem to do what it pretends to do. I.e., we still modify the original environment variables after the copy and thus I now manually pop them after each build (15971b47a2c7b7f01abb422b42dd0cc75f7a8045).
Since this is quite ugly, we should do something better in the future.
There are simple helper functions [like this one](https://gist.github.com/igniteflow/7267431#gistcomment-2551951) which would allow us to really only temporary set environment variables, but since this would require larger architectural changes, I didn't do it yet. Especially given that we might use official Tor binaries soon anyway.https://code.briarproject.org/briar/briar/-/issues/2300Show more information about startup failures2022-04-08T12:33:12ZakwizgranShow more information about startup failuresRecently we've had several reports of corrupt databases (StartResult#DB_ERROR). Because these errors prevent the app from starting, we can't use crash reports or user feedback to learn about the cause.
We should expose more information ...Recently we've had several reports of corrupt databases (StartResult#DB_ERROR). Because these errors prevent the app from starting, we can't use crash reports or user feedback to learn about the cause.
We should expose more information about startup failures in the UI. This will involve returning the information from LifecycleManager#startService() and then attaching it to the intent that launches StartupFailureActivity. StartupFailureActivity should allow the user to copy the information so they can send it to us.Android 1.4https://code.briarproject.org/briar/briar/-/issues/31Use built-in error correction for modem plugin?2022-04-18T09:39:27ZakwizgranUse built-in error correction for modem plugin?
Newer dialup modems (presumably the majority of those still in use) support error correction via V.42 LAPM and/or MNP. This may be sufficient to carry BTP without an intermediate reliability layer. If so, the reliability code (SLTP) co...
Newer dialup modems (presumably the majority of those still in use) support error correction via V.42 LAPM and/or MNP. This may be sufficient to carry BTP without an intermediate reliability layer. If so, the reliability code (SLTP) could be removed, reducing the size of the codebase and making BTP connections harder to identify: they would simply be SLIP-framed random data. (SLIP-framed UDP packets full of random data would be another easily implemented option, if that would be less likely to stand out.)
AT commands for enabling error correction (on which modems?):
* AT\N2: Require error correction, report NO CARRIER if the other end doesn't support it.
* AT&Q5: Try to negotiate an error corrected link.https://code.briarproject.org/briar/briar-desktop/-/issues/340Detect when LAN IP address changes2022-04-18T09:39:50ZakwizgranDetect when LAN IP address changesThis already works on Android, but how to do it on the desktop is an open question.This already works on Android, but how to do it on the desktop is an open question.https://code.briarproject.org/briar/briar/-/issues/64Upgrade jSSC to 2.8.02022-04-18T09:40:48ZakwizgranUpgrade jSSC to 2.8.0jSSC, the serial port library used by the dialup modem plugin, is at version 2.8.0 but we're still using version 0.9. Upgrade to the current version, amending or discarding our thread safety patch as appropriate.jSSC, the serial port library used by the dialup modem plugin, is at version 2.8.0 but we're still using version 0.9. Upgrade to the current version, amending or discarding our thread safety patch as appropriate.https://code.briarproject.org/briar/briar/-/issues/1635Try to send message before its attachments2022-04-19T11:30:43ZTorsten GroteTry to send message before its attachmentsOne way to do this would be to set the timestamp of the attachments `1` greater than the timestamp of the message itself, so in the common case the message would be sent first. There's no guarantees because of retransmission etc, but usu...One way to do this would be to set the timestamp of the attachments `1` greater than the timestamp of the message itself, so in the common case the message would be sent first. There's no guarantees because of retransmission etc, but usually that would give the result we want.https://code.briarproject.org/briar/briar/-/issues/1104Load messages on demand (paged/lazy)2022-05-16T19:53:45ZakwizgranLoad messages on demand (paged/lazy)If a group contains a lot of messages, it's expensive to load all the messages when the user views the group.
Some clients use metadata to avoid loading messages. Message bodies can then be loaded on demand as they become visible. But t...If a group contains a lot of messages, it's expensive to load all the messages when the user views the group.
Some clients use metadata to avoid loading messages. Message bodies can then be loaded on demand as they become visible. But this is still expensive if there are lots of messages and/or lots of metadata per message.
Ideally we'd use something like the MessageTracker to store summary information, then load the messages and/or metadata on demand.
One of the tasks here is to determine what summary information each client needs. For example, the forum client needs to know the number of unread posts above and below the viewport. It may also need to know the sort position of the first unread post above and below the viewport so it can jump to those posts.
Sort order will be relevant to any client that loads messages on demand. If we want to load messages a page at a time, the database needs to know how to sort the messages. But sort order is client-dependent. For example, the blog client may want to sort posts by date, whereas the forum client sorts them by depth-first traversal order of the reply tree.
We can capture both of these orders (and hopefully others) by adding a label to each message. From the database's point of view, the label is just an opaque string of bytes. The database sorts the labels in lexicographic order, and messages and metadata can be retrieved by their positions in the sort order. The client is reponsible for labelling messages to achieve the desired sort order.
For the blog client, the label can just be a big-endian representation of the timestamp. For the forum client, the label can be the concatenated timestamps of the post's ancestors and the post itself. These labels will sort in the same order as depth-first traversal of the tree, visiting siblings in timestamp order.
```
123
+-123/234
+-123/345
234
+-234/345
+-234/345/456
345
567
```
(This doesn't rely on the rule that a post has a higher timestamp than its parent.)
This approach wouldn't be efficient for dynamic sort orders. For example, if the forum client wanted to sort siblings by the number of upvotes, we could calculate the labels as with timestamps, but adding an upvote to a post would require relabelling the post and all its descendents.https://code.briarproject.org/briar/briar/-/issues/950Detect when Tor is failing to connect to the network2022-06-06T13:23:38ZakwizgranDetect when Tor is failing to connect to the networkUnder some circumstances (see #845), Tor can't connect to the network but the app doesn't realise there's no internet connectivity.. Repeatedly trying and failing to connect to guard nodes could cause Tor to mark its preferred guards as ...Under some circumstances (see #845), Tor can't connect to the network but the app doesn't realise there's no internet connectivity.. Repeatedly trying and failing to connect to guard nodes could cause Tor to mark its preferred guards as unreachable and choose new guards sooner than necessary, which could harm anonymity. We should consider setting `DisableNetwork 1` after repeated guard connection failures, then waiting for a connectivity event before trying again.https://code.briarproject.org/briar/briar/-/issues/1240Update database and sync API to support large messages2022-06-15T12:02:16ZakwizgranUpdate database and sync API to support large messagesSubtask of #1237.Subtask of #1237.Multi-block messages