briar issueshttps://code.briarproject.org/groups/briar/-/issues2022-03-10T14:24:04Zhttps://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/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/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/briar/-/issues/2269Use full camera preview when scanning QR codes2022-06-30T10:05:14ZakwizgranUse full camera preview when scanning QR codesThe QR code scanner only uses the upper half of the camera preview, as this is the only part that's visible when adding contacts in person. However, when pairing a mailbox the whole preview is visible, so the QR code may fail to scan if ...The QR code scanner only uses the upper half of the camera preview, as this is the only part that's visible when adding contacts in person. However, when pairing a mailbox the whole preview is visible, so the QR code may fail to scan if positioned in the middle of the preview.
We should either add a flag to control whether the whole preview is used, or (if testing on bad device combinations allows this), use the whole preview in both cases.
An example of a bad device combination is the Huawei Ascend Y330 showing the QR code and the Moto E3 scanning it.Mailbox: PairingDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar-mailbox/-/issues/90Wait for hidden service to be reachable before showing QR code2022-05-02T13:37:48ZakwizgranWait for hidden service to be reachable before showing QR codeMailbox: PairingTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2267Broadcast event when recording connection status of own mailbox2022-04-01T11:18:01ZakwizgranBroadcast event when recording connection status of own mailboxMailbox: Status UI for Briar appDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2266Check for API/behaviour changes in Android 13 that could affect Briar2023-07-03T11:21:13ZTorsten GroteCheck for API/behaviour changes in Android 13 that could affect Briar* https://developer.android.com/about/versions/13/behavior-changes-13
* https://blog.esper.io/android-13-deep-dive/
* https://commonsware.com/blog/2022/02/12/random-musings-android-13-dp1.html
* https://commonsware.com/blog/2022/03/19/ra...* https://developer.android.com/about/versions/13/behavior-changes-13
* https://blog.esper.io/android-13-deep-dive/
* https://commonsware.com/blog/2022/02/12/random-musings-android-13-dp1.html
* https://commonsware.com/blog/2022/03/19/random-musings-android-13-dp2.html
Changes that may affect us:
* [Low power standby](https://developer.android.com/reference/android/os/PowerManager.html#isLowPowerStandbyEnabled()) is a new power saving mode (apparently distinct from doze, light doze and power save mode) in which apps with foreground services lose network access and their wake locks are ignored. It's not clear whether doze exemption affects this mode. We should look for ADB commands that can be used to test this mode
* [Light idle mode](https://developer.android.com/reference/android/os/PowerManager#isDeviceLightIdleMode()) has also been added to the PowerManager API, although this may just be exposing the "light doze" mode that was [added in Android 7](https://developer.android.com/about/versions/nougat/android-7.0-changes#doze)
* [Apps are placed in the "restricted" app standby bucket](https://developer.android.com/about/versions/13/changes/battery#restricted-bucket) if they "drain a significant amount of device battery during a 24-hour period". This is likely to apply to Briar and Briar Mailbox. Apps are also placed in the "restricted" bucket if the user doesn't interact with them for 8 days. This is very likely to apply to Briar Mailbox and may also apply to Briar. Running a foreground service isn't enough to meet definition of "interaction" being used here. The [docs for app standby buckets](https://developer.android.com/topic/performance/appstandby#buckets) say "Apps that are on the Doze exemption list are exempted from the App Standby Bucket-based restrictions." We should test whether this remains true for the new restrictions. We should also add code to [log which bucket we're in](https://developer.android.com/reference/android/app/usage/UsageStatsManager#getAppStandbyBucket()) periodically
* [Apps need to ask permission to show notifications](https://developer.android.com/about/versions/13/changes/notification-permission) - if the app doesn't target API 33 then the permission prompt will be shown automatically when the notification channels are created, which in Briar's case happens after signing in
* The new [foreground services task manager](https://developer.android.com/about/versions/13/changes/fgs-manager) enables the user to stop foreground services. Stopping an app in this way is [roughly equivalent](https://developer.android.com/about/versions/13/changes/fgs-manager#compare-swipe-up-force-stop) to force-stopping the app, but just different enough to make sure we'll have to test both workflows. Related to #2010
* [New rules for intent filters](https://developer.android.com/about/versions/13/behavior-changes-13#security) could affect our use of intents to open other apps (such as manufacturer-specific power management apps). These rules apply if the app receiving the intent targets API 33 or higher, so it could take a while for any effects to be noticeable
Article: https://medium.com/androiddevelopers/making-sense-of-intent-filters-in-android-13-8f6656903dde
* We should check whether the [`RECEIVER_NOT_EXPORTED`](https://developer.android.com/reference/android/content/Context.html#RECEIVER_NOT_EXPORTED) flag is relevant to us (all our BroadcastReceivers are used for receiving system broadcasts)
* [`NEARBY_WIFI_DEVICES`](https://developer.android.com/reference/android/Manifest.permission#NEARBY_WIFI_DEVICES) permission - this replaces `ACCESS_FINE_LOCATION` for some wifi APIs. We should use the new permission and find out whether location services still need to be enabled for these APIs to work
* If the user places an app in the "restricted" state for background battery usage (which AFAICT is [unrelated](https://developer.android.com/topic/performance/power/power-details) to the "restricted" app standby bucket) then the app [can't run foreground services, schedule alarms or run jobs](https://developer.android.com/about/versions/13/changes/battery#restricted-background-battery-usage). If the app targets API 33 then it can't receive `ACTION_BOOT_COMPLETED` broadcasts either, which we use for the sign-in reminder
* [System notification for long-running foreground services](https://developer.android.com/about/versions/13/changes/battery#system-notification-long-running-fgs) ("APP is running in the background for a long time. Tap to review") - as CommonsWare says, the obvious response from developers is to add `FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK` or `FOREGROUND_SERVICE_TYPE_LOCATION`, and the obvious response from Google is to restrict those flags in the next update
* [System notification for excessive background battery usage](https://developer.android.com/about/versions/13/changes/battery#system-notification-battery-usage) - the docs say this notification will be shown after our foreground service finishes, ie after the user signs out, which may cause confusion
* I'm sure [TARE](https://blog.esper.io/android-13-deep-dive/#tare) will produce great value for users and won't just be the equivalent of adding a dice roll to every attempt to queue a job or schedule an alarm. We should keep it in mind when debugging alarm issues
* [Apps can release unused permissions](https://developer.android.com/about/versions/13/features#developer-downgradable-permissions) - this looks useful for privacy-conscious users but some care will be needed to integrate this into our app lifecycle, as the system kills the app asynchronously at some point after the API is called
* There's a [new AndroidX API for implementing in-app language pickers](https://developer.android.com/about/versions/13/features/app-languages#api-impl), which is great. The user can also pick a per-app language [through the system settings app](https://developer.android.com/about/versions/13/features/app-languages#app-language-settings), in which case "The list of available languages might not reflect the languages that your app supports". This will need testing
* There's a new API for [opting out of screenshots in the recent apps list](https://developer.android.com/reference/android/app/Activity.html#setRecentsScreenshotEnabled(boolean)) without preventing the user from taking screenshots. This may be useful if it doesn't open some other horrendous information leak
* [SystemClock#currentNetworkTimeClock()](https://developer.android.com/reference/android/os/SystemClock.html#currentNetworkTimeClock()) may be useful for diagnosing whether clock sync issues are due to misconfiguration or [NTP tampering](https://gitlab.torproject.org/tpo/core/tor/-/issues/26359)
* Apps with the `ACCESS_FINE_LOCATION` permission are [exempt from most of the power management changes in Android 13](https://developer.android.com/about/versions/13/changes/battery#exemptions), as are media players that are actively playing media. Perhaps Google thinks media players and navigation apps (or exercise trackers?) should be allowed to run in the background, which would be consistent with the apparent intent of previous loopholesTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/2265Replace ETA with max latency in retransmission logic2022-03-29T13:12:39ZakwizgranReplace ETA with max latency in retransmission logicThe sync protocol allows a message to be retransmitted if either the message's send time (also called expiry time in the database code) has been reached, or if the message's ETA via the currently available transport would be earlier than...The sync protocol allows a message to be retransmitted if either the message's send time (also called expiry time in the database code) has been reached, or if the message's ETA via the currently available transport would be earlier than the ETA of the previous copy. The ETA is based on the max latency of the transport.
This second (ETA) condition is met when the previous copy was sent via a higher-latency transport and a lower-latency transport is now available. But this logic has a weird edge case: immediately after sending a message via a higher-latency transport, the message can be sent via a lower-latency transport, as intended. But as the ETA of the first copy approaches, the message stops being sendable via the lower-latency transport.
This edge case is unlikely to matter when the lower latency is a tiny fraction of the higher latency (eg 30 seconds for Tor vs 28 days for removable drives). But it may become important when the lower latency is a significant fraction of the higher latency (eg 14 days for mailboxes vs 28 days for removable drives).
To remove the edge case we should store the max latency of the transport rather than the ETA, and allow the message to be retransmitted if either the send time has been reached (as now), or if the max latency of the currently available transport is less than the max latency of the transport used for the previous copy. This will require a DB migration.MailboxDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/briar/-/issues/2261Include mailbox API version in local and remote mailbox properties2022-05-16T13:59:41ZakwizgranInclude mailbox API version in local and remote mailbox propertiesDepends on https://code.briarproject.org/briar/briar/-/issues/2298Depends on https://code.briarproject.org/briar/briar/-/issues/2298Mailbox: Sync mailbox propertiesDaniel LublinDaniel Lublinhttps://code.briarproject.org/briar/public-mesh-research/-/issues/7Initial investigations: Bluetooth LE2023-08-28T16:08:02ZakwizgranInitial investigations: Bluetooth LESubtask of #1. Related to briar#28, briar#303, briar#1147, briar#1546.
Investigate BLE advertising and scanning (including larger advertisement packets in BT 5), L2CAP connections, and coded PHY.
https://www.bluetooth.com/wp-content/up...Subtask of #1. Related to briar#28, briar#303, briar#1147, briar#1546.
Investigate BLE advertising and scanning (including larger advertisement packets in BT 5), L2CAP connections, and coded PHY.
https://www.bluetooth.com/wp-content/uploads/2022/05/Bluetooth_LE_Primer_Paper.pdfPublic mesh researchakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2259Migrate to Tor 0.4.52022-04-19T11:26:19ZakwizgranMigrate to Tor 0.4.5Tor 0.3.5.18 is the last release in the 0.3.5 LTS series. The new LTS series is 0.4.5. Updating to the new series will require more testing than our usual updates, and may require changes to tor-reproducer.
https://gitlab.torproject.org...Tor 0.3.5.18 is the last release in the 0.3.5 LTS series. The new LTS series is 0.4.5. Updating to the new series will require more testing than our usual updates, and may require changes to tor-reproducer.
https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleasesAndroid 1.4Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/public-mesh-research/-/issues/6Initial investigations: Wi-Fi Aware (NAN)2022-11-08T13:28:31ZakwizgranInitial investigations: Wi-Fi Aware (NAN)Subtask of #1. Related to briar#28.Subtask of #1. Related to briar#28.Public mesh researchakwizgranakwizgranhttps://code.briarproject.org/briar/public-mesh-research/-/issues/5Initial investigations: Wi-Fi Direct2023-08-28T16:08:03ZakwizgranInitial investigations: Wi-Fi DirectSubtask of #1. Related to briar#39, briar#28.
https://www.wi-fi.org/file/wi-fi-direct-specificationSubtask of #1. Related to briar#39, briar#28.
https://www.wi-fi.org/file/wi-fi-direct-specificationPublic mesh researchakwizgranakwizgranhttps://code.briarproject.org/briar/public-mesh-research/-/issues/4Register public mesh research app's signing key and package name with Google ...2022-11-08T13:28:31ZakwizgranRegister public mesh research app's signing key and package name with Google PlayIf we plan to develop a research app as part of briar#1817, register the package name and app signing key with Google Play before the end of July 2021 so we're not required to let Google manage the signing key.
https://android-developer...If we plan to develop a research app as part of briar#1817, register the package name and app signing key with Google Play before the end of July 2021 so we're not required to let Google manage the signing key.
https://android-developers.googleblog.com/2020/11/new-android-app-bundle-and-target-api.html
Subtask of briar#1817.Public mesh researchakwizgranakwizgran2021-07-31https://code.briarproject.org/briar/public-mesh-research/-/issues/3Create skeleton app for public mesh experiments2022-11-08T13:28:31ZakwizgranCreate skeleton app for public mesh experimentsSubtask of briar#1817.Subtask of briar#1817.Public mesh researchakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2256Create skeleton app for public mesh experiments2022-01-21T14:12:55ZakwizgranCreate skeleton app for public mesh experimentsSubtask of #1817.Subtask of #1817.Public mesh researchakwizgranakwizgranhttps://code.briarproject.org/briar/briar-mailbox/-/issues/81Upgrade ch.qos.logback dependency2022-02-25T14:53:57ZakwizgranUpgrade ch.qos.logback dependencyUpgrade ch.qos.logback to version 1.2.9 to fix a JNDI-related vulnerability.
https://logback.qos.ch/news.html
logback-android is unaffected as it doesn't support JNDI. How sensible.
https://github.com/tony19/logback-android/issues/230Upgrade ch.qos.logback to version 1.2.9 to fix a JNDI-related vulnerability.
https://logback.qos.ch/news.html
logback-android is unaffected as it doesn't support JNDI. How sensible.
https://github.com/tony19/logback-android/issues/230MailboxSebastianSebastianhttps://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/2243Tests for OkHttp client calls2022-02-25T14:58:20ZakwizgranTests for OkHttp client callsCreate a basic unit or integration test for testing an OkHttp client call against a fake API endpoint provided by the test.
This will be the basis for testing methods that wrap OkHttp calls (eg #2183).Create a basic unit or integration test for testing an OkHttp client call against a fake API endpoint provided by the test.
This will be the basis for testing methods that wrap OkHttp calls (eg #2183).MailboxTorsten GroteTorsten Grote2022-01-17https://code.briarproject.org/briar/briar/-/issues/2242Migrate OkHttp to bramble-core2022-02-25T14:59:07ZakwizgranMigrate OkHttp to bramble-coreMailboxTorsten GroteTorsten Grote2022-01-03