The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Thoughts on Designing a Vouched-By System for the Web

As an avid reader of several planets, as well as a user of the various whitelist and blacklist extensions for Firefox, I sometimes must make allowances for sites that I implicitly trust by virtue of their belonging to the planets. Here’s a potential alternative.

Motivation

As an avid reader of several planets, as well as a user of the various whitelist and blacklist extensions for Firefox, I sometimes must make allowances for sites that I implicitly trust by virtue of their belonging to the planets.

So, let’s first look at that trust.  I trust the organizations that administer the planets to only syndicate trustworthy blogs, and if a blog is found to be untrustworthy, I trust the planet will remove it (at least until whatever problem has been fixed).

In other words, I’m willing to give the syndicated blogs the benefit of the doubt for the whitelists in the extensions I use, but that adds up to at least 500 blogs, which is more than I would manually wish to add and maintain (as membership changes in planets).

These planets offer what may be a unique opportunity for trust, where something like a <meta name="vouched-by" content="http://planet.example.com/vouched-by/"/> element in blogs syndicated to planets.

What are the requirements for such a system?

First, it would be convenient if it could be foregone in favor of using the referrer data, but feed readers wouldn’t handle that, and visiting a blog from a sibling on the same planet would also not support that.

It seems a good candidate for using page metadata. The metadata requires specifying who (in the form of a URL) vouches for the page or site.  From there, an extension would ask the browser what metadata (or if that specific piece of metadata) exists, and if so, would query the claimed vouching site to verify.  Once verified, the appropriate access would be granted to the vouched site.

This would also allow for the user to report a dysfunctional member site to the vouching site, helping with maintenance of community/planet standards.

Drawbacks

The main drawback to such a system would be the overhead.  The participating sites and the planet would need to implement this.  So would the extensions that use whitelists.  The extensions would have to complicate their whitelists by allowing users to specify that particular sites would be given authority to vouch for other sites in this way.

Another drawback is that It may be a use-case that’s limited to this specific type of community.  This isn’t necessarily a killer, because none of the implementation requires true standards changes.  But it may be hard to justify adding complexity to the extensions that serve a broader community just for the few users that would like this support.

One alternative that avoids that is to add the new functionality to a separate, companion extension that handles voucher discovery and updates the whitelist data accordingly.  The main trouble here would be that not all whitelisting extensions support the concept of a temporary addition, which adds extra complexity to the bookkeeping responsibility for the supplementary extension.

Conclusion

This was more of a thought experiment than a serious proposal.  I believe that, while there may be limited use for this specific idea outside of community planets, there are many applications for vouching-based access authority in the technology world that aren’t currently used.

Access control will be a key consideration as new technologies create links between existing technologies for the added convenience and utility of all.