Some might have noticed that I was working on completely revising the SE-Uploader. I will make a separate thread about this, but an important change is that we can now share Cells or Notebooks as easy as it is with images. If you want an example evaluate the expression below:


This opens the notebook of the current code for the SE-Uploader directly on your local machine by decoding it from this image

Image to decode

If you want to know more, then please study this section of the README.md in the repository which includes many details.


As I see it, and as Sjoerd has pointed out too, there are some safety issues here and unfortunately, ease of use is indirect proportional to safety. Here are some thoughts:

Online vs. installed decoding function

Pretty simple: To decode the image back to a cell, notebook or other expression, we need a decoding function.

Pro: When we use an online-version of the decoding function, all users can access them instantly and they always use the latest versions. Therefore, the requirement on the end-users side is zero.

Contra: The user must ensure that no-one altered the link to the decoding resource. Otherwise, it would be possible that an attacker can substitute the link with his own which probably does harm on the end-users machine. This point directly leads to..

...Short snippet vs. readability

Above, I have use a short URL I created with my Google account.

Pro: The included code is very short and errors because of line-break issues can be avoided. Additionally, I'm not sure whether user would really check the correctness if the whole URL was used like here:


or the wrapped version here


Contra: A possible attacker could take the chance of using his own short URL and hoping no-one notices it. With his own decoding function he could do harm on the local machine.

Final words

Btw, there are three points to consider: A possible attacker can easily fork my repository and choose a name like halirulan and the final decode-URL would look extremely like the long one above. Differences would then be harder to see than with a short URL!

The second point is, that I could (and already have) easily set-up a sub-domain and then the decoding becomes


Disadvantage is, as already pointed out by Sjoerd, that my site has to be up- and running like forever. Otherwise, we risk many broken answers.

Finally, I we have by no means any influence on what is encoded in the image. Currently, the above decoder only prints cells or notebooks and everything else is not evaluated and returned with head HoldComplete. Nevertheless, this is not secure by any means.

Any opinions about this?

  • I would say we should probably be really careful when automatically opening notebooks. Why not leave it to the user to do a NotebookPut@@nbExpr? Also, I like a setup where users can choose between using the package once or installing a local package which can conveniently be updated. That seems to be the current situation anyway. The local package can remember the url of course, so ideally you would then only have to verify the url once. Another point is that we should not become lazy w.r.t. warning users about the risks of Importing a url. Commented Apr 17, 2015 at 10:20


You must log in to answer this question.

Browse other questions tagged .