Datalagringsdirektivet – vilka måste lagra vad?

Riksdagen har röstat igenom införandet av Datalagringsdirektivet i Sverige, och nu börjar det stora arbetet med att implementera lagring av trafikdata hos operatörerna. “Operatörerna” ja – vilka är egentligen det? Och vad ska lagras? Det är mycket som inte är tydligt i den här debatten och jag bestämde mig för att åtminstone försöka reda ut på egen hand hur det ligger till. Vilka måste egentligen lagra vad?

Jag började med att leta efter information hos PTS – Myndigheten Post- och telestyrelsen, som har bra information (i den mån information finns) om vad som gäller. De har en informationssida om datalagringsdirektivet och jag hittade där ett par formuleringar som var intressanta, bland annat under “Dessa är skyldiga att lagra uppgifter”:

Enligt lagen är de aktörer som bedriver anmälningspliktig verksamhet enligt Lagen om elektronisk kommunikation, LEK, skyldiga att lagra uppgifter i sex månader.

Det är alltså endast de som har verksamhet som enligt Lagen om elektronisk kommunikation, LEK, är anmälningspliktig som måste lagra uppgifter enligt den svenska implementationen. Jag började således att läsa LEK för att se om jag kunde hitta informationen om vilka som är anmälningspliktiga, men det visade sig vara minst lika luddigt där, för i Kap 2, §1 står det:

Allmänna kommunikationsnät av sådant slag som vanligen tillhandahålls mot ersättning eller allmänt tillgängliga elektroniska kommunikationstjänster får endast tillhandahållas efter anmälan till den myndighet som regeringen bestämmer.

Det här är nästan rena grekiskan för mig. Jag är (bevisligen) inte jurist och jag får först vänja mig vid tanken på att det alltså finns en svensk lag som säger att den som tillhandahåller elektroniska kommunikationstjänster har en anmälningsplikt till myndigheten som måste fullgöras innan man tillåts leverera tjänster. Så den som vill starta en ISP måste alltså anmäla sig hos myndigheterna först. Varför? Jag har ingen aning, och det hela känns rätt märkligt. Kan det vara en kvarleva från sändningstillstånden som infördes när man startade med radio- och tevesändningar?

Hursomhelst, nyckelorden här verkar vara “mot ersättning” och “allmänt tillgängliga elektroniska kommunikationstjänster”. Dessa har anmälningsplikt och borde därför, enligt PTS, vara de som också måste lagra och leverera trafikdata till polisen på begäran. Men exakt vilka är det då? Den som driver en egen e-postserver för sig och sin familj, måste han också lagra data? Jag måste alltså gräva vidare, och efter att ha ställt ett par frågor på Twitter får jag några länkar som svar.

Oscar Swartz tipsar om ett par rapporter från PTS som ska berätta mer. Jag börjar med att läsa “Lagring av uppgifter för brottsbekämpning enligt EU-direktiv 2006/24/EG – Internationell utblick m.m. ?? PTS-ER-2011:1” vilket för övrigt är en fantastisk titel som jag ska överväga till min nästa skiva. Det här är en rapport från 2011 som PTS gjort i väntan på implementationsbeslut från riksdagen. Den tittar främst på hur andra EU-länder gjort vid implementation av direktivet och drar några försiktiga slutsatser för svensk del kring hur det kan tänkas gå till här hemma. Här står uttryckligen att “Skyldigheten att lagra uppgifter gäller enbart elektroniska kommunikationstjänster” vilket åter syftar på de som enligt LEK har anmälningsplikt.

Sen blir det lite mer spännande, för sen kommer en lista på de som INTE behöver lagra trafikdata. Här finns en gränsdragning mellan det som då kallas “elektronisk kommunikationstjänst” och de tjänster som inte omfattas av LEK, som istället kallas “informationssamhällets tjänster”. Här står det till exempel gällande “Webbpost (webmail) och webbaserad messaging”:

Följaktligen omfattas tillhandahållare av webbpost och webbaserade meddelandetjänster av direktivet om de samtidigt är tillhandahållare av allmänt tillgängliga elektroniska kommunikationstjänster eller allmänna kommunikationsnät.

Det här tolkar jag som att de som erbjuder webbmejl eller andra webbaserade meddelandetjänster endast omfattas av direktivet om de också har tjänster som omfattas av anmälningsplikten i LEK. Det här skulle då medföra att de företag som säljer Internetkapacitet och därför har anmälningsplikt måste lagra trafikdata för de tjänster de erbjuder, medan andra företag som kanske bara har en webbmejltjänst slipper undan förutsatt att de inte också är Internetleverantörer.

Rörigt? Lite. Skulle detta betyda att exempelvis Telia måste lagra trafikdata för sin webbmejltjänst medan Loopia slipper? Telia är klart och tydligt en operatör som omfattas av LEK, medan Loopia enligt nuvarande tolkning inte är det. Nu börjar det bli intressant!

Av Torbjörn Eklöv får jag en länk till en förteckning hos PTS på de som är registrerade efter anmälan enligt plikten i LEK. Här återfinns mycket riktigt Telia i listan medan Loopia saknas. Här saknas faktiskt alla svenska webbhotell jag letar efter, förutom ett par som jag känner igen eftersom jag varit/är kund där: ipeer och Glesys. Efter en fråga till  Glesys får jag veta att Glesys faktiskt säljer Internetkapacitet och därför omfattas av anmälningsplikten. Men alla webbhotell då? De saknas i listan, och förvirringen är total! Binero svarar mig på Twitter att de absolut omfattas, fast de är inte anmälda till PTS enligt LEK, så det verkar konstigt i såna fall.

Jag läser vidare i PTS-rapporten och ser att

När tillhandahållaren av en webbplats gör det möjligt för en användare att t.ex. lämna en kommentar till tillhandahållaren eller beställa en vara klassas det normalt som informationssamhällets tjänster och omfattas inte av direktivet.

Så webbplatser kommentarsfunktioner omfattas inte av DLD. Men sen blir det snårigt igen, för nu börjar jag fundera på sånt som Facebook eller andra webbplatser (varav jag själv driver åtminstone en) som låter användare skicka privata meddelanden till varandra:

När en webbplats skickar en notifiering till en användare för att tala om att användaren har ett meddelande som väntar på webbplatsen kan det göras i form av t.ex. e-post eller ett SMS. Om meddelandet passerar en leverantör av allmänt tillgänglig kommunikationstjänst omfattas det normalt av direktivet.

Meddelandet som lämnats inom webbplatsen anses däremot vara en informationssamhällets tjänster. Meddelandet omfattas då inte av direktivet.

Nu blev det ju jobbigt igen. Själva notifieringsmeddelandet som går som SMS eller e-post omfattas av direktivet förutsatt att det går via en “leverantör av allmänt tillgänglig kommunikationstjänst”. Man får anta att det då inte gäller om webbplatsen i fråga driver sin egen SMTP-server till exempel? Jag blir osäker. Men sen står det också:

När en webbplats skickar ett meddelande (inklusive innehåll) till en e-postadress på traditionellt sätt har det betydelse om webbplatsleverantören använder det egna nätet och sin egen mailserver eller inte. Det är stor sannolikhet att meddelandet hanteras av allmänt tillgängliga kommunikationstjänster och det omfattas då av direktivet. Används tillhandahållarens privata nät och den egna mailservern omfattas det inte av direktivet eftersom det då räknas som informationssamhällets tjänster såvida det inte gäller en tillhandahållare av allmänt tillgängliga elektroniska kommunikationstjänster och som använder sig av dessa.

Att tolka detta kräver lite tankekraft. Hur ett e-postmeddelande skickas från en webbtjänst till en användare e-postadress har alltså betydelse för huruvida meddelandet omfattas av direktivet eller inte. Om tjänsten har sin egen mailserver verkar man klara sig utan att lagra, men om man använder mailserver hos en “operatör” måste det lagras. Lagras av webbtjänsten? Lagras av operatören? Oklart.

Nästa stycke är lättare att begripa:

Besök på webbsidor, användning av sökmotorer, chatt, E-handel och on-line spel omfattas inte av direktivet eftersom dessa anses vara informationssamhällets tjänster.

All vanlig surfning omfattas inte av direktivet. Det betyder att din webbhistorik inte behöver lagras hos din operatör, vilket det tidigare varit tal om. Det står också att FTP och “spam som aldrig levereras till mottagarens e-postkonto” ska undantas från lagring. Däremot ska IP-telefoni lagras, men i dokumentet nämns bara “Internettelefonitjänst som startar och terminerar som en PSTN- telefonitjänst”, det vill säga där ena, andra eller båda parterna i samtalet använder sig av en klassisk “fast telefon” med jack.

Just IP-telefoni är lite extra intressant, för i den andra PTS-rapporten jag läser, “Vilka tjänster och nät omfattas av LEK? – PTS-ER-2009:12” tittade man ju på hur andra EU- och EES-länder bedömer vad som är eller inte är en “elektronisk kommunikationstjänst” och därför bör omfattas av datalagringsdirektivet (sid 16). Där finns en lista på de länder som granskats, nämligen Finland, Danmark, Lettland, Norge, Nederländerna, Tyskland, Spanien och England. Här har alla länder gjort samma sak och bestämt att P2P-VoIP inte är att betrakta som en sådan tjänst, vilket alltså skulle betyda att till exempel Skype helt undandas från trafikdatalagring!

Det är ju rätt häpnadsväckande egentligen. Tanken med direktivet är att polisen ska kunna få tillgång till trafikdata för att lösa terrorbrott, men så länge skurkarna använder Skype klarar de sig alltså. De kan också uppenbarligen använda Twitter eller Facebook för att prata med varandra utan att kommunikationen ska lagras alls! I princip verkar det endast handla om kommunikation som sker över kanaler som när direktivet införs nästan är helt omoderna. “Vanlig” telefoni, “vanlig” mobiltelefoni, SMS och e-post som skickas via registrerade Internetoperatörers e-postservrar. Om jag fattat detta rätt skulle skurkarna alltså i lugn och ro kunna använda iMessage i sina mobiltelefoner för att texta, Skype för att prata med varandra och e-post via en “icke-operatör” (t.ex. ett webbhotell) eller någon av alla hundratals andra e-posttjänster som finns, exempelvis GMail eller Hotmail.

Frågan man måste ställa sig blir till slut om det egentligen är någon brottslighet som kommer att infångas via trafikdatalagring om det är så här snävt det hela ska tolkas. ? andra sidan, om man ska vidga tolkningen blir det nästan löjligt mycket som måste lagras – alla anslutningar till alla webbtjänster i hela världen (för de skulle ju kunna vara e-mail/meddelandetjänster), ja egentligen alla IP-paket överhuvudtaget, eftersom det är mycket svårt utan att göra en ordentlig analys av paketens innehåll att veta om det är “mänsklig” kommunikation som gömmer sig där eller inte.

Till sist det här med VPN. Om man är det minsta orolig för att bli “datalagrad” – kan man då använda sig av en VPN-tjänst för att kryptera trafiken från sin egen dator till Internet och på köpet bli anonymiserad, eller kommer även VPN-tjänster att omfattas av direktivet och därmed tvingas lagra information om sina kunder och deras trafik? Daniel Westman svarar på Twitter att han tycker att det är oklart. Så den nöten återstår att knäcka, även om jag efter att ha läst igenom PTS rapporter tycker det ser tveksamt ut.

Som jag sa inledningsvis: Jag är inte jurist. Jag har säkert fel i massor av ovanstående slutsatser och en hel del är ju rena gissningar från min del (och andras). Om du som läser detta har möjlighet att sprida mer ljus över frågan, skriv gärna en kommentar!

/M;

Att rädda en 21 år gammal inspelning – datormagi med ljud

Min vän Anders och jag hade en gång i tiden ett synthband ihop med våra kompisar Olle och Jonas. Det här var i slutet av 80-talet och vi var fyra killar som gjorde musik på väldigt enkel utrustning (vi hade en Roland D-20 och en Yamaha V50) och en kassettportastudio. 1989 gjorde vi en kassettdemo som hette “In Fact” och den blev månadens demo i “Bandspaghetti” i tidningen MusikerMagasinet samma år.

Nu har Anders och jag ett helt annat band ihop, men för något år sen bestämde vi oss för att rädda våra gamla kassettportainspelningar innan kassetterna blivit helt avmagnetiserade eller försvunna. Ett stort digitaliseringsprojekt inleddes och vi samplade de gamla banden i ett ADAT-system och gjorde senare ett relativt seriöst försök att med hjälp av EQ och några filter försöka fräscha upp ljudet så gott det gick. Det brusade en hel del, men vi tänkte att det hörde till och att det inte gjorde så mycket.

Komplett Art Fact finns sedan dess att lyssna på och att ladda ner från last.fm. Det är, föga förvånande, inte särskilt många som är intresserade av att lyssna på våra 20 år gamla gamla kassettdemos på last.fm, men för någon månad sen fick jag ett mail från en kille som råkat lyssna på Art Fact och fastnat för en av våra låtar, “Rain In The South” och därför frågade om det var okej att rekommendera låten till en av hans vänner  som gör samlingsskivor på vinyl med gammal musik. Visst, sa jag, och tänkte inte så mycket mer på det.

För ett par veckor sen fick jag så ett mail till – nu från dennes vän som faktiskt också gillade låten och ville ha med den på nästa skiva! Det var bara ett problem – den version av Rain In The South som ligger uppe på last.fm är ju rätt brusig och har allmänt dåligt ljud, eftersom den faktiskt kommer från en kassett som legat i en låda i över 20 år. Kunde vi möjligen skicka en fullkvalitets WAV till skivproduktionen?

Okej, handsken var kastad och jag frågade Anders om han möjligen hade kvar den flerkanaliga dumpen av låten och om det fanns möjlighet att göra en något bättre version med med brusreduktion. Igår kväll träffades vi för att sitta i vår musiklokal och göra ett nytt försök att “rädda” Rain In The South och anledningen till att jag skriver den här bloggposten idag är att resultatet åtminstone för mig framstår som ren magi.

Med hjälp av Logic och en brusreduceringsplugg kunde vi skapa en helt ny master från våra extremt brusiga och burkiga originalsamplingar av kassettspåren. Det krävdes lite pill, men förvånansvärt lite, och i mina öron är resultatet så bra att det nästan låter nyinspelat. Ja, bortsett från den taffliga produktionen och den tonåriga sångrösten då.

Jag ger er nu chansen att höra låten, i en klassisk “före och efter”-situation. Den första spelaren innehåller den första remastern av Rain In The South som vi gjorde för ett par år sen. Den andra spelaren innehåller gårdagens remaster. Lyssna och förbluffas över vad som går att göra med digital ljudteknik idag. Och det på hobbynivå, med utrustning som inte ens kostar särskilt mycket! Jag törs inte drömma om hur mycket som går att göra om man är proffs på detta, eller om fem-tio år…

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.


Rain In The South – original

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.


Rain In The South – 2010 remaster

/M;

Permanenta länkar – vad är det?

I en debatt på mindpark.se stångades jag en stund med Joakim Jardenberg om vikten av absolut permanenta länkar på webben. Jag uttryckte min oro för att Jardenberg är på marsch mot ett förstelnande Internet och att göra ett stilleben av webben, eftersom han förespråkar att en länk är en länk är en länk, och absolut aldrig får brytas.

Jag förstår mycket väl vad han menar, det är tråkigt att bryta inlänkar och indexering i Google och andra sökmotorer, men jag är av uppfattningen att webben likt Internet i stort är under ständig förändring, och att vi inte kan bli för nostalgiska vad gäller en teknik eller något innehåll på webben. Och självklart förstår jag det positiva i att länkar inte bryts, men jag tycker helt enkelt att det finns många tillfällen då nackdelarna väger tyngre än fördelarna.

Nå – Jocke gick till så hårt angrepp att jag la några minuter på att slå hål på hans teorier genom att hitta trasiga länkar på en sajt han själv ansvarat för: hd.se. Lättare sagt än gjort skulle det visa sig, för man har verkligen ansträngt sig till det yttersta för att bevara gamla länkar.

Jag hittade till exempel följande länk genom att söka på Google: En artikel från Elöverkänsligas Riksförbund från 2004. Här länkas en artikel på hd.se som handlar om att Båstad sagt nej till nya 3G-master. Länken är som följer: http://hd.se/ArticlePages/200409/28/20040928161250_-Alla_anvandare-191/20040928161250_-Alla_anvandare-191.dbp.shtml

Ouch. Inte världens snyggaste URL direkt, men så ser den ut. Jag tänkte att jag hade hittat guldkornet jag letade efter, men blev snopen när länken faktiskt fungerade, och dessutom ledde rätt: http://hd.se/bastad/2004/09/28/baastad_saeger_nej_till_nya_3g/

Här har man ju uppenbarligen lyckats med att behålla en gammal inlänk så att den funkar, och leder till den nya länken. Imponerande! Finemang! Alla är glada. Eller? Jag kan inte låta bli att fundera lite på hur man gått tillväga. Den gamla URL:en innehåller datum för artikeln (20040928) och vad som gissningsvis är ett internt ID för artikeln från det CMS man använde 2004 (161250). Den nya URL:en innehåller inget ID alls, utan använder en modern permalinkstruktur där titeln från artikeln blir identifikationen (baastad_saeger_nej_till_nya_3g), så hur görs kopplingen från den gamla URL:en till den nya?

Här får jag gissa. HD kanske använder samma CMS nu som 2004, och i såna fall har artikelns ID troligen inte ändrats sen dess, och det är lätt att göra ett nytt fält i datbasen för “snyggare URL:er”. Men desto troligare är att HD har bytt CMS sedan 2004, och då kan man ha gjort på två olika sätt:

1) Man kan ha behållit alla ID-nummer från det gamla CMS-systemet när man importerade innehållet till det nya.

Det är ofta komplicerat, och en vanligare lösning är att man istället

2) häller in gamla ID i ett separat fält för detta (oldID, anyone?) för att bibehålla kopplingen.

Har man valt lösning (1) är det hatten av och bara att köra på. Det är väldigt lätt att göra en “rewrite” på gamla URL:er till nya i det fallet. Har man istället använd lösning (2) börjar jag få rätt i min argumentation på mindpark.se. För hur många generationer av gamla system ska man egentligen underhålla innan det blir löjligt? Visst, en generation kan man utan större problem underhålla för att ha permanenta länkar, men nästa gång man byter CMS, blir det ytterligare en generation av ID att hålla ordning på då? Och nästa gång, och nästa gång…

Min princip ligger fast – det ?R inte alltid försvarbart att till varje pris behålla länkstrukturer när man gör ett större systembyte. Det är lovvärt om det går att göra, och det finns ju inga nackdelar med att göra det om det är enkelt. Men om det är svårt, om det kräver att man hackar speciallösningar, och om det på sikt ändå är ohållbart – var går gränsen?

Och det som jag ser som det större problemet i den här frågan – ska vi verkligen betrakta webben som permanent? Kan vi inte acceptera att länkar bryts då och då? Finns det inte en ganska stor risk att vi på sikt hamnar i en okontrollerbar härva av föråldrade länkar som ska underhållas i all evighet?

/M;

Hur man misslyckas med distribution av digitala varor

Apple har släppt en ny version av sitt operativsystem, Mac OS X, kallat Snow Leopard. Jag som är varm anhängare av OS X ville självklart köpa en uppgradering för att installera på min arbetsmaskin. Eftersom allt som behövs för att installera det nya operativsystemet är en DVD-skiva från Apple borde det inte vara något problem att få tag i en. Döm så om min förvåning när jag anlände den lokala Mac-nasaren på Södermalm i Stockholm och fick höra att “Snow Leopard är slut”.

Slut? Hur tar en digital vara slut? Det går ju att kopiera den i oändlighet. Men här ser vi begränsningarna i påtvingad fysisk distribution av något som borde vara digitalt. Det finns ingen brist på DVD-material i världen, så en brist på installationsskivor borde vara rent logistiskt framkallad, dvs antingen har Apple inte tillverkat tillräckligt många eller så har grossisten/återförsäljaren inte tillräckligt i lager för att täcka behovet.

Men varför är det så? Det handlar om en några gigabyte stor fil som ska distribueras. Man skulle kunna tänka sig att Apple sålde filen till mig och jag fick ladda ner den själv och bränna, så slapp man distributionen. Man skulle också kunna tänka sig att återförsäljaren har en egen brännare och får licens från Apple att bränna hur många skivor som helst,  bara de höll koll på antalet och betalade per skiva.

Antalet lösningar är många, men den allra sämsta lösningen måste vara den man har valt – att endast distribuera färdigtryckta skivor från en fabrik någonstans.

/M;

XBMC och Apple TV är som gjorda för varandra

Jag har skaffat en Apple TV. Det är en produkt som i sitt originalutförande är nästan helt meningslös i Sverige eftersom de tjänster som Apple har till (hyra eller köpa film och teveserier) inte finns i vårt land utan bara i USA.

Men länge leve hackare, för till ATV finns något så märkligt som en nedladdningsbart hackarprogram som man lägger på en USB-sticka, stoppar in i sin ATV och bootar om, och plötsligt kan man installera XBMC eller Boxee på burken och då blir den genast mycket, mycket roligare och mer användbar.

Programmet heter ATV bootloader och är helt gratis att ladda ner och använda. Det är näst intill idiotsäkert och lätt att använda, och det tar bara fem minuter så har man XBMC installerat på en liten nästan ljudlös burk som blir en perfekt mediaextender förutsatt att man har all sin media utdelad på nätverket med t.ex. SMB, NFS eller uPnP.

Apple TV har inbyggt trådlöst nätverk (802.11n) och ethernet, så det är lätt att ansluta till hemmanätverket oavsett metod.

XBMC är, kort sagt, den bästa mediacentermjukvaran som finns tillgänglig, och den går att köra under Windows, Linux, OS X och nu även Apple TV.

Med XBMC följer en mängd intressanta funktioner som t.ex. möjligheten att ange en FTP-server som mediakälla. Plötsligt kan man bläddra på en FTP-server och titta på teve direkt strömmande, utan problem (förutsatt att det finns bandbredd nog förstås). Det finns även möjlighet att prenumerera på video-poddcaster, spela upp MP3 eller annan musik, se foton/bilder, etc, etc.

För oss blev detta en perfekt lösning för sovrummet. Förut har jag haft en lång videokabel genom hela lägenheten för att kunna titta på video från vår Mac Mini som står i vardagsrummet, men nu är det trådlös video som gäller. Smidigt!

/M;

Minirecension: Digiality Remote Extender

digiality.jpg

Efter att ha stuvat om lite i tevebänken och skaffat lite ny hårdvara fick jag problem med att styra mina enheter från sovrummet, eftersom alla fjärrkontroller använder IR och därför inte fungerar runt hörn eller genom väggar.

Därför fick jag bege mig till Kjell & Co och köpa denna märkliga pryl.

Det är en mottagarenhet, med IR-sändare och sen en liten, liten sändare som gömmer sig inne i ett AAA-batteri (adapter för AA medföljer). Den lilla sändaren har ett laddbart batteri (laddas i mottagaren!) och ersätter helt enkelt ett av de batterier man har i sin vanliga IR-fjärrkontroll. Det som händer är att den lilla sändaren på något magiskt vis läser av RF-frekvensen när man trycker på en knapp på sin fjärr, skickar den som radiovågor, RF, genom väggar, luft, tak och annat – fram till mottagaren. Mottagaren översätter sen signalen tillbaka till IR, och med det medföljande lilla ögat med lång sladd på är det lätt att styra vilken/vilka apparater som helst.

Jag satte sändaren i min multifjärrkontroll och plötsligt är ALLA mina enheter i tevebänken möjliga att styra från sovrummet, om jag nu skulle vilja.

Det hela funkar långt över förväntan bra, och det enda märkliga med apparaten är att det verkar bli nån slags konflikt om man står framför den apparat man försöker styra och trycker på fjärrkontrollen. Det verkar som att om apparaten kan ta emot signalen både direkt från fjärrkontrollen, som IR, och sen får signalen en gång till, denna gång från Digiality-mottagaren, så händer – inget.

Lösningen är att antingen tejpa för IR-sändaren på fjärrkontrollen, eller helt enkelt hålla handen för, så att apparaten i fråga inte kan “se” fjärrkontrollen, utan bara får signalen en gång – från mottagarenheten.

Sammantaget är jag mer än nöjd med funktionen och det enda man kunde önska sig vore kanske att paketet skulle vara något billigare.

/M;

Minirecension: iPhone sämre än förväntat

Så har jag då äntligen fått en iPhone. Direktimporterad från USA, snabbt upplåst, jailbreakad och aktiverad med hjälp av ett litet program till OS X. Hur enkelt som helst. Förpackningen var precis så het som bara Apple kan göra den, och telefonen är snygg, menyerna är snabba och smidiga och skärmen är riktigt skarp och trevlig.

Redan tidigare visste jag ju att iPhonen saknar många viktiga funktioner, såsom MMS och 3G-stöd, men det visade sig snabbt att det är flera viktiga funktioner som fattas, och även denna gång är det obegripligt varför Apple valt att göra en telefon som skiljer sig från vad som måste kallas branschstandard.

1. Det går inte att synka telefonen trådlöst med OS X med hjälp av iSync. Det går inte att synka telefonen alls med iSync. Synkningen sker via iTunes istället. Varför? Apple – ni har ju ett program som är gjort för att synka telefoner! iPhone har ju Bluetooth! Varför i hela friden måste jag då ansluta min iPhone med en SLADD för att synka? Det känns fruktansvärt omodernt.

2. Det går inte att ansluta till iPhone med Bluetooth för att skicka/ta emot bilder, ljud eller andra filer. ?terigen – OS X har överlägsna funktioner för Bluetooth när det gäller att ansluta till t.ex. SonyEricsson-mobiler – varför har Apple valt att inte använda dessa till sin egen telefon? Dessutom funkar inte BluePhone Elite som jag använde till alla gamla telefoner jag haft för att läsa/skicka SMS från datorn. Bu!

3. Tangentbordsfunktionen med touchscreen funkar inte så bra. Nu har jag visserligen bara haft min telefon i ett par dagar, men det är väldigt, väldigt svårt att skriva nåt på telefonen, och glöm att göra det med en hand. Det är tvåhandsfattning som gäller, och dessutom är det näst intill omöjligt att skriva t.ex. SMS eller e-mail medan man går, vilket jag snabbt upptäckte är väldigt opraktiskt.

4. Ljudkvaliteten under telefonsamtal är under all kritik! Nu vet jag inte om jag fått ett måndagsexemplar, men jag har ofta rent av svårt att höra vad motparten säger när jag pratar i telefonen, så muffligt och dåligt är ljudet. De jag pratar med klagar dessutom också på att jag låter som att jag pratar i en plåtburk. Vad har hänt här?

Trots alla klagomål ovan är jag rätt nöjd med att ha en iPhone. Det är V?LDIGT smidigt att kunna läsa e-posten på riktigt och att kunna surfa med Safari (även om det går sjukt långsamt med GPRS) var man än är. Google Maps är jättesmidigt och praktiskt. Det finns många små program att ladda ner till en jailbreakad lur som t.ex. ger fungerande MMS-stöd.

/M;

Kriget är över – ingen vinner

Många medier rapporterar om att striden mellan Blu-ray och HD-DVD är över. Efter att Toshiba slutligen meddelat att man tänker frysa produktionen av HD-DVD-spelare, är Blu-ray segrare på walk-over. De stora mediebolagen, som ett efter ett hoppat över till Blu-ray är naturligtvis medskyldiga till att formatet äntligen standardiseras, så vi slipper välja vilken HD-spelare vi ska köpa till vår nya platt-teve när vi står där i butiken.

Men är det bara jag som tror att nästa strid redan pågår, och att utgången är självklar? Varför ska vi överhuvudtaget köpa filmer och teveprogram på dyra skivor när samma innehåll finns gratis på valfri torrent-sajt på nätet? Och vem, utom de mest inbitna och enervetiska samlarna och teknikfreaksen, vill lägga ytterligare ett format till sin samling?

Förutom diskussionen om huruvida det är moraliskt rätt eller lagligt att ladda ner film gratis från nätet istället för att betala för den, är den rent tekniska diskussionen intressant. Vi har en PC som mediecenter hemma. Det är otroligt mycket smidigare att spela upp film eller teveprogram från den burken än att stoppa in en DVD-skiva i en spelare, vänta flera minuter på att diverse menyer och varningstexter ska spelas upp, och sen välja rätt program eller filmklipp innan man kan börja titta. Det är redan så att jag hellre rippar barnprogram från de DVD vi har till mediaboxen så att vi enklare kan sätta på det program Leo vill titta på för tillfället.

Om jag vill köpa videor med Fem Myror eller Pippi Långstrump åt mina barn har jag fortfarande endast alternativet “dyr, fysisk media” att välja på. DVD-skivor som jag inte vill ha, med innehåll som jag själv måste rippa och koda om för att få det i ett format som jag vill använda. Det kommer självklart inte att hålla, och i takt med att människor blir mer och mer erfarna med nedladdning och det dessutom dyker upp fler och billigare mediecenter kommer plastbitens värde att försvinna. Det finns redan mängder av relativt billiga och snart också enkla små mediespelare som kopplas direkt till teven, där du lägger dina filer på en hårddisk och spelar upp dem direkt.
Så ?? även om Blu-ray för tillfället har vunnit kriget mot HD-DVD är nästa strid redan här, och den kommer att vara omöjlig för plastbitar att vinna.

/M;

Efficient dual caching of dynamic web content

Last Tuesday, I held a short presentation at the very first “Web Monday” held in Stockholm (don’t ask why it was on a Tuesday) about a technique I used at the site I run, arkadtorget.se. The cache method I implemented there was the result of a series of discussions I had with my very good friend Peter Svensson, who is the smartest scatterbrain in the county, if not the country, or the world.

Peter, who has recently become a Javascript wizard and evangelist, suggested that I solve a problem I had with heavy load on the MySQL server at Arkadtorget by implementing a client-side cache. Storing content in local Javascript variables in the web browser. I had already determined that I needed to build and implement a server-side cache using PHP to write the results of MySQL queries into text files that I could later read from instead of bugging MySQL about the data again just because another user wants to read the same forum thread that another one just did.

There are plenty of PHP caching solutions out there, most of them using a similar method of writing database results into text files. To use server-side caching is a very wise and good idea in general, for almost any web site with common database access. Usually, the method is used to cache complete web pages after they have been rendered by a CMS or other web system. The complete resulting HTML from a complex series of PHP-parsing and database queries is stored in a text file on the server before being sent to the web browser. The next time a client requests the very same page (usually determined by the URL/query string used to access the content) the server can return the contents of the text file instead of again parsing PHP and making several database queries.

I use my cache methods mostly to cache parts of pages that I know are difficult for PHP/MySQL to render. This is often lists, tables of different kinds and simple counters or searches that are repeated a lot, but where the data does not neccessarily need to be 100% fresh. (What if it does need to be 100% pristine, fresh and healthy-smelling? More about that later.) In fact, sometimes I use server-side cache to store many parts of a page, separately and modularized, so that the same module (say, a sidebar navigation or statistics used in many different places on a site) can be called upon an unlimited amount of times without asking the database to check its rows more than once ?? i.e. the first time the content is rendered, and subsequently cached.

Now, since we are talking about tables and lists, I have made an observation regarding user behaviour and pagination. After logging every click a user makes on a paginated list of results, I noticed that the very pagination itself seems to encourage “flipping” back and forth between pages of results. I even started noticing myself doing it. I’d make a web search on Google, scan page one of results, click to page two, maybe to page three and then think “what was that third link on page one?” and flipping back to page one, checking it before flipping back to page three again and then on to four, and so on.

What’s going on here? In my logs, I could see that as many as 33% of the requested pages were pages I had already sent to the browser, during the same session! (Note, this is at a local, Swedish-language forum full of tech/arcade nerds – YMMV) Even if I have used on of the common cache methods in PHP to store the forum pages in a text file on the server, the client will ask the server for updates on every page, and with even low latency and a properly working cache, there will be plenty of requests sent from the client to the web server for changed graphics, included files, etc. (Most of which are preventable if you have set your expires headers correctly! More on this in another post.)

Now, I was already planning to migrate the forum to an AJAX-powered fetching method, but even using AJAX to get the contents of the forum, I would have to ask the backend for the same code, over and over in up to 33% of the time! This is where my friend Peter had the idea to circumvent the extra round trips to the web server by storing the HTML needed to print the pages in a local JS variable.

Simple, elegant, yet powerful. Every time a user requests a page he has not previously viewed I ask the AJAX backend (built with PHP) for the HTML-code needed to print the page. The PHP code will use the server-side cache method to make sure that the database will not have to bother with presenting content for the page, if it has been loaded before, and send the HTML-code ?? from text file cache or not ?? to the client. The browser, upon receiving this content for the first time, displays it for the user to read, but also quietly stores the entire page of data in a Javascript variable. If the user ends up going to page two and then wants page one again (“flipping” as it were) we can check to see if page one is already present in the local cache, and serve up the content of the Javascript variable straight, on the rocks, without even checking with the server to see what time of day it is! It’s a beautful solution, especially since the users who are doing the “flipping” notice nothing, except that a page they already visited before is loading instantly, without any noticable delay.
In fact, why stop there? I made some changes to make sure that the user experience is even more smooth by telling my AJAX backend to let the browser know whether the next page in the result set is available as server-cached content (I don’t want to bother the database if I don’t have to ?? I don’t know that the user is actually going to ask for the next page) and if it is, the browser will then proceed to load the next page of results straight into the local Javascript variable. The user sees and notices nothing of this, except if he clicks the next page, in which case I can now present that content instantaneously, without asking the server “hey, hand me page two ?? stat!”.

OK, so what was actually gained here? First of all, the user experience is greatly improved. The dual caching method makes this forum seem fast as lightning, most of the time. Secondly, the database can take a deep breath of relief, since I never have to ask it for content it’s already served up once.

Which brings us to the server-side cache, and its expiration methods. A common practice is to define a timeout, an interval of time during which the content will be considered fresh. When the predefined time is out, the content will be generated by asking the database the very next time it is requested by the user. This works great for content that doesn’t need to be 100% fresh, all the time. With a relatively conservative timeout, say 15 minutes, any content on the site is never more than 15 minutes old, even if it’s being read from the server cached text files. But what if 15 minutes is too long? In my case, I have a fairly active forum that needs caching, and 15 minutes is a very long time to wait between posting a message and actually showing it on the site.

We could, of course, delete the entire stock of stored text files containing the cached data every time a user posts in the forum. This would make sure that no cached content will be presented in case there is new data in the database. However, I don’t think that this is a very good idea in my case, because I have literally thousands of cached snippets (think hundreds of forum threads times tens and sometimes hundreds of pages) and deleting all of them would actually take some time for the server. Also, I am throwing the baby out with the bath water by deleting a lot of data that is not expired by a user posting in that very forum thread.

The answer is again, simple. Always make sure that you can back-reference a cache file with its content! A very common method for storing cache files on the server is using a hash (usually md5()) to make a unique filename for the content being cached. However, the drawback is that once you’ve md5()-ed, you can’t go back, since you can’t make potatoes out of fries or a cow from a hamburger. In my case, I decided on making up the file names of the cache files based on the content being cached. If I am caching forum 34, thread 34124 and page 2, the cache file is called “34-34124-2.cache”. Simple, no?

“But”, you say. “Having thousands of small text files on the server will make the request slow anyway, since the time the server needs to look up a file grows with the number of files in the same folder!”

Yes, it does. Have you ever made the mistake of not deleting session files in Apache after the session is expired? After a while, the web site will be extremely slow when Apache tries to locate your session file in a folder with a million files. My solution was to make a folder structured based on the md5() of the cache name, but using only the first two characters from the md5(). So, I currently have 235 folders storing the cache data, but I retained back-referencing!

This solution is so simple it could be used anywhere paged results are used. It costs next to nothing to implement (a little memory usage on the client, but unless you have pages of HTML using hundreds of kilobytes, this is of no concern) and there is no drawback to the method. Faster browsing, less traffic and load on the server is your reward.

Here is a tiny bit of example Javascript just to show what I am talking about:

[quickcode:noclick]function printThread(forumid, threadid, page) {
// Check for local cache first – pagesCached is an array of booleans,
// pageCache is an array of strings containing local cached content.
if (pagesCached[page] && pageCache[page].length > 10) {
alert(“From JS cache”); // We have a local cache!
// First, choose what div to write to
div = document.getElementById(“forumthread”);
// Next, set the innerHTML of that div to the content of local cache
div.innerHTML = pageCache[page];
// Now, if the next page in the result set is not
// already present in the local cache – go get it!
if (!pagesCached[(page+1)]) {
// Insert your own loading/caching code here
}
}
else {
alert(“From AJAX”);
// Go get the page from the server,
// but don’t forget to cache it locally afterwards!
}
}
[/quickcode]

/M;

Saitek A250 – en minirecension

Saitek A250

Jag vill ha min musik från datorn i vardagsrummet inne i köket. Det är ett avstånd på c:a 10 meter och två gipsväggar står emellan. Jag vill inte dra sladdar, jag vill ha musiken överförd trådlöst. Ska detta vara så svårt?

Ja tydligen.

Först provade jag en högtalare från Kjell & Company. Förutom att ljudkvaliteten inte var särskilt god blev det avbrott i musiken hela tiden. Särskilt när jag ställde mig i vägen mellan sändaren och högtalaren. Den fick åka tillbaka till Kjell.

Sedan köpte jag ett par högtalare från Teknikmagasinet. iZound hette de, och de finns av nån anledning inte på deras webbsida, utan bara i katalogen. Dessa lät också rätt risigt och hade samma problem som de från Kjell med att kunna spela musik utan avbrott. ?ven dessa fick åka tillbaka.

Till sist provade jag så en riktigt hiskeligt ful högtalare från Saitek. A250 heter modellen, och trots att de är så fula att mina ögon tåras varje gång jag går in i köket så funkar de faktiskt riktigt bra! Det är inget kraftigt ljud från dem, men ljudet är rent och klart och med relativt fyllig bas. Den lilla fina sändaren är USB endast, och trots att det står på kartongen och på sajten att den bara funkar med Windows funkade den utan problem även i OS X! Inga drivrutiner, OS X känner direkt igen den som ett externt ljudkort och det är bara att börja spela vad man vill till den.

Inga avbrott i musiken, digital (Bluetooth) överföring från sändaren till mottagaren och jag har äntligen hittat en lösning som funkar, även om den är så ful att jag är sugen på att ställa den i en papplåda för att gömma den. Fast då blir väl ljudet sämre.

Jag köpte den otroligt billigt på BRL, men den finns att beställa lite överallt, och jag rekommenderar den varmt. Fast nämnde jag att den är så ful att designkunniga över hela världen gråter för att den finns?

/M;