briar issueshttps://code.briarproject.org/groups/briar/-/issues2018-05-03T16:43:58Zhttps://code.briarproject.org/briar/briar/-/issues/617Protocol versioning2018-05-03T16:43:58ZakwizgranProtocol versioningAll protocols should include version information, and implementations should respond appropriately to versions they don't know how to handle.All protocols should include version information, and implementations should respond appropriately to versions they don't know how to handle.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/613Use metadata queries to look up introduction session state2018-04-28T00:17:21ZakwizgranUse metadata queries to look up introduction session stateSubtask of #376.Subtask of #376.Android 1.0Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/612Use metadata queries to look up invitation session state2018-06-11T10:24:35ZakwizgranUse metadata queries to look up invitation session stateSubtask of #376.Subtask of #376.Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/606Improve Fragment handling2020-11-21T17:17:05ZTorsten GroteImprove Fragment handlingThe `BriarFragmentActivity` is working around the fragment backstack instead of with it. Sometimes fragments are added to the stack and sometimes not. Fragments are *always* created from scratch even if there might already be an instance...The `BriarFragmentActivity` is working around the fragment backstack instead of with it. Sometimes fragments are added to the stack and sometimes not. Fragments are *always* created from scratch even if there might already be an instance on the backstack that could be re-used.https://code.briarproject.org/briar/briar/-/issues/605Add database method for retrieving a contact by local and remote author IDs2018-06-12T11:32:20ZakwizgranAdd database method for retrieving a contact by local and remote author IDsMilestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/604Provide hooks for mitigating flooding attacks at client layer2020-11-21T17:21:36ZakwizgranProvide hooks for mitigating flooding attacks at client layerMessage flooding attacks can be mitigated to some extent at the sync layer (#511), but the client may be in a better position to make decisions such as rate limiting. The sync API should allow clients to express these decisions, for exam...Message flooding attacks can be mitigated to some extent at the sync layer (#511), but the client may be in a better position to make decisions such as rate limiting. The sync API should allow clients to express these decisions, for example by limiting the rate at which messages are delivered to the client, shared with contacts, or both.https://code.briarproject.org/briar/briar/-/issues/603Research stream isolation for hidden service connections2020-11-16T11:11:45ZakwizgranResearch stream isolation for hidden service connectionsTor supports stream isolation, meaning that streams used for separate purposes can be forced to use separate circuits, making it harder for observers to tell whether the streams belong to the same client. Clients can activate this featur...Tor supports stream isolation, meaning that streams used for separate purposes can be forced to use separate circuits, making it harder for observers to tell whether the streams belong to the same client. Clients can activate this feature by specifying a SOCKS username and password - streams with different SOCKS credentials will be isolated from each other.
Using stream isolation for our hidden service connections may help to prevent Tor relays from learning which hidden service addresses belong to contacts of the same user. That information could be used to help identify the user or her contacts. On a larger scale it might also be used to build an anonymised social graph of hidden service addresses, which could then be deanonymised by comparing it with other social graphs (https://33bits.org/).
However, it's not clear whether stream isolation would prevent this information leak, as Tor may re-use existing circuits for publishing and retrieving hidden service descriptors (see https://gitweb.torproject.org/torspec.git/plain/rend-spec.txt).
Find out:
* Whether stream isolation applies to publishing and retrieving HS descriptors
* Whether stream isolation has a bandwidth cost due to using more circuitshttps://code.briarproject.org/briar/briar/-/issues/602Exponential backoff for RSS feeds2021-04-16T13:21:41ZakwizgranExponential backoff for RSS feedsWe fetch all RSS feeds at the same fixed interval. Some feeds update much more frequently than others, so we should adjust the interval of each feed to match its update interval. This can be done by doubling the interval whenever a fetch...We fetch all RSS feeds at the same fixed interval. Some feeds update much more frequently than others, so we should adjust the interval of each feed to match its update interval. This can be done by doubling the interval whenever a fetch succeeds without finding any new posts, and halving the interval whenever new posts are found. The intervals should be stored persistently.
Related to #44, #45.https://code.briarproject.org/briar/briar/-/issues/601Remove content type from forum posts2018-06-12T11:32:20ZakwizgranRemove content type from forum postsThe content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.The content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.https://code.briarproject.org/briar/briar/-/issues/600Remove content type from private messages2018-06-12T11:32:20ZakwizgranRemove content type from private messagesThe content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.The content type field is unused and we don't yet have a plan for when it will be used. Remove it until it's needed.Milestone FTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/599Fetch RSS feeds via Tor2018-06-12T11:32:20ZakwizgranFetch RSS feeds via TorUse the localhost Socks proxy to fetch the feeds. The proxy port is currently set in briar-android and would need to be moved to core or api.
The `FeedManager` should listen to `TransportEnabledEvent`s and enable the feed fetching sch...Use the localhost Socks proxy to fetch the feeds. The proxy port is currently set in briar-android and would need to be moved to core or api.
The `FeedManager` should listen to `TransportEnabledEvent`s and enable the feed fetching scheduler when Tor is started first. For simplicity, it should not turn off the scheduler when Tor gets turned off, but let the fetch job fail cleanly when Tor is not running.
We should use stream isolation to ensure the lookups for different feeds happen over different circuits. This is done by specifying a different SOCKS username and password for each feed (any username and password can be used, they just need to be different - generating them on the fly would be fine).Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/598Remove unused code and layouts for old blog implementation2018-06-12T11:32:20ZakwizgranRemove unused code and layouts for old blog implementationIf we decide we need them in future, they'll still be in git.If we decide we need them in future, they'll still be in git.Milestone Eakwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/596Setup UI Tests with Espresso2018-08-03T16:39:09ZTorsten GroteSetup UI Tests with EspressoWe currently do not have real UI tests. Espresso is pushed a lot by Google and it makes great progress. You can even already record tests in the UI without needing to write the code for them yourself. It does require an emulator or a rea...We currently do not have real UI tests. Espresso is pushed a lot by Google and it makes great progress. You can even already record tests in the UI without needing to write the code for them yourself. It does require an emulator or a real phone to run these tests though.Android 1.1Torsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/595Clients should decide whether to share messages2018-06-12T11:32:20ZakwizgranClients should decide whether to share messagesThe validation manager currently sets all messages as shared after delivering them. Clients should specify which messages to share, for example by returning a boolean from the delivery hook or calling DatabaseComponent#setMessageShared()...The validation manager currently sets all messages as shared after delivering them. Clients should specify which messages to share, for example by returning a boolean from the delivery hook or calling DatabaseComponent#setMessageShared() from within the delivery hook.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/594Implement Database Schema Update Mechanism2018-02-05T11:32:07ZTorsten GroteImplement Database Schema Update MechanismWhen the database schema changes in new versions, these changes should be applied to old versions of the schema.When the database schema changes in new versions, these changes should be applied to old versions of the schema.Android 1.0akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/592Scrub addresses before logging them2018-06-12T11:32:20ZakwizgranScrub addresses before logging themMAC, IP and onion addresses should be scrubbed before logging to ensure we don't leave any sensitive information in plaintext on the device or send it in crash reports or feedback.
We need to keep enough information for the addresses ...MAC, IP and onion addresses should be scrubbed before logging to ensure we don't leave any sensitive information in plaintext on the device or send it in crash reports or feedback.
We need to keep enough information for the addresses to be useful for debugging, without harming user privacy. Perhaps something like the following:
* MAC addresses (including Bluetooth): keep the first and last octets, replace the rest with XX
* Link-local and site-local IPv4 addresses: keep the full address
* Other IPv4 addresses: keep the first and last octets, replace the rest with XX
* IPv6 addresses: not intentionally used by Briar, replace the whole thing with XX
* Onion addresses: keep the first three characters, replace the rest with XXMilestone CTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/591Add New Message Types to BlogValidator2018-06-12T11:32:20ZTorsten GroteAdd New Message Types to BlogValidatorSub-Ticket of #494 and #437.Sub-Ticket of #494 and #437.Milestone DTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/589When a message is shared, share its transitive dependencies2018-06-12T11:32:20ZakwizgranWhen a message is shared, share its transitive dependenciesLike other recursive operations on the dependency graph, this should not be done in a single transaction. So we'll need to find and resume any unfinished operations at startup, by looking for shared messages with unshared dependencies.Like other recursive operations on the dependency graph, this should not be done in a single transaction. So we'll need to find and resume any unfinished operations at startup, by looking for shared messages with unshared dependencies.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/586Store latest timestamp and unread count in group metadata for invitations2018-06-12T11:32:21ZakwizgranStore latest timestamp and unread count in group metadata for invitationsThe contact list loads all invitation messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every message, which in the wors...The contact list loads all invitation messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every message, which in the worst case iterates over all sessions. Store this information in the group metadata and expose it through the SharingManager interface.
The timestamp should relate to the latest message that would be visible in the UI, i.e. invitations and responses.
Related to #373.Milestone ETorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/585Store latest timestamp and unread count in group metadata for introductions2018-06-12T11:32:21ZakwizgranStore latest timestamp and unread count in group metadata for introductionsThe contact list loads all introduction messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every introduction message, wh...The contact list loads all introduction messages just to get the latest timestamp and unread message count for each conversation. This is a very expensive provess that involves loading the session state for every introduction message, which in the worst case iterates over all sessions. Store this information in the group metadata and expose it through the IntroductionManager interface.
Related to #373.Milestone ETorsten GroteTorsten Grote