briar issueshttps://code.briarproject.org/briar/briar/-/issues2020-11-19T15:04:11Zhttps://code.briarproject.org/briar/briar/-/issues/1041Reduce CPU consumption2020-11-19T15:04:11ZakwizgranReduce CPU consumptionFeedback from a user: "I noticed that the app has a high CPU usage. My battery drained noticeably faster than usual, with briar running, and my OS warned me about it using a lot of CPU time."
Related to #44.Feedback from a user: "I noticed that the app has a high CPU usage. My battery drained noticeably faster than usual, with briar running, and my OS warned me about it using a lot of CPU time."
Related to #44.https://code.briarproject.org/briar/briar/-/issues/1025Extreme battery drain2017-10-17T16:33:07ZHenrie SchmidtExtreme battery drainHi there!
I had an enormous battery drain the last time. Briar took about 25% of the entire power and my phone was out of energy within a few hours. My friend had the same problem with a Motorola Razr I with CyanogenMod (I think it is v...Hi there!
I had an enormous battery drain the last time. Briar took about 25% of the entire power and my phone was out of energy within a few hours. My friend had the same problem with a Motorola Razr I with CyanogenMod (I think it is version 12). Because of this fact we decided to remove Briar until the Bug is fixed... :-(
I use a Samsung Galaxy S5 mini (G800F) with Lineage OS 14.1.
Greetings
Jenshttps://code.briarproject.org/briar/briar/-/issues/992continuously disconnected/logged out from Briar2021-09-01T10:10:21Zfedecontinuously disconnected/logged out from BriarThe problem I'm reporting does not concern my Briar setup (I'm using LineageOS 14.1), but my friend Briar setup. She uses a stock Android (can't check the version right now). Here's what happens to her:
- when she power-on the phone, Br...The problem I'm reporting does not concern my Briar setup (I'm using LineageOS 14.1), but my friend Briar setup. She uses a stock Android (can't check the version right now). Here's what happens to her:
- when she power-on the phone, Briar autostarts and asks for the password
- for some time she appears logged in and we can send messages each other
- after some time (less than half an hour) she appears offline and she does not receive any message
- even if she starts again Briar and logs in again, after some time she's put out without any notice
I could not see any obvious mistake in her configuration.
But I'm very new to Briar, so do not take anything for granted.
Any hint on how to debug this problem is appreciated.
Thanks in advanceakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/978Add preference for using tor only when having power2019-02-21T10:34:01ZGreg TroxelAdd preference for using tor only when having power(Sorry if this is a dup; I searched but am not confident.)
I just built and installed Briar after being absent for a while. I see there's a preference for using tor never, on wifi, and on cellular. That's great for some, but doesn't a...(Sorry if this is a dup; I searched but am not confident.)
I just built and installed Briar after being absent for a while. I see there's a preference for using tor never, on wifi, and on cellular. That's great for some, but doesn't address my problem. I realize there is tension with UX and complicated config, but given that having a HS is very very costly power wise, and outbound tor is somewhat costly, I'd like to see a config for "Use Tor when not charging" that is "no, outbound only, outbound and inbound". This would probably let me start running briar, and I suspect would let others do so as well.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/878Let contacts know that we've removed them2020-11-19T15:54:55ZakwizgranLet contacts know that we've removed themCurrently we don't tell contacts that we've removed them - we just stop connecting to them and close any connections they make to us, since we no longer recognise the tags.
The main advantage of the current approach is that we can remov...Currently we don't tell contacts that we've removed them - we just stop connecting to them and close any connections they make to us, since we no longer recognise the tags.
The main advantage of the current approach is that we can remove contacts tactfully: the contact can't necessarily tell whether we removed her or whether we just haven't signed in recently. However, if the contact sees us posting to forums, blogs or private groups, she may be able to tell that we've removed her. A second advantage is that we can immediately delete all state relating to the contact. Removing all *identifiable* state is important - it's the equivalent of forward secrecy for the social graph. But removing *all* state is just convenient.
The main disadvantage of the current approach is that the contact wastes battery and bandwidth trying to connect to us indefinitely. Depending on the transport this may expose metadata (#62). These problems will get worse over time as users accumulate defunct contacts.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/821Research whether network traffic can wake an app from sleep or doze2019-02-21T10:34:00ZakwizgranResearch whether network traffic can wake an app from sleep or dozeThe all-knowing oracles of Stack Overflow have conflicting opinions about whether an Android app that's blocked reading from a TCP connection while the device is sleeping will be woken when data arrives. This may be device-dependent. Cer...The all-knowing oracles of Stack Overflow have conflicting opinions about whether an Android app that's blocked reading from a TCP connection while the device is sleeping will be woken when data arrives. This may be device-dependent. Certainly the connection that's used for GCM/Firebase can wake the device, but the same may not be true of other connections. We also need to investigate whether doze behaves differently from sleep in this respect. Some sources claim that wifi behaves differently from mobile data - if so, we should investigate whether holding a wifi lock affects this.
It would also be useful to know whether an incoming connection to a server socket wakes the app.
Related to #44, #268.Android 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/817Add a setting to control whether Briar uses a wake lock2023-04-24T12:16:56ZakwizgranAdd a setting to control whether Briar uses a wake lockBriar holds a wake lock while Tor is running. @gdt asked for a setting to disable the wake lock, which would mean messages wouldn't be synced while the device was sleeping, but battery usage would be reduced.
If no other app is holding ...Briar holds a wake lock while Tor is running. @gdt asked for a setting to disable the wake lock, which would mean messages wouldn't be synced while the device was sleeping, but battery usage would be reduced.
If no other app is holding a wake lock, the device typically sleeps a few seconds after the screen turns off. We probably don't want to lose connectivity immediately, and it would be good if we could prepare for sleep so Tor doesn't panic when it wakes up. We might consider holding a wake lock for a few minutes after the screen turns off, then cleanly going offline and releasing the wake lock. Then we can listen for ACTION_SCREEN_ON to reacquire the wake lock and go online.
Alternatively, if we want to be really hardcore about saving battery at the expense of connectivity, we can go offline when the screen turns off. In that case no wake lock would be needed.
Related to #268, #769.https://code.briarproject.org/briar/briar/-/issues/769Test whether wake lock is still needed with Tor 0.2.82017-12-18T07:40:27ZakwizgranTest whether wake lock is still needed with Tor 0.2.8Test whether Tor 0.2.8 still needs a wake lock in order to keep the hidden service available when the device is idle. The wake lock is a major source of battery drain.
Related to #44, #574.Test whether Tor 0.2.8 still needs a wake lock in order to keep the hidden service available when the device is idle. The wake lock is a major source of battery drain.
Related to #44, #574.Milestone Fakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/602Exponential backoff for RSS feeds2021-04-16T13:21:41ZakwizgranExponential backoff for RSS feedsWe fetch all RSS feeds at the same fixed interval. Some feeds update much more frequently than others, so we should adjust the interval of each feed to match its update interval. This can be done by doubling the interval whenever a fetch...We fetch all RSS feeds at the same fixed interval. Some feeds update much more frequently than others, so we should adjust the interval of each feed to match its update interval. This can be done by doubling the interval whenever a fetch succeeds without finding any new posts, and halving the interval whenever new posts are found. The intervals should be stored persistently.
Related to #44, #45.https://code.briarproject.org/briar/briar/-/issues/545Find out why DB lookups are so slow2018-03-29T12:29:31ZakwizgranFind out why DB lookups are so slowAsynchronously looking up small amounts of data from the database takes longer than it should, even when the same data has been looked up recently. Work out which part of the process is the bottleneck, and how much performance would be i...Asynchronously looking up small amounts of data from the database takes longer than it should, even when the same data has been looked up recently. Work out which part of the process is the bottleneck, and how much performance would be improved if we spent some time improving that part of the process.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/542Don't poll for retransmission2018-03-08T15:59:11ZakwizgranDon't poll for retransmissionOutgoing sync sessions poll the database periodically for messages that have reached their send times and can be sent or offered again. This requires a thread to wake up periodically for each open session, even when there's nothing to se...Outgoing sync sessions poll the database periodically for messages that have reached their send times and can be sent or offered again. This requires a thread to wake up periodically for each open session, even when there's nothing to send.
The sync layer should keep track of the earliest send time of any message in the DB, and either broadcast an event when the send time is reached or provide a method that blocks until the earliest send time is reached.
Related to #44.Android Beta 2akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/314TorPlugin socket timeout2018-04-30T15:55:34ZErnir ErlingssonTorPlugin socket timeoutThere is a socket timeout in the Tor plugin, after 30 seconds of inactivity, that prevents user from communicating more than once over the mobile network. Connection between the devices is not re-established.
Reproduce:
1. Two devi...There is a socket timeout in the Tor plugin, after 30 seconds of inactivity, that prevents user from communicating more than once over the mobile network. Connection between the devices is not re-established.
Reproduce:
1. Two devices with connected contacts, A and B
2. Using only the mobile network, A chats with B and vice versa.
3. Close Briar and "lock" both devices by pressing the power button (don't turn off).
4. Unlock both devices after ~60 seconds (I think the timeout is set at 30 seconds) and try to chat with both A and B. Notice that no messages will be received by the other user and the "clock" symbol remains indefinitely in place.
You can re-establish connection by turning on WiFi on both devices or bluetooth and notice that then the messages are sent instantly.
Following is the error message that I got:
`
java.net.SocketTimeoutException
at java.net.PlainSocketImpl.read(PlainSocketImpl.java:488)
at java.net.PlainSocketImpl.access$000(PlainSocketImpl.java:37)
at java.net.PlainSocketImpl$PlainSocketInputStream.read(PlainSocketImpl.java:237)
at org.briarproject.crypto.StreamDecrypterImpl.readFrame(StreamDecrypterImpl.java:57)
at org.briarproject.transport.StreamReaderImpl.readFrame(StreamReaderImpl.java:61)
at org.briarproject.transport.StreamReaderImpl.read(StreamReaderImpl.java:49)
at org.briarproject.sync.PacketReaderImpl.readPacket(PacketReaderImpl.java:54)
at org.briarproject.sync.PacketReaderImpl.eof(PacketReaderImpl.java:78)
at org.briarproject.sync.IncomingSession.run(IncomingSession.java:56)
at org.briarproject.plugins.ConnectionManagerImpl$ManageIncomingDuplexConnection.run(ConnectionManagerImpl.java:267)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at java.lang.Thread.run(Thread.java:818)
`Milestone Cakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/268Research how to deal with doze mode on Android 62019-02-21T10:34:00ZakwizgranResearch how to deal with doze mode on Android 6Android 6 has a new doze mode when the device is idle. Apps can't access the network in doze mode, except during short wakeup periods. This will kill our ability to receive messages while the device is idle. The recommended workaround is...Android 6 has a new doze mode when the device is idle. Apps can't access the network in doze mode, except during short wakeup periods. This will kill our ability to receive messages while the device is idle. The recommended workaround is to use Google Cloud Messaging, which obviously won't work for us.
We may need to prompt the user to add Briar to a whitelist. Thanks Google! Love ya!
http://developer.android.com/training/monitoring-device-state/doze-standby.htmlAndroid 1.1akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/185Toggle Transport States2020-09-04T12:27:54ZTorsten GroteToggle Transport StatesIt would be great to be able to enable/disable transports by touching the icons in the dashboard.
For this, we should have three states for plugins:
* disabled
* enabled
* ready
that could be shown as grey, amber and green icons.It would be great to be able to enable/disable transports by touching the icons in the dashboard.
For this, we should have three states for plugins:
* disabled
* enabled
* ready
that could be shown as grey, amber and green icons.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/60Close idle transport connections2020-11-21T20:16:40ZakwizgranClose idle transport connectionsFor some transports keeping a connection open is expensive (especially if we're sending padding) -- but for other transports creating a new connection may be expensive. Idle connections should be closed after a transport-dependent amount...For some transports keeping a connection open is expensive (especially if we're sending padding) -- but for other transports creating a new connection may be expensive. Idle connections should be closed after a transport-dependent amount of time.https://code.briarproject.org/briar/briar/-/issues/44Reduce battery consumption2022-11-02T18:28:35ZakwizgranReduce battery consumptionSeveral users reported that Briar used an excessive amount of battery power. They identified it as the single most important issue that would prevent them from regularly using the app.
Polling for connections to contacts is probably the...Several users reported that Briar used an excessive amount of battery power. They identified it as the single most important issue that would prevent them from regularly using the app.
Polling for connections to contacts is probably the biggest single factor here.https://code.briarproject.org/briar/briar/-/issues/37Optionally disable Tor when using mobile data2018-04-30T15:55:35ZakwizgranOptionally disable Tor when using mobile dataUsers may want to save bandwidth and battery by disabling Tor when they're using mobile data. We can detect this using the same events that we use to detect loss of connectivity.Users may want to save bandwidth and battery by disabling Tor when they're using mobile data. We can detect this using the same events that we use to detect loss of connectivity.Milestone ASantiago Torres-AriasSantiago Torres-Arias