Peter Fargas
Independent Research & Prototypisation
Leipzig, Germany
Release date: July 2013
Last update: November 2014
Link to authoritative version

Usage Scenarios of Applications

☰ Content

Execution Environments
Usage Scenarios of Applications

    Each execution environment possesses it's own speciallities. I did not go on explorations into this domain from that direction?, rather the oposite as I was facing problems of the existing ones, problems of fundamental nature very complicated to overcome. This document is the result of that effort. The second paragraph speaks of the requirements, the final about the family of sollutions and their implications — whereas the first introduces the traditional models.
    The complexity of this concept's implementation, from ground up, is trivial.
    I marked a couple of spots with
? - in case you like to puzzle a bit around or confirm yourself some of the more interesting turningpoints. Enjoy,
   -Peter Fargaš

Models in wide use

  • standalone applications
  • portable applications
  • web aplications
Their usage domains are rather well known, on the properties is pondered seldomly since applications are built within those properties — instead of defining a sensefull set of them and searching for a suitable model from there?. As a simple example, I'll just mention the problem of identitiy, which is either ignored(as not relevant) or solved via login mechanism — and that is a very poor representation of a spectrum they both fit into. Only for the record: a spectrum which is bound together with some kind of privacy-spectrum (and more)?.

Problems to overcome / Needs to satisfy

    Current "western-civilisation" approach and strive is for every individual to have a personal device which is permanently online, yet if this approach has got "good" properties (theoretically, as in algebraical process theory) nor if it is feasible (praxis for the "real world") is questionable. Models which are more robust in the ever uncomprehensable possible-futures are available.
Some of the properties, which are within such "school of thought" as well as go along with "current problematics":
  • keylogger and other hard opponents
  • online and offline work
  • the various settings of: work from a trusted setting <–> necessary-action scenario
  • admin/alternative manipulation channels (bulk data extraction/manipulation, raw property extraction, interconnectivity etc.)
  • working at devices with strong user-right restrictions (public-service and/or corporate setting)
  • active access to private filesystem (missing in browser-confined applications)
  • platform independance
  • free
I will not go into discussion on the current technology, since it is a technical paper?. Just let me mention that public service is something which I believe we definitelly need to keep alive and strong. I as well believe that people should have ways to manipulate their data with tools of their choice and at different coarsity levels – something which boosts system-intelligence, tool-diversity and is rich landscape friendly (forth point). Apart from this high hoped remark, such simplifies not only usage, but as well development. Other points are as well broadening (and offering appropriate) choices of available behaviour patterns under various scenarios, outreaching in implications into neighbouring domains.


    Within the current technology offer, the best variant I found is a portable application with embedded browser - based on java technology for example, offered in various native machine codes and as bytecode.
This type of application model can be used in three different ways:
  • On devices which allows to execute portable applications, (a more powerfull model can unfold but most of all,) the portable wrapper can brigde filesystem write-access, a function which is crypled in a traditional browser setting.
    In online-mode, Identification of the user is the (unique) application-copy and state-hash of locally stored data. As the data evolves, in case of highjacking, the split can be detected and thus worked against (by proofing geo-synchronicity with other personal devices for example).
  • Running a weaker application model is a matter of having a browser to run theembedded web-application localy. Filesystem data can be read.
    Storage of data locally can be done via manual export - yet reading is available an thus the proofing of identity via most-recent-hash for online-scenario is available.
  • The third, most opened variant, is to access the application from an online location, just like a traditional web-application, a variant where user uses one of the available login mechanisms.
Data synchronization mechanism for online backup/availabilty can be offered for public-transferable data.
    The cost of developing application for such environment setting is minimal, since the core is the very same webserver-browser client application in all three variants. The embedding portable application is common. The way of usage is determined by the surrounding in which user is situated, resp. by the way (s)he decides to use the application.
Technologies as of 2013