fyi On The Absurdity of "Owning One's Identity"

All:

Pointers to Bob and Phil:
http://notabob.blogspot.com/2006/01/on-absurdity-of-owning-ones-identity.html
http://www.windley.com/archives/2006/01/algorithmic_aut.shtml

Pointers from Jim:
First off, I want to point out that Bob Blakley is a very smart, intellectually stimulating, articulate, funny, and funnily pedantic individual (yes, I’m comfortable with “funnily,” and I urge you to get with the program as well). He was one of my absolute favorite speakers during the years in which I attended and (there’s rumor to the effect that I) spoke at, helped organize, and nagged external speakers to get their slides in shape for Burton Group’s Catalyst conference. (That would mean I was once employed by Burton Group, wouldn’t it? Wouldn’t it?) Bob will kill me for this observation, but I always perceived him as one part Dick Cavett, one part Mr. Peabody (the bespectacled, professorial canine with the Wayback Machine on the old Jay Ward cartoon). Close your eyes and listen to Bob talk: “Yes, Sherman, today we’re going to travel back to 500 B.C. to see if Romulus and Remus indeed built Rome in a day.”

All of which silliness is (believe it or not, Sherman) my segue into Bob’s blog discussion “On The Absurdity of ‘Owning One's Identity.” Bob was commenting on Kim Cameron’s “First Law of Identity,” to wit: “Technical identity systems must only reveal information identifying a user with the user's consent.” Bob interprets this “law” (he rips Kim a new one for calling this a “law,” but so have I, previously, so there’s no point piling on the poor man) as an assertion that people “own their own identity” and, hence, can control how that identity is used/abused by others. And Bob then proceeds to rip the stuffings out of this presumption as well.

Blakley argues that each of us has two types of identity (is this an exhaustive categorization, Bob?):

• One’s reputation: This is the story, he says, that others tell about you, and you can’t own it. You can’t even control it, because you can’t stop people from observing you, taking your picture, or talking about you, or stalking you so they can take your picture. Well, maybe you can get a restraining order in the latter case. But you see his point.

• One’s self-image: This is the story you tell about yourself. Presumably, you own it too. But you can’t force people to feel as kindly toward you as you feel toward yourself. Anyway, it’s always about you, isn’t it? Enough, already.

Bob has a great reputation—I’ve shared with you my story of Bob (which, of course, I used to work in the chief theme, which is the story of Jim). He’s a great thinker, but he sort of beats the analysis of this issue into the ground in his blogpost.

Still, his bottom line is important: We can’t really stop people from spreading stories about us—our reputation. And we can’t get them to necessarily buy into our stories about ourselves—our conceit. Nobody needs or asks our consent to use/abuse our identity in any of these ways. And there’s no way, short of superfreaky occult mind control, that we can monitor and enforce how everybody in the world feels about us all the time. And we can’t (and perhaps shouldn’t) control how/when/whether they use our reputation (attributes of our identity, filtered through the lens of their own perception of us and our character, motives, etc.) in going about their business.

Ergo, says Blakley, it’s unrealistic for Kim Cameron and his minions to require that “technical identity systems …only reveal information identifying a user with the user's consent.” And I agree with Bob on this: If I had to explicitly authorize every instance of disclosure of some scrap of my personal information that’s being held/controlled by some other party, I’d have 10,000 authorization-seeking e-mails in my inbox every morning, as opposed to the current, more manageable 7,000.

But rewind the Wayback Machine back several paragraphs, and look at Bob’s definition of “reputation” again: the story that others tell about you. Is that really what reputation is? It seems to miss the mark by being too inclusive. If someone writes my biography (story of my life), is the final product my “reputation”? If someone simply compiles a timeline of key dates in my life (the story of my life), is this dry recitation of documented facts my “reputation”? Of course not.

Now, roll back the Wayback Machine to November 27, 2005, and look down the scroll of this blog to the “imho identity privacy reputation” posting midway through the Abhilasha thread. Proving that no one out-pedantics Jim Kobielus, I shall now proceed to quote myself at length:

“Reputation isn’t an identity, credential, permission, or role. It isn’t exactly an attribute, in the same sense that, say, your birth date or hair color are attributes. And it isn't something you claim any privacy protection over--it's the exact opposite: the court of public opinion over which you have no sovereignty and little direct control.

”In the IdM context, reputation is more of an assurance or trust level—an evaluation of the extent to which someone is worthwhile to know and associate with. Assurance generally refers to the degree of confidence that a relying party can have when accepting a password, certificate, token, assertion, claim, or other credential that is associated with a particular identity. Fundamentally, assurance is the confidence that someone else is reasonably safe to do business with. Assurance serves the relying party, allowing them to strongly verify the authenticity and validity of others’ identities, attributes, credentials, and assertions. It provides the relying party with the information they need to determine whether to refrain from, closely monitor, and/or repudiate online interactions in which such verification is lacking. It also gives the relying party the confidence that, if adverse consequences result from doing business with someone, the responsible parties can be pinpointed effectively so that appropriate legal, business, and other remedies can be pursued.”

”Reputation is relying parties’ evaluation of our reliability, of their liabilities, and of the degree to which associating with us makes them ill at ease. Appearances are assurances, for good or ill.”

Me again, back to this evening, January 25, 2006, to point out an important truth: Reputation isn’t an attribute of our identity, and it isn’t a story, really. It’s simply an assurance, confidence, or comfort level in which others regard our identity. It’s a vague, qualitative, holistic, often semi-conscious impression, calculated somewhere in the reptilian mind that has descended to us down through the ages. Quoting myself again:

“Relying parties—-the ultimate policy decision and enforcement points in any interaction—-need many levels of assurance if they’re going to do business with us. They gather assertions and data from many IdM “authorities” (authentication authorities, attribute authorities, etc.) before rendering their evaluations and opening their kimonos. They—-the relying parties—-make reputation evaluations based on information fed in from trusted authorities, from their own experiences with us, from whatever reputation-relevant data they can google across the vast field of received opinion and public record.”

Reputation is a computed halo—positive or negative--around our socially contextualized identities.

Which is my segue, believe it or not, for introducing my first mention of Phil Windley into my blog. In his recent blogpost “Algorithmic Authorizations,” Phil asks a great question: “Can anyone think of other examples besides credit scoring where authorization to access a resource is computed instead of being looked up in a table?”

Sure. Reputation is a score computed by relying parties in order to determine whether or not to authorize the reputed party to access resources such as jobs, communities, romantic encounters, time of day, etc.

Reputation is an assurance that someone is worth our while.

Jim

imho The Great Chain of Identity Assurances

All:

Strong end-to-end assurance is the foundation of trusted e-business and regulatory compliance. Assurance is a concept that can and should be applied to the whole of identity and trust management—including the new worlds of federated identity management (IdM) and federated data interchange--though it has historically been defined primarily in the electronic authentication and PKI worlds.

Traditionally, security professionals have defined assurance in terms of discrete “levels” that PKI and other credentials providers implement in their technical and business models. In that context, assurance levels—either enumerated (e.g., levels one through four) or named (e.g., basic, medium, high)—refer to a constellation of processes, protocols, formats, infrastructures, and other safeguards and controls implemented by certificate authorities, registration authorities, and other roles within an identity, trust, and security environment.

Organizations should describe their supported identity-assurance levels in published identity policy and practice statements. Vertical industry sectors should strongly consider defining standard federated identity policy and practice statements formats and rules that are applicable to all firms doing business in those markets. Furthermore, vertical sectors should consider relying on trusted third parties (trusted third parties) to vet and certify organizations’ published federated identity policy and practice statementss for compliance with accepted standards. In this way, all trading partners in a particular industry might be able to rely more thoroughly on the trustworthiness of each others federated IdM “claims,” “tokens,” or “assertions,” knowing that all participants’ federated IdM procedures have been certified to a common standard.

Within a federated identity/trust environment, trusted third parties can provide some critical assurance services: vetting, certifying, and vouching for the equivalence of all organizations’ compliance with common IdM and PKI assurance policies, best practices, and standards. In pursuing such an approach, the B2B e-business communities would be ensuring that any federated identity policy and practice statements-compliant company is eligible to participate in the community’s federated IdM environment. For example, the identity policy and practice statement standard might prescribe mandatory identity and account management policies, procedures, and practices rules applicable to export/import control throughout a multinational B2B supply chain that includes dozens to thousands of firms. Similarly, the community-wide federated identity policy and practice statements standard might specify minimum privacy-protection safeguards that all companies would need to meet in order to pass regulatory muster in all participating nations. From an efficiency perspective, a trusted third party should certify companies’ compliance with federated identity policy and practice statements standards. In this way, this trusted third party can perform a function analogous (and complementary) to the bridge certificate authorities of the PKI world.

To serve the relying parties in federated IdM interactions, IdPs should be able to generate assertions that attest strongly to their federated identity assurance level, as published in their federated identity policy and practice statements and certified by a federated identity policy and practice statements trusted third party. One critical piece of information that these assertion messages might contain is a description of the assurance level—such as two-factor authentication—associated with a particular login. The relying party would use this information in determining whether authentication had been done at a high enough assurance level for the requested resource (such as a highly sensitive operational database). Ideally, a relying party should also have visibility into the policies, practices, and controls implemented at the IdP. This knowledge would enable the relying party to determine whether the IdP has issued its assertions pursuant to sound, secure operating practices. The more trustworthy the IdP’s policies and practices, the more trustworthy the assertions issued by that IdP.

Of course, it’s not enough for an organization to simply assert that it complies with particular IdM policies. For other organizations to fully rely on a particular federated identity policy and practice statements, an IdP would first have had to gain certification from a trusted third party that had investigated and vetted that IdP’s internal procedures and controls. The trusted third party would then issue a digital signing certificate which the IdP would use to digitally sign identity assertions, confirming the IdP’s adherence to a particular established and published IdM federation policy. The trusted third party might, within its federated identity policy and practice statements-compliance assertion, also vouch for the mapping or equivalence between the IdP’s identity policy and practice statement and those of the relying firm, or the standard federated identity policy and practice statements for a particular vertical market, nation, or community. Other domains would be able to rely on those trusted third party-issued federated identity policy and practice statements compliance and equivalence assertions when deciding whether to trust that IdP’s authentication and attribute assertions. In this way, through trusted third parties, federated IdM environments can establish multilateral trust for strong authentication, SSO, RBAC, and other services. Consequently, the trusted third party becomes the hub of a federated B2B “community of trust,” providing the critical services of IdP identity policy and practice statement policy definition, vetting, mapping, certification, and vouching.

Conceivably, one could define a chain of identity assurances that each IdP would assert in its federated identity policy and practice statements. Fundamentally, identity assurance is defined by the degree to which a person’s online actions can be tracked and measured against an IdM best practice to which their IdP has committed in its federated identity policy and practice statements. Strong identity assurance could be predicated on the extent to which a given identity’s online interactions can be strongly associated, bound, or linked to demonstrated norms of IdM “best practice,” per applicable laws, regulations, policies, and industry best practices.

The chain of identity assurance associates the actions that a user takes in an online session with the consequences of those actions:

• Assurance of association between an online session and a credential: This requires client-signed session assertions, signed cookies, or other means for strongly binding an online session to a credential under which a user logged into that session. In turn, client-signed session assertions or cookies require PKI X.509 end-entity digital signature certificates and private keys. All that, in turn, requires strong PKI assurance.
• Assurance of association between a credential and a digital identity: This requires PKI X.509 end-entity identity certificates, which cryptographically bind an identity’s private identity key to the corresponding public key, and to a unique identifier such as UPN, X.500 DN, or UPN.
• Assurance of association between a digital identity and a real person: This requires PKI registration authorities to issue and renew X.509 end-entity certificates only after in-person proofing/vetting that involves having a real person present a government-issued picture ID and other supporting identifying documentation. It also requires that the request for registration or renewal of a PKI certificate/token obtain all necessary administrative approvals within the IDP that has issued the unique identifier that will (upon certificate issuance) be cryptographically bound to a public key (published in the certificate) and a private key (to which only that real person will have authorized access). In addition, provisioning of certificates to proofed users should only follow user authentication to the CA through entry of a one-time secret proofing passcode provided at proofing time by a trusted agent of the CA.
• Assurance of association between a real person and an IdP: This requires that the IdP that issued the unique identifier published in the real person’s end-entity PKI certificates maintain that identifier in a published master directory administered and controlled by the IdP. The IDP’s master directory must securely and reliably synchronize, replicate, and/or publish that master identity information to other directories and repositories, or vouch via SAML authentication or attribute assertions for its continued registration in the master directory. In addition, the IdP must use identity information in that master directory to drive the automated provisioning and deprovisioning of accounts associated with real persons.
• Assurance of association between an IdP and an IdP-asserted federated identity policy and practice statements: This requires that IdPs digitally sign any federated identity policy and practice statements that they assert with a digital signing private key held by an authorized corporate officer.
• Assurance of association between an IdP-asserted federated identity policy and practice statements and a trusted third party-published federated identity policy and practice statements: This requires that one or more trusted third parties develop and publish standard federated identity policy and practice statements formats. It also requires that trusted third parties investigate, vet, and certify equivalence or conformance between an IdP-asserted federated identity policy and practice statements and a trusted third party-published federated identity policy and practice statements.
• Assurance of association between a trusted third party-published identity policy and practice statement and trusted third party-vouched observation of identity’s demonstrated compliance with norms of IdM “best practice”: This requires that one or more trusted third parties track, monitor, and audit real people’s online behavior. It also requires that trusted third parties determine the degree to which that behavior conforms to the norms of IdM best practice that they and their IdPs have pledged to comply with, in the form of published identity policy and practice statement.

This last point is where federated IdM assurance environments would perform a critical role in stamping out phishing, pharming, and other crimes against e-business assurance. Identity theft, fraud, and impersonation violate all norms of IdM best practice, and also are criminal and civil offenses in a growing number of jurisdictions. Any real person that commits identity theft, and any IdP that actively or tacitly supports such behavior, might be held legally accountable for their behavior.

A well-architected federated IdM assurance environment would provide the identity, security, policy, management, and procedural controls necessary to prevent, detect, eliminate, and punish these violations of e-business trust.

Jim

fyi Open-Source License Debate Kicks Off

All:

Pointer to article: http://www.informationweek.com/news/showArticle.jhtml?articleID=177101776

Kobielus kommentary:
Ah yes…epic battle…open source vs. digital rights management (DRM).

And classic language, from the GPLv3 draft (note the rascally redefinition of the acronym): “"Some countries have adopted laws prohibiting software that enables users to escape from Digital Restrictions Management," the draft reads. "DRM is fundamentally incompatible with the purpose of the GPL, which is to protect users' freedom; therefore, the GPL ensures that the software it covers will neither be subject to, nor subject other works to, digital restrictions from which escape is forbidden."

In other words, no software licensed under GPLv3 (as currently drafted) may be used in products that implement DRM. Put in economic terms, a growing universe of for-free code is offlimits to those who might wish to use it to chain, contain, restrain, and meter for-pay content. So those who dream DRM will have to scrounge or gin up their own non-GPLv3 code in order to build their content constrainers.

Which, of course, they’ll easily do. Content owners (of which I'm one, though most of what I own copyright to is now utterly worthless) will spend whatever they need to spend to fortify their lockboxes. But, with the DRM-buster in GPLv3, they won't be able to do so as cost-effectively as if they had access to the full open-source universe to do so.

Call GPLv3 a symbolic stand against overzealous DRM. It may not derail the DRM overkill juggernaut. But it serves notice that those who would free software would also free the information that often gets imprisoned therein.

Jim

fyi Progress Software buying Actional for $32M

All:

Pointer to article: http://www.computerworld.com/softwaretopics/software/story/0,10801,107867,00.html?source=NLT_PM&nid=107867

Kobielus kommentary:
ESB is the most promising new middleware approach. ESB generally refers to integration software that supports simple, expedited, loosely coupled, standards-based, service-oriented integration. It also refers to a segment of middleware market that converges the best features of message-oriented middleware, integration brokers, and Web services.

The ESB market is heating up, but possibly also melting down. In the past month, we’ve seen two ESB vendors—Sonic Software (an operating unit of Progress Software) and Systinet—merge with SOA governance vendors: Actional and Mercury Interactive, respectively. ESB environments need the policy-driven management provided by robust IT governance tools.

However, neither Sonic/Actional nor Mercury/Systinet will be able to compete for long against the SOA platform vendors—especially IBM, BEA, Oracle, and Microsoft—who are adding ESB and IT governance functionality to their suites at a rapid clip. When the ESB market matures by the end of this decade, ESB pure-play vendors will find their value proposition usurped by platform vendors that have embedded ESB functionality into their offerings.

Many SOA platform vendors are embedding ESB functionality more deeply into their environments. They do so in order to address a broader range of integration scenarios, to support their own integration software products, and to position their platforms as alternatives to third-party integration software. What, for example, is Microsoft’s Windows Communication Foundation (WCF) if not an attempt to push ESB functionality more deeply into Windows.

In the next 2-3 years, the ESB wave may give some platform vendors an advantage over their direct competitors. When Microsoft delivers commercial WCF--and Windows Workflow Foundation (WWF)--functionality in Vista and “Longhorn,” the company will be able to position its server and client platforms as ESB-enabled out of the box. Microsoft has committed to running WCF on pre-“Longhorn” Windows platforms—Windows XP and Windows Server 2003--as well, which will further strengthen its ESB and SOA story.

Over the next several years, platform vendors who fail to address ESB functionality in their roadmaps will marginalize themselves out of the SOA market. Minor platform vendors won’t be able to survive in a market that will eventually be dominated by SOA platforms. Systinet did the right thing by seeking out and finding a suitor, though the combined Mercury/Systinet is on no one’s short list of leading ESB/governance vendors.

At the very least, all platform vendors will need to implement WS Reliable Messagnig (WS-RM) in their architectures in order to enable reliable, guaranteed, once-only delivery of SOAP messages over Web services environments. Any SOA platform vendor that fails to do so, and clings tenaciously to its proprietary middleware, will find itself shut out of the ESB space.

By the end of this decade, ESB functionality will just be common-denominator functionality implemented on all platforms, leveraging the industry’s common denominator interoperability stack: the WS-* stack. As ESB functionality becomes ubiquitous in application platforms, pure-play ESB middleware vendors will find the going tough. Today’s ESB middleware market segment will fade away, absorbed into the SOA platforms that will dominate all distributed environments. In order for these SOA platform vendors to distinguish their commoditized ESB features, they’ll have to keep evolving up the functionality stack, adding Web services management (WSM), dynamic content-based routing, distributed transactions, and other advanced features.

As regards WSM functionality, there’s little of that in today’s ESB market—that’s why the merger of Sonic (the ESB pioneer) and Actional (one of the WSM pioneers) is so significant. ESB vendors will layer WSM functionality on their product architectures in the coming years. It’s very likely that other WSM pioneers, such as AmberPoint, will find suitors in the ESB space. Another likely development is for network appliance vendors—such as Cast Iron Systems, Cisco Systems, F5 Networks, and Solace Systems—to reposition their products as high-performance ESB message processing nodes.

ESB-enabled SOA platforms will dominate, and also accelerate the decline of today’s separate ESB middleware market. The rest of this decade will see ongoing acquisitions, mergers, and consolidations among platform and middleware vendors. In particular, Sonic, TIBCO, Cape Clear, and Fiorano, though currently positioned well in the ESB space, won’t survive unless they partner or merge with SOA platform vendors. The surviving ESB-enabled SOA platforms will probably number no more than a handful.

No, I'm not placing any bets. Not a betting man.

Jim

fyi It's Just the Key to Your Room

All:

Pointer to article: http://www.computerworld.com/securitytopics/security/story/0,10801,107701,00.html?source=NLT_AM&nid=107701

Kobielus kommentary:
Fascinating discussion. Most mag-stripe hotel key-cards “contain only a room number, a departure date and a ‘folio,’ or guest account code -- although other data may be stored on them as well.” So, essentially, the key-cards are a credential/entitlement token tied to an identity and account maintained by the service provider (the lodging establishment) for a limited-duration facility-access grant. The property management system (PMS) links the identity (the customer name, address, credit-card info) to the access grant (the room reservation) and provisions and deprovisions the credential/entitlement token. The doorlocks enforce the entitlement grant (without the need to communicate with the PMS) by requiring the presence of a guest account code and comparing the departure date with the current date (presumably, tracked through a clock in the lock). The lodging establishment needn’t (and rarely does) encode your name/address/credit-card on the key-card itself, because billing for your use of this limited facility-access grant is handled through the PMS.

All of which reminds me of another great urban myth as regards hotel rooms: that the bed, dressers, desks, TVs, phones, and other surfaces are slathered in dried (invisible) semen stains. We’ve all heard this. I’m assuming it’s just a myth. It sounds like nonsense. Where did this myth originate from? How is it sustained? Who tests for this? Assuming it’s true in some cases, is it a general phenomenon across all rooms in all lodging establishments of all grades and in all states and countries? More important, is there any greater prevalence of dried semen in hotel rooms vs. people’s own bedrooms? People clean their own bedrooms and launder their own sheets far less frequently than most hotel/motels do theirs. Has anybody done any comparative studies?

Are people subconsciously worried about telltale DNA stains they leave behind in strange places? They should worry more about flaking skin and fallen hair shafts. We leave those DNA traces everywhere and never think twice about them.

Just as telling: The other peoples’ hair that can be found embedded in the carpet next to ours. Semen stains alone only tell half the story.

What story? Make up something. I’m sure you all have good imaginations where this sort of thing is concerned.

Jim

fyi Attacks mounting on 'Million Dollar Homepage'

All:

Pointer to article: http://www.computerworld.com/developmenttopics/websitemgmt/story/0,10801,107743,00.html?source=NLT_PM&nid=107743

Kobielus kommentary:
This is a case of the harder they come, the harder they’re hit. This page is an act of pure Internet-age hubris and opportunism, and to be admired for that. It shows how mere notoriety can be monetized to the hilt. Clearly, it’s no scam, just an ingenious moneymaking scheme: Tew is, quite transparently and honestly, selling a lease to presentable pixels over time, and the “rent” on this commodity is quite clearly derived from notoriety-stoked demand.

But, honestly, this is a crock: Notoriety has an extremely limited shelf life, especially in the overcrowded cybersphere. This site and these pixels were suddenly hot last week and this, but will soon be forgotten and never visited again by a mortal soul. Consequently, the pixels will be practically worthless for over 99 percent of the life of their lease. And even during their “heyday” (now), they’re of questionable value.

Case in point: I still haven’t viewed this “Million Dollar Homepage,” though I tried browsing to it several times last week (in its heyday—-its sweet spot--its period of max commercial value to tenants). I waited and waited for the page to download, and grew tired and eventually backed out before the access attempt had a chance to time out on me. This million-second wait may have been due to the huge volume of concurrent access requests, or to the DDoS attempt reported in this article, or to both. I don’t care.

What I do know is that even during the magnet page’s heyday, its effective value as a promotion, advertising, and clickthrough medium to its tenants was effectively zero.

As I said up above, the “Million Dollar Homepage” wasn’t technically a scam. Just a clever stunt that benefited precisely one party.

Jim

fyi How can DRM be good?

All:

Pointer to blogpost: http://www.lllj.net/blog/archives/2006/01/06/how-can-drm-be-good/

Kobielus kommentary:
In just a sec, you’ll have me kommenting on komment #8 on Lloyd Shepherd’s blogpost on DRM. Here’s that komment #8 again, sparing you the need to flip back to that (and away from me—hey, I’m trying to keep your eyeballs sticking here for a few more minutes):

o “All digital file formats become obsolete with time. DRM is designed to be incompatible and non-convertable, so the the real market test comes when people discover that all the multimedia they have bought is no longer supported by the newest hardware and that there is no easy way to convert it to the new platform when their old platform has been made defunct (for marketing reasons?). Even now, though for example divorce and migration, a few people have already discovered some of the unexpected limitations of DRM’ed multimedia. The only bright side to all this is that as long there are programmable general purpose computers one can always convert multimedia from a limited and incompatible (DRM) format into a portable open format. (See Microsofts’ Darknet paper). Lets just hope that DRM proponents don’t end up banning programmable computers and criminalizing DIY programming.”

This is the number #1 argument against universal DRM becoming a practical reality any time soon. Let’s look at the dynamics of the DRM space:

o Kontent seeks maximum distribution, availability, and consumership over its economic life, or over the life of consumer interest, which ever is longer (for the daily news, the economic life is a few days or weeks, for most content; for masterworks of literature, music, cinema, etc, the life of consumer interest in the indefinite future—future generations/eras will keep republishing and redistributing and reconsuming this stuff).
o Kontent that remains balkanized into incompatible, platform-specific, provider-specific, or otherwise fragmented spheres of distribution and consumption will revolt against those strictures and structures (especially for the masterwork kontent of perennial consumer interest).
o Kontent that remains locked into those strictures and structures will die in the marketplace, or die with the inevitable death of the enabling/capturing platforms; consequently, DRM technology (the enforcer of those strictures and structures on evermore access to perennial kontent) will die in the marketplace as well, unless it somehow becomes universal in implementation and also agile enough to support maximum (i.e., free, as in strictureless, and free, as in gratis) distribution/availability/consumership to kontent that demands (sometimes in spite of its owner/provider’s wishes) liberation.

Sounds like an unresolvable paradox. All the dynamics in the cybersphere militate against universal DRM. All the kontent of perennial consumer interest will migrate toward the gratisphere. Hence, all kontent period, even the ephemeral stuff, will find its way there too.

Circumventing whatever gantlet of strictures and structures the purveyors of the DRM pipedream lay down.

Jim