Identity Is not a Thing

It is amazing to me how many ways notions of identity are employed and how nebulous identity itself remains.  Consider all of the variations identified in Wikipedia.  Contrast the social-science distinctions of identity with the tacit assumption of identity as a definite thing in “specifications of persons” and the way personally identifiable information (PII) is spoken of as pertaining to identity.  

These different explorations of ‘identity’ demonstrate how difficult a concept it is to pin down. Since identity is a virtual thing, it is impossible to define it empirically. Discussions of identity use the term with different meanings … .  In any case, the concept that an individual has a unique identity developed relatively late in history. [Wikipedia]

I agree that each of us might be distinguishable and identifiable in various contexts, including via manifestations of ourselves in the digital realm: cyberspace.  I don’t think my being identifiable requires there to be an identity, so-called, that is distinguished and is what is identified.  Yet that way of speaking seems to be common. 

I am not my driving license.  I am identifiable with it, to some degree.  I say it was issued to me.  It does not express my identity.  

I also wonder, in the pursuit of some sort of absolute/complete identity, how witness protection programs and anonymity are expected to operate.  Or could it be that there are only trusted legends, not absolute identities, arising in our social existence and experience?

I have come to the conclusion that there is no thing that expresses a unique identity for me.  I propose, therefor, to be rather detached about assertions concerning identity as some comprehensible thing.  I propose to examine how we and others are identifiable, casually or more formally.  At a personal level,

  • How do we recognize, however reliably, activity and presence of others, especially in cyberspace?
      
  • How are we made known and recognizable to others via activities and presence, especially in cyberspace?

I suggest those questions can be explored satisfactorily without requiring a tangible capture of identity.

The “Identity” cachet is too seductive to be given up.   Just the same, when I encounter such notions as “Identity Theft,” “Identity Management,” and “Identity Ecosystem,” it is useful to consider that such Identity is not a thing.  From that position, apply critical judgment to determination of what is actually involved, identifying what is tangible and useful about those notions, thus grounded.

Identity.  It’s not a thing.  You can’t have it.  You can’t hold it in your hand.  You can’t write it down.  You can’t sell it or buy it.  You can’t transfer it or bequeath it.   You might not even be able to protect or damage it.  And you definitely can’t take it with you.

[update 2014-04-30T16:04Z A lingering typo cried out for removal.
update 2014-04-30T00:26Z: There were some wordings I had to adjust upon seeing them in the published post.]

Posted in Civil Society and Democracy, Computers and Internet, Privacy and Security, Social Networking, trust | Leave a comment

Guardian, Dictator, Manager, Mentor, or Collaborator Be?

For open-source projects that I initiate, I want some way to acknowledge differentiation of roles that permit me to preserve in some friendly way my vision of what is essential for trustworthy development, releases, and life-cycle support.  I settled on the idea of being the project Guardian while recognizing there are benevolent dictators, managers, mentors and collaborators with low-friction use of source-code management.   For decentralized participation, that means getting my head around guardianship using Git.

Motivation

The open-source projects to which I pay the most attention are little nanoISV projects of my own, where I am almost exclusively the sole developer.  Indeed, you are pretty deep into my collegial inner circle if you are aware of any of them.

I also use source-code management for everything.  I use it in the development of my web sites.  I use it in all manner of software projects, even little throw-away and practice projects of any kind.   I’m surprised that I use it so little in other kinds of digitally-born activities, although I do have personal document-management practices.

The Politics of Tools

Source-code management systems do have political leanings with regard to how collaborative development works.  With some systems, one can pretty much set up a structure without worrying too much how branching, forking, and working will work, and how various contributions will work.  At least, I always thought so.

I have finally had to look at Git with regard to the kinds of project organization that it encourages.   Although I am still learning, I have in the back of my mind that Linus Torvalds had his own interests as the total dictator of the Linux kernel in mind when he figured out Git-based collaboration workflows that would allow him to manage all of the contributions that are made to the Linux kernel.  It is his model that I am interested in.

Although the idealization of Git is that all of the distributed repositories are equals among many, and this is literally true, there are reasons to have different levels of authority associated with particular public repositories.  I recommend the presentation of Linus Torvalds on Git for his views on that subject and how it fits with the practice of curating contributions to the Linux kernel.

Dictator versus Guardian

I am certain that I want to be the dictator.  I just don’t like the title.  Not even “benevolent dictator.”   Dictator doesn’t fit my picture of what a trustworthy collaborative arrangement should look like.

I’ve settled on “Guardian.”  I saw that used in a tutorial on Git Workflows as part of Using Git with Visual Studio 2013, and I like it.  It works like this.

Decentralized Repositories and Project Roles

There is an official integrated baseline repository.   (Sometimes, it is a set of repositories, but we’ll think of that as virtually one collective repository.)

The baseline repository is the master truth of public project artifacts and their history.  It may be organized a number of ways, but it is all about that.  I also think it is all about how the deliverables of the project are derived, documented, and deployed, whether that is simple or complex.   The baseline is backed-up and it can be inspected for the complete project history, of course.  And many people can have clones of it that preserve their provenance with respect to the baseline at the point it was cloned.  If there is ever need to make a forensic investigation as part of incident resolution, the baseline repository has what’s needed.  

Measures to maintain the integrity and provenance of the baseline repository will be appropriate depending on the nature of the project and its artifacts and the level of dependability and authenticity that is to be assured.

New work starts from a baseline.  Developers, including contributors, clone working repositories from the baseline repository.  They might continue completely independently, basing a fork on the baseline but never expecting to contribute back to the advancing baseline.   They could have the clone for testing.  They could be developing a fork for any purpose.  To maintain future synchronization of the fork with changes in the baseline, they will have a private branch structure that is amenable to merges from the developing baseline.

Contributors have share-back structures.  When developers are working on contributions to be made back to the baseline project, they can make their modifications and additions available to the original project in some semi-private manner.  This can be via their own repository or a public repository of theirs to which they publish (“push”) their contribution.  The contributor semi-private repository could also be a repository/branch of the baseline repository to which the contributor is authorized to push contributions and from which the guardian and any delegates can pull or merge those contributions to a public release.  (Casual projects can be without authorization barriers, at least among the few participants of such projects.)

Auditing and accepting contributions.  It is the guardian, or delegates (feature managers or leads, say), who pull contributions to their working repositories for verification and integration.  Contributors might have pull access to those repositories so they can align their contributions to the result of any adjustments made by the leads.  Ideally, leads request changes from the contributors and do not generally do the modifications themselves.  This is part of the community spirit of Apache Software Foundation projects, for example.  Torvalds has a practice where he does not resolve contribution merge conflicts himself.  He requests that the contributor whose contribution exposes the conflict resolve it.

Reconciliation at intermediate staging.  The guardian and the leads have whatever arrangement they require for review and developing an integrated view that is pushed to the public base repository.   In one approach, the guardian has master development repositories to which changes are merged from the leads (or the contributors where leads are not involved), and the reconciliation is then published to the integrated baseline, which is always collision-free.  This must be history-preserving where the provenance and chain of custody back to original contribution must be preserved.

No one is everybody at once.  I think the guardian hat should be different than a lead hat.  To the extent that the guardian is also a feature lead/manager, those roles should be kept separate.  In particular, the guardian hat should not require having to accomplish merge conflict reconciliation.  That is a manager/lead responsibility.  And, ideally, contributors would already have done that, but for the fact that there may be multiple contributors making changes that may lead to conflicts in the integration of their branches. 

Feature-oriented development.  If a feature is being coordinated this way, a feature lead might have the only working integration of feature contributions at intermediate times, though.  There are ways to keep this public, if only by having the feature-integration repository part of a set of repositories that are the collective integration baseline, with some of them having more ephemeral activity than among release material.  This might work for subprojects, too.  

This doesn’t square with having all of the truth at a single baseline (or reference) integration all of the time.  These concerns are beyond the reach of my personal-computing focus, but scale does seem possible, and I’m satisfied that’s enough to move ahead.

Mentoring is different than managing.  In this picture, guardians and leads can also be mentors, although mentors don’t have to be leads or managers.  A mentor works with contributors that are new to the project to help them fashion contributions that satisfy the development norms of the project.   Mentors are seasoned contributors who work directly with new contributors in having them fashion satisfactory contributions.  Mentors have in common with managers the desire for the development and success of the contributor.  Mentors can rely on the guidance of leads and the guardian with regard to project direction and process requirements.

Contributors are created equal and not the same.  I have been speaking of contributors as developers, new or experienced, who want to be direct contributors to the project and who are or aspire to becoming adept users of the project repository and its artifacts.

Contributions can be casual.  Contributors might only be interested in submission of patches or tests or documentation corrections that have pretty low ceremony.   Contributors might report bugs and not have the capacity or interest to identify the specific defect and propose corrections.  That’s all good.  The leads and guardian will encourage and acknowledge such effort in the trustworthy projects I have in mind.  Contribution is a precious act to be honored.

Distinguishing the guardian.  I think the guardian’s responsibility, at any scale, is to be accountable for the articulation and preservation of the conceptual integrity of the effort and its products.  

You can think of the guardian as the chief architect/engineer of the undertaking.   The point is where the guardian focuses, something that the guardian should not be distracted from, as happens so easily when immersed in other, nose-in-the-code roles.   The same is true for project management, especially for a solo developer or a low- ceremony team.  Someone has to keep their eye on the ball and that means not doing anything else at the time.

The Mixed-Blessing of Small Projects

For small projects, guardianship, feature management, mentoring, and contribution will involve the same person(s).  It is important, in that case, to have periods of activity when only one of those hats is being worn at a time by any individual.  That’s how to ensure that the perspective required of the role is brought to bear without the distraction of other concerns and interests.  That applies to the extent that project management roles are required as well. 

It can be difficult for a solo developer to switch hats when required.  It is valuable to be part of a team that assists its members to keep their hats on straight, whatever the wardrobe of the day happens to be.  This can also be aided by colleagues who are not all working on the same project, but who can provide buddy-support.

It doesn’t have to be hierarchical.   It is easy to see that guardianship, management, and mentoring are all aspects of leadership roles.   In a fluid team, these roles can move around, often spontaneously with little or no ceremony.  Specific accountabilities for set periods emerge when scale requires clear points of contact and visible, confirmable process.  It’s about structures for workable communication and reduction of friction in achievement of a common purpose.

Repository Versus Project Structure

I was led to this thinking because I am designing a project where Git is to be used as the repository.  I don’t think it matters whether a distributed or centralized version-control system is used for management of project artifacts.   The philosophies that the different approaches engender are adaptable enough, it seems to me.  

On the other hand, Git was designed by someone who wanted loose coupling and flexibility among developers while also providing a way for the benevolent dictator to easily review and accept contributions to a project with very high provenance and artifact integrity.  I wanted to understand how Git affords that.  This guardianship explanation is what I arrived at for structuring small projects that can scale to full-blown guardian cases as project growth might require.

Posted in Geekiness, nfoWare, nfoWorks, Professor von Clueless, Toolcraft, trust | Leave a comment

Recommending “Her”

Vicki was out of town on an important family mission during my official 75th birthday, yesterday, and I treated myself to the new film, “Her.”  (Please don’t read the Wikipedia synopsis, it sucks the life out of the story and is a pale substitute.)

Vicki thinks that immersive gaming and places like Second Life are simply weird, so I figured that seeing the film on my own wouldn’t take anything away from our list of films to see together, such as the new Jack Ryan story.

I was mistaken.  “Her” is very sweet and I regret not seeing it with her.  I am quite willing to see it again though, so I can make up for that.

“Her” explores an important, intensely-human theme that also has aspects in A.I. Artificial Intelligence and in some aspects of Blade Runner and Oblivion.  In “Her” what we project into relationships, and where we create them, is front and center in every moment.

Some of the most fanciful aspects of the film are in the satirical elements that are scattered everywhere.  There are a few in-jokes as well.  One about recreation of a persona from all of his writings is particularly confounding, considering what had that author’s attention.  It is all well-played and engaging, and the performance of the actors is completely enthralling.  However quirky any of the characters are, we sense their humanity and can be concerned for their fate.

There came a point when the plot took a sudden twist where I thought I knew where the story was going.  I was mistaken.  The first sudden turn is neither the last nor the greatest.

I don’t want to relay anything of the story and how it ends.  Do pay close attention to the dialog between “Samantha” and Theodore Twombly as the story is approaching resolution.  There are three important lines of which the last is an understated, almost muffled, payoff.  The richness of what comes next and the gift the film is trumpets in that line.

Posted in Golden Geek, In My World, Orcmid's Lair, Social Networking | Leave a comment

The Wonders of Off-by-One Defects

Yesterday, I happened to be filling out a Windows 8.1 Xbox Games message form.  I filled the form with exactly 0-characters left.

When I sent the message, I received a “message too long” pop-up, reminding me of the length limit.  Then it all disappeared.  I have no way of telling if a message was sent. 

There is no way to see message I’ve sent and I wasn’t offered a chance to clean up the message.

This is not the only place I’ve seen this, where either the characters-remaining counter, the test for message limit, or the announced message-length allowance (or all of the above) are handled incorrectly.  

It was a reminder to me of how prevalent this is and how the simplest possible test case is clearly not ever performed. 

The question this raises in the mind of me, the consumer: What other more significant and possibly security-related conditions are also inadequately confirmed and demonstrated by explicit testing?

Not even that skanky dufus, Spanner Wingnut, would miss this one.

Posted in Computers and Internet, nfoWare, nfoWorks, Professor von Clueless | Leave a comment

How to not Support Windows Platforms

This analysis presented by Ed Bott on 2013-01-01 reminds me of something that has been nagging me for the past couple of years.

It is amazing to me that web-site and application developers manage to be in complete denial about the distribution of operating-system and browser usage by those they proclaim to want as users and customers.  Here’s what I see as the bottom line.

  • Internet Explorer has 58.36% of browser activity, exceeding the total of all other browsers combined.
  • The combination of Windows 7 and Windows XP represent the most successful desktop operating-system deployments ever, with 78% of current usage. 
  • Windows 8+8.1 usage, at 9.3% exceeds that of all non-Windows operating systems combined, and it is early days for Windows 8.x.
  • The most-heavily used non-Windows desktop operating system is Mac OS X.

How is it that developers of web sites and of desktop applications are able to ignore this reality?  It seems to be ideological and the echo-effect of believers.  If you don’t support Internet Explorer, of course the visitor statistics will demonstrate a different population of access, distorting (and confirming desired) reality.  If your wares appeal first to a technologically-oriented population, of course you might see statistically-significant differences in your usage and supporter population.

The question is, who are you attempting to reach and how do you want to serve them?

I am reminded of this question every time someone at Coursera or Codecademy hand-waves the justification for Internet Explorer being discouraged for their sites. 

Is that self-selection consistent with an undertaking’s expressed goals?  As far as I can tell, that rationale simply excuses developers from testing against Internet Explorer.  It’s not fact-based.  It is convenient folklore.

Although I am a mere nano-scale open-source developer, I can tell you how I intend to target and develop for desktop platforms and browsers.  Deliver on Windows first.  Target the latest version first.  Confine platform dependencies to a portably-adaptable set that brings older versions of Windows and other platforms into practical reach.  Ensure that open-source/free tools can do the job, allowing others to contribute platform adaptations. 

It’s simple, really.

The accommodation of mobile operating systems and consoles is a different avenue that is also appealing to nanoISVs such as myself.  In that case, choosing an ecosystem might be an useful factor in determining how to broaden and possibly scale-out a hit.  It depends on the application.  For gaming, social software, and personal clouds, it will be interesting to see how this approach may also work as an avenue of entry for software offerings.

Posted in Geekiness, nfoWare, nfoWorks, Professor von Clueless, Toolcraft | 1 Comment

It has come to my attention …

… That a sizable proportion of recent posts on this blog are about my resumption of blogging, my dereliction as a blogger, and other public manifestations of my miscreant ways.

And I’m doing it again!

Well, I have resumed curation of my web sites.  Really.  It is a bit like trying to touch up the paint on a long-neglected, weathered house.  I am obsessive enough, so long as my other obsessions don’t distract me too much.

On this blog, I notice a significant problem.  Apparently, when the Hideout moved from Windows Live to WordPress, many of the images were sourced from links into Windows Live still (or perhaps someplace in SkyDrive).  And now there are all of these wide-open spaces for images that have no images in them. 

This blog was mostly meant to be a preservation point and an outlet for blog urgency.  It’s not intended to be permanent.  Now the problem is figuring out the easiest way to put it all back together.  I’m not certain and I think I am not quite obsessed enough to figure it out further.

See you around the Internet.  Really.  Some Day Soon (™ Jerry Pournelle).

Posted in Blog development, Orcmid's Lair, Windows Live, WordPress | Leave a comment

How an epic blunder by Adobe could strengthen hand of password crackers | Ars Technica

Via Dan Goodin on Ars Technica, 2013-11-01

Four weeks ago, Adobe disclosed a sustained hack on its corporate network that threatened to spawn a wave of meaner malware attacks by giving criminals access to the raw source code for the company’s widely used Acrobat and ColdFusion applications. Now, researchers are warning the same breach could significantly strengthen the password crackers’ collective hand by revealing a staggering 130 million passcodes used over the years by Adobe customers, many of them from the FBI, large corporations, and other sensitive organizations.

That’s because Adobe engineers used reversible encryption to scramble the passwords contained in a 9.3-gigabyte file that’s now available online. Surprisingly, they flouted almost universally recognized best practices that call for stored passwords to be protected by bcrypt or another one-way cryptographic hashing algorithm.  …

That’s not at all the way the passwords for the 130 million active and inactive Adobe accounts are protected. They were scrambled using standard symmetric encryption. If crackers are able to figure out the key or keys that encrypt the data, they will have instant access to every single plaintext user password in the list.

How an epic blunder by Adobe could strengthen hand of password crackers | Ars Technica

Even stranger than the passwords being decryptable by Adobe, and now others who can use a variety of exploits against those encryptions, is that the attacked system was a backup designated for decommissioning.   And that presumably idle data, sitting around vulnerable to insider exploits, was not encrypted in total, regardless of the individual records having encryptions of passwords.

Posted in nfoWorks, Privacy and Security, trust | Leave a comment