OpenID aint evil, it's just a pain

Posted on by SignpostMarv

So a friend of mine sent me a link to one of Prok’s latest blog posts- “The Evils of OpenID“-, probably expecting me to agree that Prok is being a raving loony.

Unfortunately, there are some things in the post that I do agree with.

Prok’s points:

I won’t be responding to all of Prok’s points, just the first few:

1. OpenID is hard to use and misleading in its claims.

I have to agree here. And I’m not talking from the end-users’ perspective. I’m talking from a developer’s perspective.

My SLOpenID project- using OpenID to allow Residents to authoritatively log in as “themselves” has been through three different versions in it’s history. SLOpenID v1 was a heavily modified version of a now discontinued “standalone server”. SLOpenID v2 was a slightly tweaked distribution of WordPress MU. SLOpenID v3 totally abandoned the concept of attempting to be an OpenID provider (which is something that Linden Lab should really be doing themselves).

I abandoned the idea of trying to be the OpenID provider for Agni, mostly because there wasn’t enough demand for it, and partially because some changes in the WPMU platform “broke” the modifications I’d made that were necessary in integrating things in-world.

Operating software that accepts OpenID logins (a “relying party”) is almost as complex than operating an OpenID provider.

The problem lies in that you have to use some beefy math libraries (GMP or BCMath- at least on the PHP platform) in order to bring support for OpenID out of “dumb mode”- some 3rd party providers won’t log in if the relying party is stuck in “dumb mode”. In order to get these installed, you have to either contact your web host and ask them to make the libraries available- or make them available yourself.

For a total beginner to compiling software, the prospect of compiling PHP from scratch just so they can use this one feature will scare them off. For myself, I’ve had persistent problems getting the compile to run on this blog (though rarely is it a problem on SLOpenID/swslr), so even if you know how to get the libraries available, it doesn’t guarantee that you’ll be able to use OpenID.

2. OpenID is decentralized and therefore not the same everywhere.

This has caused me persistent problems on swslr. Not because of OpenID in general, but a specific, optional feature that’s touted as a means of “making it easier for end-users”- directed identity- the idea that you only have to put in “yahoo.com” anywhere you see an OpenID login.

Because of the existence of this single feature, I can’t currently rely on the OpenID data to allow people to quickly switch between their accounts, since it would allow anyone with a yahoo account to login and take control. I’m sure if I delved into the specs and libraries, I could figure out a way of supporting it, but given that the XMN stuff I’ve been working on allows people to “opt-in” with regards to linking their accounts (with the OpenID method, they could accidentally tell the server they own another account without meaning to), I don’t really have the inclination to go investigate too deeply.

Another issue I came across that Will Norris helped me out with was that the various libraries used didn’t treat URLs the same way. Some OpenID providers accepted the URLs, while others reported a vague error (to which I never received any useful help). The fix was relatively simple- just use rawurlencode() instead of urlencode(), and add in some mod_rewrite rules to enforce “+” for spaces instead of “%20″.

3. OpenID accepts other services’ log-ons, but would I give my email password to everybody?!
The system isn’t at all immune to abuse by geeks who might like to track you if they hate what you say. Christiano who raged at me for criticizing his IP captures and captures of email addresses as they came through his system screeched that the former were never used to track people to their actual homes and the latter weren’t saved but discarded. But both those pieces of info, when simply culled out and reviewed and matched against posters you don’t like, can lead you to out alts, for starters (remember the Phaylen scandal), and track people close enough to their homes to be a nuisance

I’ve always had a relatively paranoid approach with regards to the data I accept on my “public” projects- OnXiam for instance, doesn’t provide any means of “proving” that a given person owns a particular account, or is who they say they are etc. If someone wants to say they own two accounts via the XMN data, they have to log in as both avatars and say “hey, that other avatar is mine”. This would then allow the person to log in once, and “fast switch” between the different accounts- without having to log out or use multiple browsers.

Requiring explicit action on both accounts leaves out any worries that the user will accidentally expose their private alts to the world. If I were to use OpenID, the process would be more automated- just a simple SELECT/JOIN query. However, if the user associated the same OpenID with their “public” and their “private” accounts, they’ve inadvertently made it possible for me to see the private activities they get up to.

With great power comes great responsibility. I shouldn’t have to put the people who use my site into the position where they have to trust that I won’t do bad shit with their data.

My own issues with OpenID

The major feature that’s been touted about OpenID is that if you own your own domain name, you can run your own server. The average internet user wouldn’t be able to do this- previously because it meant setting up separate software to do the job. More recently, people can install a plugin on whatever blog software they happen to use- but they’d still have the issue of needing to make those math libraries available. This leaves you with the option to delegate your OpenID out to another provider, which actually relates to Prok’s 6th point- that OpenID isn’t as decentralised as it’s made out to be, since most people will gravitate towards a few well known, existing platforms (LiveJournal, Blogger, WordPress.com, even the bane of web design- MySpace), leaving only “the geeks” to utilise the actual decentralised provider features.

In the current sea of login systems, OpenID only theoretically makes things easier. You can enable millions of people to log into your software by using fewer (albeit more complex) software libraries/procedures. The only alternative would be to support the ability for people to log in with their Google account (via AuthSub), with their flickr account via flickr’s authAPI, and I’ve even noticed Facebook login support popping up on nearly every other site I stumble across. While that does mean you need to maintain another set of code for each additional service you want to enable logins for, these “non-standard” methods are typically easier to support- not requiring people to recompile PHP from scratch for example.

</end>

OpenID does still have it’s uses- I do still strongly believe that Linden Lab should start acting as an OpenID provider, as it would give 3rd party developers an existing set of tools to work with that would allow Residents to log into a wide range of SL-centric websites, without needing to go through the current paranoid methods of going in-world to prove you own the account you want to use (the alternative would be for Linden Lab to acquire each and every website that’s specifically targeted towards Agni Residents so that they don’t have to :-P)

OpenID is currently very much a double-edged sword, it has good and bad points, though its still very much a pain to learn to wield correctly.

Reducing support for Internet Explorer (versions below 8)

Posted on by SignpostMarv

UPDATE

Okay, so perhaps I was a little bit harsh on Trident- the CSS 2.1 portions of the new design for sw.slr work flawlessly in IE8, so with Dean Edwards’ Javascript libraries, the CSS3 portions should work sufficiently as well.

So I’ve decided to rephrase my position as “reducing” support for IE- it is still an inferior rendering engine, and its use is on the decline compared to alternatives such as Firefox, Opera and Safari. I’m going to attempt to get the new design working as best I can in IE (I’ve got the Multi-IE package installed, so I could possibly get it functional in IE 3 :-P), but I’m still going to continue focusing on standards-compliant browsers (which does now include IE8 by the looks of things).

The actual number of people using IE on sw.slr is only in 3-digit figures, whereas other browsers have 4 and 5 digit figures (the majority of IE users are using IE7, which means they’re more likely to use IE8 when it gets a stable release).

original post:

I’ve had it with Trident. It’s an obsolete rendering engine. I’ve been experimenting with a new design for my sw.slr project (its a miracle I can make anything look aesthetically pleasing :-P ), only to have it held up by trying to make it work in Internet Explorer.

There’s a tiny part of the CSS specification that has been in there since 1998. Coming up on 11 years, and Internet Explorer doesn’t support it. Its bloody ridiculous.

So, rather than employ a bunch of hacks in order to try and get it working almost the same, or changing the underlying code just to make it work in IE (when it already works fine in every other modern browser), I’ve decided to official drop support for Internet Explorer- at least until a version of it is released that supports the portions of the CSS standard that I’m using.

Auto-discovery of OpenSim Simulator Creations

Posted on by SignpostMarv

Update: After poking around the Microformats Wiki, I’ve altered my proposal slightly to use the enclosure value.

Timeless Prototype

With the recent increase in OpenSim usage, the natural progression will be for people to offer entire simulator creations for download.

What we now need is a searchable tag to easily find such downloadable simulators. I’m finding that a whole lot of the obvious acronyms are already taken up by other technologies.

You can read more on the original post, but the basic gist is that Timeless is proposing the use of a short blurb of link text, more commonly known as a “tag”. Well… there are a few problems with this- semantic ones, mainly.

  1. The presence of the matching tag does not guarantee that the link in question has anything to do with OpenSim.
  2. The use of the tag makes no distinction between documents that are OpenSim Region archive files, and post about OpenSim Region archives.
  3. The use of link text makes it a little difficult to have descriptive link text (also known as “click here” syndrome).

As I suggested to Timeless on his blog post, a more semantic method would be to use the rel attribute of the anchor tag, as opposed to the link text, using something such as opensim-region-archiveopensim-region enclosure.

Listing multiple region archives.

W3C: Basic HTML Data Types

Authors may use the following recognized link types, listed here with their conventional interpretations. In the DTD, %LinkTypes refers to a space-separated list of link types. White space characters are not permitted within link types.

These link types are case-insensitive, i.e., “Alternate” has the same meaning as “alternate”.

User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.

<a href=”http://example.org/foo.tgz” rel=”opensim-region enclosure nofollow” type=”application/x-gzip”>ZOMG DOWNLOAD MAH SIM NAO, LOL!!!!111!ONE</a>

Lolcats aside, the previous piece of html anchor code indicates that the document the link refers to is an OpenSim Region archive (it also instructs search engines not to go poking around the link, since fully fleshed-out simulators may be quite large, even when compressed). The humorous link text is also sufficiently human readable to English-reading web users, and wholly ignorable for machine reading/web crawler purposes- it doesn’t lock link text down to anything specific, so wouldn’t cause any problems with internationalisation/localisation.

So multiple anchor tags using the rel method can be embedded in a document, all with unique, descriptive strings for the link text- making it suitable for environments such as a MDC‘s catalogue. Those of you familiar with HTML at all will know that the rel attribute can be found on another HTML element- link.

Listing the download source for a region archive.

<link rel=”alternate opensim-region enclosure nofollow” type=”application/x-gzip” href=”http://example.org/foo.tgz” />

In some circumstances, individual pages will be given to an OpenSim Region archive- again, in the MDC catalogue scenario, but also perhaps on a dedicated review site for OpenSim Regions. Now, there’s nothing stopping such a site using anchor tags, but the link tag has extra geekery in its’ implementation- the use of the alternate rel value. This may or may not be borking things slightly, though a link tag with a rel value of “alternate stylesheet” is often used to allow a browser to switch between multiple skins- just having a rel value of “opensim-region-archive” alone would be enough to indicate that an OpenSim Region archive for the current document was available at the specified location.

Autodiscovery.

While there are many sites out there- such as del.icio.us and Technorati that are “tag friendly”, as I mentioned earlier, the presence of the tag alone does not guarantee that the document is in fact, an archive. This means that any web crawler or browser extension would likely have to download the linked resource *first* in order to ensure that the resource is actually an archive, and not just a blog post relating to the subject.
The rel attribute method on the other hand, allows for a web crawler, browser extension or even userscript to identify the presence of OpenSim Region archives available for download- consider the following piece of javascript:

1
var oar = document.evauluate('*//*[contains(@rel,"opensim-region enclosure")]',document,null, XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
2
if(oar && oar.snapshotLength >= 1){
3
alert("There are " + oar.snapshotLength + " OpenSim Regions available for download via this page.");
4
}

An advanced web-crawler would use similar XPath queries, queue the resource in question for download, then at some point in the future, automatically attempt to “restore” the archive to a (firewalled, no need to let external script comms work) local OpenSim grid, checking for any error output- thereby validating the contents of the OpenSim Region archive, and adding it to the index of Regions it has found.

HTTP/1.1 204 No Content: A Usability Problem

Posted on by SignpostMarv

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent’s active view.

Joyous differences between “SHOULD NOT” and “MUST NOT” aside, I’m finding that every browser’s implementation of 204 No Content creates a usability problem. Lets break the process down.

What the spec appears to state

  1. User agent (web browser) loads a document (web page).
  2. User interacts with the document via the user agent to load a new document (clicking a link on the web page).
  3. Server responds with 204 No Content
  4. User agent active view (the window/tab the first document was loaded in) does not change, allowing for actions to take place without causing a change to the user agent’s active document view (js alert boxes set on a timeout so many seconds after an anchor tag has been clicked ?).

How browser implementation of 204 No Content causes a usability problem.

  1. User agent (web browser) loads a document (web page). Example (Codie’s land listing on sw.slr)
  2. User interacts with the user agent- not the document in active view- to load a new document (clicking a bookmark or manually pasting in an URL). Example (Marv’s land listing on sw.slr)
  3. User agent active view does not change.

A Usability Problem

In the example, it appears to the average user that the second document is identical to the first, or if Codie were to sell all her land and sims, and the page was loaded by clicking a bookmark for the same active view as a previous version of the document, it would appear that Codie still owns regions.

The issue of 204 No Content as a usability problem doesn’t appear to lie with the HTTP spec. It explicitly states it SHOULD NOT change its document view from that which caused the request to be sent. However, it seems to be the case that a User Agent’s UI is not part of the document view, so the HTTP spec should not need to be updated in order to clarify this (given the diversity of applications, the protocol spec really shouldn’t make any attempt to reference any UI elements past, present or future possibilities).

It seems that browsers (perhaps all browsers) are at fault here, though on first glance it doesn’t seem to be that big a deal- you could say “Why not use 404 Not Found instead ?”. Yes, 404 Not Found could indeed get around the usability problem, as it allows a message body to be sent alongside the response- whereas 204 No Content MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.. However, 204 No Content is for when the server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation., and 404 is for when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. Semantically speaking (in my examples), with 204 No Content, the server is saying “Yes, I understood your request, but there’s nothing to see, though I might have some extra info relating to your request.”, but with 404 Not Found, the server is saying “Okay, nothing to see here”.

In short…

In short, if the HTTP spec does not mean to include a user agent’s UI in it’s “active view”, then the behaviour of all browsers needs to change so that the user is informed- either via an alert or error page- if a 204 No Content header is received in response to an attempt to load a document from anywhere other than the document in the “active view” (bookmarks, manual paste/type, browser extensions, external programs).

PHP5 LLSD Parser example

Posted on by SignpostMarv

I recently committed my LLSD parser to the public SVN server, after someone posted on the RegAPI mailing list asking for a LLSD parser that worked under PHP5.First the example script, then a step by step explanation of the output.

01
< ?php
02
header('Content-Type:text/plain'); # makes it easier to read the output
03
define('UHU_DEBUG_MODE',true); # enables extended error reporting
04
define('UHU_ERROR_AS_EXCEPTION',true); #
05
define('UHU_ROOT','s:/uhu public SVN/trunk/uhu-5'); # change to the directory
06
define('UHU_CONFIG_PATH','s:/uhu public SVN/trunk/uhu-5/uhu-config.php'); # change the path also
07
define('UHU_LIBS','s:/uhu public SVN/trunk/uhu-5/libs'); # ditto
08
require_once(UHU_ROOT . '/uhu.php'); # no need to change this
09
uhu::load_apps(); # an empty call needs to be made if the install root is not declared inside the config or if it needs to be overriden.
10
uhu_install_config::set('uhu::install::site_root','s:\localhost',true); # change to the path of the root directory for the install- not the web root, as some UHU components like to use a cache directory etc.
11
uhu::load_components('LLSD'); # loads the LLSD parser
12
$source = file_get_contents('./sample.llsd'); # go nab http://wiki.secondlife.com/wiki/LLSD#Example_XML_Output
13
$LLSD = new uhu_LLSD($source);
14
echo
15
	print_r($LLSD->struct()->struct(),true),"\n\n", # yeah, I should probably refactor this double geekery out.
16
	uhu_LLSD::save($LLSD->struct(),0),"\n\n",
17
	uhu_LLSD::save(NULL_KEY,0),"\n\n",
18
	uhu_LLSD::save(new uhu_LLSD_UUID(NULL_KEY),0),"\n\n",
19
	uhu_LLSD::save(new uhu_LLSD_integer_NaN,0)
20
;
21
?>

Continue reading →

pure CSS3 tree navigation

Posted on by SignpostMarv

Here’s a little something I put together earlier- tree/branch style navigation, powered entirely by CSS3 selectors, using valid XHTML 1.1 Strict code.

It seems to work in every browser, though IE7 doesn’t seem to support the coolest feature- the ability to have the page keep branches open while you navigate through branches higher up the tree. Not entirely sure what causes the borkage of course, but hey- IE’s Trident engine has never been one to play nice :-P