Jump to content

WebApps with LocalStorage and AppCache

From Wikiversity
Basic AppLSAC with Browser as Runtime Environment
WebApp: Classical Client-Server Architecture - Browser loads WebApp from Server and exchanges data with server - (see also Same-Origin Policy)

AppLSAC is an abbreviation for privacy friendly web-based applications that runs in a browser without the need to contact a server to process data. The WebApp consists of HTML, CSS and Javascript files and the AppLSAC is able to run disconnected from the internet. AppLSACs uses

  • (LS-Local Storage) LocalStorage of the browser to store generated data, configuration and settings of the WebApp in a browser instead of storage on a remote server.
  • (AC-AppCache) AppCache is used to store the WebApp locally in the browser (optional), so that the web-based applications can run offline without internet connectivity.

LocalStorage and AppCache can be replaced by equivalent web-technologies that are privacy friendly as well. Developed software is Open Source, so that the community can check, that the WebApp is programmed with privacy friendlyness in mind. As an alternative to the AppCache the HTML/Javascript/CSS files as bundle can be stored locally on the mobile device or desktop PC and executed with a browser. Starting an AppLSAC can be done just by loading a local HTML-file in the browser (e.g. a file myapp_lsac.html. The Javascript embedded in the HTML file performs a certain task e.g.

  • replace text, parse text, convert into a different syntax, ...
  • rotate an image, merge image on canvas, create an image map for the image, ...
  • edit a JSON, process data from a CSV file (e.g. CSV2Chart)
  • ...

Interaction with the filesystem is done transparently for the user, so the user has to select a loaded file, that should be processed and the file stored with download mechanism of the browser, but the file is generated locally in the browser (e.g. the rotated image, converted text, the edited JSON, ...) without contacting a remote server.

Main Steps in Learning Resource

[edit | edit source]

Some Javascript repositories are developed explicitly for the Wikiversity learning resource. The repositories are stored on GitLab to have a Version Control System for the application and forking of the libraries in learning task. We start with

  • (AppLSAC Examples) exploring AppLSAC example and apply AppLSACs for your work with Wikiversity as a learaing,
  • (Load, Processing, Save) identify the main operations of AppLSAC and understand the underlying concepts,
  • (Create an AppLSAC) create your first AppLSAC that runs completely in your browser without Internet connectivity.
  • (Remote Data Download) For an AppLSAC-0 it is allowed to download data from a remote server. In this part you will learn, how AppLSACs can be able to download data from a remote server. Of course this creates a digital footprint. Even in an AppLSAC-0 a remote download operation must be triggered by a users interaction - see also AppLSAC type.
  • (Privacy) Analyse the privacy by design pricinple and apply that on the AppLSAC concept. How can you address and improve privacy issues in general if you are using application and how are they addressed with an AppLSAC?
  • (Create a Library) Some tasks appear multiple times in AppLSACs. This learning task is about creating a library for that standard task, which can be used multiple times in your own WebApps. The procedures is rolled out for a specific library as use-case and you can apply that on your own WebApps. Identifiy at first your standard tasks you want to perform with your AppLSACs by describing the similarities in all use-cases you have in mind. The similarities define the UML-structure of your new library (UML Unified Modelling Language).

Main Operations of AppLSACs

[edit | edit source]

To be introduced to privacy friendly web-application we consider 3 main steps in this learning resource:

  • (Load) Load a file into the browser environment (and not to any server for processing)
  • (Processing) perform the task/job in the browser by implementation with Javascript
    • (ZIP) JSZip provides a method to handle folders and files within a browser without accessing the file system physically.
    • (Print) print content generated by the AppLSAC.
    • (JSON) load and process a JSON file in an AppLSAC.
  • (Save) finally save the results on the device of the user.

In the context of AppLSAC the browser is regarded as a runtime environment for local Javascript code.

Local Files and Same-Origin Policy

[edit | edit source]

If you load a local HTML file in your browser the scheme part of the URL shows file instead if https or http. The same-origine policy in general expects files from the same origine. The same-origin policy (abbreviation SOP) is applied as an important security concept for web browsers. SOP permits scripts contained in a loaded web page to access data from a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page within the Document Object Model.

Same-Origin - Cross-Origin

[edit | edit source]

For a local file

 file:///home/username/documents/app/index.html

Javascript files e.g. with the path name

 file:///home/username/documents/app/js/mycode.js

would be from the same origin while importing code with a script tag in the HTML file index.html with

 <script src="https:///www.example.com/content/delivery/netnork/remotecode.js"></script>

injects remote code from the file remotecode.js into your web application (cross-origin).

Relative links to locally stored images, audio, video files are considered as same origin, e.g.

 <img src="img/myimage.png">

embedded in the web app index.html refers to a local PNG image from the same origin, expected to exist with an absolute path.

 file:///home/username/documents/app/img/myimage.png

So with relative links for (e.g. the images) the concept implies loading from the same-origin.

Strict Application of Same Origin Policy for Local Files

[edit | edit source]

A strict application of the same origin policy would be that full pathname of the root HTML file (in our example file:///home/username/documents/app/ ) would be taken as the origin of the Web app stored in index.html. This implies that a browser could access only files under the same origin policy that are stored in a subdirectory of

   file:///home/username/documents/app/

Discuss benefits and drawbacks of such an approach.

White List Concept

[edit | edit source]

Privacy of data processing can be violated when data is submitted to a remote server. For homework of students that work with a local AppLSAC running completely offline might be submitted to a server for school/college or university. If the browser notifies remote server contact from an AppLSAC and the user may want to accept remote server to submit homework to the school server. A white list contains all remote servers the local AppLSAC may submit data to. All other remote server contact are blocked. Default for a white list concept is an empty white list or a configured whitelist for browsers on an e.g. Educational Linux Operating System or an LineageOS on mobile devices used in an educational setting.

Learning Tasks

[edit | edit source]

In general we have to distinguish between fetching data from a remote server and submitting data to a remote server.

  • Analyze the privacy concept of browsers according to the access to remotely stored resources (especially scripts) that are loaded and injected into your browser for execution.
  • Discuss the whitelist and blacklist concept for remote access to servers from a according to PROs and CONs for educational purposes and conclude in an assignment of different types of servers and content that are placed on a white list and on the blacklist of server access.
  • In spatial decision support systems the access to GPS-sensor of a mobile device is required to provide support to the learner according to the geolocation of the user. So e.g. access to the nearest point of interest (POI) that contains a new learning task (see also Real World Lab).

Graphical User Interface

[edit | edit source]

Furthermore you can learn about Navigation Menus as part of Graphical User Interfaces (GUI):

  • (Navigation Menu) A applications have menus from which the users can select specific features of the software. Load and Save are widely used menu items.
  • (Icons for Menu) Icons are used e.g. in a navigation menu. In this learning resource you will learn about handling icons in AppLSACs. For this part of the learning resource a GitHub repository Icons4Menu was created that aggregates a small set of icons and displays them with the licence in the README.md.

Underlying Concepts

[edit | edit source]

Learning Tasks

[edit | edit source]
  • (Browser as Runtime Environment) Explore the concept of Runtime Environments and explain, why a browser can be regarded as Runtime System for applications developed in Javascript!
  • (HTML,JS,CSS Software Bundle) Explain, why a WebApp can be developed and distributed as a bundle of HTML, Javascript and CSS files, that runs completely in a browser! HTML and CSS define the Graphical User Interface (GUI) for the AppLSAC.
  • (Differences WebApps vs. native Applications) Application can load and save files without notice to the user. Why is it necessary, that browsers need an explicit Load and Save dialog, in which the user must create an event to save content processed in the browser (privacy)?
  • (AppLSAC Limitations) Explain the limitations of WebApps (e.g. processing large files, access to sensors of the mobile device, ...) if users want no processing of data outside the browser, i.e. users do not want to grant permissions to process certain data in the cloud or on a remote server!
  • (Progressive WebApps) Analyse the concept of Progressive Web Apps and identify the feature of progressive WebApps that allow Commercial Data Harvesting. Explain similarities of the approach between AppLSAC and Progressive WebApps!
  • (Local Storage) Explain the concept of browser Cookies. How can web developers use browser cookies to store personalized data locally in the browser. What are the limations of Cookies to store data locally in the browser! How can web developers use Cookies for Commercial Data Harvesting. Assume you have a local HTML file with integrated Javascript, that store data locally. Are other domains able to access the local data in the browser (see also Same-Origin Policy)? Create a list of PROs and CONs in terms of privacy friendly design of WebApps for different options of local storage of data in the browser!
  • (Browser) Explain the role of browsers in general for the implementation of privacy friendly WebApps! What is your expected browser behaviour for a privacy friendly software design.
  • (WebApp Stores) F-Droid is an OpenSource App repository for Android. Explain the role of a digital distribution platform for developed mobile WebApps that run in the browser with the operating system of your desktop PC or mobile device. The store allows users to browse and download WebApps.

Programming Task

[edit | edit source]
  • Create a WebApp that is able to perform a QR-Code scan and stores the encoded data in the QR-Code into a textarea (see InstaScan HTML5 QR Code Scanner).
  • Create a WebApp that is able to detect the geolocation of the browser (see Geolocation in HTML5 on W3C.
  • Discuss Pros and Cons of such APIs for AppLSAC development.

Future Changes

[edit | edit source]
  • Migrate all GitHub repository for Wikiversity learning resources to GitLab (2018-*).

See also

[edit | edit source]