1. Front end (user interfaces) Facilitating the user‘s interaction with the SandS services and processes I. Mlakar, D. Ceric, A. Lipaj Valladolid, 17/12/2014

2. Overal Goal Specification, design, development and deployment of user environment allowing users the engagement and interaction of with the SandS system (services and processes within different Sands layers). The goals and requirements are achieved via the developed and deployed highly modular SandS front-end web-application Specific requirements  Providing access to SandS system (user registration and profiles)  Providing access to SandS services regarding recipes, and appliances  Task description via natural language (including speech)  Full circle communication over secured bi-directional communication channels

3. Front end as gateway between user and SandS system  PHP based web appliaction core,  Dynamic resources, loaded as required,AjaxLoader + JavaScript Loader, via url: index.php?class=domain&function=module  Static resources, loaded only upon refresh (page load), HTTPLoader, via url: index.php?main_page=page_title  Using latest web-standards CSS3, WW3C WebSokcets, WW3C Web Speech API, HTML 5  Stand-alone WebSocket Server, Php server, hybi10 protocol,

4. Full Communication circle No data is stored by front-end  Dislocation: DI and front end do not share system resources; Client-Side: ajax connectors (load without refresh), HTML5 WebSockets client (WWW3C compliant), HTML 5 Web Speech Client (WWW3C compliant)  Bi-directionality: front-end and DI can both trigger communication

5. User‘s Registration and Sign-in  Web forms (functions, resources and protocols) for registration, sign and update of user profiles  Communication between web GUI (client) and core (server) request/response based via ajax, HTTP.  Communication between front_end core and DI request/response based via HTTPS JSON.  Front-end acting as mediator between web GUI and DI

6. Appliance management  Dynamic web forms & resources, functions and protocols that allow users to: list, engage/remove appliances to/from their location  DI is source of information, front-end only serves as a mediator.

7. Recipes And Evaluation  Starts with user action which loads dynamical resources  Task description by either typing or speech recognition client (extended from Google Speech Recognition AP)  NLP module: extract the relevant parameters (POS tagging/matching)  match them against an appliance.  Ajaxloader: load and populate the appliance dependent task specification form

8. Recipes And Evaluation (continued)  Translated into DI compatible format and transmit to DI via DI connector  Load recipes detail form. Refine and/or Confirm  Send to DI as JSON (location, recipe_id, appliance_id).  Upon completion of the recipe users may also evaluate its final outcome.  The DI returns the best-matching recipe as a JSON encoded object

9. Messaging  Communication between DI and web GUI in triggered by DI.  DI-listener service enabling cross- domain interaction (domain restricted) If message and origin are verified they are dispatched to designated user-front-ends (receivers) COMPONENTS: javascript WebSockets client, PHP WebSocket server, PHP WebSocket client, DI-Listener web service Protocol: WebSocket hybi10 protcol  PHP WebSocketClient transmits verified message to WebSocket Server (connect, send, disconnect) (IP restricted).

10. Security  XSF attacks (page encryption): via encrypted sessions through security token.  Token is renewed at each load, stored as $_SESSION parameter and HTML element. Upon data/action submission both are checked by HTTPLoader or AjaxLoader.  XSS attacks (server-side data validation): via incoming data sanitation process.  HTML sanitation removing/escaping HTML tags including tags, remove escape sequences (e.g. '//'),  URL sanitation removing sequences starting with http, document., $(, etc.  POST/GET parameter sanitation prior processing exclude POST/GET parameter- names/values that contain certain black-listed constants (e.g. 'GLOBALS', '_COOKIE', '_ENV', '_FILES', '_GET', '_POST',…)

11. Security (continued)  Content Security Policy:.htaccess files are used to protect against unwanted snooping, file/folder permissions are set to read (CHMOD 644 for files and 755 for folders), server management via encrypted connections (SFTP (SSH FTP) for FTP access and PuttySecure command line connections)  Front-end/DI communication: secured via HTTPS, by using OpenSSL and self-signed SSL certificates. All the data exchanged between the entities is also sanitized  DI/Front-end cross-domain communication: secured via domain restricted HTTP. Only If the origin is verified the appropriate headers are set.  WebSocket hybi10 protocol: The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. We also implemented additional IP/domain restriction for accessing the message distribution service.

12. Thank You for your attention!