NymPolicy Documentation

The NymPolicy 0.2 of October 12, 2013 is intended to provide a starting basis for conducting the research study described in this wiki. The dense and formal language used is definitely not intended to be retained but was crafted in hopes of providing a more definite and detailed basis from which to raise and hone several key policy, legal and business issues relevant to the topic and important for the research study. The final language should be very simple and as concise as possible, with references and other links or functions enabling deeper dives into the content or contexts.

The rewrite and replacement of the initial policy was absolutely not due to any lack of merit or wisdom in Sai's draft. Rather, once I read over what Sai wrote again more carefully, I realized his assumptions were not especially consistent with the narrow goal of setting up a site that stands for the principle that people can call themselves whatever they want. For example, Sai's draft indicated:

"You may use a name that you would normally introduce yourself as at a party to a friend of a friend — i.e. your display name is what someone could actually address you as in person."

This is a nice rule and, frankly, I'd probably choose to gravitate some of my personal and social activities toward service providers with policies or at least common voluntary customs along these lines. However, for the purpose of conducting research on nym policies designed to protect and defend the right to use nyms, the restriction feels to tight to me. I see no reason to limit the types of names participants in the research project can use to only "what someone would actually address [them] as in person." Most especially so if "in person" means physically in person and by spoken word.

Also, the proposed rule that "You may use a common name that happens to be also used by someone else, so long as does not appear to us to be an attempt at impersonating the other person" posed some issues with respect to assumptions underlying the research study. An axiom guiding the research study and being tested by the research is that sometimes it is widely expected, welcome and completely legal to impersonate another person, such as in jest, as part of role play in the context of debate preparation, as part of character acting in the context of performing a biographical theatrical production or as part of political satire or parody in the context of standup comedy, among many other situations. I think Sai was attempting to get at the situations when impersonation is conducted with the intent to commit a fraud or crime (such as the crime of impersonating a police officer or committing a bank robbery by perfectly impersonating the branch manager).

In looking up the common definition of impersonate I came upon the word "personate" the primary definition of which is: "to assume without authority and with fraudulent intent (some character or capacity)" See: http://www.merriam-webster.com/dictionary/personate? Potentially, the words "impersonate" should in the future be used to mean lawful parody, performance or other portrayal of another and the word "personate" should be used to distinguish the same act conducted with fraudulent or criminal intent.

Conversely, the statement: "Impersonation is the only reason we will suspend your profile" is a bit too narrow (because there are plenty of frauds and crimes and worse that involve or even hinge upon lying including about one's name but reserving the right to suspend an account based "only" upon one of many important reasons does not adequately reflect the policy basis intended for this research. Rather, it is intended that the policy, practices and procedures modeled by the site should reflect a realistic and commercially plausible (or ideally successful) basis for sustainable long term use and acceptance by the account holders, third party app or service providers and the System Provider. The Study Design wiki page describes this approach in more detail.

Before I conclude an opinion about the last few clauses from Sai's original draft, I need to think more about them and do some tests by setting up accounts on Google Business Apps using non-Roman, "simply decorative" and other unusual characters or formats for the name, and especially test unusual names of Google Business Apps account via OAuth2 integration with external (3rd party) apps/services. In other words: even if Google Biz Apps can handle a really weird name, can one log into other major or minor apps and services as well and have that value pass forward into the corresponding field of the external account or does something erroneous or anomalous result with the external client?