briar issueshttps://code.briarproject.org/groups/briar/-/issues2020-11-15T18:21:38Zhttps://code.briarproject.org/briar/briar/-/issues/1574Consider separating the package structures for bramble-java and bramble-core2020-11-15T18:21:38ZiwakehConsider separating the package structures for bramble-java and bramble-coreConsider using a separate package for ```bramble-java``` (e.g. ```org.briarproject.bramble.java.*```)
Currently, ```bramble-java``` provides the same packages as ```bramble-core```.
Some ```bramble-java``` classes extend package-private...Consider using a separate package for ```bramble-java``` (e.g. ```org.briarproject.bramble.java.*```)
Currently, ```bramble-java``` provides the same packages as ```bramble-core```.
Some ```bramble-java``` classes extend package-private classes from ```bramble-core``` (mostly in bluetooth). Hmm ....
When briar is going to use java >= 9 and provides modules this needs to be addressed anyway.
(I believe briar should be around for many, many new java versions to come ;-)https://code.briarproject.org/briar/briar/-/issues/1569Connection manager could fail to close connection2020-11-15T18:24:37ZakwizgranConnection manager could fail to close connectionWhen the connection manager disposes of the incoming side of a duplex connection, it interrupts the outgoing sync session (if any) so the outgoing session can finish cleanly. If this happens before the outgoing session is created, it won...When the connection manager disposes of the incoming side of a duplex connection, it interrupts the outgoing sync session (if any) so the outgoing session can finish cleanly. If this happens before the outgoing session is created, it won't be interrupted.
If the incoming side of the connection is being disposed of because of an exception then the transport connection will be closed, so the outgoing session should eventually catch an exception when it tries to write to the connection. But if the incoming side of the connection is being disposed of because the end of the stream was reached then the transport connection will be left half-open, so the outgoing session could keep running indefinitely. This might also happen in the case of an exception if there's nothing to send and the transport doesn't require keepalives, which is the case for Bluetooth.
This could result in a dangling connection that's only usable in one direction. As far as I can tell it won't prevent a new connection from being made, or cause issues like !921, because the registration and unregistration of duplex connections is based on the lifetime of the incoming session, not the outgoing session.
The opposite can also happen: if the connection manager disposes of the outgoing side of the connection before the incoming session is created, the incoming session won't be interrupted. This can only happen if an exception has been thrown (in which case the transport connection will be closed, which *should* cause the incoming session to catch an exception eventually), or if the outgoing session has finished cleanly, which only happens if it's interrupted due to the incoming side of the connection being disposed of. So the only possible cause of a bug like !921 in this case would be if closing the connection didn't cause the incoming session to catch an exception (flaky Bluetooth stacks, I'm looking at you).
Labelling this as a bug because it's unintended behaviour, although it's not clear if we need to fix it.https://code.briarproject.org/briar/briar/-/issues/1568Test the effects of dormant mode when operating as a Tor client2020-11-15T18:26:32ZakwizgranTest the effects of dormant mode when operating as a Tor clientTest whether a Briar peer that's not running a hidden service or holding a wake lock can operate as a Tor client (i.e. connect to contacts' hidden services and fetch RSS feeds), and whether this is affected by Tor's dormant mode.Test whether a Briar peer that's not running a hidden service or holding a wake lock can operate as a Tor client (i.e. connect to contacts' hidden services and fetch RSS feeds), and whether this is affected by Tor's dormant mode.https://code.briarproject.org/briar/briar/-/issues/1563DozeView disappears when rotating screen after whitelisting Briar2020-11-15T18:27:59ZakwizgranDozeView disappears when rotating screen after whitelisting BriarSteps to reproduce:
* Use a device with Android 6+
* Ensure Briar isn't whitelisted for doze
* Create a new account
* In the power management setup screen, tap "Allow Connections" and accept the dialog
* Rotate the screen
* Expected: The...Steps to reproduce:
* Use a device with Android 6+
* Ensure Briar isn't whitelisted for doze
* Create a new account
* In the power management setup screen, tap "Allow Connections" and accept the dialog
* Rotate the screen
* Expected: The layout stays the same
* Actual: The "Allow Connections" button (with its check mark and help button) disappears
* Use the back button to return to the password setup screen
* Expected: The layout is the same as before
* Actual: The "Next" button changes to "Create Account"
The unexpected layout changes happen because we re-check whether we're whitelisted.
If the fragment instances are retained across rotations, perhaps the password and doze fragments could remember the whitelisting state when they were first created, and use that to control the text of the password fragment's "Next" / "Create Account" button and the visibilty of DozeView, so that they stay the same after we're whitelisted, while using the current whitelisting state to show/hide the "Allow Connections" button's check mark and enable/disable the power management fragment's "Create Account" button, which are the bits that are supposed to change when we're whitelisted.https://code.briarproject.org/briar/briar/-/issues/1559Avoid using third parties' resources for testing and maybe enable offline tes...2020-11-15T18:28:22ZiwakehAvoid using third parties' resources for testing and maybe enable offline testing```testFeedImportAndRemoval``` uses a third party blog feed for testing.
1) Maybe, rather use briar's own resources instead of Schneier's blog, e.g. simply supply a static test feed on briarproject's server or use https://code.briarproj...```testFeedImportAndRemoval``` uses a third party blog feed for testing.
1) Maybe, rather use briar's own resources instead of Schneier's blog, e.g. simply supply a static test feed on briarproject's server or use https://code.briarproject.org/briar/briar.atom.
2) This way of testing will fail when the testing machine is offline, which is not the aim of the test. So, avoiding internet access here might be a better solution and would also support to introduce test cases for feed content that could trip briar functionality.https://code.briarproject.org/briar/briar/-/issues/1558ViewModelModule is breaking package encapsulation2021-04-30T13:38:33ZTorsten GroteViewModelModule is breaking package encapsulationThe ViewModelModule is breaking package encapsulation. Let's refactor the ViewModel bindings into the respective packages and cleaning them up.The ViewModelModule is breaking package encapsulation. Let's refactor the ViewModel bindings into the respective packages and cleaning them up.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()`https://code.briarproject.org/briar/briar/-/issues/1553Option to revert screen filter setting2020-11-15T18:32:09ZakwizgranOption to revert screen filter settingA user asked for the ability to revert the decision to allow certain apps to draw on top of Briar.A user asked for the ability to revert the decision to allow certain apps to draw on top of Briar.https://code.briarproject.org/briar/briar/-/issues/1550Relay encrypted messages between contacts2020-11-15T18:44:35ZakwizgranRelay encrypted messages between contactsSeveral users have suggested that Briar should relay encrypted messages between contacts, so that users who can't communicate directly can pass messages through mutual contacts.
This would have implications for battery and bandwidth con...Several users have suggested that Briar should relay encrypted messages between contacts, so that users who can't communicate directly can pass messages through mutual contacts.
This would have implications for battery and bandwidth consumption. If message propagation was restricted then it would also have privacy implications (Alice could see that Bob and Carol were both sending messages at 3am, when nobody else was sending anything). If message propagation was unrestricted then the battery and bandwidth impact would be hard to control - this would affect scalability and enable flooding attacks. Fair queueing might help to mitigate flooding attacks (#511).
One user suggested that the privacy impact could be mitigated through fine-grained controls (e.g. Bob and Carol would only choose Alice to relay their messages if they didn't mind her knowing when they were communicating). I'm skeptical about whether most people can predict and manage their privacy needs at that granularity in advance, but I could be wrong.https://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/1548Chat with Tor Browser users via hidden service2020-11-15T18:45:55ZakwizgranChat with Tor Browser users via hidden serviceUser feedback: "It would be a realy cool feature for Briar if one could generate a .onion link that one can share over another channel (basically like OnionShare), that would then open a text chat in the Tor Browser to allow communicatio...User feedback: "It would be a realy cool feature for Briar if one could generate a .onion link that one can share over another channel (basically like OnionShare), that would then open a text chat in the Tor Browser to allow communication with other platforms than Android."https://code.briarproject.org/briar/briar/-/issues/1544AMOLED dark theme2021-09-23T12:30:59ZakwizgranAMOLED dark themeA user asked for an AMOLED dark theme (i.e. based on pure black).
Related to #976.A user asked for an AMOLED dark theme (i.e. based on pure black).
Related to #976.https://code.briarproject.org/briar/briar/-/issues/1543Make sign-in reminder more prominent2020-11-15T18:50:15ZakwizgranMake sign-in reminder more prominentUser feedback: "Please consider making the sign-in notification more prominent after restart. Sometimes I forget I'm not signed in for hours or even days, a more visible reminder would really help. Splash page after restart maybe?"
Poss...User feedback: "Please consider making the sign-in notification more prominent after restart. Sometimes I forget I'm not signed in for hours or even days, a more visible reminder would really help. Splash page after restart maybe?"
Possibly related to #1458.https://code.briarproject.org/briar/briar/-/issues/1542Pinned posts2020-11-15T18:51:08ZakwizgranPinned postsA user asked for the ability to pin posts in private groups and forums.
Related to #880.A user asked for the ability to pin posts in private groups and forums.
Related to #880.https://code.briarproject.org/briar/briar/-/issues/1541Allow users to create polls2020-11-15T18:52:19ZakwizgranAllow users to create pollsA user asked for the ability to create polls in groups, blogs and forums.
This would be pretty easy to implement at the client layer, by adding "poll" and "vote" message types, where a vote message depends on a poll message, indicates o...A user asked for the ability to create polls in groups, blogs and forums.
This would be pretty easy to implement at the client layer, by adding "poll" and "vote" message types, where a vote message depends on a poll message, indicates one of the options in the poll message, and is signed by the voter. The client would use metadata attached to the poll message to count votes and apply rules for situations like an identity voting for multiple options (whether this is valid [depends on the voting system!](https://en.wikipedia.org/wiki/Approval_voting)).
I think this feature would make the most sense for private groups. Forums don't have any limit on which identities can take part, so vote stuffing would be easy. Blogs have the same issue, and allowing subscribers to send vote messages would remove one of the nice security properties of blogs, which is that subscribers have no way to DoS a blog because only the owner can post messages.https://code.briarproject.org/briar/briar/-/issues/1540Make it easier to find the changelog2020-05-09T15:15:42ZakwizgranMake it easier to find the changelogUser feedback: "Please provide change logs that are easily accessible."
Perhaps we should link to the changelog from the website and/or include it in the app.
Related to #1312.User feedback: "Please provide change logs that are easily accessible."
Perhaps we should link to the changelog from the website and/or include it in the app.
Related to #1312.https://code.briarproject.org/briar/briar/-/issues/1539Retrieving the onion address of a specific contact2020-11-15T18:54:25ZalexRetrieving the onion address of a specific contactHello;
This is more a question than an issue, and it will help many others develop this app.
I was looking for very long hours, for the onion address of the target contact when sending a message.
I followed the 'createMessage()' method ...Hello;
This is more a question than an issue, and it will help many others develop this app.
I was looking for very long hours, for the onion address of the target contact when sending a message.
I followed the 'createMessage()' method and it's usage/declaration but found no clue .
I/WE will be very grateful if you show us the location of these onion addresses to where the packets are sent to;
and how to retrieve them.
Thank you for your time , and again, this is gonna help us develop new features and finally commit them.https://code.briarproject.org/briar/briar/-/issues/1533support Netguard2020-11-15T18:55:42Zbillfromisletasupport NetguardIssue #1284 and #1400 make it clear that users have trouble trusting whether Briar is not leaking on the clearnet. It raises some questions:
* what happens if Orbot is not installed?
* how does Briar work if Tor is enabled and also Net...Issue #1284 and #1400 make it clear that users have trouble trusting whether Briar is not leaking on the clearnet. It raises some questions:
* what happens if Orbot is not installed?
* how does Briar work if Tor is enabled and also Netguard is using transparent proxying to force Briar packets over Tor? On a desktop system, such a scenario would break because the app would be trying to connect to 127.0.0.1:9050 on the WAN. But on Android it functions, which seems to imply that Netguard is being bypassed.
Netguard's *lockdown mode* does not work on Briar apparently because Netguard is being bypassed. If Briar supported a non-Tor configuration, then users could use Netguard to force it over Tor and automatically have more confidence that there are likely no leaks. Although I don't know if netguard and orbot can handle whatever onion addressing Briar uses.https://code.briarproject.org/briar/briar/-/issues/1531Update threat model document2020-11-15T18:57:13ZakwizgranUpdate threat model documentThe [threat model document](https://code.briarproject.org/briar/briar/wikis/threat-model) on the wiki is out of date, and it doesn't mention the goal of concealing the fact that Briar is being used. The document should be updated.The [threat model document](https://code.briarproject.org/briar/briar/wikis/threat-model) on the wiki is out of date, and it doesn't mention the goal of concealing the fact that Briar is being used. The document should be updated.CleopatraCleopatrahttps://code.briarproject.org/briar/briar/-/issues/1525IllegalThreadStateException when starting contact exchange task2021-11-04T11:03:43ZakwizgranIllegalThreadStateException when starting contact exchange task* Android version: 8.1.0
* Briar version: 1.1.5 (8f4c3c4)
* Phone model: OnePlus A0001 (bacon)
* User feedback: "Tried to connect @ 35C3 during the event."
Stacktrace:
```
java.lang.IllegalThreadStateException
at java.lang.Threa...* Android version: 8.1.0
* Briar version: 1.1.5 (8f4c3c4)
* Phone model: OnePlus A0001 (bacon)
* User feedback: "Tried to connect @ 35C3 during the event."
Stacktrace:
```
java.lang.IllegalThreadStateException
at java.lang.Thread.start(Thread.java:724)
at org.briarproject.bramble.contact.ContactExchangeTaskImpl.startExchange(ContactExchangeTaskImpl.java:113)
at org.briarproject.briar.android.keyagreement.ContactExchangeActivity.lambda$startContactExchange$0(ContactExchangeActivity.java:66)
at org.briarproject.briar.android.keyagreement.-$$Lambda$ContactExchangeActivity$fyog59L3yYwzJYBvp0hzYrpHYRo.run(Unknown Source:4)
at org.briarproject.briar.android.controller.DbControllerImpl.lambda$runOnDbThread$0(DbControllerImpl.java:35)
at org.briarproject.briar.android.controller.-$$Lambda$DbControllerImpl$SwC9ndeQwlnMM-VN8yvqCJG1ESc.run(Unknown Source:4)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
```
This exception is thrown if start() is called when the thread isn't in the initial state. A couple of guesses about how this could have happened:
* A ContactExchangeTask instance was reused across multiple contacts
* A ContactExchangeActivity instance received multiple KeyAgreementFinishedEvents, possibly relating to different contacts, each of which cause it to start its ContactExchangeTask
Assigning to myself as I'm refactoring this code for remote contacts.Android 1.4