Privacy/Reviews/TogetherJS

Document Overview

Feature/Product:	TogetherJS
Projected Feature Freeze Date:	(tbd)
Product Champions:	Ian Bicking, Aaron Druck, Simon Wex
Privacy Champions:	Curtis Koenig
Security Contact:	(the security Friend you're working with)
Document State:	[NEW]

Timeline:

Architectural Overview:	(date TBD)
Recommendation Meeting:	(date TBD)
Review Complete ETA:	tbd

Architecture

In this section, the product's architecture is described. Any individual components or actors are identified, their "knowledge" or what data they store is identified, and data flow between components and external entities is described.

The main objective of this feature/product is: TogetherJS enables real-time collaboration on websites.

Design Documents: [[ https://togetherjs.com/docs/#technology-overview | technology overview ]]

Components

Client

The client is a Javascript library that site owners include on their website (either linking directly to https://togetherjs.com/togetherjs-min.js or the site owner can make their own copy of the client). The client is generally activated by the user explicitly hitting a button (though the site owner could invoke it any way they want – for instance in our [[ https://togetherjs.com/examples/todo/ | examples ]] we auto-start the client). The session is always accompanied by a panel of widgets on the side. The session lasts over multiple page loads, so long as they are on the same site and same tab.

The client allows the user to enter their name and an avatar, and sends information about any form elements (so the form values can be sync'd across all the people in the session), and any URLs on the site that the user visits.

Stored Data:

What	Where
Name and avatar	localStorage and sessionStorage

Hub

The clients generally can't speak directly to each other, so we have a "hub": a server that accepts WebSocket connections, based on a "room" (or session ID), and any messages sent to the server are echoed to everyone else in that room. The one exception is WebRTC audio, where we have people connect directly to one another. Web site owners can deploy their own hub if they wish.

All people in the same session connect to the same server instance, and messages received are sent out immediately to the other clients. Messages are not saved, and all the transfer is done in memory. There is no backend server like Redis that coordinates between servers.

The server has some logging. Some details of messages are logged when the server is at a debugging log level. In production we only log statistics. These are per-session statistics. We record the domain the session was on (or in unusual cases, multiple domains). We record a count of the number of pages, unique URLs, and activity. We do not record any identifying information, we do not record actual URLs, and we do not record detailed activity (only things like number of bytes, number of messages, idle time). Basically we're doing the first half of analysis in-process, and only output already-aggregated data. Nothing is anonymized beyond this, as we are not considering the domain private and all other information is naturally anonymous.

Stored Data:

What	Where
Aggregate Statistics: domain names, session times, user agent strings	S3

• Note: user agent strings are not yet being saved ([[ https://github.com/mozilla/togetherjs/issues/777 | bug ]])

[[ https://gist.github.com/ianb/fe8bc29c8ad0951a413f | Example of stats record being saved ]]

Communication with Client

Direction	Message	Data	Notes
In/out: (all communication is symmetric)	{type: "hello", name: "Me", avatar: "data:...", url: "http://example.com/page.html#location"}	Name, avatar, exact URLs, idle status

User Data Risk Minimization

In this section, the privacy champion will identify areas of user data risk and recommendations for minimizing the risk.

Alignment with Privacy Operating Principles

In this section, the privacy champion will identify how the feature lines up with Mozilla's privacy operating principles.

See Also: Privacy/Roadmap_2011#Operating_Principles:

Principle: Transparency / No Surprises

(How the feature addresses this)

Recommendations: (what can be improved)

Principle: Real Choice

Recommendations:

Principle: Sensible Defaults

Recommendations:

Principle: Limited Data

Recommendations:

Follow-up Tasks and tracking

What	Who	Bug	Details
[NEW] Initial Overview Discussion	?		Meeting time TBD