briar issueshttps://code.briarproject.org/groups/briar/-/issues2021-09-02T12:26:52Zhttps://code.briarproject.org/briar/briar/-/issues/2105Let contacts know if removable drive transport isn't supported2021-09-02T12:26:52ZakwizgranLet contacts know if removable drive transport isn't supportedAndroid devices running API < 19 where the removable drive feature isn't supported should let their contacts know that the feature isn't supported. This could be done by not configuring the plugin on API < 19, so no transport properties ...Android devices running API < 19 where the removable drive feature isn't supported should let their contacts know that the feature isn't supported. This could be done by not configuring the plugin on API < 19, so no transport properties will be sent.
A nicer but more complex solution would be to send different transport properties on API < 19 (supported = false), so the contact's device knows that we're running a Briar version that's aware of the transport, but our device doesn't support it, and thus the contact's UI can show an appropriate message.
Subtask of #1802.Transfer content securely via SD cards and USB memory sticksIvanaIvana2021-07-31https://code.briarproject.org/briar/briar/-/issues/2103Check whether we have transport keys before trying to send data via removable...2021-07-06T20:10:49ZakwizgranCheck whether we have transport keys before trying to send data via removable driveAs well as checking whether the contact supports the transport, we should check whether transport keys have been derived.
Subtask of #1802.As well as checking whether the contact supports the transport, we should check whether transport keys have been derived.
Subtask of #1802.Transfer content securely via SD cards and USB memory sticksakwizgranakwizgran2021-07-31https://code.briarproject.org/briar/briar/-/issues/2095Add option to use system's Tor binary2023-10-10T18:11:51ZNicoAdd option to use system's Tor binaryThis is most likely needed for a release to Debian (~~https://code.briarproject.org/briar/briar-gtk/issues/38~~ https://code.briarproject.org/briar/briar-desktop/-/issues/261).This is most likely needed for a release to Debian (~~https://code.briarproject.org/briar/briar-gtk/issues/38~~ https://code.briarproject.org/briar/briar-desktop/-/issues/261).https://code.briarproject.org/briar/briar/-/issues/2091Add a transport property that just indicates that the transport is supported2021-07-02T18:01:34ZakwizgranAdd a transport property that just indicates that the transport is supportedWe need to know whether it's possible to communicate with a given contact via removable drives. The presence of transport keys doesn't necessarily mean the contact supports the transport, as when adding a contact we derive keys for all t...We need to know whether it's possible to communicate with a given contact via removable drives. The presence of transport keys doesn't necessarily mean the contact supports the transport, as when adding a contact we derive keys for all transports we support, without knowing whether the contact also supports them.
For all existing transports we can use transport properties to check whether the contact supports the transport. But the removable drive transport doesn't have any properties.
Add a "supported" property for all transports, so that we can tell which transports a contact supports regardless of whether any properties are needed for establishing a connection.
We may also be able to use this property for key derivation when adding a contact, so that we only derive keys for transports both parties support.Transfer content securely via SD cards and USB memory sticksakwizgranakwizgran2021-07-31https://code.briarproject.org/briar/briar/-/issues/2083Add eager mode to BSP spec2021-11-12T18:00:01ZakwizgranAdd eager mode to BSP specTransfer content securely via SD cards and USB memory sticks2021-07-31https://code.briarproject.org/briar/briar/-/issues/2082Protocol spec for transport key agreement client2021-11-12T17:16:42ZakwizgranProtocol spec for transport key agreement clientTransfer content securely via SD cards and USB memory sticks2021-07-31https://code.briarproject.org/briar/briar/-/issues/2079Check that timestamp is reasonable before deriving transport keys2021-07-06T14:21:54ZakwizgranCheck that timestamp is reasonable before deriving transport keysDeriving rotation mode transport keys with a very old timestamp may take a long time, as the keys need to be rotated from the period containing the very old timestamp to the current period. If we do this while holding a DB transaction th...Deriving rotation mode transport keys with a very old timestamp may take a long time, as the keys need to be rotated from the period containing the very old timestamp to the current period. If we do this while holding a DB transaction then the DB may be blocked. Sanity-check the timestamp before deriving rotation mode keys and reject it if it's unreasonably old.Transfer content securely via SD cards and USB memory sticksakwizgranakwizgran2021-07-31https://code.briarproject.org/briar/briar/-/issues/2077Add DB methods for checking whether there's anything to send to a contact2021-07-06T10:50:14ZakwizgranAdd DB methods for checking whether there's anything to send to a contactTransfer content securely via SD cards and USB memory sticksakwizgranakwizgran2021-07-31https://code.briarproject.org/briar/briar/-/issues/2076Usability testing for transferring content via SD cards and USB sticks2021-08-31T13:10:44ZakwizgranUsability testing for transferring content via SD cards and USB sticksTransfer content securely via SD cards and USB memory sticksRenata GegajRenata Gegaj2021-07-31https://code.briarproject.org/briar/briar/-/issues/2075Upgrade Tor to 0.3.5.152021-08-27T11:46:44ZakwizgranUpgrade Tor to 0.3.5.15https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.3.5.15https://gitweb.torproject.org/tor.git/tree/ChangeLog?h=tor-0.3.5.15Android 1.3akwizgranakwizgranhttps://code.briarproject.org/briar/briar/-/issues/2071Remove ContactIds from RemovableDriveManager's task management2021-07-06T09:41:47ZTorsten GroteRemove ContactIds from RemovableDriveManager's task managementRemove `ContactId`s from `RemovableDriveManager`'s task management, so we just have one writer and one reader task globally.
* For writer tasks we'll still need to pass a `ContactId` when creating the task, but not when checking for an ...Remove `ContactId`s from `RemovableDriveManager`'s task management, so we just have one writer and one reader task globally.
* For writer tasks we'll still need to pass a `ContactId` when creating the task, but not when checking for an existing task.
* For reader tasks, we don't provide any progress information. We can just remove the progress monitoring stuff from the reader task, and have it post a single progress update when it's complete (success or error).Transfer content securely via SD cards and USB memory sticksakwizgranakwizgran2021-07-31https://code.briarproject.org/briar/briar/-/issues/2070Unit test for transport key agreement validator2021-06-23T14:08:44ZakwizgranUnit test for transport key agreement validatorTransfer content securely via SD cards and USB memory sticksTorsten GroteTorsten Grote2021-07-31https://code.briarproject.org/briar/briar/-/issues/2069Integration test for transport key agreement client2021-07-02T11:11:31ZakwizgranIntegration test for transport key agreement clientTransfer content securely via SD cards and USB memory sticksTorsten GroteTorsten Grote2021-07-31https://code.briarproject.org/briar/briar/-/issues/2065Implement UI of transfer data feature2021-07-06T09:41:34ZTorsten GroteImplement UI of transfer data featureTransfer content securely via SD cards and USB memory sticksTorsten GroteTorsten Grote2021-07-31https://code.briarproject.org/briar/briar/-/issues/2063Allow messages to be resent before they expire2021-07-06T09:41:53ZakwizgranAllow messages to be resent before they expireWhen sending data via removable drives, the strategy of waiting for one maximum round-trip time (twice the maximum latency of the transport) before allowing messages to be resent is likely to cause problems. For example:
* Alice exports...When sending data via removable drives, the strategy of waiting for one maximum round-trip time (twice the maximum latency of the transport) before allowing messages to be resent is likely to cause problems. For example:
* Alice exports messages to a removable drive. Before sending the drive to Bob, Alice realises that she accidentally used a drive belonging to her elderly mother, Carol, who uses the drive to store episodes of Desperate Housewives that she watches on the long bus ride to San Pedro de Atacama (Carol doesn't enjoy the austere beauty of the Atacama Desert, for reasons that are beyond the scope of this user story). Alice deletes the file and exports her messages again, using the right drive this time. Alice may expect that the new file contains all messages not seen by Bob, but in fact it doesn't contain any messages. The messages in the deleted file won't be sendable again for one max round-trip time
* Alice exports messages to a removable drive. Before sending the drive to Bob, Alice writes another message and wants to send this too. So she exports messages to the drive again. Alice may expect that if she overwrites the file she created the first time, the new file will contain all messages not seen by Bob. But in fact it will only contain the most recent message. The messages in the overwritten file won't be sendable again for one max round-trip time
* Alice exports messages to a removable drive and attaches it to a carrier pigeon. Knowing that the Atacama Desert is a harsh environment for pigeons, Alice also exports messages to a second drive, which she attaches to a carrier tortoise as a backup in case the pigeon succumbs to the arid climate. Alice may expect that the second drive contains the same messages as the first one, but in fact it doesn't contain any messages. The messages attached to the unfortunate pigeon won't be sendable again for one max round-trip time
To address these user stories we should send all unacked messages when syncing via removable drives. When syncing via mailboxes we should continue to use the current strategy of sending only messages that have not been sent before, or that were last sent more than one max round-trip time ago.Transfer content securely via SD cards and USB memory sticksakwizgranakwizgran2021-07-31https://code.briarproject.org/briar/briar/-/issues/2055Hide hotspot offline sharing feature behind feature flag2021-07-06T09:38:53ZTorsten GroteHide hotspot offline sharing feature behind feature flagInstall via Bluetooth or Wi-FiSebastianSebastian2021-07-31https://code.briarproject.org/briar/briar/-/issues/2045Make retransmissions in the sync protocol more flexible2021-07-06T09:41:41ZDaniel LublinMake retransmissions in the sync protocol more flexibleDifferent transports need different retransmission behaviour. Retransmission is currently coupled with key rotation period.
For the Removable Drive we might want cause retransmissions every time that the data for a contact is written to...Different transports need different retransmission behaviour. Retransmission is currently coupled with key rotation period.
For the Removable Drive we might want cause retransmissions every time that the data for a contact is written to storage.
- user might might not be sure that the file was correctly saved, and on the actual removable drive, and immediately repeat the process
- user might be accumulating data daily for several days before removable drive is eventually dispatched
- drive might soon break or get lost in transit, and user want to repeat the process, retransmitting all messages again (getting them all onto the removable drive again)Transfer content securely via SD cards and USB memory sticksakwizgranakwizgran2021-07-31https://code.briarproject.org/briar/briar/-/issues/2040Investigate the effect of errors when stopping hotspot2023-03-15T12:41:30ZTorsten GroteInvestigate the effect of errors when stopping hotspot`WifiP2pManager#removeGroup()` can call `ActionListener#onFailure()` with `BUSY` or other error codes. We should check the effect of those and if the system is reliably taking down hotspots or if we need to do some extra work here oursel...`WifiP2pManager#removeGroup()` can call `ActionListener#onFailure()` with `BUSY` or other error codes. We should check the effect of those and if the system is reliably taking down hotspots or if we need to do some extra work here ourselves.SebastianSebastianhttps://code.briarproject.org/briar/briar/-/issues/2039Implement HotspotErrorFragment2021-07-06T09:38:42ZTorsten GroteImplement HotspotErrorFragmentWhen the hotspot or the webserver can't start, we should show an error page and include an option to get to the feedback sender, so we can be notified about the issue.When the hotspot or the webserver can't start, we should show an error page and include an option to get to the feedback sender, so we can be notified about the issue.Install via Bluetooth or Wi-FiSebastianSebastian2021-07-31https://code.briarproject.org/briar/briar/-/issues/2038Sync client to establish keys for newly added transports2021-06-17T13:36:49ZakwizgranSync client to establish keys for newly added transportsWrite a sync client that establishes transport keys with each contact for any transports that were added more recently than the contact was added.
Subtask of #1802Write a sync client that establishes transport keys with each contact for any transports that were added more recently than the contact was added.
Subtask of #1802Transfer content securely via SD cards and USB memory sticksakwizgranakwizgran2021-07-31