I though it was about time to add a logo to the site. I’m not a graphic designer so I just imitate what I can.

The basics of a logo is that it has to have a unique twist that sets it apart and it also has to be usable. This means recognizable at different sizes and in different contexts.

The theme is a mix of traditional publishing (coming from LaTeX) and modern web (this service). For this reason I chose an extra bold italic serif L from the Simonetta font (standing for “LaTeX”) and a preceding extra bold sans serif M from the Changa One font (standing for “Multi”). The M is superscripted as a homage to the way TeX and LaTeX are written. (You’ll have noticed that I never write Multilatex as MultiLaTeX because I believe it’s silly to mix up names and logos.) Someone could look at it and just see a single long looping curve, but there is a bit of reasoning behind it. To make it more visible I also created a rectangle one.

I created the SVG with Inkscape and I used Fontello to convert it to fonts usable in browsers.

The whole favicon situation is horrible, so I used Iconifier to generate all the favicon sizes.

I won’t go into styling the website any more now, so I haven’t picked a color theme. The logo will be just white or black.

TeX is a powerful language and thus it can be dangerous. Whenever executing arbitrary code from unknown sources one has to be careful.

I will have to build a system in Node which sandboxes pdflatex so that it can produce no harm to the rest of the system.

Shell code

One of the first problems is that LaTeX can be made to execute arbitrary system commands with the \write18{command} construct. This is usually disabled by default but it’s best to disable it completely with the -no-shell-escape argument.

Bad usage

TeX is a Turing complete language so (as with C++ templates) one cannot determine ahead of time if compilation will ever finish.

LaTeX is huge, so it’s likely there are many yet undiscovered problems in its packages that can be triggered to fill the memory or enter infinite loops.

The best solution to these problems is to run the tasks as multiple Linux users which are limited appropriately. This means limiting:

• where the user can write;
• how much virtual memory he can use (with ulimits);
• how much CPU time he can use
• and others.

Infinite loops can be managed by setting a time limit for generating the PDF after which the pdflatex process is terminated.

Bad usage could be intentional by malicious users, but it’s more likely that it’s accidental so human users should be presented with the errors.

Other

There are other ways you can influence the system like writing output files with the newfile package. One could clog the system with large files. This is also solved by setting Linux user limits.

Doing it

I am now in the process of writing the prototype for the site so I won’t be doing exactly this. I’ve actually added a disclaimer in the footer about the site being in pre-alpha.

In light of the somewhat recent revelations of Adobe’s password leak I think it’s important to stress the importance of secure storage of passwords.

I use the simple and secure method of hashing with SHA1 and unique salt. Technically, bcrypt is better, but I don’t have the hardware resources for that.

Hints

Adobe’s leak included the password hints which led the the amusing suggestion by XKCD of creating huge crossword puzzle which was eventually made.

I disagree with password hints exactly for this reason: it gives others ideas. If you forgot your password you’re better of reseting it.

Third party logins

Some say that the best way to store passwords is to not do it at all: let other services handle that. I disagree with this because it’s not a good idea to depend on others.

But if you do go down that path, which services should be allowed? Everyauth, which is a popular package for authentication in Node, supports more services than I can comfortably count.

I’ve chosen to not do this for now, since it doesn’t bring me any benefit, but I might in the future add options for strategic ones like Dropbox and GitHub (for the purposes of integration).

Quick signup

Instead of allowing people easy login by connecting with account they already have on other sites, I’ve chosen to not ask much on signup. I’ve included a sign-up box on the main page with three fields: the desired username, password and password confirmation.

All other information (real name, email address, birth day) can be entered when desired.

Other notes

I don’t have a certificate yet so I’m not using HTTPS. This makes authentication rather insecure so I’ll have to get one later.