briar issueshttps://code.briarproject.org/briar/briar/-/issues2021-07-06T10:03:53Zhttps://code.briarproject.org/briar/briar/-/issues/1114Show when user feedback has been received2021-07-06T10:03:53ZakwizgranShow when user feedback has been receivedA user asked to be shown when their feedback was received.A user asked to be shown when their feedback was received.Adapt to changes in the Android platformTorsten GroteTorsten Grote2021-04-30https://code.briarproject.org/briar/briar/-/issues/1999Android 11 - possible to connect with nearby contact without the location per...2021-07-06T10:03:22ZIvanaAndroid 11 - possible to connect with nearby contact without the location permission - after a dirty shutdownSteps to reproduce:
Fresh install of Briar on Android 11 device (PIxel 2)(Bulid of 15.4, githash 2ddb7b...)
Go to settings > privacy > permissions manager > camera and verify that the Briar access to camera is denied.
Go to settings >...Steps to reproduce:
Fresh install of Briar on Android 11 device (PIxel 2)(Bulid of 15.4, githash 2ddb7b...)
Go to settings > privacy > permissions manager > camera and verify that the Briar access to camera is denied.
Go to settings > privacy > permissions manager > location and verify that the Briar access to location is denied.
1. Log into Briar app.
2. Tap on + to add a nearby contact
3. Tap continue when prompted
4. A pop-up dialog asks for user's permission to use the camera. Options are: Allow while using the app, Only this time, and Deny. User choses deny.
5. A pop-up dialog asks for user's permission to use the location. Options are: Allow while using the app, Only this time, and Deny. User choses deny.
6. A message comes up: "To scan the QR code, briar needs access to the samera. To discover bluetooth devices, Briar needs to access your location. Briar does not store your location or share it with anyone" User taps the button 'Continue'
7. Popup dialogs come up again and ask the user's permission... User selects deny again (for both camera and location user had the same options on dialogues as in step 5)
8. A message titled 'Camera permission' comes up and says this: "You have denied access to the camera, but adding contacts requires using the camera. Please consider granting access". User has options to Cancel or OK.
9. User taps OK
10. This action takes the user to the App info screen for Briar app. User goes to permissions > camera and gives the Briar app acess to camera by chosing 'allow while in use'
11. User goes to permissions > location and gives the Briar app acess to location by chosing 'allow while in use'.
12. Before leaving the previous screen, User then changes their mind and decides to deny Briar access to location- they set Location to denied.
13. User navigates back to Briar by tapping the back button several times
14. User is logged out of Briar
15. User logs back in.
Expected results:
- User should be shown the initial Briar screen (Contacts) and should be able to restart the process of creating nearby contacts?
Actual results:
- The first screen the user sees is: the info screen that explains to user how to scan the QR codes. User taps Continue.
- The previsouly started process of creating the nearby contact (which was started before the logout, in step 2 above) continues successfully, the QR code of another device can be scanned and contact created.
- The location setting for Briar app in privacy > permissions manager > Location = Denied for Briar app.
Question: Is the workflow as described in actual results correct?Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2000Android 11 - 'Ask every time' - should the user be asked to give permissions ...2021-07-06T10:03:14ZIvanaAndroid 11 - 'Ask every time' - should the user be asked to give permissions for every new contact?When giving permissions for camera and location during the creation of a new nearby contact, user is given three choices in dialog popups: Allow while in use, Just this time, and Deny.
If the user select 'Just this time' - what does th...When giving permissions for camera and location during the creation of a new nearby contact, user is given three choices in dialog popups: Allow while in use, Just this time, and Deny.
If the user select 'Just this time' - what does that mean? Should the user be asked to grant permissions for Briar to access their camera or location every time they try to create a neaby contact? Or not?
in Pixel2, Android 11, user is not asked it every time.
Steps to reproduce:
precoditions: Briar is denied access to location and camera.
1. Tap + to create new nearby contact
2. Tap continue
3. Dialog/popup comes up and asks the user to grant permission for Briar to access their camera. User selects Just this time.
4. 3. Dialog/popup comes up and asks the user to grant permission for Briar to access their location. User selects Just this time.
5. User continues the process and creates a nearby contact.
6. User then starts a new process to create another neaby contact.
7. User taps continue.
Expected results:
- User expects to be asked again to give Briar permission to access the camera and location.
Actual results:
- User is not asked for their permission, instead, after tapping Continue, user is shown a message: your device will be visible to other bluetooth devices during 120 seconds and the options are OK and cancel.
- User taps OK
- the process can be completed successfully.
Question: Should user be asked to give permission for Briar to access their camera and location every time the app needs to do it? (ie for creation of every new nearby contact?)Adapt to changes in the Android platform2021-04-30https://code.briarproject.org/briar/briar/-/issues/2002Android 11 PIxel2 - 'Ask every time' - workflow user asked for permission in...2021-07-06T10:03:06ZIvanaAndroid 11 PIxel2 - 'Ask every time' - workflow user asked for permission in popup after they just selected 'ask every time' on deviceScenario: When user is taken to the pages Briar app settings on their device - they decide to grant Briar permission to access the camera and location by selecting 'Ask every time'. They then navigate back to Briar and are given the dial...Scenario: When user is taken to the pages Briar app settings on their device - they decide to grant Briar permission to access the camera and location by selecting 'Ask every time'. They then navigate back to Briar and are given the dialog/popup again with the same question to giv Briar permissions to access their location and camera again - They have just done that, so they shoudln't be asked it again.
Steps to reproduce:
Preconditions: Briar's access to location and camera are denied.
1. Start a new process of creating a nearby contact
2. Tap continue.
3. Popup asks the user to grant Briar permissions to access the camera and location.
4. User denies both.
5. User gets this message: you have denied access to the camera but adding contacts requires using the camera. Please consider granting access. User taps OK.
6. User is then taken to the Briar app settings to grant the Briar access to their camera.
7. User selects the 'Ask every time' option.
8. User navigates back to Briar by tapping the back button.
9. Briar create nearby contacts info screen shows, and user tap Continue
10. A popup comes up and asks the user to grant Briar access to their camera.
Expected results:
- The popup should nto be asking the user to grant permissions after their have just done so.
Actual result:
- A popup comes up and asks the user to grant Briar access to their camera.
- After granting the camera access once more, the user can continue and create the nearby contact OKAdapt to changes in the Android platform2021-04-30https://code.briarproject.org/briar/briar/-/issues/2009Give instructions during setup for protecting app from Xiaomi/Redmi power man...2021-07-06T10:02:52ZakwizgranGive instructions during setup for protecting app from Xiaomi/Redmi power managementWhile working on #1743 I found that the [Snooze app](https://code.briarproject.org/akwizgran/snooze) was killed when running overnight on the Redmi Note 7. [Locking the app to the recent apps list](https://code.briarproject.org/briar/bri...While working on #1743 I found that the [Snooze app](https://code.briarproject.org/akwizgran/snooze) was killed when running overnight on the Redmi Note 7. [Locking the app to the recent apps list](https://code.briarproject.org/briar/briar/-/issues/1743#note_49341) prevented this from happening. We should recommend this during account setup, as we do for Huawei's protected apps and app launch settings.
(The user can also [change the app's background setting to "No restrictions"](https://code.briarproject.org/briar/briar/-/issues/1743#note_49269), which is recommended in various places but didn't help in the case of the Snooze app.)Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2027Pause polling when doing Connect-via-BT to specific contact2021-07-06T10:02:37ZDaniel LublinPause polling when doing Connect-via-BT to specific contactShould increase likelyhood of successful connection.Should increase likelyhood of successful connection.Adapt to changes in the Android platformDaniel LublinDaniel Lublin2021-04-30https://code.briarproject.org/briar/briar/-/issues/1919Password fields not focusable when navigated back to from the next page (keyb...2021-07-06T10:01:58ZIvanaPassword fields not focusable when navigated back to from the next page (keyboard doesn't come up when they are tapped)The test scenario was like this:
I type in my nickname on the first screen and I tap Next button. Then I proceed to type in my passwords, and click next (on the keyboard Next button).
A message comes up onthe next screen informing th...The test scenario was like this:
I type in my nickname on the first screen and I tap Next button. Then I proceed to type in my passwords, and click next (on the keyboard Next button).
A message comes up onthe next screen informing the user that briar has to stay connected and that they user should switch off the battery optimisation.
From that screen user navigates back to the password screen, because they changed their mind about what password to use and they want to change it.
The passwords cannot be changed because the keyboard doesn't come up when fields are tapped, so user cannot type. This was confirmed a bug in mattermost conversation (Testing channel, 3.2.21, around noon)
What should happen here? Should the user be able to chang etheir password from here?
Or should something else happen when they navigate back to the password page?
Please describe the details of solution in here so they can be re-tested when fied.
mp4 attached for your info.
![device-2021-02-03-124850](/uploads/2f3f336a75746a0b25efd7d786886283/device-2021-02-03-124850.mp4)Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/1961Implement UI of "Connect via Bluetooth" feature2021-07-06T10:01:35ZTorsten GroteImplement UI of "Connect via Bluetooth" featureImplement the design of #1960
Sub-task of #1821Implement the design of #1960
Sub-task of #1821Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2043Scrolling not happening automatically for own blog posts2021-07-06T10:01:09ZIvanaScrolling not happening automatically for own blog postsDescription:
Scrolling doesn't happen automatically for own blog posts - in portrait orientation
Steps to reproduce:
1. Create enough blog or reblog posts to have more than one full screen of them on a device
2. Then create one more ...Description:
Scrolling doesn't happen automatically for own blog posts - in portrait orientation
Steps to reproduce:
1. Create enough blog or reblog posts to have more than one full screen of them on a device
2. Then create one more new blog post
Expected results:
1. On own device, wn blog post should appear on top of the page.
Actual result:
1. The new blog post does not appear on top of the screen before manually scrolling to it, or before tapping the blue 'Scroll' word on the message that briefly shows on the bottom of the screen
![device-2021-05-17-132727](/uploads/c005cc532d63069bc98a3ef874ce4be4/device-2021-05-17-132727.mp4)Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2032Crash while trying to connect via bluetooth2021-07-06T10:00:56ZIvanaCrash while trying to connect via bluetoothSteps to reproduce:
Master: 2021-05-06 13:14 GitHash: 9dff8bd
Devices: HTC One M9 and Nokia 3.1
Device Settings: wifi= OFF on both devices. BT = ON on both devices.
App access to location and camera = ON on both devices
- Add a neaby ...Steps to reproduce:
Master: 2021-05-06 13:14 GitHash: 9dff8bd
Devices: HTC One M9 and Nokia 3.1
Device Settings: wifi= OFF on both devices. BT = ON on both devices.
App access to location and camera = ON on both devices
- Add a neaby contact on each device.
- Scan the QR code when prompted and verify that contacts are added OK on both devices and that they show status 'online'
- Go to device settings and switch the bluetooth setting OFF on each device
- This will result in the two 'nearby' contacts showing as being offline
- Now go to the menu for the contact added in step 1, and select Connect via Bluetooth - on each device
- Tap 'start' on both devices at the same time (as much as that is possible)
- Tap 'allow' to allow the device visibility to other BT devices during 120 seconds
Expected results:
- the BT setting on the device is turned on during this process
- the process concludes successfully
- user is given messages that the connection via BT was successful
- the contact show online and can send each other messages via BT
Actual results:
- The process starts off OK, and users get messages 'connecting via bluetooth', and then both devices crash before the process is completed.
- The BT setting on the device is switched on during the process - despite the crash
The two Android Studio logifles from the two crashes:
[crash_while_connecting_via_BT_10052021.txt](/uploads/c5535c39691cdb3eced22497eab14c67/crash_while_connecting_via_BT_10052021.txt)[crash2_while_connecting_via_BT_10052021.txt](/uploads/b608db975758dbd673beb6ac6fcb1ff2/crash2_while_connecting_via_BT_10052021.txt)
Crash report sent from Nokia 3.1 for both crashesAdapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/2005Connect Via Bluetooth shows error even if connection succeeds2021-07-06T10:00:49ZTorsten GroteConnect Via Bluetooth shows error even if connection succeedsIt can happen that we tell the user that no connection could be made even if it could be made.
It might help to show the error toast only after some delay.It can happen that we tell the user that no connection could be made even if it could be made.
It might help to show the error toast only after some delay.Adapt to changes in the Android platformIvanaIvana2021-04-30https://code.briarproject.org/briar/briar/-/issues/1823ViewModel migration2021-07-06T09:59:04ZakwizgranViewModel migrationhttps://code.briarproject.org/briar/briar/-/issues/1801Finish migrating ConversationActivity to ViewModel2021-07-06T09:58:45ZakwizgranFinish migrating ConversationActivity to ViewModelTorsten GroteTorsten Grotehttps://code.briarproject.org/briar/briar/-/issues/1800Replace controllers with ViewModels2021-07-06T09:58:13ZakwizgranReplace controllers with ViewModelsThe remaining ResultHander-based controllers should be replaced with ViewModels and LiveData.The remaining ResultHander-based controllers should be replaced with ViewModels and LiveData.https://code.briarproject.org/briar/briar/-/issues/804Self-destruct timer for messages2021-07-06T09:57:26ZTorsten GroteSelf-destruct timer for messagesDuring testing session #788 and during the first Briar presentation at Cryptorave, users asked if we support a self-destruct timer for messages like Signal introduced recently and like it is also supported by Telegram.
The user seemed t...During testing session #788 and during the first Briar presentation at Cryptorave, users asked if we support a self-destruct timer for messages like Signal introduced recently and like it is also supported by Telegram.
The user seemed to see less need for the feature after it was explained that this feature does not help against adversaries who also receive that message, because they can always retain it despite the self-destruct timer. Most users might not know that and get a false sense of security from such a feature. However, testers still found it nice to be able to let messages delete automatically in case they are forced to enter their password or somebody gets hold of their phone unlocked.Self-destructing messages2021-01-31https://code.briarproject.org/briar/briar/-/issues/1853Show a notice in the conversation when one party changes self-destruct timer2021-07-06T09:57:04ZTorsten GroteShow a notice in the conversation when one party changes self-destruct timerSort the conversation message items/headers by timestamp, work through them in order, and whenever the local or remote timer duration changes, insert a notice into the list.Sort the conversation message items/headers by timestamp, work through them in order, and whenever the local or remote timer duration changes, insert a notice into the list.Self-destructing messagesTorsten GroteTorsten Grote2021-01-31https://code.briarproject.org/briar/briar/-/issues/1862Show a bomb icon on the send button when the self-destruct timer is enabled2021-07-06T09:56:55ZakwizgranShow a bomb icon on the send button when the self-destruct timer is enabledSubtask of #804.Subtask of #804.Self-destructing messagesTorsten GroteTorsten Grote2021-01-31https://code.briarproject.org/briar/briar/-/issues/1835Automatically decline incoming blog/forum invitations when they self-destruct2021-07-06T09:56:40ZakwizgranAutomatically decline incoming blog/forum invitations when they self-destructWhen an incoming blog/forum invitation self-destructs without being answered, automatically decline the invitation. This may require a protocol update (coordinated with #1830) to flag the decline as an automatic response that shouldn't b...When an incoming blog/forum invitation self-destructs without being answered, automatically decline the invitation. This may require a protocol update (coordinated with #1830) to flag the decline as an automatic response that shouldn't be shown in the UI.
Subtask of #804Self-destructing messagesIvanaIvana2021-01-31https://code.briarproject.org/briar/briar/-/issues/2012Special bubbles not updating correctly when messages self-destruct2021-07-06T09:56:29ZSebastianSpecial bubbles not updating correctly when messages self-destructSelf-destructing messagesIvanaIvana2021-01-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-31