Não posso precisar, mas a primeira vez que ouvi falar de SQL Injection deve andar a rondar uma década quando o rain forest puppy publicou na Phrack um artigo sobre as implicações de segurança que a vulnerabilidade pode implicar.

Parece que existe muito webmaster que só agora soube do termo, sinal de ignorância profissional já que a maioria das linguagens para a web possuem funções específicas de modo a prevenir estes ataques. Ninguém pode afirmar que está imune aos mesmos, mas um script automático descobrir e explorar aleatoriamente 500 mil sites em ASP/X vulneráveis é deveras preocupante para todos os utilizadores da rede.

Nunca fui de acompanhar estatísticas de sites pessoais, leia-se não comerciais. De longe a longe lá consulto o webalizer mais para verificar uma situação especifica do que para fazer grandes interpretações dos números apresentados.
Pode parecer cliché, mas eu escrevo para mim sem dar grande importância à audiência. Quando digo isto, normalmente perguntam-me porque o faço publicamente, e a resposta vem numa analogia de que é mais libertador gritar para o infinito de uma falésia do que dentro de um quarto, se houver eco de volta melhor, senão é gratificante o bastante.

Este POST surge depois ter lido a opinião da Mª João Nogueira sobre o mesmo assunto e de no desenvolvimento alguém ter sugerido "aldrabar" o Blogómetro.
O Blogómetro baseia-se no sitemeter que por sua vez contabiliza os requests HTTP feitos ao site. Aldrabar estes requests significa fazer um shell script com um loop e um curl com umas flags pelo meio a apontar para o objecto do Sitemeter e deixá-lo a correr durantes umas horas.
O resultado é este:



Se registasse o My Little Place no Blogómetro, estaria em primeiro em todos os tops, não o faço para não atrair visitas indesejáveis. A parte da Blogosfera que se debate perante estes números deveria pensar que um bom blog não tem de ser o mais visitado (com toda a subjectividade aqui demonstrada), mas sim o que acrescenta valor a quem o lê.

No dia 8 de Abril a Network Solutions começou a resolver todos os subdomínios inexistentes dos domínios que hosta para os IPs dos seus servidores de publicidade.
Supostamente este procedimento é legal porque no "contrato" de aceitação do serviço existe esta alínea:


You also agree that any domain name directory, sub-directory, file name or path (e.g.) that does not resolve to an active web page on your Web site being hosted by Network Solutions, may be used by Network Solutions to place a "parking" page, "under construction" page, or other temporary page that may include promotions and advertisements for, and links to, Network Solutions' Web site...'


Basicamente os utilizadores da NetSol cederam direitos de trademark, e esta pode fazer publicidade usando o nome de marcas que não são suas.
Como se esta situação não fosse suficientemente dúbia de legalidade, mas certamente reprovável a nível de conduta profissional, as páginas de publicidade mencionadas apresentavam vulnerabilidades a nível de XSS que exploradas permitem injectar código no domínio pai com por exemplo pop-ups, ou seja a segurança do site do utilizador não depende só deste, mas também da segurança de páginas feitas por terceiros que decidiram fazer hijack aos seus subdomínios inexistentes.
Muita gente anda a usar o OpenDNS como a oitava maravilha do mundo, e dei-me conta que os nameservers destes fazem exactamente o mesmo, resolvem subdomínios inexistentes para 208.69.34.132 servindo uma página dos próprios.

A meu ver este problema não se cinge apenas aos DNS, mas também aos webservers. Existes muitos webhosting providers que configuram os webservers para que o error 404 dê origem a uma página publicidade dos mesmos, e caímos no mesmo problema de segurança se essa página apresentar vulnerabilidades.
È por estes motivos que prefiro sem dúvida ter o meu próprio nameserver/webserver e apenas depender da conectividade do meu ISP, no enquanto apareceu um estudo a comprovar a existência de ISPs que andam a injectar Ads no payload dos pacotes TCP destinados a HTTP.
Sem dúvida que algumas entidades reguladoras/fiscalizadoras não andam a fazer o seu trabalho.

Update: NebuAd and Partner ISPs: Wiretapping, Forgery and Browser Hijacking

Tu desconfias que estás perante um verdadeiro flop quando um produto que devia ser lançado em 2003 apenas o é em 2007 sem a inclusão das funcionalidades centrais anunciadas e as que trás não são novidades para o mercado.

Tu sabes que estás perante um verdadeiro flop quando são os próprios utilizadores que não fazem o upgrade para esse produto porque as novidades funcionais não justificam o investimento

Tu tens a certeza que estás perante um verdadeiro flop quando a empresa aumenta o tempo de vida da versão anterior desse produto e começa a fazer propaganda ao seu sucessor sem se preocupar com as consequências que tal anúncio acarreta para adopção da versão actual.