I sure wouldn't want to reverse-engineer it. It uses a combination of techniques. No, I'm not saying what techniques it uses.
No, I wouldn't say so. Offhand I'd say that the ciphertext ends up being about twice to ten times the size of the plaintext.
No.
I dunno, maybe, but it was made and is hosted in Canada anyway. If you're from the US and are worried, you'll have to look into that yourself.
By default, LCE just encodes with default settings (erm). This provides as much security as you might expect; after all, all you have to do is paste the LCE code into the decode
box, and there you go. If you want better security, provide a password when you're encoding your message. Of course, the recipient will also need to know the password to decode. It's up to you to be creative and sneaky enough to make your recipient aware of the password without sending it along with the ciphertext.
I don't really want to get into making a database of private keys and all that.
Yep. The encoding involves an integrity check; if the message is tampered with it won't decode.
It's a very long cat and should be celebrated as such. However if you want to be creative about it, you may use the /, |, \, #, @, _ and space characters freely to modify the output.