Firefox 83 met 'https-only'-modus verschijnt

Mozilla heeft Firefox 83 uitgebracht. De ontwikkelaars van de browser hebben een optie voor https-only toegevoegd. Zodra een gebruiker een website bezoekt die niet via https beschikbaar is, krijgt de gebruiker een waarschuwing.

De https-only-optie is standaard niet geactiveerd. Gebruikers kunnen dat vanaf versie 83 van Firefox, die dinsdag is verschenen, instellen bij het Privacy & Security-menu. De modus is voor alle vensters of alleen voor privévensters in te schakelen. De browser zal dan alleen nog sites die https ondersteunen direct openen.

Als een gebruiker een site wil bezoeken die nog niet via https beschikbaar is, toont Firefox een waarschuwing dat een beveiligde verbinding niet te maken is. De gebruiker kan die waarschuwing negeren en de site toch bezoeken, Firefox schakelt de https-only-modus dan tijdelijk voor die site uit. Via het slotje in de url-balk is de modus ook handmatig uit te zetten, bijvoorbeeld als sites er niet correct uitzien omdat ze deels nog via http werken, wat met bijvoorbeeld afbeeldingen het geval kan zijn.

Een andere wijziging bij versie 83 van Firefox is dat de prestaties van JavaScript-engine SpiderMonkey verbeterd zijn en dat deze 8 procent minder geheugen inneemt. Ook is pinch-to-zoom voor webpagina's ingeschakeld voor touchscreens van Windows-apparaten en het trackpad van Macs. Verder kunnen gebruikers voortaan met de pijltjestoetsen vooruit- en terugspoelen bij video's die picture-in-picture draaien.

Inmiddels is duidelijk dat de volgende versie van Firefox, versie 84, de laatste is die nog npapi-plug-ins draait. Bij versie 85 laadt de browser npapi-plug-ins niet meer. Npapi is verouderde en onveilige plug-in-technologie, die te herleiden is tot Netscape Navigator 2.0 uit 1995. Mozilla staakte de ondersteuning al bij Firefox 52 in 2017, maar ook Adobe Flash was een npapi-plug-in en daarvoor bleef ondersteuning aanwezig.

Reacties (65)

[Uchy]

Ik vind dat er weinig aandacht wordt geschonken aan de beoogde snelheids-verbeteringen. Wel iets over 8% minder geheugen, maar niets over 15%/12% snelheidswinsten:

Firefox keeps getting faster as a result of significant updates to SpiderMonkey, our JavaScript engine, you will now experience improved page load performance by up to 15%, page responsiveness by up to 12%, and reduced memory usage by up to 8%. We have replaced part of the JavaScript engine that helps to compile and display websites for you, improving security and maintainability of the engine at the same time.

Wel benieuwd overigens of dat ook ergens is gebenchmarked Ik vind alleen heel oude benchmarks uit de nightly tijd...

[SilverRST]

En hoe zit het dan met Youtube? Youtube draait verschrikkelijk wanneer je deze zonder extensies gebruikt. Voorlopig update ik Firefox even niet.

[Blinkin]

Komt dat niet door de redesign van YouTube? Meen dat ze een bepaalde verouderde API gebruiken die niet langer ondersteunt wordt behalve door Chrome waardoor alle andere browsers veel trager zijn op YouTube terwijl er al lang nieuwere versies zijn die andere browsers wel ondersteunen.
Maar kan zijn dat dit al iets heel oudse is.

[DutchKevv]

Het komt grotendeels door het verlaten van het polymer framework.

Google wedde op meerdere paarden waarvan Angular gewonnen heeft, polymer word praktisch niet meer doorontwikkeld (volgens mij) door Google

YouTube was een beetje het proefkonijn.

[Blinkin]

Aah dat verklaart een hoop inderdaad. Angulsris mij ook bekender.

[SilverRST]

Nee, Google heeft dat met opzet gedaan zodat gebruikers sneller gaan neigen naar Chrome.

https://addons.mozilla.or.../addon/fast-youtube-load/

Van de link:

YouTube page load is 5x slower in Firefox than in Chrome because YouTube's Polymer redesign relies on the deprecated Shadow DOM v0 API only implemented in Chrome.

[cnieuweboer]

Dat is al een tijdje niet meer nodig. Youtube laadt weer prima in Firefox tegenwoordig. En Chrome heeft Shadow DOM v0 verwijderd in versie 80, zie https://chromestatus.com/feature/4507242028072960

[Omega]

Deze nieuwe patches zien wel enkele regressies in synthetische benchmarks en dit is ook bekend bij Mozilla.

Hier zijn benchmarks van een maand geleden, veel verschil zit er niet tussen deze nightly build en wat nu in stable is beland:
https://www.phoronix.com/...e&item=firefox-83-nightly

[cnieuweboer]

Bekend maar verbeteren van synthetische benchmark scores heeft (terecht) een vrij lage prioriteit.

[TweakerPas]

Firefox heeft sinds versie 82 nog steeds een gigantische bug m.b.t. bonprinters.
Vanaf versie 82 printen veel bonprinters ineens niet meer goed, dit is door velen gemeld bij Firefox, maar bij versie 83 zie je nog steeds geen verbetering hierin. De printers printen ineens blanco`s of een paar cm niets.

[xSNAKEX]

Heb je misschien een linkje hiervan?

[TweakerPas]

https://www.bleepingcompu...-printing-issues-crashes/

https://techdows.com/2020...website-login-issues.html

Dit zijn een aantal linkjes waarin ze het ook melden.
Bij mij printen 350 series Bixolon printers alleen nog maar een stukje wit met alleen het woord firefox erop.
Terwijl in de vorige versie de bonnen perfect eruit kwamen.

Vervolgens gedowngrade naar versie 81 en alles draait weer als vanouds.
Auto updates eerst maar uitgeschakeld, daar we het bij een aantal mensen gebruiken voor een bestelsysteem.

Test met beta 83 gedaan, een ook daar dezelfde issues nog aanwezig.

[Reactie gewijzigd door TweakerPas op 28 juli 2024 02:44]

[Munchie]

Voor het lokale netwerk lijkt Firefox een uitzondering te maken.

In https-only mode springt mijn verbinding automatisch naar http als ik verbinding maak met mijn Ziggo modem, die tevens ook enkel via http te benaderen lijkt. (En een connection time-out geeft als ik https forceer.)


Edit:
https-only ook op het lokale netwerken activeren kan door in about:config dom.security.https_only_mode.upgrade_local op true te zetten.

[Reactie gewijzigd door Munchie op 28 juli 2024 02:44]

[84hannes]

17 november 2020 16:34
Voor het lokale netwerk lijkt Firefox een uitzondering te maken.

In https-only mode springt mijn verbinding automatisch naar http als ik verbinding maak met mijn Ziggo modem, die tevens ook enkel via http te benaderen lijkt. (En een connection time-out geeft als ik https forceer.)

Op je lokale netwerk https gebruiken heeft ook weinig zin. Ten eerste kun je voor een op-adres of een lokale domeinnaam (bijvoorbeeld router.local) geen certificaat aanvragen, dus moet je handmatig een alternatieve certificaatautoriteit op al je browsers instellen. Ten tweede beschermt https je slechts tegen man-in-the-middle-aanvallen: die zijn er op je lokale internet veel minder vaak dan op het grote boze internet.

[Reactie gewijzigd door 84hannes op 28 juli 2024 02:44]

[Call of Duty]

Hangt dat niet van de risico-analyse van je netwerk af? Kan me voorstellen dat er partijen zijn die vast een stap vooruit willen denken in de scenario's en in het scenario dat hun netwerk gepenetreerd is zit er iemand intern, toch? Als je dan ook voor intern verkeer https hebt, is het alweer een stuk lastiger om verkeer af te tappen lijkt me zo.

[84hannes]

Ik kan me daar inderdaad iets bij voorstellen. Het certificatenprobleem is uiteindelijk wel op te lossen door intern domeinnamen te gebruiken die extern geldig zijn, of door inderdaad al je browsers correct te configureren. Dat vraagt echter nogal wat expertise: wellicht een about:config-optie?

[Call of Duty]

Ja dat vergt wel even wat klussen aan de configuraties. Maar ik denk dat bedrijven die met dit soort risico's rekening houden wel een IT consultant kunnen inhuren of zelf al een security tech-officer in dienst hebben.

Zoiets lijkt me ook goed company-wide uit te rollen. Tenzij iedereen een BYOD heeft maar als je dan afdwingt dat iedereen FireFox gebruikt zou je idd een installeerbare config-file kunnen verspreiden.

[Nickvdd]

Dus nou zou je eigenlijk HTTPS Everywhere van EFF niet meer nodig hebben?

[Rudie_V]

Mijn reactie in de downloads van Firefox 83:
Rudie_V in 'downloads: Mozilla Firefox 83.0'

In de standaard instelling van HTTPS Everywhere worden alleen bekende sites via de rulesets naar https omgeleid en kan je nog gewoon http sites of mixed mode sites bekijken.
HTTPS Everywhere kan ook alles naar https omleiden door de Encrypt All Sites Eligible optie aan te zetten, http sites krijgen een waarschuwing en kon je tijdelijk of permanent toestaan, in mixed mode sites wordt http content niet meer geladen.

De HTTPS-Only mode van Firefox werkt eigenlijk zoals de Encrypt All Sites Eligible optie in HTTPS Everywhere. Alles wordt naar https geleid, in mixed mode sites wordt http content niet geladen en http sites krijgen een waarschuwing en kan je kiezen om alsnog door te gaan naar de http site.
Mocht je een site bezoeken met mixed mode content dan kan je per site HTTPS-Only uitzetten door op het slotje in de adresbalk te klikken. Helaas zie ik dat Firefox niet duidelijk laat zien dat je een mixed mode site bezoekt, pas als je HTTPS-Only voor een mixed mode site (tijdelijk) uitzet wordt de http content wel geladen en dan laat Firefox wel weer het bekende uitroepteken op het slotje zien.

Dus om antwoord op je vraag te geven, mijn inziens is HTTPS Everywhere overbodig geworden ja en kan je de HTTPS-Only mode van Firefox gebruiken, natuurlijk wel in alle windows, niet alleen private browsing.

Mixed mode test site:
https://www.bennish.net/mixed-content.html

[sOid]

Daar dacht ik ook meteen aan ja. Scheelt weer een extensie!

[SMGGM]

Denk dat beide toch nog een verschil hebben. Bij HTTPS everywhere gaat hij over naar HTTPS als die ook beschikbaar is in zijn S variant. Bij deze optie van Mozilla gaat de website gewoon niet laden als er geen S variant beschikbaar is.
Voor de mensen die zeer achterdochtig zijn kan het handig zijn of voor mensen die vaak op publieke netwerken zitten. Ik zie bedrijven zo'n optie ook nog wel inschakelen.

Op zich kan je het ook nog configureren voor mensen die iets minder kennis hebben van computers als waarschuwing voor hen: zie je de melding, wees dan extra voorzichtig met de data dat je zal delen.

[wica]

Niet alles hoeft over HTTPS.
Sommige informatie zou ik ook graag willen benaderen over een bagger mobiele verbinding...

[GertMenkel]

Let wel dat moderne alternatieven (QUIC, HTTP/2, opkomend: HTTP/3) beter om kunnen gaan met slechte netwerken dan het traditionele HTTP over TCP. De initiele handshake is inderdaad trager door de triple handshake (je hebt de 0-RTT modus maar daar zitten beveiligingsnadelen aan) maar door de tunneling van de verbinding die je met HTTP/2 hebt, worden de assets tegelijkertijd over een verbinding binnen gehaald.

Waar je voorheen dus op 3 sockets een reset kon krijgen terwijl assets werden binnengehaald (HTML, JS, CSS), hoeft de verbinding nu per host maar op 1 plek geshapet te worden.

Hier haal je geen voordeel uit op websites die enkel HTML en inline CSS/JS bevatten, maar helaas is het web zo onnodig complex geworden dat dit niet meer realistisch is.

Overigens kan een TLS-sessie gewoon vervolgd worden door middel van session cookies zonder een nieuwe triple handshake als je dezelfde host bezoekt binnen 24 uur. Twee keer per dag Tweakers checken zal dus als het goed is bijna nooit een extra handshake opleveren, waardoor je even snel bent als wanneer je Tweakers over HTTP zou bezoeken.

Ik denk dat je eerder DNS-vertragingen zult krijgen met moderne webservers dan dat je zit te wachten op de TLS-handshake. Hopelijk switchen meer websites binnenkort naar certificaten en ciphers die op elliptische curves gebaseerd zijn in plaats van het oude RSA-algoritme, dat scheelt toch weer snel een paar kB aan certificaatuitwisseling.

[Eonfge]

Argument dat nog niet genoemd is: Defence in depth.

Je wil wel dat zoveel mogelijk systemen gebruik maken van TLS, voor als andere beveiligingen het laten afweten. Op netwerkniveau zou het best kunnen dat een MitM aanval zichzelf voor doet als NS access point, en dat ze vanaf daar besmette pagina's kunnen aanbieden. Daartegen is TLS ook.

Zelfde voor besturingssystemen en dergelijke: Je gaat toch niet alleen op de browser-sandbox vertrouwen dat alles veilig is?

[MrR0b3rt]

Waarom zou niet alles over HTTPS hoeven? Of misschien anders: welke informatie zou je niet over HTTPS moeten willen versturen? Oprechte vraag...niet cynisch bedoeld

[renevanh]

Nou, als ik de (platte) website van een loodgieter bezoek om zijn telefoonnummer op te zoeken hoeft dat van mijn niet perse over HTTPS...

[MrR0b3rt]

Die website van die loodgieter heeft waarschijnlijk wel een contact formulier (want dat heeft 99,9% van de websites tegenwoordig). Als ik mijn gegevens invul, wil ik wel dat die over https verzonden worden.

Omdat bedrijven van die omvang vaak een Wordpress website gebruiken (zie ik althans heel vaak bij kleinere bedrijven), zit het admin deel onder hetzelfde domein. Vanuit het perspectief van het bedrijf zouden zij om die reden ook https moeten willen gebruiken.

Een dergelijk certificaat kost nauwelijks iets en kan zelfs via sommige webhosting bedrijven simpel via Let's Encrypt worden ingeschakeld (zoals bij TransIP). Dus ik vraag me nog steeds af waarom je dit niet zou willen.

[renevanh]

Ik zeg heel bewust 'platte website' en 'telefoonnummer opzoeken'. Zodra je gegevens gaat versturen is de meerwaarde van HTTPS duidelijk.

[MrR0b3rt]

Uiteraard, dat ik gelezen maar dit zijn imho edge cases die we nu bespreken, 99,99% van de websites is niet zo plat en wordt niet gebruikt om alleen even een telefoonnummer op te zoeken. Die 0,01% die dan overblijft kan van bezoekers vragen deze functie uit te zetten of een certificaat (gratis of betaald) gaan gebruiken.

Edit: Edge was geen pun trouwens

[Reactie gewijzigd door MrR0b3rt op 28 juli 2024 02:44]

[Derkades]

Ook in dat geval zou je als consument en bedrijf liever niet willen dat iemand het telefoonnummer zou kunnen veranderen of andere inhoud op de website kan bewerken

[Single Core]

Toch wel, want door een mitm aanval kan ik daar een telefoon nummer plaatsen van mijn totaal-echte-loodgieter die u mooi zal pluimen.

[Bender]

De kans dat de gebruiker malware heeft die content van een pagina veranderd acht ik alleen een stuk groter.

[RGAT]

Maar omdat er een grote kans is betekent niet dat we een ander makkelijk op te lossen risico hoeven te negeren.
Omdat de kans dat sommigen door rood rijden groter is dan een ongeluk hoeven we geen airbags

HTTPS zou overigens het ook voor malware lastiger maken, de malware zou dan administrator permissies moeten zien te krijgen om HTTPS verkeer te onderscheppen/een eigen certificaat te installeren dus ook in het geval van malware maakt HTTPS het een stukje lastiger voor die malware.

[Bender]

Malware hoeft alleen een extensie in de browser te hebben, je kunt dan de volledige content aanpassen van een pagina, of het nu https is of niet.

[RGAT]

Die was ik even vergeten inderdaad, gelukkig alweer een flink aantal jaren geleden dat ik op de servicedesk de helft van de dag browserextensies van gebruikers stond te verwijderen om dan te zien dat de klachten van meestal ongepaste advertenties op alle websites verdwenen.
Maar toch, HTTPS kan geen kwaad natuurlijk en zoals alle beveiliging is het een kwestie van lagen; HTTPS beschermt niet tegen malware en antivirus/niet overal op klikken beschermt niet tegen een MITM, daarom is het handig beide te gebruiken.
Verder kost HTTPS tegenwoordig niks, kost het geen moeite om in te stellen voor een website (Certbot bijv.) en kost het in resources verwaarloosbaar weinig terwijl het wel helpt beschermen tegen een aantal risico's.

[Single Core]

Als de gebruiker malware heeft staan op zijn eigen systeem dan is https niet meer relevant...

[Bender]

Dat is inderdaad mijn punt ook :-P

[grashopper]

Goede vraag.
Dit doet mij denken aan het verhaal van de Amerikaanse provider AT&T die advertenties injecteerde in HTTP-pagina's. Sinsdien zie ik persoonlijk nog weinig redenen om geen HTTPS te gebruiken. Je weet maar nooit wie er aan je content zit te prutsen.

bron:
https://www.pcworld.com/article/2976025/att-wi-fi-hotspot-reportedly-stuffs-extra-ads-into-web-pages.html

[kluyze]

Mijn interne zelf geschreven webpagina op mijn raspberri pi die ik op ip adres bezoek. Waarom heeft die https nodig? En wat voor zaken moet ik allemaal instellen om die over https te laten gaan?

Ook een oprechte vraag natuurlijk, ik heb wel eens heel kort getest met een dns server in te stellen en een eigen root CA aan te maken en overal te vertrouwen. Maar volgens mij liep ik bij de DNS server vast bij IPv6.

[Reactie gewijzigd door kluyze op 28 juli 2024 02:44]

[Jazco2nd]

Een webservice/webUI van iets wat lokaal op mijn LAN draait (en zelfs niet exposed is online).

[slow whoop]

Als ik thuis de webinterface van mijn routers/access points wil benaderen gaat dat volgens mij altijd met HTTP. Ik zie niet in waarom dat met HTTPS zou moeten. Externe toegang staat bij mij altijd uit.

[gimbal]

Ik vermoed dat de grootste hordel daar certificaatbeheer is. Je krijgt TLS niet kado, je moet goed beheerde certificaten hebben. Die willen nog wel eens verlopen of ingetrokken worden. Als je een webserver beheert - te overzien. Als het op de hardware van honderdduizenden klanten moet gebeuren... ja dat is lastiger.

[Verwijderd]

Gelukkig heb je de optie om het over HTTP te benaderen nog steeds

[Nindustries]

Dat gaat ook perfect over TLS. In TLS 1.3 heb je nu zero-round-trip: https://blog.cloudflare.com/introducing-0-rtt/
Het gaat ook over dat niemand tussen jou en de server geen dingen kan aanpassen, niet gewoon lezen.

[wica]

Dat zou fijn zijn, ga ik eens testen met een verbinding ie veel reset verstuurd.

@Single Core Ik ben wel eens op locaties, waar echt een bagger verbinding is. Hee veel tcp resets. Dan is HTTPS echt niet fijn. Maar wil wel gewoon bepaalde websites kunnen lezen. Nee, ik vraag dit niet voor mijn bank website of zoiets anders belangrijks waar ik op moet inloggen.

[Jeanpaul145]

Beveiliging en de kwaliteit van je verbinding zijn orthogonale issues

Ik bedoel, zelfs over een dialup verbinding kan je nog steeds https gebruiken.

[Reactie gewijzigd door Jeanpaul145 op 28 juli 2024 02:44]

[Single Core]

Zever is pakjes, alles moet WEL HTTPS zijn, waarom zou je anders willen ...
Wat maakt uw verbindings snelheid uit ivm HTTPS?

[Tozz]

HTTPS heeft gewoon meer overhead en vereist meer pakketjes over en weer gedurende de handshake. Dat maakt het trager, ookal is dat wellicht minimaal. Maar hoe groter je latency hoe trager het wordt.

[delphium]

SSL vereist welbeschouwd twee extra roundtrips naar de server. Met huidige verbindingssnelheden en technieken als http2 is dat echt te verwaarlozen. Dus liever gewoon alles versleuteld.

[Tozz]

Zeg dat tegen iemand die via een schotel op Internet zit, met een round trip time van 300ms.

Zit je toch 0,6 seconden langer te wachten.

[Keypunchie]

Als groot voorstander van 'alles https', ik zie het nut niet zo van deze modus?

Is het bedoeld voor systeembeheerders om hun gebruikers het leven zuur te maken bij het surfen? Genoeg malware die met een certificaatje wordt gehost, dus daar helpt het niet echt tegen. En genoeg http-sites met nodige content, dus je hindert je gebruikers alleen maar, zonder echt iets toe te voegen.

Als gebruiker zelf, tsja, ik zie in de menubalk vrij goed of iets http/https is. Maar mensen die het niet zien, gaan die deze modus gebruiken?

Wat ik wil is dat site-beheerders gestimuleerd worden om hun site te beveiligen. Niet dat ik als eindgebruiker gehinderd wordt om content te benaderen. Er is nog net iets te veel non-https op het web.

Of is het idee om een signaal uit te laten gaan? Zo van, nu is die modus nog opt-in, straks wordt 'ie opt-out en daarna wordt ondersteuning voor http gedropt?

[Reactie gewijzigd door Keypunchie op 28 juli 2024 02:44]

[mpol]

Wat ik zie als ik een domeinnaam intik in de adresbalk, zoals 'tweakers.net', dat hij eerst de 'http'-website bezoekt, daar een redirect krijgt om dan de 'https'-website te laden. Het heeft me al langer verbaasd dat het zo gebeurt, ik zou dat andersom willen. Dat is schijnbaar nu aan het veranderen, nu eerst als optie, daarna als standaard instelling.

[R4gnax]

Wat ik zie als ik een domeinnaam intik in de adresbalk, zoals 'tweakers.net', dat hij eerst de 'http'-website bezoekt, daar een redirect krijgt om dan de 'https'-website te laden.

Tweakers stuurt netjes strict transport security headers, dus die redirect is enkel een interne redirect aan de kant van de browser zelf en omvat geen daadwerkelijk netwerkverkeer.

[Reactie gewijzigd door R4gnax op 28 juli 2024 02:44]

[84hannes]

Waar het om gaat is dat als je geen protocool specificeert, de browser eerst http probeert. Het zou anno 2020 toch niet raar zijn om default voor de veiligere optie te gaan en http alleen te gebruiken als de gebruiker dit expliciet aangeeft?

[mpol]

Wat 84hannes ook al zegt.
De headers zijn HTTP headers, je moet dus wel netwerkverkeer hebben, eerst via http, voordat je browser snapt dat hij het nogmaals via https moet proberen.

[R4gnax]

Wat 84hannes ook al zegt. De headers zijn HTTP headers, je moet dus wel netwerkverkeer hebben, eerst via http, voordat je browser snapt dat hij het nogmaals via https moet proberen.

Fout dus.

Strict transport security headers worden intern in je browser bijgehouden voor zo lang ze geldig zijn. Mocht je binnen die tijd het bijbehorende domein via het http:// protocol bezoeken dan zal je browser zelf onmiddelijk een redirect terug sturen naar dezelfde URL op het https:// protocol.

Gebruik een netwerk-monitoring tool als Fiddler en je kunt het verifiëren er zal geen HTTP request naar buiten gaan en je ziet geen redirect terugkomen. Dat gebeurt allemaal intern in de browser zelf.

Alleen de eerste keer dat je een site bezoekt en de strict transport security headers nog niet ontvangen zijn; of wanneer de reeds ontvangen headers verlopen zijn, zul je daadwerkelijk een redirect krijgen die echt via een netwerk request loopt.

[Reactie gewijzigd door R4gnax op 28 juli 2024 02:44]

[Tozz]

HSTS headers zijn niet geldig over HTTP. Dus het is zeker geen interne redirect, het is een redirect die de webserver stuurt naar de client met een HTTP 301/302.

[R4gnax]

HSTS headers zijn niet geldig over HTTP. Dus het is zeker geen interne redirect, het is een redirect die de webserver stuurt naar de client met een HTTP 301/302.

Bij het eerste HTTP verzoek heb je een redirect naar HTTPS. Via HTTPS worden de HSTS headers verstuurd die voor een bepaalde duur geldig zijn. Alle verdere requests over HTTP binnen die geldigheids-duur worden direct via een interne redirect in de browser omgezet in HTTPS.

Dat is dus ook wat ik reeds beschreven had.
Maar ik heb het nog even iets duidelijker geformuleerd, voor het geval je het voorheen niet kon volgen.

[Reactie gewijzigd door R4gnax op 28 juli 2024 02:44]

[Tozz]

Ik kon het voorheen inderdaad niet volgen

[Verwijderd]

Ik maakte al gebruik van een extensie in Firefox om https overal te forceren, maar goed om te zien dat het nu ook standaard in de browser zit. Top bedrijf dat Mozilla

[Maurits van Baerle]

Ik ga eens een uurtje met die HTTPS-only switch aan werken. Kijken hoeveel er niet meer werkt.

Ik vermoed dat vrijwel alles inmiddels over HTTPS kan. Ik heb sowieso al HTTPS-Everywhere draaien dus merk vaak niet eens dat er ook nog een HTTP optie bestaat.

Het zijn van die dingen die grotendeels onzichtbaar vernieuwen. Ik draai ook SixOrNot en met IPv6 zie je ook dat het grotendeels een evolutie is die niet opvalt als je er niet op let.

[daanb14]

Heel erg fijn dat invulvelden voor .pdf-bestanden nu ondersteund worden. Ik heb dus geen aparte pdf-viewer meer nodig

[Ventieldopje]

Mooi zo, dat scheelt weer 2 extensions