We can attach image files but not .zip (or other compressed formats). This would be very handy for some usage examples.
just link to external file service
Sorry, not clear. You mean make a link to some external URL? (that’s not what we do when attaching images).
What I want it to be allowed to drag-n-drop a zip file.
As far as I know I believe that the reason that zip files are not allowed, is that they can be a security hazard if downloaded blindly?
If I have a very complex inquiry, what I do most of the time is just make a short github repos - then people can have a look at the code and see if it is something they want to help with or not, without a bigger hassle for them.
Kind regards
5 Likes
@Ahmed_Salih Thanks for the input, but what would be the difference in terms of security from linking to an external invented_zip_location?
I wouldn’t download any zip, not from here and not from an external source. Risk too high.
7 Likes
Atleast on Github you can view the contents of a file before downloading, not all other services provide this. Still as @oheil mentions, nothing good can come of downloading an external zip file where you are not sure of recipent etc.
It is just a security hazard which is not worthwhile opening up imo.
Kind regards
Common anti-virus programs do scan inside zip files, and thus Discourse could check them when uploading takes place?
Also, a certain level of trust could be required from the user in order to be able to upload.
In what context would this be the right thing to do vs just putting the files in a more-or-less throwaway GitHub (or alternative) repo?
3 Likes
If an external source is throwaway then the documentation function of the discourse thread is lost. People come to see what was learned but all the relevant files have long since disappeared.
I like Rafael’s idea based on a trust level (all Discourse users have an associated kind-of trust level).
I thought on .zip because it’s a convenient way of allowing different formats. The case that triggered this suggestion was actually one where I wanted to attached a text file, but because many times what counts is the extension and not the (text) content, zipping is a handy way. I antecipate, however, other cases where one might want to attach a netCDF or HDF file. All off them could put in the same zip bag.
Another reason. If I’m desperate for help I would certainly give myself the extra work. If, on the other hand, I’m trying to help I will simply not do it.
I did not necessarily mean that the “throwaway repo” would actually be deleted. I just meant that you put it up online somewhere else that was publicly accessible, yet not necessarily greatly documented or discoverable or intended to me maintained. A simple repo titled “FilesJuliaDiscourse20211031”, for example.
Also, I would imagine that allowing file uploads would dramatically increase the storage+hosting costs of the forum, which may not be worth it.
Right, file size should be limited to small files and the situation would nowhere be different then current one of attaching images (which is an allowed feature).
Yeah, I don’t think we should do this for all the reasons listed here and more. Arbitrary zip/tar archives are just highly abusable. We actually don’t have control over the max upload size here — I think it’s fixed at 10MB, but I can’t even see that value. We do have limits on our total site-wide storage use.
The one addition I could maaaybe, pooossibly see, though, is CSV. Yes, text is wildly compressible, but it’s also a de-facto plaintext standard. That said, apparently allowing non-image uploads (at least used to, six years ago) degrades the image UX.
5 Likes
At least text files would be already a plus. And 10 MB for images is a LOT. In GMT forum we have apparently 4 MB but I get too big warnings at arround ~> 1 MB
Yeah, I don’t have those settings, I think because we’re a hosted instance.
1 Like