metanohi/site/misc/stadig-digital-sikring.org

#+title: Stadig digital sikring mod gennemførsel af eksamen
#&summary
A text about the continuing failings of digital education and "copy
protection". In Danish.
#&
#+license: wtfpl
#+language: da

Jeg sendte denne besked til Undervisningsministeriet som så forklarede at de
var nødt til at bruge kopisikring fordi de brugte tekst, billeder og video fra
eksterne kilder (såsom BBC). Det må være muligt for dem at lave bedre aftaler i
deres kraft af undervisningsministerium --- desuden er det ikke engang alle
skoler der bruger de kopisikrede cd'er, så i flere tilfælde er kopisikring
ligegyldig. Så fjern den dog!

Sendt 31. maj 2011. Se også <@eval macros.titlelink('digital-sikring')@>.

* Stadig digital sikring mod gennemførsel af eksamen

Hej UVM

D. 8. marts sendte jeg jer en klage/ideer-til-forbedring-e-mail ved navn
"Digital sikring mod gennemførsel af eksamen en realitet" hvor jeg
forklarede jer at kopisikringer på cd'er forhindrede min computer, som
kører styresystemet GNU/Linux i stedet for fx Microsoft Windows eller
Apple Mac OS X, i at læse teksten på cd'en til skriftlig engelsk
terminsprøve (skriftlig engelsk eksamen 2010): videoklippene var
tilgængelige i filsystemet, men teksten var der ikke. I skrev tilbage at
I arbejdede på at det også skulle virke på GNU/Linux og at der
sandsynligvis ikke ville være nogle problemer ved eksamen --- hvilket
der så var. I går til skriftlig engelsk eksamen blev jeg endnu en gang
ramt af cd-krypteringen, og kun skolens beredskab med en usb-stick
reddede mig. Jeg kan acceptere at i sender cd'er ud, men vil I ikke nok
lad være med at kopisikre dem? Det er både bedre og nemmere at lave
ukrypterede cd'er.

Jeg ved ikke om dette er den rette kanal, men jeg vil lige beskrive mit
problem på en teknisk måde og bevise min påstand om kopisikringen:

Først og fremmest: kravet til en computer til en skriftlig engelsk
eksamen bør være at den understøtter basale standarder inden for tekst,
lyd, video og, da I har valgt at bruge et webinterface, webteknologier
såsom HTML, CSS og JavaScript. Dette betyder at computeren og det
operativsystem der kører på den, skal have support for læsning af
HTML-tekst m. CSS og JS der følger en HTML-standard, og systemet skal
kunne dekode og afspille lyd og video der er gemt i standardiserede
formater. Dette er alt. Man bør ikke stille flere krav.

GNU/Linux understøtter alle disse nødvendige standarder. Det samme kan
ikke helt siges om MS Windows og Apple Mac, men det er muligt at få dem
til at understøtte de få nødvendige standarder relativt nemt (selv om
det er nemmere bare at skifte til GNU/Linux).

Men hvilke lyd- og videostandarder? Jeg undersøgte den videofil der
fulgte med dette års eksamensoplæg, og jeg så at den brugte VP6 til
video og MP3 til lyd. Disse to codecs er begge patenterede, og VP6 er
tilmed proprietært. Dette betyder at folk ikke bare kan lave et nyt lyd-
eller videoformat uden først at undersøge om bare en lillebitte del af
deres format er en del af VP6, for hvis det er tilfældet, er der
retssager og pengekrav. Softwarepatenter kan stoppe nogle vakse
mennesker med at udvikle nye, revolutionerende computerprogrammer,
algoritmer og digitale multimedieformater. Indrømmet, dette er kun
direkte et problem i lande hvor softwarepatenter eksisterer, men i VP6's
tilfælde er det samtidig også svært at implementere en dekoder da en
fuld formatspecifikation med vilje ikke er gjort tilgængelig. Når folk
bliver ved med at bruge disse patenterede formater, kan virksomheder
føle sig tvunget til at bruge de samme formater, og de frie, bedre
formater bliver usynlige. Så selv om EU og Danmark heldigvis ikke har
softwarepatenter, bør vi stadig ikke bruger patenterede formater som VP6
og MP3. Nogle hårdtarbejdene frivillige har sørget for at der er frie
dekodere tilgængelige for VP6 og MP3, så jeg kunne godt se videoen ---
det er bare ikke pointen. Formater man ikke kan kontrollere --- formater
der bliver kontrolleret af en privat organisation --- bør ikke bruges,
så digitalopfindere ikke begrænses af magtbaserede love.

Alternativet er formater som Ogg Theora eller VP8 for video og Ogg
Vorbis, Ogg Speex eller FLAC for lyd. Funktionelt set er disse lige så
gode --- eller bedre --- som fx VP6 og MP3, og samtidig er de frie. WebM
er en ny "container" der består af VP8 for video og Vorbis for lyd. Den
er nem at bruge i webbrowsere, og selv YouTube er begyndt at understøtte
den.

Hvis man brugte WebM men stadig ville gøre det muligt for computere uden
flere formater. Det har HTML5 fint support for. Og hvis ens browser ikke
understøtter HTML5 --- hvilket er helt ok --- kan man have en Java
fallback-player (ikke Flash).

Og nu til beviset at cd'en var kopisikret: På en brændt cd er der rå
data. Denne rå data kan læses hvis man har en cd-læser. Den rå data er
den samme uafhængigt af operativsystem, for det samme bliver læst. Den
rå data kan dekodes som et filsystem hvor den rå data oversættes til
filer og mapper. Både Mac, Windows og GNU/Linux kan læse filsystemet på
cd'en, men på GNU/Linux læses ikke hele filsystemet. På GNU/Linux er det
let at læse den rå data, så jeg lavede en undersøgelse. Jeg kiggede den
rå data igennem for de filnavne GNU/Linux kunne dekode fra cd'en samt
det indhold der var i filerne. Cd'en burde bruge et simpelt
ISO9660-filsystem, så filnavnene og filindholdene burde bare være
direkte læselige, hvilket de også var. Derefter forsøgte jeg samme
søgemetode med nogle af de nye filer der var på den usb-stick jeg havde
fået udleveret: Jeg fandt intet indhold. Alt det jeg ikke fandt må altså
være krypteret på en eller anden Windows- og Mac-venlig måde. Der er
ingen grund til at kryptere det.

Dette er de rodmapper og -filer (efter media/) som jeg har adgang til på
den krypterede cd:

: error.html files/ index.html loading.html xit!.html

Dette er de mapper og filer jeg har adgang til hvis jeg kunne dekryptere
cd'en (data fra usb-stick):

: data/ files/ flashplayer/ images/ index.html js/ styles/ xit!.html

Som eksempel på min filsystemssøgning kan vi tage filen 'index.html' som
var i den ukrypterede del af cd'en, og filen 'data/uvmXml.xml' som jeg
ikke kunne læse fra cd'en.

Filen 'index.html' eksisterer:

: $ grep -i index.htm engeks11cd.iso
: Binary file engeks11cd.iso matches

Og indholdet eksisterer også ('<body
onload="UVM.view.funcFitToScreen()">' er unikt nok til kun at forekomme
i 'index.html'):

: $ grep '<body onload="UVM.view.funcFitToScreen()">' engeks11cd.iso
: Binary file engeks11cd.iso matches

Vi ser at 'uvmXml.xml' faktisk også eksisterer:

: $ grep -i uvmXml.xml engeks11cd.iso
: Binary file engeks11cd.iso matches

Men hvad med dens indhold? Fra usb-sticken ved jeg at 'uvmXml.xml' har
mange '<CONTENT>'-tags. Så:

: $ grep -i '<CONTENT>' engeks11cd.iso
: $ echo $?
: 1

Indholdet i 'uvmXml.xml' er altså ikke tilgængeligt uden dekryptering.

Og så lige en anden teknisk ting: Jeg vil ikke blande mig så meget i
jeres måde at lave webinterfacet på, men er JavaScript virkelig
nødvendigt? Det føles som overkill at bruge jsQuery til at hente data
fra en XML-fil og så servere det som HTML. I oplægget fra skriftlig
engelsk 2010 var de forskellige ting pænt delt op i separate HTML-filer
uden voldsomt brug af scripting. Der er sikkert nogle få elever der har
slået JavaScript fra i deres browsere, så det er bedst at holde det
simpelt.



Nå, bortset fra det var årets stilemne godt.


Relevante links:

+ [[http://gnu.org/]]
+ [[http://fsf.org/]]
+ [[http://webmproject.org/]]
+ [[http://xiph.org/]]
+ [[http://theora.org/cortado/]]
+ [[http://w3.org/]]
+ [[http://w3.org/TR/html5/video.html]]


V.h. Niels Serup 3. E, HTX Hillerød (snart student)[fn:done]


[fn:done] Jeg blev student i juni.