Mozilla brengt Firefox 32 met certificate pinning uit

Mozilla heeft versie 32 van zijn populaire Firefox-browser uitgebracht. De desktopversie van Firefox 32 voegt onder meer certificate pinning toe: daardoor wordt het moeilijker om valse certificaten voor een website uit te geven.

Oorspronkelijk kan elke certificaatautoriteit certificaten voor elke website uitgeven, waardoor het hele systeem in gevaar komt als er één certificaatautoriteit wordt gehackt. Dat is geen theoretisch gevaar: in het verleden hebben meerdere certificaatautoriteiten valse certificaten uitgegeven, waaronder het Nederlandse bedrijf DigiNotar.

Certificate pinning is bedoeld om dat probleem deels te ondervangen: het aantal certificaatautoriteiten dat voor een bepaalde domeinnaam certificaten mag uitgeven, wordt dan beperkt. Dat betekent dat het moeilijk wordt om valse certificaten te genereren zonder dat de webbrowser alarm slaat, en waardoor Firefox-gebruikers minder vatbaar zijn voor man in the middle-aanvallen.

Op dit moment wordt certificate pinning alleen bij Twitter en de eigen Mozilla-sites ondersteund. Later komt mogelijk ondersteuning voor een standaard die websites laat aangeven wie certificaten mag uitgeven voor dat domein. Google Chrome beschikt al een aantal jaar over certificate pinning, maar alleen voor Google-sites.

Verder komt Firefox 32 met een vernieuwde http-cache. Daardoor zouden pagina's sneller moeten laden, moet de browser minder geheugen in beslag nemen en moet de browser zich beter herstellen na een crash. Verder bevat de nieuwe browserversie bugfixes.

Reacties (48)

[Will_M]

Waarom moet een webbrowser zich gaan bemoeien met certificat-chains? IK vertrouw een uitgever..... En dat kán m'n eigen CA zijn.

[Armin]

Jij vertrouwt 'een uitgever'.

Maar wat al die uitgever nu opeens of gehacked wordt (zoals vorige maand een Indiaase CA), of "per ongeluk" een vals certificaat uitgeeft aan een persoon voor een website die die persoon niet onder beheer heeft?

Zo heeft de Franse overheids CA ooit eens een certificaat uitgegeven voor Google, wat de Franse defensie toen gebruikte voor een MITM aanval op gebruikers. In Turkije is iets soortgelijks gebeurt. Uiteraard beide per ongeluk ...

Vertrtouwen is goed, controle is beter. Je browser controleert of de CA wel de juiste is.

[BugBoy]

Een website kan vanaf nu aangeven welke certificaat-autoriteiten voor die specifieke website certificaten mogen uitgeven.

Volgens mij was het Diginotar probleem dan niet voorkomen. Door de Diginotar hack konden ze certificaten uitgeven namens Diginotar. Daar had Firefox dan denk ik geen enkel alarm op gegeven. Dat is de reden waarom het hele Diginotar CA is teruggetrokken. Het was gewoonweg niet meer na te gaan welk certificaat nog wel en welke niet meer te vertrouwen was...

[Armin]

Daar had Firefox dan denk ik geen enkel alarm op gegeven

Juist wel. Dit is namelijk precies waar certificaat pinning tegen helpt. Dat is de kern van de deze feature.

Immers de hacker maakt dan een eigen bijvoorbeeld Facebook certificaat op basis van de diginotar chain, en voert een MITM aanval uit. Jouw browser zonder certifciaat pinning zal inderdaad geen alarm slaan, want diginotar is vetrouwd.

Jouw browser mét pinning, slaat alarm, want detecteert dat Facebook certificaat chain opeens eindigd in een diginotar certificaat en niet in de CA die zij in hun whitelist hebben staan. Resultaat een dik eng rood schild in de display (of bij EMET een system popup).

[MBV]

Even heel cynisch: als die diginotar certificaten niet waren gebruikt om Gmail mee te signen, dan was het ons nooit opgevallen dat iemand DigID etc kon spoofen. Diginotar was gehackt, en de legale instantie om certificaten voor DigID uit te geven. Daar had Firefox nooit tegen kunnen waarschuwen!

[Armin]

Daar had Firefox nooit tegen kunnen waarschuwen!

Klopt, maar dat is in feite enkel zeggen dat zolang men de valse certificaten niet gebruikt om populaire sites te vervalsen, de massa het niet merkt

Maar een staatshacker die het gebruikt om gericht te spioneren bij een andere staat, zou inderdaad heel lang zijn gang kunnen gaan...

[BugBoy]

Het biedt alleen geen bescherming bij sites die al bij Diginotar draaiden (zoals veel websites van Nederlandse overheidsinstellingen). Ik vind het nogal een adhoc manier om een security probleem op te lossen (en daardoor een vrij waardeloos iets voor het beveiligen van miljoenen websites).

Ik zou overigens niet weten waarom je dan zou opslaan dat het een Verisign certificaat moet zijn. Sla dan gewoon het verwachte certificaat op, dan heb je elke modificatie door. Een hel om te onderhouden, maar dat is een beetje inherent aan deze oplossing (als je dat op brede schaal wilt gebruiken).

[Armin]

Het biedt alleen geen bescherming bij sites die al bij Diginotar draaiden

Nee, het bied ook daar bescherming. Het controleert namelijk de chain per certifciaat. Het is geen whitelist van root CA's, maar een whitelist van root CA's per individueel certifciaat of domain.

Dus in dit voorbeeld, een NLse overheids site van diginotar was OK, maar Google.com van diginotar niet.

Sla dan gewoon het verwachte certificaat op, dan heb je elke modificatie doorr

Dat doet men dan ook zo. Enige complicatie is dat bedrijven als Facebook soms verschillende certificaten van verschillende CA's gebruikt voor hetzelfde toplevel domain. Vandaar dat de whitelist flexibel moet zijn. Maar het is dus inderdaad een whitelist van verwachte certificaten.

[DutchReaper]

Aangezien de pinning meegestuurd wordt met de installatie van firefox, krijg je dan geen problemen als juist de private key van een CA op straat komt te liggen. Want dan kunnen die sites niet meteen hun oude certificaten vervangen voor nieuwe omdat de gebruikers een beveiliginswaarschuwing krijgen.

Ipv certificaat pinning zie ik persoonlijk meer heil in het cache van certificaten van websites die je bezocht hebt en als deze is veranderd bij het volgende bezoek te controleren of de root CA veranderd is, en of het oude certificaat in de tussentijd revoked is.

Hiermee bescherm je de gebruiker tegen private keys van CA's die op straat liggen,
NSA die certificaten uitbrengen mbv private keys van hun eigen Amerikaanse Root CA.
En er wordt eindelijk iets gedaan met de mogelijkheid om certificaten te revoken.

[Armin]

Ik weet niet waarom je een -1 krijgt, want je stelt een goede en on-topic vraag. Zal wel dezelfde persoon zijn die mij 0 (off topic) geeft terwijl het evident on-topic is

Hoe dan ook, het antwoord op je vraag: Men gebruikt bij pinning niet de private key (want Firefox weet die zelf ook niet, want dat zou het hele concept van 'private key' ongedaan maken ), maar de handtekening (welke uniek is) van het CA certificaat zelf.

Ipv certificaat pinning zie ik persoonlijk meer heil in het cache van certificaten van websites die je bezocht hebt en als deze is veranderd bij het volgende bezoek te controleren of de root CA veranderd is, en of het oude certificaat in de tussentijd revoked is..

Probleem is dat veel website verschillende certifciaten voor hetzelfde domein hebben. Facebook heeft wel 12 certificaten voor Facebook.com van ook nog eens verschillende CA's. En Google en Microsoft hebben er ook talloze.

[sfranken]

Toch wel. Nu kan DigiNotar voor domain b.com (bijvoorbeeld) ook een (nep)certificaat uitgeven, en dat kan tot problemen lijden. Als de website in kwestie (b.com) nu zegt "he, browser, alleen VeriSign mag certificaten voor mij uitgeven" krijg je nooit het probleem wat ik hierboven aanhaal.

[BugBoy]

Daar heb je inderdaad gelijk aan, maar wat ik begrepen heb is dat niet wat SSL pinning doet. Bij certificate pinning controleer je of het gepresenteerde SSL certificaat eigenlijk wel hetzelfde is als wat je zou verwachten. Voor een webbrowser is dat schier onmogelijk, omdat je naar miljoenen SSL sites kunt gaan. Maar een beetje zekerheid is beter dan niets, dus voor de populaire sites kun je het doen.

Certificate pinning is veel logischer voor applicaties of VPN verbindingen. Als je een mobiele applicatie bouwt (bijv. een Twitter client die alleen met de Twitter API kletst), dan weet je welk certificaat je kunt verwachten. Als dat niet matcht, dan geef je een waarschuwing. Alleen bij uitgifte van nieuwe certificaten moet je de app updaten (evt. tijdelijk twee certificaten toestaan vlak voor de migratie).

Ook voor een VPN kan het wellicht handig zijn als je bang bent voor man-in-the-middle attacks. Door het public deel van het certificaat ook op de VPN client te installeren kun je controleren of het certificaat matcht en daarop waarschuwen. Handiger is het om een eigen root-certificaat op al je PC's te installeren en op basis daarvan een trust-chain op te bouwen (beter beheersbaar).

[CH4OS]

Daar heb je inderdaad gelijk aan, maar wat ik begrepen heb is dat niet wat SSL pinning doet. Bij certificate pinning controleer je of het gepresenteerde SSL certificaat eigenlijk wel hetzelfde is als wat je zou verwachten.

En daarmee dus óók de Certificate Authority (ook) checked.

[BugBoy]

Maar alleen voor een zeer beperkte lijst van domeinen. Als Mozilla het niet belangrijk vindt dan heb je pech. Pure willekeur en beetje 'beter iets dan niets' principe. Als DigiD niet in die lijst zou staan dan had je het niet gezien.

[sfranken]

Hieronder word het prima uitgelegd. Wat ik uitlegde is dus precies wat pinning is: Armin in 'nieuws: Mozilla brengt Firefox 32 met certificate pinning uit'

[Little Penguin]

Op zich klopt het dat het Diginotar-debacle dan niet voorkomen zou zijn, maar een populair domein als google.com zou dan wel beveiligd geweest zijn tegen het uitdelen van een certificaat door de Diginotar-hacker (waarbij de randvoorwaarde geweest zou zijn dat Google.com van een andere root CA gebruik gemaakt moest hebben)...

In een notendop is CA-pinning het opgeven welke 'root CA' er een certificaat voor je domein uit mogen delen. Als er een door een andere 'root CA' ondertekende certificaat aangeboden wordt dan zou certificaat-pinning een waarschuwing/blokkade opleveren...

[BugBoy]

Ik ben denk ik niet helemaal duidelijk geweest... In het Tweakers artikel staat "een website kan vanaf nu aangeven welke certificaat-autoriteiten voor die specifieke website certificaten mogen uitgeven.". Als dat het geval was geweest, dan was het Diginotar verhaal alsnog niet gemeld.

Het artikel klopt namelijk niet (daarom quote ik die zin in mijn opmerking). Een website kan niet aangeven welke CA het certificaat heeft mogen uitgeven. De browser bevat een lijst met certificaten voor de populaire sites en als dat niet klopt dan krijg je een waarschuwing.

Het kromme van deze werkwijze is dat de browsermaker aangeeft welke certificaten goed zijn en welke niet. Als je al SSL pinning wilt, dan zou je dat eigenlijk in je OS willen hebben en niet in de browser. Dan werkt het namelijk voor alle SSL certificaten en dan heb je niet een per-app oplossing.

Een ander nadeel is dat het slechts een deeloplossing is voor een probleem. Je hebt juist certificate-chaining om een chain-of-trust te hebben om de lijst beheersbaar te houden. Nu wordt het eigenlijk een bijna oneindige lijst die niet te beheren valt.

Overigens heeft Chrome dit al een hele tijd voor het Google domein.

[Reactie gewijzigd door BugBoy op 29 juli 2024 01:06]

[alt-92]

EMET 4.1 en hoger bieden eenzelfde functionaliteit aan, en dan niet alleen voor één programma.

[Little Penguin]

Werkt EMET 4.1 dan ook samen met bijvoorbeeld OpenSSL? (Zodat je programma's die van deze bibliotheek gebruik maken ook gelijk op deze manier kunt beveiligen...) - Volgens mij niet...

Aangezien men bij Mozilla gekozen heeft om de afhandeling van SSL/TLS door een eigen bibliotheek uit te laten voeren, die ook gelijk met alle ports meegeleverd wordt, kan men geen gebruik maken van dit soort "fabrieks"specifieke oplossingen...

[alt-92]

OpenSSL is sowieso al een draak, maar dat daargelaten: ik zei erbij dat het dan niet maar voor één applicatie geldt, Gebruik je de OS-eigen PKI functionaliteit op Windows, dan is EMET heel nuttig. Het werkt bijvoorbeeld ook voor Google Chrome (35+) zo.
Dat Mozilla een keuze heeft gemaakt om niet de OS native libraries te gebruiken is een zaak voor Mozilla.
Goed dat ze het erin hebben gestopt.

[Armin]

Werkt EMET 4.1 dan ook samen met bijvoorbeeld OpenSSL?

EMET werkt alleen met SChannel en de Microsoft trust-store, net zoals Google's certifciate pinning enkel werkt met de SSL blibliotheek die bij Chrome bijgelevert wordt, en deze Firefox pinning enkel werkt met hun eigen ingebouwde trust-store. Dus bij EMET is alles wat de SChannel en MS trust store API's gebruikt beschermt.

Dus bijvoorbeeld al je (corporate) C#/.Net software wordt automatisch beschermt. Ook kun je als tweaker/geavanceerde gebruiker zelf ook pinning rules toevoegen. Bijvoorbeeld als je eigen servers hebt.

[mloman]

EMET doet dat alleen voor Internet Explorer, niet andere webbrowsers.

[alt-92]

Niet waar, cert pinning kun je in EMET zelf uitbreiden zodat het ook meer dan alleen de Google sites meeneemt in Chrome.

[Armin]

Dat is omdat Chrome op Windows de Microsoft trust store gebruikt.

[alt-92]

volgens mij heb ik dat ook gezegd (dat ik v35 en hoger noem heeft meer te maken met het punt dat Chrome < 34 en EMET geen vriendjes waren)

[Armin]

Wat bedoel je met vriendjes zijn?

mloman stelt dat EMET het enkel bescherming biedt voor Internet Explorer. Voor het onderdeel certificaat pinning is dat inderdaad niet waar, omdat op Windows de Chrome browser dezelfde certificaat store gebruikt als Internet Explorer. Maar dat is bij mijn weten al zo ver voor versie 34?

(Andere aspecten van EMET werken niet goed samen met Chrome, maar staan dan ook default uit.)

[alt-92]

In EMET 4.1 u1 en 5 ja, maar daarvoor was de combinatie EMET en Chrome een waar crashfest.
Google heeft sinds 34 een aantal functiecalls anders in hun eigen sandbox geimplementeerd waardoor er geen conflict meer optrad met EMET 4.1. Voor die tijd moesten we de ADMX template aanpassen om de standaard mitigation settings te bewerken (EMET in bedrijfsomgeving met GPO management).

[Armin]

In EMET 4.1 u1 en 5 ja, maar daarvoor was de combinatie EMET en Chrome een waar crashfest.

Bij mijn weten is Chrome en EMET nog steeds een relatief crash fest voor diverse EMET features Met name EAF faalt nog steeds af en toe met Chrome, maar hangt wellicht ook van de plugins af.

Maar zoals ik schreef staan de non-pinning features default uit voor Chrome. Dat was in ieder geval ook al in 4.0 zo? Gewoon klikkerde-klik klik EMET installeren heeft dus geen nadelig effect op Chrome

[locke960]

Certificate pinning is bedoeld om dat probleem deels te ondervangen: een website kan vanaf nu aangeven welke certificaat-autoriteiten voor die specifieke website certificaten mogen uitgeven.

Voor de duidelijkheid. De manier waarop dit werkt is dat een website dit bij Mozilla aan kan geven die die gegevens dan samen met de browser software verspreid. Inderdaad, een oplossing uit de vroege jaren 90 die niet schaalt en een hele reeks nieuwe problemen op gaat leveren.

In feite wordt een slecht ontworpen systeem opgelapt door nog meer slechte ontwerpen toe te voegen. Dit is in het beste geval dus een tijdelijke oplossing.

[Reactie gewijzigd door locke960 op 29 juli 2024 01:06]

[robvanwijk]

Meer info: https://wiki.mozilla.org/...eering/Public_Key_Pinning

Zou het niet veel logischer (en robuuster en schaalbaarder en vendor-independenter (eh....)) zijn om pins toe te voegen als een, optioneel, veld in de DNS records?

[Snow_King]

Natuurlijk! We zouden ook van de CA's af kunnen met DNS records, maar de SSL business is een miljarden business, dus de CA's houden zulke zaken heel hard tegen met goed lobby werk.

[The Zep Man]

Natuurlijk! We zouden ook van de CA's af kunnen met DNS records, maar de SSL business is een miljarden business, dus de CA's houden zulke zaken heel hard tegen met goed lobby werk.

Want DNS providers zijn te vertrouwen? Het is niet dat ik de huidige manier van public key infrastructure goedkeur, maar je gaat het probleem niet oplossen door de macht die bij enkele partijen ligt te verplaatsen naar enkele andere partijen.

[XVI]

Daarom moet het samen met DNSSEC gebruikt worden: DANE

[justincase]

justincase in 'nieuws: Mozilla brengt Firefox 32 met certificate pinning uit'

[Snow_King]

Ja, want de DNS records beheer je zelf bij je provider naar keuze.

DNSSEC kan de DNS keten van A tot Z valideren en jij kan je domein onder brengen bij elke provider die je wil.

CA's hebben nu enorm veel invloed. Technisch stelt SSL weinig voor, maar door de monopolie positie van de CA's kunnen ze gruwelijk veel geld voor SSL vragen.

[Soldaatje]

SSL beheer je ook zelf bij een provider naar keuze.
CA's hebben veel invloed maar ze zijn op één of twee handen te tellen (bij wijze van spreken). Valt er eentje door de mand, is het niet meteen een ramp, nemen de anderen het over.
Als er met DNSSEC ontelbaar veel providers zijn, dat valt niet te controleren door wie dan ook, en dus zal er veel door de mand kunnen vallen. Zeker als de prijzen laag worden of zelfs gratis, dan zal de beveiliging ook omlaag gaan.
Monopolie is het niet, want er zijn meedere aanbieders, en gruwelijk veel geld is relatief maar volgens mij valt daar ook nog in te shoppen.

[Plofkotje]

Er is per TLD maar een provider met DNSSEC, de organisatie die de TLD beheert.

Bij .nl signed SIDN de .nl root zone met een key. Jij stuurt je public key naar SIDN (via je registrar), en die zetten hem in hun zone, ondertekend met hun sleutel. Zo weet je DNS resolver dat je key klopt. Als je dan met DANE je TLS key in de DNS zone zet, is dit vele malen veiliger dan een instantie die jouw certificaat tekent.. Dan weet je wel dat een CA hem goedgekeurd hebt, maar je weet nooit zeker of dat certificaat ook wel echt bij die dienst hoort. Met DNSSEC en DANE heb je voor elk domein wat dit doet wel die garantie, of in eiser geval meer dan dat je met t huidige systeem hebt.

Ik snap dat de CA moet controleren of het certificaat ook wel echt geissued word aan de juiste partij, maar dat is in het verleden al veel te vaak misgegaan. DNSSEC met DANE is vele malen veiliger.

[Reactie gewijzigd door Plofkotje op 29 juli 2024 01:06]

[justincase]

Zoals je zelf al aangeeft is het in het verleden een aantal keren fout gegaan. Waarom zouden we dan deze macht over moeten dragen aan de registrars? Registrars zijn juist helemaal niet ingesteld op dit soort veiligheid.

Sowieso veranderd er in een aantal gevallen niks. Als je Verisign niet als CA vertrouwd dan heeft DANE weinig meerwaarde aangezien hun o.a. de .com beheren.

SIDN is wellicht te vertrouwen. Maar als inwoner van Libië ben je dus aangewezen op de overheid. Of in Rusland op de Russische overheid. Je hebt geen keuze uit een andere CA zoals je die nu hebt. Dat wekt niet veel vertrouwen. Daarnaast, als jij SIDN niet meer vertrouwd vanwege een incident heb je pech — je kan niet overstappen naar een ander.

Wat erg interessant zou zijn is bijv. Tack.io. Hiermee kunnen we het bestaande PKI systeem behouden maar is de "slechtste" CA niet meer de zwakste schakel.

Voor een beter plaatje lees dit artikel wellicht eens: SSL And The Future Of Authenticity

The registrars. CAs are sketchy, but this is a whole new world of sketchiness. Think, sketchasaurus. Registrars were never built or selected with security in mind, and most of them don’t have a very good track record in this area. Shouldn’t it be laughable that the current first step in deploying DNSSEC is to create an account with GoDaddy? I mean really, do you trust this guy? Forever?

[justincase]

Zie ook justincase in 'nieuws: Mozilla brengt Firefox 32 met certificate pinning uit'

[Locke_]

Ja superfijne dat certificate pinning. Kon op geen enkele ilo interface meer inloggen. Gelijk die optie maar weer uitgezet.

[wica]

Dank voor de tip alvast. Dit is dus de 2de keer dat ik ervaar, dat een update aan firefox, het beheer van devices met een http interface moeilijker maakt.
De eerste keer toen ze besloten SSLv2 uit te zetten en nu dus dit. Verder zullen we het maar niet hebben of het gedoe met self signed certificate, waarvan Firefox vind dat ze gevaarlijk zijn.

[The Zep Man]

Dank voor de tip alvast. Dit is dus de 2de keer dat ik ervaar, dat een update aan firefox, het beheer van devices met een http interface moeilijker maakt.
De eerste keer toen ze besloten SSLv2 uit te zetten en nu dus dit. Verder zullen we het maar niet hebben of het gedoe met self signed certificate, waarvan Firefox vind dat ze gevaarlijk zijn.

Je zou natuurlijk ook gewoon het certificaat van je eigen CA kunnen toevoegen aan de vertrouwde CA lijst van je Firefox installatie om problemen te voorkomen. Dan zijn (voor Firefox) de certificaten op jouw apparaten niet meer self-signed. Hierbij neem ik aan dat alle certificaten op de apparatuur die je gebruikt netjes met een eigen CA zijn aangemaakt. Dat heb je toch wel in orde?

En over SSLv2: het is goed dat dit standaard uit staat. Sysadmins die het nog voor legacy systemen nodig hebben waar ze niet vanaf komen kunnen hier omheen werken, maar voor een gewone gebruiker die over het web surft heeft SSLv2 geen toegevoegde waarde meer.

[Reactie gewijzigd door The Zep Man op 29 juli 2024 01:06]

[_Thanatos_]

Dus een gecompromisseerde website heeft alleen maar een nieuw setje HTTP-headers nodig om ook dit te omzeilen. Of is hier iets magisch aan de hand?...

[Kewne]

Certificate pinning zoals het nu in Firefox zit is een statisch lijstje dat met de browser mee gescheept wordt. HTTP headers hebben momenteel dus weinig relevantie. Er wordt wel gewerkt aan een Public-Key-Pins header, maar voor zo ver ik weet wordt deze nog nergens ondersteund.

Zelfs als het wel ondersteund wordt kan er niet zomaar mee gesleuteld worden; er zal namelijk eerst een geldige HTTPS verbinding tot stand moeten komen. Als de pin al bij de browser bekend was dan is dat niet zomaar te omzeilen. Tenzij de aanvaller natuurlijk een certificaat gestolen heeft dat geldig is volgens die pin, maar dat is geen use-case waar pinning mee kan helpen.

[Reactie gewijzigd door Kewne op 29 juli 2024 01:06]

[_Thanatos_]

Dus de browser heeft nu een lijst van websites met certificaten. Ik vind het wel een beeeetje overdreven hoor. Ik heb ook geen zin in een nog zwaardere browser die wat tijdelijke schijnveiligheid toevoegt.

[mcgloud]

Dit heeft niks met de FF 32 features te maken, maar ik hoop echt dat Mozilla snel met een goedwerkende versie van Shumway komt zodat ik niet meer aan Adobe Flash vast zit.

Op Windows en OS X is dit geen probleem maar op mijn Linux machines wordt ik geforceerd om Google Chrome te gebruiken omdat ik simpel weg sommige sites waar een nieuwere versie van Flash voor nodig is (11 is de laatste versie voor Linux) niet kan bezoeken of gebruiken. De site voor het lesmateriaal van mijn school vereist een nieuwere versie van Flash bijv.

[_Thanatos_]

Ik zie het punt niet zo. Of je nou de ene of de andere Flash VM gebruikt. Uiteindelijk moet de VM compatibility bieden met de applet die erom vraagt. Dus ook Shumway kan outdated raken.

Ik zou es even de webbouwer van je school over de knei leggen. Flash vereisen voor lesmateriaal klinkt als een noob die alleen maar Flash kon, en dus de site in Flash is gaan bouwen. Met Flash-vereiste werkt de site immers ook op veel mobiele apparaatjes niet. Alleen op Windows tablets eigenlijk.

[Reactie gewijzigd door _Thanatos_ op 29 juli 2024 01:06]

[incaz]

Niet zo'n duidelijk plaatje, (niet iets waarmee ik het kan uitleggen aan anderen), maar wel een prima feature.