issue_comments

It might be possible with this library: https://docs.python.org/3/library/imghdr.html

quick test of the downloaded blob:

```

import imghdr imghdr.what('material_culture-1-image.blob') 'jpeg' ```

The output plugin would be cool. I'll look into making my first datasette plugin. I'm also imagining displaying the image in the browser -- but that would be a step 2.

As you can see, I'm pretty paranoid about serving content with Content-Type HTTP headers because I'm so worried about execution vulnerabilities. I'm much more comfortable exploring that kind of thing in plugins, since that way people can opt-in to riskier features.

You found datasette-media which is my most comprehensive exploration of that idea so far - but there's definitely lots of room for more plugins along those lines.

Maybe even an output plugin? .jpg as an export format which returns the BLOB column for a row as a JPEG image with the correct content-type header (but first verifies that the binary content does indeed look like a real JPEG) could be interesting.

Hi Simon

Just finding this old issue regarding downloading blobs. Nice work!

As a feature request, maybe it would be possible to assign a blob column as a certain data type (e.g. .jpg) and then each blob could be downloaded as that type of file (perhaps if the file types were constrained to normal blobs that people store in sqlite databases, this could avoid the execution stuff mentioned above).

I guess the column blob-type definition could fit into this dropdown selection:

Let me know if I should open a new issue with a feature request. (This could slowly go in the direction of displaying image blob-types in the browser.)

Thanks for the great tool!

edit: just reading the rest of the twitter thread: https://twitter.com/simonw/status/1318685933256855552

perhaps this is already possible in some form with the plugin datasette-media: https://github.com/simonw/datasette-media

This code needs these permission checks: https://github.com/simonw/datasette/blob/bf82b3d6a605c9ddadd5fb739249dfe6defaf635/datasette/views/table.py#L911-L913

So for https://latest.datasette.io/fixtures/binary_data the BLOB download URLs would be:

https://latest.datasette.io/fixtures/-/blob/binary_data/1/data.blob - that last bit after the primary key is to indicate the data column

With these headers:

• Content-Disposition: attachment; filename="binary_data-1-data.blob"
• X-Content-Type-Options: nosniff
• Content-Type: application/binary

Another useful demo database: https://datasette-render-images-demo.datasette.io/favicons/favicons - see https://datasette-render-images-demo.datasette.io/favicons/favicons.csv

Should this work just for BLOB columns, or should it work for other columns too?

For the moment I'm going to restrict it to BLOBs, since data from other columns is available through the UI whereas BLOB columns are not.

Actually I like .blob

What should the suggested filename be?

I think something that includes the table name, primary key and the name of the column would work.

How about a file extension? I guess .binary, then let the user rename it? Or .raw.

Possible URL for this: /db/table/-/blob/primary-keys - this would use the /db/table/-/ namespace proposed in #296.

Extra security idea: a blob_download_host setting which can be used to indicate a host that should be used for downloads - for example datasettestatic.com. If this setting is populated then binary downloads are served from paths on that host only, and no other Datasette URLs from that host will be served.

I think this plus the binary-CSV stuff in #1034 will justify a dedicated section of the documentation to talk about how Datasette handles binary BLOB columns.

I can also use a Content-Disposition header to force a download. I'm reasonably confident that the combination of Content-Disposition and X-Content-Type-Options: nosniff and application/binary will let me allow users to download the contents of arbitrary BLOB columns without any XSS risk.

https://security.stackexchange.com/questions/12896/does-x-content-type-options-really-prevent-content-sniffing-attacks says:

In Tangled Web Michal Zalewski says:

Refrain from using Content-Type: application/octet-stream and use application/binary instead, especially for unknown document types. Refrain from returning Content-Type: text/plain.

For example, any code-hosting platform must exercise caution when returning executables or source archives as application/octet-stream, because there is a risk they may be misinterpreted as HTML and displayed inline.

From https://hackerone.com/reports/126197:

archive.uber.com mirrors pypi. When downloading .tar.gz files from archive.uber.com, the MIME type is application/octet-stream. Injecting <html><script>alert(0)</script> into the start of the .tar.gz causes an XSS in Internet Explorer due to MIME sniffing.

So you do have to be careful not to open accidental XSS holes with application/octet-stream thanks to (presumably older) versions of IE.

From that thread it looks like the solution is to add a X-Content-Type-Options: nosniff header.

Twitter thread: https://twitter.com/dancow/status/1318681053347840005