A position paper by Paul Downey on behalf of Osmosoft for the W3C Workshop on Security for Access to Device APIs from the Web to be held 10-11 December in London. This document was authored as a TiddlyWiki, a snapshot of the contents being submitted to the workshop as a static XHTML file. The originating TiddlyWiki is available from http://osmosoft.com/~psd/TiddlyWikiDeviceAccess and is published under a W3C Document License
The Workshop call for participation describes the Web as becoming a "ubiquitous development platform" where "application developers have a need to access features available on the computers or devices on which their Web application (through a browser or through a widget) is running". This statement, along with the assertion "The Web is becoming a compelling alternative to locally installed applications", matches our experience, however we would like to draw the Workshop's attention to a class of application which falls somewhere between these two extremes, that of HTML Applications.
Sometimes dubbed "Single Page Application" (SPA) or a "client-side mashup", a HTML file opened from a file URI enjoys greater privileges than a server hosted Web application, whilst remaining compatible with a wider variety of browsers and operating environments than desktop widgets which rely upon vendor specific browser extensions or locally installed applications.
A HTML file served from a HTTP URI is constrained by the security model of the Web browser, in particular with respect to:
A HTML file opened locally in a browser, from a file URI, is typically subject to fewer of these restrictions. The relaxation of these restrictions differs between browsers and operating systems and is apparently not widely understood or employed, with the notable exception of TiddlyWiki.
Microsoft HTA, is a formalisation of the concept of a HTML Application, is confined to Windows systems and has a different security model to files with a .HTML extension opened inside a browser.
Microsoft formalised the concept of the HTML Application as HTA, a package format which expands to a directory structure containing a HTML file along with other assets such as CSS, JavaScript and image files which together provide a Web like experience which may run offline. A Microsoft HTA file downloaded from the Web onto a Windows computer results in a similar challenge to that offered as a result of downloading an executable. Once access is granted by the user, the application has the ability including the ability to execute commands against the document, or portions of the document through the JavaScript execCommand method.
HTA is specific to Microsoft Windows, and may be run outside of the browser This differs to the cross-platform story of .HTML files, running inside a browser, illustrated by TiddlyWiki.
TiddlyWiki is an Open Source wiki implemented in a single HTML file containing CSS, JavaScript and the content stored in a series of sections, or Tiddlers. You are encouraged to read a TiddlyWiki by following links rather than sequentially, which a number of authors have found a novel medium for writing, promoting a distinctive writing style.
In addition to textual content, a tiddler may be a plugin containing additional JavaScript and CSS to extend TiddlyWiki and has resulted in a wide variety of adaptations and Use Cases beyond that of a personal wiki.
TiddlyWiki content is made up from a collection of Micro Content, or tiddlers. Each tiddler is stored as a HTML <div> containing the source text in wiki format. For example, this Tiddler is stored as follows:
<div title="Tiddler" modifier="Paul Downey" created="200811132220" modified="200811132225" changecount="3" tags="paper"> <pre>TiddlyWiki content is a collection of Micro Content ... </div>
Invented by Jeremy Ruston, and released as Open Source under a BSD License, TiddlyWiki is maintained by an active community which includes Osmosoft. The IPR is held in trust by Una Mesa, a not-for-profit association. The source code is maintained at http://trac.tiddlywiki.org and released from TiddlyWiki.com.
As a single HTML file, TiddlyWiki makes an ideal Guerilla Wiki and whilst there are many instances of TiddlyWiki on the Web, the majority of TiddlyWikis reside behind corporate firewalls, on personal computers and are exchanged on thumb drives and over email, in a manor similar to word processing documents and spreadsheets.
The extensible nature of TiddlyWiki combined with Features arising from being a HTML Application enabled the Community to use TiddlyWiki as a JavaScript framework to build specialisations including a wide variety of Server Side adaptations, a number of task management tools including TeamTasks, a number of Web clipping tools including TiddlySnip, a Message Vault, and a collaborative note taking tool RippleRap. There is a plethora of plugins and other examples in the expansive TiddlyTools. SocialText uses TiddlyWiki to provide an unplugged experience. Osmosoft have been using TiddlyWiki to front-end enterprise systems, improving the user experience and providing offline for BT's HR and expenses systems.
Experiments on the future direction of TiddlyWiki include Project Cecily and JigglyWiki.
There are many further examples of adaptations listed on http://tiddlywiki.com, the TiddlyWiki community wiki as well as on the TiddlyWiki Wikipedia page page.
A number of strategies for hosting editable or collaborative TiddlyWikis which use HTTP Requests to Synchronize content to the Web, notably:
There is a more complete list of server side implementations on TiddlyWiki.com
Project Cecily is an experimental Zooming User Interface (ZUI) for TiddlyWiki created by Jeremy Ruston. Using advanced browser features including the canvas and CSS transforms, it runs on WebKit 3.1 (and above) and Firefox 3.1 (and above).
JigglyWiki is an experiment in replacing the TiddlyWiki core code with JQuery to demonstrating the feasibility of an unobtrusive Javascript version of TiddlyWiki.
It is hard to estimate the number of people using and developing with TiddlyWiki largely due to the number of private and offline Use Cases. A small indication of the vibrancy of the TiddlyWiki community may be gleamed from the TiddlyWiki Discussion Group and TiddlyWiki Developer Group which are consistently highly active, with more than 3,500 participants exchanging 800-1000 and 200-300 posts per month, respectively.
As a HTML Application, a TiddlyWiki saved locally and opened in a browser from a file URI is able to:
A number of other features, not directly applicable to this workshop, listed on TiddlyWiki.com.
A TiddlyWiki opened from a file URI may save changes made back to the file using one of the following techniques:
The user experience of granting privilege to save differs radically across browsers and operating systems as illustrated by the step-by-step guides on how to install TiddlyWiki locally on TiddlyWiki.com:
Writing itself to a file led Jeremy Ruston to consider TiddlyWiki being akin to a quine.
Character encoding bugs in the file saving component used in Internet Explorer prevents HTML Applications from directly saving binary content. TiddlyWiki avoids this constraint by escaping non-printable content using HTML character entities prior to saving. This technique is employed for Writing Other Files.
The "TiddlySaver.jar" allows TiddlyWiki to save changes made to a file URL in Safari, Opera and other browsers. The jar file, placed in the same directory as the HTML, must be present before the file is opened. The jar has been digitally signed using the Una Mesa "Thawte Code Signing CA" intermediate certificate which demands trust from the user when opening a TiddlyWiki file for the first time.
At the time of writing, TiddlyWiki is known to be viewable on all major desktop browsers on Windows, Macintosh and Linux and many mobile browsers such as the Apple iPhone and the Nokia 770/N800, notably:
| Browser | Version | File Saving Supported? |
|---|---|---|
| InternetExplorer | 6.0+ | Yes |
| Firefox | 1.0+ | Yes |
| Safari | 1.0+ | Yes, using TiddlySaver plugin |
| Opera | ? | Yes, using TiddlySaver plugin |
| NetscapeNavigator | 7.0+ | Yes |
| Camino | 1.0+ | Yes |
| Chrome | All | Yes, using TiddlySaver plugin |
| Wii | All | No |
A TiddlyWiki opened from a local file URI and able to engage in File Saving is also able create and write to other files, this has a number of common use cases:
TiddlyWiki has the ability to synchronize content either using HTTP Requests through a formal adapter framework or informally from plugins and extensions.
There are a number of adaptors available which when combined with formatters supporting a wide variety of wiki text markup dialects, make TiddlyWiki ideally suited for refactoring wiki content, and a Use Case of cascading, moderated content, colloquially known as TiddlyChatter.
When parsing another TiddlyWiki from a local file or hosted on the Web, a temporary, hidden iframe is created to load the URI, and the browser DOM used to parse the TiddlyWiki HTML content.
A HTML Application opened from a file URI isn't bound by same origin policy when accessing the Web from JavaScript using XHR. This enables a number of interesting Use Cases normally precluded from a client side application, in particular collecting data from a wide variety of sources and mashing up public resources with private or localized data.
Browsers such as Firefox 3.0, represent cookies for an XHR to another domain, enabling session hijacking. This is useful for some Use Cases, but does raise opportunities for a malicious HTML application.
Where a TiddlyWiki is opened from a HTTP URI, and is bound by same origin policy it is common practice to either use Server Side code, or deploy a small, generic proxy, in the manor of the Google Feed API, although this introduces a central point of failure and attack. For this reason, we are tracking the progress of the Access Control for Cross-Site Requests specification with interest.
For services using delegated authentication such as Fickr and OAuth, the inability to redirect from the Web back to a file URI means HTML Applications have to behave as an installed application. This requires a user requesting permission for TiddlyWiki to access a resource to visit a Web site in a separate window or tab, grant access and then return to the TiddlyWiki and click a button or link before authorization may complete.
TiddlyWiki options such as the wiki author's name and preferences such as where backup files are created, across browser sessions. Cookies stored against the file URI is a feature widely supported, though not well documented. Notably the Google Chrome browser does not support storing cookies to a file URI, as discussed under the Google Chrome Issue #535. This appears to be for well thought out reasons, as explained in the paper Beware of Finer-Grained Origins by Collin Jackson and Adam Barth of Stanford University, 2008.
TiddlyWiki has possible solutions for where file URI cookies are unavailable, most of which involve storing data inside the TiddlyWiki file. A method of storing user preference data outside of a TiddlyWiki remains desirable for some options use-cases.
Building on the examples presented in the Workshop call for participation, examples of features which are of interest to a TiddlyWiki developer could include:
Ideally, these should be made available to TiddlyWiki as JavaScript functions, and in a browser independent way. To that end, we support the efforts of to standardise common practice in the Web Applications, Geolocation, Ubiquitous Web Applications and HTML Working Groups.
Whilst we are excited by the possibilities offered by the world of Device APIs, we are concerned that access should be granted in an open and consistent way, across browsers, in a way which doesn't unpleasantly surprise users.
A TiddlyWiki user having traversed the challenges presented by File Saving, places a great deal of trust in the authors of TiddlyWiki as well as any plugins they maybe using. Whilst Open Source and view source makes incorporating malicious software into TiddlyWiki difficult to hide, it would be helpful if the granularity of security opened up was made clearer by browsers, and is an constant manor. To this end we support the efforts of the Web Security Context Working Group working group.
Our position for the workshop is therefore to:
Paul is a member of the Osmosoft team where he contributes to a number of Open Source projects including TiddlyWiki. Formally BT's Chief Web Services Architect, Paul continues to promote the value of Web Architecture and REST through a series of drawings, notably The Web is Agreement.
psd@osmosoft.com | |
| Blog | http://blog.whatfettle.com/ |
| Photos | http://www.flickr.com/photos/psd/ |
| Bookmarks | http://ma.gnolia.com/people/psd/bookmarks |
| http://twitter.com/psd |
Head of Open Source Innovation at BT and leader of the Osmosoft team. The original creator of TiddlyWiki, Jeremy continues to participate in the TiddlyWiki Community and is currently exploring zoomable interfaces for TiddlyWiki in Project Cecily.
jeremy@osmosoft.com | |
| Blog | http://jermolene.wordpress.com/ |
| Photos | http://www.flickr.com/photos/jermy/ |
| Bookmarks | http://del.icio.us/jeremyruston |
| http://twitter.com/Jermolene |
A small company of open source developers owned by BT
A not for profit organisation which holds the copyright to TiddlyWiki in trust.