Prompted by the disturbing privacy defaults in Windows 10 and an enquiry whether Webconverger leaked any intranet information, we reviewed Firefox defaults.

This review was accomplished with Wireshark, a tool that allows us to analyse every packet leaving and entering a Webconverger instance.

Strictly speaking these Firefox defaults don't leak any private information and elements like safe browsing should give an extra layer of malware protection, but in practice the network noise generated by these services are too risky for security. Some future exploit could masquerade as one of the services we turned off and it would have been very difficult to have noticed it otherwise. Furthermore "Safe browsing" doesn't really have value when a typical Webconverger deployment is locked on a customer's homepage.

So our quiet defaults from version 32 can be overridden by your own Firefox preferences with our prefs= API to turn them back on for example.

Webconverger 32 with non-noisy defaults and ...

As mentioned what was coming next in Webconverger 31 release, we did make boots a few seconds faster by closing #220! for details and Firefox 41 is included.

c3c1ee4c594b50557ffdca62d56ff1e4b8bb106c  webc-32.0.iso

Please download from our CDN. Please support our continued operation by purchasing a subscription.

No user tracking

In the course of comparing privacy defaults with our Windows competitors such as Kioware and SiteKiosk, we did notice disturbingly they have features to log where kiosk users surf to.

We don't and by design can't log user activity from our end for privacy reasons. What we suggest customers do, is track the kiosk from their Web analytics platform:


You could then use that expanded WEBCID for tracking the particular kiosk on your site. Of course that strategy only applies to Web sites the kiosk owner controls.

If you, the kiosk owner wanted to know how many visits a kiosk user makes of for example Gmail, we can't tell you! Competitors allow you to do that, but we don't because we don't want to infringe on the privacy of Webconverger users. If you, the kiosk owner, don't want your kiosk users to go on other Websites, you need to use one of our filtering options or simply use our user interface without a URL bar option.

We hope that our policy gives users more confidence to use Webconverger branded kiosks in public spaces, since their privacy will be respected if they are permitted by kiosk owners to surf private Web sites.

Posted Fri Sep 25 02:32:21 2015

UK to Singapore

tl;dr We are closing the UK entity in favour of operating exclusively via the Singapore entity which (almost) all customers have already been using for the last couple of years. All assets have (or will be) transferred to the Singapore entity. This does not effect our regular use of the MIT license. Business as usual!

As mentioned in the acknowledgements of Webconverger, the opensource kiosk project was founded by myself Kai Hendry in February 2007 and then in September 2007 formed as a private limited company (Company No. 6366403) in the UK.

In 2012 I decided to move to Singapore largely due to my now wife and I incorporated a Singapore entity on the 4th May 2012 (Company No. 201211208C). I did this at the time mainly to help myself get a visa, to stay long term in Singapore. Unfortunately as a small business, the EntrePass assumes you have received some venture capital and I've long decided not to take Webconverger down that "get big or go bust" road.

Nonetheless as my confidence grew I moved more and more accounts to Singapore. Having the money in Singapore obviously helps with paying the bills without transferring money back and forth. In the meantime the upkeep of the UK business became more and more tiring.

Seemingly never a couple of months would pass without the need to be made aware of new HMRC or European regulation. It's frustrating that HMRC can't communicate directly with businesses online in 2015 and that silly European tax laws came into force. To keep up with regulation I needed to pay an accountant at least 1500GBP a year to complete corporate and personal tax returns.

For those of you interested in doing business in Singapore, the costs of running a business are roughly the same as the UK, especially since you need to nominate a local director here as a foreigner. There is a tax honeymoon period, but that soon expires and you will be paying roughly the same UK tax corporate rate of ~20%. With especially the European Commission's VATMOSS in mind, yes it is easier to run a software company in Singapore than in the UK. And the weather is a lot better!

I would like to thank you in advance for your understanding and support, and I look forward to serving you long into the future wherever you or I may be physically located. That said, if any of my customers are passing through Singapore, please get in touch! -Kai (Managing Director)

Posted Thu Sep 17 09:14:50 2015

Webconverger's main competitor especially in the K12 school (assessments) market is Google with their Google Chrome OS aka Chrome{books,box} product, which is typically sold as a hardware and software bundle.

It's high time to post an update on a 6 year old Comparing Google Chrome OS blog, which demonstrated that we had support for inexpensive Netbook category of PCs and speculated what Google would do. Six years later and Google are domineering.

To summarise; the main advantages that Webconverger has over Google are:

  • Simpler, less is more. Less things to understand and we provide great customer service if you get stuck!
  • No lock-in as opposed to Google Cloud Print, specific hardware, (App) extensions & other office related services upsell... these are all proprietary ways for Google to lock you into their solution
  • We don't try to own your users, we don't ask users to login or register!

The products are comparable

Webconverger actually started before Google did, in 2007:


Google recently became somewhat transparent with their pricing. We too offer discounts, and based upon their resellers perpetual license page they charge 150USD whilst we charge 200USD.

ChromeOS pricing 2015

ChromeOS's perpetual Licenses seem analogous to our One off subscriptions. Like us they also do annual subscriptions, but oddly limited to North America. They charge 50USD per year and we currently charge 100USD.

We want to be competitive, so do please ask sales for a quote to beat.


The hardware is difficult to directly compare since they design their own hardware and subsidise it accordingly. For example a Chromebook at 250USD is a good price, though you need to remember you are effectively locked to running Google software on that hardware, limiting your choice and making your switching cost very high.

Webconverger does not design hardware. We focus on supplying software that will run on any PC. This broadens your hardware choice and software choices too. Have old PC stock you want to deploy Webconverger to? No problem. What to run in Virtualbox? No problem with Webconverger.

Google's embrace, extend and extinguish... via extensions

One of our system integrators reports why he chose Webconverger:

  1. The Chrome feature to allow a user to sign in to the browser itself is inappropriate in shared use environments. In practice users frequently forget to sign out! - Webconverger prevents this user misbehavior completely.

  2. Installing Chrome Extensions is quickly becoming a 'go to' way for malicious actors to get malware onto endpoints even without Admin rights and again Webconverger prevents this from becoming an issue.

  3. One other thing to note is that malicious Chrome Extensions 'follow' the Google user account from computer to computer. Any malicious Extensions must be deleted in the user account itself which adds to Administrator workload.

  4. Simply closing all tabs to get a fresh session is much faster than the login/logout required on a fat client.

In the education environment Webconverger rocks!

What is the price of freedom?

We do currently charge a little bit more for our software. However running unconfigured or trialling our configuration management with several machines for a week or two is free of cost. As a business supporting an opensource product, we want to attract and invoice large deployments. Deployments where choice, privacy and openness about the way their clients get on the Web are important. They choose Webconverger.

Please contact sales for a competitive quote!

Posted Mon Aug 3 07:30:47 2015

Two months ago was our momentous Jessie based Webconverger 30 release and since then we've: for details

Please download from and follow the USB imaging guide to put it on a USB stick! The sha1sum is 4032c86eefdcbcb3486f7e00661d1f9920fffdf7 for webc-31.0.iso.

What next?

We could really do with your feedback, help & support on a couple of goals for the next release:

If you can't code or have the time to, please purchase a subscription!

Other hardware news

Managed to integrate the EETI eGalaxTouch driver for some models of resistive touchscreens. It works well as your can see by this touch screen demo video and it's typically deployed in Point of Sales in retail. Unfortunately the driver is in a private branch since the End User of License is very limited and a good case study of how not to write a license. Please enquire to know more.

Recently obtained a ~130 USD Intel NUC NUC5CPYH and it works well as our single take NUC video shows. We have recommended this neat PC form factor before and thankfully they are getting better and cheaper.

Posted Thu Jul 30 06:59:01 2015

tl;dr Webconverger's current security model of enabling features through limited APIs is actually the right way to do it.

New functionality in Webconverger, means new APIs to control them. Since I can be too lazy to design an API, I've often thought about offering a shell API.

For example:


Which downloads and executes the script. Analogous to curl | sh "anti-pattern".

The pro with the shell API is that we can now create scripts on the fly, and so could clients to toggle some functionality like:

  • Copying in a style sheet and overriding style
  • Downloading service files and enabling / starting them (e.g. for motion detection hardware)
  • Installing some special driver or configuring xinputs
  • Tweaking wpa_supplicant@wlan0.service with wext for older wlan interfaces
  • Overriding SSL warnings or preloading internal SSL certificates
  • Probably most importantly: Freedom to create your own API!

So we can implement new functionality as clients needed them, without Webconverger requiring an reboot and upgrade!


HTTP Secure doesn't help. Just imagine if someone managed to compromise Every config could get an extra line:


Own4ge! 1000s of Webconverger machines could become zombies.

What about CODE SIGNING?

We could employ code signing on the shell API. I.e. before executing, we also download to check it's signed by someone trusted.

But who is going to be trusted? Ultimately, the Webconverger developer makes most sense. However this extra layer of security FAILs if the hacker managed to get the developers laptop where both GPG (for code signing) and SSH key (for git control) lies.

Too risky. Too much power in one place.

Lets get practical and think about security issues by:

  1. The speed in which they take to fix (how much downtime will there be?)
  2. The speed in which they take to detect (can we actually tell there is malicious code at play?)
  3. The impact of the security issue (will clients lose data or hardware?)
  4. The worst possible action customer needs to take (what does a client have to do?)

The shell= API would score:

  1. Once the machine is compromised, it can't be fixed remotely
  2. We probably cannot tell a machine has been compromised
  3. The entire machine will effectively be lost to the hacker. Completely owned.
  4. The client would have to re-install (which doesn't take long mind)

Back to the status quo

The reason that the APIs exist is to protect the Webconverger system from being permanently compromised. The APIs also offer crucially:

  • idempotency
  • safety from permanently damaging the system
  • they are tested before bring rolled out

So even in the case where is totally compromised. What's the WORST possible outcome?

What currently are the WORST POSSIBLE SCENARIOS?

Today the worst possible scenarios for Webconverger clients controlled by a compromised are:

homepage= is changed to point to some offensive site

As soon as the compromise was realised, restoring is as simple as cloning a git repository onto a Web host that the DNS dig +short points to. The DNS record's TTL for is 60 seconds. DNS is hosted at Route 53 and the Registration is currently with Dreamhost, both are protected by 2 factor authentication.

The point is, can be restored very quickly if compromised. So the "hacked configuration" with the offensive site can be mitigated quickly.

Denial of service

A cronjob, for example rebooting Webconverger every minute would lead to denial of service. Again this can be mitigated quickly since is completely managed in source control is designed to be easily restored. However the client would need to be rebooted.

Browser sessions are not cleared between users

The "noclean" API means that Webconverger would not delete the ~/.mozilla directory between sessions. This could jeopardise users privacy local to the machine, as cookies etc would be shared amongst sessions. Again, once this discovered, it is very quickly rectified by effectively a reboot.

Our current API design served by would score:

  1. Usually this would just require a reboot, but in the homepage= case with instantupdate, it could be quicker
  2. We have a git log of all the configuration changes, so we can tell if something is amiss
  3. The worst possible case is noclean mode, described above, which isn't nearly as bad as shell= potential of having root access
  4. Worst possible case with, the machine would require a manual reboot

Wait... what if the upgrade mechanism got compromised?

Now it's probably worth mentioning the elephant in the room. What happens if got compromised? The impact could be very bad (root), however note that upgrades only happen at boot with install versions. So there is a natural delay. Next the speed in which we can detect and fix a piece of malicious code injected into our repository should be VERY QUICK. is closely watched. Finally the worst possible outcome for a client is a re-install.

Keeping to the current slow API design

So, thanks the API's safety and the way is managed, these "worst possible" scenarios are far less risky, since they are severely limited, quickly and easily fixed by a reboot. The current security design is a LOT better than if the machine turned into a Zombie via a remote scripting interface like shell=!

The down side is that you need to request every new feature and we need to implement it as an API. It's more secure that way.

Posted Fri Jun 5 05:40:16 2015

As announced on twitter earlier this month, we achieved a significant technical accomplishment for Debian based derivatives doing the dreaded dist-upgrade.

A seamless upgrade. No config changes. No hoop jumping. No sweat. If you are running the install version that upgrades itself, you will now be based on Debian Jessie. The new "stable" major release of the underlying open Debian platform for Firefox that will be the basis for Webconverger for the next 3 years.

So we skipped version 29 and 30 marks the fact that we are on Debian Jessie 8.0. Hopefully the only difference you will notice is that this new release should run a bit better on newer hardware. There is an unfortunate caveat that if you are using a 486 kernel based Webconverger, your upgrade will not go smoothly. We noticed that most people using the 486 kernel were doing so mistakenly and we've asked the very few people that are affected, to please simply re-install with any version since 25. Usually you will find your machine to run better, since it's taking advantage of 686 multicore architecture. So yes, we are dropping 486 support.

The detailed changelog between 28.0 and 30.0 and of course this release includes the latest Firefox 38 at time of writing.

Many thanks to Matthijs Kooijman & Bizplay for helping realise this "no mean feat" of a release.

Notice a problem? Please let us know! Please download the new release from our CDN and the sha1sum is 9db8fb19bf63ab5d6b770f493bff825110d295c8. The webc-30.0 package list will show every package as being updated.

Posted Mon May 25 10:53:18 2015

On April 25th, we demoed and launched the Raspberry PI2 port of Webconverger at "Tech Saturday" with the following pricing:

Rpi2+Webconverger launch offer

The hardware is about 90SGD, making the software about 60SGD or 45USD. Which is about 22% cost of the PC pricing.

As a bundle and with TCO in the sense this software will be updated into the future, this is breakthrough pricing for getting into Web signage.

Webconverger is distributing the bundle in Singapore via 12geeks. This saves the hassle of following several installation steps involved in putting the software on a microSD card. If you're interested in the bundle, please get in touch with sales!

Posted Thu May 7 02:24:16 2015

28 booted up

2015 has been a busy year. New Android 5 and Raspberry PI2 ports give customers cheaper hardware deployment options. All these different device architectures managed consistently via

The PC x86 version however is our mainstay and this is our last release based on Debian Wheezy. Debian's stable platform lived up to its name. It has been rock solid. Thank you to the Debian project, its developers and users. The next version "jessie" should run better on new Intel hardware.

28.0's most exciting new feature is opted in with the instantupdate API option which allows you to change the homepage remotely for one or many of your devices in an instant. No reboot required! See the instantupdate demo. The technology behind this is Websockets and the service runs upon

The detailed changelog between 27.1 and 28.0 otherwise shows a raft of security updates and minor bug fixes. If you are Live user, you really must update for the Flash fixes alone. For install users... you should have nothing to worry about. Do double check the version on about: in case something is amiss.. it's never a bad idea to re-install (it only takes a couple of minutes)!

Coming soon: A major update where we will upgrade from Debian codename wheezy to jessie smoothly. Work in our testing branch is well underway and we hope to release the next version of "stable" soon after Debian makes the switch.

The sha256sum is ce422a67f18b8fbf97303bf421c0010f7d8af87b0c09fd78b9c281dca5cb9cbb webc-28.0.iso, please download from our CDN, where we are playing with some AWS credits for this release.

Posted Thu Apr 23 02:59:26 2015

Webconverger is sometimes compared to "thin client" solutions like those offered by Enterprise heavyweights like Amazon, VMWARE and Citrix solutions. In reality they are in a different market sector called Virtual Desktop Infrastructure. Nonetheless, it's a good exercise to compare a Webconverger to VDI for analysis.

This is our biased view and we would love to hear your feedback.

Network fault tolerance


If Webconverger goes offline, tasks like form filling will still work. Once a form is submitted it will retry until completed. Truthfully offline Web apps aren't quite there yet, though they should get better in the near future with technologies such as service workers.

Typically when a network connection is lost VDI solutions are unusable. Furthermore in some solutions, if the "management server" goes down, this can be another single point of failure. Better VDI solutions can operate without a "management server" by caching its configuration. Webconverger actually also caches its configuration, in case goes down.

To summarise, Webconverger wins since it is more usable and will be even more usable in the future, offline.


Webconverger page loads will indeed suffer from a poor connection. However Web delivery is arguably "Internet grade" than typically LAN based "premise" VDI solutions where certain network assumptions are made and which will lag on the Internet. Once a Web application is loaded, it's very responsive and usable.

If your end to end network is managed by yourself, then this argument is probably moot, however this is increasingly rare as things move towards a more cost effective "cloud hosted" VDI.

Webconverger is powered by the Web and therefore is much more robust and usable on poor internet connections.


VDI quickly advocate its solution as scalable. Webconverger has been specifically designed with an Internet connection in mind and will prove to be less of a burden on the network.

In summary Webconverger is very bandwidth efficient.

Control and management

An important component to "mass deployment" is control and management. With Webconverger you can streamline your business process by setting the default application even easier than you can with VDI solutions. Just update the homepage= URL, enter a password and any amount of machines attached to the configuration will have a new configuration applied on reboot.

However we do not allow administrators to monitor the exact screen of the end user as most VDI solutions do, for privacy reasons. Some Orwellian enterprises sadly require this invasive feature in order to be considered "enterprise grade".

To conclude, VDI has better controls, unless you care about end user privacy, and then you will want Webconverger.

Input & Output devices

Since Webconverger is limited to a Web browser for input and output for the end user, we are limited typically to abstracted Javascript APIs of:

  • keyboard
  • mouse
  • printers
  • touch screens
  • microphone
  • camera

Truthfully the microphone and camera access via getUserMedia APIs are variable, and it is unlikely to work well without careful consideration and testing of your hardware.

With VDI you typically have complete control of all input and outputs. So you can attach anything to your local device and you should be able to integrate it with your application as the vendor intended. Webconverger, or rather the browser currently is unable to support a range of devices like cash registers and smart cards which a lot of businesses rely upon. However there is usually an out of band (usually more expensive) alternative solution that can fulfill these use cases, such as logging in with 2 factor authentication or standalone electronic payment devices.

VDI wins here since it has better device control.

Legacy support for non-Web applications

Given a legacy (Windows) application, it's not reasonably possible to run that in a Web browser. This is definitely a strength of VDI solutions, as all sorts of odd legacy environments can be provisioned easily.

Webconverger is waiting for corporate infrastructure to migrate to SaaS and Web applications at that. The reasons to migrate to Web applications are several:

  • open an application to a greater Internet audience
  • leverage open standards
  • reduce complexity

Of course some apps just can't be migrated easily to the Web, like display or compute intensive applications. e.g. CAD/matlab

However when applications are indeed Web applications, the Web has a good track record of backwards compatibility. Often one reason enterprises are burdened with odd insecure legacy platforms, is due to broken upgrade paths.

VDI is a better technology for supporting non-Web platforms, though hopefully the Web can maybe one day support VDI in the browser, with projects like freerdp-webconnect which still has a long way to go.

Hardware requirements

Webconverger runs on any PC with 1GB of RAM. Also we recently started testing on lower cost Android 5.0 and ARM7 Raspberry PI2 devices.

Typically VDI solutions run on PCs on top of pre-installed Windows operating systems, making it a heavyweight stack. However there are dedicated "locked down" VDI "thin client" hardware which can be quite inexpensive. One negative point is that this hardware is often proprietary and there is some lock in. On the contrary system integrators are usually better geared to supplying VDI solutions, since currently to deploy Webconverger, you need to source the hardware yourself.

Over time browsers and the Web applications they host may ask for more and more memory, making the base Webconverger system slower and slower. VDI solutions like Amazon workspaces correctly argue their VDIs can be provisioned with more memory or CPU on the server side. We would like to argue any client hardware in our experience probably needs to be replaced every 5-10 years and that cycle basically keeps up with Web browser and application bloat in that time.


This is a complicated topic (devil is in the details!), though overall the two approaches share a similar security model, where the application and data are remotely hosted and not local.

Webconverger's main security strength is that it's not susceptible to key loggers and screen grabbers like all Windows based thin client applications tend to be. The VDI on the server might be well managed, but usually the underlying non-dedicated clients are poorly locked down.

To summarise, assuming you are running Web applications in your business, the Webconverger system certainly has the edge. Webconverger offers a better user experience on a frequently unstable Internet, it's less complex and offers better security than the typical vulnerable thin client running on Windows.

Posted Wed Mar 11 09:12:57 2015

Example deployments of Webconverger on a Nexus 7

Android 5.0's new features such as screen pinning and managed provisioning, has now enabled Webconverger to make a port without too much fuss, instead of say building a ROM.

At the time of writing, the current release is beta software and we are looking for interested testers!

For Android Lollipop

Why Android? Pros:

  • Better touch screen experience
  • In future we should be able to leverage Android's native IMEs and easily support Korean, Japanese & Chinese inputs
  • Android hardware is generally cheaper than PC hardware
  • Android hardware is easier to deploy, especially in the DOOH use case. You could deploy on an ANDROID >=5.0 TV!
  • TODO: Android is a better platform for pushing configuration updates, by leveraging Google Cloud Messaging


If you have an Android 5.0 (or above) device, check it out in the Play store. Thare are other Web kiosk apps in the Google play store, though they are not Opensource like our effort is. Futhermore now you can simply manage both Android and PC devices from our configuration service! That's a first!

Posted Mon Feb 9 05:18:02 2015