Assemblix Backstage

Googlen kalenteri ja Nokian N800 toimivat varsin hyvin yhteen, kunhan nettitablettiin sujauttaa ensin gpe-calendarin ja synkronointiin erminig-nimisen Maemo-softan.

Voin nyt tehdä merkinnän joko Googlen web-liittymällä tai taskussa kulkevalla tabletilla, tarvittaessa off-line. Kummankin merkinnät päätyvät lopulta toiselle.

Parasta koko hommassa on tämä Googlen maksuton SMS-muistutus tulevasta kalenterimerkinnästä. On niin hyvä palvelu, ettei varmasti kauaa enää pysy maksuttomana.

No, nautitaan vielä kun voidaan.

Tänään avatun wikimme viime hetken säätelyissä meinasi mennä hermot. Muuten MediaWiki toimi oikein kiltisti, mutta lyhyet osoitteet tuottivat ongelmia.

Ongelmia aiheutti assemblix.netin WAMP-alusta. Palvelu pyörii siis Windows Server 2003:lla, Apachella ja MySQL:llä.

Linuxin ja Windowsin välillä ei yleensä ole ollut suuria eroja, mutta nyt niitä aiheutti tiedostopolun kaksoispiste. Kaikki MediaWikin erikoislinkithän sisältävät niitä, esimerkiksi /Ohje:Ohje.

Niin kauan ongelmia ei ollut, kun käytimme puoli-pitkää osoitemuotoa /index.php?title=Ohje:Ohje. Lyhyimpään muotoon pääsy ei kuitenkaan luonnistunut, sillä Windows alkoi valittaa kielletyistä merkeistä:

(20024)The given path misformatted or contained invalid characters: Cannot map GET /index.php/Assemblix:Ajankohtaista HTTP/1.0 to file, referer: http://wiki.assemblix.net/LAMP

Ymmärsin, että vika liittyi kaksoispisteeseen joten aloin kehittämään mod_rewritella ratkaisua, jotta kielletty merkki ei päätyisi tiedostojärjestelmälle näkyviin kutsuihin.

Apachen mod_rewrite on oma tieteenhaaransa, eikä väitä sitä läheskään ymmärtäväni. Rewrite-loggauksen, foorumien lueskelun, yrityksen ja erehdyksen kautta tajusin kuitenkin miten vian voi ohittaa.

Normaalisti olisin kohdistanut uudelleenkirjoitussäännön hakemistotasolle, eli joko .htaccessiin ja httpd.conf:in Directory-elementtiin. Tämä muoto ei kuitenkaan toimi Windowsissa:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php?title=$1 [L,QSA]

En nyt aivan tarkkaa syytä tähän tiedä, enkä oikeastaan sitäkään, miksi seuraava muoto toimii. Eli kun muutin hieman sääntöä ja siirsin sen globaaliin kontekstiin, ei virheitä enää tullut:

RewriteCond c:/htdocs%{REQUEST_FILENAME} !-f
RewriteCond c:/htdocs/%{REQUEST_FILENAME} !-d
RewriteRule ^/(.*)$ /index.php?title=$1 [L,QSA]

Tätä ennen olin yrittänyt erinäisiä eksoottisia temppuja, mm. kaksoispisteen sisältävien osoitteiden erikoiskäsittelyä:

RewriteCond %{REQUEST_URI} ^/(.*)MediaWiki: [OR,NC]
RewriteCond %{REQUEST_URI} ^/(.*)Talk: [OR,NC]
RewriteCond %{REQUEST_URI} ^/(.*)Template: [OR,NC]
RewriteCond %{REQUEST_URI} ^/(.*)User: [OR,NC]
RewriteCond %{REQUEST_URI} ^/(.*)Special: [NC]
RewriteRule ^(.*)$ - [S=nnnn]


Kyseessä on kuulemma vanha vika Windows-Apachessa, johon ei ole vieläkään saatu korjausta.

Lisätietoa mm. Apache Lounge: Error in MediaWiki with Apache 2.2.X and PHP 5.1.X ja
MediaWiki Users: (20024)The given path misformatted or contained invalid characters:.

Sopivasti muotoillun linkin klikkaus suorittaa minkä tahansa komennon kaikissa Windowsin Firefox-versioissa (myös 3.x).

Tässä tapauksessa käynnistyy Windowsin calc.exe:

Tämä yhdistettynä JavaScript-koodiin, joka peittää tilarivillä näkyvän osoitteen… Huh, tästä tulee vielä epidemia.

Bugzillan mukaan koodia on korjattu kyllä varsin vikkelästi, mutta se odottaa vielä testausta ja pääsyä jakeluun.

(Kiitokset jälleen digitoday.fi:lle otsikon inspiroinnista!)

Huolimattomasti sanitoitujen Office-tiedostoliitteiden mukana kulkee tuon tuosta arkaluontoisia lisätietoja. Toistuvasti käytetyn tarjouspohjan vanhat tiedot tai peruutuspuskurin turhat jämät kannattaa suodattaa perusteellisesti ennen lähetystä.

Nämä aivan uusimmat Officet hoitavat siistinnän onneksi omatoimisesti - vanhemmat olivat varsin lavertelevia.

Aivan tavallisissa mediatiedostoissa kulkee kuitenkin yhä enemmän tunnistedataa. Digipokkareista tallentuneeseen megapikselimössöön saisi kevyesti upotettua Sonera-kirjan jos toisenkin, eikä tiedostokoko tuntuisi vielä missään.

Viime aikoina olen testaillut, kuinka paikkatieto- ja IPTC-kuvaukset siirtyvät eri palvelujen ja laitteiden välillä.

Hieman parempaa tietoa tiedosta kuitenkin jossakin tarvitaan, sillä varsin sekaisin ovat nämä meta ja data. Pelottavan ylivuototautisilta Mehtälä-muistiinpanot loppuvaiheessa näyttivät:

Olen siis video - kliketi kliks! »

Olen sulkenut ikkunoita GUI-ympäristöissä kohta 20 vuotta tuplaklikkaamalla sitä ikkunan vasemmalla puolella näkyvää pientä kuvaketta.

Stardockin uusimman WindowBlindsin asennettuani tämä menetelmä ei ole toiminutkaan enää kunnolla.

Kun valitin softavalmistajan foorumilla, minua valistettiin että Windowsissa ikkunat voi sulkea painamalla myös siellä oikealla puolella olevaa X-ruksia.

Olin aina kuvitellut, että vain aloittelijat käyttävät ruksia - kenties juuri ne samat, joille tehtäväpalkissa ärsyttävästi tilaa vievät Copy- ja Paste-nappulatkin on tarkoitettu.

No joka tapauksessa, olisi kiva jos joku Windows-guru voisi vilkaista Winspector-screencastiani ja heittää noille Stardock-porukoille valistuneen arvauksen mistä ongelma johtuu. Ehkä saan sitten tämän kahdenkympin karkkikuomun korjattua.

Pieni jenkkikauppa ei tykkää ulkomaalaisesta. Osoitetietojen antamisen jälkeen voimme ihmetellä stack tracea:

Äidin pyytämä dieettikirja jäi sitten ostamatta.

Eilen tämä aukesi vielä ongelmitta, tänään sain virhesivun:

MySQL-käyttäjätunnuksesi on web22_ul. Kiitos tiedosta.

Vaikka nykyinen Windows on varsin tuore asennus, alkaa tilannevalikko taas huolestuttaa:

Toivottoman sekavaa.

No, kaipa näitä pääsee muokkaamaan jollakin GUI-hakkerointivälineellä. Nuo alimmat (Cut, Copy, Create Shortcut, Delete, Reneme) ainakin voisi poistaa. Käytän niihin näppäimistöä, en valikkoa.

Ja kappas, minullahan näyttää olevan tuolla kaksi eri vertailusoftaa, WinMerge ja Beyond Compare.

Huvittavinta tässä yltäkylläisyydessä on kuitenkin se, ettei usein tarvittua Create new folder -komentoa löydy sitten millään. Sen esiinsaanti vaatii juuri tiettyä Explorer-kontekstia, pelkän kansion klikkailu ei kumma kyllä riitä.

Nokia N800:lle tulossa oleva Skype (josta on tiedetty jo kuukausia) konkretisoitui sopivasti vain päivää ennen iPhone-ryntäystä.

Laskelmoitua?

(Kuva: jkontherun)

Spammaajat ovat keksineet näköjään taas keinon ohittaa Outlookin roskapostisuodatin.

Outlookin suodatin käyttää Microsoft Researchin kehittämää SmartScreen-tekniikkaa. Toteutuksen yksityiskohdat ovat tarkkaan varjeltu salaisuus. Venäläisten reverse engineering -analysoinnin ja Microsoftin omien dokumenttien perusteella tekniikasta tiedetään kuitenkin jonkin verran:

SmartScreen perustuu neuroverkkoalgoritmiin ja on esimerkki ns. oppivasta koneälystä (machine learning).

Oppimateriaalina käytetään mm. Hotmail-käyttäjiltä saatua tietoa siitä, millaisia sanomia raportoidaan roskapostiksi. Tämän lisäksi SmartScreen sisältää joukon heuristiikkaa ja erilaisia sääntöjä, joilla vastaanotettu sanoma pisteytetään roskapostiepäillyksi.

SmartScreeniä käytetään valtaosassa Microsoftin sähköpostituotteista ja se lisättiin Outlookiin Office 2003:n ilmestyessä. Kirjoitin tuolloin SmartScreenstiä ja sen salatuista rajapinnoista myös Assemblixiin.

SmartScreen poikkeaa muista oppivista suodattimista, sillä käyttäjä ei voi itse opettaa sitä tunnistamaan tai olemaan tunnistamatta roskapostiksi. SmartScreen voidaan ohittaa omilla black- ja white-list -luetteloilla, joissa voi määrittää osoitteita tai verkkotunnuksia aina sallituille tai aina suodatettaville posteille.

Suodatuksen herkkyyttä voi säätää hyvin karkeasti, eli ainoastaan matalaksi tai korkeaksi. Näiden tarkempaa toimintalogiikkaa ei ole julkaistu, ja sopivan herkkyystason valinta edellyttää testaamista pidemmällä aikajaksolla.

Oman kokemuksen perusteella matala suodatustaso ei ole missään nimessä liian matala, sillä roskapostikansioon kulkeutuu viikoittain sallittua postia. Korkean suodatustason valinta ei ole käynyt itselläni siis mielessäkään.

SmartScreen sisältää varmasti aivan hienoa teknologiaa. Microsoft on kuitenkin mokannut pahemman kerran UI-toteutuksessa, jolla käyttäjä voi ohjata suodatinmoottoria ja yleisemmin koko roskapostisuodatuksen prosessia Outlookissa.

Roskapostisuodatus tapahtuu ennen käyttäjän määrittämien sääntöjen käsittelyä. Itselläni on yli 100 sääntöä tulevalle postille, joilla ohjaan esimerkiksi postituslistojen viestit oikeisiin kansioihin. Outlookissa voi sallia kyllä osoitekirjasta löytyvien osoitteiden päästäminen läpi, muttei sääntöjen osoitteista. Outlook jättää siis sääntöihin tallennetun arvokkaan tiedon hyödyntämättä ja merkitsee viestejä aivan turhaan roskapostiksi.

Outlookin käyttämää sanastoa ja sääntöjen parametreja päivitetään kuukausittain Microsoft Update -kierrosten yhteydessä. Päivitysten väliin jää kuitenkin pitkiä aikavälejä, jona roskapostitehtailijat voivat oppia kiertämään viimeisimmät säännöt.

Kesäkuun Outlook-päivityksen salat on ilmeisesti jo selvitetty, sillä viikonlopun aikana on Outlook alkanut päästää läpi aivan ilmiselvää kuvallista roskapostia. Välissä on ollut monen kuukauden tauko, jolloin Inboxini pysyi kiitettävän puhtaana.

Yllä olevasta kuvakaappauksesta näkyy, että postipalvelimellani oleva SpamAssasin on analysoinut viidestä sanomasta kolmen roskapostiksi. Outlookin mielestä kaikki viisi ovat sallittua postia.

Kaiken huipuksi Outlook ei näyttäisi millään tavoin reagoivan SpamAssasinin lisäämiin X-Spam -kenttiin.