Fri, 30 May 2008 21:18:00 GMT
Domain Tasting Games 1
I came across new "game" being played related to domain names. I was in a position to attempt to capture a domain that had expired and was about to be deleted. I had the .ca version of that domain and wanted to get the .com that was just about to be available. I employed a service that is designed to capture these domains as soon as they become available. I've done this before successfully so I was hopeful that this one would happen without a hitch.
Well the service announced that the domain had been captured by a registrar called "namevolcano.com". I knew a lot of the domain spammers capture newly deleted names to "taste" them for the revenue generation prospects. They usually drop these domains within 5 days so that they don't have to pay for them. I guess that they are looking for domains that will generate more revenue than the roughly $6/yr that they end up paying for registering them. So I was hopeful that I still might get a crack at the domain.
About 4 days after the domain was captured by "namevolcano.com", I got an email that was trying to "sell" me the domain, suggesting that the fact that I had the .net variant (I didn't have that) that I really should buy this .com from the sender, for the low price of only $557! I was careful at the time to not follow any the links in the email as that might have shown interest to the sender and they might have kept the domain. I didn't repsond.
About 12 hours after receiving the email the domain change hands to a registrar called "vibrant networks". After two days, I received a second email, substantially the same as the first, although reminding me that this was their second email on the subject.
After the second 5 day tasting period ran out, I finally captured the domain. I then went back and started checking the links provided by the email. This is how I got the $557 purchase number as it wasn't actually in the email.
A interesting fact is that the whois server for the second taster was whois.itimemarketing.com, which is the same domain where the link in the initial email was pointed at. So these two domain registrars seem to be related and were playing some kind of tag team game. I guess they figured that they needed 10 days to try to "sell" the domain to me.
I've use the words "game" and "sell" in quotes above as I actually consider this activity to something in the neighborhood of scam to extortion. Somehow think that this kind of activity is against the terms of service that registrars must follow to be accredited by ICANN. ICANN has really got to clean up the mess of scammers that are posing as domain registrars. These guys make the oil, gas and electricity market manipulators look tame by comparison in their brazen activities.
The one takeaway I can suggest from this experience is that if you run into a similar situation, don't do anything to raise the scammer's hopes of actually selling you the domain as I think that this will reduce your chances that they will just let the domain go and give you a real chance of getting the domain.
Well the service announced that the domain had been captured by a registrar called "namevolcano.com". I knew a lot of the domain spammers capture newly deleted names to "taste" them for the revenue generation prospects. They usually drop these domains within 5 days so that they don't have to pay for them. I guess that they are looking for domains that will generate more revenue than the roughly $6/yr that they end up paying for registering them. So I was hopeful that I still might get a crack at the domain.
About 4 days after the domain was captured by "namevolcano.com", I got an email that was trying to "sell" me the domain, suggesting that the fact that I had the .net variant (I didn't have that) that I really should buy this .com from the sender, for the low price of only $557! I was careful at the time to not follow any the links in the email as that might have shown interest to the sender and they might have kept the domain. I didn't repsond.
About 12 hours after receiving the email the domain change hands to a registrar called "vibrant networks". After two days, I received a second email, substantially the same as the first, although reminding me that this was their second email on the subject.
After the second 5 day tasting period ran out, I finally captured the domain. I then went back and started checking the links provided by the email. This is how I got the $557 purchase number as it wasn't actually in the email.
A interesting fact is that the whois server for the second taster was whois.itimemarketing.com, which is the same domain where the link in the initial email was pointed at. So these two domain registrars seem to be related and were playing some kind of tag team game. I guess they figured that they needed 10 days to try to "sell" the domain to me.
I've use the words "game" and "sell" in quotes above as I actually consider this activity to something in the neighborhood of scam to extortion. Somehow think that this kind of activity is against the terms of service that registrars must follow to be accredited by ICANN. ICANN has really got to clean up the mess of scammers that are posing as domain registrars. These guys make the oil, gas and electricity market manipulators look tame by comparison in their brazen activities.
The one takeaway I can suggest from this experience is that if you run into a similar situation, don't do anything to raise the scammer's hopes of actually selling you the domain as I think that this will reduce your chances that they will just let the domain go and give you a real chance of getting the domain.
Wed, 28 May 2008 18:13:00 GMT
Is Microsoft Trying to Wrap RSS in DRM?
I received an interesting message yesterday from a developer using Microsoft's Silverlight (I suspect a Microsoft employee). He was trying to read a RSS feed from the Twemes.com website but couldn't because Twemes.com did not have a cross-domain policy file. My immediate thought was "What's Microsoft attempting to do to RSS?" It felt like some kind of Trojan Horse, sneaking in with the Silverlight runtime.
My "expertise" in Silverlight cross-domain policy requirements consists of about 10 minutes reading the provided references, so I could be completely wrong about all of this but here are my concerns about using this for RSS.
Microsoft seems to have modeled this on Adobe's cross-domain policy file (/crossdomain.xml) and will fall back to this file if it doesn't find it's perferred /clientaccesspolicy.xml. The idea being that client software that supports the use of this policy file will use it to decide if the content on a given website is allowed to be used by the client. So for Adobe Flash or MS Silverlight runtimes, it's a way to prevent someone from creating an application that access resources from a website that does not explicitly give it permission. (I'm assuming that this is a technical permission and does not assign copyrights but I'm Not A Laywer).
I don't know how effective this has been for controlling cross-domain usage of Flash resources but it seems superficially viable. Especially with the Flash file formats and players that were at one time proprietary (are they still?) This could provide for a type of DRM, regardless of it's effectiveness.
The problem with applying this kind of DRM to RSS is that in some respects, a RSS file *is* a content policy file. It kind of says: "Instead of scraping data from my website's HTML pages, I'll give you this data in an nice machine readable format so you will get it right and so I can have some say in what and how it is presented." By having an RSS feed, we are saying you can use this data in the RSS file but leave the rest of what's on the website alone. I don't know how much legal standing this has but there does seem to be a pretty clear common sense message in RSS.
So over the last 8 years RSS has developed with a fairly universal understanding that its reasonable for any software to import and use it (within the bounds of copyright) and that if the publisher doesn't like this, then don't publish it. If you want to restrict access to an RSS feed, use technology (such as HTTP basic authentication) to do that.
So why is Microsoft demanding a new layer of permission system (DRM) to be present before a Silverlight program can access resources that have been considered completely open? Is this just the side effect of overly intrusive legal counsel? A beta software problem where RSS was just thrown in with media files types and no one considered this issue? Or is just another example of Microsoft's long history trying to turn open standards into proprietary Microsoft monopolies?
My "expertise" in Silverlight cross-domain policy requirements consists of about 10 minutes reading the provided references, so I could be completely wrong about all of this but here are my concerns about using this for RSS.
Microsoft seems to have modeled this on Adobe's cross-domain policy file (/crossdomain.xml) and will fall back to this file if it doesn't find it's perferred /clientaccesspolicy.xml. The idea being that client software that supports the use of this policy file will use it to decide if the content on a given website is allowed to be used by the client. So for Adobe Flash or MS Silverlight runtimes, it's a way to prevent someone from creating an application that access resources from a website that does not explicitly give it permission. (I'm assuming that this is a technical permission and does not assign copyrights but I'm Not A Laywer).
I don't know how effective this has been for controlling cross-domain usage of Flash resources but it seems superficially viable. Especially with the Flash file formats and players that were at one time proprietary (are they still?) This could provide for a type of DRM, regardless of it's effectiveness.
The problem with applying this kind of DRM to RSS is that in some respects, a RSS file *is* a content policy file. It kind of says: "Instead of scraping data from my website's HTML pages, I'll give you this data in an nice machine readable format so you will get it right and so I can have some say in what and how it is presented." By having an RSS feed, we are saying you can use this data in the RSS file but leave the rest of what's on the website alone. I don't know how much legal standing this has but there does seem to be a pretty clear common sense message in RSS.
So over the last 8 years RSS has developed with a fairly universal understanding that its reasonable for any software to import and use it (within the bounds of copyright) and that if the publisher doesn't like this, then don't publish it. If you want to restrict access to an RSS feed, use technology (such as HTTP basic authentication) to do that.
So why is Microsoft demanding a new layer of permission system (DRM) to be present before a Silverlight program can access resources that have been considered completely open? Is this just the side effect of overly intrusive legal counsel? A beta software problem where RSS was just thrown in with media files types and no one considered this issue? Or is just another example of Microsoft's long history trying to turn open standards into proprietary Microsoft monopolies?
Sun, 13 Jan 2008 18:52:00 GMT
Twemes.com - Twitter Memes
Over the last couple of months, I've gotten myself into Twittering more and trying to see how this could be a useful tool to me. I've found that by following a number of prolific Twitterers, that I can keep my finger on the pulse of a number of subject areas. One of the problems I ran into is that I often feel that I'm missing out on half of the conversation and wanted to easily see the whole conversation around specific memes. That's when the concept of a tweme (Twitter meme) came up. A tweme is a tag that gets included in twitter posts about a particular meme. This makes it possible to look at twitter posts from the perspective of that meme and see what the whole twittersphere is saying about it.
As a first approximation of what viewing twemes would be like, I've create Twemes.com. Twemes.com shows the most recent twemes as extracted from the Twitter public status stream as well as a "tweme cloud" of the most active twemes. You can also view and bookmark pages of specific twemes so that you can follow the twittersphere's thoughts on that meme.
Thu, 12 Jul 2007 21:34:00 GMT
Typo
I've decided to convert my infrequently updated blog from Wordpress to Typo. Not because there is anything wrong with Wordpress. In fact, I quite like Wordpress but I wanted to try out Typo and I thought it would be educational to have a closer look at a real world Rails app. The install process was pretty straight forward. I created my own theme out of the scribbish theme provided.
I did find that the way that Typo managed it's template system to be quite interesting. While I was familiar with being able to programatically set the layout for a controller or the whole application, what I really wanted to do was to to be able to override any view template for a specific theme. I've done this kind of thing in PHP but I really wanted to do this "the rails way". What Typo does is quite elegant although it's a bit risky. Typo overrides the ActionView::Base function full_template_path which will produce an absolute path for a template. By default this resolves to templates in the RAILS_ROOT/apps/views directory but Typo overrides this and sets up a list of serach paths to attempt to resolve to that includes RAILS_ROOT/themes/#{themename} . There are a couple of other tricks to get stylesheets, javascript and image directories to live in the theme directory.
I did find that the way that Typo managed it's template system to be quite interesting. While I was familiar with being able to programatically set the layout for a controller or the whole application, what I really wanted to do was to to be able to override any view template for a specific theme. I've done this kind of thing in PHP but I really wanted to do this "the rails way". What Typo does is quite elegant although it's a bit risky. Typo overrides the ActionView::Base function full_template_path which will produce an absolute path for a template. By default this resolves to templates in the RAILS_ROOT/apps/views directory but Typo overrides this and sets up a list of serach paths to attempt to resolve to that includes RAILS_ROOT/themes/#{themename} . There are a couple of other tricks to get stylesheets, javascript and image directories to live in the theme directory.
Thu, 08 Dec 2005 20:08:00 GMT
Google Transit
Google Labs has opened up a beta of their transit trip planning tool at http://google.com/transit. It generates very detailed directions about how to get from one point to another using public transit. It provides transit travel time, walking times and distances as well as a comparing with the cost and travel time of driving. A tool like this could really help people to make a well informed decision about whether to drive or take public transit.
Too bad it currently only works for Portland, Oregon.