Genom Nikke's index hittade jag info om forskningsprojektet Spamalot som utvecklas på University of Illinois in Chicago.
Det handlar om ett robotsystem designat för att kunna uppehålla bedragare i konversioner som aldrig tar slut. Systemet svarar på email och ber hela tiden bedragaren om mer information samt ber denne att ringa upp per telefon. Den kan även anta några olika personaliteret så att bedragaren inte ska lära känna mönster i svaren.
Några stackare gick verkligen på det hela under testperioden och man kan se emailkonversioner samt lyssna på några av de inspelade meddelandena från telefonsvararen.
Även om det inte verkar handla om nån riktigt "stark AI" så är det en rolig idé som jag hoppas på att vi får se mer av.
Vi har pratat mycket om användarvänliga url:er här på bloggen. Ni som har hängt med på ämnet vet att Microsofts ASP.NET-teknik inte är så optimal för att göra användarvänliga länkar.
Scott Guthrie som är utvecklingschef på Microsoft gör sitt bästa för att hålla modet uppe för alla url-designande freaks där ute. Vi har väntat länge på en lösning och nu kommer den snart i form av Longhorn Server och IIS 7.0.
Scott gjorde i måndags en genomgång av nya finesser i webbservern IIS 7.0 och visar även ett diagram hur processmodellen skiljer sig från den tidigare IIS 6.0. Samtidigt klargörs ytterligare en gång att IIS 7 inte kommer att finnas tillgänglig på Windows 2003.
Så det är väl bara att vänta på det nya serveroperativet då och alla de förbättringar som det kommer att ge.
Det som är bra är att man i alla fall får ordentligt med tid på att tänka igenom exakt hur man vill ha sina url:er när möjligheten finns att förbättra dem. Jag har tidigare spånat lite på hur jag vill ha urler:na till denna bloggen i kommentarerna till en tidigare tråd på ämnet.
Som ett exempel har just detta inlägget du läser just nu adressen:
http://codeodyssey.se/blog.aspx_id=270
Det säger ingenting om innehållet av artikeln för en besökare och det är det jag vill förbättra i första hand. Istället tycker jag att detta skulle vara en snyggare och mer tillgänglig adress.
Jag har fortfarande inte bestämt mig helt hur jag ska hantera alla specialtecken som inte stödjs i url:formatet. En som har funderat mer på dessa är Scott Hanselman och han bjuder idag på riktigt intressant läsning i sin artikel "Are Blog URLs important". Scotts blogg har rätt sjyssta url:er men dras fortfarande dras med .ASPX-ändelsen.
Det finns ju några genvägar mot snyggare adresser men vi känner att det bästa skulle vara att vänta tills IIS 7.0 kommer och man kan få till adresserna precis som man vill ha dem med en gång.Adresserna bör ju aldrig ändras så att göra några halvmessyer känns inte aktuellt.
Men för er som länkar till oss kan vara lugna. De url:er vi har just nu, kommer fortsätta att fungerar, även när vi lanserar de mer besökarvänliga varianterna. Trasiga länkar är inget kul.
Vi har jobbat med SQL Server nu i några år och gillar databas-typen från Microsoft. Den är robust, fungerar i alla väder och ger många trevliga verktyg att jobba med.
När man ska spara längre texter än maxstorleken för ett datapage på 8000 bytes, är det dock en del saker man bör tänka på. Speciellt om man jobbar på SQL Server 2000 och funderar på att uppgradera till SQL Server 2005 i framtiden.
Magnus Ahlqvist ger i en tråd på IDGs forum en bra förklaring till hur datapages fungerar och att storleken för index är 900 Bytes. Läs denna för att få lite insikt i hur prestandafrågor rörande textstorleken.
Vidare så kollar vi på vad det finns för alternativ för att spara texter på SQL Server 2000. Vi har varchar (max 8000 tecken - ej Unicode), nvarchar (4000 tecken - Unicode), text (2 GB data) och ntext (2GB data Unicode).
Så vill vi spara texter över 8000 Bytes på SQL Server 2000 så måste vi använda text eller ntext. Dessa datatyper sparar dock inte texter över 8000 Bytes direkt i dataraden utan endast en minnespekare till informationen. Läs mer på SearchSQLServer vilka problem detta kan leda till. Många funktioner som replace fungerar inte på datatyper som text eller ntext. Det finns dock lösningar på hur man kan köra replace på dessa typer också.
Så rådet är att använda varchar eller nvarchar i största möjliga mån. I SQL Server 2005 har ju dessa datatyper utökats med MAX-alternativet, och de kan innehålla mer data än 8000 Bytes.
Typerna text och ntext är på väg bort från SQL Server och kommer inte att stödjas i framtida versioner. Läs mer på SQL Server Helper som förklarar läget ytterligare.
Vi fick för någon månad sen fått en inbjudan till att vara med i adressregistret PAR men lade det brevet i "undersök vad det är senare"-högen. För en vecka sen fick vi en påminnelse och en uppmaning att komplettera våra uppgifter i registret. Det står att det är kostnadsfritt att delta, men någon omfattande beskrivning vad det innebär finns inte i brevet. Inte heller hur man ska göra ifall man inte vill vara med.
Idag läser jag Internetworlds artikel "Så värvar du kunder med finspam" och förstår lite mer vad PAR-registret används till. Företag kan använda registret för att skicka ut reklamerbjudanden via email. Bra att man nu vet vad det handlar om, det tycker jag PAR borde ha förklarat lite bättre i de pappersbrev vi fått. Fler erbjudanden på email är något vi inte riktigt behöver, så nej tack. Vill vi köpa en tjänst eller vara så letar vi helt enkelt upp den själva - när vi behöver den.
Idag var min första dag på en ny kontorsplats (mer info om detta senare) och det öppnar verkligen upp tankar om allt möjligt, att byta miljö.
Det senaste har jag haft ovanligt ont i min musarm och jag har insett att jag måste göra något åt mitt arbetssätt för att råda bot på detta.
Väldigt passande så skriver Jeff Atwood idag, om hur man genom några enkla knep, kan lära sig att använda kortkommandon på tangentbordet i större utsträckning. En positiv följd blir att man kodar snabbare och även får en mer välmående kropp.
Kan även rekommendera en tidigare postning av samma upphovsman där han går igenom de vanligaste kommandona för att navigera med kursorn i textmassor.
Att det är en vanlig metod att temporärt "ta ner" webbplatser genom Denial Of Service (DOS) är ett välkänt faktum. Det har under åren skett många hot och icensättningar av överbelastningsattacker mot webbplatser. Ibland politiska aktioner men även utpressning mot krav på pengar.
Bland annat har spelsajter i USA pressats på stora pengar av internetbrottslingar.
Kortfattat går det till så att webbplatsen överbelastas med ett stort antal anrop och genom att rikta sig mot dokument av stor datamängd.
Så vad kan man göra för att skydda sig mot dessa attacker?
Jo dels kan man göra det genom att använda smart hårdvara som kan känna av ifall trafiken härstammar från otillåtliga källor eller följer ett felaktigt mönster.
Men man kan även bygga in skyddet direkt i sin webb-applikation som Omar AL Zabir visar ett exempel på i sin blogg. Hans metod skriven i ASP.NET C# går ut på att besökarnas IP-adresser sparas i Cache-minnet under en stund och håller reda på att inte för många anrop har kommit från samma källa, inom en tidsrymd.
Smart tänkt och ett bra komplement till hårdvaruskydd.
Gapminder har nyligen blivit uppköpet av Google och på sökmotornjättens domän, finns nu verktyget att testa. Man kan se utvecklingen av jordens länder, enligt många parametrar som ländernas befolkningsmängd, ekonomisk tillväxt, livslängd, barndödlighet m.m. Gapminder-verktyget innehåller för tillfället data för åren mellan 1975 till 2004.
Programmet som såldes för en okänd summa, är utvecklat av professor Hans Rosling vid Karolinska Institutet och hans son.
Skatteverket har redan en spindel som är ute på nätet och samlar ihop uppgifter ifrån näringslivet. Målsättningen är att kunna hitta de näringsivrare som inte betalar skatt ordentligt.
Nu lanserar man en ny uppdaterad version, kallad Xenon, som ska vara ännu effektivare på att lokalisera skattesmitare. Samarbete sker sedan tidigare mellan Holland, England, Österrike, Danmark och Kanada. Och nu alltså även Sverige.
På DN kan man läsa mer om några hur det hela väcker olustkänslor hos Pär Ström, "integritetsombudsman" på tankesmedjan Den nya välfärden.
Dag Hardyson, Skatteverkets riksprojektledare för Xenon menar dock att det inte ska ska finnas några risker för att integriteten ska kränkas.
- Men vi tittar bara på det som är publikt. De här sajterna vill ju verkligen synas och vi letar inte efter sådant som är personligt, säger Dag Hardyson.
Jag blir mest intresserad av hur denna spindel är programmerad. Ska definitivt försöka hålla utkik efter den i våra besökarloggar. Ska bli intressant att analysera hur en svensk myndighet väljer att automatisera denna typ av övervakning. Om den nu kommer hit och krälar. Vi betalar skatt så du är välkommen att snoka runt lite, Xenon.
Om någon vet hur man identifierar denna spindel så uppskattar vi mer information.
Uppdatering:media:screen spinner vidare på tråden och ställer frågan om Skatteverkets datainsamling till och med kan vara olaglig, enligt upphovsrättslagen. Läsvärt helt klart.
Där finns även en del intressanta referenser, bland annat till artikeln på Wired. Här kan vi läsa att Marten den Uyl från företaget Sentient, som ligger bakom produkten, förklarar att spindeln kommer söka igenom webbplatserna enligt en långsam algorytm. Här handlar det om smart urval av länkar och innehåll. Han avslöjar dock inte vad spindeln kommer använda för user-agent (används till att indetifiera internet trafik) men förklarar att det är upp till varje skattemyndighet att ange vilken sträng som ska synas.
Igår kväll kollade jag genom min inkommande trafik till sidan. Såg då att någon stackare klickat sig in till vår hemsida från Windows Live på ett snuskigt engelskt uttryck. Denne besökare måste ha blivit ganska så besviken att hamna här för det var nog inte det han ville.
Hur som helst blev jag nyfiken på hur sökmotorn från Microsoft kunde hitta denna term på vår hemsida. Vi skriver ju inte om porr här och har absolut aldrig använt den termen som det handlade om. Jag sökte alltså på den i W-Live men kunde aldrig se vår hemsida på de första 30 sidorna i resultaten. Så detta förblir ett mysterium ett tag till.
Medans jag sökte på den snuskiga termen så hittade jag dock något annat intressant i resultaten. En url till en sub domän på det välkända företaget Eastpoint Media. Förundrad över vad de kunde finnas för porrelaterat på deras domän besökte jag adressen och hittade en gästbok helt överfull med spam.
Skickade vidare infon till Nikke eftersom han brukar ha intressanta tankar om SEO-företag. Han skrev sedan ett inlägg om det där han reflekterar över vådan av kommentarspam.
Att spam tar över en sida på det här sättet är väldigt vanligt, speciellt på sidor som använder lite äldre teknik. Sidan hos Eastpoint som är så spamfylld ligger antagligen kvar som en gammal rest från tidigare utveckling. Den har nog glömts bort och legat där och samlat spam ett bra tag.
Såna sidor är väldigt vanliga och i sökresultaten som jag just kollade hittade jag många fler, tex en på Unka.se.
Sen måste jag erkänna att jag själv var ansvarig för en liknande gästbok som låg hos en kund och samlade spam till bara för någon månad sen. Nu är den dock uppgraderad till ASP.NET och spammet har stoppat helt. Så nu har jag bättre samvete i denna fråga.
Men jag skulle tipsa andra utvecklare att se över sina gamla sidor, det är inget bra att ha såna här gamla applikationer som ligger och skräpar. Dels så växer era databaser och tar en massa utrymme. Sen skräpas sökresultaten ner ordentligt och det blir svårare att hitta relevant information.
Hur kan man stoppa spam?
Så vad gör man om man har problem med webbspam? Om du använder Wordpress har jag hört att tillägget Akismet fungerar väldigt bra. Läs t ex på TechCrunch hur det stoppar runt 15000 spam varje dag i deras blogg.
Om du utvecklar din egen blogg så kan du göra ditt eget skydd. media:screen berättade ett tag sen hur de stoppade spam på ett relativt enkelt sätt. De ville inte göra det för besvärligt för besökarna att lämna kommentarer, vilket är klokt.
Att använda en så kallad CAPTCHA-funktion är ett annat sätt som är rätt vanligt. Dock kan detta hämna besökare att lämna kommentar vilket inte är så bra. Gör den absolut inte så överdrivet komplicerad som i detta exemplet.
Här på Code Odyssey har vi inga spam-problem hittills vilket nästan är lite tråkigt. Det enda försöket har varit den kinesiska spammaren, men där rörde det sig nog om en människa.
Ska inte klaga för mycket men tycker det endå är lite roligt att se hur spam-robotar fungerar och lista ut sätt att överlista dem. Vi använder ASP.NET och enligt min erfarenhet så stoppar ramverket spam nästa automatiskt. Det vore väldigt intressant att höra av någon annan som har problem med spam på applikationer som kör ASP.NET.
Om nu spammet skulle komma igång så har jag tänkt att prova på NoBot i ASP.NET Ajax Control Toolkit. Denna ska enligt beskrivning känna av att mönstret på postningen liknar en människas aktivitet och stoppa de ovälkomna botsen.
I februari i år hittade säkerhetsexperten beNi ett XSS-problem på Googles inloggningssida. Se en skärmdump på denna "säkra" SSL-sida kunde utnyttjas innan den tätades av Googles utvecklingsteam.
Google har enligt uppgift tackat beNi för hans upptäckt men han blev lite besviken på att man inte gjorde mer för honom. Jag förstår honom. Ett företag av Googles storlek borde kunna visa lite större uppskattning, mot de snälla hackers, som hjälper till att säkra deras applikationer helt av eget intresse.
Eftersom beNi inte kände sig nöjd med responsen från Google, väljer han nu att i framtiden inte kontakta dem innan han avslöjar fler brister.
Nu avslöjar han således bevis för hur en datorbrottsling skulle kunna komma åt alla kontakter i en användares Gmail-konto och även Google Authentication Token. Dessa finns att få tillgång till genom en sida som genererar ett prydligt XML-dokument. Riktigt skrämmande faktiskt. Om du är inloggad i Gmail så kan du prova att surfa till denna adressen så ser du själv.
BeNi fortsätter sedan med att visa hur dessa uppgifter kan utnyttjas. Till detta behövde han en ny XSS-brist hos Google. Läs mer på hans blogg för bilder och förklaring hur detta går till. Jag har även sparat en skärmdump på sista steget i demonstrationen, här ovan.
Så från och med nu vet vi att Gmail-uppgifter inte är säkra. Det räcker med ett litet XSS-hack för att komma åt alla Gmail-kontakter. Så när dett nu är allmänt känt så rekommenderar jag dig att vara försiktig med vilka länkar du klickar på som går till Google. Vid minsta tveksamhet om källans ursprung bör du inte klicka på länken.
Själv använder jag inte Gmail så mycket och har bara en kontakt där så det känns inte så farligt för mig. Men att även verifieringsnyckeln finns så lätt åtkomlig känns riktigt otryggt. Jag vill inte att någon ska kunna ta över min Google-inloggning och börja leka med mina Adsense-konton och andra tjänster som jag använder.
