Our AIM Pages beta is now up: www.aimpages.com. Kevin just blogged about it. Check it out, have fun, let us know what you think!2006/05/10
AIM Pages Lives!
Our AIM Pages beta is now up: www.aimpages.com. Kevin just blogged about it. Check it out, have fun, let us know what you think!
2006/05/04
Memories of IIW2006
Some quick visuals from the Internet Identity Conference (it might help to quietly hum "Memories" to yourself). The pictures are mostly Phil Windley's.
Kaliya and others reviewing the Identity Timeline at the start of the workshop:
The lunch that AOL (partially) sponsored, from DeeDee's. Best meal of the workshop:
Dave Winer discussing OPML 2.0 and identity contact URLs with a bunch of very smart people. I am off to the side putting on a wise expression.
This slide is a cool vision statement of how identity URLs enable an entire open ecosystem:
Yan Cheng talks about the dimensions of identity. He convinces everybody that we're good guys. Maybe we should adopt a Googleian corporate motto: "Do good."
Circle time! I'm trying to learn the lyrics. Or maybe falling off my seat. Hard to be sure.
And last but not least, the AOL logo up on the wall:
Kaliya and others reviewing the Identity Timeline at the start of the workshop:
The lunch that AOL (partially) sponsored, from DeeDee's. Best meal of the workshop:
Dave Winer discussing OPML 2.0 and identity contact URLs with a bunch of very smart people. I am off to the side putting on a wise expression.
This slide is a cool vision statement of how identity URLs enable an entire open ecosystem:
Yan Cheng talks about the dimensions of identity. He convinces everybody that we're good guys. Maybe we should adopt a Googleian corporate motto: "Do good."
Circle time! I'm trying to learn the lyrics. Or maybe falling off my seat. Hard to be sure.
And last but not least, the AOL logo up on the wall:
2006/05/02
Internet Identity Workshop 2006
I'm at IIW2006 in Mountain View today (and tomorrow as well). I'm a highly interested observer who just wants stable identity and authentication system(s) to build useful things upon. From my point of view, the really useful thing that's happening at this conference is the interactions between lots of really smart people who are motivated to interoperate and provide really useful identity services for real people.
We had a good discussion about interoperability with AOL's Yan Cheng talking about different dimensions of functionality which are, at least to a first approximation, orthogonal. For example, exactly how authentication is handled is mostly orthogonal to the issues of how public identity and reputation is handled. I do think that we need to talk about these things in the context of real world examples. It's the minor little things that trip these simple scenarios up -- like, how do we auto-discover authentication capabilities from a user without adding even more login steps?
It seems like this space is going into a consolidation/cooperation phase, where everybody agrees to work together using a few very basic building blocks in an extensible framework.
We had a good discussion about interoperability with AOL's Yan Cheng talking about different dimensions of functionality which are, at least to a first approximation, orthogonal. For example, exactly how authentication is handled is mostly orthogonal to the issues of how public identity and reputation is handled. I do think that we need to talk about these things in the context of real world examples. It's the minor little things that trip these simple scenarios up -- like, how do we auto-discover authentication capabilities from a user without adding even more login steps?
It seems like this space is going into a consolidation/cooperation phase, where everybody agrees to work together using a few very basic building blocks in an extensible framework.
2006/04/26
Atom feed updates: Pagination
One of the hidden changes from last week's release is the support for Atom pagination. This will potentially let tools browse of the entries in a blog, copy them, archive them, search them, etc. Technically, this means we're supporting the link@rel="first", "last", "next", and "previous" relations. Get the current feed and follow the "previous" links until you run out of data; then you've got all of the entries in a blog, in standard Atom format. And, we're valid according to http://feedvalidator.org. Let me know if you see any problems.2006/04/14
Tags: Web Bumper Stickers
Our new entry tagging secret beta stealth feature might be a little difficult to see since it doesn't work on IE yet, though Joe did a great job with screen shots. (Joe: It's not much of a stealth feature if you tell everybody about it, is it?)
Tags are just labels that you can apply to your entries; since they're public, they're kind of like electronic bumper stickers. If you use Firefox or Mozilla, you can play with them on beta.journals.aol.com/<your screen name>. Otherwise, well, here's a little animation:
...and you can see the results below. I have no idea what "stealth" is going to link to, since right now it just does a general web-wide tag search. I think that's kind of fun, actually, but your mileage may vary. We're looking at various ideas, including having the links go to a blog-specific search page (but perhaps with links off to the general web search to see what other people have chosen the same bumper stickers). Also, we'll leverage the results to provide better categorization tools for your entries and blogs. It's pretty wide open at the moment. So if you have opinions, let us know.
Tags are just labels that you can apply to your entries; since they're public, they're kind of like electronic bumper stickers. If you use Firefox or Mozilla, you can play with them on beta.journals.aol.com/<your screen name>. Otherwise, well, here's a little animation:
...and you can see the results below. I have no idea what "stealth" is going to link to, since right now it just does a general web-wide tag search. I think that's kind of fun, actually, but your mileage may vary. We're looking at various ideas, including having the links go to a blog-specific search page (but perhaps with links off to the general web search to see what other people have chosen the same bumper stickers). Also, we'll leverage the results to provide better categorization tools for your entries and blogs. It's pretty wide open at the moment. So if you have opinions, let us know.
Whoops. Seriously.
This week, AOL accidentally started spam blocking email with "dearaol.com" URLs embedded in the text. And then we fixed it. Never ascribe to malice that which is adequately explained by... um... never mind. I know of no conspiracy and the people running our spam filters are good folks, it's just sometimes the software they wrangle gets a little obstreperous.
(techdirt)
(techdirt)
2006/04/11
Code, and other laws... (part 2)
In part 1I talked about the ideal world where feeds were all clearly licensed. Sonow I'll turn to the real world, and I'll be very US-centric becausethis article is quite long enough as it is. You might want to skip tothe happy fun summary at the bottom.
Millions of feeds aren't explicitly licensed. Some can't be becausetheir generators don't allow for it. For others, the owner doesn'tknow or care about licensing. For unlicensed feeds, it's notreasonable to make the default assumption "nothing more than fair use"because there are millions of feeds out there whose owners want theircontent syndicated as-is (headline feeds with links back to content,for example). On the other hand, if you assume anything more than fairuse, you also need to be prepared handle exceptions. So how to do bothof these in a way that minimizes overhead and letsaggregation happen without lawyers while respecting copyright?
My take is that a reasonable default assumption is to assume the Creative Commons Attribution license only if the feed owner hasn't specified otherwise. Thismeans that by default, we'd assume that copying of feed content isallowed as long as attribution is given through an appropriatehyperlink. Then, provide easy ways to let feed owners specify a different license whenever they explicitly declare one.
If a feed owner is happy with the default, they need to do nothing. My senseis that this covers 98% of unlicensed feeds. For the remainder, a feedowner could go to individual aggregators and tell them explicitly whatlicense they prefer. They can always choose a completely restrictivelicense that allows only fair use for the general public. Or, they canchoose a noncommercial license. My take is that something equivalentto the current Creative Commons license chooser is sufficient.
Of course, what we'd all really prefer is for feed owners to put thelicenses in their feeds directly. That way, our AOL proxies and cacheswould simply pass the information along to clients, which would makeappropriate decisions about what to do based on the particularlicense. If we're dealing with a small number of well understoodlicenses, this is the easy part.
How should the feed licenses work? There's a pretty good page with reasonable recommendations at Creative Commons on the subject. James Snell's Feed License Link Relation works well for Atom and is pretty flexible:
Finally there's the RSS 2.0 <copyright> element, which is justplain text. But, given that some tools might allow people to put textin this field but not embed the other types of licenses, I think it'sreasonable to look for a known license URL in the copyright text aswell:
A client might also want to inquire about a feed's declared licensewithout retrieving it. For this, we could provide a simple REST API:
Finally, we'd advertise a variety of ways for feed owners to contact usand declare their licenses. There does need to be some sort ofvalidation step to ensure they really own the feed. As part of thehopefully painless process we'd ask them to pick from one of theexisting Creative Commons licenses. If these aren't sufficient we canadd other licenses but it's easier all around if people can agree on asmall set.
How about a real world example? Brian Alvey of Weblogs Inc. recently announced support for excerpt feeds, for example Engadget full vs. Engadget headlines. The full Engadget feed has the copyright statement:
So far, so good. Having multiple versions does raise the question of how automated processors are supposed to find these feeds. I think that's going to have to be a followup post.
That's about it. In summary:
Tags: Feed Copyright, Creative Commons, RSS, Atom, syndication
Millions of feeds aren't explicitly licensed. Some can't be becausetheir generators don't allow for it. For others, the owner doesn'tknow or care about licensing. For unlicensed feeds, it's notreasonable to make the default assumption "nothing more than fair use"because there are millions of feeds out there whose owners want theircontent syndicated as-is (headline feeds with links back to content,for example). On the other hand, if you assume anything more than fairuse, you also need to be prepared handle exceptions. So how to do bothof these in a way that minimizes overhead and letsaggregation happen without lawyers while respecting copyright?
My take is that a reasonable default assumption is to assume the Creative Commons Attribution license only if the feed owner hasn't specified otherwise. Thismeans that by default, we'd assume that copying of feed content isallowed as long as attribution is given through an appropriatehyperlink. Then, provide easy ways to let feed owners specify a different license whenever they explicitly declare one.
If a feed owner is happy with the default, they need to do nothing. My senseis that this covers 98% of unlicensed feeds. For the remainder, a feedowner could go to individual aggregators and tell them explicitly whatlicense they prefer. They can always choose a completely restrictivelicense that allows only fair use for the general public. Or, they canchoose a noncommercial license. My take is that something equivalentto the current Creative Commons license chooser is sufficient.
Of course, what we'd all really prefer is for feed owners to put thelicenses in their feeds directly. That way, our AOL proxies and cacheswould simply pass the information along to clients, which would makeappropriate decisions about what to do based on the particularlicense. If we're dealing with a small number of well understoodlicenses, this is the easy part.
How should the feed licenses work? There's a pretty good page with reasonable recommendations at Creative Commons on the subject. James Snell's Feed License Link Relation works well for Atom and is pretty flexible:
<link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/>.The Creative Commons RSS Module works for RSS 2.0:
<creativeCommons:license>http://www.creativecommons.org/licenses/by-nc/2.5</creativeCommons:license>.Both of these work with CC and other licenses and have been deployed in real implementations There's an RDF version for RSS 1.0 as well (cc:license).
Finally there's the RSS 2.0 <copyright> element, which is justplain text. But, given that some tools might allow people to put textin this field but not embed the other types of licenses, I think it'sreasonable to look for a known license URL in the copyright text aswell:
<copyright>Thecontents of this feed are licensed to the public under http://creativecommons.org/licenses/by-nc-sa/1.0/</copyright>If a processorcan't find any of the above licenses, I'm proposing that AOL feedconsumers fall back to a license based on an explicit list that AOLmaintains by feed owner request. This would be part of our feedinfrastructure. I see this working two ways. First, we would addmetadata to feeds which are requested via our feed proxies. For Atomand RSS 2.0, the two output formats we support, this would be anamespaced extension, aol:declared-license:
<aol:declared-license>It would contain a Feed License Link Relationindicating which license the owner specified to AOL. It couldpotentially contain multiple license links. It could contain othernamespaced elements in the future as well, but feed consumers canignore ones they don't understand.
<link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/>
</aol:declared-license>
A client might also want to inquire about a feed's declared licensewithout retrieving it. For this, we could provide a simple REST API:
GET http://example.aol.com/declared-license/example.org/feed/atom.xmlwhich returns a simple XML document:
<?xml version="1.0" encoding="utf-8" ?>Note that non-AOLclients could potentially make use of this; you'd just have to believethat AOL is maintaining a good declared license list (the licensesthemselves are the ones the feed owners want to provide to the generalpublic, not to AOL specifically). We could even potentially sharethese lists between feed aggregators. An embedded (original) licensewould always override any declared license; this would let feed ownerseasily start embedding their own licenses in the future. (Should weeliminate any declared license as soon as the source feed startslicensing itself? I think so, but our legal team would need to weighin on that.)
<declared-license xmlns="http://example.aol.com/2006/aolfeeds">
<link rel="license" href="http://creativecommons.org/licenses/by/2.5/"/>
</declared-license>
Finally, we'd advertise a variety of ways for feed owners to contact usand declare their licenses. There does need to be some sort ofvalidation step to ensure they really own the feed. As part of thehopefully painless process we'd ask them to pick from one of theexisting Creative Commons licenses. If these aren't sufficient we canadd other licenses but it's easier all around if people can agree on asmall set.
How about a real world example? Brian Alvey of Weblogs Inc. recently announced support for excerpt feeds, for example Engadget full vs. Engadget headlines. The full Engadget feed has the copyright statement:
<copyright>Copyright2006 Weblogs, Inc. The contents of this feed are available fornon-commercial use only.</copyright>Translating into license-speak, we'd get anAttribution-NonCommercial-NoDerivs license for the full feed, meaningno commercial exploitation, links back are required, and editing of the material is not allowed beyond fair use:
<creativeCommons:license>http://creativecommons.org/licenses/by-nc-nd/2.5/</creativeCommons:license>The excerpt Engadget feed has the copyright statement:
<copyright>Copyright2006 Blogsmith, LLC. The contents of this headlines and excerpts feedare available for limited commercial distribution. You may repost thisfeed to your site provided you link back to the original story, do notedit the material, and do not remove this copyrightnotice.</copyright>Translating intolicense-speak, we'd get Attribution-NoDerivs for the excerpt feed,meaning that commercial use is OK but links back are required and thematerial may not be edited:
<creativeCommons:license>http://creativecommons.org/licenses/by-nd/2.5/</creativeCommons:license>(I'massuming here that the restriction on editing applies to the individualarticles, not the feed document as a whole, since feed documents arenot intended to be kept intact in any case. This minor ambiguity goesaway with Atom's Feed License Link Relation.)
So far, so good. Having multiple versions does raise the question of how automated processors are supposed to find these feeds. I think that's going to have to be a followup post.
That's about it. In summary:
- Support and promote feed standards for embedded licenses.
- Treat unlicensed feeds as if under the Creative Commons Attribution license (see update)
- ...unlessthe owner requests something different, in which case honor theirrequest quickly for all your current and future products.
Tags: Feed Copyright, Creative Commons, RSS, Atom, syndication
Subscribe to:
Posts (Atom)
Suspended by the Baby Boss at Twitter
Well! I'm now suspended from Twitter for stating that Elon's jet was in London recently. (It was flying in the air to Qatar at the...
-
Update 6/2/2023: I was right . These are my observations for our local conditions (Santa Clara County, July 10-12, 2020), which to summarize... -
Last night Rachel Maddow talked about an apparently fake NSA document "leaked" to her organization. There's a lot of info t... -
Well! I'm now suspended from Twitter for stating that Elon's jet was in London recently. (It was flying in the air to Qatar at the...
