- From: John Morris <jmorris@cdt.org>
- Date: Fri, 21 May 2010 01:09:54 -0400
- To: W3C Device APIs and Policy WG <public-device-apis@w3.org>
As further background on this topic, ten years ago the privacy concerns arising from revealing MAC addresses led the IETF to create a privacy-protective option for IPv6 addressing. See http://www.ietf.org/rfc/rfc3041.txt , "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". John On May 21, 2010, at 12:43 AM, John Morris wrote: > Brian, > > Is this your main use case? I actually don't really see the value > being offered to users -- I must be missing something -- so perhaps > you could flesh it out more. > >> Imagine an app where ppl anonymously log complaints to a location. It >> drops a pin on the map. Everyone elses complaints are a white pin. >> The >> pin for your comment would be blue! > > > Do you have other use cases? > > John > > On May 21, 2010, at 12:36 AM, Brian LeRoux wrote: > >> Hey John, I gave an example two emails ago. Again, if I want to spoof >> a mac address I get About 74,900,000 results on Google. If I want to >> access a mac address in any other first class development platform it >> is trivial. The scenario you describe def travels into security and >> privacy and capabilities which is, imo, a different problem, eh. >> >> >> On Thu, May 20, 2010 at 9:23 PM, John Morris <jmorris@cdt.org> wrote: >>> The vast majority of people will never spoof their MAC addresses. >>> MAC >>> addresses -- if trivially available to any website on the Internet >>> -- would >>> become a unique and unchanging identifier for all Internet users, >>> thereby >>> destroying privacy and anonymity. Websites track users today with >>> cookies >>> and Flash LSOs and the like, and users have a reasonable level of >>> control >>> over those (although controls over LSOs are slower to emerge). >>> Easy MAC >>> address availability would deprive users of that control, and would >>> trivially allow users' access of diverse websites to be linked up. >>> Everyone from behavioral advertising companies to the government >>> of China >>> would be thrilled if the W3C enabled simple universal Internet user >>> tracking. >>> >>> So, as Thomas asked, what are your specific use cases? >>> >>> >>> On May 20, 2010, at 11:28 PM, Brian LeRoux wrote: >>> >>>> What are the significant and problematic implications for privacy!? >>>> >>>> >>>> >>>> On Thu, May 20, 2010 at 8:24 PM, John Morris <jmorris@cdt.org> >>>> wrote: >>>>> >>>>> +1 on Thomas's request for specific, realistic use cases for >>>>> revealing >>>>> MAC >>>>> addresses through the web browser. I'd also be interested in any >>>>> argument >>>>> that revealing MAC addresses is "not really a threat" -- I think >>>>> that >>>>> such a >>>>> capability would have very significant and problematic >>>>> implications for >>>>> privacy. >>>>> >>>>> John >>>>> >>>>> On May 20, 2010, at 5:28 PM, Thomas Roessler wrote: >>>>> >>>>>> On 20 May 2010, at 14:23, Brian LeRoux wrote: >>>>>> >>>>>>> Some notes from the phonegap team for consideration: >>>>>>> >>>>>>> - MAC addresses can be used to uniquely identify a network >>>>>>> device >>>>>>> which we can/have/do use for some apps. I can give some >>>>>>> specific use >>>>>>> cases here if neccessary. We feel this is useful in the spec >>>>>>> and not >>>>>>> really a threat. >>>>>> >>>>>> I'd be interested in seeing the specific use cases. In >>>>>> particular: >>>>>> *What* >>>>>> is it that you really want to uniquely identify? The network >>>>>> interface? >>>>>> The >>>>>> user? The device? >>>>>> >>>>>>> - Also: MAC addresses can be spoofed! >>>>>> >>>>>> Yes, but that's not very likely to occur. >>>>>> >>>>>>> - IP Addresses only give a rough estimate of where a person >>>>>>> is...and >>>>>>> if we don't include it can be easily retrieved with >>>>>>> http://whatismyipaddress.com anyhow. We should include in the >>>>>>> spec. >>>>>> >>>>>> These may well be different addresses: The device might be >>>>>> behind a NAT, >>>>>> a >>>>>> proxy of sorts, or may use an anonymization service. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > > >
Received on Friday, 21 May 2010 05:10:32 UTC