Tails

#3 Updated by bluewater 2015-01-09 23:51:01

intrigeri wrote:
> It looks like a good idea to me. Indeed, as you indicated with Type of work = UX, it need design. What screenshot would you want to attach? One that you’ve taken previously (yourself, manually), or one that WhisperBack would take? If the latter, what to do with the WhisperBack window?

TAILS already has an app to take a screenshot, so I’d say the option should be for whisperback to upload a screenshot previously taken instead of a one to take by whisperback.

#4 Updated by intrigeri 2015-01-10 08:35:28

> TAILS already has an app to take a screenshot, so I’d say the option should be for
> whisperback to upload a screenshot previously taken instead of a one to take
> by whisperback.

OK, makes sense. Then, how about making this feature request more generic, and allowing users to attach any arbitrary file to a bug report? (BTW, would a limitation to one single fine be good enough, at least for a first iteration?)

#6 Updated by bluewater 2015-01-13 17:00:21

intrigeri wrote:
> OK, makes sense. Then, how about making this feature request more generic, and allowing users to attach any arbitrary file to a bug report? (BTW, would a limitation to one single fine be good enough, at least for a first iteration?)

this would pose a security risk. A few days ago I read about an Egyptian security researcher who hacked facebook servers by infecting a pdf file with malware and uploading it to the facebook jobs websites as his cv. So any file uploaded via whisperback carries the risk of being infected. Whereas a text based report does not carry this risk. Please take this in consideration.
I think limiting the upload to 3 files is better. 1 might not get the whole picture. But making it unlimited opens the servers for DoS attacks by flooding it with files. So I think 3 files limitation is good.

#7 Updated by intrigeri 2015-01-13 17:08:02

redmine@labs.riseup.net wrote (13 Jan 2015 17:00:21 GMT) :
> this would pose a security risk. A few days ago I read about an Egyptian security researcher who hacked facebook servers by infecting a pdf file with malware and uploading it to the facebook jobs websites as his cv. So any file uploaded via whisperback carries the risk of being infected. Whereas a text based report does not carry this risk. Please take this in consideration.

Sure. That will need to be conveyed to Tails frontdesk people, who are handling these incoming bug reports.

> I think limiting the upload to 3 files is better. 1 might not get the whole picture. But making it unlimited opens the servers for DoS attacks by flooding it with files. So I think 3 files limitation is good.

It seems to me that a size limit would better address this problem than limiting the number of attached files. OTOH, the SMTP relay that’s forwarding these bug reports supposedly has Postfix’ default size limit for messages, so most likely we don’t need to enforce this on the client side.

#8 Updated by sajolida 2015-01-13 18:33:05

> so most likely we don’t need to enforce this on the client side.

We should for UX reasons: we don’t want the user to try to upload 10MB
of attachments and then only get an error back from Postfix on the
server. I think that this should be checked upfront.

Regarding the number of files, I admit that when people attach
screenshots to their non-WhisperBack reports they tend to attach various.

#9 Updated by intrigeri 2015-01-13 20:01:26

> We should for UX reasons: we don’t want the user to try to upload 10MB
> of attachments and then only get an error back from Postfix on the
> server. I think that this should be checked upfront.

Ah, right, good catch!

#21 Updated by sascha.markus@gmail.com 2018-07-26 08:53:02

sajolida wrote:
> Hi Sascha, thanks a lot for working on WhisperBack again!
>
> I couldn’t download your screenshot from Redmine this time. Maybe the ‘»’ characters in the file name were not handled properly by Redmine…
This is an good hint. This char is part of the default filename pattern if you create a screenshot in debian with the german language.
So for the we might do some ascii folding to make sure the files can be opens be the helpdesk people.

> Then I tried to copy the .ui file into the source code (based on master) and got some error messages. So I opened the .ui file in Glade and I think I got the idea!
>
> In such cases, what I find easier to review are Git branches, but take it easy if that’s complicated for you.

Sorry. Just opening Glade was the idea but missed to explain it in the comments.

>
> I’m attaching my proposal for the interface and here is my rationale:
>
> * Since we want to limit the size of the attachments, as you said, we should display the size of each file, the total size, and the maximum. From my experience, users have a very hard time dealing with file sizes, so every bit of help will be helpful.
> When the user adds a file that goes beyond the maximum file size, we could display the following error message:
> I also considered adding a notification below the [Browse…] button but I thought that it would be harder to implement and get right.
>
> […]
>
> * I’m displaying the max size in kB as well. I bet than screenshots at least will always be in kB and that our limit will always be below 10 MB, so writable with 4 digits which is not too long. This way we avoid people having to switch mentally between kB and MB.
>
> * I’m adding a button to take a screenshot. The button would start GNOME Screenshots as people might otherwise not know how to do that (and it’s a useful shortcut anyway). Do you think it will be possible to get back automatically the filename of the screenshot once GNOME Screenshots exits? Otherwise no problem, but the button will still be useful.
>
I tried a bit. I didn’t find a way to get the filename.
> * I went straight for an expandable list of screenshots (and not a fixed list of 3 screenshots) because I guessed that this might not be the hardest part of the code. An interface for a fixed list of screenshots would also look quite different (with different error messages, etc.) and we might have to recode a lot of stuff if we start with a fixed list. But if that’s quite complicated, I can adapt my proposal to a fixed list.
>
> * In the list of screenshots we need something to remove screenshots (as a way of providing an “undo”). I was doubting whether to use a trash icon (/usr/share/icons/HighContrast/16x16/places/user-trash.png) or a cross icon (/usr/share/icons/HighContrast/16x16/stock/gtk-cancel.png) but I thought that the cross icon might not look enough like a button if the list is a simple list of text on a gray background. On the other hand a trash icon could be interpreted as “putting the screenshot in the trash” which is not the case. If you think that the cross icon looks good, please try that.
>
> And stuff you could skip for a first implementation:
>
> * The paperclip icon (/usr/share/icons/HighContrast/16x16/status/mail-attachment.png) on the left of the list is bonus if that’s easy :)
Should this just tell the user “This will be attached”? In this case I’d rather not add it. It just takes away space to display the filename smaller. And in the same row we have an icon which performs an action.
>
> * For now, it sounds safer to limit ourselves to screenshots only. So the file chooser when clicking [Browse…] should filter images only (PNG, JPG, anything else?). I also thought it could default to ~/Pictures which is where GNOME Screenshots stores its files by default.
>
> * I’d like the file name of the screenshot to be clickable and open GNOME Image Viewer, as a way of helping people check the content of what they are submitting. I don’t think that we need to put anything visible to allow that and making the file name clickable should be enough (black on gray with no underline).

I had a look at the filechooser when I created my prototype. We can filter be filetype image/*.
For the Gnome Viewer: what about a magnifying glass next to the undo?

I’m rather busy these days so I won’t make it in time for the 3.9 schedule.

#22 Updated by sajolida 2018-07-29 11:35:00

> This is an good hint. This char is part of the default filename pattern if you create a screenshot in debian with the german language.
> So for the we might do some ascii folding to make sure the files can be opens be the helpdesk people.

Good point!

>> * I’m adding a button to take a screenshot. The button would start GNOME Screenshots as people might otherwise not know how to do that (and it’s a useful shortcut anyway). Do you think it will be possible to get back automatically the filename of the screenshot once GNOME Screenshots exits? Otherwise no problem, but the button will still be useful.
>>
> I tried a bit. I didn’t find a way to get the filename.

Then forget about that. A button that only opens GNOME Screenshots will
be helpful already.

>> * The paperclip icon (/usr/share/icons/HighContrast/16x16/status/mail-attachment.png) on the left of the list is bonus if that’s easy :)
> Should this just tell the user “This will be attached”? In this case I’d rather not add it. It just takes away space to display the filename smaller. And in the same row we have an icon which performs an action.

Ok, fair enough!

>> * I’d like the file name of the screenshot to be clickable and open GNOME Image Viewer, as a way of helping people check the content of what they are submitting. I don’t think that we need to put anything visible to allow that and making the file name clickable should be enough (black on gray with no underline).
>
> I had a look at the filechooser when I created my prototype. We can filter be filetype image/*.

That’s great!

> For the Gnome Viewer: what about a magnifying glass next to the undo?

I thought that making the file name clickable would provide a bigger
clickable target and avoid adding one more visible element while still
being easy to discover.

But I’m not against the magnifying glass, then in addition to making the
file name clickable (which doesn’t hurt).

> I’m rather busy these days so I won’t make it in time for the 3.9 schedule.

No problem!!!

#24 Updated by syster 2020-05-13 12:01:22

Hey Sascha,
great that you’ve been working on “Add an option to attach screenshots to WhisperBack reports”.
Are you still interested/have the capacity for it?
If you have any questions/need support to move on this issue, don’t hesitate to reach out to us.