Phil Dreizen

Because at least two people have requested that I add comments, I've implemented a comment system. This isn't well tested by me or anything, so if you encounter bugs please let me know about them! And please, make feature requests. To leave a comment, you'll need to sign in with a 3rd party, like google or yahoo.

Adding comments introduces some...issues. So I wasn't originally in a rush to get it done.

The first issue is trying to combat spam. There are lot's of options to deal with it. Widely used options like recaptcha are in a war of escalation with spammers. As a result they've gotten so difficult to read, I find them too hostile to non-spammers like me. I considered rolling my own Ascii Captcha - it would generate random words in ascii art, and prompt the user to enter the word generated. (In fact, I DID develop this and chose not to use it...yet...) Though a system like this would be fairly easy to break, any time spent doing it would be specific to kupad.net, and not really worth a spammers time. There are services like akismet that probably use baysian categorizers and the like to guess if a particular comment is spam. akismet is widely used right now, it's probably a good choice. Right now I don't have any of these in place...I'm hoping that since I'm requiring an openid login, spam will be reduced, though I don't actually know that it will help in anyway. I do have a simple honey pot in place. Apparently, spambots can't resist filling in form fields, and so I have a form field (no display) that must be left blank for a successful comment submission.

Then there's the concern that comes with any user submitted data: security. Inviting users to comment invites users to try break into the site. (Things like SQL injection). And, especially since comments are displayed right back on the page, another concern is users leaving malicious javascript code in the comments they leave (XSS). Third party libraries like htmlpurifier help with the later at least.

And what to do about anonymous users? I ultimately decided that having some kind of identity will reduce flaming. So, in order to leave a comment, you'll need to authenticate using OpenID. You'll be able to use lots of services (Google,Yahoo...) to authenticate this way.

Finally is the fact that there will be bugs. So I'm looking forward to angry friends telling me how they tried to leave a comment but couldn't. Why did I bother implementing this from scratch again?

My girlfriend and I wanted a *secure* ip camera to watch her pet tortoise. Unfortunately, it's very difficult to find any cameras that are affordable that also can handle SSL encyrption - cameras with SSL functionality seem to be very expensive.

So I decided to use a Foscam FI8910W, which is an adequate and cheap ipcam - but has no SSL support - and use a Raspberry Pi to run an apache web server which would act as an SSL reverse proxy to the camera. The ipcamera would be restricted to the LAN only, but the raspi, which also lives in the LAN, would be accessable from anywhere. All access to the apache web server is SSL encrypted, so in turn, all access to camera outside the LAN is also encrypted.

People seem to ask, "why bother making the camera secure?" so often, I decided it was worth spending some time answering. I think an example is in order here: start by googling for allintitle: "Network Camera NetworkCamera" and look around. There are lots of search terms that find insecure cameras you can try. (This is a case where starting a page or two into the results will be better than starting from page 1.)

ipcameras have microphones, so anyone listening in can eavesdrop, and the direction the camera is pointing at can be controlled remotely via the web. So, someone getting access to the camera who shouldn't can see (and hear) more than just a pet you're keeping an eye on. And the password protection cameras without SSL encryption provides lend a false sense of security. The passwords are sent over the network in plaintext, so anyone with the right tools (a packet sniffer like wireshark) can see your password.

For this post, I'm not going to go into exact detail on how I set this up. (I may do that in a future post). But here are some pointers. First, you may need some help setting up the Foscam. I recommend looking at Linux compatible Foscam Wireless Netcams. Then you're going to need to set up the apache webserver. There's already a post that does go into some detail about setting up apache specifically for a Foscam here: Securing Foscam IP camera access over SSL with Apache reverse proxying. More detail on setting SSL on Debian, is useful for anyone running Raspbian on their Raspberry Pi, which there is a very good chance you are.

Finally, I should mention an annoying snafu I bumped into. The OTHER purpose of the Raspi I was using for this project is to be a XBMC Media Center, and so it is running Raspbmc. Raspbmc comes with iptables set up to drop all traffic outside the LAN. So you'll have to open up whatever port you have apache listening on by modifying:

/etc/network/if-up.d/secure-rmc

You'll have to add a rule like:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT

That will open the raspberry pi to the world. Well, once you configure your router to port forward to your raspberry pi anyway.

So...now I wonder...should I make a detailed tutorial?