W3C publiceert eerste ontwerp voor web cryptography-api
De W3C heeft een eerste public working draft gepubliceerd van de web cryptography-api. De voorgestelde api moet het mogelijk maken om data met behulp van javascript te versleutelen en weer leesbaar te maken.
De ontwerpversie van de door de W3C voorgestelde api is opgesteld door ontwikkelaars bij Mozilla en Google. De javascript-api moet webapplicaties de mogelijkheid geven om basale encryptiebewerkingen uit te voeren binnen de browser, zoals het versleutelen van data en het genereren van hashes. Ook het aanmaken en controleren van digitale handtekeningen wordt aangeboden door de web cryptography-api.
Volgens de W3C is de api niet alleen nuttig voor webapplicaties, maar kan hij ook in cloudcomputing goed gebruikt worden om data veilig op afstand op te slaan. Zo zou de nieuwe api als alternatief kunnen dienen voor het versleutelen van verbindingen met behulp van ssl en tls.
De working draft-status van de api betekent dat de W3C en de achterliggende Web Cryptography Working Group aan derde partijen vragen om input te leveren. Naar verwachting brengt de W3C in de loop van 2014 de definitieve recommendation uit om de api tot webstandaard te verheffen.
Reacties (46)
En het is natuurlijk geweldig voor het volgen van personen ( privacy) omdat ze nu ook de data kunnen encrypten met als gevolg dat je ook niet meer kan achterhalen wat er over de verbinding gaat.
Als je verbinding maakt via HTTPS wordt alles over HTTPS al encrypt, dus voor zover ik weet is dat niet direct een voordeel. Dit biedt alleen voordelen als je niet over HTTPS connect, maar volgens mij zou dat een eenvoudigere oplossing zijn dan je hele JS project om te laten gaan met encryption en decryption.
Je kunt niet zomaar overal HTTPS implementeren. Als je bijvoorbeeld een web app voor een klant maakt die geen eigen vps heeft voor zijn website, kun je niet zomaar zeggen: ja ga maar even ssl gebruiken (als je meer dan 1 domein op ssl wilt per server is het vaak ook al best prijzig)
Certificaat gaat per IP dus je kan meestal voor een paar euro per maand een extra IP adres aanvragen in plaats van een hele VPS er bij
Of gewoon name-based SSL (ja, dat bestaat ook)
Behalve dan dat er nog genoeg browsers en webservers zijn die SNI niet ondersteunen.
servers die het niet ondersteunen moeten uit. De browsers die het niet ondersteunen zijn niet erg relevant meer (firefox, chrome en ie7+ doen het gewoon).
De probleemgevallen zijn inderdaad oud. Maar ook moderne browsers op oude operating systems, bijv. alle versies van IE op Windows XP. Helaas heeft die combinatie nog een aanzienlijk marktaandeel, dus is het momenteel nog moeilijk om de knoop door te hakken.
bron: http://en.wikipedia.org/w...ame_Indication#No_support
bron: http://en.wikipedia.org/w...ame_Indication#No_support
Sorry maar als het om gevoelige gegevens gaat dan maakt het echt geen drol uit dat het een paar euro extra kost per maand als ik daar mee mijn klanten kan beter kan beschermen dan wel hun meer zekerheid kan bieden dat hun data veilig is dan is dat zeker de moeite waard.
Het geld argument is de reden dat de meest basale beveiliging in veel bedrijven simpel weg achter wegen wordt gelaten. En als alles helemaal fout gaat en op eens wel iemand die 70 miljoen CC gegevens steelt is er op eens wel geld om het allemaal op te lossen.
Het is heel simpel als je met gevoelige gegevens werkt moet je dat goed beveiligen en dat kost geld veel of weinig geld maat niet zo veel uit. Beveiliging is een noodzaak niet een optioneel iets.
Om dit als vervanging van SSL/TLS te zien lijkt me een beetje vreemd omdat de enige omdat zo als het artikel het al zegt het om basale encryptie gaat en dat is bij SSL toch net even anders (goed is het niet maar beter dan basaal is het wel). Hoe dan ook alle kleine beetje beveiliging helpen natuurlijk.
Wat ik me eigenlijk af vraag is hoelang we nog met javascript blijven klooien en wanneer we nu eindelijk eens naar een volwaardige taal overstappen. Javascript is in veel opzichten net niet goed genoeg om echt goede code in te schrijven en dus doen veel bedrijven zo als google <programeer taal X> naar javascript compilers schrijven om daar om heen te werken maar uit eindelijk is dat natuurlijk niet een oplossing maar alleen maar een manier om het echte probleem niet aan te hoeven pakken. Het lijkt me toch dat als de W3C zou willen ze met zijn alle best wel een betere oplossing kunnen vinden dan javascript. Of op zijn minst javascript van een aantal broodnodige updates zouden kunnen voorzien.
Het geld argument is de reden dat de meest basale beveiliging in veel bedrijven simpel weg achter wegen wordt gelaten. En als alles helemaal fout gaat en op eens wel iemand die 70 miljoen CC gegevens steelt is er op eens wel geld om het allemaal op te lossen.
Het is heel simpel als je met gevoelige gegevens werkt moet je dat goed beveiligen en dat kost geld veel of weinig geld maat niet zo veel uit. Beveiliging is een noodzaak niet een optioneel iets.
Om dit als vervanging van SSL/TLS te zien lijkt me een beetje vreemd omdat de enige omdat zo als het artikel het al zegt het om basale encryptie gaat en dat is bij SSL toch net even anders (goed is het niet maar beter dan basaal is het wel). Hoe dan ook alle kleine beetje beveiliging helpen natuurlijk.
Wat ik me eigenlijk af vraag is hoelang we nog met javascript blijven klooien en wanneer we nu eindelijk eens naar een volwaardige taal overstappen. Javascript is in veel opzichten net niet goed genoeg om echt goede code in te schrijven en dus doen veel bedrijven zo als google <programeer taal X> naar javascript compilers schrijven om daar om heen te werken maar uit eindelijk is dat natuurlijk niet een oplossing maar alleen maar een manier om het echte probleem niet aan te hoeven pakken. Het lijkt me toch dat als de W3C zou willen ze met zijn alle best wel een betere oplossing kunnen vinden dan javascript. Of op zijn minst javascript van een aantal broodnodige updates zouden kunnen voorzien.
HTTPS versleuteld alleen de verbinding tussen jouw client en de server. De data blijft volledig leesbaar voor de server. Met deze nieuwe API wordt het mogelijk om b.v. een dropbox achtige client te maken die bestanden 'in the cloud' opslaat die op jouw computer al versleuteld zijn. De beheerder van die cloud heeft dan dus geen toegang tot jouw content. Groot voordeel.
Nadeel blijft dat extra diensten aan de cloud kant (b.v. zoeken in al je bestanden, handschriftherkenning op geuploade foto's, etc) niet werken als je encrypt op de client maar dat is een inherent gevolg van cloudoplossingen.
Nadeel blijft dat extra diensten aan de cloud kant (b.v. zoeken in al je bestanden, handschriftherkenning op geuploade foto's, etc) niet werken als je encrypt op de client maar dat is een inherent gevolg van cloudoplossingen.
Moet er wel eerst een api komen waarmee je bestanden van je filesysteem kan benaderen.om b.v. een dropbox achtige client te maken
Zoiets als de W3C 'File System API' zou voldoende moeten zijn. Daarmee hebben browsers toegang tot bepaalde sandboxed delen van het filesystem.
Plus dat je waarschijnlijk de certificerende maatschappijen niet meer nodig hoeft te hebben. Als de encryptie 1-op-1 verloopt is dat een stuk veiliger (Iran zal blij zijn...).
Wat ik me afvraag is echter op welke manier de verbinding de sleutels overdraagt, is dit een pgp-achtige manier? Of mogen we nu de sleutels in een verzamel-database gaan zetten zodat overheden makkelijker verbindingen kunnen decrypten?
Wat ik me afvraag is echter op welke manier de verbinding de sleutels overdraagt, is dit een pgp-achtige manier? Of mogen we nu de sleutels in een verzamel-database gaan zetten zodat overheden makkelijker verbindingen kunnen decrypten?
Encryptie is maar wiskunde hoor. Zelfs zonder deze API is het mogelijk om gegevens in Javascript te encrypteren. Een RC4 encryptie algorithme bijvoorbeeld is maar enkele regels groot en makkelijk in elke programmeertaal te ontwikkelen.
Deze API is juist een mooie vervanging voor de zelf in mekaar geflanste encryptie-algorithmes die in JavaScript zijn ontwerpen.
Trouwens, iemand die persoonlijke gegevens van jou geencrypteerd wil doorsturen, zal daar altijd wel een manier voor vinden. met of zonder deze API.
Deze API is juist een mooie vervanging voor de zelf in mekaar geflanste encryptie-algorithmes die in JavaScript zijn ontwerpen.
Trouwens, iemand die persoonlijke gegevens van jou geencrypteerd wil doorsturen, zal daar altijd wel een manier voor vinden. met of zonder deze API.
Maar er zijn toch al talrijke oplossingen hiervoor.. Hoe doen huidige sites dit dan?
Het probleem is dat het nu vaak niet heel gemakkelijk is om bijvoorbeeld dmv javascript dingen te versleutelen en zo veilig te versturen over een niet-ssl verbinding (denk aan AJAX requests).
Als dit met deze nieuwe api wel kan, is het natuurlijk een hele vooruitgang.
Loop zelf ook wel eens tegen deze problemen aan bij het maken van webapps.
Als dit met deze nieuwe api wel kan, is het natuurlijk een hele vooruitgang.
Loop zelf ook wel eens tegen deze problemen aan bij het maken van webapps.
Definiëer "heel gemakkelijk". Het is relatief eenvoudig om een bestaande crypto library voor Javascript te pakken, en je content ermee te encrypten voor je het meegeeft aan het ajax request. Je moet dat idd handmatig doen, maar om nou te zeggen dat het "niet heel gemakkelijk is"...Het probleem is dat het nu vaak niet heel gemakkelijk is om bijvoorbeeld dmv javascript dingen te versleutelen en zo veilig te versturen over een niet-ssl verbinding (denk aan AJAX requests).
Daarnaast, als je requests gewoon over HTTPS gaan dan is de encryptie geheel automatisch.
Ja, dat dacht ik ook. Waarom dan weer een of andere API? Of is deze API iets heel anders?Bovendien, als je requests gewoon over HTTPS gaan dan is de encryptie geheel automatisch.
Voor veel cryptographische algoritmes zijn ook pure JavaScript-oplossingen, dus inderdaad, voor een groot deel is dit al mogelijk.
Nadeel van oplossingen in JavaScript is natuurlijk dat ze veel trager zijn (hetgeen zeker voor dit soort algoritmes weldegelijk een merkbaar verschil geeft, helemaal op mobile devices), plus dat het vaak onhandig is in die zin dat iedere webdeveloper weer zelf op zoek moet naar een JavaScript-library die het gewenste algoritme implementeert (vaak zonder te weten hoe betrouwbaar de implementatie is) en dan ook die code weer naar de client moeten sturen.
Nadeel van oplossingen in JavaScript is natuurlijk dat ze veel trager zijn (hetgeen zeker voor dit soort algoritmes weldegelijk een merkbaar verschil geeft, helemaal op mobile devices), plus dat het vaak onhandig is in die zin dat iedere webdeveloper weer zelf op zoek moet naar een JavaScript-library die het gewenste algoritme implementeert (vaak zonder te weten hoe betrouwbaar de implementatie is) en dan ook die code weer naar de client moeten sturen.
Ze zijn niet alleen trager, ze zijn ook onveiliger. Doordat de crypto library ook over de verbinding gaat is het met een "man in the middle"-attack* mogelijk om een veranderde variant bij de client binnen te laten komen. Dan is gelijk al je data weer onveilig. Doordat de crypto delen al in de browser zitten is dat niet mogelijk.
Zie bijvoorbeeld ook https://project.crypto.cat/about/ en dan de sectie over "Secure accessibility". Cryptocat is een project wat cryptografie in javascript doet. De kritiek hierop is juist dat de crypto javascript ook over de 'potentieel' onveilige verbinding gaat.
Zelfs met https is dit nog een mogelijkheid gezien de hoeveelheid slecht beveiligde Certificaat verstrekkers en mogelijke wildcard certificaten.
Zie bijvoorbeeld ook https://project.crypto.cat/about/ en dan de sectie over "Secure accessibility". Cryptocat is een project wat cryptografie in javascript doet. De kritiek hierop is juist dat de crypto javascript ook over de 'potentieel' onveilige verbinding gaat.
Zelfs met https is dit nog een mogelijkheid gezien de hoeveelheid slecht beveiligde Certificaat verstrekkers en mogelijke wildcard certificaten.
Het zou mooi zijn als dit uiteindelijk in alle (veelgebruikte) browsers terecht komt. Dit geeft de mogelijkheid om (gebruiksvriendelijk) standaard alle email te versleutelen, niet alleen de verbinding met de mailserver.
Men legt nu het vertrouwen veelal in de handen bij Google, Microsoft of een ISP-gerelateerde maildienst; het vertrouwen dat de mail die men verstuurt en ontvangt niet ingezien wordt door derden. Met de steeds grotere wordende inzagemogelijkheid van overheden en de overvloed aan recente hacks vind ik dit een eng idee.
@storeman; Je hebt gelijk wat je 2e alinea betreft, beetje een deuk in mijn argument. Echter de javascript van een website kun je bekijken; dus als je dit controleert kun je er zeker van zijn dat je niet gemonitord wordt. En als de data versleuteld op de server opgeslagen wordt, kan een eventuele hack of overheidsinzage deze data niet meer ontsleutelen zonder jouw private key.
Dit soort oplossingen bestaan uiteraard al als plugins, maar die zijn 1. uncommon en 2. ongebruiksvriendelijk.
Men legt nu het vertrouwen veelal in de handen bij Google, Microsoft of een ISP-gerelateerde maildienst; het vertrouwen dat de mail die men verstuurt en ontvangt niet ingezien wordt door derden. Met de steeds grotere wordende inzagemogelijkheid van overheden en de overvloed aan recente hacks vind ik dit een eng idee.
@storeman; Je hebt gelijk wat je 2e alinea betreft, beetje een deuk in mijn argument. Echter de javascript van een website kun je bekijken; dus als je dit controleert kun je er zeker van zijn dat je niet gemonitord wordt. En als de data versleuteld op de server opgeslagen wordt, kan een eventuele hack of overheidsinzage deze data niet meer ontsleutelen zonder jouw private key.
Dit soort oplossingen bestaan uiteraard al als plugins, maar die zijn 1. uncommon en 2. ongebruiksvriendelijk.
[Reactie gewijzigd door geez op maandag 17 september 2012 15:53]
Wat draagt deze API daar precies aan bij? Voor het mailverkeer wat jij suggereert, zijn natuurlijk al lang en breed oplossingen met public/private sleutels. Dit is puur een implementatie in Javascript tussen de browser en de server.
Natuurlijk zou je dit puur en alleen clientside kunnen gebruiken, maar wie zegt dat dit daadwerkelijk zo is? Alles wat je in een browser doet, kan gemonitord worden door de maker van de site. Je bent in zijn pagina. Of het daadwerkelijk gebeurd is natuurlijk een tweede. Het punt is dat ik niet inzie waarom zaken nu veiliger zouden worden.
Natuurlijk zou je dit puur en alleen clientside kunnen gebruiken, maar wie zegt dat dit daadwerkelijk zo is? Alles wat je in een browser doet, kan gemonitord worden door de maker van de site. Je bent in zijn pagina. Of het daadwerkelijk gebeurd is natuurlijk een tweede. Het punt is dat ik niet inzie waarom zaken nu veiliger zouden worden.
Nice!
Kunnen we clientside al het wachtwoord hashen en de hash versturen. Zelfs zonder https kan niemand het wachtwoord dan afluisteren (over wifi ofzo).
Kunnen we clientside al het wachtwoord hashen en de hash versturen. Zelfs zonder https kan niemand het wachtwoord dan afluisteren (over wifi ofzo).
Heel handig, want dan kunnen hackers gewoon de hash als authorisatie token gebruiken.
Uiteraard hash je de server z'n challenge mee.
Of ze nou je wachtwoord of de hash gebruikruiken..... blijft het zelfde.
Deze methode zal een extra beveiliging opleveren voor man in the middle attacks. Zorda een hacker je systeem heeft zal deze sowieso je private key kunnen ontfutselen en zodoende de data weer decrypten.
Deze methode zal een extra beveiliging opleveren voor man in the middle attacks. Zorda een hacker je systeem heeft zal deze sowieso je private key kunnen ontfutselen en zodoende de data weer decrypten.
Ik bedoel dus dat als je zonder https zoals rvec schrijft makkelijk kan sniffen wat er gestuurd wordt. Als het wachtwoord gehasht is dan is dat het token om mee in te loggen. Je kan hier inderdaad omheen werken met een eenmalig bruikbare login token van de server.
En dan? Dan komt er meestal een sessie cookie terug. Aangezien dat allemaal plain text gaat, is het alsnog bingo voor de hacker.
Waar dit wel heel handig voor is, is het signen van data als (web)mails, of het volledig encrypten van data, zodat een cloud dienst niet in staat is de inhoud van de content te bekijken. Ook als mensen je account zouden hacken dan zouden ze de inhoud niet kunnen lezen, tenzij ze ook jouw keystore op jouw computer hebben weten te bemachtigen.
En dan? Dan komt er meestal een sessie cookie terug. Aangezien dat allemaal plain text gaat, is het alsnog bingo voor de hacker.
Waar dit wel heel handig voor is, is het signen van data als (web)mails, of het volledig encrypten van data, zodat een cloud dienst niet in staat is de inhoud van de content te bekijken. Ook als mensen je account zouden hacken dan zouden ze de inhoud niet kunnen lezen, tenzij ze ook jouw keystore op jouw computer hebben weten te bemachtigen.
Nogmaals of ze nu je wachtwoord gebruiken om een sessie tot stand te brengen of een hash van je wachtwoord. Blijft het zelfde. Maar dat is ook niet de intentie van deze api. Uiteraard zou je doormiddel van een sharedkey (via sms ofzo) je wachtwoord kunnen hashen bij versturen zodat dit nooit plain text over het web gaat maar dat is weer een ander verhaal.
Wat hiermee gedaan kan worden is dat alle data van jouw clientsided via javascript ge-encrypt wordt met een sleutel (waarschijnlijk je wachtwoord) waardoor een hacker welke de serversided database bemachtigd (of een man in the middle uitvoert) nooit jouw data kan bekijken zonder jouw wachtwoord.
Wat hiermee gedaan kan worden is dat alle data van jouw clientsided via javascript ge-encrypt wordt met een sleutel (waarschijnlijk je wachtwoord) waardoor een hacker welke de serversided database bemachtigd (of een man in the middle uitvoert) nooit jouw data kan bekijken zonder jouw wachtwoord.
Maar ik heb het over wat rvec zegt, en hij zegt dat zonder https een hash versturen een goed idee is, maar dat is het niet zonder allerlei aanvullende voorwaarden. Hashen != encrypten.
Dat kan allang, er bestaan al jaren cryptografie-libraries voor javascript. Voorbeeld. Voordelen van een dergelijke API zijn vooral het kunnen checken en managen van certificaten - dat kon javascript natuurlijk niet out-of-the-box. Het andere voordeel zal zijn dat encryptie en hashing nu native geïmplementeerd kan worden door de browser, waardoor het een stuk beter performt dan wanneer je het in javascript zelf zou implementeren.Kunnen we clientside al het wachtwoord hashen en de hash versturen
Wat betreft je opmerking: nee, gewoon de hash sturen is niet echt slim, dan kan een man in the middle gewoon herhalen wat jij ooit tegen de server gezegd hebt. Beter is een challenge/response systeem, waarbij de server een 'nonce' stuurt en de client de hash berekent van het wachtwoord icm de nonce. Die nonce is random en elke keer anders, dus er kan niets herhaald worden. Maar om dat te laten werken moet je je wachtwoord toch ooit naar de server hebben gestuurd, en de énige veilige methode is wat dat betreft gewoon HTTPS. En als je toch al HTTPS ondersteunt kun je natuurlijk net zo goed de hele login methode daar gebruik van laten maken waardoor je het hashen ook niet meer nodig hebt.
Daarnaast is er nog het feit dat iemand die verkeer kan afluisteren meestal ook in staat is dat verkeer aan te passen. Als je daar vanuit gaat is de door jouw gesuggereerde methode sowieso een schijnveiligheid - de attacker kan gewoon de pagina zo aanpassen dat het door jou in plain text ingetypte wachtwoord naar hem verstuurd wordt zonder dat jij het doorhebt.
[Reactie gewijzigd door .oisyn op maandag 17 september 2012 16:19]
Een goede en noodzakelijke ontwikkeling, me dunkt.
Het probleem ligt namelijk echt niet altijd bij onwetende gebruikers die desgevraagd hun financiële info naar Nigeria sturen. Er zijn minstens zoveel programmeurs die niet genoeg focus op veiligheid leggen.
Het probleem ligt namelijk echt niet altijd bij onwetende gebruikers die desgevraagd hun financiële info naar Nigeria sturen. Er zijn minstens zoveel programmeurs die niet genoeg focus op veiligheid leggen.
ik kan je hier zeker een voorbeeld opgeven, ook nog wel ergens op het asp.net forum terug te vinden,
een tijd geleden kwam ik op het asp.net forum een programmeur tegen die een bankprogramma aan het maken was echter in het stukje code dat ie gaf was duidelijk dat hij de encryptie pas deed na de post waardoor de encryptie enkel werd gebruikt om de gegevens op te slagen op de database ipv encryptie al voor de post toe te passen.
een tijd geleden kwam ik op het asp.net forum een programmeur tegen die een bankprogramma aan het maken was echter in het stukje code dat ie gaf was duidelijk dat hij de encryptie pas deed na de post waardoor de encryptie enkel werd gebruikt om de gegevens op te slagen op de database ipv encryptie al voor de post toe te passen.
Ik zie zeker wel mogelijkheden. Nadeel is natuurlijk dat je niet meer kunt beveiligen op javascript die de invoer van de gebruiker afvangt, om er vervolgens iets mee te doen. Met andere woorden: De uiteindelijke implementatie moet dusdanig zijn dat fake pagina's die met javascript de input opvangen om vervolgens door te sturen naar een derde parij geen kans hebben. Je kunt niet meer op kritische pagina's javascript uitschakelen, wat in het verleden al wel eens geadviseerd is
.
In het artikel wordt ook gesproken over re-using keys, waarbij twee applicaties onderling toch informatie kunnen uitwisselen
.
Ook zou ik graag in de browser een indicatie willen zien dat de API gebruikt wordt, net als je bij https kunt zien.
.
In het artikel wordt ook gesproken over re-using keys, waarbij twee applicaties onderling toch informatie kunnen uitwisselen
.
Ook zou ik graag in de browser een indicatie willen zien dat de API gebruikt wordt, net als je bij https kunt zien.
Sorry voor de misschien domme vraag. Maar dit is client side .. wat als iemand javascript uitzet..
Het voelt voor mij veiliger om hashes en zo aan de serverside kant te genereren.
Het voelt voor mij veiliger om hashes en zo aan de serverside kant te genereren.
Dan zal er niets werken. Vermoedelijk zal dit icm met AJAX-achtige toestanden gebruikt worden. En aangezien Javascript één van de fundamenten is van AJAX en elke andere vorm van interactiviteit in een webpagina, zal je gewoon een 'dode' pagina hebben die niets verzendt of verwerkt.
Open de bron van een webpagina, dit alles is wat je "client side" noemt.
Deze code kan de gebruiker actief inzien en manipuleren, dus alles wat je client side meestuurt kan de gebruiker zien. Het is dus niet sim om met bijvoorbeeld javascript, met de database te gaan connecten.
Voorbeelden client side: (X)HTML, Javascript, CSS, XML
Aan de andere kant staat "server side", dit is code die EERST uitgevoerd wordt door de server en daarna alsnog omgezet wordt naar client side. server side wordt het wel aantrekkelijk om te verbinden met een databank, de toegangsmethode (username, password, host) wordt simpelweg niet meegestuurd naar de client side code.
Voorbeelden server side: PHP, ASP,
Deze code kan de gebruiker actief inzien en manipuleren, dus alles wat je client side meestuurt kan de gebruiker zien. Het is dus niet sim om met bijvoorbeeld javascript, met de database te gaan connecten.
Voorbeelden client side: (X)HTML, Javascript, CSS, XML
Aan de andere kant staat "server side", dit is code die EERST uitgevoerd wordt door de server en daarna alsnog omgezet wordt naar client side. server side wordt het wel aantrekkelijk om te verbinden met een databank, de toegangsmethode (username, password, host) wordt simpelweg niet meegestuurd naar de client side code.
Voorbeelden server side: PHP, ASP,
Mooi zo. Dus tegen ongeveer 2030 kunnen hiervan gebruik maken? Maak vooral geen haast, W3C.
Lijkt me een strak plan: kunnen ze samen met de browserbouwers eerst eens een veilige browser ontwerpen (met bijbehorende standaarden) 
Ja, inderdaad, het gaat nu ook al zo langzaam of niet??
Op dit item kan niet meer gereageerd worden.
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
