briar issueshttps://code.briarproject.org/groups/briar/-/issues2019-02-25T09:56:36Zhttps://code.briarproject.org/briar/briar/-/issues/361Testers could not connect to their contacts2019-02-25T09:56:36ZakwizgranTesters could not connect to their contactsDuring a multi-day test, testers were sometimes unable to connect to their contacts and messages were delayed for days. This happened whether they were connected to wifi or mobile data.During a multi-day test, testers were sometimes unable to connect to their contacts and messages were delayed for days. This happened whether they were connected to wifi or mobile data.https://code.briarproject.org/briar/briar/-/issues/257Consider offering user validation alternatives2019-04-10T10:39:39ZErnir ErlingssonConsider offering user validation alternativesCurrently we are only validating users with text strings but text input, on small mobile devices especially, is little fun and for that reason some users might choose comfortability, with a short password, over security. There are severa...Currently we are only validating users with text strings but text input, on small mobile devices especially, is little fun and for that reason some users might choose comfortability, with a short password, over security. There are several possibilities available to tackle this "problem":
**1. Offer more user validation possibilities besides using a password, e.g. use the device's fingerprint sensor**
if available. This will only work for one account though, if a user has multiple accounts we will need to offer some way for the user to define which account is using his fingerprint.
**2. Define access layers with different security restrictions**
This is much more tricky and maybe not desirable at all but I feel there is sufficient discussion merit nonetheless. Currently Briar employs a single access restriction on a per account basis, i.e. you either have access to everything (for the respective account) or nothing depending on your knowledge of the password.
Another approach would be to have multiple access levels, e.g. you enter the app with a four digit pin that gives you access to the app but in order to communicate with extra-secure users (this could be marked when contacts are added) you must first confirm your password on a session basis. Here we would need to make sure that the security restriction on the communication between contacts A and B would be identical, i.e. both parties would be required to confirm the passwords in order to communicate.Android 1.1https://code.briarproject.org/briar/briar/-/issues/249Support multi-block messages2018-05-11T13:29:32ZakwizgranSupport multi-block messagesDepends on #175.Depends on #175.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/59Traffic analysis prevention layer2022-11-01T14:51:18ZakwizgranTraffic analysis prevention layerThe traffic analysis prevention (TAP) layer is responsible for preventing an observer from determining the volume and timing of data carried by a BTP stream.
What should the interfaces between BTP, TAP and the transport plugin look like...The traffic analysis prevention (TAP) layer is responsible for preventing an observer from determining the volume and timing of data carried by a BTP stream.
What should the interfaces between BTP, TAP and the transport plugin look like? Does the plugin need to be able to ask for a specific stream length, other than setting an upper bound? Are there any transports for which sending data as quickly as possible is preferable (from a TAP point of view) to sending it at a limited rate?
The TAP layer could adjust the transmission rate, increasing it if there's data waiting and decreasing it if not. What could the adversary learn by observing changes in the transmission rate and/or manipulating congestion?
Padding could be handled at the BTP layer by choosing a padding multiplier for each stream. The TAP layer would then sit between BTP and the transport and handle chopping and delaying the stream -- that is, segmenting the encrypted, padded stream according to some segment size distribution, and writing segments to the transport according to some inter-segment delay distribution.
The padding, size and delay distributions can be used to produce a characteristic traffic 'shape' for each device or pair of devices:
http://www.cs.kau.se/philwint/pdf/wpes2013.pdf
We can conceal traffic bursts by throttling the output of the TAP layer so that bursts are smoothed out. However, we should make good use of intermittently available transports -- if we send too slowly, the transport connection may be lost before we finish.https://code.briarproject.org/briar/briar/-/issues/28LAN peer discovery2022-09-08T12:24:41ZakwizgranLAN peer discoveryThere are three options:
1) Use Wi-Fi Direct peer discovery.
Advantages:
* Available on recent Android devices with very little effort
* Doesn't create a Briar-specific traffic fingerprint
* Doesn't reveal the number of contacts
Disad...There are three options:
1) Use Wi-Fi Direct peer discovery.
Advantages:
* Available on recent Android devices with very little effort
* Doesn't create a Briar-specific traffic fingerprint
* Doesn't reveal the number of contacts
Disadvantages:
* Not available on older Android devices
* May not be available on all platforms
2) Use BitTorrent's local peer discovery protocol. Advertise a single infohash for all contacts.
https://en.wikipedia.org/wiki/Local_Peer_Discovery
http://forum.utorrent.com/viewtopic.php?pid=433785#p433785
Advantages:
* Doesn't create a Briar-specific traffic fingerprint
* Doesn't reveal the number of contacts
Disadvantages:
* Direct use of multicast won't work on all Android devices
3) Use a custom protocol. Choose a pseudorandom multicast group, advertise it in transport properties. Join the group at startup and periodically send a UDP packet to the group. Join contacts' multicast groups, listen for UDP packets, and connect back via TCP.
Advantages:
* Won't trigger filter rules designed to catch P2P traffic
Disadvantages:
* Direct use of multicast won't work on all Android devices
* Will IGMP traffic reveal the number of contacts?https://code.briarproject.org/briar/briar/-/issues/700Update blog backend to match current usage2018-01-28T11:30:28ZakwizgranUpdate blog backend to match current usageThe blog backend supports some features we're not using:
* Multiple blogs per author
* Titles for blogs and posts
* Descriptions for blogs
On the other hand, the backend doesn't provide any support for distinguishing between imported RS...The blog backend supports some features we're not using:
* Multiple blogs per author
* Titles for blogs and posts
* Descriptions for blogs
On the other hand, the backend doesn't provide any support for distinguishing between imported RSS posts and native Briar posts.
We have to balance two concerns: keeping the implementation flexible so that we can add new features, and keeping the implementation simple so it's easier to maintain and audit. Forward compatibility isn't a major concern: we're going to be breaking compatibility in many other ways over the coming months, so keeping the blog protocol forward compatible while everything else breaks won't achieve anything.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/609Update UI in paused state to support multi-window mode2018-01-28T11:30:28ZakwizgranUpdate UI in paused state to support multi-window modeIn Android N's multi-window mode, the app that doesn't have focus is in the paused state. We should move all our calls to register/unregister event handlers, refresh content, etc, from onPause/onResume to onStart/onStop so that the UI is...In Android N's multi-window mode, the app that doesn't have focus is in the paused state. We should move all our calls to register/unregister event handlers, refresh content, etc, from onPause/onResume to onStart/onStop so that the UI is updated in the paused state.
https://developer.android.com/guide/topics/ui/multi-window.htmlMilestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/544PersistentData classes aren't thread-safe2018-01-28T11:30:28ZakwizgranPersistentData classes aren't thread-safeForumPersistentData and BlogPersistentData aren't thread-safe but they're accessed by multiple threads. They hold references to non-thread-safe collections. Callers make multiple calls assuming that the state won't change between calls, ...ForumPersistentData and BlogPersistentData aren't thread-safe but they're accessed by multiple threads. They hold references to non-thread-safe collections. Callers make multiple calls assuming that the state won't change between calls, potentially causing NPEs and other less obvious bugs.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/452Hide Identities Initially2018-01-28T11:30:28ZTorsten GroteHide Identities InitiallyIt has been decided that we will not support multiple identities initially, so they should be hidden from the UI from now.It has been decided that we will not support multiple identities initially, so they should be hidden from the UI from now.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/419Add Contextual Action Bar for selecting multiple Blogs2018-01-28T11:30:28ZTorsten GroteAdd Contextual Action Bar for selecting multiple BlogsThis ticket depends on #414, #412 and #418.
When long-pressing a blog in "My Blogs" or the "Blog List", the blog should be selected and a Contextual Action Bar should be shown that allows to delete the blogs or share them with contact...This ticket depends on #414, #412 and #418.
When long-pressing a blog in "My Blogs" or the "Blog List", the blog should be selected and a Contextual Action Bar should be shown that allows to delete the blogs or share them with contacts.
![delete_flow_small](/uploads/cc0b55fe246c0b9d6e4da8255d57f170/delete_flow_small.jpg)
Image update: Now with tab indicatorhttps://code.briarproject.org/briar/briar/-/issues/418UI for Deleting a Blog2018-01-28T11:30:28ZTorsten GroteUI for Deleting a BlogThis ticket depends on #410.
The code should prepare for multiple blogs being deleted in one go. The selection of multiple blogs and triggering the deletion action will be done in ticket #419.
![delete_flow](/uploads/9a44fc79fa0c5...This ticket depends on #410.
The code should prepare for multiple blogs being deleted in one go. The selection of multiple blogs and triggering the deletion action will be done in ticket #419.
![delete_flow](/uploads/9a44fc79fa0c59a8936a877cdea98787/delete_flow.jpg)
(1) hide delete behind the overflow to minimize accidental deletion
(2) + (3) show a message that makes the delete consequences obvious
There is an additional way to delete directly from the list. It has the advantage that multiple deletions are possible:
(4) long tap on a blog...
(5) highlights the entry and changes the app bar. Another long tap...
(6) selects a second entry, so the user can delete or share multiple blogs
Image update: now with tab indicatorsMilestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/412UI for Sharing a Blog with Contacts2018-01-28T11:30:28ZTorsten GroteUI for Sharing a Blog with ContactsThis ticket depends on #410.
The code should prepare for multiple blogs being shared in one go. The selection of multiple blogs and triggering the sharing action for them will be done in ticket #419.
![sharing_blogs_overview_small...This ticket depends on #410.
The code should prepare for multiple blogs being shared in one go. The selection of multiple blogs and triggering the sharing action for them will be done in ticket #419.
![sharing_blogs_overview_small](/uploads/2788d30a48a67e29e54d25f741801011/sharing_blogs_overview_small.jpg)
Update: Tab indicators addedhttps://code.briarproject.org/briar/briar/-/issues/406Sharing Blogs User Interface2018-01-28T11:30:28ZTorsten GroteSharing Blogs User InterfaceA User Interface for sharing blogs needs to be designed and implemented. This is the main ticket for that. Sub-tickets should be created where appropriate.
Assuming that we model blogs closely to how the UI for forums work, this could...A User Interface for sharing blogs needs to be designed and implemented. This is the main ticket for that. Sub-tickets should be created where appropriate.
Assuming that we model blogs closely to how the UI for forums work, this could be suitable sub-tickets:
* UI to share a blog with contacts (#412)
* UI to show all unanswered blog invitations (#413)
* UI to show personal blog invitations (in private conversation with notification?)
* UI to show sharing status of a blog (#416)
* Contextual Action Bar for sharing multiple Blogs (#419)Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/405Blog User Interface2018-01-28T11:30:28ZTorsten GroteBlog User InterfaceA Blog User Interface needs to be designed and implemented. This is the main ticket for that. Sub-tickets have this structure:
* Blog Fragment in Navigation Drawer (#409)
* UI to Create a New Blog (#410)
* UI for Writing Blog...A Blog User Interface needs to be designed and implemented. This is the main ticket for that. Sub-tickets have this structure:
* Blog Fragment in Navigation Drawer (#409)
* UI to Create a New Blog (#410)
* UI for Writing Blog Posts (#411)
* Save Blog Posts as Draft and Show List of Drafts (#420)
* Research and Implement Rich Text Editor for Writing Blog Posts (#421)
* UI for deleting blog Posts (#418)
* Contextual Action Bar for deleting multiple Blogs (#419)
* UI for Listing All Subscribed Blogs (#414)
* UI for Viewing Blogs (#415)
* Blog Post Activity (#428)
* Display posts from all blogs the user subscribes to in a single combined feed (#417)
Please note that this ticket is **not about sharing** blogs with others. This is handled by ticket #406.Milestone Dhttps://code.briarproject.org/briar/briar/-/issues/391Handle responses to forum invitations by multiple contacts2018-01-28T11:30:28ZTorsten GroteHandle responses to forum invitations by multiple contactsMilestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/388Possible Race-Condition when Two Contacts Share Same Forum with each other2018-01-28T11:30:28ZTorsten GrotePossible Race-Condition when Two Contacts Share Same Forum with each other> What happens if Alice and Bob invite each other to the forum, then some time later both their invitations are delivered? It seems to me that each of them will consult `canBeShared()` for the incoming invitation, see that they've sent a...> What happens if Alice and Bob invite each other to the forum, then some time later both their invitations are delivered? It seems to me that each of them will consult `canBeShared()` for the incoming invitation, see that they've sent an invitation, and delete the incoming invitation. Does that sound right to you? Does that mean neither of them will receive the other's invitation?
Yes, their invitations are most likely deleted without any indication to them.
![forum-sharing-same](/uploads/a267b5ec4a46f4a8f6dc8a83b233d6f9/forum-sharing-same.png)
> Regardless of the answer to this specific question, I think you're right to be concerned about treating symptoms rather than causes. Unfortunately I think the problem might be quite fundamental. We're trying to keep the state of the forum (are we subscribed, is it visible to the contact) consistent with the state of each session - but there can be multiple sessions relating to a given forum. Can we be sure that those sessions will always produce consistent answers to (a) whether we belong to the forum, and (b) whether the contact belongs to it?
> The message queue ensures that our messages are delivered to the contact in order and vice versa, but if we want to be sure that a given set of messages always produces the same state, we need a canonical ordering for all the messages: ours and the contact's. Within each session, we can use knowledge of the protocol to order certain messages (for example, a response must follow an invitation), but I'm not sure we can do that across multiple sessions in the general case.Milestone CTorsten GroteTorsten Grotehttps://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/302Improve privacy of LAN plugin2018-01-28T11:30:28ZakwizgranImprove privacy of LAN pluginThe LAN plugin updates its transport properties with the latest IP address whenever a connectivity change is detected. This may allow the user's contacts to tell when she's at a frequently visited location, either by recognising an addre...The LAN plugin updates its transport properties with the latest IP address whenever a connectivity change is detected. This may allow the user's contacts to tell when she's at a frequently visited location, either by recognising an address she used when they were nearby, or by inferring a pattern (e.g. the IP address she usually advertises at night probably represents her home network).
Instead of advertising a single current address, we could advertise a list of recent addresses. This would make polling more expensive - addresses that aren't valid for the current network aren't polled, but we can expect a lot of networks to use the 192.168.0.0/16 range, resulting in multiple polling attempts per contact.
Related to #28, #44, #62.Milestone Chttps://code.briarproject.org/briar/briar/-/issues/233Add MAC to messages in private groups2018-01-28T11:30:28ZakwizgranAdd MAC to messages in private groupsFor future multi-device support it would be useful for private groups (i.e. groups shared between a pair of contacts) to be shared by all the contacts' devices, so that messages are automatically synchronised among all devices.
A user...For future multi-device support it would be useful for private groups (i.e. groups shared between a pair of contacts) to be shared by all the contacts' devices, so that messages are automatically synchronised among all devices.
A user's devices need to be able to distinguish remote messages created by the user's other devices from remote messages created by the contact's devices.
A simple way to achieve that is to add a MAC to all messages and share the MAC key between the user's devices. Any message with a valid MAC was created by one of the user's devices, any other message was created by one of the contact's devices.
We're not implementing multi-device support yet, but we should add this now so we don't have to change the wire format later.