briar issueshttps://code.briarproject.org/groups/briar/-/issues2020-11-21T19:02:14Zhttps://code.briarproject.org/briar/briar/-/issues/368Simplify Dagger providers2020-11-21T19:02:14ZakwizgranSimplify Dagger providersThe Dagger modules have a lot of methods like this:
```
@Provides
Foo provideFoo(Bar bar, Baz baz, Bam bam, Qux qux) {
return new FooImpl(bar, baz, bam, qux);
}
```
This can be simplified, making it easier to maintain:
```
@Provides
...The Dagger modules have a lot of methods like this:
```
@Provides
Foo provideFoo(Bar bar, Baz baz, Bam bam, Qux qux) {
return new FooImpl(bar, baz, bam, qux);
}
```
This can be simplified, making it easier to maintain:
```
@Provides
Foo provideFoo(FooImpl foo) {
return foo;
}
````https://code.briarproject.org/briar/briar/-/issues/365Reuse contact exchange protocol for Bluetooth and QR codes2018-06-12T11:32:28ZakwizgranReuse contact exchange protocol for Bluetooth and QR codesRelated to #256.Related to #256.Milestone Dhttps://code.briarproject.org/briar/briar/-/issues/364Introduction responses should be signed2018-06-12T11:32:28ZakwizgranIntroduction responses should be signedIn the direct contact protocol, the parties don't directly sign the identity public keys, transport properties or timestamps. Instead, each party signs a nonce derived from the key exchange protocol's master key. This provides a degree o...In the direct contact protocol, the parties don't directly sign the identity public keys, transport properties or timestamps. Instead, each party signs a nonce derived from the key exchange protocol's master key. This provides a degree of deniability: the remote party obtains a fresh signature from the local party, but can't prove to a third party without help from the local party that the signature included input from the remote party, and thus that the local and remote parties are contacts.
If we directly sign the identity public keys, transport properties and timestamps in the introduction protocol, we'll lose deniability for introduced contacts. Cryptographic deniability isn't one of our design goals, so that's acceptable. But I'd like to explore whether a similar construction to the direct contact protocol would work here.
Subtask of #256.
# Description of protocol
The format of the response message is unchanged. Two fields are added to the ack message: a signature and a MAC.
Immediately before the local introducee sends her ack (which may happen either when she receives the remote introducee's response or when she makes her own decision, whichever happens later), she derives a master key from the ephemeral shared secret. Two nonces and a MAC key are derived from the master key. The local introducee signs one of the nonces and calculates a MAC over her own identity public key, ephemeral public key, transport properties and timestamp. The local introducee includes the signature and MAC in her ack.
On receiving the remote introducee's ack, the local introducee verifies the signature and MAC.
# Security goals
The local introducee doesn't know whether each piece of information received from the introducer originates from the remote introducee or has been replaced by the introducer, i.e. whether the introducer is carrying out a man-in-the-middle attack. The introduction protocol doesn't aim to detect or prevent man-in-the-middle attacks. We only aim to establish that if the remote identity public key is not replaced then the remote ephemeral public key, transport properties and timestamp are not replaced either. Later, when the local introducee verifies that the remote identity public key belongs to a particular person, she can also be sure that the remote ephemeral public key, transport properties and timestamp originated from that person.
# Security argument
We assume that signatures reveal what was signed, so the introducer learns the nonces.
The master key is only known to the local introducee and whoever knows the remote ephemeral private key.
The master key includes input from the local party, so it is fresh, i.e. it has not been replayed.
Verifying the signature proves that the originator of the signature knows the corresponding identity private key: the master key is fresh, so the nonce is fresh, so the signature is fresh.
Replacing the signature would require replacing the identity public key, and vice versa.
Replacing the ephemeral public key would require replacing the MAC, and vice versa.
Replacing the ephemeral public key would produce a different nonce, and would therefore require replacing the signature (but not vice versa).
Replacing the transport properties or timestamp would require replacing the MAC (but not vice versa).
So if the introducer doesn't replace the identity public key, she can't replace the signature, so she can't replace the ephemeral public key, so she can't replace the MAC, so she can't replace the transport properties or timestamp.
# Authenticating negative responses
Negative responses are not authenticated, so the introducer can falsely claim that the remote introducee declined. This is consistent with what we show in the UI, i.e. "Alice says that Bob declined the introduction".
If we want to authenticate negative responses in future, we'll have to add extend the protocol as follows:
* Response message includes an ephemeral public key regardless of whether the response is accept or decline
* Ack message is sent regardless of whether the response is accept or decline
* If the response is accept, the MAC is calculated over the response, identity public key, ephemeral public key, transport properties and timestamp
* If the response is decline, the MAC is calculated over the response, identity public key and ephemeral public key
Milestone BTorsten GroteTorsten Grote2016-08-31https://code.briarproject.org/briar/briar/-/issues/342Organise strings.xml to make life easier for translators2018-01-28T11:30:28ZakwizgranOrganise strings.xml to make life easier for translatorsGroup the strings according to where they appear in the app so that translators can see the context in which each string is used. We'll also need a section for strings that appear in multiple places, such as dialog button labels.
Subt...Group the strings according to where they appear in the app so that translators can see the context in which each string is used. We'll also need a section for strings that appear in multiple places, such as dialog button labels.
Subtask of #341.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/341Co-ordinate initial translations2018-06-12T11:32:29ZakwizgranCo-ordinate initial translationsMilestone Dhttps://code.briarproject.org/briar/briar/-/issues/339Forum Sharing Integration Tests2018-06-12T11:32:29ZTorsten GroteForum Sharing Integration TestsMilestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/338Assign parents to activities2020-11-21T19:06:06ZakwizgranAssign parents to activitiesMost activities are currently using NavDrawerActivity as their parent. Pick an appropriate parent for each activity and update the manifest.Most activities are currently using NavDrawerActivity as their parent. Pick an appropriate parent for each activity and update the manifest.https://code.briarproject.org/briar/briar/-/issues/337Avatar Placeholders for Forums2018-06-12T11:32:29ZTorsten GroteAvatar Placeholders for ForumsTo make forums visually more pleasing, they should have avatars that use the first letter of their name and a deterministically chosen color as a background. Here's a mockup:
![avatars](https://code.briarproject.org/akwizgran/briar/up...To make forums visually more pleasing, they should have avatars that use the first letter of their name and a deterministically chosen color as a background. Here's a mockup:
![avatars](https://code.briarproject.org/akwizgran/briar/uploads/7c7eb7eb7029c015bc2ed48a1115073c/forums_list_with_Circles.jpg)
Tthis works better with unsaturated colors. I would suggest saturation < 50%. For the identicons we pick random red, green and blue values in the bottom 3/4 of the range, which ensures the colours are somewhat desturated and dark enough to contrast with a light background.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/336Remove TestingActivity2018-06-12T11:32:29ZakwizgranRemove TestingActivityThis has been replaced by the new feedback reporter.This has been replaced by the new feedback reporter.Milestone Cakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/322New ForumSharingManager based on ProtocolEngine2018-06-12T11:32:30ZTorsten GroteNew ForumSharingManager based on ProtocolEngineIn order to improve the UX for sharing forums, the `ForumSharingManager` needs to be rewritten.
Similar to the `IntroductionManager`, it should make use of the abstract Protocol engine and implement a protocol (#320) between two parties...In order to improve the UX for sharing forums, the `ForumSharingManager` needs to be rewritten.
Similar to the `IntroductionManager`, it should make use of the abstract Protocol engine and implement a protocol (#320) between two parties.
This is a subtask of Issue #121 which concerns the UX. The interface with the UI is discussed in #321.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/321ForumSharingManager interface with UI2018-06-12T11:32:30ZTorsten GroteForumSharingManager interface with UIThe ForumSharingManager will be rewritten and changes its paradigm from "sharing as state" to "sharing as action", so the UI interface will need to change along with it.
This is how it could look like:
```java
/** Returns the uniq...The ForumSharingManager will be rewritten and changes its paradigm from "sharing as state" to "sharing as action", so the UI interface will need to change along with it.
This is how it could look like:
```java
/** Returns the unique ID of the forum sharing client. */
ClientId getClientId();
/** Sends an invitation to share the given forum with the given contact and sends an optional message along with it. */
void sendForumInvitation(Forum f, ContactId contactId, @Nullable String message) throws DbException;
/** Responds to a pending forum invitation */
void respondToInvitation(SessionId sessionId, ContactId contactId, boolean accept) throws DbException;
/** Returns all forum sharing messages sent by the Contact identified by contactId. */
Collection<ForumInvitationMessage> getForumInvitationMessages(ContactId contactId) throws DbException;
/** Returns all forums to which the user could subscribe. */
Collection<Forum> getAvailableForums() throws DbException;
/** Returns all contacts who are sharing the given forum with the user. */
Collection<Contact> getSharedBy(Forum f) throws DbException;
/** Returns the IDs of all contacts with whom the given forum is shared. */
Collection<ContactId> getSharedWith(Forum f) throws DbException;
```
Note that I removed methods for adding and (un)subscribing to/from a forum. These are probably better placed into the `ForumManager`.
This is a subtask of Issue #121.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/320Design Protocol for Sharing Forums2018-06-12T11:32:30ZTorsten GroteDesign Protocol for Sharing ForumsThe protocol will look like a simpler version of the introduction protocol, with two parties per session, and messages for invite/accept/decline/abort. (if you share a forum with more than one contact we can just create one session per c...The protocol will look like a simpler version of the introduction protocol, with two parties per session, and messages for invite/accept/decline/abort. (if you share a forum with more than one contact we can just create one session per contact, there's no reason to tie them together.)
1: **INVITATION** - This is send by the sharer to one of her contacts. The content is a BDF list.
* (int) The type of the message, here 1
* (raw) SessionId chosen by the sharer
* (string) name of the forum
* (raw) salt to uniquely identify this forum
* (string) optional invitation message
2: **ACCEPT RESPONSE** - This should be sent by contacts that received a sharing invitation. The content is a BDF list with these elements:
* (int) The type of the message, here 2
* (raw) SessionId must match the SessionId of an unanswered invitation.
3: **DECLINE RESPONSE** - This should be sent by contacts that received a sharing invitation and do not want to add the forum. The content is a BDF list with these elements:
* (int) The type of the message, here 3
* (raw) SessionId must match the SessionId of an unanswered invitation.
4: **LEAVE** - This should be send by a contact that is unsubscribing from the forum. The content is a BDF list with two elements:
* (int) The type of the message, here 4
* (raw) SessionId must match the SessionId of a previous (un)answered invitation.
5: **ABORT** - This should be send by a contact that encountered an error, so that it can not complete the protocol. The content is a BDF list with two elements:
* (int) The type of the message, here 5
* (raw) SessionId must match the SessionId of an unanswered invitation.
A successful run of the protocol would look like this:
![forum-sharing](/uploads/8f53758e8ed55146f498181b2708a9b1/forum-sharing.png)
**Sharer**
![sharer-state-machine](/uploads/5ca0924c21eef0601e5cfdf4060577ad/sharer-state-machine.png)
[sharer-state-machine.odg](/uploads/24354e5ef7779d36ed7a815eccb8f35e/sharer-state-machine.odg)
**Invitee**
![invitee-state-machine](/uploads/b57dc42ebe5873530543ce7ab36af8f4/invitee-state-machine.png)
[invitee-state-machine.odg](/uploads/2099baeb7948980819022fda5f402aed/invitee-state-machine.odg)
Arrows that have no label stand for 'all other actions'.
It should be documented in the wiki as well: https://code.briarproject.org/akwizgran/briar/wikis/ForumSharingClient
This is a subtask of Issue #322.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/319Distinguish between transient, recoverable and permanent DB exceptions2020-11-21T19:08:20ZakwizgranDistinguish between transient, recoverable and permanent DB exceptionsThis would be useful for message delivery hooks and any other operation that should be retried if the failure is temporary, or cancelled if it's permanent.This would be useful for message delivery hooks and any other operation that should be retried if the failure is temporary, or cancelled if it's permanent.https://code.briarproject.org/briar/briar/-/issues/317Remove binaries from git history2022-01-21T09:59:52ZakwizgranRemove binaries from git historyThe git repo is huge. Rewrite the commit history to remove unnecessary binaries (fonts, android.jar, etc).
We could also remove the Tor binaries and any jars that have been converted to Gradle dependencies, but that would make it imposs...The git repo is huge. Rewrite the commit history to remove unnecessary binaries (fonts, android.jar, etc).
We could also remove the Tor binaries and any jars that have been converted to Gradle dependencies, but that would make it impossible to build old commits that used those binaries.https://code.briarproject.org/briar/briar/-/issues/313Move create forum post and share forum buttons in action bar2018-06-12T11:32:30ZTorsten GroteMove create forum post and share forum buttons in action barThis is a subtask of #121.
According to the designs in #305, the 'create forum post' and 'share forum' buttons will go into the in action bar.
In the spirit of keeping MRs small and to avoid conflicts with #306, this could be done ...This is a subtask of #121.
According to the designs in #305, the 'create forum post' and 'share forum' buttons will go into the in action bar.
In the spirit of keeping MRs small and to avoid conflicts with #306, this could be done first and independently of future work.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/312Audit logging for sensitive or identifying information2018-06-12T11:32:30ZakwizgranAudit logging for sensitive or identifying informationCreate scrubbers for data such as IP addresses, MAC addresses and Tor hidden service addresses. These fields should not be logged verbatim, but may need to be logged in part, or hashed with salt, so that we can understand the logs.Create scrubbers for data such as IP addresses, MAC addresses and Tor hidden service addresses. These fields should not be logged verbatim, but may need to be logged in part, or hashed with salt, so that we can understand the logs.https://code.briarproject.org/briar/briar/-/issues/311Audit crash report and feedback fields for sensitive or identifying information2018-06-12T11:32:30ZakwizgranAudit crash report and feedback fields for sensitive or identifying informationSubtask of #123.Subtask of #123.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/310Client layer events for forums2018-06-12T11:32:30ZakwizgranClient layer events for forumsThe forum UI currently depends on sync layer events such as MessageStateChangedEvent. The forum and forum sharing clients should broadcast their own high-level events with the information the UI needs.
Related to #122, #289.The forum UI currently depends on sync layer events such as MessageStateChangedEvent. The forum and forum sharing clients should broadcast their own high-level events with the information the UI needs.
Related to #122, #289.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/309Client layer events for messaging2018-06-12T11:32:30ZakwizgranClient layer events for messagingThe messaging UI currently depends on sync-layer events such as MessageStateChangedEvent. The messaging client should broadcast its own high-level events with the information the UI needs.
Related to #289.The messaging UI currently depends on sync-layer events such as MessageStateChangedEvent. The messaging client should broadcast its own high-level events with the information the UI needs.
Related to #289.Milestone ETorsten GroteTorsten Grotehttps://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.