Webcam and Annotation With HTML5

Nowadays, Webcam is widely used for both personal and business. It is simple, cheap, and yet powerful for image acquisition.

Some developers prefer to create their own webcam libraries. In this case, you need to learn technologies like TWAIN,WIA and/or DirectShow.

Note: the WIA and DirectShow APIs are recommended to develop a webcam SDK. TWAIN, however, is a good option for scanners.

However, due to the complexity of learning the APIs, as well as the technologies such as COM interfaces, it’s not an easy task for developers to create and embed Webcam SDK into their web applications. There are two options to simplify the whole process:

• Use a third-party plug-in/add-on to access and control the webcams, such as Flash, Silverlight, etc.
• Adopt the new technology – HTML5.

I will talk more about the second option in this article.

Webcam devices will be supported by the new video element and the getUserMedia API in HTML5. This means we can capture video streams and images from Webcam devices with just a few lines of JavaScript and HTML code, and the end users do not need to install anything for the browsers.

Information you need to know:

• HTML5 is not released yet. So this article is for early experimentations and it is not recommended to use the code snippet in the article for actual implementations.
• Currently only the following browsers support getUserMedia and WebGL:
  • Google Chrome (Version 21 and above) – Recommended for testing.
  • Firefox (Nightly Build, version 17 and above)
  • Opera (Version 12 and above, need to enable WebGL in opera:config)

Access the Webcam

Thanks to Wes Bos. He posted a wonderful article on how to access the Webcam. If you are new to HTML5, I suggest you read this article first (you can skip the content for ccv and scripts.js).

Basically, there are two steps:

1. Getting the Webcam stream

We use the getUserMedia API to get the stream.

 Collapse | Copy Code

navigator.getUserMedia_ = navigator.getUserMedia || navigator.webkitGetUserMedia || 
  navigator.mozGetUserMedia || navigator.msGetUserMedia;
//Get the API according to the browser.
navigator.getUserMedia_({ video: true, audio: false }, success, error);

Unfortunately, different browsers have different names for the getUserMedia API. So we have to check and pick the correct one in the first step.

When we call the API, video:true indicates that we want video access and audio:false indicates that we don’t want audio. Error function will be called when the stream is not accessible.

Success is the function to receive the stream:

 Collapse | Copy Code

function success(stream) {
	var domURL = window.URL || window.webkitURL;
	//start streaming via the video element
	document.getElementById(‘myVideo’).src =
	domURL ? domURL.createObjectURL(stream) : stream;
}

When you access the page, the browser will ask for the permission to use your webcam. If you click Deny, the web application cannot access the Webcam and it will trigger the error function.

2. Output to canvas

We have the video stream for the Webcam and now we can output the images to canvas element.

 Collapse | Copy Code

var video = document.getElementById(‘myVideo’);
var canvas = document.getElementById(‘myCanvas’);
var ctx = canvas.getContext(’2d’);
ctx.drawImage(video, 0, 0, canvas.width, canvas.height);

In the above code, we only capture an image from the video and draw on the canvas. So the question will be: how can we output the video? Well, you can set an interval and draw the image every few milliseconds, or, you can use therequestAnimationFrame API to perform an animation from the browser level. (You will find the sample in the attached source code).

Annotation

Annotation is always important for image processing. We can use it to mark or highlight some important information, add some notes, hide certain area, etc… If you have checked the face detection demo from Wes Bos, you will find it also useful for entertainment.

Since we have the canvas object, we can actually use the context of the canvas object to draw lines, arc, text or image on the canvas. It is pretty much just a simple annotation design (we won’t discuss the advanced annotation functions in this article).

You can find all the information from canvas and canvas 2D context.

For example, let’s draw a text on the video:

 Collapse | Copy Code

var canvas = document.getElementById(‘myCanvas’);
var ctx = canvas.getContext(’2d’);
ctx.font = “10px sans-serif”;
ctx.strokeText(“Hello World”, 0, 0); //output the text to (0,0)

Note: this code should be added into the repaint loop. Otherwise the text will be lost in the next repaint operation.

You can find a complete annotation sample in the source code .

Capture and save image from Webcam

Canvas object offers a method to save the current display to an image element. This allows us to capture and save both the image and the annotations.

 Collapse | Copy Code

var img = canvas.toDataURL(“image/png”);
window.open(img, “_blank”);

You can open a new window to display and save the captured image, or you can use the img element to hold the image.

A complete sample for Webcam and annotation with HTML5

Please test the web page as a web application (place the page in IIS/Apache/Tomcat/etc… and access the page via HTTP address). If you just double click the HTML file and run it from local file system, the browser will not be able to access the webcam resources.

Google Chrome Version 21 and above is recommended for the testing.

Download sample (source code included)

Conclusion

HTML5 provides a simple way for developers to create a webcam SDK. As you can see from the sample, we can easily enable our applications to interact with the webcams. However, this method also brings up some questions:

1. Compatibility with the browsers.
2. Security (since the app will access device directly)

Please let me know if you have the same concerns. Any comments are welcome.

20 ways to Secure your Apache Configuration

DECEMBER 06, 2005

Here are 20 things you can do to make your apache configuration more secure.
Disclaimer: The thing about security is that there are no guarantees or absolutes. These suggestions should make your server a bit tighter, but don't think your server is necessarily secure after following these suggestions.
Additionally some of these suggestions may decrease performance, or cause problems due to your environment. It is up to you to determine if any of the changes I suggest are not compatible with your requirements. In other words proceed at your own risk.

First, make sure you've installed latest security patches

There is no sense in putting locks on the windows, if your door is wide open. As such, if you're not patched up there isn't really much point in continuing any longer on this list. Go ahead and bookmark this page so you can come back later, and patch your server.

Hide the Apache Version number, and other sensitive information.

By default many Apache installations tell the world what version of Apache you're running, what operating system/version you're running, and even what Apache Modules are installed on the server. Attackers can use this information to their advantage when performing an attack. It also sends the message that you have left most defaults alone.
There are two directives that you need to add, or edit in your httpd.conf file:

ServerSignature Off
ServerTokens Prod

The ServerSignature appears on the bottom of pages generated by apache such as 404 pages, directory listings, etc.
The ServerTokens directive is used to determine what Apache will put in the Server HTTP response header. By setting it to Prod it sets the HTTP response header as follows:

Server: Apache

If you're super paranoid you could change this to something other than "Apache" by editing the source code, or by using mod_security (see below).

Make sure apache is running under its own user account and group

Several apache installations have it run as the user nobody. So suppose both Apache, and your mail server were running as nobodyan attack through Apache may allow the mail server to also be compromised, and vise versa.

User apache
Group apache

Ensure that files outside the web root are not served

We don't want apache to be able to access any files out side of its web root. So assuming all your web sites are placed under one directory (we will call this /web), you would set it up as follows:

<Directory />
  Order Deny,Allow
  Deny from all
  Options None
  AllowOverride None
</Directory>
<Directory /web>
  Order Allow,Deny
  Allow from all
</Directory>

Note that because we set Options None and AllowOverride None this will turn off all options and overrides for the server. You now have to add them explicitly for each directory that requires an Option or Override.

Turn off directory browsing

You can do this with an Options directive inside a Directory tag. Set Options to either None or -Indexes

Options -Indexes

Turn off server side includes

This is also done with the Options directive inside a Directory tag. Set Options to either None or -Includes

Options -Includes

Turn off CGI execution

If you're not using CGI turn it off with the Options directive inside a Directory tag. Set Options to either None or -ExecCGI

Options -ExecCGI

Don't allow apache to follow symbolic links

This can again can be done using the Options directive inside a Directory tag. Set Options to either None or -FollowSymLinks

Options -FollowSymLinks

Turning off multiple Options

If you want to turn off all Options simply use:

Options None

If you only want to turn off some separate each option with a space in your Options directive:

Options -ExecCGI -FollowSymLinks -Indexes

Turn off support for .htaccess files

This is done in a Directory tag but with the AllowOverride directive. Set it to None.

AllowOverride None

If you require Overrides ensure that they cannot be downloaded, and/or change the name to something other than .htaccess. For example we could change it to .httpdoverride, and block all files that start with .ht from being downloaded as follows:

AccessFileName .httpdoverride
<Files ~ "^\.ht">
    Order allow,deny
    Deny from all
    Satisfy All
</Files>

Run mod_security

mod_security is a super handy Apache module written by Ivan Ristic, the author of Apache Security from O'Reilly press.
You can do the following with mod_security:

• Simple filtering
• Regular Expression based filtering
• URL Encoding Validation
• Unicode Encoding Validation
• Auditing
• Null byte attack prevention
• Upload memory limits
• Server identity masking
• Built in Chroot support
• And more

Disable any unnecessary modules

Apache typically comes with several modules installed. Go through the apache module documentation and learn what each module you have enabled actually does. Many times you will find that you don't need to have the said module enabled.
Look for lines in your httpd.conf that contain LoadModule. To disable the module you can typically just add a # at the beginning of the line. To search for modules run:

grep LoadModule httpd.conf

Here are some modules that are typically enabled but often not needed: mod_imap, mod_include, mod_info, mod_userdir,mod_status, mod_cgi, mod_autoindex.

Make sure only root has read access to apache's config and binaries

This can be done assuming your apache installation is located at /usr/local/apache as follows:

chown -R root:root /usr/local/apache
chmod -R o-rwx /usr/local/apache

Lower the Timeout value

By default the Timeout directive is set to 300 seconds. You can decrease help mitigate the potential effects of a denial of service attack.

Timeout 45

Limiting large requests

Apache has several directives that allow you to limit the size of a request, this can also be useful for mitigating the effects of a denial of service attack.
A good place to start is the LimitRequestBody directive. This directive is set to unlimited by default. If you are allowing file uploads of no larger than 1MB, you could set this setting to something like:

LimitRequestBody 1048576

If you're not allowing file uploads you can set it even smaller.
Some other directives to look at are LimitRequestFields, LimitRequestFieldSize and LimitRequestLine. These directives are set to a reasonable defaults for most servers, but you may want to tweak them to best fit your needs. See the documentation for more info.

Limiting the size of an XML Body

If you're running mod_dav (typically used with subversion) then you may want to limit the max size of an XML request body. TheLimitXMLRequestBody directive is only available on Apache 2, and its default value is 1 million bytes (approx 1mb). Many tutorials will have you set this value to 0 which means files of any size may be uploaded, which may be necessary if you're using WebDAV to upload large files, but if you're simply using it for source control, you can probably get away with setting an upper bound, such as 10mb:

LimitXMLRequestBody 10485760

Limiting Concurrency

Apache has several configuration settings that can be used to adjust handling of concurrent requests. The MaxClients is the maximum number of child processes that will be created to serve requests. This may be set too high if your server doesn't have enough memory to handle a large number of concurrent requests.
Other directives such as MaxSpareServers, MaxRequestsPerChild, and on Apache2 ThreadsPerChild, ServerLimit, andMaxSpareThreads are important to adjust to match your operating system, and hardware.

Restricting Access by IP

If you have a resource that should only by accessed by a certain network, or IP address you can enforce this in your apache configuration. For instance if you want to restrict access to your intranet to allow only the 176.16 network:

Order Deny,Allow
Deny from all
Allow from 176.16.0.0/16

Or by IP:

Order Deny,Allow
Deny from all
Allow from 127.0.0.1

Adjusting KeepAlive settings

According to the Apache documentation using HTTP Keep Alive's can improve client performance by as much as 50%, so be careful before changing these settings, you will be trading performance for a slight denial of service mitigation.
KeepAlive's are turned on by default and you should leave them on, but you may consider changing the MaxKeepAliveRequestswhich defaults to 100, and the KeepAliveTimeout which defaults to 15. Analyze your log files to determine the appropriate values.

Run Apache in a Chroot environment

chroot allows you to run a program in its own isolated jail. This prevents a break in on one service from being able to effect anything else on the server.
It can be fairly tricky to set this up using chroot due to library dependencies. I mentioned above that the mod_security module has built in chroot support. It makes the process as simple as adding a mod_security directive to your configuration:

SecChrootDir /chroot/apache

There are however some caveats however, so check out the docs for more info.