apk zenonia 5

Today, after 7 months, Bradley Horowitz announced that Google Plus will accept some pseudonyms. Kinda. If you can prove you're already famous. And can convince their robot it looks like a name. However, Google Engineer Yonatan Zunger spills the beans in a comment on that thread:

First of all, you might ask why we have a names policy at all. (i.e., why we don’t simply go with the JWZ proposal) One thing which we have discovered, while putting some miles on the system, is that it is indeed important to have a name-based service rather than a handle-based service. This isn’t a matter of functionality so much as of community: You get a different kind of community when people are known as Mary Smith than when they are known as captaincrunch42, and for a social product in particular we decided that the first kind of community is the one we want to build. In order to do that, we want to establish a general norm that the names you put in to the system should be names, not handles.

So one thing that our name checking flow tries to catch is handles, which should normally be nicknames, shown in addition to a name. The other important thing it’s trying to catch is people who are creating individual accounts, rather than +Pages, for non-human entities such as businesses or organizations. The behavior of +Pages is deliberately restricted in the system, and we don’t want people to be creating fake human accounts to circumvent that. The name check turns out to be a very powerful tool to catch these.

Our name check is therefore looking, not for things that don’t look like “your” name, but for things which don’t look like names, period. In fact, we do not give a damn whether the name posted is “your” name or not: we will not challenge you on this basis, nor is there any mechanism for other users to cause you to be challenged for this.

There are two main cases where the name check screws up. One is false positives: people (such as you) who have unusual names which get flagged because they looked like handles. Being able to appeal via things such as drivers’ licenses is useful for this case, since it’s a simple “oh, we got this wrong.” The other case is people such as +trench coat, who are so well-known under this handle that it would be bizarre not to let them onto the system under this name. For this case, we allow appeals based on being well-known under the name: thus the ability to prove the “established pseudonym.” We’ve deliberately set the threshold for that latter case fairly high for now, but we intend to continue to tune it; the objective is that the frequency of such names should basically be the same as their frequency in meatspace.

So to answer your questions one-by-one:

(2) “Meaningful following” only applies to cases of established pseudonyms which do not look like names. The definition of “meaningful” is deliberately vague so that we can tune it, so that it behaves in a natural fashion.

(3) That’s correct; drivers’ licenses are for false positives, not pseudonyms.

(4) Unusual names will indeed hit friction, because of false positives. We’re trying to minimize that, but it’s going to take some trial and error.

(5) Google+ can absolutely be your first identity online. No matter what your language, no matter where you come from. The “established pseudonym” logic should apply to a very small subset of people. If some groups are seeing a higher false positive rate than others, that’s a bug, not a feature, and we have the data available to spot this situation and remedy it.

Our name check is therefore looking, not for things that don’t look like “your” name, but for things which don’t look like names, period. In fact, we do not give a damn whether the name posted is “your” name or not: we will not challenge you on this basis, nor is there any mechanism for other users to cause you to be challenged for this.

Bruce Schneier in Beyond Fear coined a phrase:

one of the goals of a security countermeasure is to provide people with a feeling of security in addition to the reality. But some countermeasures provide the feeling of security instead of the reality. These are nothing more than security theater. They're palliative at best.

The Common Names debâcle at Google Plus is a variant of this, where the supposed protections are manifestly not working. Google's stated policy on this is that you should use your 'common name' - normatively defined to have exactly two words in it, in a naïve English speaking way, that fails in a huge number of common English cases, let alone other languages.

Vic Gundotra has said

he is trying to make sure a positive tone gets set here. Like when a restaurant doesn't allow people who aren't wearing shirts to enter.

so it is explicitly designed to exclude 'people not like us' from the space.

Early users can set the tone for a network, but one that has aspirations to include most people will need to support multiple different communities within it. If you want a positive tone, you have to work at it, and empower the tummlers to maintain it. Teresa Nielsen-Hayden put it well:

1. There can be no ongoing discourse without some degree of moderation, if only to kill off the hardcore trolls. It takes rather more moderation than that to create a complex, nuanced, civil discourse. If you want that to happen, you have to give of yourself. Providing the space but not tending the conversation is like expecting that your front yard will automatically turn itself into a garden.

2. Once you have a well-established online conversation space, with enough regulars to explain the local mores to newcomers, they’ll do a lot of the policing themselves.

More from Teresa and from John Scalzi.

The initial flavour of Google Plus, because it was seeded by Googlers and other geeky folk they invited, was like pre-Eternal September Usenet - it had a cultural coherence because we were all geeks. As it grew to 25 million users, this could not hold.

Blogs deal with this by making it clear who the site owners are, and empowering them to manage commenters. Twitter does it by not showing you comments unless you chose to see the commenter, or if they address you directly. Google Plus is an uneasy hybrid of the two.

You can delete and block commenters on your postings, like a blog, and if you reshare someone's post, it starts a new comment thread, like a blog. However, anyone can @ or + your name and drag you into another comment thread via notification, and then you get notified of other follow-ups too, making griefing and harassment all too easy.

Enforcing 'common names' does nothing to help this; it just means your trolls and griefers will be using plausibly American-looking names that may or may not be their own, while those with unusual names, will either be excluded outright or easily preyed on by the griefers reporting them, which is what I suspect happened to Violet Blue tonight.

Once you are suspended, the verification process is crude and manual, and also easily gamed. Kellan warned about this problem:

If you’ve never run a social software site … let me tell you: these kinds of false positives are expensive.

They’re really expensive. They burn your most precious resources when running a startup: good will, and time. Your support staff has to address the issues (while people are yelling at them), your engineers are in the database mucking about with columns, until they finally break down about build an unbanning tool which inevitably doesn’t scale to really massive attacks, or new interesting attack vectors, which means you’re either back monkeying with the live databases or you’ve now got a team of engineers dedicated just to building tools to remediate false positives. And now you’re burning engineer cycles, engineering motivation (cleaning up mistakes sucks), staff satisfaction AND community good will. That’s the definition of expensive.

And this is all a TON of work.

And while this is all going down you’ve got another part of your company dedicated to making creating new accounts AS EASY AS HUMANLY POSSIBLE. Which means when you do find and nuke a real spammer, they’re back in minutes. So now you’re waging asymmetric warfare AGAINST YOURSELF.

This is the hole Google is now in. A surprisingly large number of people I know, who've been discussing civilly online for years, have fallen foul of Vic's Procrustean name rules. When they point this out, they're harrassed by 'Real named' dickheads telling them to shut up and change their name, both in public and by being +-summoned by the trolls, and they have to find Google plus's well-hidden blocking tools rather quickly. Or give up and go elsewhere.

Now, Google has announced that they are verifying some people's names, to prevent impersonation. Trouble is, they haven't said how . Twitter verifies celebrities via an opaque process. Amazon does it by checking your name matches a Credit Card. Google Search uses rel="me" and rel="author" microformats. What Plus does is unknown. One of my profiles is verified, possibly because I went through the verification process on Google Knol before.

This is also Identity theatre - Google saying 'trust us', rather than revealing the rel="me" link from the person's page that we already know.

Vic Gundotra needs to stop digging this hole. Scrap the normative 'common names' policy, add a coherent name verification and linked-site verification so we can tell the people we already know, and make moderation tools visible and available so we can curate the conversations ourselves.

With this, and an apology to those already ensnared by the existing process, he could maybe prevent Plus from being spoken of only alongside Wave and Knol.

More on this:

• my.nameis.me has testimonials on the nuances of names
  
• jwz is shocked by othering of the anonymous
  
• The EFF's case for pseudonyms
  
• Journalists tempted by slumming

He says:

Your data host’s job is to perform actions on your data. Rather than giving copies of your data out to a thousand companies (the Facebook and Data Portability approach) you host the data and perform actions on it, programmed by those companies who are developing useful social applications.

Which is exactly what an OpenSocial container does - mediate access to personal and friend data for 3rd party applications.

This environment has complete access to the data, and can do anything with it that you want to authorize. The developers provide little applets which run on your data host and provide the functionality. Inside the virtual machine is a Capability-based security environment which precisely controls what the applets can see and do with it.

This maps exactly on to Caja, the capability-based Javascript security model that is being used in OpenSocial.

Your database would store your own personal data, and the data your connections have decided to reveal to you. In addition, you would subscribe to a feed of changes from all friends on their data. This allows applications that just run on your immediate social network to run entirely in the data hosting server.

Again, a good match for OpenSocial's Activity Streams (and don't forget persistent app data on the server).

Currently, everybody is copying your data, just as a matter of course. That’s the default. They would have to work very hard not to keep a copy. In the data hosting model, they would have to work extra hard, and maliciously, and in violation of contract, to make a copy of your data. Changing it from implicit to overt act can make all the difference.

The situation is worse than that; asking people for their logins to other sites is widespread and dangerous. I'd hope Brad would support OAuth as a step along the way to his more secure model - especially combined with the REST APIs that are part of OpenSocial 0.8

If you're interested in these aspects of OpenSocial, do join in the linked mailing lists, and come along to the OpenSocial Summit on May 14th (just down the road from IIW).