All nedladdning är inte fel

Dags att ännu en gång försöka röja det där missförståndet ur vägen. Erik Hedin, som presenterar sig som "trebarnspappa som startade och numera konceptutvecklar SVT Play (föräldraledig till maj 2013)", lyckades tidigare i dag skriva så här på Twitter:

Som ni ser länkar han till ett inlägg på diskussionsforumet, där jag förklarar varför SVT Plays nya strömmar inte ännu fungerar med Huggpunkt VHS.

När man lägger fritid på att utveckla lagliga alternativ till illegal fildelning är det en smula nedslående att kallas för TV-pirat, särskilt som jag aktivt tagit avstånd från piratkopiering, så jag känner ett visst behov av att svara. Visserligen har jag fortfarande ett Twitter-konto eller två och skulle kunna svara där, men saker som ryms i en tweet är sällan värda att säga alls, och om man ändå försöker ser man bara dum ut. (Att varenda kotte som sysslar med marknadsföring, media eller politik har Twitter är säkert helt icke-relaterat.)

Jag svarar här i stället. Någon som läser bloggen kan ju pinga honom, om det känns värt besväret.

Av framför allt tre skäl är Erik Hedins kviddevitt sannolikt sprunget ur häcken.

  1. Det här har ingenting med piratkopiering att göra.
  2. Problemet är inte nya SVT Play, utan de nya strömformaten.
  3. "TV-piraterna" har inga problem, utan det är vi andra.

Nedan förklarar jag mera ingående vad som ligger bakom de här tre punkterna.

1. Det har ingenting med piratkopiering att göra

De två program som foruminlägget Erik Hedin länkat till handlar om är Huggpunkt VHS och SVTPlay.sh.

(Jag nämner visserligen även PiratePlay i inlägget, som fyller ungefär samma funktioner, men vare sig jag eller inlägget har egentligen något med PiratePlay att göra. Detta utgår jag från att Erik Hedin förstått, eftersom han, precis som alla andra twittrare, aldrig skulle uttala sig utan att först ha satt sig in i ämnet.)

Grejen är att vare sig H.VHS eller SVTPlay.sh lär vara särskilt intressanta för personer som sysslar med illegal fildelning. De är helt enkelt vare sig nödvändiga eller särskilt smidiga i den typen av situationer. Detta förklaras kanske bäst genom att säga något om vilka programmens respektive syften och målgrupper faktiskt är.

SVTPlay.sh är ett skalskript som tillkommit för att SVT Play bara fungerar om man har Flash, vilket inte är någon självklarhet. Den första versionen av skriptet skrev jag för flera år sedan för att slippa allt krångel med HTML-kod varje gång jag ville se något program på datorn. Flash finns nämligen inte för OpenBSD, och jag har ingen lust att byta operativsystem bara för att komma åt public service-sändningar.1

Målgruppen är framför allt unix-användare. Skriptet har en närmast överdriven mängd parametrar för att kunna användas i så många olika situationer som möjligt, exempelvis plugin för webbläsare eller "smarta" TV-apparater.

Huggpunkt VHS har en helt annan målgrupp. Även om programmet ger åtkomst till videor på SVT Play och en handfull andra sajter även på plattformar utan Flash, så är huvudsyftet att göra nedladdning för privat bruk enkelt. Jag inser att det där med "privat bruk" låter litet suspekt, eftersom det är en fras som mellan varven missbrukas. Därför är det bäst att åtminstone ge några exempel på hur programmet faktiskt används:

  • Hämta program på datorn och föra över dem till exempelvis en iPad inför en längre bil- eller tågresa. Mobilnätet har inte perfekt täckning, särskilt inte på tåg.
  • Se program i bättre kvalitet än vad som går att strömma. Jag bor själv i en liten by och har inte bandbredd nog för de tjockaste strömmarna på SVT eller TV4 Play.
  • Spara program man vill se men inte har tid att se förrän de försvunnit från sajten.
  • Ladda ned program som bara visas i Sverige, för att någon närstående som bor i utlandet ska kunna se dem.

Samtliga användningsområden jag beskrivit ovan är lagliga. Det är inte frågan om att de är lagliga enbart för att ingen förbjudit dem, utan lagen är särskilt utformad för att sådana här användningsområden ska vara tillåtna. Syftet med den privatkopieringsersättning vi betalar ovanpå priset för olika datamedia är just att ersätta upphovsrättsinnehavare för sådan här nedladdning och kopiering för privat bruk.

De allra flesta som använder den här typen av program är bara intresserade av att se videorna utan att behöva strömma dem samtidigt, och lagen är utformad för att det ska vara tillåtet att använda sajterna på det sättet.

Därför har det här inte med piratkopiering att göra. Lättanvända och lagliga alternativ gör snarare att efterfrågan på piratkopior minskar. (Vilket väl är bra?)

2. Problemet är inte nya SVT Play utan strömformaten

Det inlägg i diskussionsforumet som Erik Hedin länkade till förklarar egentligen det mesta bakom den här punkten, men en sak är värd att tillägga: SVT Plays nya webbsajt, som lanserades i början av juni, är faktiskt mycket enklare att interagera programmatiskt med än den tidigare versionen.

Det är inte nya SVT Play som är problemet, utan Adobes och Apples nya strömformat. Problemet är dessutom inte formaten i sig, utan att öppen källkod-världen inte hunnit ifatt ännu.

Ska man tvunget ha något att klaga på SVT över, så är det i så fall att de använder Flash. Flash är dåligt och onödigt. Youtube har fungerat utan Flash rätt länge nu.

3. Det är inte "TV-piraterna" som har problem

Rent tekniskt finns det inga större hinder att kopiera videoströmmarna. Om man har tillräcklig kompetens och motivation att sprida videor på torrentsajter, så har man också tillräcklig kompetens och motivation att använda de krångligare lösningarna på nedladdningsproblemen.

I de fall där strömmarna inte direkt går att spara med AdobeHDS.php eller FFmpeg kan man helt sonika köra ett skärmfångstprogram som bara spelar in vad som visas på skärmen. Visserligen tar det litet längre tid, och man måste krångla en del för att inte få antingen gigantiska videofiler eller märkbart sämre kvalitet, men det är som sagt bara en fråga om motivation och kunnande. Och ingen tror väl att det där är två egenskaper som dem som lägger upp grejor på torrent-trackers saknar?

Piratkopierarna har alltså inte några större problem med SVT Play – eller någon av de andra Play-sajterna. I stället hamnar vi i slutändan (åter) i en situation där TV-programmen inte går att spara på de sätt som är lagliga, eller ens att se på vissa plattformar, men de finns på Pirate Bay.

Perfekt.

  1. Sveriges Radio ska för övrigt ha en eloge. När de för några år sedan lanserade sin nya sajt blev det krångligare för oss utan Flash, vilket jag skrev till dem om. De besvarade kritiken genom att göra det enklare än någonsin tidigare att komma åt mediaströmmarna. Det var lysande!

Exilen är över

Förra våren skaffade jag ny dator, eftersom den gamla helt enkelt var slutkörd. Tyvärr visade sig X11 och grafikkortet (ATI Mobility Radeon HD 4500) inte kunna komma överens, och med VESA gick det inte att få till något bättre än helt olidliga 1152x864 utsträckt till 16:9. För första gången sedan 2004 blev jag Windows-användare igen.

Men nu är det äntligen över. För någon vecka körde jag – som många gånger tidigare det senaste året – en sökning efter "radeon" över openbsd-cvs, och såg att bara några dagar tidigare hade default växlats över till en ny radeon-driver. Och visst fungerar det! Dessutom utan att behöva krångla med någon xorg.conf. (Enda kruxet verkar bli att jag tvingas följa current upp till OpenBSD 5.3, men det är jag åtminstone van vid.)

Så nu, äntligen, är exilen över. I några veckor framöver kommer jag kunna roa mig med att återuppväcka min gamla arbetsmiljö. Det ser ut att kunna bli en del jobb. Vissa knep fungerar inte längre, medan många skript behöver städas och anpassas till nya omständigheter. I takt med att den här hemflytten pågår ska jag försöka dokumentera de intressantare delarna här på bloggen.

Kan man jämföra OpenBSD och SELinux?

Jag har fått en fråga! Kurt undrar så här:

En säkerhetsfråga från en novis.

Vad jag förstår så bygger säkerheten i OPENBSD på att undvika säkerhetshål, så ingen kan komma in. Säkerheten i SELINUX bygger väl på principen att om någon kommer in kan de inte göra något elakt. Skulle man inte kunna kombinera principerna och implementera SELINUX i OPENBSD och därmed få ett supersäkert system?

Det korta svaret är: Nej.

Ett förtydligande tillägg lyder: Beskrivning av de båda projekten är inte riktigt riktig.

En längre utläggning följer. :-)

Jag tror båda projekten sysslar med både intrångssäkerhet och intern säkerhet i lika hög utsträckning. Däremot skiljer de sig från varandra på så vis att SELinux (nästan) bara är en åtkomstmodell, som så att säga "står i mitten" och försöker styra upp eventuella taskigt konstruerade program, medan OpenBSD är ett helt operativsystem (i ordets vidare bemärkelse).

OpenBSD innefattar till exempel varianter av GNU-kompilatorn och Apache-servern, och är »hemsystem« för både OpenSSH och sudo, och GCC-varianten som följer med har ett inbyggt skydd mot stack-smashing. SELinux omfattar däremot inte ens något skal, och än mindre någon kompilator, utan är en uppsättning patchar för Linux-kärnan.

Projekten är alltså inte helt jämförbara, eftersom SELinux bara är en modifikation av Linux-kärnan, medan OpenBSD är både en unik kärna och ett userland bestående av unika program (alltså ungefär en »distribution« på Linux-språk, fast en distribution där alla program kommer från samma källa istället för att ha plockats ihop från olika håll).

Vill man göra en ordentlig jämförelse, så bör det alltså vara mellan OpenBSD och en enskild Linux-distribution (till exempel Ubuntu, Fedora eller Slackware), inte mellan OpenBSD och Linux (vilket vore litet som att jämföra en päronplantage med ett mandelträd.)

Om vi ägnar en stund åt de områden där jämförelser ändå går att göra i någon mån, alltså sådana områden där projekten i en annan värld hade kunnat vara likadana, så finns det faktiskt flera väsentliga skillnader. Den säkerhetsmässigt mest avgörande tror jag är inställningen till användaren. OpenBSD bibehåller aktivt en viss inlärningströskel, och de flesta program som utgör ens en perifer säkerhetsrisk är inte aktiverade på en fräsch installation. Konfigurering sker därtill i regel på klassiskt vis, genom att man ändrar i textfiler, vilket i sin tur kräver att man läser de noggrant underhållna man-sidor som följer med systemet.

Inlärningströskeln gör att man måste lära sig en del om hur programmen fungerar för att få dem att bete sig som man vill, eller för att ens starta dem. Konsekvensen är (förhoppningsvis) mera upplysta användare och administratörer, vilket i grund och botten är vad all säkerhet går ut på, både intern och extern.

I rättvisans namn så är en sådan inriktning antagligen omöjlig att genomföra för SELinux. Projektets fokus är rent kodmässigt betydligt snävare, och svängrummet är därför mera begränsat. Kärnan har inget som helst inflytande över hur svåra eller lätta program är att administrera, hur säker programmens kod är, vad som körs och inte körs direkt efter en installation eller hur bra dokumentationen av programmen är. Däremot kan en kärna vara konstruerad så att den begränsar skadeverkningarna av dåliga program (vilket givetvis inte är förbehållet SELinux, utan gäller alla kärnor).

Att kombinera SELinux och OpenBSD är i praktiken omöjligt. Linux är rent kodmässigt en klon av Unix, medan BSD-systemen är direkta avkomlingar. BSD-systemen (däribland Darwin under OSX) har var sina egna kärnor, som liknar och delar viss kod med varandra, medan Linux-kärnan har en helt egen struktur och bygger på helt annan kod. BSD är alltså inte Linux, men Linux är (tillsammans med GNU-systemet som brukar följa med) ursprungligen skapat för att efterlikna BSD:s förfäder.

Linux-kärnan är dessutom GPL-licensierad, vilket gör det mycket svårt att använda kod därifrån i BSD-systemen, eftersom de i regel använder olika varianter på BSD-licensen. OpenBSD använder numera mestadels en ISC-licens, som i praktiken bara kräver att licenstexten och copyright-snutten lämnas orörda, och det endast i källkoden. Därför kan man hitta BSD-licensierad i helt sluten programvara, som Windows, marslandaren och en del routrar. GPL tillåter inte något sådant.

Den licensen kräver ju en hel del mer, bland annat att samma licens gäller alla ändringar och tillägg i koden, och att den alltid är tillgänglig till självkostnadspris för alla som har programmet. Om du infogar GPL-kod i ett BSD-licensierat program så måste hela programmet därefter distribueras enligt GPL-villkoren. Det är alltså inte omöjligt att infoga GPL-kod i BSD-licensierade program, men det är få BSD-utvecklare som vill, eftersom de tycker BSD-licensen passar dem bättre.

Om man däremot tar BSD-kod och placerar i GPL-program, så uppstår inga problem förrän någon får lust att hämta tillbaka eventuella förbättringar i koden till ett BSD-program; detta är omöjligt utan att hela programmet blir GPL-licensierat istället. På så vis är BSD-licensen alltid den »svagare« i relation till GPL.

Men som tur är, så tror jag det vore onödigt att kombinera själva idéerna i SELinux med OpenBSD-kärnan. Jag vågar inte påstå att det vore ett säkerhetsmässigt nerköp för OpenBSD, men det skulle nog inte heller tillföra något väsentligt. Ibland talas det om att den mera flexibla filåtkomst-modellen som SELinux implementerar skulle vara en fördel i OpenBSD, men i praktiken kan man uppnå samma effekt med den för Unix-system traditionella åtkomstmodell som OpenBSD använder. En fördel med den traditionella modellen är att den är lättare att förstå sig på och överblicka.

Jag hoppas det här duger som svar på frågan. Dessutom kostar jag på mig brasklappen att jag inte är någon »säkerhetsexpert«, vare sig i betydelsen white hat, eller på så vis att jag försörjer mig genom att varna för internetmaskar åt något antivirusföretag. ;-)

Däremot är jag intresserad sedan flera år tillbaka. Kritiska eller utvecklande kommentarer är med andra ord (också) välkomna!