Investigate security and legal considerations of via service

This ticket is meant to be the home for the discussion of what security and legal considerations need to be addressed with our Via service. Some of these considerations might (very likely) have been brought up previously. Let's link to existing docs where relevant and make sure we are all on the same page with how we approach what this service does.

## Overview of Via

Via's project description:
>This project uses the live web rewriting and banner injection capabilities of pywb web replay system to automatically add hypothes.is annotations to any web pages.
>
>(Previously, to see Hypothesis annotations, the user has to manually install a plugin or enable the annotations via a bookmarklet).
>
>This project is a demonstration of using a web replay rewriting system for automatically showing annotations, which allows the annotations to (in theory) work on any modern browser."

Boiled down, pywb serves as a proxy service that downloads a given website's initial html, updates the links/assets on the website to point back to the proxy service. This allows us to present a website that is a mirror of the actual website but is hosted by us and allows for us to inject JavaScript (and whatever we want) into it.

## Considerations that should be addressed with via

- It introduces a number of security vulnerabilities to the websites themselves (Removing CSP and X-Frame-Options Headers for example). _To follow up with nick as he had a list of security problems with via somewhere_
- It does not present a clear indication to the user that they are using a viewer/proxy
- It is an application of ours that is being used without asking acceptance of terms of services and privacy policies.
- Is it legally acceptable to be mirroring and (depending on perspective) redistributing content? Or are there some things we need to do to be allowed to do this?
- With link/form action rewriting, the website that is targeting will also have its form contents sent to us first while the proxying process is happening. This means sensitive information goes through us like email/password combinations and potentially credit card info.
- We do not, ourselves add any security headers to the content so we can be used as a vehicle to exploit websites. (No framing deterrents of via opens up to Clickjacking and no CSP headers leave it more open to XSS attacks)
- How are we handling logs?
- How are we handling access to this service? (is it as simple as sshing to the service to change the code to do something malicious?)

These are just the ones I can think of off the top of my head, please add more as they come up and let's link to the answers or provide some answers on this. I have a few suggestions that could get us (what I think is) 90% of the way to being a lot safer - I will add a comment below for those)

## Lessons learned

Genius has a similar service to via call genius.it. It has some of the same limitations as our service but was called out publicly:
http://www.theverge.com/2016/5/25/11505454/news-genius-annotate-the-web-content-security-policy-vulnerability

IMO, it's only a matter of time before we are called about because of the level of undoing that the service does. Let's learn a lesson from what happened to them and get this handled before it's forced on us.

No files, tests, or implementation entry points are named. Start by reviewing the existing Via documentation and the linked Genius example, then organize answers to the listed security, privacy, access, logging, and legal questions. Done means the relevant risks, decisions, and links are documented with agreement from the project owners.

Written by the indexing model from the issue text.