briar issueshttps://code.briarproject.org/groups/briar/-/issues2017-09-20T12:08:42Zhttps://code.briarproject.org/briar/briar/-/issues/1024NPE when opening group: MessageTreeImpl.parseNode()2017-09-20T12:08:42ZTorsten GroteNPE when opening group: MessageTreeImpl.parseNode()This was while testing notifications with lots of new messages. When I go into the same group after the crash, it doesn't crash again. This might suggest some concurrency issue.
```
08-01 12:34:40.882 E/ACRA: ACRA caught a NullPointerEx...This was while testing notifications with lots of new messages. When I go into the same group after the crash, it doesn't crash again. This might suggest some concurrency issue.
```
08-01 12:34:40.882 E/ACRA: ACRA caught a NullPointerException for org.briarproject.briar.beta
java.lang.NullPointerException
at org.briarproject.briar.client.MessageTreeImpl.parseNode(MessageTreeImpl.java:70)
at org.briarproject.briar.client.MessageTreeImpl.add(MessageTreeImpl.java:48)
at org.briarproject.briar.client.MessageTreeImpl.add(MessageTreeImpl.java:55)
at org.briarproject.briar.android.threaded.NestedTreeList.add(NestedTreeList.java:28)
at org.briarproject.briar.android.threaded.ThreadItemAdapter.add(ThreadItemAdapter.java:88)
at org.briarproject.briar.android.threaded.ThreadListActivity.addItem(ThreadListActivity.java:405)
at org.briarproject.briar.android.threaded.ThreadListActivity$9.onResultUi(ThreadListActivity.java:388)
at org.briarproject.briar.android.threaded.ThreadListActivity$9.onResultUi(ThreadListActivity.java:385)
at org.briarproject.briar.android.controller.handler.UiResultExceptionHandler$1.run(UiResultExceptionHandler.java:24)
at org.briarproject.briar.android.activity.BaseActivity$1.run(BaseActivity.java:140)
```Android Beta 2akwizgranakwizgranhttps://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/923Tester expected contact to be added immediately after accepting introduction2018-12-19T12:22:16ZakwizgranTester expected contact to be added immediately after accepting introductionA tester expected that when she accepted an introduction the contact would be added to her contact list immediately. She didn't understand that the introducer was waiting for the other introducee's response.A tester expected that when she accepted an introduction the contact would be added to her contact list immediately. She didn't understand that the introducer was waiting for the other introducee's response.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/922Emoji in forum and group names2020-11-19T15:24:18ZakwizgranEmoji in forum and group namesA tester asked to be able to use emoji in forum and group names. (This is possible with an emoji keyboard, but not otherwise.)A tester asked to be able to use emoji in forum and group names. (This is possible with an emoji keyboard, but not otherwise.)https://code.briarproject.org/briar/briar/-/issues/921Contact seemed to remain online after phone was reused2020-11-19T15:25:24ZakwizgranContact seemed to remain online after phone was reusedThis issue arose in user testing when one of the devices was reused by another tester.
User A with device X and user B with device Y added each other as contacts. Then user C took over device Y and created a new account. User A continue...This issue arose in user testing when one of the devices was reused by another tester.
User A with device X and user B with device Y added each other as contacts. Then user C took over device Y and created a new account. User A continued to see user B as online.
This may have been caused by a Bluetooth channel remaining open between the devices, causing user A to think that a connection to user B was still open. Perhaps a subsequent connection between user A and user C either reused the channel or otherwise caused it to remain open rather than timing out, or perhaps the Bluetooth stack on device X simply doesn't time out connections in a reasonable time.
If any of those speculations are right, we should work out how to avoid relying on Bluetooth to time out the connection and time out after a reasonable time in the Bramble stack instead.
We should also check that Bluetooth connections are being disposed of properly when they're closed.https://code.briarproject.org/briar/briar/-/issues/920Transfer ownership of a private group2022-11-18T17:24:07ZakwizgranTransfer ownership of a private groupA tester asked for the ability to transfer the ownership of a private group to another member.
This might not be possible with the current structure, because not all members might be contacts of the new owner, or might not wish to revea...A tester asked for the ability to transfer the ownership of a private group to another member.
This might not be possible with the current structure, because not all members might be contacts of the new owner, or might not wish to reveal whether they were.https://code.briarproject.org/briar/briar/-/issues/918Voting or consensus for inviting a new member to a private group2021-01-13T11:59:11ZakwizgranVoting or consensus for inviting a new member to a private groupA user suggested this in a recent testing session.A user suggested this in a recent testing session.https://code.briarproject.org/briar/briar/-/issues/917Testers did not understand who could be invited to private groups2020-11-19T15:34:00ZakwizgranTesters did not understand who could be invited to private groupsTesters asked whether they could invite users who weren't their contacts to a group, and whether an invited member could invite her contacts. They eventually worked out what was possible but were initially confused.
Related to #801, #81...Testers asked whether they could invite users who weren't their contacts to a group, and whether an invited member could invite her contacts. They eventually worked out what was possible but were initially confused.
Related to #801, #811 and #855.https://code.briarproject.org/briar/briar/-/issues/902Improve key binding in introduction protocol2018-03-29T12:53:22ZakwizgranImprove key binding in introduction protocolThe introduction protocol provides the following guarantees:
* Each introducee knows that the ephemeral and identity public keys she received are owned by the other introducee
* Each introducee knows that the ephemeral and identity p...The introduction protocol provides the following guarantees:
* Each introducee knows that the ephemeral and identity public keys she received are owned by the other introducee
* Each introducee knows that the ephemeral and identity public keys she received were used by the other introducee in the same run of the protocol - in other words it binds each introducee's ephemeral key pair to the same introducee's identity key pair and vice versa
* Each introducee knows that the ephemeral public key she received was used by the other introducee in the current run of the protocol - in other words it binds the introducees' ephemeral key pairs to each other
Unlike the contact exchange protocol, the introduction protocol does not verify the personal identity of the other introducee. The other introducee may be a persona presented by the introducer as part of a man-in-the-middle attack. However, the introduction protocol guarantees that if an introducee later verifies that a person owns the identity public key she received, that person also owns the ephemeral public key she received, and no man-in-the-middle attack took place.
To achieve this, each introducee uses her identity key pair to sign a nonce derived from the ephemeral shared secret, and authenticates her identity key pair using a symmetric key derived from the ephemeral shared secret.
Each introducee knows that the nonce she received is fresh, as it depends on her own ephemeral key pair, so the nonce itself proves that the other introducee owns the ephemeral public key received by the first introducee, while the signature proves that the other introducee owns the identity public key received by the first introducee.
The nonce is unique to this combination of ephemeral key pairs, so the signature represents a claim by the owner of the received identity public key that she took part in a protocol run involving both ephemeral key pairs. Authenticating the identity public key with a symmetric key derived from the ephemeral shared secret represents a claim by the owner of the received ephemeral public keys that she took part in a protocol run involving both ephemeral key pairs and the identity key pair.
As far as I can tell, this construction is secure and achieves what we need, but it's unnecessarily convoluted. The binding and proof of ownership that's achieved by signing nonces could be achieved more straightforwardly by signing public keys:
* Each introducee signs both introducees' ephemeral public keys and timestamps using her identity key pair
* Each introducee authenticates both introducees' identity public keys, ephemeral public keys and timestamps, using a symmetric key derived from the ephemeral shared secret
If we're not concerned with deniability, each introducee can sign both introducees' identity public keys, ephemeral public keys and timestamps. But as far as I can see, we get all the assurance we need without doing this.
Related to #901.Android 1.0https://code.briarproject.org/briar/briar/-/issues/901Improve key binding in contact exchange protocol2020-11-19T15:35:33ZakwizgranImprove key binding in contact exchange protocolThe contact exchange protocol provides the following guarantees:
* Each party knows that the ephemeral and identity public keys she received are owned by the other party
* Each party knows that the ephemeral and identity public keys she ...The contact exchange protocol provides the following guarantees:
* Each party knows that the ephemeral and identity public keys she received are owned by the other party
* Each party knows that the ephemeral and identity public keys she received were used by the other party in the same run of the protocol - in other words it binds each party's ephemeral key pair to the same party's identity key pair and vice versa
* Each party knows that the ephemeral public key she received was used by the other party in the current run of the protocol - in other words it binds the parties' ephemeral key pairs to each other
To achieve this, each party uses her identity key pair to sign a nonce derived from the ephemeral shared secret, and authenticates the signed nonce using a symmetric key derived from the ephemeral shared secret.
Each party knows that the nonce she received is fresh, as it depends on her own ephemeral key pair, so the nonce itself proves that the other party owns the ephemeral public key received by the first party, while the signature proves that the other party owns the identity public key received by the first party.
The nonce is unique to this combination of ephemeral key pairs, so the signature represents a claim by the owner of the received identity public key that she took part in a protocol run involving both ephemeral key pairs. Authenticating the signed nonce with a symmetric key derived from the ephemeral shared secret represents a claim by the owner of the received ephemeral public keys that she took part in a protocol run involving both ephemeral key pairs and the identity key pair.
As far as I can tell, this construction is secure and achieves what we need, but it's unnecessarily convoluted. The binding and proof of ownership that's achieved by signing nonces could be achieved more straightforwardly by signing public keys:
* Each party signs both parties' ephemeral public keys and timestamps using her identity key pair
* Each party authenticates both parties' identity public keys, ephemeral public keys and timestamps, using a symmetric key derived from the ephemeral shared secret
If we're not concerned with deniability, each party can sign both parties' identity public keys, ephemeral public keys and timestamps. But as far as I can see, we get all the assurance we need without doing this.
Related to #902.https://code.briarproject.org/briar/briar/-/issues/899Forum subtitle is not updated when contact joins/leaves2019-02-27T10:24:27ZakwizgranForum subtitle is not updated when contact joins/leavesThe sharing information in the forum subtitle isn't updated when the number of contacts the forum is shared with changes due to a contact joining or leaving the forum.The sharing information in the forum subtitle isn't updated when the number of contacts the forum is shared with changes due to a contact joining or leaving the forum.https://code.briarproject.org/briar/briar/-/issues/898Invitations to our own blog should be rejected2020-11-20T11:22:52ZakwizgranInvitations to our own blog should be rejectedThe validator or delivery hook should check whether an invite message refers to our own blog, and if so, consider it invalid.The validator or delivery hook should check whether an invite message refers to our own blog, and if so, consider it invalid.https://code.briarproject.org/briar/briar/-/issues/897Reply button of received forum post doesn't work after using scroll button2019-02-27T10:32:40ZakwizgranReply button of received forum post doesn't work after using scroll buttonSteps to reproduce:
* Create a forum with a screenful of posts, shared between devices A and B
* Write a new top-level post on device A
* When the post is received on device B, use the scroll button to show it
* Try to reply to the post ...Steps to reproduce:
* Create a forum with a screenful of posts, shared between devices A and B
* Write a new top-level post on device A
* When the post is received on device B, use the scroll button to show it
* Try to reply to the post on device B - the reply button doesn't work
If I scroll to the post manually rather than using the scroll button, the reply button works. The reply button works on device A (where the post was written). It can be made to work on device B by touching the reply button on another post, backing out, then touching the reply button on the new post.https://code.briarproject.org/briar/briar/-/issues/896Use dependencies to deliver transport property updates in order2017-12-15T13:08:23ZakwizgranUse dependencies to deliver transport property updates in orderThis will allow us to remove the buggy message queue.This will allow us to remove the buggy message queue.https://code.briarproject.org/briar/briar/-/issues/895Save unsent text input as draft when screen left and restore it when reentered2021-11-09T12:13:51ZTorsten GroteSave unsent text input as draft when screen left and restore it when reenteredPeople are used from other messengers to their unsent text being saved when they leave a conversation and have it restored when they reenter it.
Briar currently just drops this text and loses it for the user.People are used from other messengers to their unsent text being saved when they leave a conversation and have it restored when they reenter it.
Briar currently just drops this text and loses it for the user.https://code.briarproject.org/briar/briar/-/issues/888Use consistent language for forum posts2018-12-19T12:25:32ZakwizgranUse consistent language for forum postsPosts should be called posts in the UI, not entries or items.Posts should be called posts in the UI, not entries or items.https://code.briarproject.org/briar/briar/-/issues/887Support for multiple devices2022-11-13T20:46:18ZakwizgranSupport for multiple devicesThis is an umbrella ticket for organising ideas about how we might support multiple devices.This is an umbrella ticket for organising ideas about how we might support multiple devices.https://code.briarproject.org/briar/briar/-/issues/886New workflow for adding contacts via QR codes2020-11-19T15:51:59ZakwizgranNew workflow for adding contacts via QR codesTesters have had trouble with the QR code workflow in the past. Some testers expected to be able to add multiple contacts by scanning a series of QR codes. We can get closer to meeting this expectation by dividing the workflow into two p...Testers have had trouble with the QR code workflow in the past. Some testers expected to be able to add multiple contacts by scanning a series of QR codes. We can get closer to meeting this expectation by dividing the workflow into two phases: scanning and showing.
In the scanning phase, the user scans any number of QR codes. In the background, her device connects to each scanned device and delivers a contact request. If the scanned device has already sent a contact request to the scanning device, the devices proceed with contact exchange.
In the showing phase, the user's device shows a QR code for other users to scan. A snackbar shows incoming contact requests. Touching the snackbar opens a list of contact requests sent, received and completed. Received requests are marked "scan to confirm". Touching a received request opens the scanning screen.
Pending requests are also indicated by a snackbar at the bottom of the contact list, so the user can leave the contact exchange feature to deal with other tasks, then come back and continue adding contacts.
Separating the initial contact request from the subsequent contact exchange allows users to scan each other's codes in any order. The list of contact requests allows them to keep track of which contacts need to be confirmed.https://code.briarproject.org/briar/briar/-/issues/880Forum topics2020-11-19T15:54:25ZakwizgranForum topicsThis is a suggestion for a different way to organise forum threads.
Each top-level post starts a new topic. The author picks a subject line for the topic. Descendents of the post that started the topic don't have subject lines of their ...This is a suggestion for a different way to organise forum threads.
Each top-level post starts a new topic. The author picks a subject line for the topic. Descendents of the post that started the topic don't have subject lines of their own.
Within each forum, we show a list of topics. These can be sorted by recent activity, so inactive topics fall to the bottom. Subject lines provide a summary of the topics currently being discussed. The user can open an existing topic or start a new topic. Within each topic we show a threaded view like the one we currently use for the forum as a whole.
The aim is to allow parallel conversations to happen within a single forum, while making it easy to navigate between different conversations or focus on the most interesting ones. Subject lines make it easy to collapse inactive conversations down to a summary.
The main disadvantage is adding another level of navigation. The distinction between the forum list and the topic list might not be clear.https://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.