Add a section on previous attempts and the differences

Resolves #30 and https://github.com/w3ctag/w3ctag.github.io/issues/22

README.md

@@ -96,6 +96,15 @@ Supporting contacts this way has a number of downsides:
   * Feature detection is harder, and would likely need a new API such as `HTMLInputElement.isTypeSupported()` mimicking the [`MediaRecorder`](https://www.w3.org/TR/mediastream-recording/#dom-mediarecorder-istypesupported). Unlike existing specializations of file pickers, contacts would be unlikely to gracefully degrade to a general picker.
   * Extensibility is harder, as it would rely on additional parameters being passed to the mime type.
 
+#### Previous Standardization Attempts
+There have been multiple previous attempts to bring a Contacts API to the web:
+  * https://wiki.mozilla.org/WebAPI/ContactsAPI
+  * https://lists.w3.org/Archives/Public/public-device-apis/2009Apr/att-0001/contacts.html
+  * https://www.w3.org/TR/2010/WD-contacts-api-20100121/
+  * https://www.w3.org/TR/2015/NOTE-contacts-manager-api-20150602/
+
+This attempt differs in its approach to privacy, which was the main emphasis of the API when it was designed. Unlike previous attempts which allow for perpetual access after granted permission, or include a vague privacy model, this spec enforces UI restrictions which give users full control over shared data and limit abuse. For example, a picker model is enforced where the user always acts as an intermediary of the shared contact info with full control every time contacts are requested.
+
 ## Potential follow-up work
   * As mentioned, more properties can be added iteratively as use cases are identified. It is a non-goal of this API to share _all_ information stored for a particular contact without filtering.
   * A Contact Provider API can be considered to complement data available from the operating system or the user's account.