briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-06-12T11:32:27Zhttps://code.briarproject.org/briar/briar/-/issues/409Blog Fragment in Navigation Drawer with Tabs2018-06-12T11:32:27ZTorsten GroteBlog Fragment in Navigation Drawer with TabsThis ticket is for adding a new fragment to the navigation drawer that holds a [TabLayout](https://developer.android.com/reference/android/support/design/widget/TabLayout.html). Each tab should be able to hold a child fragment. Swiping l...This ticket is for adding a new fragment to the navigation drawer that holds a [TabLayout](https://developer.android.com/reference/android/support/design/widget/TabLayout.html). Each tab should be able to hold a child fragment. Swiping left/right in the child fragment should switch the tab. Clicking on the tab should switch to the respective fragment.
Creating the child fragments with content is **not** part of this ticket.
![Navigation Drawer](https://code.briarproject.org/akwizgran/briar/uploads/342b38ffb0991760da0d2a03beaf42f9/navidrawer_new_blogs.jpg)
![Blogs_5_tab_feed](/uploads/0025186abf95bccf235827d03d3636c3/Blogs_5_tab_feed.jpg)
Update: just added a mockup with a tab indicator
Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/404Create a Blog Factory2018-06-12T11:32:27ZTorsten GroteCreate a Blog FactoryBoth, the Blog Client (#402) and the Blog Sharing Client (#403) will need to construct blogs. Create a `BlogFactory` that can be used by both.
A blog is one group. The group descriptor of a blog is a BDF list with two elements: name (...Both, the Blog Client (#402) and the Blog Sharing Client (#403) will need to construct blogs. Create a `BlogFactory` that can be used by both.
A blog is one group. The group descriptor of a blog is a BDF list with two elements: name (string) and public_key (raw).Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/397Remove unused Java layout helpers2018-06-12T11:32:27ZakwizgranRemove unused Java layout helpersVarious classes in org.briarproject.android.util can be removed once the last layouts have been converted to XML.
Subtask of #53.Various classes in org.briarproject.android.util can be removed once the last layouts have been converted to XML.
Subtask of #53.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/396Convert ExpiredActivity to XML2018-06-12T11:32:27ZakwizgranConvert ExpiredActivity to XMLSubtask of #53.Subtask of #53.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/395Convert CreateIdentityActivity to XML2018-06-12T11:32:27ZakwizgranConvert CreateIdentityActivity to XMLSubtask of #53.Subtask of #53.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/393Sort threaded messages2018-06-12T11:32:27ZakwizgranSort threaded messagesWrite code for sorting a forest of threaded messages:
* Roots in timestamp order
* Children below their parents
* Siblings in timestamp order
The input will be an unsorted collection of messages with parent pointers. The code mus...Write code for sorting a forest of threaded messages:
* Roots in timestamp order
* Children below their parents
* Siblings in timestamp order
The input will be an unsorted collection of messages with parent pointers. The code must not use more than O(n log n) time or space. Algorithms presumably exist already, find them!
Subtask of #122.Milestone Chttps://code.briarproject.org/briar/briar/-/issues/392Use new metadata queries for forum client2018-06-12T11:32:27ZTorsten GroteUse new metadata queries for forum clientUse new queries introduced in !187.Use new queries introduced in !187.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/385Add BQP support to the LAN plugin2018-06-12T11:32:27ZakwizgranAdd BQP support to the LAN pluginThis will allow us to work around Bluetooth issues when both devices are connected to the same LAN.This will allow us to work around Bluetooth issues when both devices are connected to the same LAN.Milestone Chttps://code.briarproject.org/briar/briar/-/issues/382Deliver messages to incoming message hook after their dependencies2018-06-12T11:32:27ZakwizgranDeliver messages to incoming message hook after their dependenciesThe sync layer should keep track of each message's dependencies and deliver messages to the incoming message hook after their dependencies. If any dependency is invalid or in a different group, the message is invalid and should be delete...The sync layer should keep track of each message's dependencies and deliver messages to the incoming message hook after their dependencies. If any dependency is invalid or in a different group, the message is invalid and should be deleted.
Messages that are waiting for dependencies should not be visible to clients.
Subtask of #122.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/381Extract dependencies from messages in validation hook2018-06-12T11:32:27ZakwizgranExtract dependencies from messages in validation hookThe validation hook should return a list of dependencies to the validation manager.The validation hook should return a list of dependencies to the validation manager.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/378Replace BDF data structures with classes in forum sharing client2018-06-12T11:32:28ZakwizgranReplace BDF data structures with classes in forum sharing clientThe forum sharing client uses BdfDictionary and BdfList for its internal data structures, rather than just for serialisation. This tends to push type checking from compile time to run time. Create classes to represent the protocol messag...The forum sharing client uses BdfDictionary and BdfList for its internal data structures, rather than just for serialisation. This tends to push type checking from compile time to run time. Create classes to represent the protocol messages and other internal state.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/375Extract ForumFactory from ForumManager2018-06-12T11:32:28ZakwizgranExtract ForumFactory from ForumManagerThe code for creating forums in ForumManager is used by ForumSharingManager and also needed by InviteeEngine. Extract it into its own class.The code for creating forums in ForumManager is used by ForumSharingManager and also needed by InviteeEngine. Extract it into its own class.Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/374Add Forum Avatars to Available Forums List2018-06-12T11:32:28ZTorsten GroteAdd Forum Avatars to Available Forums ListAs soon as !172 and !178 have both been merged, the forum avatars should also be added to the Available Forums List.
As soon as !172 and !178 have both been merged, the forum avatars should also be added to the Available Forums List.
Milestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/372Clean up Introduction Session States when removing contact2018-06-12T11:32:28ZTorsten GroteClean up Introduction Session States when removing contactCurrently, when a contact is removed, any existing sessions will be aborted, but no session state messages are deleted from the local group.
Currently, when a contact is removed, any existing sessions will be aborted, but no session state messages are deleted from the local group.
Milestone CTorsten GroteTorsten Grotehttps://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/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/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 Cakwizgranakwizgran