Self-Elevating to make hosts file change in Windows

Working on a Windows machine without elevated permissions can often be difficult for developers. One item that is often useful to change is the ‘hosts’ file. IN Windows 7 and 8 you can often ‘Self-Elevate’ to run a file, but it’s not always obvious how to edit a file in this manner. Some simple batch files can be helpful in this case as you can elevate them to do the actual work requiring permissions.

For example to make all requests to ‘’ to be directed to your own machine…

@echo off
set hostspath=%windir%\System32\drivers\etc\hosts
echo >> %hostspath%
echo >> %hostspath%

To replace the existing hosts file with one of your chosing from your desktop. (NOTE: you can change this file or path to anything).

copy "%UserProfile%\Desktop\hosts" "c:\Windows\System32\drivers\etc"

A standard ‘hosts’ file in Windows appears as such:

# Copyright (c) 1993-2009 Microsoft Corp.
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
# For example:
# # source server
# # x client host

# localhost name resolution is handled within DNS itself.
# localhost
# ::1 localhost

Content-Security-Policy HTTP Header

There’s yet another new means to ‘help’ client User-Agents with preventing XSS on your websites.

In it’s simplest form you can simply use the following HTTP Header(s), the second one is for earlier versions of Webkit (Chrome/Safari):

Content-Security-Policy: default-src 'self'
Webkit-CSP: default-src 'self'

You can also add to the above to permit assets to load from other sources.
For example, if you were to permit javascript files from you could include:

Content-Security-Policy: default-src 'self'; script-src

Additionally, while failures are noted in the client’s browser console (that most users are not aware of), you can have them sent back to your server by adding a ‘report-uri’ attribute with an appropriate handler:

Content-Security-Policy: default-src 'self'; report-uri


Device Fingerprinting

Often it can be beneficial to ‘more’ uniquely identify your users. For applications this is trivial, but in a web browser this can be accomplished via only a few attributes.

  • HTTP – User-Agent, IP Address, Content types and languages accepted.
  • HTTPS/SSL – the keys and encryption methods available to a specific user may vary for each client configuration.
  • HTML5 – local storage and capabilities supported.
  • Geolocation – this is included in HTML5, but also supported in many clients without full HTML5 support, or via browser extensions.
  • JavaScript – Installed version – and many DOM attributes/capabilities such as timezone, installed plugins, screen sizes and fonts from the browser can be detected.
  • Java (Applet) – Installed version – this can often be used to get additional information regarding the client system directly from the VM or Operating System itself. (* Persistent Cookies possible)
  • Flash – Installed version – this can often be used to get additional information regarding the client system directly from the Operating System itself. (* Persistent Cookies possible)
  • Silverlight (for Microsoft Windows) – – Installed version and additional information from Operating System?
  • GoogleGEARS (deprecated) – Installed version and additional information from Operating System such as Geolocation


HTML5 speech input

Adding speech input to your webapp is much easier than it might first seem.
This is part of the proposed HTML5 enhancements to FORMS and is already implmented in some browsers.

Google Chrome (WebKit 534.24) added this in version 11 in April 2011.

XHTML compatible example:
<input type="text" x-webkit-speech="x-webkit-speech" speech="speech" value="" />

In this example, ‘x-webkit-speech’ is the proprietary attribute used by Google Chrome (WebKit). ‘speech’ is the expected HTML5 attribute when it is finalized.


Google ChromeFrame

There was some debate back when this was first revealed in 2009, but the use of ChromeFrame is still relevant for some organizations that are stuck on older browsers for legacy applications.

<meta http-equiv="X-UA-Compatible" content="chrome=1" /><!-- this is for all versions of IE -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE6" /><!-- this is for IE6 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE7" /><!-- this is for IE7 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE8" /><!-- this is for IE8 and lower -->
<meta http-equiv="X-UA-Compatible" content="chrome=IE9" /><!-- this is for IE9 and lower -->
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=IE6" /><!-- this is for IE9 and lower, passes Edge to others -->


  1. Installation can be done without Administrative rights on the Windows OS.
  2. Installation will append the ‘chromeframe’ version to the ‘User-Agent’ HTTP header sent by the browser to allow it to be parsed.