November 3, 2007

Harold's OpenSocial Exploit

Harold the Rebel has demonstrated how an OpenSocial gadget can run rampant in its container. Because Ning is executing his gadget's code in an iframe that they served up, his widget is able to access window.top.document. As Ning is serving his gadget via proxy, Harold could have initially submitted an innocent version of the widget and then changed it later on.

Ning obviously will start to parse incoming gadgets for malicious code as will every social software service using OpenSocial.

Unfortunately, the gadgets XML format does not use namespaces identified by URIs, much less a widely recognized way to refer to the document author and other essential metadata. As a gadget is essentially a working html document, it should follow all of the conventions of one. These oversights essentially leave OpenSocial gadgets "disconnected" from the emerging data web, increasing the difficulty of forming of a reliable and open web of trust around them.

November 2, 2007

Getting a Handle on OpenSocial Gadgets

Kudos to Danny for exposing and then mitigating the ugliness of OpenSocial's PersonKind!

In spite of all the positive feelings I have about the intentions of OpenSocial, I think that I'll take aim at its shortcomings as well.

My goal is to start building a way to be able to embed an app into some of these early-adopter communities. Looking over the Javascript API's Developer's Guide it appears as if I am required to use the Google Gadget API to be able to embed.

I hope that this is not the only way to do it, because the gadgets are not very pretty. This gadgets XML format that is about to be very, very widely used to embed web apps is seriously begging for an organized standardization effort. It looks like something that I half-put together in 1999. For starters, no XSD or XML namespaces are to be found. The xml description and the examples listed throughout the gadgets documentation do not even encourage developers to indicate what sort of XML a passerby is looking at, much less what version of the gadget format it represents. Should a developer (much less an automated process) come across a gadget in the wild, he would have work a while to figure out what the document is and what its elements are used for.

I can momentarily find it in my heart to sympathize with a developer who would choose to skip the XSD creation for something used in a very isolated capacity. But it is absolutely a requirement for a format that is going to be used... just about everywhere! The lack of clarity in the gadget XML format is not worth the bits conserved or the apparent simplicity for less-experienced developers.

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
 <ModulePrefs title="List Friends Example">
   <Require feature="opensocial-0.5"/>
 </ModulePrefs>
 <Content type="html">

 <![CDATA[

 <script type="text/javascript">

 /*Request for friend information when the page loads.*/

  function getData() {

    document.getElementById('message').innerHTML = 'Requesting friends...';

    var req = opensocial.newDataRequest();

    req.add(req.newFetchPersonRequest('VIEWER'), 'viewer');

    req.add(req.newFetchPeopleRequest ('VIEWER_FRIENDS'), 'viewerFriends');

    req.send(onLoadFriends);

  };

 /* Parses the response and generates html to list the friends */

  function onLoadFriends(dataResponse) {

    var viewer = dataResponse.get('viewer').getData();

    var html = 'Friends of ' + viewer.getDisplayName(); 

    html += ':<br><ul>';

    var viewerFriends = dataResponse.get('viewerFriends').getData();

    viewerFriends.each(function(person) {

      html += '<li>' + person.getDisplayName() + '</li>';

    });

    html += '</ul>';

    document.getElementById('message').innerHTML = html;

  };

  _IG_RegisterOnloadHandler(getData);

  </script>

  <div id="message"> </div>

  ]]>

  </Content>

</Module>

Source: OpenSocial: List Friends Example

The ModulePrefs, aside from preferences and "Require" dependencies, is used to store metadata for a gadget, including title, author, author_email, and so on (see the XML below). This is beyond silly and gives OpenSocial implementers many reasons to say: we can do better.

One big picture question that is begging to be asked is whether it is realistic or not to expect MySpace, SixApart, and the dozens of other competing communities to fully implement all of the functionality that appears in this API? This is quite a lot of cooperation to expect from everyone involved and I suspect that the various gadget container implementations will begin to remind us of the brower wars of the late 1990s.

Except that this time there isn't an objective party like the W3C in the center of the field. Not yet, anyhow.

Back to creating my OpenSocial UI, the simplest way to display something using one of these gadgets is to supply a url which the javacript of the container app will use to load the external content. This is how the DogstarRadio embed works:

<?xml version="1.0" encoding="UTF-8" ?> 
<Module>
  <ModulePrefs 
    title="Now Playing on SIRIUS"
    height="60"
    width="250"
    description="Displays what is currently playing on Sirius Satellite Radio using data from DogstarRadio.com"
    author="DogstarRadio.com"
    author_email="schedule@dogstarradio.com"
    title_url="http://www.DogstarRadio.com"
    screenshot="http://www.DogstarRadio.com/images/now_playing_gadget_screenshot.png"
    thumbnail="http://www.DogstarRadio.com/images/now_playing_gadget_thumbnail.png"
    >
    <Require feature="opensocial-0.5"/>
  </ModulePrefs>
  <Content type="url" href="http://www.dogstarradio.com/sirius_display.php?size=gadget">
  </Content>
</Module>

Source: Ning's OpenSocial Gadgets Directory

Appropriately, there is a size=iphone for this URL. Seeing this, I wonder what the HTTP_USER_AGENT for the XHR client would look like to my embeddable app. I suppose that I could just create a separate controller for all embeddable functionality and then send an initial call to my hosted app containing metadata about the OpenSocial container and embedding member.

To accomplish this I can use the Remote Content APIs, a means to supply the embedding app and its OpenSocial hooks with data returned from the external app. This is one of the most interesting parts of the system. Of course it might also be the most dangerous.

While these methods will encourage more javascript code and UI to be placed into the horrid Module XML, I expect them to be a boon to developers stumped by browser cross-domain security restictions.

September 20, 2007

SixApart: Opening the Social Graph

I've been crossing my fingers, hoping that SixApart would take OpenID to the next level and open up their systems elegantly - or at least assemble the parts and promote the concept - leading the way for the huge number of social software sites out there to open their data up. This intriguing post indicates that the wait may be over:

We think that the best way for you to manage your network is to stop thinking about all of the little pieces and to start focusing on the big picture: you and the people who matter to you. We think relationships mean more than email addresses or which service you're signed on to at the moment. So we've created an experimental demo based upon open technologies OpenID, the Microformats hCard and XFN, and FOAF that allow you to see your entire network of relationships in one place - across services, across platforms, across the entire Web.

Source: We Are Opening the Social Graph

I wired OpenID into my Memecat experiment but delayed the development of "social networking" with the hope that the next iteration of what BlogLog does would emerge. I would have done "friends" myself, but I don't have too many members. There must be a lot of sites out there in this position.

Check out the video demo.

March 6, 2007

Scribd, more than just a pdf viewer in flash

Scribd is a document sharing community done right. The pdf "viewer" in flash idea truly rocks, but equally amazing is the clean simplicity with which Scribd organizes their social community, traffic analytics, and other things.

The irony of viewing pdf inside of flash is palpable, except that it looks like Scribd is using Flashpaper to do this.

Flash is becoming the everything viewer, for better or for worse.

December 8, 2006

Exploring Social Annotations for the Semantic Web

Slashdot indirectly pointed me to a very useful paper that was presented last May at the 15th WWW Conference. In Exploring Social Annotations for the Semantic Web, Xian Wu, Lei Zhang, and Yong Yu describe an approach to improving the disambiguation of tags within social bookmarking service. The "co-occurrences" of tags logged by users with similar interests for a given url are analyzed to form knowledge categories and to derive the semantics of the free-form assertions made by users.

Representation of Semantics:

• We represent semantics of an entity (a web resource, a tag or a user) as a multi-dimensional vector where each dimension represents a special category of knowledge.
• Every entity can be mapped to a multi-dimensional vector, whose component measures the relativity between the entity and the category of knowledge. If one entity relates to a special category of knowledge, the corresponding dimension of its vector has a high score.
• The total knowledge of users, tags and resources are the same, we can represent them in the same multi-dimensional space, which we call conceptual space.

Source: Slides from the WWW2006 Presentation

As more objects in web apps become taggable by users, this approach can be used to determine which object properties users are interested in annotating, searching, and viewing. The UIs for lists and views could even be customized per user to emphasize the aggregated data of other users with similar interests.

October 5, 2005

Ning Content Store

Chris covers this subject in much more detail, but I'll post anyway.

I was looking around Ning (perhaps Ning around?) and noticed an interesting blog entry about the Ning Content Store.

This hosting service provides its community with "data playdough" in the form of content objects which can be read (but not written) across apps. There is no direct management of the data store, although you can browse the data using the RESTish pivots.

The biggest difference between the Content Store and a traditional RDBMS is that in the Content Store, there is no definition of content structure separate from actual content. There are no table schemas that must be set up before rows are inserted. The type and developer attributes that an app chooses to use at runtime are the type and developer attributes that end up in a content object.

Restrictions on content type and structure are not enforced by the content store. That job is left to the app. This allows apps to be much more flexible about the data they manage. Creating an app that allows end-users to define their own fields in addition to those defined by the app developers (such as a flexible calendaring app or a to-do list manager), is unwieldy in a relational database -- in essence, a developer would have to create a mechanism like that provided by the Content Store natively. Queries and data management are simpler, and apps can be both more flexible and more powerful, without making them harder to build.

Source: Ning Dev Docs

I prefer the structured approach to defining application data, but I understand why Ning's developers are prioritizing convenience. Over time, conventions and standards will emerge in the Ning community, and us structured folks can always help.

Playdough and Lego bricks are both great ways to build things.

March 16, 2005

Semantic Micro-Content

Yahoo! 360° (previously known as Mingle) will apparently allow users to post brief assertions such as movie and music reviews. Will Yahoo! connect this data to the greater web?

By far - the most interesting features Mingle has - is it's support for various kinds of micro-content. This is something I've been predicting for a while now.

The natural way to delineate out and chop up all this end-user content - is to see it from a 'micro-content' POV. Notice this idea - as opposed to the burgeoning 'lower case semantic web' notion of microformats.

Micro-content is the notion that Reviews, Events, People, Lists, Media, etc. are what humans understand - and that many, many data silos have captured end-users content - to use it for themselves (Epinions comes to mind.) Source: Marc Canter

I can see some interesting features to add to MT and Wordpress!

December 15, 2004

Digging into Digg

Continuing the evolution away from the "avant-garde" editor approach of Slashdot and Boing Boing, the beta version of digg allows community members to flag and categorize stories which they feel are significant. It extends the del.icio.us concept with a quick voting mechanism, but limits the number of categories.

How digg expands the rating and rewarding of better story-spotters is going to be interesting. There probably should be some limit to the number of "diggs" (the currency of this site). To continue my usual market-oriented thinking, a cut of future diggs for a particular story should be awarded to those who flag and tag that story early on.

Spotter: del.icio.us (where else?)

May 3, 2004

PeoplesDNS

Joel De Gan of PeoplesDNS has posted Whats the problem with FOAF?. He intends to add centralization, private information, social circumstance, and groups - all through his FOAF dns concept. It looks like he will use the RELATIONSHIP (the older one?) and Trust ontologies in this effort.

I am very interested in how community centers will use concepts such as pDNS and what their role in the development of open social networking will be. Social "routers" will be able to provide a level of customization (of information, participation, formality, and privacy) which will be required to break social networking away from the big social networks.

PeopleDNS will use a "De Gan Filter" to handle the anticipated large dataset. Last week, Danny Ayers posted a brief summary of De Gan's implementation of bloom filters.

April 22, 2004

TalkBack: Reply on My Blog

RE:
How to Make Blogging More SemWeb Friendly,
RSS Conversations,
Topics in Weblogs,
Threads of Conversation.

This particular fork got started here.

Blog-to-blog conversations are easily fragmented, with responses residing on blog discussion boards, the responder's site, and on various tracking services.

I have been thinking about how to implement a "reply on my blog" link which would enable a writer to reply using his own CMS.

Implemented with current web technology, this idea assumes that the API of the responder's blogging software can be known to the site which he is responding to. This reply would link to a script on the original site, which, after noting the action, would redirect the request to the content management system under the responder's control.

RDF for the original entry (and historical data about the conversation) would be passed to the responder's CMS in the url string. He would respond. As his CMS updates his blog, his response would be forwarded on to the cited blog (which would be expecting it), trackers, aggregators, and online communities.

Additional concepts:

• the responder would be provided with a standard blog posting page, perhaps with: a listing of links in the original post, metadata about the discussion, information about the participants, a way to view the conversation tree, etc.
  
• any metadata (such as dc:Subject and the tracking service of choice) assigned to the entry by the original blogger could carry over to the responder, who could add additional metadata. But how much metadata should accumulate?
  
• the effort to implement something like "reply on my site" would add to the culture of interoperability between sites (as TrackBack did)
  
• threading, summarization, and other forms of conversational analysis could be performed by any interested party, provided that the RDF can be obtained from each participating site
  
• organized conversation forking could be supported
  

April 16, 2004

FOAFed

Marc Canter complained about how AskMyNetwork mined one of his FOAF sets to pre-populate his social network. Dom Ramsey posted a great response to this compaint. He pointed out that AskMyNetwork gets its FOAF data from PLINK (both of which he operates). A YAFA is feeding a YASNS.

So what's so bad about evolution through YA* anyway?

April 7, 2004

Relationship Theme Parks

David Weinberger posted a great reply to Clay Shirky (RE: The truth about why I hate Friendster).

March 31, 2004

Situated Software

Clay Chirky has posted Situated Software, an interesting essay in which he describes new approaches to software customization.

Situated software isn't a technological strategy so much as an attitude about closeness of fit between software and its group of users, and a refusal to embrace scale, generality or completeness as unqualified virtues. Source

March 24, 2004

Danah Boyd on RELATIONSHIP

Danah Boyd has posted a thought-provoking criticism of the RELATIONSHIP ontology (by way of Marc Canter) While I approach this matter from a strongly technical perspective, the perspective she presents should be carefully considered as we define social software standards.

• Relationships are situated within a CONTEXT.
• Relationships are defined by CULTURE; their types are SOCIAL CONSTRUCTS.
• Relationships do not exist without POWER.

Source

My answer is that we will have to allow the semantics of relationships to emerge from the somewhat distorted political dynamics of the labeling process. Openly developing standards for the assignment of relationships surely is better than relying on online services to force standards through flat, html interfaces.

Categorical Context

At the very least, the surface sort of relationship context (i.e. defined by logical groups of relationships) must be incorporated into a relationship ontology. Beyond adding a new dimension of expressiveness, this would create a natural framework for participation. I can see all kinds of useful (and humorously useless) ontologies of relationships withing a certain category being maintained. RDF and OWL allow for contributions from whomever wishes to host one - what ends up being adopted is a different matter entirely.

Perspective

The context of perspective (i.e. defined by who may be viewing this information about your relationship) is something that must be customized by the person maintaining their own information. Identifying the viewer would allow more detailed access, or contextualized access, to the relationship resources.

Culture

As for the cultural aspect, this can be accomplished through subclassing of context, or through the definition of new contexts. Translation services might play a role in how this information may be understood by people of other cultures. Lets be friends in the American sense, or pen pals in the Japanese sense. Actually, lets just be friendster friends.

Power

The power dynamic aspect may be (somewhat badly) incorporated into a standard through guiding the formation of a relationship, especially those which may need to require some sort of verification. Ultimately, the complex power dynamics of relationships should be simply interpreted by the users. My favorite implementation of this notion: the "open marriage" designation.

With a more expressive ontology for defining relationships (certainly more so than RELATIONSHIP), we may actually end up with a better understanding of the social dynamics of the real world, across the world. In order to have a conversation, we need to agree on some conventions, so we can't complain too much about the RELATIONSHIP. :)

Interview with Ken Jordan

Seb Paquet has posted a brief summary about an interview with Ken Jordan, one of the thinkers behind the Augmented Social Network (by way of Many 2 Many).

March 23, 2004

Rules and Rankings in Social Systems

AJ Kim has posted an interesting article about the gaming aspect of social software.

The rules of the game in services such as Google, eBay, and Orkut are enforced and sometimes altered in order to extract the desired information, or to encourage certain behaviors. The rules must also be structured to prevent cheating and abuse, for once there is a game to be won, there will be people who go very far to win it.

Traders in markets such as the NYSE participate in what is probably the largest-scale implementation of social software which uses game play to achieve, through rules governing behavior and information flow, the proper balance between cooperation and competition.

RELATIONSHIP: Two Worldviews

Clay Shirky has posted a very interesting clarification of his earlier comments about the RELATIONSHIP schema.

Human social calculations are in particular a kind of thing that cannot be made formal or explicit without changing them so fundamentally that the model no longer points to the things it is modeled on...

The flaw in RELATIONSHIP is not that you can?t characterize someone as a colleague and an employee, but rather that you can?t completely specify the fullness of any reasonably complex relationship, you can?t know in advance which of those characterizations you would use in what circumstances, and you can?t make even a subset of those things explicit without changing the thing you are trying to describe. Source

I completely agree with Clay's comment about the importance of circumstance. I have been working on the issue of circumstance in developing a framework for customized social networks. There needs to be a means to contextualize the relationship: friends, co-workers, co-students, acquaintences, strangers (one-way), family members, participants in a common activity, and so on. There may also be more than one context: family members who are also co-workers.

Providing a relationship contexts would place restrictions on the nature of the relationships that could occur between two personae, which would also provide a higher level of expressiveness for users. Further, I believe that working circumstance into a social networking standard would also simplify the development of a means to fetch and query the distributed data.

March 22, 2004

Technorati Redesign

David Sifry has posted a list of new features. Among them is BookTalk, borrowing some good ideas from All Consuming.

March 19, 2004

LOAF: using social software to minimize spam

Clay Shirky has posted a summary of LOAF, a perl app designed to create networks of trust among email correspondents. The email addresses are obscured by a Bloom Filter in order to prevent "Ex-Girlfriend" attacks :)

LOAF works by attaching a small file to each outgoing email you send, and monitoring your incoming email for LOAF attachments. These attachments are automatically stored away in one of two folders - a 'trusted' area for people you have corresponded with before, and a 'strangers' area for people who are unknown to you.

Each incoming mail is tested against the LOAF files of all the people in your trusted folder. If the sender has corresponded with one of your friends before, a header is added to the email to indicate the number of matches, and the addresses that matched. Source