Skoleledere langer ud efter Aula: »Har på ingen måde gjort hverdagen lettere«

Formålet er vel at gøre det nemt for undervisningsministeriet og kommunerne at holde øje med elever, lærere og skoler.

Det har systemet vel klaret meget godt?

At der ikke er taget meget hensyn til øvrige interessenter, er ikke specielt for AULA.

Hvorfor ikke bare droppe AULA, det overskrider GDPR lovgivningen.

Allerede dengang systemet kom i udbud, kunne man se, at det ville blive noget rod. Det var planlagt til at blive en katastrofe.

Jeg tror at en af grundene til at projektet var så dårligt tænkt er, at det blev undfanget midt i GDPR-forvirringen, som gjorde, at det helt centrale fokus var hvem kan se hvad, hvorfor og hvornår etc, fremfor trods alt at have de daglige arbejdsopgaver i centrum. Resultatet er et system, der virker helt blottet for brugervenlighed i ordets bredeste forstand.

Heller ikke stor fan.

Gratis feature-forslag til næste update:

1) Opsigelse sendes til dansklærere helt automatisk, såfremt personen udgiver en nyhed, hvor der ikke startes med stort begyndelsesbogstav.

2) Bloker mulighed for at uploade dokumenter, hvis dokumenterne ikke indeholder andet end tekst.

3) Bloker Word dokumenter i posts til forældre, uanset hvad de indeholder.

4) Haptisk interface. Elektriske stød hvis der postes billeder af kager.

I forbindelse med at mit barns klasse blev sendt hjem pga. en coronahændelse sendte skolen en besked ud til alle klassens forældre med vigtige informationer. Her viste Aula en uheldig opførsel, idet beskeden først dukkede op i min og min kones indbokse efter næsten et døgn og med nogle timers mellemrum. Beskeden blev indsat et stykke nede i indbakken efter afsendelsestidpunkt. Man kan tilsyneladende ikke se hvornår den rent faktisk ankom i indboksen ligesom man ikke kan se om en afsendt besked er blevet leveret til modtagerne.

Aula kan derfor ikke bruges som pålidelig kommunikationskanal.

Aula overtræder ikke Schrems II:

Aula-data gemmes i Europa

Aulas data opbevares i ét europæisk datacenter hos Amazon Web Services – AWS. AWS har datacentre i Irland, Tyskland, Frankrig og Sverige. AWS er amerikanskejet, men drives i EU af et europæisk datterselskab, som er underlagt europæisk lovgivning. Det indgår i Aula-aftalen, at data skal være placeret i et EU/EØS-land – det vil altså sige et land i Europa – og på intet tidspunkt må føres ud af EU/EØS.

men drives i EU af et europæisk datterselskab,

Lige her er problemet, for det amerikanerne prøver at agumentere for, er at når hovedkontoret ligger i USA er alle data amerikanske, hvis man altså spørg amerikanerne. Lige meget om det er et datterselvskab der ejer EU delen, for ejeren er jo det amerikanske hovedselvskab.

Men har udviklet et nyet system og alle vil bare forsætte som intet var hent. Man vil ikke forandringer så man bliver ved med gamle rutiner og sætter groft sagt strøm til papir men man ændre ikke arbejdsgangene så man lader det it systemtet er bedst til gøre arbejdet men man gør det manuelt. En klassiker. AULA blev testet og testet grundigt men hvorfor kom disse ting så ikke frem den gang når de er så tydelige nu? Det er jo et kendt problem at skolerne ikke havde forberedt sig til overgangen men bare kopirede gamle måder, arbejdsgange m.m. direkte over uden at have sat sig ind i det nye system. Man gad ikke bruge tid på bruger tilladelser m.m. Der ud over har forældre en forbandet hang til at ville vide alt om alt gerne inden det er sket og naturligvis skal alle vide hvad man mener om alt.. aka elendig beked diciplin. Så kommer det til sikkerheden.. folk er åbenbart så dovne at de er kolde bagi omkring deres barns personlige oplysninger at de hellere vil have det til at flyde frit fremme bare de kan undgå at logge ind.

Ja AULA er langt fra fejlfri men jeg mener stadig at 80% af problemerne ligger på skolerne og i kulturen blandt skolefolk og forældre. De sidste 20% må udviklerene og driften tage på sig.

AULA blev testet og testet grundigt

• Det er muligt. Men i den kontekst betyder ”grundigt” ikke nødvendigvis ”godt nok”.

hvorfor kom disse ting så ikke frem den gang når de er så tydelige nu

• Mit bud er ingen fokus på skalering og forskellige adfærdsmønstre blandt slutbrugerne.

Der er ingen tvivl om at nogle af problemerne stammer fra skole og forældre, med der er nogle helt generelle fejl og mangler, som relaterer sig til systemet.

Jeg ved ikke hvor let det er for skolen at sende beskeder der kun rammer de relevante målgrupper. Med de andre UX udfordringer der er, kan jeg kun gætte mig til at det er noget nær muligt at finde ud af.

Et godt UX vil unægtelig gøre det lettere for alle parter at fjerne en stor del af disse 80% af problemerne.

Men med hensyn til de (ifølge dig) resterende 20% så burde der komme fokus på:

Der er (for) ofte login problemer. Særligt om morgenen, som gør det umuligt at se elevernes skema eller give sende beskeder til skolen. Det gør det lidt svært at pakke tasken om morgenen eller give informationer, der er relevant for den aktuelle dag. Generelt er den ofte meget langsom. Specielt på tidspunkter hvor der må formodes at være mange bruger på systemet.

Der er ingen let funktion til ”Marker alle som læst” i ”Overblik” og ”Beskeder”. Det betyder at jeg pt. har 3 ulæste emner i mit ”Overblik” som jeg ikke finde, da det tager for lang til at scrolle gennem gamle beskeder. Og når en gammel besked er læst ryger man ofte tilbage til toppen af ”Overblik”, hvorefter man kan begynde forfra på noget der ender i en sisyfos opgave.

Der er ingen datomarkering i ”Overblik”, hvilket gør det svært at se hvor langt tilbage i oversigten man er kommet. Specielt i relation til ovenstående problematik.

Hvis telefonen kortvarigt lægges fra sig/låses, genindlæses ”Overblik” og man kan begynder forfra med at søge efter gamle beskeder. Igen med reference til ovenstående

Stylingen af ”Overblik” vs. ”Beskeder” er forskellige og kan give lidt forvirring. I beskeder er skriften ”fed” ved ulæste beskeder, mens det ikke er tilfælde i ”Overblik”, hvor der nogle gange står "NY". Det giver ellers mulighed for at se hvad der er står som ulæst.

Når der registreres ferie/fridag kan den efterfølgende ikke ses samme sted som registreringen sker. Det betyder at bla. at jeg ikke kan se om konen har husket at registreret ferie som aftalt…eller var det nu forreste mig der lovede at gøre det.

Standardmetode til svar under ”Beskeder” er ”Svar til alle..” hvilket støjer og betyder at forældre vælger ”Forlad samtalen” (hvorfor ”samtale” og ikke ”besked”?). Det har igen den utilsigtede konsekvens at hvis trådstarteren kommer med ny vigtig information, er det ikke alle der modtager den.

Det er ikke intuitivt hvad ”Marker som følsomt” betyder under beskeder. Er det hele tråden eller min mit eget svar der markeres som følsomt. Og kan andre fjerne det igen?

Der er ingen rød tråd i fremsøgning af elever/forældre hvis man fx skal give en besked til alle pigerne.

Det er muligt at tilføje elever til en besked på trods af at de ikke kan modtage beskeder (1. klassetrin). Men "heldigvis" får man en generisk fejlbesked ved afsendelse i stil med ”Der er modtagere på listen der ikke kan modtage din besked”). Så må man jo gå igang med en lille gætteleg om hvad det kan skyldes.

Der ser ikke ud til at være den mindste brug af lokal cache, som gør det utroligt langsomt at navigere frem og tilbage mellem de samme emner. Uanset om det er beskeder, kalender eller overblik.

Der burde være blokeret (eller i det mindste meget besværligt) at vedhæfte .docx filer. Det er lettere irriterende at blive tvunget til at installere Word på sin telefon, for at kunne læse nyeste vigtige besked vedr. håndtering af dagens coronaudbrud.

…..og jeg kunne blive ved ☹

I denne situation er jeg glad for at vi kun har ét barn.

tl;dr * Dårlig performance * Grimt/inkonsekvent UI * Dårlig UX

Som jeg læser det er hovedparten af dine problemer bundet op på bruger adfærd. Pakke tasken til dagen.. ændres skemaet så tit at barnet ikke kan pakke tasken om aftenen inden senge tid? Beskeder.. her er problemet mere at der er deles for meget "information" som ikke er nødvendigt, for meget ævl og kævl.

Test var ude på skoler i en skala få systemer offentlige og private ikke når op på. Men har du spurgt på dit barns skole om hvornår s¨de begyndte at forberede sig på Aula? Hvornår de lavede og implementerede en kommunikationsplan? Hvornår de ( efter endt uddannelse) satte AULA op til deres kommunikations plan?

Og ikke mindst har du prøvet at lade dit barn tage ansvar og klare sig selv? det var ikke uhørt før i tiden at skolebørn kunne pakke tasken selv, huske deres skema efter få uger og faktisk godt kunne huske at på tirsdag skal vi være ude i idræt og ikke inde... Er børn og især forældre så hjælpeløse i dag? for det kan intet it system rette op på...

Skoleintra var udviklet af lærere for lærere. Mange små værktøjer blev tilføjet, som kunne lette en lærer i det daglige arbejde. På et tidspunkt blev det til et værktøj for ledelsen, da man så en fordel i denne form for kommunikation - specielt på de store skoler, der kom ud af sammenlægninger.

Forældreintra og Elevintra er knopskud hertil, som fik den udformning det har, ud fra hvad en lærer har brug for at en forældre/elev ved/kan/skal. Skoleintra er et teknologisk bedaget system, som har (nutid, da det stadig lever) sin force i at være et redskab i hænderne på praktikerne.

Aula er omvendt konstrueret med fokus på skoleledelse (set fra et kommunalt perspektiv) og beskeddelen er bevidst skruet sammen, så fokus er på forældrenes behov og de krav, der kommer af GDPR. Alle de værktøjer, som lærere anvendte Intra til at udføre, er ikke med i udbuddet og skal nyudvikles og tilkøbes som moduler til Aula. Som situationen er pt er der en række funktioner, som lærerne tidligere anvendte Intra til at løse, som nu skal udføres manuelt.

https://aulainfo.dk/information-til-medarbejdere/tidsplanen-for-aula/

Yes - AULA implementeres i alle kommunale dagtilbud (på nær KBH) - er der noget sted man kan få et overblik over hvad der gemmes og med hvem det deles?

... Hvorfor skal i det grunden være så pissesvært at finde ud af hvilken mængde data der gemmes og hvem det deles med, når man har at gøre med det offentlige...?

Lige her er problemet

hvis man ikke krypterer indholdet korrekt, jf. anbefalingerne fra European Data Protection Board:

A data exporter [Kombit/Aula] uses a hosting service provider [AWS] in a third country [USA pr. amerikansk lov jf. dig] to store personal data, e.g., for backup purposes.

If

1. the personal data is processed using strong encryption before transmission,

2. the encryption algorithm and its parameterization (e.g., key length, operating mode, if applicable) conform to the state-of-the-art and can be considered robust against cryptanalysis performed by the public authorities in the recipient country taking into account the resources and technical capabilities (e.g., computing power for brute-force attacks) available to them,

3. the strength of the encryption takes into account the specific time period during which the confidentiality of the encrypted personal data must be preserved,

4. the encryption algorithm is flawlessly implemented by properly maintained software the conformity of which to the specification of the algorithm chosen has been verified, e.g., by certification,

5. the keys are reliably managed (generated, administered, stored, if relevant, linked to the identity of an intended recipient, and revoked), and

6. the keys are retained solely under the control of the data exporter, or other entities entrusted with this task which reside in the EEA or a third country, territory or one or more specified sectors within a third country, or at an international organisation for which the Commission has established in accordance with Article 45 GDPR that an adequate level of protection is ensured,

then the EDPB considers that the encryption performed provides an effective supplementary measure.

(der kan være stavefejl i det ovenstående - det er kopieret fra PDF'en, og der er naturligvis ukurrante mellemrum i det kopierede)

(der kan være stavefejl i det ovenstående - det er kopieret fra PDF'en, og der er naturligvis ukurrante mellemrum i det kopierede)

Du fejler vel på punkt 1 og 6, hvis din applikation er hostet hos AWS/Google/Microsoft/whoever?

Med mindre du krypterer i Javascript/WebAssembly... 🙄

Du fejler vel på punkt 1 og 6, hvis din applikation er hostet hos AWS/Google/Microsoft/whoever?

Med mindre du krypterer i Javascript/WebAssembly... 🙄

Du kan sædvanligvis ikke behandle data hvis det er krypteret, og alle fornuftige programmeringssprog har i dag understøttelse for kryptering og dekryptering på den enhed, som funktionaliteten afvikles på.

Kombit har tidligere fortalt at AWS alene har en blob og at de selv har krypteringsnøglen. Jeg kan forestille mig at data mellem AWS og Aula backend er krypteret med en master-key, mellem Aula backend og frontend med Uni-login. Databehandling foregår så i Aula backend (java? C#?) og frontend (som vistnok er lavet i php, oprindeligt som Frog i England og Malaysia).

Ja, Tak. Jeg forstår ikke hvorfor det er så uendeligt svært at gemme dokumentet i pdf, så det bare er nogenlunde læsbart på en mobil.

så det bare er nogenlunde læsbart på en mobil.

Det bliver endnu bedre; anbefalingerne fås kun, så vidt jeg kunne finde, i den PDF.

Du kan sædvanligvis ikke behandle data hvis det er krypteret, og alle fornuftige programmeringssprog har i dag understøttelse for kryptering og dekryptering på den enhed, som funktionaliteten afvikles på.

Kombit har tidligere fortalt at AWS alene har en blob og at de selv har krypteringsnøglen. Jeg kan forestille mig at data mellem AWS og Aula backend er krypteret med en master-key, mellem Aula backend og frontend med Uni-login. Databehandling foregår så i Aula backend (java? C#?) og frontend (som vistnok er lavet i php, oprindeligt som Frog i England og Malaysia).

Med mindre de udelukkende bruger AWS som storage, og håndterer alt behandling af dekrypteret data på maskiner der står udenfor Amazon, så har de som minimum dekrypteret data samt dekrypteringsnøgler i hukommelsen på compute instanser. Det er forholdsvist trivielt at dumpe.

Og nogle af de måder du kan håndtere krypteret traffik på hos Amazon har Amazon sortakinda adgang til nøglerne.

Don't get me wrong, deres HSM setup er nice, og der er er væsentligt sikrere arkitektur end du ser mange andre steder... men det er ikke sikkert mod onde insiders eller TLA-agenturerne...

Jeg ved vi er på version2, men spørgsmålet kunne også være: Er IT godt (nok) til skoleledere?

Med mindre de udelukkende bruger AWS som storage, og håndterer alt behandling af dekrypteret data på maskiner der står udenfor Amazon

Så vidt jeg kan se, er det netop tilfældet.

Fra aulainfo.dk om datasikkerhed i Aula (min fremhævning):

Frank Stjerne, som er specialist i it-drift i KOMBIT:

“De data, der ligger i Aula er sikre. Data er krypterede fra det øjeblik de bliver afleveret til Aula, når de transmitteres, og når de lagres i Aula og helt frem til brugerens web-browser eller Aula-appen. Nøglerne til krypteringen er gemt i Danmark under lås og slå og ingen uvedkommende – end ikke Amazon AWS – vil kunne læse de data, som er gemt i Aula”.

I øvrigt siger samme side at det forventes at Aula kommer til at have over 20 petabyte data. Alligevel en sjat.

Så vidt jeg kan se, er det netop tilfældet.

Gad god at høre lidt mere om hvordan de har gjort det – og hvilke data der er krypteret på denne måde. Database-queries er fx lidt besværligt hvis data først kan dekrypteres i browseren... og hvordan håndterer de key management?

Har de et første led af "frontend" servere der står i Danmark, eller har de fundet en måde at håndtere det på, selvom alt er i AWS?

Man kan self. argumentere for at "data er krypterede hele vejen" så længe at der er HTTPS på alle connections, meeeeeen... 😁