Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 38 reacties

Google heeft in een vroege build van zijn Chrome-browser uitgebreide informatie over websitebeveiliging toegevoegd. Gebruikers kunnen zien welke encryptie wordt gebruikt, van zowel de website die wordt bezocht als extern ingeladen content.

Ilya Grigorik, die bij Google werkt als ontwikkelaar, kondigde de nieuwe functionaliteit aan op een post op het sociale netwerk Google+. De beveiligingsfeature zit in een zogenaamde Canary-build van de Chrome-browser; een kanaal dat de internetgigant gebruikt om testversies van zijn software uit te brengen.

In de nieuwe Chrome-build krijgen gebruikers in het ontwikkelaarspaneel een extra kopje te zien. Dit nieuwe beveiligingspaneel toont of de website die de gebruiker bezoekt is beveiligd met een geldig encryptiecertificaat. Ook van andere websites waarvan op de webpagina content wordt getoond, bijvoorbeeld van advertentienetwerken, wordt getoond hoe het met de beveiliging van de verbinding zit.

Met de nieuwe feature wil Google meer inzicht geven in de beveiliging van de bezochte websites. Wanneer het paneel naar de Chrome-builds voor het grote publiek komt is nog niet duidelijk; hierover is verder geen informatie verstrekt.

Chrome security panel

Moderatie-faq Wijzig weergave

Reacties (38)

Goed idee, ook een dikke rode balk voor onbeveiligde verbindingen zou wel goed zijn, of in ieder geval een waarschuwing geven als er inloggegevens verstuurd gaan worden.
Ik ging laatst bij een goedkope Europese hoster inloggen, blijkt achteraf dat de verbinding niet versleuteld was, https gaf zelfs een certificaat-fout. Natuurlijk dikke fout van de hoster of een mitm-aanval maar toch.
Firefox Nightly (te vergelijken met Chrome Canary) markeert onbeveiligde verbindingen al als onveilig.
Firefox Nightly (te vergelijken met Chrome Canary) markeert onbeveiligde verbindingen al als onveilig.
Firefox 'gewoon' ook al voor jaren. Ze vervangen nu alleen het open-slot icoontje met een slot-icoontje met een rode streep erdoorheen. En dat doen ze alleen voor loginpagina's. En de echte waarschuwing zit achter een knop waar de gebruiker eerst zijn muisaanwijzer op moet zetten.

In het begin krabt de eindgebruiker nog achter zijn oor, maar daarna gaat die gewoon weer vrolijk door. En terecht. Waarom moet de gebruiker controleren of zijn verbinding veilig is? Het is aan zijn apparatuur en aanbieders om een veilige verbinding op te leveren. Dat de organen die webstandaarden verzinnen samen met ontwikkelaars van browsers en webservers gefaald hebben in het verplicht beveiligen van het HTTP verkeer moet niet op de gebruiker afgeschoven worden.

Hoe had je het overheden al heel lastig kunnen maken zonder de gebruiker lastig te vallen? Al het HTTP verkeer standaard van encryptie voorzien, maar niet van authenticatie. Zo sluit je in ieder geval passieve man-in-the-middle aanvallen uit (zoals monitoring door overheden). Om zoiets door te voeren zal je echter als organisatie verantwoordelijk voor het web moeten samenwerken met andere organisaties. Dat is best moeilijk! Laten wij daarvoor in plaats maar de (niet-technische) eindgebruiker lastig vallen. Die heeft immers geen noemenswaardige stem in dit proces, dus zal niet protesteren tegen wat hem wordt opgelegd. |:(

[Reactie gewijzigd door The Zep Man op 25 oktober 2015 11:39]

Er zijn meerdere redenen waarom er nog zoveel websites niet beveiligd zijn. Dat is echt niet alleen luiheid of onwetendheid van de ontwikkelaars.

Ten eerste vraagt encryptie ook iets van de computer en server. Het leverde vroeger merkbaar vertraging op. Tegenwoordig zijn onze PC's en smartphones snel genoeg, maar 20 jaar geleden toen het internet nog in opkomst was was de hardware niet snel genoeg om alle verbindingen te versleutelen. Niet voor niks had men vroeger de gewoonte om alleen de registratie en login pagina's te beveiligen.

Ten tweede is daar het legacy probleem (zie punt 1). Er zijn al super veel websites en die moeten allemaal overstappen op HTTPS. Dat probleem is zo mogelijk nog groter dan iedereen op IPv6 over te laten gaan.

Ten derde is er het certificaat. Dit kost gewoon geld. Het gaat al snel richting de 100 euro per jaar en voor een hoop kleine websites is dat teveel. Pas nu zie je initiatieven zoals Let's Encrypt die gratis certificaten gaan aanbieden.

Ten vierde is er niet één organisatie verantwoordelijk voor het internet. Juist alle verschillende organisaties moeten samen tot een oplossing komen.

De eindgebruiker targetten zou dus juist wel eens de slimste strategie kunnen zijn. Als die actief gaan vragen naar beveiligde verbindingen dan ontstaat er druk op de verschillende marktpartijen om die te leveren.

Overigens is dat zo te zien niet wat Chrome hier doet, want wat ik zie in de screenshot is de Developer Tool en die weten de meeste mensen niet te vinden...
Er zijn meerdere redenen waarom er nog zoveel websites niet beveiligd zijn. Dat is echt niet alleen luiheid of onwetendheid van de ontwikkelaars.

Ten eerste vraagt encryptie ook iets van de computer en server. Het leverde vroeger merkbaar vertraging op. Tegenwoordig zijn onze PC's en smartphones snel genoeg, maar 20 jaar geleden toen het internet nog in opkomst was was de hardware niet snel genoeg om alle verbindingen te versleutelen. Niet voor niks had men vroeger de gewoonte om alleen de registratie en login pagina's te beveiligen.
'Vroeger' is niet nu.
Ten tweede is daar het legacy probleem (zie punt 1). Er zijn al super veel websites en die moeten allemaal overstappen op HTTPS. Dat probleem is zo mogelijk nog groter dan iedereen op IPv6 over te laten gaan.
Moet je zien hoe snel sites encryptie gaan ondersteunen wanneer alle browsers dit verplicht stellen. Leg het probleem niet bij de eindgebruiker (geen geld en geen tijd), maar bij de aanbieder.
Ten derde is er het certificaat. Dit kost gewoon geld. Het gaat al snel richting de 100 euro per jaar en voor een hoop kleine websites is dat teveel. Pas nu zie je initiatieven zoals Let's Encrypt die gratis certificaten gaan aanbieden.
Onzin. Je kan al jarenlang gratis certificaten verkrijgen via StartSSL. En een wildcard certificaat hoeft niet meer te kosten dan 75 euro op jaarbasis (bijvoorbeeld). Een gewoon certificaat hoeft niet meer te kosten dan 8 euro per jaar. Zelfs met de investering van een domeinnaam zelf zijn de kosten om een eigen plek te hebben op het Internet minimaal. En voor bedrijven zijn zulke bedragen helemaal niets als je ziet wat zij terugverdienen door aanwezigheid op het Internet.
Ten vierde is er niet één organisatie verantwoordelijk voor het internet. Juist alle verschillende organisaties moeten samen tot een oplossing komen.
Dat is wat ik schreef. Maar kennelijk is dat erg moeilijk en wordt daarvoor in plaats de makkelijke weg gekozen.
De eindgebruiker targetten zou dus juist wel eens de slimste strategie kunnen zijn. Als die actief gaan vragen naar beveiligde verbindingen dan ontstaat er druk op de verschillende marktpartijen om die te leveren.
De eindgebruiker gaat niet actief vragen naar beveiligde verbindingen. De eindgebruiker is er namelijk alleen in geïnteresseerd dat iets werkt, veilig of niet.

Het blijft een zwaktebod dat de industrie hier geen goed antwoord op kan verzinnen, maar het weer op de eindgebruiker moet afschuiven. Technologie is ter ondersteuning, niet het doel. Lever dus een goed product en geen doos met gereedschap waar de gebruiker niet veilig mee om kan gaan.
Overigens is dat zo te zien niet wat Chrome hier doet, want wat ik zie in de screenshot is de Developer Tool en die weten de meeste mensen niet te vinden...
Dus de toegevoegde waarde is nog minder van belang, want deze informatie was al opvraagbaar zonder Developer Tools.

[Reactie gewijzigd door The Zep Man op 25 oktober 2015 15:05]

Moet je zien hoe snel sites encryptie gaan ondersteunen wanneer alle browsers dit verplicht stellen.
Ook hiervoor geldt: Dit is niet onder controle van één partij. Je zult zowel Microsoft, Apple en Google alsook Mozilla en (in mindere mate) Opera op één lijn moeten krijgen. Als een browser maker dit in zijn eentje probeert pleegt hij 'zelfmoord' want gebruikers zijn zo weg als hun sites het niet meer doen.
Je kan al jarenlang gratis certificaten verkrijgen via StartSSL
Dat heb ik dus zelf ook geprobeerd, maar Google meldt dan (i.i.g. voor het certificaat dat ik kreeg) dat het certificaat niet vertrouwd is. Je hebt dus wel een beveiligde verbinding, maar alsnog met een rood kruis door het 'https://' deel van de url heen.

Je kunt wel zeggen dat het onzin is, maar ik vind 100 euro (of 75, jij zegt het) dus veel geld voor een persoonlijk blogje of zo en gratis is mij tot op heden nog niet gelukt. Er zijn miljarden websites en die zijn niet allemaal van grote bedrijven die bulken van het geld.
Ten vierde is er niet één organisatie verantwoordelijk voor het internet. Juist alle verschillende organisaties moeten samen tot een oplossing komen.
Dat is wat ik schreef. Maar kennelijk is dat erg moeilijk en wordt daarvoor in plaats de makkelijke weg gekozen.
Ja los jij het anders even op?

Dit is toch precies het hele probleem? 'Kennelijk is dat erg moeilijk' is gewoon een super understatement, want het is niet erg moeilijk, het is onmogelijk. En wie moeten we dat kwalijk nemen? Iedereen? Niemand? Als een scenario vereist dat tientallen marktpartijen onafhankelijk van elkaar hetzelfde doen, waarbij ook nog eens geldt dat dit voor individuele partijen nadelig kan uitpakken, dan is het gewoon een droom scenario dat nooit uit zal komen. Als Firefox vandaag weigert onbeveiligde sites te tonen dan zijn ze morgen hun userbase kwijt. Alleen als alle browsers dat tegelijk zouden doen zou het effect kunnen hebben, maar zelfs dan loop je grote kans dat er een fork komt waarin het uitgezet is en die ineens heel populair wordt.
De eindgebruiker gaat niet actief vragen naar beveiligde verbindingen.
Net zoals die niet actief gaat vragen naar biologisch vlees?

I beg to differ. Mensen kunnen. mits goed geïnformeerd, wel degelijk complexe problemen begrijpen en vragen naar oplossingen.
Het blijft een zwaktebod dat de industrie hier geen goed antwoord op kan verzinnen
'De industrie' is een oversimplificatie. Alsof er ergens een groepje mensen zit dat deze beslissing kan nemen. Maar nogmaals, los dit probleem gewoon op. Of ga je beweren dat jij daartoe niet bij machte bent? Welkom bij de club want er is niemand, niet Microsoft, niet Google, niet W3C, niet IANA die genoeg macht heeft om dit zomaar af te dwingen.

Bedenk dit: IPv6 heeft grote voordelen t.o.v. IPv4 en er is ook nog eens een stok achter de deur in de vorm van een oprakende IPv4 adresruimte en nog duurt het jaren om de overstap te maken en gaat dat maar heeeeel moeizaam.
[...]


Ook hiervoor geldt: Dit is niet onder controle van één partij. Je zult zowel Microsoft, Apple en Google alsook Mozilla en (in mindere mate) Opera op één lijn moeten krijgen. Als een browser maker dit in zijn eentje probeert pleegt hij 'zelfmoord' want gebruikers zijn zo weg als hun sites het niet meer doen.
Dus die partijen moeten samenwerken in plaats van het de eindgebruiker lastig maken.
Dat heb ik dus zelf ook geprobeerd, maar Google meldt dan (i.i.g. voor het certificaat dat ik kreeg) dat het certificaat niet vertrouwd is. Je hebt dus wel een beveiligde verbinding, maar alsnog met een rood kruis door het 'https://' deel van de url heen.
Zie deze issue waar het mogelijk mee te maken heeft.
Je kunt wel zeggen dat het onzin is, maar ik vind 100 euro (of 75, jij zegt het) dus veel geld voor een persoonlijk blogje of zo en gratis is mij tot op heden nog niet gelukt. Er zijn miljarden websites en die zijn niet allemaal van grote bedrijven die bulken van het geld.
Je leest mijn post niet goed. 8 euro per jaar is niet veel voor je blogje.
Ja los jij het anders even op?
Als ik commentaar geef op films, muziek, etc. dan krijg ik ook niet het argument naar mijn hoofd geslingerd dat ik geen films of muziek maak. Dit argument is een zwaktebod vanuit jouw kant. Jammer, maar het toont impliciet aan dat je het met mij eens bent dat eindgebruikers het niet op kunnen lossen en machteloos zijn. Bedankt daarvoor. :)
Dit is toch precies het hele probleem? 'Kennelijk is dat erg moeilijk' is gewoon een super understatement, want het is niet erg moeilijk, het is onmogelijk. En wie moeten we dat kwalijk nemen? Iedereen? Niemand? Als een scenario vereist dat tientallen marktpartijen onafhankelijk van elkaar hetzelfde doen, waarbij ook nog eens geldt dat dit voor individuele partijen nadelig kan uitpakken, dan is het gewoon een droom scenario dat nooit uit zal komen.
'Onmogelijk' bestaat niet. Laat de grootste partijen het tegelijk doen. De rest volgt wel. Het is op de lange termijn immers ook in het voordeel van de grootste partijen.
Als Firefox vandaag weigert onbeveiligde sites te tonen dan zijn ze morgen hun userbase kwijt. Alleen als alle browsers dat tegelijk zouden doen zou het effect kunnen hebben, maar zelfs dan loop je grote kans dat er een fork komt waarin het uitgezet is en die ineens heel populair wordt.
Dus je doet het niet alleen voor browsers, maar ook voor webservers. Daar komt straks Let's Encrypt bij, die het beheer daarvan kan automatiseren. Een gebruiker gaat niet miepen als het onveilig is, maar wel als het niet meer werkt.
Net zoals die niet actief gaat vragen naar biologisch vlees?
Wat is de proportie van consumenten die vraagt om 'biologisch' vlees? Zet dat uit tegenover de hoeveelheid consumenten die gewoon normaal vlees kopen. Mogelijk zit je op dezelfde ratio als eindgebruiker/power users op het web.
I beg to differ. Mensen kunnen. mits goed geïnformeerd, wel degelijk complexe problemen begrijpen en vragen naar oplossingen.
Ten eerste verschillen wij over de mening of 'mensen' dat kunnen. Het gaat echter niet om kunnen, maar ook om willen. Eindgebruikers hebben hier geen tijd en energie voor.

Je hebt echt de mentaliteit van een tweaker: eindgebruikers moeten het maar begrijpen. Helaas gaat dat excuus niet meer op in de 21e eeuw.
'De industrie' is een oversimplificatie. Alsof er ergens een groepje mensen zit dat deze beslissing kan nemen. Maar nogmaals, los dit probleem gewoon op. Of ga je beweren dat jij daartoe niet bij machte bent? Welkom bij de club want er is niemand, niet Microsoft, niet Google, niet W3C, niet IANA die genoeg macht heeft om dit zomaar af te dwingen.
Gezamenlijk hebben ze dat wel, en met samenwerking kan het opgelost worden. Hoe is men anders tot de huidige veelgebruikte webstandaarden gekomen?
Bedenk dit: IPv6 heeft grote voordelen t.o.v. IPv4 en er is ook nog eens een stok achter de deur in de vorm van een oprakende IPv4 adresruimte en nog duurt het jaren om de overstap te maken en gaat dat maar heeeeel moeizaam.
Wat merkt de eindgebruiker hiervan, tot nu toe? Niets. Het is dus geen groot probleem op het moment. Ja, het is een probleem, maar niet iets dat op de achtergrond tijdelijk gemitigeerd kan worden.

[Reactie gewijzigd door The Zep Man op 26 oktober 2015 13:15]

Dit argument is een zwaktebod vanuit jouw kant.
Nee.

Je blijft zeggen dat anderen ('de industrie') het maar even samen op moeten lossen. Die anderen hebben echter precies hetzelfde probleem als jij. Ze zijn er niet toe bij machte.

Dit geldt voor de browser bouwers, zowel als de webserver makers. Er zijn tig verschillende webservers. Dus stel dat Apache dienst gaat weigeren tenzij je een certificaat configureert... Wat er dan gebeurt is niet dat iedereen een certificaat configureert hoor. Nee, mensen stappen gewoon over naar een andere webserver die dit niet probeert af te dwingen.
'Onmogelijk' bestaat niet.
Op zich een hele goede mentaliteit hoor... Maar alleen als het over je *eigen* inzet gaat. Als jij denkt dat het kan, ga ervoor zou ik zeggen. Apache Web Server is Open Source dus je kunt beginnen met een fork te maken en je wijziging in te bouwen. Hetzelfde geldt voor Chromium en Firefox.

Echter als je het hebt over iets wat *anderen* moeten gaan doen dan is dit niet echt een houding waar je ver mee komt.

Sowieso vraag ik me af wat nu je concrete plan is? Alle browsers tegelijk updaten zodat ze geen onversleutelde pagina's tonen? En alle webservers tegelijk updaten dat ze geen onversleutelde pagina's meer serveren?

Sorry maar dat plan is wel degelijk gewoon onmogelijk.
Belangrijkste probleem is als je meerdere domeinen op 1 ip-nummer hebt zoals veel kleine webservers bij hostingproviders. Dat is een stuk lastiger te configureren dan als je je ip-nummer voor je alleen hebt.

En dan nog: behalve voor het inloggen zie ik geen toegevoegde waarde voor https bij bijvoorbeeld tweakers waar publiekelijk nieuws en informatie gepubliceerd wordt of als je een pb stuurt de crew van tweakers ook gewoon mee kan kijken. Een overheid of andere privacyschender heeft daar geen enkel belang bij.
Klopt. Hoewel dit met verdwijnen van windows xp en de opkomst van de SSL extentie SNI wel grotendeels is opgelost inmiddels. Deze extentie geeft de domeinnaam mee tijdens de SSL verbinding en maakt het mogelijk meerdere domeinen op een enkel IP te draaien.

[Reactie gewijzigd door MoonWatcher op 26 oktober 2015 07:27]

Het ondertekenen van certificaten zorgt voor authenticatie. Voor puur encryptie is het niet noodzakelijk.

Men kan best een opportunistic encryption mogelijkheid aan aan HTTPS toevoegen. Dat is geen nieuw of ingewikkeld concept. Protocollen als IPSec, bittorrent, tor, etc. kunnen het ook.

Als ze dat zouden doen is met een simpele update van de gangbare web servers en browsers in 1 klap bijna het hele internet versleuteld.

Vroeger was het argument al snel dat encryptie zonder authenticatie geen meerwaarde heeft, maar dat lijkt me na Snowden geen goede reden meer.
Ja zou ik ook niet tegen zijn.

Probleem is wel dat je zonder authenticatie (met wie praat je eigenlijk) wel bloot staat aan Man in the Middle aanvallen... En doordat je op HTTPS zit kun je een gevoel van schijnveiligheid krijgen. MitM aanvallen zijn minder ingewikkeld dan het lijkt. Ook dit zou dus voorlichting aan de eindgebruiker vergen.

Uiteindelijk is het met beveiliging zo dat de eindgebruiker betrokken is en moet zijn. Al is het maar om te controleren dat hij inderdaad op zijn bank zit en niet op een andere site die er veel op lijkt. Daar helpt geen encryptie tegen namelijk.

Verder hoor ik meerdere mensen zeggen 'we leven nu' maar dat is een totaal onrealistische manier om tegen het internet aan te kijken. Er zijn miljarden web pagina's en nog veel meer individuele gebruikers. Als je browser / OS / site / router / netwerkkaart / wifi dongle etc etc niet werkt met de bestaande situatie (die van vroeger dus) dan koopt niemand het.

Backwards compatibility is niet optioneel op het internet. Het is een must. Hierdoor beweegt het web als een gletsjer. Langzaam maar zeker. Niemand kan dit overnight oplossen.
Je eerste punt over dat encryptie vroeger vertraging opleverde en computers niet snel genoeg waren kan de prullenbak in. We leven nu en niet vroeger. Zoals je zelf ook al aangeeft is er wat performance betreft geen reden meer om het niet veilig te doen.

Je tweede punt slaat ook als een tang op een varken. Er moeten al veel sites overstappen op https dus dat vormt dan een probleem voor sites om het niet ook te doen?

Certificaten zijn duur maar de grotere en zeker commerciële sites moeten dat bedrag kunnen ophoesten.

Dat meerdere organisaties verantwoordelijk zijn voor internet wil toch niet zeggen dat je als website bouwer dan maar geen https invoert? Wat is dat voor kromme redenering? Ondanks de vele organisaties voeren heel veel site wel https in. Je zegt het zelf ook al. Dus nogmaals geen reden voor anderen om het zelf ook niet te doen.

Je punten gaan in mijn ogen niet op. Het is laksheid van de ontwikkelaars of gierigheid van de bedrijven om https niet door te voeren.
Ik betaal 60 per twee jaar voor een onbeperkt aantal sites. Zo duur vind ik dat niet.
met onbeperkt aantal sites bedoel je onbeperkt aantal domeinnamen? mag ik vragen waar?
Ten eerste vraagt encryptie ook iets van de computer en server. Het leverde vroeger merkbaar vertraging op. Tegenwoordig zijn onze PC's en smartphones snel genoeg, maar 20 jaar geleden toen het internet nog in opkomst was was de hardware niet snel genoeg om alle verbindingen te versleutelen.
Precies, en de servers trokken dat niet toen! Ik weet nog wel dat er speciale kaarten voor waren , misschien nog wel. Maar je moet alleen versleutelen wat de moeite waard is. dus spacer.gif bijvoorbeeld heb ik liever normaal via HTTP om maar iets te noemen.
Zit ook Fx 42 beta 64 bit die ik gebruik. Melding krijg ik op inoreader, omdat met de httpsversie de previewfunctie niet werkt. Gebruik ik, omdat ik niet steeds een tab wil openen, maar de feed gewoon in inoreader te lezen ;)
Ik denk dat dat inderdaad goed voor de bewustwording is. Misschien haalt dat meer websites over om ook certificaten te gaan gebruiken, hoewel het voor sommige sites een dilemma (plan: Dilemma: moet Tweakers https inzetten?) kan zijn.

Verder is er misschien wel de kans dat gebruikers denken dat een website met een versleutelde verbinding en certificaat als veilig beschouwd kan worden, terwijl de veiligheid ook van andere dingen afhankelijk is.
Dat zou geen bottleneck meer mogen zijn. Alle bedrijven die vinden dat performance boven beveiliging gaat zijn volgens mij verkeerd bezig.
Er bestaan daarvoor SSL Offloaders en je kan die toch inzetten om dit geheel op te nemen?
Probleem is dat die niet gratis zijn natuurlijk, maar is user security en site security niet belangrijker dan performance en een goede mix van de twee te bekomen?

Anyway, goed dat er aan gedacht wordt door de website ontwikkelaars, maar vrees dat dit in final builds als een optie zal worden weergegeven en niet als een standaard feature? Gewone gebruikers weten niet hoe ze hier mee om moeten.

Men zal een manier moeten vinden om de gebruikers steeds weer op te voeden en dit dan te integreren in de surf experience.
Het probleem met https is dat browser bouwers https als alles of niks hebben behandeld, maar tegelijk http aan de gebruiker te presenteren als OK.

Daardoor gaan sites nog niet over, omdat mixed cobtent in sommige browsers waarschuwingen genereert.
terecht van de browser, anders weet je als gebruiker niet wat er precies versleuteld is en wat niet.
Nee, b. V. self signed is veilger dan http, maar geeft grote enge melding.
Het punt met rood en groen samen is dat kleurblinden er geen kaas van maken.

Firefox is in de nightly overigens begonnen de gebruiker te waarschuwen wanneer een password input op een pagina staat zonder https verbinding.

https://ma.ttias.be/firef...orms-in-http-as-insecure/
Dat is heel vervelend voor kleurenblinden, maar dat hoeft niet leidend te zijn.

Veel mensen kunnen wel het onderscheid maken en het is een veelgebruikte kleurcodering, dus reden te meer om dat te gebruiken als standaard. Voor kleurenblinden kun je dan een optie inbouwen om het verschil op een andere manier duidelijk te maken.
Daarom staat er meestal een icoontje bij waardoor ook een kleurenblinde de boodschap begrijpt
Firefox heeft sinds enige tijd ook al zo'n "Security Panel", met wat meer technische details over de SSL/TLS setup en ciphers: https://ma.ttias.be/secur...ctor-lands-in-firefox-37/

Het blijft, voor zowel Chrome als Firefox, nog wel een beperkte uitwerking: er kan veel gedaan worden met zo'n security panels - het is goed nieuws dat er nu alvast één is, maar in de toekomst zal dit nog fel evolueren.
Schaamteloze reclame naar je eigen website. Not done vind ik. Als je je artikel nu in een quote had opgenomen ok..

Ben het overigens met je stelling eens dat dit zal evolueren. Nu Google ook hoger gaat indexeren zal misschien het alles niks verhaal veranderen zodat gegevens die veilig moeten zijn dat ook kunnen zijn.
We zitten op Tweakers. Leden hier zijn actief op internet, ook met eigen sites. Als iemand dan over een bepaald topic geblogged heeft mag hij daar dan niet naar linken als het gewoon on topic is?

Er wordt hier de hele dag gelinked naar sites van miljardenbedrijven zoals Apple en Samsung maar een linkje naar iemands persoonlijke blog is 'schaamteloze reclame'? Het moet niet gekker worden.
Agree, had ik anders moeten verwoorden. To be honest, was aangenaam verrast dat anderen naar mijn blog linkten (zonder mijn invloed) en in de "adrenaline" iets te ver in mee gesleept. My bad, won't happen again.
Interessant dat ze HSTS ook melden, vaak staat dit uit i.v.m. performance/overhead op request.

[Reactie gewijzigd door djwice op 25 oktober 2015 17:50]

Reden temeer voor grote bedrijven om hun beveiliging in orde te houden. Hopelijk volgen de andere 3 grote browser leveranciers snel met soortgelijke implementaties.
Die zijn er wel.

Dit is een hulpmiddel voor ontwikkelaars. Een soort debug optie.

Voor eindgebruikers hebben alle grote browsers al maatregelen om het verschil tussen http en https en de verschillende soorten certificten aan te geven

slotje open / dicht
slotje met kruis erdoor
adresbalk groen of rood maken
waarschuwingspagina voordat je naar een site met ongeldig certificaat kunt gaan
etc
Zou cool zijn als ze in ontwikkelaars modus ook de rating van https://www.ssllabs.com/s...net&hideResults=on&latest
voor alle domeinen op de pagina kan tonen incl. eventuele risks/verbeter tips.

En idem voor csp / cors en ander handigs.

Ik zie op veel sites dat dit nog niet optimaal is ingericht, vaak door onwetendheid over de mogelijkheden.

[Reactie gewijzigd door djwice op 25 oktober 2015 17:11]

Safari op OSX opent volgens mij zulke sites niet eens?
edit. reactie had ergens anders gemoeten.. :/

[Reactie gewijzigd door Menesis op 25 oktober 2015 21:05]

Google+ wordt wel gebruikt en gelezen.
Ik wou dat Chrome OS meer te bieden had. Meer processor en ram geheugen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True