Anyone Installed Firefox/Mozilla's New Ap: "Light Beam" helping track for Your Security?

[KoKo]

12. Seems to be a Ford Foundation Experimental Grant...

The tension between transparency
and online user privacy

We believe that the Add-on and the Lightbeam data server together make up an effective strategy to raise awareness regarding third party behaviour and ultimately may contribute to changing policy. However, the inherent tension between increasing transparency and protecting online user privacy complicates our task. This tension can be characterized as follows: collecting and showing data about third parties requires exposing data about how people use the web, which in turn may give tracking agents even more data to effectively track their users. In other words, the more data we expose publicly about third parties, the more data we expose about web users in general, and the more likely third party trackers - which we aim to expose - will use Lightbeam data to more effectively target and track online users. Avoiding this potential arms race required us to consult closely with the Mozilla privacy team and others to mitigate the potential risk to online privacy while allowing us to exploit the benefits of collecting aggregated Lightbeam data. In short, the tension between transparency and online user privacy has and will continue to require constant and cautious attention, but is possible to overcome given the following approach.

Our original proposal included building an Application Programming Interface (API) to enable anyone to access third party data from Lightbeam users who submit their data to public server. Upon review, we realized that without implementing careful restrictions, third parties would easily be able use the crowd-sourced Lightbeam data to increase their knowledge about Lightbeam users, by specifically correlating the behavior in their databases (which span some sites for all the sites’ users) with the data in Lightbeam (which spans all sites for some users). We address this issue by implementing an API that gives access only aggregated data, to encourage users to visualize the state of tracking on the web as an aggregate, but restricts access to the fine-grained data to trusted privacy researchers and others with whom a contractual relationship can be established to make abuse of the data unlikely. While this approach seems on first blush to fly in the face of the open data policy to which we normally adhere, we believe that protecting Lightbeam users’ privacy is worth the trade - off.

Data overload means that meaningful
visualizations beg for contextualization

One of the first issues we noticed with the initial visualization is that with even a few hours of data collected, the graph of “colluders” was so dense that it became scary, rather than informative. It was impossible for a user to make sense of the graph. In the revised Lightbeam, a common theme is that of context. The user is invited to select a context either by specifying a time range (a day, a week, etc.), a third party site (and then understanding the span of time and sites that the third party had visibility over), or a website (and then understanding the set of parties involved in tracking behavior on that site).


1. The Lightbeam add-on, which enables individual users to see who they are connecting to in real time, and -

2. A publicly available server of aggregated Lightbeam data collected through the willing participation of Lightbeam users who are interested in promoting further research in the field of online tracking and privacy.

This two-pronged approach gives people the tools to make decisions about their online privacy while at the same time providing a valuable and open community research platform that can reveal patterns.
connected themselves to your online activity.

Goals for the project included making it easy for people to make sense of their own browsing data, to expose relationships between websites and third parties - which normally remain hidden - and ultimately to give people the tools to make their own decisions about their online privacy.

Toward these goals we adopted three main design approaches to engage users possessing various levels of technical knowledge and interest in privacy issues. The first approach engages people with little technical knowledge by giving them a tool to view and explore their own personal internet browsing history.

The second enables those already knowledgeable about privacy issues to find relationships, patterns and trends among third party sites and the web sites that enable them. The third lets users act on what they find in the Lightbeam data in real time. Together these three interfaces would empower users to take control over their own online privacy and perhaps take a step towards changing our expectations and policies toward how and when people watch us across the Web.


visualizations


The team explored multiple visualizations beyond the original network graph of the first Lightbeam visualization, and built various conceptual models which ideally would exist in all browsers, so that third parties could be laid on top of a pre-existing conceptual and visual language.

opportunities and implications

During the conceptual phase of the project the team started testing the visualizations based on certain hypothesis. New factors to be considered emerged.

Some dealt with the scope of the application and implications and opportunities with the user interface. For example, how can we visualize the use of multiple tabs according to browsing history, how can we navigate through time? What is the best way to isolate data and create notification systems relating to ambient, audio or visual triggers?

Another focus area was on the application programming interface and how to convey different elements of online tracking. How should we represent cookies and the connections between cookies and websites? Should cookies be grouped according to the domain that issued them? What is the best way to display the action-reaction relationship between user behaviour and tracking?

And in another way, we needed to look at the motivation a user might have to activate the application in an ongoing way. What could we do to make Lightbeam an everyday tool? What are the key things a user would want to know? Where are the most evocative triggers?

Hypotheses

After raising questions and addressing key issues, we formed the following hypotheses to explore:

design axis
We identified the following set of axes on which we based the Lightbeam interface design. Some of these included:
personal vs. global perspective
generic vs. customized
static vs. deep time
opacity vs. transparency
ambient vs. direct attention
clustered vs. spacious
semantic vs. graphic
narrative vs. emergent

hypothesis #1
Exploring my browsing history
Users would like to see their browsing history as a hook to show tracking.

hypothesis #2
Dive into deep time
Users would benefit from seeing their data over time.
hypothesis #3

Simple Lightbeam metric as widget
Users find it easy and useful to read metrics as single numbers and simple graphs.
what is online tracking?


In order to develop an initial understanding of online tracking the visualization team designed animations. This method of visualization became helpful as we developed a visual language and delved deeper into how to represent online tracking.