Embedded images cannot be viewed via right-click

I often use ssb to share pictures, and will then copy the external link to my own viewer instance, to share with friends and family. Some of them will actually want to see the images in full resolution, but right clicking on them to see the image forwards to a raw blob url and ssb-viewer does not return a content-type header for those. The result is that the file will be an unusable abcdef.sha256-type filename and the person has to then...

1. Save the file
2. Guess the right file type (or use file from the commandline to guess it)
3. Rename the file
4. Open the image with an external viewer

That's pretty much untenable, especially on mobile (which some of my friends & family use because those often have quite nice, bright screens with high pixel density)

@Daan can you share an example message/blob and which browser(s) your are seeing this in? My assumption was that the browser would do content sniffing to detect that it is in image, so I am in interested to see where that is not happening. We can also just do the content-sniffing in ssb-viewer to send an HTTP header. That is done in e.g. git-ssb-web.

This happens for any image attachment on my viewer instance at least. Example: https://ssb.muchmuch.coffee/%25U13iMbNEjhdpAoNb2vwpD4iLBj0YiTfR2oZzq2awlKw%3D.sha256

Browser-wise this happens on any Firefox version I tried (including nightly) and also on chromium.

However, I just realized there's an easy check whether this is a config issue on my viewer, and indeed this link works fine with Firefox and chromium: https://viewer.scuttlebot.io/&5G+cePXuwiBGFgm9ufEHbH7QhS8/8h5WhyDrt89RfZ0=.sha256

However, I don't see any content-type headers being returned in either case, so I don't get why the browsers correctly interpret one set of bytes but not the other...

@Daan your web server reverse-proxy appears to be adding this header:

X-Content-Type-Options: nosniff

That header tells the browser not to content-sniff. So the browser treats the response as some opaque data. Is this header needed?

Very likely not necessary, and totally an artifact of me not being a webadmin.

Great, then it's just a matter of config. I'll figure it out and maybe drop a line into the readme. :)

So indeed the option was explicitly set by me. However, not being a security person I probably copied it from some article on "how to secure nginx".

Here's what the mozilla docs say about that header:

This header was introduced by Microsoft in IE 8 as a way for webmasters to block content sniffing that was happening and could transform non-executable MIME types into executable MIME types. [...] Site security testers usually expect this header to be set.

So a config change will do, but it might be worth thinking about this since the prospect of inadvertently hosting malicious files like that makes my tummy hurt. :|