For our first anniversary, and our honeymoon, Anna & I went to Costa Rica. We just got back on Wednesday. It was an incredible time. Costa Rica is a beautiful country, and everyone we met was very friendly and outgoing. I think my favorite thing was all of the cute or amazing animals. Also, lots of the restaurants were hardly even "inside". They were mostly open to the air, although covered, so sometimes frogs or kittens would be hanging out with you while you were eating.

I had heard a lot of good things about Costa Rica, and I can wholeheartedly echo them all! Here are some photos below, but there are lots more, so check out the gallery. Don't worry, we've already taken out repetitive pictures and cropped them :)

We went during the rainy season, but it actually didn't rain on us except when it didn't really matter. When we were in the hot springs, it started pouring, but it was really warm rain, and it just made the experience of the hot waterfalls all the more intense. On the colder side of things, we also went whitewater rafting, and that was the only other time it rained while we were actually doing anything, so again it didn't really matter. We did get kinda lucky that it didn't rain while we were on the beach and stuff.

Some random surprising facts about Costa Rica: Intel's microprocessor facility in Costa Rica is responsible for 20% of Costa Rican exports and 4.9% of the country's GDP. They actually make a lot of money from high tech and from tourism.

After fighting and winning a civil war, a rebel force abolished the army elected an assembly, wrote a constitution, gave Blacks and women the right to vote, and then the rebel junta stepped out of power and Costa Rica became a democracy. Wow.

On our first few days, we were in La Fortuna exploring the rain forest, relaxing by the pool, watching the live volcano erupt, and riding some ziplines. We also visited some hot springs which were awesomely beautiful and relaxing.

Our first day in San Jose, we went to a butterfly garden. The tour guide seemed very into the butterflies. When she would pick one up, she would gently blow on it, and when Anna asked, she said it was just to say "hi" and to relax the butterfly.

We flew out of San Jose to La Fortuna on this little airplane. No security, no bar codes on the boarding passes. No flight attendants.

Here's me with some Iguanas. This tree was covered with them. Costa Ricans call them "Tree Chickens" because they taste like chicken. By the way they love telling you this, I must have heard that joke like 5 times. They don't eat them anymore because they're protected, and the population is therefore increasing again.

In La Fortuna, we went on a boat on the Rio Frio and saw lots of animals, including several howler monkeys, this cayman alligator, as well as lizards who could walk on water, lots of birds, etc. Check out all our pictures.

The howler monkeys make a really cool, really loud noise that sounds like a huge gorilla or something, but they're really pretty small. Wikipedia says they are the loudest land mammal.

La Fortuna has a big, active volcano, and we got to watch it erupting a bit, especially while we were doing these zipline rides. By the way, the ziplines were fun, but I wouldn't recommend them as being particularly interesting. They were billed as a kind of canopy tour, but really they were more like an amusement park ride.

A pair of Macaw parrots lived in our hotel and this one beat me at foosball. Apparently they mate for life, according to wikipedia. These two were never apart whenever we saw them. Also, one of our cab drivers lived nearby and said he is in a battle with those parrots and they hate him. They did have a LOT of attitude.

After La Fortuna, we flew back to San Jose, and then drove to Manuel Antonio where we toured the national park. This was the most amazing animal viewing we did. Our guide had this tripod-mounted monocular or telescope or something, and he would spot tiny or distant animals and set up the telescope to let us view them.

Most of the time, we would try to spot whatever it was, a tiny frog or group of bats or something with the naked eye, and we couldn't see it because these animals all have great camouflage. Several of these pictures were taken through that lens, which is why they have such high resolution.

This is a three-toed sloth, which are hard to spot and very slow moving. Anna actually spotted one on her own at our hotel one day. Mostly, they look like a ball of fur, but with the telescope, we could actually get a look at its face. I still can't actually figure out what a sloth looks like altogether because all of the photos of them just looked photoshopped to me. Like, where is that arm coming from?!

This frog was tiny and hard to see :)

Lounging Lizard:

One of my favorite animals was the capuchin monkey. They were so cute and curious, and they were kleptomaniacs, but they didn't steal anything from me. A few days later, we got to watch an entire troupe move through the forest while we were kayaking, and they came over to check us out, so we got to see them really close. It was really fun to watch them jump around between the trees and run across the ground. We also saw a little baby all alone following the big group, but a minute later, mom came over and baby climbed up on mom and they zoomed off. You need to see the high resolution version of this picture too :)

Their faces look so old and wise and mysterious, but then they act like little kids. Some stupid tourist was feeding some of them (which is really bad for them) and she was teasing them with a banana. When he didn't get the treat, one of the monkeys ran over to someone's backpack and reached into the pocket and tried to grab something, but someone chased him away.

This was while we were on the beach, and there are all kinds of things trying to get you and your stuff. We saw that monkey try to grab something, we saw a raccoon trying to get into a bag, not to mention the thieves that we didn't see but were warned about approximately 100 times. Also, there was a poisonous tree on the beach with a sign saying not to sit under it. In Spanish, this tree is called manzanilla de la muerte, or "little apple of death". The Iguanas can actually eat the fruits, though.

Here's a beach photo. We swam in the warm waters a lot. This was on the pacific side, by the way, not the Caribbean.

Our hotel in Manuel Antonio was so beautiful. Definitely the nicest place we've ever stayed in. The room even had an etched window. Most everywhere we went, except San Jose, looked this lush. Costa Rica is kinda like Portland in that it gives the impression that if you stopped fighting off the plants, they would just take over.

After Manuel Antonio, we drove back to San Jose in a rented car. This was about 200km, and the roads were insane. They were really winding, and everyone wanted to pass everyone all the time. Also there were features like dirt roads, and the roads didn't have names mostly.

Then there were these insane "bridges" that weren't originally meant for cars but for trains, where you'd have to wait for 10 minutes to cross because there were folks crossing in the other direction. To the left, you can see that they're building a new bridge, which is like half done, but it looked better already than the one I was using!

There were lots of school kids out in uniform and lots of people on bikes in all kinds of weather. These two look like they're having a great time.

So that's it! That's just a sampling of all of our pictures, so if you want to see more monkeys, flowers, frogs, and other fun stuff, go check out the gallery.

Lots of love,

isaac & anna

In looking at how my blog does OpenID login and comments, I was really wishing that it did what I would expect: When someone wants to post a comment, all I care about is their identity (which is mostly just to show that they're not impersonating someone else), and whether or not they are a spammer.

The Good

OpenID and Captcha is all you need to comment

So ideally, my blog could just ask for a commenter's OpenID and have them answer a captcha. Unfortunately, Drupal's current OpenID implementation has the same problem as others I've seen, which is the obsession with people having an "account".

A site's OpenID implementation should not require an account, password, confirmation of email, and an OpenID. I was excited when I realized that Blogger has the right interface for commenting; an OpenID login, and a captcha (don't tell any spammers what it says!):

The Bad

I need your Google password to continue
I was all ready to give Blogger all kinds of props when I noticed that their login screen asks me for my Google password. Now, Blogger is actually owned by Google, but not everyone knows that, and so this looks like a phishing attack.

You should not give out your Google password to a third party web site. It's just a bad idea. One simple example why: Email can often be used to reset your password to another web site that has your private information in it. It's bad enough that sites like Twitter ask for your Google password when creating an account. Google shouldn't make people think it's OK to give third party sites your password by using a login screen like this. That's bad.

The Ugly

I have descended into a no-man's land on LiveJournal

I saw that LiveJournal supports OpenID and I thought I'd try it out. Their comment system looks fine, but then the integration with everything else is just a mess. I'm logged in, but I don't have an "account". The first thing I see when I log in is a link that says "Update your Journal" but when I click it, I get an error message saying that I don't have one. I can configure my account, and it says that it has emailed me instructions (I never got them) and gave me a helpfully random URL as my blog, which, when I click it, is just an error. LiveJournal makes OpenID look broken and hard to use :(

I admit, LJ gave me fair warning, "Our OpenID consumer support is very new. That is, external users logging in with their identity here will find some rough edges while we work on smoothing it all out."

This has been the state of affairs for months, though, and I'm surprised that they can't at least give me a link to somehow create the right kind of account.

If you know of any other really elegant uses of OpenID or OpenID design patterns, please email me, and I'll post whatever I collect later. You can also leave a comment on Reddit. You are welcome to leave a comment below, but you'll have to create an account and answer a captcha. Sorry about that ;)

I've just released feed-cli: a Really Simple way to generate RSS feeds from the command line. This program is implemented in Haskell :)

feed-cli generates RSS 2.0 feeds based on command line arguments. Use it to create and update feeds from shell scripts, build scripts, cron jobs, CGIs, or other programs instead of using a library.

Some Examples

./feed-cli new-feed -tTitleOfFeed -d"Feed Description" \
  -o/tmp/feed.xml  -lhttp://www.syntaxpolice.org

./feed-cli new-item -t"entry of the day" -d"This is a description of this feed item." \
   -u/tmp/feed.xml  -lhttp://www.syntaxpolice.org

ls -l | ./feed-cli new-item --pre --pipe-mode -t"directory contents" \
  -u/tmp/feed.xml  -lhttp://www.syntaxpolice.org

Sigbjorn Finne, Isaac Potoczny-Jones, Eric Mertens

Galois, Inc, Beaverton, Oregon

January 2008

The following is a little whitepaper written primarily by Sigbjorn with help from me and Eric from Galois. We attempt to give an easily understood overview of the current state-of-the art in secure mashups, and would be very interested in your feedback, so email me or join in the Reddit discussion if you think there's anything we're missing here. Relatedly, we recently released some Haskell web libraries.

Abstract

Having the ability to easily combine together information from a number of disparate input sources into a greater whole is a touted benefit of 'Web2.0' mashup applications. They have great promise as flexible, and user-tailored ways to both disseminate and collaborate on information on the web, but with today's web technology, face a number of security risks when being asked to also aggregate restricted information sources. This paper introduces the domain and what these risks are, along with suggested mashup application architectures that are more secure.

Introduction

Sharing and combining information from a number of disparate web resources is a common task for today's web applications. We introduce and define the key concepts in this area, focusing on how we can take advantage of the opportunities for collaboration and sharing of information that this affords without compromising or giving up on security.

Terminology

Mashups: (From Wikipedia) In technology, a mashup is a web application that combines data from more than one source into a single integrated tool; an example is the use of cartographic data from Google Maps to add location information to real-estate data from Craigslist, thereby creating a new and distinct web service that was not originally provided by either source.

OAuth: An emerging authentication & authorization protocol for letting a user grant access rights to his/her Protected Resources held by a Service Provider to a third party, a web application (the Consumer.) This is done without the User having to hand over authentication credentials to the Consumer.

Public Resource: A piece of public data that can be offered by a Service Provider to a mashup. These are resources that are available to everyone on a particular network.

Protected Resource: A piece of "private" data that is not publicly available. This might take the form of information, text, video, or articles. It could be personal information specific to a user, or data available to a set of users based on membership in a group.

Public Mashups: A mashup containing only public resources. No further authentication needs to be done. There are no "protected resources".

Private Mashups: A mashup containing any protected resource.

Personal Mashups: A mashup containing a protected resource that relates to a specific user, where a user should have control over sharing of that data.

Service Providers: The web site or web service controlling the data being used as input to a mashup application. Some or all of the hosted data may be Protected Resources.

Consumers: The hybrid application itself; the mashup application. The party that is aggregating the service provider resources on behalf a User or Community.

User: The end-user(s) of a mashup application. In the case of private or personal mashups, some of the resources being mashed up may be hosted by Service Providers on the User's behalf. We include a community/group of users under the User label, as well.

Web applications: common vulnerabilities

When venturing into the terrain of web applications, all issues surrounding the security of such applications need to be carefully considered and explicitly designed for. Mashup applications are definitely no exception, quite the opposite. Confidentiality, integrity, availability and authenticity all need to be addressed.

Many kinds of attacks against both web application services and the user's browser are possible and known, cataloged by MITRE in their CVE database amongst others. Some classes of vulnerabilities are more common than others, the current 'top 5' (in 2007) kinds are:^iv

• Cross-site scripting (XSS). User provided content is passed along to other clients' browser for malicious rendering/execution. The client-side is impacted.

• Injection flaws. User-supplied input is sent to an interpreter on the server, causing it to be included in commands or queries. A server-side issue.

• Malicious File Execution. User-supplied input is treated as valid input file content on the server.

• Insecure Direct Object Reference. References to sensitive information is directly included in content served out to a web browser. Attacker may harvest that info directly or use it to craft separate attacks. Both a server- and client-side issue.

• Cross-Site Request Forgery (CSRF). Attack that forces a logged-on client to send pre-authenticated requests to a vulnerable web application. Both a server- and client-side issue.

Of these, XSS, Direct Object Reference and CSRF are of particular concern in a "Web 2.0" setting where larger parts of an application are executing on the user's web browser. What are the implications for mashups with respect to these vulnerabilities?

Mashups: Web 2.0 and Cross-Domain Security

It is common for current mashup applications to take advantage of JavaScript to provide a rich and dynamic user interface; implementing what is termed an AJAX application. Combined with this, it is increasingly popular to use the JavaScript Object Notation(JSON) format for transporting data from other web applications, including the information sources being mashed up. JSON is simply a serialized representation of JavaScript values, including arrays and dictionaries.

One immediate hurdle faced by an AJAX-based mashup application is one of the current foundations for web browser scripting security, the so-called Same Origin Policy. It disallows JavaScript hosted in an HTML page from accessing web resources other than ones coming from the same domain as the server that offered up the hosting HTML page. A JavaScript-based mashup would naturally want to consult resources from a number of disparate sources.^ix

A couple of workarounds exist to this policy, with one in particular being prevalent and compatible with JSON usage: introduce external JavaScript code (as JSON values) via the addition of extra HTML "<script>" elements to the code that cause JSON values to be fetched and passed on to a client-defined callback function^x -- loading external scripts are excepted from the Same-Origin Policy. While flexible and achieving a useful goal, this use of JSON leaves applications even more susceptible to the common vulnerabilities in the previous section.^xi

An example of this architecture is shown in Illustration 1. In step 1, the consumer would generate JavaScript which, when executed, would instruct the user's browser to visit each "service provider." In step 2, the browser requests content from each service provider, supplying the user's session cookies. Each service provider would be enabled with a JSON (or similar) API which is the component that implements the callback. (From now on, we'll refer to this as the JSONP.)

The aggregation would occur entirely on the client side (in the browser), with JSONP requesting the page contents with the user's session cookie, no central component would need to be trusted to handle the data. Unfortunately, we believe that configuring the Service Providers to allow such mashup access leads to a CSRF problem. The concern is that this approach allows the Service Providers to return scripts containing private resources (via JSONP). That is passed to a callback, which circumvents the browser's cross-domain scripting restrictions.

If the Consumer is able to instruct the user to load these scripts, then any site on the network that the user visits would be able to do the same. A malicious or poorly written page could easily instruct the user to request restricted content from the JSONP and send it to any server it might choose.

This is the case because the JavaScript callback allows a 3^rd party site to proxy the user's credentials to connect to an otherwise secure service provider (thus forging the request). In this way, the 3^rd party site can gain access to any data that the user has access to, just by the user loading that site, and without the user's knowledge. There is a CERT advisory about this and similar vulnerabilities^xiii.

There are ways to mitigate and protect against CSRF attacks by making the Service Provider much less trusting of requests coming from the User – that way weeding out the genuine mashup requests from CSRF attacks that piggybacks on a current browser session. However, the fact that a mashup application is aggregating content widens the attack surface a bit further, allowing cross-domain attacks that don't require issuing requests back to the server:

• Cross-source XSS/CSRF. If an attacker knows that it is being mashed up with other sources, it could gain access to these mashup input resources. These resources could be private to the user, so if they're mashed up along with public resources that aren't resistant to XSS attacks, the attacker may gain access to the private resource by way of the mashup application. The data may not be private per se either, but only accessible on an intranet.

• Session snooping via CSRF. One end-user recommended strategy for protecting yourself against CSRF attacks is not to remain logged in to web sites holding personal data (e.g., your online banking accounts, web mail) for longer than necessary, preventing those sessions from being hijacked by CSRF vulnerabilities in other web applications. Mashup applications will tend to leave sessions open to all web resources being combined, making CSRF attacks against any of those easier.

The above two aren't relevant if we consider Public Mashups of resources all on the same network, but CSRF attacks against the mashup application can still be used to determine what kind of resources a user is mashing up and exploit that extra knowledge somehow.

Still, this JavaScript + JSON approach to implementing mashups on a client is popular; it's a relatively simple, flexible and convenient way of creating public mashups. It's possible to accommodate personal mashups this way also, but requires tackling the issue of how the User authenticates and authorizes access to the Protected Resources being included in the mashup. A couple of approaches here are:

• Trust the mashup application with your login credentials (e.g., view your Gmail in the mashup that is Facebook by trusting Facebook with your Gmail password.)

• Have the user manually log in and establish a session for the mashup to use.

• Use an open-standard, distributed authentication protocol like OAuth (or vendor-specific solutions, like Yahoo's OpenAuth, Google's AuthSub etc.), which lets the user remain in control of his/her Protected Resources, but provides a way of granting access to them to a mashup application without sharing or compromising his/her login credentials.

All of these can be implemented with JavaScript+JSON, but many mashups either insist on being trusted with login credentials and implement the first option, or work under the umbrella of a bigger vendor's authentication solution and only support the mashing up of Protected Resources from that vendor next to public resources. A good example of this is third-party application developers registering with Google and thereby gaining mashup access to Google-hosted resources/services for a particular user through the use of the Google AuthSub protocol.

Irrespective of approach, providing a secure and trusted non-public mashup application requires careful design and even more careful JavaScript programming to achieve using current best practices. So, with the adoption and use of something like OAuth, it is not impossible to come up with a secure mashup application that's mainly running on a user's browser. Notice though that as this is done via browser JavaScript, all the logic and steps used to secure the application is available for any attacker to see and, potentially, circumvent.

Analysis: Although it may appear that we are trusting fewer components with our protected resource (since the consumer never touches the data), it's unclear if this is actually enforceable. The authorized consumer would be trusted not to use its privilege to look at private resources itself, but would have less liability to have to carefully handle secret data.

Reconsidering Mashups: Centralized Aggregation

So, if implementing mashup applications securely via client-side JavaScript+JSON is proving to be harder than first appearances, stressing as it does the language and browser to the point of breaking, what are the alternatives, if any? A more centralized aggregation approach to mashing up suggests itself. The mashup being a separate web application and centralized server, which performs the main aggregation/mashing up function.

As it is a separate web application, it is freed from running in a web browser, and can hence request resources from any network-accessible web service without having to use or rely on JSON combined with insertion of '<script>' elements (aka JSONP.) For private mashups, it also fits in relatively well with a protocol like OAuth, which lets the User grant access to the centralized mashup application (the Consumer) to his/her Protected Resources that are hosted by one or more Service Providers. The User remains in full control of what is shared and the credentials required to authenticate with the Service Providers.

This approach is shown in Illustration 2. In this approach, the user authorizes the central mashup server (the Consumer) to gather protected resources on its behalf. In step 1, the user visits the mashup, and the mashup contacts the content providers to gather the resources. In step 2, the central server performs the aggregation and presents the aggregated content to the user.

When combined with the use of OAuth, the first time the user visits the mashup application, the user is redirected to the service providers to grant access to the mashup so that it can include some of his/her protected resources in the aggregated, mashed-up output. (A timeout can be set so that the grant can expire in an hour, a month, or a year, and the Consumer will no longer have access to that site.)

Analysis: A downside of this approach is that the user must now trust the Consumer (the centralized mashup component) and the Service Providers with their Protected Resources, since the Consumer now also has access to them. Rather than building defense-in-depth, we are simply adding another link to the chain of security; another point of failure. We believe that this is actually true of the JavaScript approach as well, although it may not be readily apparent.

Interestingly, this centralized architecture can be seen as a more general version of the other solution that AJAX applications use to get around the Same Origin Policy; having the mashup application proxy all outgoing requests back to the server.ix In addition to performing the communication, the centralized component also performs the aggregation before communicating the result to the client. Notice that a centralized server does not preclude the use of AJAX-style user interfaces on the client.

Related and ongoing work

Addressing the need for more secure ways of writing mashup applications, is an ongoing concern in the web browser and applications community. A number of different efforts are underway to come up with a more secure platform for writing AJAX mashup applications, in particular:

• WAFWG's cross-site access control proposal.

• JSONRequest object for enabling more secure, cross-domain JSON data transfers.

• 'Sandboxing' the components of a mashup, allowing careful control over their ability to interact with other components.^xvi

• And others.

Common to all of them is the need to either extend the browsers (or add to their current installations) or have them become widely adopted by AJAX applications and the frameworks they're often built on top of.

Conclusions

This paper has presented a couple of different architectures for implementing Web2.0 mashup applications that aggregate content from a number of disparate sources, with some of these sources possibly containing user sensitive content. Doing this securely, by provably fulfilling a security policy perhaps, without compromising the user's data is an absolute requirement. Possible security risks and the extended attack surface of mashup applications were introduced,highlighting in particular the added vulnerabilities faced by flexible, client-side AJAX-style mashup applications.^xvii

As of today (January 2008), there is no comprehensive and solid solution on offer for AJAX mashup developers, causing us to strongly suggest that another, less client-demanding, mashup application architecture based on a centralized mashup server should be given serious consideration instead. Especially if you want to make it a tractable problem to trust and possibly even prove that your mashup application's aggregated output cannot introduce covert channels that maliciously leak information about the content being mashed-up.

Complementary to the efforts of securing AJAX applications, the OAuth protocol was introduced and shown how it can effectively be used in a mashup application context to solve the issue of allowing mashup access to a user's data without handing over the credentials required to do so. That's an important piece, and will be directly applicable with either architecture.

About Galois

Galois researches, designs and develops high assurance technologies for security-critical systems, networks and applications. We use Haskell as a primary development tool for producing robust components for a diverse range of clients.

Web-based technologies are increasingly important in this area, and we believe Haskell has a key role to play in the production of reliable, secure web software. The culture of correctness Haskell encourages is ideally suited to web programming, where issues of security, authentication, privacy and protection of resources abound. In particular, Haskell's type system makes possible strong static guarantees about access to resources, critical to building reliable web applications. We hope that the release of this suite of libraries to the community will push further the adoption of Haskell in the domain of web programming.

End Notes

Lately I've been thinking about the concept of "Play".

When I first learned the game of Go, I was just messing around and it was really fun. I was playing. Then I got a little bit better at it and started caring if I was winning. It stopped being quite so fun. It started being Serious.

Sometimes we can do the same thing at home as we do for our work and it's fun and playful. I think a lot of open source developers have that experience.

Play is when it's almost like the result doesn't matter. It doesn't matter if you win or lose or if your program gets used by a bunch of people, or if you sell the product.

Play is when it's almost like standards don't matter. You'll be as organized about things as you want to be. You'll use good coding conventions if you feel like it. You'll write detailed documentation if it doesn't take too much time. You'll play Go with someone who is not at your level just for kicks, even though it doesn't help you to get better.

Play is going for a walk in the woods not to get exercise or to get enlightenment, but just because you enjoy it.

In fact, despite what I said above, you can care about the end result if that's part of your joy, and you can care about the standards if that's part of your joy. When I was talking to my friend Dylan about this, he said that he races better when he's just playing. That's also why some people love their jobs.

You know you are Playing when you find Joy in the action itself and those other pieces are incidental. Go Play :)

The rise in the use of cell phone cameras and cheap, high-quality video gear has been a really interesting development for journalism. Citizens routinely video or photo monitor the behavior of police at protests, for instance, and upload them to the Internet.

One problem with this is that the camera or digital media can be confiscated as the the police in Portland allegedly did (and this is apparently common, as noted here, here, here, here, and here).

But with the combination of cheap, high quality cameras with cheap, portable WiFi devices, this social problem can be overcome with a technical solution. It should be pretty easy to build a camera device which uploads video via wifi directly to a site like youtube or a server outside of repressive countries.

A simple solution that could work almost right now without any hardware modification would be to write some shell scripts for the Nokia N810 or similar. These devices have everything you need: A built-in video camera, a wifi card, and it's based on Linux, so you can program for it, and there are already ssh clients available.

Here are a few problems with that: Internet is not available everywhere in most cities (but cell phone connections are), and the Nokia doesn't have a very high quality camera.

A more complex but flexible solution would be to add a bluetooth card to an existing high quality camera (here's a video camera and a still camera that already have bluetooth). The Bluetooth card could transmit photos to an Internet-enabled cell phone in your pocket like the Palm Treo, which could upload it to youtube or what-have-you. Similarly, a video-enabled cell phone like that Treo could upload the video directly to youtube.

Remember, you don't have to stream the video at viewable speed, just fast enough so that if it gets confiscated you will have already uploaded it.

One problem with that approach is that Bluetooth is kinda slow. It also requires three devices (camera, phone, and Internet server), and the camera and phone would require specific programming which isn't necessarily that easy to do since they're often based on proprietary platforms.

Anyway, this is bound to happen eventually, and maybe has already? Does anyone sell a digital video camera with an "upload to youtube" feature built-in?

My commute starts in the relaxed, low key South East of Portland where I ride through neighborhood streets that have more cyclists than cars. On my way home along this road, the view of blinking bike tail lights is always an inspiration.

I meet the most cyclists while crossing the river, though. There are two lanes here on the bridge and the faster cyclists take the left lane. It gets tight further on, and not everyone gives the pedestrians the space they need.

Once I hit downtown, it's mostly car traffic. There are bike lanes, but the construction can be distracting and disruptive. Throughout the downtown commute, I can easily keep up with the cars. There are so many cars that they slow each-other down, but lots of them don't know this.

The downtown part of my rides finishes at the top of a hill, and then I get to bomb down it, across the commuter train tracks and past the train stop. Most days, when the weather is nice, instead of turning left to get onto the train, I turn right up another hill.

This hill is surprisingly steep. This is probably the hardest part of the ride. The people here seem to have bigger cars than downtown, and they are more distracted. I'm not moving particularly fast here so they zoom by me.

Then it's relief: This hill ends in a beautiful park. Often I won't see any cars for the entire trip through the park. In a few minutes, I'll ride past an awesome view of the mountain, weather permitting.

It's a steady climb from here to the top of the hills. The steepest part is fortunately pretty short and I like to tackle it quickly to get it over with. Pretty soon, I'll ride by the zoo and often hear loud bird sounds or something.

I like the downhill part of the ride because I don't have to take it too slowly. There's no traffic, just a bike lane beside the highway. Very occasionally, I'll be going faster than the cars on the highway, but not usually.

Then I hit the suburbs. The drivers here are extremely distracted, impatient, and driving large cars. The streets are designed to direct the traffic onto particular streets, so I have learned to avoid those streets and ride over the speed bumps.

At the end, I ride across the train tracks again. I could have taken the train all the way in, but this was much nicer :)

Recently I heard an interview with Muhammad Yunus where he talked about his new book, Creating a World Without Poverty. Yunus is one of the pioneers of microcredit, which is the "extension of very small loans (microloans) to the unemployed, to poor entrepreneurs and to others living in poverty". He also won the Nobel Peace Prize for his work.

The idea is that these microloans help poor folks to get out of debt patterns and to bootstrap making money. These loans are often given to collectives of women, who are more likely to pay them back.

It's such a cool idea, and very exciting that it apparently works. I don't really know anything much about Yunus or his work, but I'm really interested to read his new book and see what big ideas he's been having.

Bill Gates has recently talked about a new kind of "creative capitalism" from businesses to help improve the lives of the poor. (Maybe Gates is trying to redeem himself.)

Most of his examples sound very similar to what Yunus was talking about in the interview. Maybe they're working together? We can all hope it's not a new kind of "Embrace, Extend, and Extinguish" tactic.