Privacy/Policy/NTIA RFC: Difference between revisions

Jump to navigation Jump to search

Privacy/Policy/NTIA RFC (view source)

Revision as of 20:20, 2 April 2012

449 bytes added ,  2 April 2012
→‎III. Mozilla's Experience: Considerations for Implementing Multi Stakeholder Processes
Line 127: Line 127:
From our analysis, we would end up ranking privacy considerations for online services directed at teenagers as an ideal area for a code, given the maturity and number of accountable industry and public interest groups already working on kids privacy as a result of the Children's Online Privacy Protection Act. Likewise, looking to codes in the area of collecting personal data via multiple technologies (e.g., cookies, LSOs and cache) is another area where we see technology standards groups being well positioned and public interest groups having substantial experience working together with business and consumers to be a potentially good area for a code of conduct.
From our analysis, we would end up ranking privacy considerations for online services directed at teenagers as an ideal area for a code, given the maturity and number of accountable industry and public interest groups already working on kids privacy as a result of the Children's Online Privacy Protection Act. Likewise, looking to codes in the area of collecting personal data via multiple technologies (e.g., cookies, LSOs and cache) is another area where we see technology standards groups being well positioned and public interest groups having substantial experience working together with business and consumers to be a potentially good area for a code of conduct.


===III. Mozilla's Experience: Considerations for Implementing Multi Stakeholder Processes===
<br>
====Mozilla supports a process that is open and transparent while at the same time develops effective and meaningful codes of conduct.====
====Mozilla supports a process that is open and transparent while at the same time develops effective and meaningful codes of conduct.====
 
=====A. Open Participation=====
'''****Tantek and Jishnu are making major edits to this section, please hold off for a bit****'''
 
A. Open Participation
 
In an open, transparent process, first and foremost, it is critical to keep all relevant documents, drafts, ideas, etc. on process, guidelines, meeting plans and meeting notes on an open, accessible site, such as a wiki. See https://wiki.mozilla.org/ for an example of such a wiki. This will promote transparency and participation.
   
   
It may also be useful to split up the code of conduct into various subgroups organized by topic which could aid to participation and reaching consensus. The process of splitting the codes could in itself happen as the first stage of the open, transparent processes.
To maintain an open, transparent process, first and foremost, it is critical to make available all relevant documents, drafts, ideas, etc. on process, guidelines, meeting plans, and meeting notes through the following suggested methods:
* Post information on an open, accessible site, such as a wiki. See https://wiki.mozilla.org/ for example. This will promote transparency and participation.
* Hold open discussions on the web (e.g., webcast), via Internet Relay Chat (IRC) or by an open conference call for anyone to dial in, in order to maximize inclusiveness. As additional options to holding meetings in person, these formats may enable those who lack resources to send delegates to in person meetings may still participate.
* Do not require pre-requisites, such as position papers, to attend meetings. However, such optional papers can and should be submitted by posting them openly on the web, in an open format (preferably HTML) in a way humans can easily view them on any web browser, and search engines can easily index.
* Communicate with stakeholders through an email list that is open for anyone to join.
* Foster broad community participation early and often.  
   
   
If the discussions are made open and primarily take place on the web, simple publication of the URL(s) of the wiki would encourage the right stakeholders to contribute. In order to maximize inclusiveness, we suggest that as much as possible should be done on online wiki's and internet relay chat as opposed to in person so that those who lack resources to send delegates to in person meetings may still participate. While phone and in person meetings may be necessary, they have a tendency to lower participation. As such, they should be minimized and should be properly documented.
=====B. Transparency=====
 
======Technology======
If the NTIA chooses to introduce prerequesites to meetings, such as position papers, we do not believe such papers should be mandatory prerequesites to attend at a meeting. Mandatory requirements will lower participation and should be kept to a minimum. To be consistent with the principle of openness, all position papers should be submitted by posting them on the web, in an an open format (like HTML) in a way humans can easily view them on any web browser, and search engines can easily index. Proprietary formats like .DOC (Word) and search-unfriendly formats like PDF should be discouraged.
Mozilla believes that the technology used to promote the process can affect the transparency of the process as much as the procedural rules. Therefore, we would recommend that all documentation use open web standards like HTML that can be implemented in multiple viewers and rendered in ways that are searchable and accessible at the lowest cost to stakeholders and the public.
======Process======
To facilitate a transparent process, we recommend that discussions during in-person meetings be documented in meeting minutes by voluntary minute-takers (as designated by the chair of the meeting). A technology that may be useful for this is Etherpad  (e.g. https://etherpad.mozilla.org ), where others in the meetings can also add to the minutes and make corrections as necessary in real-time.
======Procedures stakeholders should follow to explain decisions======
Stakeholders should publish their explanations of decisions on issues discussed on the web, preferably on an open wiki, and cite sources for their reasoning (using URLs). Stakeholders should also cite the minutes/notes of their meetings with other stakeholders to explain decisions they have reached in concert.
There are several lessons from existing consensus-based, multi-stakeholder processes in the realms of Internet policy or technical standard-setting that could be applied to the privacy multi-stakeholder process. We recommend a study of the W3C, IETF, WHATWG and microformats.org organizations. Many of the points those processes have come up with are summarized in this blog post by one of our contributors, Tantek Çelik: http://tantek.com/2011/168/b1/practices-good-open-web-standards-development.  
======Defining & Incentivizing Consensus======
There are numerous factors in reaching consensus and they tend to differ based on the people involved and the issues at hand. For example, the W3C defines consensus roughly as a position which is either absent of objections, or has the least significant objections among several options.
The NTIA can encourage consensus by requiring that all proposals be posted publicly and all discussions be posted publicly which will encourage stakeholders to think with a broader perspective than simply their own self-interests. Let sub-groups of stakeholders form organically rather than attempting to facilitate anything in particular. To keep the overall process transparent, make sure that all materials discussed are published openly on the web, and that meeting plans/attendees/minutes/notes are similarly published openly on the
web.
====Requirements for a multi-stakeholder process====
Mozilla supports efforts to implement codes of conduct that would bring at least the level of technological and legal principles around privacy afforded to users of the web to the development of mobile apps.
Therefore, the key requirements that a multi-stakeholder process will need to identify for privacy considerations to be addressed adequately are:
# What are the privacy best practices that should influence the design of mobile apps and associated hosted services to provide user transparency and choice?
# What are the legal or regulatory ramifications for failing to follow the codes of conduct?
# How much will such codes of conduct continue to allow for innovation around novel uses of data that have user benefit?
==== Current illustrative privacy practices ====
Mozilla continues to implement a variety of consumer data privacy innovations in the creation of its products that we believe may help provide examples of potential areas for codes of conduct. We design our products with the following principles in mind (paraphrased from http://www.mozilla.org/en-US/privacy/ ):
* No Surprises
** Certain collection, use or disclosure of data sometimes unexpectedly suprises users. This means that, for unexpected collection, use and disclosure of data, we work hard to implement product-level notices and interactions that let users know and understand the data we collect and how we use it.
* Real Choices, User Control and Sensible Settings
** We give our users actionable and informed choices. We establish default settings that we try to align with user expectation as much as possible.
* Limited Data
** We collect and retain the least amount of information necessary for the feature or task. 
* Third Parties. We make privacy a key factor in selecting and interacting with partners.
From a design perspective, we take into account a three-level approach to privacy notifications as we roll out and update our products:
# In-product disclosures as the behavior of a feature or privacy notification.
# Settings that allow users to opt-in or opt-out of various collections, uses or disclosures of their data either separate from default or after they have made a privacy impacting choice.  
# An understandable but sufficiently detailed Privacy Policy.  
Mozilla is in the process of launching an open HTML5 application marketplace (https://marketplace.mozilla.org ). We are considering a range of privacy-related features including the following guidelines for application developers to improve the privacy of their applications:
   
   
B. Transparency
* design your app so that what you want to do with user data is what users think you are actually doing with it.  
 
* give the user as much control over their data as you can.  
Technology
* limit your data collection and use to only the data that you need.  
 
* design your app to protect the security of your user's data in its collection, storage and use.
Mozilla believes that the technology used to promote the process can affect the transparency of the process as much as the procedural rules. Therefore, we would recommend that all documentation use open web standards like HTML which can be implemented in multiple viewers and rendered in ways that are searchable and accessible at the lowest cost to stakeholders and the public. We also recommend open hosted services such as IRC for discussions and etherpad for collaborative note-taking  http://etherpad.mozilla.org/. At the end of meetings, the NTIA could post archives of IRC discussions and etherpad notes on the wiki for the project, establishing a quickly updating history of discussions and meetings.
* respond to user questions and concerns about your privacy practices.  
 
* avoid 'secret' updates
Process
* make your use of social or local features transparent and give (i) people a way to turn automatic sharing off and (ii) granular control over these features
 
* obtain consent from users when necessary, especially for location and other sensitive information
Since the advent of web standards, there are many We recommend that discussions during in-person meetings should be minuted by voluntary minute-takers (as designated by the chair of the meeting) in an Etherpad so that others in the meetings can also add to the minutes and make corrections as necessary in realtime.  
 
Procedures stakeholders should follow to explain decisions
 
Stakeholders should publish their explanations of decisions on issues discussed on the web, preferably on a centralized open wiki, and cite sources for their reasoning (using URLs).
Stakeholders should also cite the minutes/notes of their meetings with other stakeholders to explain decisions they have reached in concert.
 
Are there lessons from existing consensus-based, multistakeholder processes in the realms of Internet policy or technical standard-setting
that could be applied to the privacy multistakeholder process?
 
Yes, examples abound. We recommend a study of the W3C, IETF, WHATWG and microformat organizations. Many of the points those processes have come up with are summarized in this blog post by one of our contributors, Tantek Celik: http://tantek.com/2011/168/b1/practices-good-open-web-standards-development.
 
Defining & Incentivizing Consensus
 
There are numerous factors in reaching consensus and they tend to differ based on the people involved and the issues at hand. For example, the W3C defines consensus roughly as a position which is either absent of objections, or has the least significant objections among several options. [We need more detail on how different bodies define consensus and what our recommendations might be based on how we do things at Mozilla and in standards bodies].
 
Some standards efforts have failed to reach consensus. In such cases, the failure to achieve consensus can cause one group to "fork" the effort and reach consensus by itself. An example of this is the 2004 W3C workshop in which the W3C staff promoted browser adoption of XML+RDF as a future for the web. Many The argument was essentially one between pursuing a fairly new, more academically pure yet more complex model, and evolving existing pragmatic technologies and the positions were irreconcilable. A group of stakeholders split off and formed the WHATWG.org to advance HTML, CSS and the DOM, the results of which became HTML5.
 
The NTIA can encourage consensus by requiring that all proposals be posted publicly and all discussions be posted publicly which will encourage stakeholders to think with a broader perspective than simply their own self-interests. Let sub-groups of stakeholders form organically rather than attempting to facilitate anything in particularly. To keep the overall process transparent, make sure that all materials discussed are published openly on the web, and that meeting plans/attendees/minutes/notes are similarly published openly on the
web.
 
====Mozilla supports efforts to implement codes of conduct that help bring at least the level of technological and legal principles around privacy afforded to users of the web to the development of mobile apps.====
 
The key requirements that a multistakeholder process will need to identify for privacy considerations to be addressed adequately are:
# what are the privacy best practices that should influence the design of mobile apps and associated hosted services to provide user transparency and choice? and
# what are the legal or regulatory ramifications for failing to follow the codes of conduct?
# how much will such codes of conduct continue to allow for innovation around novel uses of data that have user benefit?
 
====Mozilla continues to implement a variety of consumer data privacy innovations in the creation of its products that we believe may help provide examples of potential areas for codes of conduct.====
 
We design our products with the following principles in mind:
[Insert privacy principles]
[TBD this section]
 
====Accountability====
====Accountability====
We believe that a clear accountability framework is necessary to help make a resulting code of conduct a meaningful exercise. Such an accountability framework should, at a minimum, involve:  
We believe that a clear accountability framework is necessary to help make a resulting Code of Conduct a meaningful exercise. Such accountability framework should, at a minimum, involve:
* clear, consistent rules around what constitute a violation of the code of conduct, and
(i) clear, consistent rules around what constitute a violation of the code of conduct  
* balance user-centric innovation for uses of data with the need for more transparency and user control around their data.
(ii) balance user-centric innovation for uses of data with the need for more transparency and user control around their data.


===IV. Public Resources from Mozilla on Privacy and Security===
===IV. Public Resources from Mozilla on Privacy and Security===
Jishnu
67

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/415232"

Navigation menu