The User Dashboard

All too often online, the day-to-day user is unwittingly under the microscope. They visit sites, and use applications, unaware that their digital footprints are being tracked, stored, analysed, and often monetised.

Central to the OPENi vision is the empowerment of it’s users, so naturally, this exploitation is anathema to us. To redress the imbalance, we have developed the OPENi User Dashboard. We allow our users to pull back the curtain, and see how, and who, is using their data.

User Dashboard Login

The user dashboard is an off-application HTML dashboard that gives the user unfettered access to their Personal Cloudlet. It allows them to browse all the data within their Personal Cloudlet, view details on the apps that requested access to their data, and it also allows them to view or edit app permissions.

The dashboard offers four sources of insight to the user

  1. Data Browsing
  2. Auditing
  3. Permissions
  4. Notifications

User Insights

Data Browsing

The Personal Cloudlet owner can view all their data categorised by type, app, or by time. It also allows them to view data in their Personal Cloudlet filtered by the permissions settings for each of their 3rd part apps.

Data View Data View


The user can view their Personal Cloudlets access request logs, categorised by requests allowed and denied. These logs are provided via the Piwik based Analytics Service Enabler.

Access Logs over Time Access Logs per Company/App Access Logs per Country


The user can view and edit all permissions associated with their app.

Permissions Summary Permissions Control


Users can setup notifications attached to their Personal Cloudlet so that they are informed of access requests and permission requests on their Personal Cloudlet.



The user dashboard addresses the OPENi objective to give users more control over their data and directly addresses research question 2

Which mechanisms should be incorporated by the OPENi platform  to provide its users with a comprehensive picture of access to their data?

It does so by informing end users of activity on their Personal Cloudlet; it also affords them the ability to alter permissions if they see activity that they don’t agree with.

The OPENi Personal Cloudlet

The strength of the OPENi platform stems from the three pillars upon which it is built: the Cloudlet Framework, the API Framework, and the Security Framework.

Most readers will be somewhat familiar with APIs and Security. The term ‘cloudlet’, however, might not reveal it’s meaning as readily. Simply put, an OPENi cloudlet provides application consumers with a single location to store and control their personal data.

To treat it more technically, it is a user-centric datastore with privacy-aware access control for cloud-based data platforms.

In conjunction with the security framework, the cloudlet allows application consumers remain in control of their data. Consumers are assured their data is not being used without their consent.

Personal Cloudlet Objectives

Before work commenced, we asked ourselves the following question

How should a secure and privacy concerned web based framework be developed in order to provide user-centric management to dynamic data and APIs, while providing the developer with the ability to access the data in a privacy concerning manner?

To answer this, we set out these key objectives

  1. To build key technological enablers to ensure the practical applicability and efficient use of the OPENi platform
  2. To deliver an open source platform that will allow application consumers to create, deploy, and manage their personal space in the cloud (Personal Cloudlet). Each Personal Cloudlet constitutes an entity that will be linked to its user’s identity
  3. To provide and promote a novel, consistent, user-centric application experience of cloud-based services not only across different devices but also across different applications
  4. To ensure the OPENi platform maintains a low barrier to entry for application developers and service providers

Building the Pillar

The cloudlet is implemented as a distributed application, composed of a number of software components, called workers, distributed across a number of hardware nodes. These workers communicate with each other by passing messages.

This approach provides several significant features

  • Each component can scale independently of each other, depending on the demand
  • Components are small and concentrate on a single task
  • The overall application is stateless, i.e. none of the core components maintain state/session data

A range of diverse, complimentary technologies have been brought together to realise our vision of the cloudlet

  • JavaScript/Node.js
  • Mongrel2 (web server that talks HTTP to Browsers on the frontend and ZMQ to micro-services on the backend. It connects the application to the real world.)
  • ZMQ (Message Bus)
  • JWT (allows for session like requests in a stateless system i.e. a public/private key setup where only the auth component has the private key, and other components have the public key.)
  • Swagger (makes it easier to develop REST endpoints via auto generated HTML pages which interact with the endpoints and also create SDKs)
  • CouchBase (NoSQL Datastore)
  • JSON (data format, used in transport and at rest)
  • Micro-services/distributed application

The View from the Top

Data Storage

The data storage component is capable of storing user, app-specific, and internal cloudlet data. This data may be in various forms such as text, graphical, audio etc. Consequently it is capable of accommodating binary files as well as structured JSON data.

Data Access

All data that exists in a cloudlet will be accessed via the Data API and the Type API. They ensure a consistent access point for all services such as apps, the API framework, and 3rd party services. In conjunction with the Authentication, Authorisation, Accounting component and permissions, the cloudlet owner is in full control of who and what can access each piece of data in their Personal Cloudlet.

Cloudlet GUIs

To empower Cloudlet owners in the management of their cloudlets they have a standalone GUI, separate to the on app interface. GUI features include:

  • access logs viewing
  • preference editing
  • permissions editing.

User Centricity & Privacy Preservation

JSON Web Tokens (JWT) are digitally signed, base64 encoded JSON objects, that enable stateless REST based frameworks to manage sessions and claims. In the Personal Cloudlet Framework, we extended the use of JWTs to also manage the context of the party accessing the users data.

In OPENi, multiple 3rd parties request data using the same endpoints but are presented with different subsets of user data dependent on user permissions. JWTs enable this data masking in accordance with an OAuth 2.0 compliant workflow.

All Personal Cloudlet data is persisted to a NoSQL document store; accordingly, a users Personal Cloudlet is composed of a number of JSON objects. OPENi Types are in place to expose the structure of the JSON objects without revealing the objects content. All OPENi Types are public and app developers are free to either create their own or reuse those created by others. To further promote Type reuse the platform provides a Registry which describes existing types and and also gives an indication of a type’s popularity.

The Personal Cloudlet Framework controls data access by attaching permissions objects to each individual Object within a cloudlet. Each permissions object lists approved apps and whether the approved app can create, read, update, and delete that object. When an app calls the object API these permissions rules are checked before the API call is acted upon.

Access Token


We are inextricably bound to our identities. The modern web has seen us compartmentalise aspects of ourselves, divvying up parts of our digital identity for various cloud-based services and applications. At a fundamental level, this weakens us. We are eroding. Our digital self is no longer whole, and that separation results in a loss of value in our personal data.

The OPENi Cloudlet offers a solution to this digital disconnect. By providing users with a single location to store and control their personal data, we are neither merely catering to them, nor are we simply hoping to attract them, instead we are empowering them.

OPENi App for Mobile Marketing and Personalised Advertisement

OPENi applications’ Recommender and personalised Ads” application, namely OPERA app is an OPENi-enabled Android native mobile application that incorporates state-of-the-art methods in mobile marketing and personalised advertising, leveraging privacy awareness and end-users Quality of Experience (QoE) in a new optimized level via:

  1. providing personalized ad services in an opt-in and anonymised basis;
  2. anonymously and non-invasively context-based personalized ads;
  3. introducing a novel mobile advertising model (i.e., pull model), that can be enabled due to the unique features of OPENi;
  4. Incentivising users to opt-in to a marketing campaign via offers, coupons thus, enable them to implicitly monetize the action of sharing of their personal data.

OPENi provides a consumer-centric, open source mobile cloud applications solution that: (a) incorporates an open API framework that is capable of interoperating with a selection of cloud-based services, abstracting the integration challenges to a single open standard without losing any service features, and (b) reduces the fragmentation and duplication of consumers’ data through personal Cloudlets that enable them to manage what information is available to each application and for what purpose.

OPERA is an application developed throughout the OPENi project by Velti.

Optimize Mobile Marketing – Respecting Users Privacy

The emerging era of Mobile Marketing and Advertising is characterized by personalization and audience targeting towards enabling enhanced end-user’s experiences in line with their profile, interests, contextual trends and needs, and ultimately, maximizing the added value to the consumer. Towards this direction, advertisers and marketers need to deliver personalized marketing campaigns that take into consideration various user activities, behaviours, and digital trails, from preferences/interests and geo-location attributes to behavioural data and social networking interactions, towards addressing/targeting population segments with specific characteristics.

To this end, the OPENi Advertising Service Enabler (SE) allows the efficient introduction and exploitation of end-users’ personal data information in the overall life-cycle of mobile marketing and advertising in a privacy-by-design manner. Identifying the luck of such information due to data fragmentation in today’s advertising process/lifecycle, Advertising SE aims at facilitating the design and realization of a large variety of new innovative ways for enabling personalised advertising.

In a nutshell, the Advertising SE exploits OPENi Platform features to enable innovation in mobile marketing & advertising, via the collection, anonymization, aggregation, analysis, and correlation of large amounts of consumers’ personal data, in a privacy-aware manner, towards:

  • optimizing the overall performance of mobile marketing and advertising campaigns;
  • enabling consumer-centric and context-aware (i) audience management and (ii) consumers targeting in mobile marketing, towards maximizing the benefit to end-users’ as a result of the content of the ads that they interact with;
  • providing mobile users enhanced advertising personalized experiences by utilising their digital and social footprint;
  • reassuring mobile end-users privacy, by introducing a novel privacy-by-design pull ad serving model, that decouples the processes of i) ad campaign audience estimation/targeting and ii) ad delivery (to users’ mobile devices), reassuring end-users anonymity.

The Advertising SE Web Application is packaged and can be provided to OPENi developer/users for directly using it (along with OPENi Platform and Advertising SE). The template can be easily customised/parameterised by a service provide and/or developer and is available at More information on the Advertising SE is also available at OPENi Deliverables D5.2 & D5.5 Social Media Related Services Evaluation Phase 1 and Phase 2.

Advertising SE GUI – Audience Evolution Infographics in the case of “Mood” and “Application” Demographic Segments

Advertising SE GUI – Audience Evolution Infographics in the case of “Mood” and “Application” Demographic Segments

Time-based (day, week, month) audience evolution statics comparison.

Time-based (day, week, month) audience evolution statics comparison.

OPENi Analytics Service Enabler

Empowering OPENi Users

Piwik is the leading open-source web analytics platform. Much like the OPENi partners, the Piwik team are concerned about where and how our private information is being used, and they have been widely lauded for their approach to data privacy.

Piwik provides an excellent dashboard out-of-the-box that can be highly customised through the addition of graphs, reports, widgets etc. that are most relevant to a particular user. For OPENi we considered providing each user/company a unique login, allowing them to view metrics for their apps. We demoed this using the Personalised Shopping Assistant app in T6.3.

Piwik Dashboard

Then we had an epiphany. Why not turn the traditional Piwik use case on it’s head. Rather than facilitating companies track the movements of users through their apps, we decided to give users insight into the companies using their data.

Piwik already had an extensive API for tracking various parameters, but was not immediately suitable for our use case. To solve this we developed four custom Piwik plugins, each exposed via an API

  • OpeniAppTracker
  • OpeniCompanyTracker
  • OpeniLocationTracker
  • OpeniObjectTracker

We then developed a node.js component, called tracklet, which would be used by the auth-api and object-api. When a user is created via the auth-api the tracklet creates a corresponding entry in Piwik

User Creation

Piwik User Creation


This user can then access their OPENi user dashboard, and they will see that no 3rd party has accessed their data

User Dashboard

Zero Requests

Once they grant an app permission to access their data, requests can be made against that data, but thanks to the tracklet these requests will be logged and visualised to the user.

Requesting User Data


Now, if that same user goes to their user dashboard they can easily see that Betapond have accessed their cloudlet data

Access Log


Differentiating OPENi

There are a multitude of offerings that assist companies gain insight into how their users are behaving. There are far too few, however, which assist the user gain insight into how companies are using their personal data. OPENi, thanks in part to the Analytics SE, is now one of those few.

A privacy aware recommender system leveraging the power of personal cloudlets

Recommender systems are a subclass of information filtering systems that seek to predict the ‘rating’ or ‘preference’ that a user would give to an item” (Wikipedia, June 2015).

For the less tech-savvy, recommender systems are simply everywhere! If you think this is an over-statement, think again! If you have ever visited an e-shop, you have seen products being predicted as useful for you based on your purchases or browsing patterns. Movie rental sites, music streaming platforms, e-bookstores, mobile applications marketplace, sightseeing, wherever the volume of available options is intimidating, recommender systems are the way to go!

Recommendations can be based on people with similar tastes as you, on products similar to the ones you have already shown interest for, your social network’s preferences, your current state/context (Is it day or night? Are you at work or away for the weekend?) or a combination of the above…Useful information may at first seem irrelevant to the task at hand. Maybe your music taste is connected to your clothing style and, of course, much more interesting dependencies can be revealed…

But do you really want these interconnections to get smarter? Your income level may indeed be a decisive factor for the products you are willing to buy, but are you comfortable sharing it with an e-shop platform? Before answering that you would never do that, keep in mind that personal data don’t always come directly from you, but are also revealed from your actions and interactions and platforms can act upon the induced information towards enhancing their functionalities and increasing their profits…

Sacrificing the comforts of personalized recommendations is not a viable solution, but privacy control rules should apply. Leveraging the power of personal information is not by itself a bad idea, but in OPENi we feel that the data owner part should not be diminished in the process. The OPENi Recommender Service Enabler (SE) reconciles personalized recommendations with the emerging privacy-aware paradigm. The Recommender SE acts as a native trusted agent that retrieves contextual information from a user’s Cloudlet and uses it to deliver personalized object rankings. In order to do that, place check-ins, product purchases and selected mobile applications are occasionally retrieved from Cloudlets for which users have provided the necessary permissions, which they can revoke at any moment.

It is important to know that the Recommender is not allowed to store this information outside of the user’s Cloudlet or keep track of the users that have agreed to use the provided services. The workflow is quite straightforward: as depicted in Figure 1, when a user first accesses an OPENi application that utilizes the Recommender SE, he is asked to provide the access permissions for his Cloudlet requested by the Recommender SE and any others that may be required by the specific application. He may then optionally proceed to update the contextual information that will be used for the recommendations generation in an anonymous way. After that, the application is configured and the user can receive personalized recommendations presented to him through the application at hand. From the developer perspective, as shown in Figure 1, each of the previous actions implies a number of intermediary calls to the core OPENi APIs (Framework, Cloudlets, Permissions), but all our APIs come with extensive documentation, so you can have your application up and running with little effort and time.


Figure 1: User and Developer perspectives of the Recommender SE


In a way, what you need to remember in order to use the Recommender SE is that: Users are the only data owners and in charge of the way they are being used; Developers can leave all privacy control burdens behind and focus on more interesting parts of their apps!

Do you need more specific information? Let’s dive a bit deeper!

The OPENi Recommender SE draws its power from the user context, i.e. information such as age, gender, interests etc. We use a graph database in which we have created contextual nodes for a variety of information types, connected by parent-child category relationships, structured into context type hierarchies. The following image shows an example of such nodes (notice the “Context” label), specifically nodes that all hold demographic data of different types (“Education”, ”Gender”, ”Age”). The “weight” field is the one updated by the retrieved user interactions from the Cloudlets and shows that some nodes are more informative than others. Ιt is thus obvious that the information stored inside the Recommender SE does not point to any particular user.


Figure 2: Contextual node examples

This is of course a tiny portion of the context types available inside the Recommender database. There are many more contextual nodes that represent diverse information types, some more generic and others much more fine-grained than the ones shown here. Each of these nodes is connected to Places, Applications and Products through multiple paths. These paths together with the associated weights are used to find the best matches and return the most appropriate recommendations based on the current user’s context! This is quite a lot of nodes and edges! Fortunately, Neo4j ( has provided us with an efficient solution as it can handle the vast amount of information and calculate the best paths in almost no-time. After all, it would not be a Recommender system fit for modern apps, if it failed to provide the recommendations exactly when the user needs them, which is usually… “right now”!

If you are looking for a privacy-aware, trustful and powerful recommender system to create killer OPENi applications, come and play with the Swagger documentation of our API (!/recommender) or find us at the OPENi Github repository (!

For more details, please refer to the OPENi Deliverables D5.2 ( and D5.5.

A Framework to Control and Visualize Your Privacy

The OPENi project delivers a novel consumer-centric, privacy-by-design, open source mobile cloud applications development platform, serving as a catalyst for a new mobile applications era. Main element of the OPENi architecture is the introduction of users’ Cloudlet, where applications access, store and update users’ data and content (i.e. profile, location, social data) according to their preferences.

To this end, in OPENi we have developed OPENi-enabled cloud-based mobile applications, to demonstrate and educate end-users on the importance of controlling and managing their digital personal data, generated and accessed by mobile applications, via OPENi’s novel privacy control and personal data management framework and visualizations.

More specifically, the OPENi-enabled application can access end-user’s personal data stored in her/his personal Cloudlet. These data are generated by all the OPENi enabled applications activated by the user with user’s consent and via OPENi privacy framework. In the case of OPENi demo applications, these personal data are: users’ profile data, multimedia data & privacy preferences data.

The OPENi-enabled applications allow end-users to have explicit control over the use of their digital personal data. This is achieved with OPENi privacy framework that enables users to gain full control and transparency on the use of their personal data stored in their personal Cloudlet and accessed by OPENi-enabled applications. OPENi privacy framework allows end users to interact through advanced visualization experiences with their OPENi personal cloudlet, and enables them to get insights on the use of the personal data and to govern the access to their data in an easy-to-use, intuitive and innovative way.

As part of the demonstration, OPENi demo applications include OPENi Privacy Control Visualization Framework and demonstrate the following innovative user-centric privacy-aware features i.e.,

I. Permissions Dialog & Personal Data Visualization: an interface that enables users to visualize, monitor and get useful insights on the use of their personal data from OPENi enabled applications.

II. Personal Data Management (Opt-in & Opt-out): interface that enables users to control in a transparent way the use of the personal data via clear and easy to understand optin and opt-out methods in a layered and structured way.

III. Fine-grained Privacy Control: an interface, that enable users to control the use of their personal data in a user-friendly and fine-grained per-application access control model, being able to determine the user/access of (a) groups of data/object types, (b) groups of data/objects, (c) exact data/objects and (d) data/objects specific attribute, all stored in the Cloudlet.


Edit settings that an app can access

Edit settings that an app can access

manage the OPENi account through an OPENi-enabled app

Manage the OPENi account through an OPENi-enabled app

Edit media that an app can access

Edit media that an app can access

OPENi wins at TADHack Dublin

The 2015 TADHack (Telecom Application Developer Hackathon) took place on the 13th and 14th of June in a series of location around the globe including one in Dublin, Ireland. The OPENi project sent one of its developers (Neil Flynn) to the Dublin TADHack to take part with the aim of exposing OPENi in the WebRTC and Telecoms world.

The application he developed targeted the area of customer service and the conversation users have with customer service agents. The “My Customer Service” was a mashup between OPENi and Forge; the application used the Forge SDK to provide the application with real time messaging and the OPENi Android SDK to persist customer service conversations to the customers cloudlet.

Each team recorded a video presentation of their application and the idea/demo, this video was submitted to the local judging panel and also submitted to the TADHack HQ in Lisbon. On Monday we received the news that Neil and OPENi had won one of the global prizes, an Apple Watch. ( Well done Neil.

The video submission for OPENi can be seen at the following YouTube link:

How to build your own API with the help of the OPENi API Builder

APIs are everywhere. Growing from baby steps to maturity, APIs are created exponentially, as can be seen historically in search directories like the Programmable Web. Enterprises, start-ups and individual developers understand the power that lies in providing and consuming endpoints, for connection with the rest of the world.

OPENi proposed the Graph API Framework (Part I) (Part II) in order to create a set of seven Generic APIs by combining various Cloud-based Services, simplifying the work needed by developers and enterprises that want to make requests to multiple services at the same time.  This initial proposition of the Generic APIs and Objects has to be maintained and evolve in time as versions of the CBS APIs and needs of the community change. The OPENi API Builder was considered as a means for advancing the work done in the API Framework.

The API Builder simplifies the process of creating an API, showcase it, get feedback, likes, followers and ultimately be forked. By browsing through the community’s APIs (Figure 1 – APIs Index), a lot of interesting cases can be found and followed for updates on future changes. Specific domains of interest can also be explored for finding relevant APIs.

Creating an API is easy by providing its name, description, version and type. The type of an API can either be public, seen and updated by everyone; protected, seen by everyone but updated only by designated authors; or private, only seen and updated by the corresponding authors.

Then, Objects and their Properties can be created or forked from other APIs. Recommendations are provided for similar implementations and comments can be made to communicate with fellow developers and collaborate on the creation process. The new API can then be submitted for review by the administrators so as to get approved and be recommended to the community.

1 - Api Index Figure 1 – APIs Index

 As an example, imagine a Health App developer, John, who wants to create an API for harnessing data from various repositories. After browsing through the API Builder, he stumbles upon the Health API, but realizes that it does not quite satisfy his needs. So, he creates the Fitness API as seen in Figure 2, which contains the Objects Running, Pulse and Fat. Fat is actually an Object forked and reused from the aforementioned Health API. All the Objects contain four basic properties, like id and url, as well as extra properties defined by him.

From the Object management screen, John can also choose which methods he wants to provide for each Object of his API and the Cloud-based Services that can be linked to this particular Object. These Cloud-based Services are proposed by the community and approved by the administrators so as to give added value to the APIs. Some of the already implemented CBS are Facebook, Twitter, Foursquare, Flickr, Dropbox, Youtube, Instagram and Citygrid.

A swagger interface is used for interactive documentation and experimentation, while all basic API standards like Hydra, RAML, API Blueprint and WADL are also supported and provide the capability to download / update the relevant API documentation.

 2 - Api Management Screen

Figure 2 – API Management Screen

The API Builder is provided as a complete solution, both as a platform and as open-source code at Github. Documentation with instructions for easy setup is available within the code repository.

For a more extensive analysis of the research contribution of the API builder as part of OPENi, you may refer to the following papers:

  • Tsouroplis, R., Petychakis, M., Alvertis, I., Biliri, E., & Askounis, D. (2015). Community-based API Builder to manage APIs and their connections with Cloud-based Services. In CAiSE 2015 Forum, pp. 17-23.
  • Tsouroplis, R., Petychakis, M., Alvertis, I., Biliri, E., Lampathaki, F., & Askounis, D. (2015). Internet-based Enterprise Innovation through a Community-based API Builder to manage APIs. In Proceedings of the 1st Workshop on PErvasive WEb Technologies, trends and challenges (PEWET 2015) in conjunction with the 15th International Conference on Web Engineering (ICWE 2015).

3rd OPENi Hackathon – TSSG headquarters Waterford

On Friday 13th March the TSSG hosted an open invite hackathon for the OPENi project. The hackathon had a grand prize of €300 worth of Amazon Web Services which was awarded for the best OPENi enabled application created within the 8 hours of coding. The applications were judged on their originality, privacy awareness, and their use of the OPENi Platform.

The OPENi project provides a platform that allows users greater control over their online data. The platform provides users with a single location to store and control their personal data in the cloud. This Personal Cloudlet enables users to manage what information is available to each application and for what purpose. The teams were provided with both an Android and JavaScript OPENi SDK that simplified the development of their applications.

sunnySEA rare sunny day at TSSG Headquarters

Many teams attended the OPENi hackathon however one of them was excluded from the competition proper. The team in question is part of a commercialization project within the TSSG that utilises the OPENi platform. The judges thought that this gave them an unfair advantage which is why their excellent fitness application was excluded.

There was a good balance of technologies from the remaining competitors. In the end there could be only one winner and the winning application on the day came from a pair of 4th year Applied Computing students from Waterford Institute of Technology.

teams The teams preparing for the start of the hackathon

Their winning application used the OPENi JavaScript SDK to create an application that introduced the Steam API to OPENi. A user of their application, after logging in with their OPENi credentials, could enter their steam account ID onto the page and submit the form. The application would then gather the users game information and store it in their OPENi Cloudlet. The user could then view their game list on the web application including a thumbnail for each game and their playtime statistics.

Close second was an application that used the OPENi Android SDK to create an application that allows a user to store their images within their OPENi Cloudlet. Once logged into the application using OPENi credentials a user could choose to view the images from their Cloudlet or take new images to upload. When viewing their images the application would retrieve a list of images from the users Cloudlet and as the user moved through the images the application would download the images from the list.

sensors One of the teams using sensors for an IOT/OPENi mashup

In third place we had an application that used the OPENi JavaScript SDK coupled with Cordova/PhoneGap to create a mobile application that could connect to a sensor via Bluetooth and recorded the sensor’s data. The sensor can transmit multiple streams of data including temperature, accelerometer and pressure data that could then be collected by the mobile device.

Overall it was a very successful day and a fantastic way to end a busy week that also included an OPENi plenary meeting and a platform workshop. The teams did a tremendous job creating their applications in the short timeframe and everyone involved enjoyed the pizza lunch and the inspirational music from the Spotify playlist that accompanied the teams throughout the day.