Studiebloggen header 3

Må studerende rette fejl i universitetets software?

Der er mange fagområder i erhvervslivet, der kan løftes og effektiviseres ved at introducere nye værktøjer. Det samme gælder for visse universitetskurser; der er sågar nogle kurser der ikke ville være praktisk mulige hvis ikke de var understøttet af et værktøj. Det ville fx være ret problematisk at arbejde med billedanalyse eller statistiske modeller uden et værktøj, til at bearbejde billederne eller større datamængder.

tl;dr (tilføjet d. 27/10 10:00)

Til dig der har travlt: Jeg ønsker at påpege et generelt problem, ikke pege fingre af bestemte systemer. Min pointe er at man kunne vælge at udvikle et universitets undervisningsværktøjer i open source projekter, fordi de studerende der bruger værktøjerne kunne have lyst til at rette de fejl der irriterer dem. Jeg tror at man ved en officiel udmelding med vejledning og ressourcer, fra et universitet til sine ansatte og studerende kunne sikre muligheden for at vi får fornuftige værktøjer og en mulighed for at rette de problemer der generer os.

Det første værktøj

Jeg blev i begyndelsen af dette semester introduceret til et værktøj, der skulle hjælpe de studerende med at strukturere deres projektarbejde; et domænespecifikt værktøj, som blev indført til netop dette kursus, og som var egen-udviklet af en kandidatstuderende til formålet. Da jeg kørte versionen til Linux på min maskine fik jeg en fejl med et tracedump i en log-fil.

Jeg kontaktede den kursusansvarlige fordi jeg ville hjælpe med at rette fejlen, men blev sat på plads af professoren med følgende ord: “There will be no on-the-fly fixes since we are a University here, not a software product company (just in case you haven't noticed).

Et andet værktøj

Vi blev efterfølgende introduceret til endnu et egen-udviklet system - denne gang web-baseret. Fra URL'en blev frigivet i forelæsningslokalet gik der blot et kvarter til programmøren bag systemet, en kandidatstuderende, havde fået tilsendt en mail fra en kursusdeltager med følgende ord:

Hi,
 
As we discussed in the class, there are some issues with the
security of the system. We would be happy help secure it to
make sure noone can mess with it :)
 
define("DB_SERVER", "localhost");
define("DB_USER", "root");
define("DB_PASS", "her-stod-koden");
define("DB_NAME", "4tt!l4-w4s-h3r3");
 
Cheers,

Dette og professorens irettesættelse fik mig til at gruble. Kan det først og fremmest passe at et universitet ikke producerer software? Og hvis ikke, ville det så ikke være smart at tillade os studerende at hjælpe til med at rette fejlene i de værktøjer, som vi bliver mere eller mindre tvunget til at bruge i forbindelse med undervisningen?

DTU står ikke alene med problemet

Sidste ugens it-profil Ken Friis Larsen artikulerer ret godt sine frustrationer om de administrative systemer, der omgiver ham på DIKU (Datalogisk Insitut ved Københavns Universitet):

De fleste af dem kunne være lærebogseksempler på, hvor galt det kan gå, lige fra horrible brugergrænseflader, hen over eklatante sikkerhedshuller til arkitekturbeslutninger, der er så håbløst forkerte, at det skinner igennem til brugerne.” og fortsætter i en kommentar under artiklen:

Jeg ser bestemt Universiteterne som software-producerende organisationer, historisk set har universiteterne fx bidraget stærkt til mange Open Source projekter. [...] Men det er fx frustrerende at give en indledende forelæsning i indledende websecurity, og ikke en gang nå tilbage til sit kontor efter forelæsningen før man modtager den første email fra en studerende hvor de spørger om det virkeligt kan passe at der er i sikkerhedshul i det ene eller det andet system der bliver brugt til undervisningen. Det er jo ellers en åbenlys mulighed for at vise de studerende hvordan et veldesignet system kunne være, i stedet står vi bare og ser uprofessionelle ud over for de studerende.

Konfrontationen

Da jeg i en pause i en forelæsning konfronterede min professor med idéen om at bidrage til at rette fejlene i begge systemer, fik jeg at vide at det ikke var muligt at give os adgang til kildekoden. Universitetets administration er generelt meget insisterende i forhold til at forsvare ejendomsretten til de produkter universitetet producerer, lød det. Efter hans overbevisning inkluderede det den føromtalte software.

Hvis dette er rigtigt, synes jeg for alvor at der er noget galt. Det giver ingen mening for et universitet at fastholde ophavsretten til et system med så mange fejl og mangler, at det alligevel ikke kan kommercialiseres.

Det minder mig om det klassiske spørgsmål man stiller til iværksættere når de overvejer at tage imod risikovillig kapital: "Vil du have en hel muffin eller et stykke af en kæmpe kage?". I dette tilfælde sidder universitetet med en muffin der er gået lidt over holdbarhedsdatoen og siger nej til at de studerende bager en bedre kage til dem.

Administrationens svar

Jeg blev nødt til at blive klogere, så jeg tog kontakt til administrationen på DTU. Her fik jeg en god snak med Francis Romstad, der til dagligt hjælper universitetets forskere med at anvende deres resultater kommercielt. Her var sagen klar: Han bekymrede sig mest om den kommercielle udnyttelsen af patenter og opfindelser der kunne patenteres.

Selvom ophavsretten til et værk, fremstillet af en ansat forsker eller ph.d. studerende ved universitetet, tilhører universitetet, så har han ingen umiddelbar grund til, at man ikke kunne open source offentliggøre kildekoden til et værktøj der blev fremstiller til et kursus.

Omend systemerne var underlagt universitetets ophavsret - hvilke ikke er tilfældet eftersom de begge er produkter af en studerendes arbejde og ikke af en ansat forsker - *ville alle så ikke vinde ved at lade projekterne frigives under en open-source licens? *Det ville tillade de studerende og undervisere fra andre kurser muligheden for at rette de fejl, mangler og sikkerhedshuller som værktøjet har.

Men hvad gik galt?

Jeg tror at underviserene ved universitetet mangler en klar udmelding fra administrationen. Helst en åben tilkendegivelse af, at hvis man som forsker eller studerende fremstiller et værktøj, så er det velset af det offentliggøres under en open source licens. Jeg mener at det bør være en officiel bestræbelse for universiteter som DTU (med dertil hørende ressourcer og vejledning), at universitetets egenproducerede software forbedres som open-source, uanset om universitet kan indse at de producerer software eller ej?

Det er i denne sammenhæng interessant at læse DTU’s officielle IT politik, der dikterer at “DTU’s IT-anvendelse bør gøre brug af den viden om IT og IT-forskning, der findes og udvikles i DTU’s forskningsmiljøer”. Det kan være meget svært at praktisere dette, hvis man ikke kan indgå i en åben dialog omkring systemernes design og kildekode.

Hvis jeg blæser den helt op og sætter den på spidsen kunne dette sågar inspirere til en udvidet version af den statslige digitaliseringsstrategi, som et redskab til at opnå at “universiteterne skal være digitale fra optagelse til eksamensbevis”.

Relateret indhold

Kræn Hansens billede
Kræn er uddannet civilingeniør i informationsteknologi fra DTU. Han er medejer, rådgiver og udvikler i virksomheden Socialsquare, hvor han hjælper organisationer med at bruge open source løsninger hvor det giver mening. Kræn blogger om open source, IT-sikkerhed og livet som iværksætter.

Kommentarer (26)

Kommentarer (26)
David Askirk Fotel

Hvis dette er rigtigt, synes jeg for alvor at der er noget galt. Det giver ingen mening for et universitet at fastholde ophavsretten til et system med så mange fejl og mangler, at det alligevel ikke kan kommercialiseres.

Se det er jo det. Der er en del produkter der bliver lavet med lige så store hvis ikke størrere fejl i. Så der er ikke noget der stopper universiteterne i at sælge produktet, selvom det er fyldt med sådanne fejl.

Oleksandr Shturmov

"There will be no on-the-fly fixes since we are a University here, not a software product company (just in case you haven't noticed)."

Det lyder som et svar fra en IT administrator i en stor til mellemstor softwareudviklingsfirma. De har en process, en beslutningshierarki, mm. Samme gælder egentlig universiteter, men man ville tro at underviseren var mere tilbøjelig med et hjemmebrygget system.

Problemmet med beslutningshierarkiet hos KU er at softwaren nemlig ikke er hjemmebrygget, så alle henveldelser om de utællelige sikkerheds- og logikfejl skal til et softwarehus der lige så sjældent har interesse i at lave fixes "on-the-fly", eller endda efter et par udviklingscykler.

Jacob Christian Munch-Andersen

...findes fordi folk er ligeglade. Det har ikke noget specielt med universiteter at gøre. At fortælle folk om deres sikkerhedshuller har i bedste fald ingen effekt, i værste fald bliver man meldt til politiet.

Du kan lige så godt lade være, basale SQL injektioner og lignende er altovervejende et udtryk for at ejeren er fuldstændig ligeglad.

Mark Gray

Kræn, jeg er 100% enig med dig. Vi har samme udfordringer på ITU, hvor vi også gerne så en større inddragelse af studerende i udarbejdelse af forskellige systemer.

Vi har ikke modtaget den helt samme afvisning som du lyder til at have gjort. Alligevel er der tydeligt nogle manglende rammer og principper på hvordan dette skal gøres, hvorfor jeg heller ikke kan pege nogle studenterudviklede systemer som bruges generelt på ITU.

Et par eksempler: Nogle studerende tilknyttet ITU Innovators var trætte af de lærings- og online samarbejdssytemer ITU tilbød og ville derfor se på at lave et nyt dashboard-system. Af forskellige årsager kom de ikke så langt med det før det blev droppet. De nåede dog at afholde en del møder med ITU administrationen som var meget glade for initiativet og jeg tror mange af de forslag som de studerende kom med blev ført videre i de officielle planer for udvikling af systemer på ITU.

Et andet eksempel var en kammerat som ville lave en app med kursus- og lokaleinformationer til de studerende. Dette er data som ikke er frit tilgængelig for andre end folk med en ITU-email. Der var meget lidt samarbejdsvillighed fra adminstrationen til at åbne op for dette data, heller ikke under kontrollerede forhold, som f.eks. web services. Resultatet? Forsøg på at crawle data, men jeg tror appen blev droppet til sidst (det var jo nok ikke helt lovligt jo).

Et sidste eksempel er faktisk mere positivt, men viser et andet problem. ITU er det eneste danske universitet hvor der ikke stemmes elektronisk til universitetsvalg. Jeg har i noget tid arbejdet på at få dette gjort muligt, men der var en del modstand fra adminstrationens side. De kunne ikke se fordelene, men de omkostninger der var forbundet med udvikling og idriftsætning var meget tydelige. Til min store overraskelse blev det dog foreslået om jeg ikke kunne finde nogle studerende som ville udvikle det som en del af et semesterprojekt.

Desværre lykkedes dette ikke, hvilket peger på et andet problem: Hvordan udnytter vi de interesser, ideer og resourcer som de studerende har til at løse de problemer som universitet har. Det er et spørgsmål at matche gode ideer med gode studerende og derfor synes jeg arbejdet skal ligge i at skabe nogle gode rammer og principper.

Jesper Lund

Selvom ophavsretten til et værk, fremstillet af en ansat forsker eller ph.d. studerende ved universitetet, tilhører universitetet, så har han ingen umiddelbar grund til, at man ikke kunne open source offentliggøre kildekoden til et værktøj der blev fremstiller til et kursus.

Dette er generelt ikke korrekt. Som udgangspunkt tilhører ophavsretten ophavsmanden (skaberen af værket), medmindre der er aftale en overdragelse. Universitetsansatte forskere har ikke indgået en sådan aftale, så de har ophavsretten til deres manuskripter, undervisningsnotater, og hvad de ellers producerer.

Der dog § 59 som giver arbejdsgiveren ophavsretten til et edb-program som er frembragt i en ansættelsesforhold. Men der er formentlig ikke ret mange forskere eller undervisere som beskæftiger sig med udvikling af edb-programmer i en sådan grad at § 59 bliver relevant.

Patenter er en anden sag, men software kan jo ikke patenteres i Danmark. Endnu.. ;-)

Torben Mogensen Blogger

Jeg har ofte tænkt, at det ville være oplagt for KU at tage datalogistuderende i praktikophold i IT-afdelingen (KIT) for at løse nogle af de problemer, der vitterlig er med den software, som KU faktisk selv kan gøre noget ved (modsat Absalon og andet, som er leveret udefra). Men universitetets regler forbyder studerende at lave praktikprojekter på KU -- det skal være hos virksomheder eller institutioner udenfor KU. Efter min mening forhindrer denne meget firkantede regel udnyttelse af en gratis ressource, som kunne gøre en forskel.

Lars Tørnes Hansen

... for mange år siden (i 2004).

Jeg gik på et kursus, hvor der blev lagt noget materiale op på en webside.

Den webside havde dog noget horribelt dårligt skrevet javascript der producerede ukorrekt HTML at en af de ældre studerende havde lavet en oversætter kun til at oversætte denne ene side til korrekt HTML (uden javascript).

Alle studerende på det kursus, incl instruktor brugte det program.

Jens Dalsgaard Nielsen

Jeg tror desværre ikke du har ret. Som ansat er du ansat til at udføre et stykke arbejde for din arbejdsgiver.
På AAU er regelsættet er AAU er bestemmende indenfor et år om hvis og i så fald de vil udnytte det du har lavet. Hvis de mister interessen efter et år får du rettighederne.
Dette gælder OGSÅ det du har udviklet i din fritid. Altså hvis du er rumskibsingeniør og laver noget smart til rumskibe derhjemme i weekenden vil AAU påberåbe sig at det er deres. Årsagen er bla ukontrollerbar arbejdstid osv.

Jesper Lund
Silas Ørting

Jeg er næsten færdig med et "Selvstudium under vejledning" projekt hvor jeg har arbejdet med nogle CT scanninger. For at få adgang til data skulle jeg underskrive en aftale der bla gav KU og en privat partner ekslusive rettigheder til den kode jeg skrev.

For mig at se burde KUs, og andre universiteters, forskning og produktion være så åben som muligt. Det er ikke universiteternes opgave at sikre patenter til forskere og virksomheder, men at øge samfundets viden gennem forskning og uddannelse. Det handler ikke om at undgå samarbejde med private virksomheder, men om at undgå at sætte kunstige barrierer op for udvikling.

Et andet problem ved at "lukke" universiteterne er at man som studerende ikke kan være sikker på at projekter og evt kode kan bruges til at søge arbejde.

Et interessant projekt kunne være at lave en fælles platform for fjernundervisning, optimalt skulle det være så materiale fra andre universiteter problemfrit kunne bruges i undervisningen. Med lidt kreativitet kunne det sikkert laves som en kombination af "selvstudium" og bachelor projekter, selvfølgelig med deltagere fra flest muligt universiteter og fag.

Kai Birger Nielsen

Datalogi i Aarhus har en meeeget lang tradition for at ansætte studenter som programmører til at kode systemer til brug i undervisningen. Godt nok har AU nu samlet alt "koncern-IT"-agtigt i en centralt styret organisation (der sidder jeg fx :-) men der er stadig masser af forskningsprojekter og eksternt finansierede projekter, der bruger den model. Bemærk at det ikke er de "gratis ressourcer" i de studerende, der bliver udnyttet (for de bør bruge tiden på studieaktiviteter), medmindre de er meget vedholdende (jeg erindrer en app til at slå medarbejdere og lokaler op).

Nu sidder jeg selv på den anden side af "hegnet", men jeg tror godt at jeg tør sige at jeg forstår begge sider af diskussionen. (Dog ikke lige den citerede professor, hvis det var alvorligt ment. Hvis jeg var den kandidatstuderende, der havde lavet softwaren, ville jeg drille professoren med at han skræmte folk væk, der kom med fornuftige kommentarer og fejlmeldinger. Og have en dåse bolsjer stående til studerende, der meldte fejl på fornuftig måde. Forhåbentlig kan folk, der er stødt på mig i den funktion, skrive under på at det ikke er tomme ord ;-)

Kræn Hansen Blogger

Du kan lige så godt lade være, basale SQL injektioner og lignende er altovervejende et udtryk for at ejeren er fuldstændig ligeglad.


Det tror jeg desværre at du har ret I. Og problemet er her at det ofte er de studerende der skal bruge værktøjet - ikke underviseren. Det er også derfor at det ville være naturligt at have et open source projekt omkring produktet, så dem der bliver irriteret af fejlene har en mulighed for at rette dem.

Så ansæt dem dog?
Datalogi i Aarhus har en meeeget lang tradition for at ansætte studenter som programmører til at kode systemer til brug i undervisningen.


Jeg er bange for at de produkter jeg refererer til ikke har et udviklingsbudget. Vi taler her om produkter der bruges i undervisningen men som ingen har penge til at vedligeholde.

Kai Birger Nielsen

Hmm, jeg ville gerne skrive noget pænt, men jeg har været for lang tid på den anden side af den grøft. Jeg tager lige fløjlshandskerne af: Det er noget at basere undervisning på den slags "programmer". Mit favoritskræmmeeksempel er en "kalender", som en af underviserne fik enelleranden til at lave for "det var jo så let at lave sådan en". På et tidspunkt (ca 5 minutter efter at det compilede første gang?) tabte vedkommende "udvikler" så interessen for sit "produkt" og underviseren (der for resten også var institutleder på det tidspunkt) mente at det kunne vi da passende overtage supporten af.

Jeg vil være meget flink og medgive at mange af bogstaverne i koden kunne være genbrugt til at lave et kalenderprogram med. Et par af problemerne i koden var at man ikke kunne flytte en aftale og at der let gik ged i det, hvis der var mere end en, der forsøgte at booke en aftale på samme tid.

Så nej, jeg er ikke stor tilhænger af den slags programmer, heller ikke selv om de er open source og skrevet med økologisk blæk :-)

En mere munter oplevelse var da et andet institut havde klonet en webside/script, jeg havde skrevet til at lave dørskilte med. De havde bare ikke fortalt nogen at de havde klonet det, så da jeg så senere fik en fejlmeddelelse på at dørskiltegeneratoren ikke virkede var de første fem minutter af dialogen ren "goddag mand. økseskaft!".

På den anden side har jeg set flere/mange fornuftige programmer, der havde vores studenterprogrammører som hoveddesigner eller meddesigner, så min personlige skillelinie går ved om der er et ansættelsesforhold. Hovedbegrundelsen er at man så kan beordre folk til ikke at skrive lortekode med sikkerhedsproblemer bygget ind fra starten. (Hmm, gad vide hvordan sharepoint egentlig er startet?) Og fortælle dem at fejlmeddelelser af typen: "Unknown error" ikke er best practice.

En sidste ting inden jeg hopper ned fra sæbekassetalerstolen: Undervisere bør foregå med et godt eksempel og faktisk vise de studerende hvordan gode programmer ser ud. Selv mange lærebøger i programmering hopper desværre udenom problemet.

Kræn Hansen Blogger

Det er noget hø at basere undervisning på den slags "programmer".


Jeg tror vi bliver nødt til at differentiere på disse programmer - som jeg nævnte er de to værktøjer specifikke til undervisningen, og ikke så generelt at et institut overtager supporten.

Så nej, jeg er ikke stor tilhænger af den slags programmer, heller ikke selv om de er open source og skrevet med økologisk blæk :-)


Til referatet: Jeg hævder ikke at programmer automatisk får højere kvalitet fordi de udvikles open source.

Hovedbegrundelsen er at man så kan beordre folk til ikke at skrive lortekode med sikkerhedsproblemer bygget ind fra starten.


Man kunne også bare afvise lortekode med sikkerhedsproblemer når en studerende kommer med en patch.

Undervisere bør foregå med et godt eksempel og faktisk vise de studerende hvordan gode programmer ser ud.


Hvis de kan. Men som absolut minimum bør de være imødekommende (ikke blot i ord) når en studerende har et reelt bidrag til værktøjet.

Kai Birger Nielsen

Fair nok. Jeg tror vi er i bund og grund enige. Måske lige på nær om det er rimeligt at "værktøjer specifikke til undervisningen" er af ringe kvalitet. Men det er jo i sidste ende op til pågældende underviser. Måske skulle I bare lokke ham med i fredagsbar og fremføre jeres synspunkter, når han er i et modtageligt humør?

(Og jeg har en ubehagelig fornemmelse af deja-vu, for jeg husker engang i 1982 selv at have fremført lignende synspunkter over for en forelæser på 3. år i datalogistudiet på Århus Universitet :-)

Om ikke andet, så giver det en ekstra gang selvtillid at vide at man er uenig med en professor og at det er en selv, der har ret.

Gert Madsen

Den tidligere regering havde et mantra, der hed "fra forskning til faktura", og som nok har haft en del indflydelse på hvordan Universiteterne håndterer den slags.

Så der er i hvert fald nogen der har en anden opfattelse af universiteternes opgave mht. at sikre patenter og ophavsret, end der gives udtryk for her i debatten.

Kræn Hansen Blogger

Fair nok. Jeg tror vi er i bund og grund enige. Måske lige på nær om det er rimeligt at "værktøjer specifikke til undervisningen" er af ringe kvalitet.


Jeg kan godt lide at være enige :) Men det kan jo være svært at lave det forkromede værktøj i første forsøg. Det er i min optik vigtigere at have en effektiv strategi for hvordan man får rettet fejl fremadrettet.

Og så en lille tilføjelse til min egen kommentar:

Kai Birger Nielsen skrev: "Datalogi i Aarhus har en meeeget lang tradition for at ansætte studenter som programmører til at kode systemer til brug i undervisningen."

Jeg er bange for at de produkter jeg refererer til ikke har et udviklingsbudget. Vi taler her om produkter der bruges i undervisningen men som ingen har penge til at vedligeholde.

Jeg vil lige tilføje at det heller ikke ville virke i det tilfælde jeg beskrev. Jeg ville gerne bruge min fritid på at undersøge fejlen og lave en patch der kunne rette den fejl jeg oplevede, men jeg gad ikke bruge tid på at vedligeholde værktøjet generelt. Hverken i et kandidat speciale, et projekt eller som fritidsjob.

Jens Madsen

I de fleste tilfælde, syntes jeg ikke, at sikkerhedshuller er et problem.
De studerende er ansvarlige personer, og som regel, kan det medføre bortvisning fra universitet, hvis de søger at bryde sikkerheden. Det kan ganske enkelt medføre, at en - eller flere - studerende bortvises.

De studerendes opgave, i et kursus, er at bruge det software, som de får givet. Det skal naturligvis fungere, i en grad, så at kursusets formål kan opfyldes. Naturligvis, må det ikke "gå ned", eller på anden måde, give problemer for de studerende.

Der er således et funktionalitetskrav - mens sikkerhedskravet betyder mindre. Dem, der går på universiteterne, er voksne personer, og det er ikke en samling hackere. Hvis de er hackere, og søger at kompromitere sikkerheden, risikeres bortvisning.

Jørgen L. Sørensen

Hvis de er hackere, og søger at kompromitere sikkerheden, risikeres bortvisning.

Kommer vel an på om de er dygtige nok til at gøre det uden at blive opdaget.

Det at de studerende (forhåbentlig) er voksne, er ingen garanti for at de holder sig til reglerne. Hvis de er motiveret nok til at omgå reglerne, og føler at de kan gøre det uden det bliver opdaget, skal der nok være nogle der vælger at bryde dem. Det er jo ikke ukendt at aviserne skriver om voksne mennesker der har brudt reglerne - og dermed er blevet jobsøgende, eller tremme-kaniner.

Brian Hansen

Det vil da på ingen måde undre mig om der er nogen whitehat hackere der kunne finde på at "små sabotere" systemerne, så universitetet kan få fingeren ud, og få rettet de alvorlige fejl der er. Nogen gange er det simpelthen det der skal til, bare se på Blaster ormen til Windows. Man kan ikke lukke sikkerheds huller ved at fortie dem!
Hvis en bruger gør mig opmærksom på et hul i mine systemer, så vil jeg da tværtimod være glad for hans indsats og ærlighed, så hullet kan blive lukket.

Kræn Hansen Blogger

De studerende er ansvarlige personer, og som regel, kan det medføre bortvisning fra universitet, hvis de søger at bryde sikkerheden. Det kan ganske enkelt medføre, at en - eller flere - studerende bortvises.

De studerendes opgave, i et kursus, er at bruge det software, som de får givet. Det skal naturligvis fungere, i en grad, så at kursusets formål kan opfyldes. Naturligvis, må det ikke "gå ned", eller på anden måde, give problemer for de studerende.

Min umiddelbare tanke er at der er forskel på systemer. Hvis jeg som studerende påpeger et sikkerheds problem i et system der kun bruges som værktøj i undervisningen og som på ingen måde skal bruges til at fastsætte min karakter i kurset, så er det helt urimeligt at trække bortvisnings kortet.

På den anden side, hvis et system bruges til at vurdere min karakter eller håndtere sensitiv information om mig (fx min dårlige besvarelse af en opgave eller lignende), så er det i høj grad i min interesse at systemet ikke bare virker (ie. det ikke "går ned"). Hvis systemet håndterer information om mig eller kan påvirke min karakter, kan det påvirke min studiegang at andre kan ændre min karakter eller impersonere mig på anden vis. I sådan et tilfælde vil jeg gøre hvad jeg kan for at systemet bliver sikkert, altså påpege fejl, eventuelt ved eksemplets magt, what-ever it takes.

Så må universitetet for den sags skyld smide alle de stærke hjerner med holdninger og stærke værdisæt, på gaden. Men så ved jeg ikke hvad en universitetsgrad er værd i Danmark anno 2012.

Jens Madsen

Da jeg var studerende, mener jeg ikke, at der var gjort meget ud af sikkerheden. Vi kunne i princippet, gå ind og se de andre elevers mapper og filer. Og hvis nogen ønskede det, tror jeg ikke, at det var et problem med superbrugeradgang. Det skulle ikke undre mig, hvis passworded lå en fil.

Til gengæld, var mit indtryk, at man i nogle tilfælde loggede hvad de studerende foretog sig. Så ihvertfald, vil nok være klogt, at logge ind i andre studerendes navn. Vi fik også at vide, at web-cam kameraerne, blev brugt til overvågning, så der vil nok også være klogt, at lægge noget over, og at finde et sted, der ikke kunne ses på videokameraerne, der overvåger lokalet. Samt, at finde en andens studiekort, for at få adgang til rummet.

Det blev kaldt "frihed under ansvar".

Log ind eller opret en konto for at skrive kommentarer