GeoRSS has gained a lot of popularity and has recently shown up in some user tracking applications like Dopplr and Plazes. This means you can drop the feeds into your feed reader - or GeoRSS widget or aggregator to mix in your friends' or family members' locations with your other feeds.
However, once you pull the feed out of the original service, you should being to wonder about the privacy. Many of these services required authorization before allowing you to pull down feeds. This way they can make some assurance that only allowed people can grab your location feed. However, once the feed is pulled out, it is out of the hands of an authorization system and has a very easy potential to be made unwittingly public.
The onus of security is on the application or aggregator that pulled the feed on behalf of the authorized user. But at the same time once the feed has been retrieved, there is no storage of the authorization credentials with the feed itself. It has essentially been stripped of it's shell of potential privacy and looking at the feed itself you would have no idea if it was supposed to be kept private, and visible only to certain, unknown persons.
What would be nice would be a mechanism to store at least references to permissions and authorization credentials within the feed itself. That way if an application still has the feed, or wishes to store it and re-aggregate it, they can apply the same authorization as the feed originally had.
Brian Suda pointed me to the, currently suspended, Platform for Privacy Preferences. But this appears to be a rather heavy-handed approach. The W3C GeoPriv Working Group is also looking at location privacy but not in terms of feeds, and the idea of permissions and privacy aren't specific to location (though that is typically where it gets a large amount of attention).
I'm wondering if there exists, or could easily be formulated, an additional markup in Atom to specify permissions. It would still be the responsibility of the application to abide by these permissions - but at least they would have the information necessary to do so.
Here is a possible solution. Provide a default access (private), but then refer to authorization endpoints for who would be allowed to view this feed. In this example, if the user can provide OpenID authorization to this URL, then they can view the feed: