Difficult to learn

This used to be mostly true. Javascript was a poorly documented language, often only documented in tutorial form by w3schools, or technically documented as ECMAScript. The absolute wealth of tutorials and blog posts made the good information few and far between. Largely when looking for information on how to perform a particular function you had to download some sample code and figure out how it was done based on that.

More recently though Javascript has caught the wave that is trying to standardize the web and this has somewhat improved the situation. Browser manufacturers are documenting their Javascript implementations and largely converging on a common standard. Additionally many helper libraries have been introduced to make the task of working on Javascript even easier. Once Javascript may have been difficult to learn, but as of late this is no longer true.

Javascript Documentation:

• Mozilla Developer Center – Javascript
• WebKit DOM Reference
• MSDN – JScript Language Reference
• Opera Libraries

Subtle differences in interpretation

This is is one of the biggest problems you still see in Javascript today. You will often find developers writing functions to simply deal with the differences between browsers, there are even entire libraries dedicate to to abstracting away the differences. If I had a dollar for every implementation of a function to get a XMLHttpRequest object across browsers, I wouldn’t need my job.

Unfortunately it is still however very important to know the differences between implementations of Javascript if you plan on writing anything that will run on more than one browser. These difference may be in the features available in the language, in the Document Object Model or in the way the browser handles CSS. Thankfully many people work on documenting the difference and abstracting around them in libraries.

Javascript Implementations Differences:

• Quirks Mode
• Browser Migration – MDN
• Web Browser CSS Support

Javascript Libraries:

• DOJO ToolKit
• Prototype
• jQuery
• script.aculo.us
• MiniAJAX

Random Thought: If only Facebook didn’t get in the way of Javascript all the time…

To attempt to rectify this SPF was created. To setup SPF you add either a TXT or an SPF record to the DNS zone you will be sending from. This record defines which servers are allowed to send mail that is coming from that domain. So on my domain danielhall.me I could publish an SPF record that says only my mail server is allowed to send mail that ends in @danielhall.me. Any mailservers receiving mail that is from my domain but not coming from an address listed in my SPF record can see that the mail is likely forged and throw it away. SPF works well in most situations but fails at a very common use case. If someone I send mail to tries to forward it to another address using an automatic process (no clicking forward in their client) then the mail will appear to come from my domain when it gets to the user it was forwarded to, however it will have came from the original recipients mailserver.

DKIM solves this problem by giving each sending mailserver a cryptographic key pair. The public keys is then published in a DNS record in that zone and stores the private key somewhere safe on the server. The server then proceeds to sign the headers (especially the From: header) and the body of all outgoing emails. This signature is then attached to the email as an extra header. When the receiving server get the email it gets the signature and uses that along with the list of signed headers to verify the signature against the public key of the signing domain. This means as long as the mail has passed through an authorised mailserver at any point it will be considered valid.

Setting up a DKIM is relatively simple process. You will need access to the  zone records for your domain and access to the configuration of all the mailservers which all mail originating at your domain passes through. You also need to be aware that signing mail makes it slightly more processor intensive to send an email. If you send a large amount of email this difference could be quite significant. If you’re using sendmail you may be able to alleviate it by switching to a less resource hungry MTA like Exim. You should also note that in some configurations DKIM can not be setup. For example if you use masquerading in sendmail DKIM will always fail as sendmail will modify the from header after signing.

Ultimately DKIM is a good move for the internet community at large, especially when combined with SPF. DKIM mail is assured to come from the sender and can be cryptographically proven so. While it does take more take a little more effort to setup and maintain it assures mail from your domain is secure and can be assured to have come from you or your company. Ultimately DKIM can protect your company against phishing attempts and boost your spam scores.

Random thought: What would Email look like if it were designed today?

Wireless networks can either be encrypted or unencrypted but in both these cases only the payload is encrypted. The packet headers which contain information about who the packet is addressed to and who it is from. The reasons for this are similar to why you might write a letter in code, but you would not write the envelope in code. In an unencrypted network the whole packet is sent in clear text including the envelope and contents. The difference between these analogies and how a real network works though is that to read the envelope you need to physically obtain it and there is only one copy. A wireless network broadcasts everything to everyone within 100 meters.

This isn’t really a problem if your network is encrypted as people will not be able to read it easily. If however your network is not encrypted its the equivalent of yelling out everything that you type into and read from your PC. Almost all banking websites will ask your PC to use extra encryption, but many other sites will not. So anyone in a 100 meter range of your computer or access point can watch everything you do on your computer.

What Google were trying to do was get a list of the locations of these access points. So they would have captured the headers of all packets they saw, grabbed the wireless routers address out of it and marked its location on a map. Except according to them they accidentally put code in that captured the whole packet. This meant that for all the unencrypted networks the Google Street View cars drove past they may have captured private information.

There is a class action in Germany against Google for capturing this data, and more can be expected elsewhere soon. Suing Google for this is like walking in to a public place, yelling out a bunch of private information and then suing anyone who happened to be recording at the time, or suing someone for writing down smoke signals you send to someone from the top of a mountain. If your access point is sending data unencrypted then every wireless device within 100 meters cannot help but hear your data, you’re just lucky most will ignore it.

If you really cared about your privacy you would at least make some attempt to restrict others access to your data. Not knowing is much an excuse as not knowing people were recording in that shopping mall. Don’t take your privacy for granted, check whether your network is encrypted, and if you don’t know how, get someone who does. Ignorance is not an excuse! This time it was Google, the next time it could be an identity thief.

Random Thought: If privacy is so important to people at the moment, what’s with all the data on Facebook?

Many sites offer web services, xml data and json encoded data. These can provide almost anything from the weather, to search results, to advanced APIs. To use these services from your site using javascript you’ll have to employ one of the methods below.

Signing Javascript

Firefox allows you to sign your Javascript and place it in a jar file. This will give your code more privileges, You can also request these permissions explicitly without having your code signed, but having a dialog box appear for every AJAX request could get very tiring for the user. Another problem with this approach is that it isn’t documented very well and its Firefox specific. The first link in the references section deals with this method.

Access-Control Headers

This is the w3 approved method of allowing a client from another domain to access your web service. It is a server side method and requires no changes on the client to implement. This is both and advantage and a disadvantage. If you have control over the server then this method is simple, otherwise (for sites such as Yahoo API or other public services) you will not be able to implement this. It should also be noted that this was implemented in Firefox 3.5 so it can’t be used with earlier versions, or other browsers.

To use this method you tell your service to output extra headers that tell the browser whether access was allowed or denied.

Flash Enabled xmlhttprequest

This method involves using an invisible flash player to perform the actual request then handing the result back to the Javascript for processing. Flash still performs permission checking by looking for a /crossdomain.xml file in the root directory of the domain the request is being made to. There are several libraries that implement this approach and a few even implement in a way which is compatible with xmlhttprequest. One downside is this Flash is required, though recently Flash is required for several major sites and most browsers will have it installed.

Add Sites To Trusted Zone

Internet Explorer allows and denies cross-domain based xmlhttprequests based on the security setting. This approach is likely not going to be used on the Internet as it requires user interaction and is Internet Explorer specific. On a corporate Intranet this is slightly less difficult but not by much.

Apache mod_proxy

With this method you use the same server you shared the page from to proxy the requests automatically to the server with the data you’re fetching. For this to work your version of Apache has to be compiled with proxy support or you need to have the mod_proxy dso loaded. This method increases the latency of requests as they must first go via your server. It should also be noted that this cannot be implemented in .htaccess file and must be done in the main configuration.

Manual Proxy

If you don’t have control over your servers configuration then you can mimic the above method by writing a script that forwards the variables required and forwards back the data. This approach can even be more preferable than the above method as it allows you to preprocess the variables and cache the data if required.

References

http://www.mozilla.org/projects/security/components/signed-scripts.html

http://dev.w3.org/2006/waf/access-control/

http://developer.yahoo.com/javascript/howto-proxy.html

https://developer.mozilla.org/En/HTTP_Access_Control

http://ejohn.org/blog/cross-site-xmlhttprequest/

http://ajaxpatterns.org/XMLHttpRequest_Call

http://ajaxpatterns.org/Flash-enabled_XHR

Random Thought: Can you use AJAX to make web applications cleaner?

EncFS is an encrypted filesystem based on FUSE. It transparently encrypts files stored in it and places them on another volume. This is in contrast to block level encrypted filesystems which transparently encrypt the data under the filesystem layer as it is being written to disk. Think of EncFS as a bind mount, except that the source for the mount is encrypted and the place it is mounted to is the only place it is available unencrypted.

The main advantage of EncFS filesystems is that when backing up only the files which have changed need to be backed up. This means it works perfectly with tools such as rsnapshot. Another advantage is that the filesystem doesn’t need a block of disk allocated to it and will shrink and expand as the files inside change.

Finally because this is all implemented with FUSE it is all done in userspace. No root access is required (apart from setting FUSE up) to create and alter encfs filesystems.

Setting Up an EncFS Volume

So the first thing you need to do to setup an encfs volume is to install FUSE and EncFS. If you don’t have root access you will have to ask your sysadmin to do this for you, otherwise follow your distribution specific method of installing new packages. On Fedora it is called ‘fuse-encfs’ and on Debian/Ubuntu its called ‘encfs’. On some older systems users wishing to use FUSE may need to be added to the correct group.

First you need to decide where you will put the encfs volume, and where you’ll mount it. I usually put mine in /home/daniel/.crypt and mount it to /home/daniel/crypt. But feel free to name it whetever you want. When you’ve decided run the EncFS with those arguments, for example to use the example I specified it would look like this:

<daniel@server ~>$ encfs /home/daniel/.crypt /home/daniel/crypt
The directory "/home/daniel/.crypt/" does not exist. Should it be created? (y,n) y
The directory "/home/daniel/crypt" does not exist. Should it be created? (y,n) y
Creating new encrypted volume.
Please choose from one of the following options:
 enter "x" for expert configuration mode,
 enter "p" for pre-configured paranoia mode,
 anything else, or an empty line will select standard mode.
?>

Standard configuration selected.

Configuration finished.  The filesystem to be created has
the following properties:
Filesystem cipher: "ssl/aes", version 2:2:1
Filename encoding: "nameio/block", version 3:0:1
Key Size: 192 bits
Block Size: 1024 bytes
Each file contains 8 byte header with unique IV data.
Filenames encoded using IV chaining mode.
File holes passed through to ciphertext.

Now you will need to enter a password for your filesystem.
You will need to remember this password, as there is absolutely
no recovery mechanism.  However, the password can be changed
later using encfsctl.

New Encfs Password:
Verify Encfs Password:

As you can see the directories don’t need to be created first. There is also a prompt for what security settings you want to use. Hitting enter will give you standard settings, but for something more powerful you should hit ‘p’ then enter. You can now proceed to place files in /home/daniel/crypt and they will be encrypted and placed into /home/daniel/.crypt. If you don’t believe me go ahead and check.

See? I told you so. Now you can unmount it using ‘fusermount -u /home/daniel/crypt’ and mount it again using encfs /home/daniel/.crypt /home/daniel/crypt and typing your password.

Random Thought: When travelling to other countries, local laws may mean that customs can search your laptop, including encrypted filesystems. You may have to reveal your key, or be arrested.

The Internet filter, quite simply put is technically infeasible. The filter will work by directing all requests from Australian users towards a site containing RC content to a filtering device. This device then relays all requests to that site to the actual server, unless a requests is made for a blocked page, which will instead return a page indicating the site is blocked. This is similar to the way the firewall in China and other countries with a national Internet filter. This method is effective in that it is often 100% effective (which means that every page on the blocked list is blocked, with no false positives) when done right. There is a problem however, this method does not scale well. If the government were to block a page on a large site (as was attempted to Wikipedia in the UK) then the filter would not be able to handle the load. Secondly it appears to the administrators of that site that all requests are coming from a few IP adresses. This could cause Wikipedia to eventually block all Australians either because the requests will look similar to a DDOS or because they have no way to distinguish between users and need to prevent abuse. Although the filter may be 100% accurate at blocking web traffic it will not be capable of dealing with many other varieties of Internet data.

The proposed filter will only be capable of filtering standard web traffic from web browsers. The Internet consists of a large number of computers talking in any number of protocols. While web traffic is one of these there are many other ways to exchange information. This filter will not be capable of filtering email, bit torrent, edonkey, gnutella, XMPP, DDC, SSH, VPN, TOR and that is only naming a small portion. Many people caught to have been in possession of child pornography and other illegal content are found to have downloaded it via peer to peer technology. This is because standard web traffic makes it easy to trace and identify the owner, where as peer to peer traffic can be hidden much easier. Secondly web traffic can be ‘tunnelled’ or hidden inside these other protocols and this way completely bypass the filter. This means anyone with sufficient knowledge or five minutes to learn will be able to configure their PC to hide their data amongst an SSH or VPN connection. These technical arguments come from my experience as a systems Administrator, but there are other arguments not so technical.

Steven Conroy has said that the filter will only deal with RC rated content, however there is no transparency about what will be blocked. The government can’t publish a list of sites that are blocked because that will effectively give people looking for this content a list of places to find it. Without knowing what sites are being blocked we won’t know if or when the government decides that they would like to start blocking sites that are debating for or against abortion, euthanasia or any other politically sensitive topic. It may be interesting to know that the definition for RC content includes pages instructing in any crime, which would include euthanasia. A representative for Steven Conroy has specifically stated the filter won’t be filtering pages related to euthanasia but because of this broad definition it could be changed at any time and we wouldn’t know until after the material was blocked.

I am a Unix Systems Administrator, and for the reasons listed above, and more covered better by other bloggers, I am opposed to the filter proposed by Senator Steven Conroy and the Labor government. I urge my readers who are also opposed to the filter to write to your local MP, to Senator Conroy, to Tony Smith (Shadow Minister Minister for Broadband, Communications
and the Digital Economy). If all else fails and the Government does not see sense then use your vote. The filter will not work and will waste taxpayer money that could be used in many better ways.

Random Thought: Will posting instructions about how to bypass the filter be illegal?

The user sees

You register your fingerprint using the built in reader and it saves it as your password. Next time you go to login you choose your username, swipe your finger and the PC verifies it against the one you scanned last time. If it matches then the computer logs you in.

What actually happens

1. You open up the fingerprint reader application on your laptop, it adds hooks into the Windows login system (Credential Providers).
2. You scan in one or more fingers and register them to your account.
3. The application stores the fingerprints for later use, some will even store them unencrypted.
4. When the user goes to login next time they select their username and scans a finger.
5. The fingerprint reader takes the scan and compares it to the previous scan
6. If the scan matches one of the stored scans then the user is authenticated

Why its not secure

How often do you write down your password? If you do where would you leave it? Now think about your fingerprint. Where would you leave your fingerprint? In general people don’t constantly where gloves and end up leaving fingerprints all over the place, on glasses, door handles, keyboards, touch screens and mobiles. It is a little bit harder to copy a fingerprint but security by obscurity is not an excuse. So it can be argued that a password is more secure (in that its harder to obtain) than a fingerprint.

Most fingerprint authentications allow you to use either your fingerprint, or your password. This effectively doubles the possible attack vectors for trying to get into the system. A malicious attacker can now either use a dictionary attack against your password, a fingerprint based attack against the fingerprint reader, or look for holes in either system.

Why it may actually endanger you

Do you know how the fingerprint reader is storing your fingerprints? Is it storing them as bitmaps, as a collection of swirls and whorls or as a md5 hash or some key identifiable features? If you can’t answer that question with 100% certainty then you should be concerned. If someone managed to hack your machine and retrieve bitmaps of your fingerprints then they could use them to open any other fingerprint locks you have, or implicate you in a crime.

Finally if someone is determined enough to break a law to hack your computer they could simply cut off your fingers to gain access to your PC. Of course if the fingerprint sensor has a warmth sensor they might need to microwave them first. I would hope though that you keep something that sensitive or valuable under all sorts on encryption and armed guards.

Don’t rely on fingerprint readers for added security, that is quite simply not the case. Fingerprint readers are primarily for convenience, and they could put your security and your wellbeing in danger.

Random Thought: What is this obsession with altering perfectly fine machines to remove an component that never bothers anyone? Dyson has the bladeless fan, and recently we’re seeing the spokeless bike. Have you ever looked at a fan and said: “Those blades really make that fan so annoying!”?

A daemon is a program that runs in the background. A daemon will usually be started at system startup and end at system shutdown. The exceptions to this rule are programs like the Bluetooth SDP daemon, which is activated when a new Bluetooth HCI is found,, and ends when it is removed. Daemons run transparently and do not normally interact with the user directly.

Daemons start as ordinary processes but they eventually ‘fork and die’ to start running in the background. Some daemons do only the ‘fork and die’ step but ignore other important steps. Here is a list of what a daemon should do:

1. Fork to create a child, and exit the parent process.
2. Change the umask so that we aren’t relying on the one set in the parent.
3. Open logs to write to in the case of an error.
4. Create a new session id and detach from the current session.
5. Change the working directory to somewhere that won’t get unmounted.
6. Close STDIN, STDOUT and STDERR.

These steps ensure that our association with the calling environment is destroyed and our daemon is now free to run as a completely separate process.

Lastly before writing the daemon you should make sure the code is written securely and in a way that fails gracefully. If your daemon crashes it will not be able to prompt the user about what action to take. The user may not even notice until it is too late.

Forking a child process

In Unix fork() is the only system call with two return values. When you call fork a child process is created which is a near copy of its parent (some things will be different in the child eg. process id). The fork command then returns a 0 in the child and the childs process id in the parent, on failure a -1 is sent to the parent. Generally a program will then check whether it is the child or parent by these return values (just like in movies when a cloned character will check to see if he has a belly button and hence is the original). Here is a snippet of code to do this:

pid_t pid;

/* Clone ourselves to make a child */
pid = fork(); 

/* If the pid is less than zero,
   something went wrong when forking */
if (pid < 0) {
    exit(EXIT_FAILURE);
}

/* If the pid we got back was greater
   than zero, then the clone was
   successful and we are the parent. */
if (pid > 0) {
    exit(EXIT_SUCCESS);
}

/* If execution reaches this point we are the child */

Changing the umask

Because we are a clone of our parent we’ve inherited its umask. This means the child doesn’t know what permissions files will end up with when it tries to create them. We do this by simply calling umask like this:

/* Set the umask to zero */
umask(0);

Open logs to write to

This part can be done in several different ways. You could open text files, log to a database or use syslog. The method I’m going to demonstrate here is to log using syslog. Syslog sends your log messages to a system wide logger, where they can be configured to be written to a file, send to a network server or filtered away entirely.

/* Open a connection to the syslog server */
openlog(argv[0],LOG_NOWAIT|LOG_PID,LOG_USER); 

/* Sends a message to the syslog daemon */
syslog(LOG_NOTICE, "Successfully started daemon\n"); 

/* this is optional and only needs to be done when your daemon exits */
closelog();

Create a new session id

Each process on a Unix system is a member of a process group (or session). The id of each group is the process id of its owner. When we forked from our parent earlier we will have inherited its process group, and our process group leader will still be its parent process. We want to create our own process group and become our own process leader otherwise we will look like an orphan. We can do this easily as follows:

pid_t sid;

/* Try to create our own process group */
sid = setsid();
if (sid < 0) {
    syslog(LOG_ERR, "Could not create process group\n");
    exit(EXIT_FAILURE);
}

Changing the working directory

At the moment we have the working directory we inherited from our parent. This working directory could be a network mount, a removable drive or somewhere the administrator may want to unmount at some point. To unmount any of these the system will have to kill any processes still using them, which would be unfortunate for our daemon. For this reason we set our working directory to the root directory, which we are sure will always exist and can’t be unmounted.

/* Change the current working directory */
if ((chdir("/")) < 0) {
    syslog(LOG_ERR, "Could not change working directory to /\n");
    exit(EXIT_FAILURE);
}

Closing the standard file descriptors

A daemon doesn’t interact with the user directly it has no use for STDIN, STDOUT and STDERR and we really have no idea where these are connected or where anything we write to them will end up. As these file descriptors are not required and effectively useless we should close them to save some system resources and prevent any related security problems. We close these descriptors like this:

/* Close the standard file descriptors */
close(STDIN_FILENO);
close(STDOUT_FILENO);
close(STDERR_FILENO);

Writing the payload

Now you have a C program that is capable of becoming a daemon, but its a pretty useless daemon if it exits immediately. Payload code is really up to you to design. I’ll offer you a few tips on designing your payload.

• Put your payload in a loop. Generally in a daemon you want to perform the same action over and over again until you’re killed. If you have to cleanup (such as closing syslog) when the daemon is about to be killed you should add an exit clause that will be activated by a SIGTERM signal handler.
• Make your code as fast an efficient as possible. This is something you should do with any program, but with daemons it is important that you do not hamper the performance of the rest of the system. This is especially true if you’re going to be running this daemon on desktop systems.
• Be aware that your code may be preempted very often. As your daemon is going to be running for the amount of time the system is up, it is likely that its execution will be preempted.
• Be paranoid about security. Daemons are common attack vectors and can be used to gain privileged access to a system. You should consider dropping any privileges that you don’t require.

Conclusion

So if we take all the code I’ve mentioned in this post and put it all together you have a simple daemon. You can download the source from the link here: daemon.c.
If your daemon is only going to be run on Linux and not on a System V style system such as Solaris you can use the daemon function to do a lot of this work for you.

References

Linux Daemon Writing HOWTO in C
Linux Daemon writing in C++

Random Thought: It appears the devil uses a Unix based OS, probably OSX.

Generics and parametrized classes allow Java programmers to place a type on a class and have that type inherited by its methods. For example you can now declare an ArrayList class with a type String. This alters the ArrayList class so that its add method now only accepts objects of type String, the get method now also returns objects of type String. This makes everything type safe which means you don’t have to cast anything and your code won’t compile if you try to put something in the ArrayList that doesn’t match its class.

Java uses parametrized classes to build its collections and you’ll want to use them too if you’re making your own collection class. For example if you were implementing a stack, a queue or a multi-priority FIFO queue are good cases for parametrized classes. Be careful though of the lure parametrized classes can have. They are not a replacement for polymorphism and shouldn’t be used when polymorphism would make more sense. For example if your multi-priority queue gets the priority out of the object itself then you’d need an interface that provides a method to get the priority. Then your class will only be able to accept items that implement that interface, which makes sense in this case as we need to priority to be able to store it.

A parametrized class is really simple to use. Here is an example implementation of a stack collection backed by an ArrayList:

import java.util.ArrayList;
import java.util.Collection;

/**
 * This class acts as a stack. Items can be 'pushed' which adds them to the top
 * of the stack. items can also be 'popped' which removes and returns the top
 * item on the stack and removes it. This means only the most recently added
 * item is available at the current time. To get to older items you need to
 * first remove the others.
 *
 * Note: Java already has a stack object that should probably be used in
 *       preference to this one. This is only an example implementation.
 *
 * @author Daniel Hall <daniel@danielhall.me>
 *
 * @param <T> The type of items that can be stored in the Stack.
 */
public class Stack<T> {
	/* Uses the same type as this class to store the items */
	private ArrayList<T> array = new ArrayList<T>();

	/**
	 * Creates a Stack containing items already in a collection. The collection
	 * must have the same parameterized type as this class to ensure that we get
	 * the right objects.
	 * @param c The Collection to initialize with
	 */
	public Stack(Collection<T> c) {
		array.addAll(c);
	}

	/**
	 * Creates an empty Stack object
	 */
	public Stack() {

	}

	/**
	 * Adds an item to the top of the stack.
	 * @param item The item which will be added to the top of the stack.
	 */
	public void push(T item) {
		array.add(item);
	}

	/**
	 * Removes the first item from the stack
	 * @return The item that was on the top of the stack.
	 */
	public T pop() {
		/* This gets the size so we don't have to do it twice. */
		int count = array.size();

		/* If the stack is empty return null, note that the Java implementation
		 * of stack throws an Exception instead.
		 */
		if (count == 0) {
			return null;
		}

		/* Remove the last added object (which will have index count - 1) */
		return array.remove(count - 1);
	}
}

Random thought: John Lions wrote a book about the Unix source code, in the seventies, which because it also included some code, was blocked from being published until 1996.