7.7 KiB
Stadig digital sikring mod gennemførsel af eksamen
#&summary A text about the continuing failings of digital education and "copy protection". In Danish. #&
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. Se også <@eval macros.titlelink('digital-sikring')@>.
Stadig digital sikring mod gennemførsel af eksamen
Hej UVM
-
- 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)1
Jeg blev student i juni.