murb hanteert een browser support grading systeem (een idee dat ik ooit heb gekregen van Anselm Hanneman bij het lezen van How to define a browser support level matrix) voor browserondersteuning. We classificeren browsers met een A, B, C of D.
Klasse Omschrijving A Beste gebruikerservaring; alle features werken en weergave is duidelijk. B Alle features werken. Weergave niet altijd optimaal. C Basis functionaliteit werkt (in ieder geval rollen buiten controle (b.v. niet-admin functies)), maar geavanceerdere functies zijn niet altijd beschikbaar. Performance mogelijk niet optimaal. D Wordt niet ondersteund.Veelal kantoortoepassingen, complexe schermen, mobile support is een nice to have.
It is easier said than done: "just stop supporting Internet Explorer (IE)". There are large organizations that require IE for some of their legacy often in-house applications. If you serve these organizations, you might be required to support IE. Even though, globally, roughly only 2% of the users still use this old browser.
For versions before IE the argument has been easy: "We don’t support a browser Microsoft is not supporting," but support for IE11 doesn’t seem to stop anytime soon (see the update below!): The latest IE (IE11)will be supported as long as the last version of Windows that supports it. That means untill support for the current version of Windows has ended.
With the launch of Edge, [Microsoft initially went along with popular demand not to bring support for older engines to their new browser Spartan](https://docs.microsoft.com/en-us/archive/blogs/ie/updates-from-the-project-spartan-developer-works…
Recently I’ve been researching what other Certificate Authorities do within the domain of online generation of certificate requests (and related private keys).
It is tricky territory: JavaScript and Crypto. Or more generic, webapplications and crypto. But with the advance of the WebCryptoAPI some issues that were raised (e.g. insufficient random number generation) by security experts have been addressed, but still: the WebCryptoAPI entry on MDN starts with a fair warning: “If you're not sure you know what you are doing, you probably shouldn't be using this API.”
Why think about a web implementation at all to create a certificate request? Typically tools to generate certificates are hard to use. Just look at the list of options a user has to generate certificates, which are typically all of…
Veilige verbindingen zijn gebaseerd op een keten van vertrouwen. Browsers en computers vertrouwen standaard een beperkt aantal zogenaamde ‘root’-certificaten. Deze root certificaten kunnen gebruikt worden om een groen slotje te geven aan een site. Meestal gebeurd dat met een tussenliggend certificaat: De site betrouwbaar omdat deze Certificaat A heeft welke vertrouwd is omdat het ondertekend is door Certificaat B en Certificaat B wordt vertrouwd omdat het ondertekend is door een root certificaat (de keten kan complexer en langer zijn); een certificaat dat vastgelegd is in de browser of het besturingssysteem. Het is dus belangrijk dat een beheerder van een root certificaat er alles aan doet dat diens vertrouwen niet wordt geschonden. Dat is vorig jaar bij Symantec (het bedrijf dat bekend is geworden met Norton Utilities en later AntiVirus) gebeurd.
Certificaten mogen alleen worden uitgegeven aan eigenaren van een domeinnaam; certificat…
Sometimes I get a bit upset about a state a project I get to work on is in. Recently I came across a project which frontend served over 30 files that could be reduced easily to about 10. I got upset because to me it is like one of the basic things you have to be aware of as a web developer. I told the others working on the project that is a problem that should be fixed, to optimize speed. But later that day, in bed, I started wondering because the pages were served using HTTPS: was I actually correctin stating it as a problem? Well, currently still yes.
I started wondering because I remembered something about 'pipe-lining'. A year ago I turned on the experimental SPDY protocol a year ago, which supports asynchronous pipe-lining. Pipe-lining allows browsers to request all files in one request, which diminishes the reason why a developer should try to reduce the numbers of file…
In een vorige post over het concept achter de hypes schreef ik over hoe ik onderscheid maak tussen een duurzame trend, het concept, en een hype.
Achteraf oordelen dat iets een hype was is echter gemakkelijk, dus hierbij een voorspelling. Even de 'regels' herhalen:
> De trend (en doel) voor het internet, die zich vanaf het begin heeft ingezet, is: informatie zo goedkoop, handig en snel mogelijk overal beschikbaar maken. Big data, personal cloud, Twitter, prijsvergelijkers, en vele andere hypes passen hier in. Dat is wat ‘de technologie wil’. Maar of je zou moeten investeren in de hype voor de langere termijn moet er toch op zijn minst aan de volgende voorwaarden worden voldaan: > 1. Het moet open zijn > 2. Het moet aanpasbaar zijn > 3. Het moet flexibel zijn.
Hypes vroegtijdig herkennen is niet alleen leuk om te doen, het houd je ook nuchter in een snel veranderende wereld. Goed. Met de bovengenoemde reg…
Dit artikel van murblog van Maarten Brouwers (murb) is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie .