Tweakers stapt over op https

Meer veiligheid en privacy

Referrers en conclusie

Er zijn diverse gebruikers die eigen artikelen linken op Tweakers en gewend zijn om dan in hun analytics of serverlogs precies terug te kunnen zien waar hun bezoekers vandaan kwamen. Voor hen hebben we slecht nieuws; dat wordt een stuk minder informatief vanaf Tweakers.

Voorheen stuurden de meeste browsers een referrer mee met de url waar ze vandaan kwamen. Dat gedrag is anders zodra de bronpagina een https-pagina is en de doelpagina via http gaat. Dan sturen de meeste browsers juist helemaal geen referrer mee. Door te vertellen waar iemand vandaan komt, wordt tenslotte een stukje privé-informatie uitgelekt via die onbeveiligde verbinding. Voor links van https-pagina naar https-pagina worden standaard wel referrers doorgestuurd. Er zijn uiteraard instelmogelijkheden en plug-ins die dit gedrag veranderen, waardoor de meegegeven informatie nooit helemaal betrouwbaar was voor eigenaars van websites.

Wij hebben nu ook referrer-metatags toegevoegd. Dat hebben we enerzijds gedaan om het gedrag tussen http en https gelijker te maken, maar anderzijds om de privacy-impact in beide situaties te reduceren. Daarmee verzoeken we browsers om de referrer aan te passen aan de origin, bijvoorbeeld https://tweakers.net of https://gathering.tweakers.net, zonder verdere padinformatie. Het is dus nog wel zichtbaar dat iemand van Tweakers komt, maar niet meer precies vanaf welke pagina.

Het is nog wel zichtbaar dat iemand van Tweakers komt, maar niet meer vanaf welke pagina

Deze metatags zijn overigens een verzoek aan de browser. De browser kan zich via plug-ins of instellingen alsnog anders gedragen. Ook kunnen we niet precies specificeren wat de referrer moet worden, enkel welke stukjes van de referrer (niets, domein+protocol, alles) wat ons betreft mogen worden meegestuurd.

De enige uitzondering zijn de prijslijsten. Daarbij hebben we een zekere verantwoordelijkheid tegenover de diverse webshops. Als we melden dat honderd bezoekers hebben doorgeklikt, dan willen de winkels dat natuurlijk kunnen terugvinden in hun eigen informatie. De referrer is een van de methoden om dat te herleiden. Daarom laten we specifiek bij die prijslijsten de volledige referrer meesturen. Aangezien winkels toch al weten welk product aan hun kant werd opgevraagd, is het triviaal om te bepalen vanaf welke pagina dat op Tweakers had moeten zijn; de privacy-impact is dus erg beperkt. Door toch de hele referrer mee te laten sturen, ook naar http, maken we het voor de webwinkels wel makkelijker om te controleren of we de juiste bedragen in rekening brengen. Specifiek voor die pagina's plaatsen we daarom niet onze standaard-origin-when-cross-origin, maar de markering die vergelijkbaar is met het gedrag van vóór de https-site: unsafe-uri.

Conclusie

Al met al was het een behoorlijke klus om https goed te ondersteunen. Vooral het verhelpen van mixed content in de bijna achttien jaar aan forumposts en nieuwsberichten was een uitdaging. Daarin zaten verschillende generaties html-stijl en allerlei verwijzingen naar sites of afbeeldingen die ondertussen al lang niet meer bestaan.

Het is goed mogelijk dat we iets hebben gemist. Als dat zo is, dan horen we dat graag. In dit topic kun je ons daarvan op de hoogte brengen.

Ook kan de 'geef feedback'-knop met het i-tje gebruikt worden. Daarin kunnen specifieke elementen worden geselecteerd. Die knop is overigens voor niet-ingelogde bezoekers wat groter. Ook kan hij afhankelijk van de schermresolutie en tracker-instellingen juist verborgen zijn. In dat geval kan ook de 'Feedback'-link helemaal onder aan de pagina worden gebruikt.

Reacties (218)

[mkools24]

Nu nog HSTS En waarom letsencrypt? Je mag hier toch wel een deftig EV certificaat verwachten?

[ACM]

Waarom EV? Dat kost veel meer (ook meer dan een gewoon SAN-certificaat buiten letsencrypt om) en zorgt er ook nog eens voor dat we dan eerst 'de Persgroep Online Services B.V.' tonen en daarna pas Tweakers. De herkenbaarheid wordt daardoor dus nog slechter van ook

[mailis]

Zou je ook de bedragen (of indicatie) kunnen noemen? Als de dubbele kosten van 10,- naar 20,- per jaar gaan is dat natuurlijk te overzien. Maar dat zal het vast niet zijn...

[Kees]

Voor een EV-SAN certificaat betaal je (minimaal) 359,- per jaar. Maar je mag dan ook nog 169,- per SAN naam extra betalen. Als we het huidige (gratis) certificaat 1-op-1 zouden overzetten dan zou dat ruim 3000 euro per jaar kosten.

Bovendien is de huidige oplossing ook nog eens een stuk beter te beheren. Alles word automatisch verlengt en ik hoef niet intern om een creditcard te gaan bedelen om 2 maand voor het verlopen van een certificaat een nieuw certificaat te regelen, en als die er eenmaal is die overal toe te voegen. Dus naast de kosten voor het certificaat scheelt mij die per jaar ook minimaal een dag werk.

Verder over de nadelen van EV: Kees in 'plan: Testresultaten op specificatietab - Development-iteratie #86'

[Reactie gewijzigd door Kees op 22 juli 2024 16:55]

[atlaste]

Tussen de verschillende aanbieders van EV-MDC zitten inderdaad enorme verschillen. Daarnaast kan je ze vaak nog benaderen, bijv. als je langere termijnen wilt afnemen (ik koop certificaten normaliter voor 5 jaar, wat zo'n beetje de maximum is).

Nu vind ik de prijs/prestatie verhoudingen van SSL certificaten persoonlijk een beetje scheef. Daarom heb ik LetsEncrypt ook sinds mei oid. in gebruik. Ik merk echter dat de applicatie die je nodig hebt niet altijd stabiel genoeg werkt (in mijn geval op Windows Server); zo bleef het proces een keer hangen (je krijgt dan een expiration e-mail...) en heeft de applicatie onder IIS op een dag bedacht dat hij de andere certificaten moest vervangen ondanks dat dit niet mag gebeuren (not funny als je VPN over SSTP gebruikt). Verder is het een prima dienst wmb - en de issues die ik heb gehad worden over de tijd vast minder...

All things considered... https://www.sslcertificaten.nl/SSLCertificaten ben ik zelf op uitgekomen destijds. Een Comodo organisatie/wildcard certificaat voor 5 jaar kost je +/- 150 euro per jaar iirc.

EV certificaten zijn niet echt nodig ofzo; volgens mij doet Google dat nog niet eens. Maarja, mocht je groen een mooie kleur vinden kunnen EV MDC certificaten natuurlijk ook, kost +/- 175 per jaar.

Ook die certificaten zijn niet bepaald heilig. Installatie is niet bepaald eenvoudig door verschillende types/bugs (ik heb Symantec, Comodo en Verisign gehad) en ik kreeg voor een 5-jaar certificaat van Verisign een keer een renewal e-mail met een reactie-periode van 1 maand. Die laatste is vooral prettig als je precies op dat moment op vakantie bent.

De prijzen lopen enorm uiteen van dat tot +/- 2000 (!) per jaar van Symantec en Verisign. Dat verschil geeft al wel aan hoeveel marge er is.

Als je dan ook nog PDF's wilt signen, bijv. omdat je facturen officieel wilt tekenen met een certificaat (zoals dat officieel hoort...) heb je weer speciale certificaten nodig. Die certificaten zijn helemaal belachelijk duur... volgens mij vooral omdat Adobe de CA lijst beheert...

Kortom, ik vind het niet zo'n gekke keuze. Ultimo maakt het niet heel veel uit.

[Reactie gewijzigd door atlaste op 22 juli 2024 16:55]

[kwakzalver]

Juist omdat het Tweakers is verwacht ik een LetsEncrypt certificaat in plaats van een commerciele SSL boer.

Tweaken en gebruik maken van LetsEncrypt vindt ik een prima oplossing.

Henk zou het hier roerend mee eens zijn.

[maniak]

Dat ben ik ook (echte naam is Henk )

[SleutelMan]

Let wel dat vanaf 30 juni het afnemen van 5 jaar geldige SSL certificaten niet meer mogelijk is, Dat is namelijk per die datum verboden in de Baseline Requirements (zie paragraaf 6.3.2.) van het CA/B Forum.

Hoewel genoemd orgaan een vrijwillige samenwerking is van browsers en CA´s nemen de grote browser partijen (MS, Mozilla, Google en Apple) in hun eigen eisenprogramma op dat je er onverkort aan dient te voldoen. Oftewel, na 30 juni 2016 mag een dergelijk certificaat maximaal 39 maanden geldig zijn (27 maanden voor EV).

De reden waarom trouwens geavanceerde/gekwalificeerde certificaten (bedoeld voor het tekenen van stukken) zo duur zijn is voornamelijk de hoeveelheid validatieslagen die er aan gekoppeld zijn tov een Domain Validated server certificaat: denk hierbij aan persoonlijke identificatie etc.

[Reactie gewijzigd door SleutelMan op 22 juli 2024 16:55]

[Anoniem: 781715]

Waarom zou je ook alles een-op-een willen overnemen. In het Letsencrypt ssl certificaat:

Is er maar 1 belangrijk hoofddomeinnaam:
DNS-naam: tweakers.net

2 belangrijke subdomeinnamen:
DNS-naam: gathering.tweakers.net
DNS-naam: pricewatch.tweakers.net

2 domeinnamen die extern ingeladen worden en op de hoofdpagina pagina niet gevonden staat:
DNS-naam: charts.tweakzones.net
DNS-naam: ic.tweakimg.net

12 Omleidingen (redirects) naar tweakers.net
DNS-naam: secure.tweakers.net
DNS-naam: static.tweakers.net
DNS-naam: tweakers.be
DNS-naam: tweakers.mobi
DNS-naam: tweakers.nl
DNS-naam: tweakers.tv
DNS-naam: tweakimg.net
DNS-naam: twk.rs
DNS-naam: www.gathering.tweakers.net
DNS-naam: www.tweakers.be
DNS-naam: www.tweakers.net
DNS-naam: www.tweakers.nl

Voor de 12 omleidingen heeft een SSL certificaat niet zo veel zin. charts.tweakzones.net en ic.tweakimg.net worden alleen extern ingeladen en niet direct bezocht worden, dus waarvoor een EV certificaat ook niet veel zin heeft.

Voor 1 hoofddomein en 2 subdomeinen zou een EV bij een site zoals xolphin.nl 375,00 Euro per 2 jaar kosten (gemiddeld 187.50 euro per jaar, wat 16 keer minder is dan 3000 euro per jaar)

[ACM]

Dat ze niet per se in een EV-certificaat hoeven zal best kloppen, maar dan verliezen we weer het voordeel dat alle belangrijke domeinen in één certificaat zitten.

Dat zouden er wel minder kunnen dan die lijst die je daar inderdaad toont. tweakimg.net en ic.tweakimg.net worden op dit moment voor alle ondersteunende content, waaronder afbeeldingen, css en javascript gebruikt. Dus dat zijn niet 'redirects'.

Maar ons grootste bezwaar blijft hoedanook bestaan. De bedrijfsnaam is 'de Persgroep Online Services B.V.' Je kan dit effect op diverse sites zien, maar eentje die ik uit mijn hoofd wist is karwei.nl. Daar geeft het EV-certificaat Intergamma B.V. als naam; niet iets dat je direct associeert met Karwei (tenzij je weet dat ze hetzelfde moederbedrijf als Gamma hebben )
Bij ons wordt het nog iets erger doordat onze bedrijfsnaam nog een stuk langer is. Overigens zie ik dat Chrome (iig in Android 6) de bedrijfsnaam juist helemaal niet toont, dus daar valt het probleem alweer wat mee.

Maar wat is uiteindelijk de meerwaarde van een EV-certificaat? Die paar honderd euro waar het dan alsnog om gaat en het feit dat het waarschijnlijk lastiger is te automatiseren (en dus meer handwerk geeft) moeten wel iets goed doen voor Tweakers natuurlijk

Domweg zoiets zien staan is niet echt enorm zinvol vind ikzelf:
de Persgroep Online Services B.V. https://tweakers.net/

[Reactie gewijzigd door ACM op 22 juli 2024 16:55]

[SWINX]

Een EV voegt denk ik inderdaad weinig toe, maar toch vraag ik me af of je niet een handelsnaam op kunt geven in je certificaat.

Als je naar https://www.rabobank.nl kijkt dan zie je daar "Rabobank Nederland" staan, terwijl hun statutaire naam eigenlijk "Coöperatieve Rabobank U.A." is. Zoiets zou voor Tweakers dan toch ook moeten kunnen (in het geval dat EV gewenst zou zijn).

[Anoniem: 781715]

"Rabobank Nederland" is geregistreerd bij de kamer van koophandel en staat ook als "Houder" vermeld bij de whois informatie van rabobank.nl Bij de websites van tweakers is de houder die in de whois informatie vermeld staat "Tweakers.net", maar blijkbaar is deze naam uitgeschreven bij de kamer van koophandel.

[Reactie gewijzigd door Anoniem: 781715 op 22 juli 2024 16:55]

[Anoniem: 781715]

~[html]<b style="color: green">de Persgroep Online Services B.V.</b>~[/html] https://tweakers.net/
zou inderdaad niet zo mooi staan als bijvoorbeeld
~[html]<b style="color: green">Tweakers.net B.V.</b>~[/html] https://tweakers.net/

Oorspronkelijk waren EV bedoeld voor banken om onderscheid te maken tussen de echte banksite met https in de URL en een slotje toonde in de webbrowser en een neppe banksite met https in de URL die bijna identiek was en ook een slotje toonde, waarbij voor de neppe banksite makkelijk zonder handmatige controle een SSL certificaat voor te krijgen was.

Als voorbeeld zou https://tweakers.net en https://tvveakers.net makkelijker van elkaar te onderscheiden zijn, ongeacht het lettertype. Sommige andere vormen van vervalste site en MITM (Superfish) zouden ook makkelijker te herkennen kunnen zijn, hoewel sommigen de duidelijk visueel verschillende kenmerken toch zullen blijven negeren.

Of een EV-certificaat echt zinvol voor Tweakers weet ik niet.

Maar tegenwoordig worden EV certificaten ook gewoon gebruikt omdat het een coole exclusieve badge is die betrouwbaarheid uitstraalt.

[Reactie gewijzigd door Anoniem: 781715 op 22 juli 2024 16:55]

[himlims_]

mag ik jou even complimenteren met de snelheid over https !!! super!!!

[lesander]

Bij EV certificaten* praat je al snel over prijzen tussen de 400 en 800 euro, en dan heb je nog niet eens een wildcard certificaat, die prijzen liggen nog veel hoger (1000 euro tot 5000 of meer). Een lucratieve business dus, die EV's.

* Extended Validation, wat je bij banken vaak ziet in de URL balk: "ING B.V."

[Reactie gewijzigd door lesander op 22 juli 2024 16:55]

[SleutelMan]

En dan kan je nog geeneens een wildcard EV certificaat afnemen, dat wordt namelijk verboden in de EV Guidelines van het CA/B Forum waaraan de grote browserpartijen zich hebben gecommitteerd.

En EV is dan ook voornamelijk bedoeld voor high profile websites. Voor de gewone huis-tuin-keuken websites is een Domain Validated certificaat (zoals Letsencrypt) meer dan genoeg.

Organisation Validated (OV) certificaten zijn dan net een stapje beter (er vinden meer validatieslagen plaats en de organisatienaam komt terug in het certificaat), maar helaas varieert daarin nogal per CA welke validatieslagen zij uitvoeren en plaatsen browsers genoemde certificaten in dezelfde categorie als DV (beide een normaal ¨grijs¨ slotje).

Om van dat laatste een voorbeeld te geven: Binnen OV heb je zowel CA´s die alleen controleren op het bestaan van de organisatie bij een register (bijv. KvK) en alleen op afstand identificatie afnemen (bijv. telefonisch) als CA´s die bijna op een EV niveau zitten waarbij fysieke identificatie vereist is (denk bijv. aan PKIoverheid). Aangezien daar nogal wat verschillen in zitten en er alleen voor EV echt heldere kaders zijn gesteld aan identificatie van de aanvragende partij (zie de eerder genoemde EV Guidelines) wordt er door de browsers alleen bij die laatste een duidelijke visuele hint gegeven (groen slotje/balk).

[kaas-schaaf]

Het gebruik van wildcards moet je zo veel mogelijk beperken door het makkelijke misbruik en de mogelijke performance problemen die je krijgt bij grote bezoekersaantallen. Voor het teakblog domain zal het overigens wel meevallen. Door de verbeterde netwerken zal het overigens vandaag de dat niet langer de hoofdreden zijn, maar security wel.

Zie ook rfc 6125 (https://tools.ietf.org/html/rfc6125#section-7.2) voor meer over wildcard en waarom niet.

[Reactie gewijzigd door kaas-schaaf op 22 juli 2024 16:55]

[SleutelMan]

Ook dat inderdaad. Het gebruik van een wildcard certificaat betekent per definitie dat hetzelfde keypair (private+public key) op meerdere systemen rondzwerft. Op hoe meer plekken een kopie staat van het sleutelpaar, hoe groter de kans dat genoemd sleutelpaar uitlekt. En als dat gebeurd moet je weer een nieuwe aanvragen en op alle verschillende plekken weer uitrollen.

Ergo: Het kost je meer inrichtingswerk, maar mits je de boel gedeeltelijk kan automatiseren (zeker Let´s Encrypt leent zich hier goed voor, maar ook bij een reguliere CA valt een groot deel met scripting af te vangen) is het uiteindelijk wel veiliger. Afhankelijk van het type certificaat wat je afneemt wel duurder. Maar ja, die afweging heb je altijd als het om veiligheid gaat...

[Anoniem: 781715]

Een EV certificaat hoeft geen honderden Euro's te kosten als je maar weet waar je ze goedkoop kunt krijgen. Hier $79 per jaar met coupon CHEAPEV79. Of deze EV SSL aanbieding van $46.85 voor het allereerste jaar. Als direct bij Comodo een EV SSL certificaat koopt dan kost het 99 Euro per jaar.

[Reactie gewijzigd door Anoniem: 781715 op 22 juli 2024 16:55]

[lesander]

Het eerste jaar zal je daar wat mee uit sparen, maar daarna zal je de volle mep moeten betalen.

[Anoniem: 781715]

Zo'n $79 per jaar is nog steeds veel minder dan 'tussen de 400 en 800 euro' per jaar.

[ACM]

De dubbele kosten is bij SAN vs niet SAN. EV hebben we niet echt bekeken, maar dat is sowieso veel meer.

Maar dan heb je het over van zo'n 1000 euro per jaar naar zo'n 2000 euro per jaar. En met letsencrypt is dat dus juist van 1000 naar 0 gegaan

[Anoniem: 781715]

1000 Euro jaar? Jullie hebben dan wel erg dure SAN SSL certificaten gekozen.
Bij PositiveSSL Multi-Domain is het ook mogelijk om ecdsa te gebruiken, wanneer er contact met ze opgenomen wordt voor de activatie. Voor 17 domeinnamen kost het $516.84 voor 3 jaar. (Gemiddeld $172.28 per jaar) PositiveSSL zonder SAN (dus een aparte certificaat voor elke domeinnaam) voor 17 domeinnamen zou $81.45 per 3 jaar kosten. (Gemiddeld $28.05 per jaar)

Gratis is natuurlijk beter. Gratis SSL certificaten is iets dat Cloudflare al sinds October 2014 aanbied. De beta Letsencrypt was tusen September 2015-April 2016. Maar ik had toch wel verwacht dat jullie iets beters hadden kunnen vinden dan 1000 euro per jaar.

[Reactie gewijzigd door Anoniem: 781715 op 22 juli 2024 16:55]

[ACM]

Eerlijk gezegd zijn dit soort reacties juist - wat mij betreft - nog meer reden voor letsencrypt

Het gedoe om elke keer weer de goedkoopst te vinden, te checken of ze wel ecdsa ondersteunen en zo nog wat zaken, maken het er niet eenvoudiger op.

Elders in de reacties beschrijft collega Kees dat dat zomaar een jaarlijkse dagtaak kan zijn.
Hoewel het natuurlijk goed is om op de centjes te letten, zijn we ook weer niet speciaal met die reden aan het werk gegaan bij Tweakers. Dus we zijn niet alleen verlost van de - blijkbaar te - dure certificaten, we zijn ook verlost van de (twee)jaarlijkse zoektocht naar de goedkoopste aanbieder van certificaten

Het belangrijkste wat we daarmee niet krijgen is ondersteuning voor EV. Maar ik heb nog geen hele goede redenen gezien waarom we dat echt nodig zouden hebben. Of ik heb daar natuurlijk overheen gelezen?

[MadEgg]

Kleine kanttekening is dat mijn BlackBerry Q10 Let's Encrypt certificaten (nog) niet ondersteund en dus Tweakers.net nu niet vertrouwd. Gelukkig ben ik net overgestapt op een iPhone dus zelf heb ik er geen last van, maar wellicht zijn er nog meer bezoekers die daar nu problemen mee ondervinden.

[Kees]

Klopt, BlackBerry Q10 is het enige (nog in gebruik zijnde) platform wat LetsEncrypt niet ondersteunt. Zelfs Windows XP vind het een geldig certificaat.

Nu is het aandeel blackberry zo laag, en kun je alternatieve browsers gebruiken dat we in dit geval hebben besloten dat dit geen blocker is.

[vkransen]

Zelf heb ik deze gebruikt.

[Powermage]

Zou je dan niet "Intermediair" weergeven aangezien dat volgens mij de hoofd naam lijkt van de kvk inschrijving
Maargoed, hoe dan ook, volgens mij is dat op te lossen door Tweakers.net toe te laten voegen als handelsnaam aan de KVK inschrijving.

[Kees]

Sinds dit jaar moet je de bedrijsnaam voeren en mag de handelsnaam niet meer volgens mijn certificaat verkoper

[Anoniem: 781715]

Waarom zouden jullie niet 'Tweakers.net BV' weer kunnen inschrijven bij de Kamer van Koophandel en als organisatienaam kunnen opgeven?

"Tweakers.net B.V.KvK 24331300Rechtspersoon24331300 810596052. Tweakers.net BV. Besloten vennootschap met gewone structuur.Deze rechtspersoon is uitgeschreven uit het Handelsregister"

Een EV certificaat hoeft geen honderden Euro's te kosten als je maar weet waar je ze goedkoop kunt krijgen. Hier $79 per jaar met coupon CHEAPEV79. Of deze EV SSL aanbieding van $46.85 voor het allereerste jaar. Als direct bij Comodo een EV SSL certificaat koopt dan kost het 99 Euro per jaar.

[Reactie gewijzigd door Anoniem: 781715 op 22 juli 2024 16:55]

[JJ93]

Omdat het bij een EV SSL certificaat gaat om de officiële naam zoals de eigenaar van de website bekend is bij de Kamer van Koophandel. En dat is dus niet Tweakers maar 'Persgroep Online Services B.V.'.

En denk je nou echt dat de developers bij Tweakers niet een onderzoekje hebben gedaan naar zogenaamde goedkope EV certificaten? Het heeft gewoon geen meerwaarde voor een site als Tweakers. En zeker met de manier hoe de organisatie in elkaar zit zal een groen balkje met Persgroep Online Services B.V. niet echt positief bijdragen als een gevoel van veiligheid.

[Anoniem: 781715]

Reactie van ACM: "EV hebben we niet echt bekeken, maar dat is sowieso veel meer. Maar dan heb je het over van zo'n 1000 euro per jaar naar zo'n 2000 euro per jaar."

Als ik de reactie van ACM lees, dan denk ik inderdaad dat de developers bij Tweakers niet een onderzoekje hebben gedaan naar zogenaamde goedkope EV certificaten

[JJ93]

Met de aanbiedingen gaat het alleen om één jaar. Denk niet dat ze elk jaar naar een andere provider willen overstappen. De twee certificaten waar je naar linkt zijn ook alleen geldig voor één domein, dus geen subdomeinen over andere websites.

Inmiddels heb je de gegevens van Tweakers uit het KvK register bijgevoegd. Zoals in je eigen tekst al staat: "deze rechtspersoon is uitgeschreven uit het Handelsregister". Het valt dus niet onder Tweakers B.V. maar toch echt Persgroep Online Services B.V. met KvK nummer 34265814.

[Anoniem: 781715]

Op internet kun je elk jaar wel een EV SSL certificaat vinden met een vergelijkbare prijs. EV SSL certificaten zijn normaal gesproken maximaal 2 jaar geldig. Meer domeinennamen kost meer en een wildcard domein is niet mogelijk bij EV.
Bijvoorbeeld €290,00 per 2 jaar voor 2 domeinnamen (gemiddeld €72.50 per jaar voor 1 domeinnaam). € 85,00 per jaar 2 voor elke extra domeinnaam. (gemiddeld €42.50 per jaar voor 1 domeinnaam)

[Anoniem: 169091]

Interessant stuk over de plaatjes die vanaf een http site komen. Geeft dit geen problemen met het auteursrecht, of valt dit onder toegestane caching?

[Rafe]

Ik denk niet dat dit in gebruik is genomen zonder het af te stemmen met de juridische afdeling van De Persgroep, maar er zijn wel een paar dingen die je kan bedenken waarom het geen probleem is:

• Het wordt gedaan om puur technische redenen, niet om winst te maken.
• Afbeeldingen die via camo worden geladen krijgen serverside een HMAC toegevoegd in de URL, zonder een geldige HMAC krijg je niets te zien. Op deze manier draai je geen open proxy die door anderen kan worden misbruikt.
• Het veel grotere GitHub is er ook niet om aangeklaagd in een jurisdictie waar men dat sneller doet om grotere bedragen dan hier in Nederland

@ACM: bedankt voor de credits van de tip!

[Reactie gewijzigd door Rafe op 22 juli 2024 16:55]

[WhatsappHack]

Waarom zou github aangeklaagd worden voor het hosten van een script?
Dat gaat niet.

Het is wel zo dat grote namen in bijvoorbeeld de forum wereld, zoals XenForo en SMF, ook zo'n systeem hebben. De klanten krijgen slechts extreem sporadisch een DMCA of equivalent daarvan, vanwege de regels rondom caching. In de EU is dat wat beter dan in de VS overigens, vind ik.

In principe ben je vanwege de doorgeefluik functie dus geen inbreuk aan het maken, al zullen sommigen dat wel zo zien. Maar de richtlijnen van de EU op dit vlak zijn nogal helder. Het aantal take down requests dat je krijgt zal waarschijnlijk nihil zijn zolang de cache maar vluchtig is... Een afbeelding moet na x tijd niet opgevraagd te zijn expiren en dan is het goed en geen schending.

Overigens zullen sommige mensen hier juist super blij mee zijn, omdat je dan ook geen traffic meer "steelt" door afbeeldingen te hotlinken. Die komen nu immers uit de lokale cache.

[Rafe]

Waarom zou github aangeklaagd worden voor het hosten van een script?
Dat gaat niet.

Zoals in het artikel staat is camo ontwikkeld door en in gebruik bij GitHub, daar doelde ik op.

[mace]

Nu nog HSTS en HPKP gaan gebruiken en dan zou het helemaal af zijn.

Verder zie ik dat jullie 3DES aan hebben staan, is het een vereiste om XP nog te ondersteunen?

[ACM]

HPKP is met de introductie van letsencrypt wel lastiger geworden, omdat het certificaat elke paar maanden verandert

Maar HSTS komt sowieso ook nog. Voor je 3DES-vraag zal ik Kees nog even vragen waar dat voor is, zou inderdaad voor oudere browsers kunnen zijn.

[mace]

Je kunt ook met Let's Encrypt steeds dezelfde sleutel blijven gebruiken, dan moet je een CSR maken en die gebruiken met de --csr optie. Op deze manier gebruik ik ook Let's Encrypt icm HPKP.

[Kees]

Dat is inderdaad een goede tip. We gebruiken al een eigen csr (anders kun je geen ecdsa certificaten krijgen) dus dat moet niet al te moeilijk in te bouwen zijn

[Kees]

En ook omdat ik nog geen volledig correcte cipherlist heb bedacht voor http/2 met ecdsa en rsa certificaten

[526735]

Ik zou de volgende gebruiken https://mozilla.github.io...tls/ssl-config-generator/

[Kees]

Ik ook, ware het niet dat ik geen apache of nginx gebruik voor ssl (maar een proprietary oplossing van Brocade, waar ik de vraag ook al uit heb staan )

[SleutelMan]

In dezelfde categorie: Ik zie dat jullie zowel DHE als ECDHE ondersteunen... die 1e geeft nogal een performance penalty en ik vraag me af hoeveel compatibility je ermee wint ;-).

In dat kader kan ik het OpenSSL cookbook en in het verlengde daarvan het Bulletproof SSL and TLS boek van Ivan Ristić aanbevelen, Zeker in die laatste wordt er uitgebreid ingegaan op performance van de verschillende cipher suites en de keuzes om bepaalde suites wel of niet te ondersteunen.

[Reactie gewijzigd door SleutelMan op 22 juli 2024 16:55]

[The Zep Man]

HPKP is met de introductie van letsencrypt wel lastiger geworden, omdat het certificaat elke paar maanden verandert

Zoals mace aangeeft werkt HPKP via public key pinning i.p.v. certificate pinning. Je kan dus hetzelfde keypair gewoon recyclen voor meerdere certificaten. Geef wel een backup key op (en bewaar daarvan de private key ergens offline/in een HSM), zodat je een uitwijkoptie hebt.

Maar HSTS komt sowieso ook nog. Voor je 3DES-vraag zal ik Kees nog even vragen waar dat voor is, zou inderdaad voor oudere browsers kunnen zijn.

Zie de Qualys SSL Test. 3DES is volgens mij alleen nodig voor Internet Explorer 8 onder XP. Dan zou het wel weg kunnen...

[Reactie gewijzigd door The Zep Man op 22 juli 2024 16:55]

[CyBeR]

HPKP is met de introductie van letsencrypt wel lastiger geworden, omdat het certificaat elke paar maanden verandert

Als je 't fout doet wel ja.

Je pint met HPKP de public key, niet het certificaat. Je kunt de key gewoon een tijdlang blijven hergebruiken.

[526735]

HPKP kan well met Let's Encrypt zie https://scotthel.me/LE

[Armin]

Behalve XP ook mensen die achter oude/slechte bedrijfs proxies zitten.

Merk ook op dat er in principe niets mis met 3DES is. Het is zwaar voor zowel server als client, maar nog steeds veilig, al is CBC chain mode niet helemaal ideaal.

En zoals nu geconfigureerd wordt het enkel gebruikt in hele grote uitzonderingen voor hele oude clients, dus qua server-load zal je er zo goed als niets van merken schat ik zo in.

[Slavy]

Totaal niet zeikerig bedoelt (ben er echt blij mee! ) maar waarom nu pas anno 2016? Als dé site die over IT nieuws gaat en waar veel security kwesties voorbij komen had dit stiekem toch al gebeurd moeten zijn?

[Anoniem: 28912]

Omdat het eigenlijk geen meerwaarde heeft. Het toevoegen van https is puur de schijn van veiligheid. Een MitM attack kan nog gewoon voorkomen, tenzij je alleen naar tweakers en bank browst en verder niet en dan nog loert het malvertising gevaar nog altijd.

Het enige voordeel is dat je baas niet meer mee kan lezen. Maar als je baas zich de hele dag alleen maar met dat soort dingen bezig houdt, zou je je kunnen afvragen bij wat voor soort club je werkt.

De overheid zou theoretisch nog gewoon mee kunnen lezen. Nu heeft de Nederlandse Inlichtingendienst een ander budget dan de Amerikaanse, maar het is een flink poos geleden al aangetoond dat 128bits encryptie destijds makkelijk met distributed computing te kraken viel, laat te raden over hoe snel het met een modern serieus cluster gaat.

[MikeN]

het is een flink poos geleden al aangetoond dat 128bits encryptie destijds makkelijk met distributed computing te kraken viel

Enlighten me? Volgens mij weet je iets wat de rest van de wereld niet weet. AES128 is voor zover ik weet (en voor zover bijv. Wikipedia weet) niet echt te bruteforcen op dit moment.

Ik denk dat je het verwart met asymmetrische crypto, dat is heel wat anders.

Een MitM attack kan nog gewoon voorkomen

Hoe bedoel je dit? Natuurlijk kan je eigen PC problemen hebben (maar dat is wat mij betreft geen echt MitM), maar de verbinding zelf zou je niet tussen moeten kunnen komen hoor.

[Anoniem: 28912]

Ik doelde op dit project: https://en.wikipedia.org/wiki/Moo!_Wrapper

RC5 werd destijds als veilig beschouwd maar werd maar trage thuis computertjes gekraakt.

Als je naar de derde website wel malware op staat, raak je gewoon alsnog geïnfecteerd. Je zou verkeer op de achtergrond gewoon kunnen forken en 2 richtingen op kunnen sturen. Man-in-the-middle attack begint bij een lokale malware die een redirect/kopie doet. Hackers zitten niet ergens op de zeebodem bij een internet kabel met wireshark ofzo. (tussen de echte sharks)

[CyBeR]

Ik doelde op dit project: https://en.wikipedia.org/wiki/Moo!_Wrapper

RC5 werd destijds als veilig beschouwd maar werd maar trage thuis computertjes gekraakt.

RC5 is wel even een iets ander verhaal dan AES. Er is nog geen enkele manier om AES 128 binnen driehonderd eeuwen te kraken.

[Anoniem: 28912]

300 eeuwen op een systeem met hoeveel PetaFLOPS? Ik bedoel als je een periode schat, zal je ook de gebruikte apparatuur in je schatting specificeren.

Waarom eist de Amerikaanse overheid AES256 voor zijn top secret documenten?

https://blog.agilebits.co...ving-to-256-bit-aes-keys/

[CyBeR]

300 eeuwen op een systeem met hoeveel PetaFLOPS? Ik bedoel als je een periode schat, zal je ook de gebruikte apparatuur in je schatting specificeren.

Maakt niet uit. Er is geen manier om AES128 sneller te kraken dan met brute force.

Waarom eist de Amerikaanse overheid AES256 voor zijn top secret documenten?

Wel 't is niet alsof Amerikanen erom bekend staan shit te overdrijven.

[psyBSD]

Wel 't is niet alsof Amerikanen erom bekend staan shit te overdrijven.

Je moet bij encryptie in ogenschouw nemen hoe lang een document vertrouwelijk moet blijven voordat het zijn relevantie (voor jou en voor derden) heeft verloren. Onze belastingaangifte en bankafscriften zijn een stuk sneller obsolete dan een top-secret overheids-document.

Correspondentie van onze Koningin ten tijde van de tweede-wereld oorlog is pas nu openbaar gemaakt. Nu kun je je afvragen of 70 jaar niet een beetje overdreven is, maar als het 'maar' 30 jaar is (nog steeds veel meer dan de gemiddelde documenten die wij thuis hebben liggen) dan kunnen de spelers die daarin genoemd worden / bij betrokken zijn nog steeds op het toneel meespelen. De 'koude oorlog' heeft ruim 40 jaar geduurd, en sommige zeggen dat deze nu weer op laait. Je kunt je voorstellen dat sommige informatie uit die tijd nu nog steeds relevant/vertrouwelijk is. Datzelfde zal over 30 jaar gezegd kunnen worden over sommige documenten van vandaag. Daarom schrijft men deze encryptie voor, omdat het niet alleen nu, maar (met een aan zekerheid grenzende waarschijnlijkheid) ook nog over 30 jaar geheim moet blijven.

[MikeN]

RC5 werd destijds als veilig beschouwd maar werd maar trage thuis computertjes gekraakt.

RC5 werd helemaal niet als veilig beschouwd, anders was dat hele bruteforce project niet gestart. Ze zijn daarbij maar tot 64 bit gekomen tot nu toe, overigens.

Man-in-the-middle attack begint bij een lokale malware die een redirect/kopie doet

Dat is geen MitM, dat is gewoon een lekke client. MitM is iemand die op jouw lokale treinwifi meekijkt, en dan iets in je verbinding stopt. En daar helpt Tweakers over HTTPS zeker wel tegen.

[Anoniem: 28912]

Je hebt gelijk wat betreft lekke client. Ik liep even wat dingen door elkaar te gooien, Mea Culpa!

Het is inderdaad alleen nuttig voor die mafkees die ergens persé op een publieke WiFi allemaal heel gevoelige zaken wil doen.

[Eagle Creek]

Het enige voordeel is dat je baas niet meer mee kan lezen. Maar als je baas zich de hele dag alleen maar met dat soort dingen bezig houdt, zou je je kunnen afvragen bij wat voor soort club je werkt.

Mijn baas kan nog steeds meelezen want hij breekt de verbinding open en plakt hem netjes weer dicht voordat het op m'n werkplek aankomt. Datzelfde trucje passen meerdere applicaties, zoals virusscanners, toe waardoor dit argument zeker niet waterdicht is .

[Armin]

Dat kan hij enkel op jouw bedirjfs-PC. Dat is dan ook geen MitM aanval, maar een samenwerking tussen de client en de malware/proxy server van jullie werkgever. De client weet namelijk dat hij niet echt met Tweakers.net spreekt, maar accepteert het omdat het root-certifciaat van de scanner/proxy als vetrouwd is aangemerkt.

Zou jij met je privé computer, telefoon, etc op het bedrijfsnetwerk hetzelfde doen (wat ongetwijfedl tegen jullie bedrijfsvoorwaarden is ) dan zul je of een dik rood schild/kruis/etc krijgen, of het systeem is slim genoeg geen redirect te doen en het verleer ongemoeud te laten. Dat laatste is uiteraard dan wel een security-lek.

Maar ook, zou iemand anders dan die bedrijfs scanner/proxy een echte MitM aanval uitvoeren, zou ook die bedrijfs-PC alarm slaan. Immers hij staat het enkel toe bij servers waar het certifciaat als betrouwbaar aangemerkt is.

[Blizz]

Het enige voordeel is dat je baas niet meer mee kan lezen.

Een blik via RDM en je leest zo mee hoor. Dus zelfs dat kun je afstrepen.

[Anoniem: 28912]

Touché! Hahaha.. Inderdaad! Of stiekum een spy-cam op je scherm gericht

[Yamotek]

Of een baas die gewoon die lekker persoonlijk gewoon over je schouder meekijkt .

[Kees]

Performance, complexiteit van de site, performance, snelheid van de site. En gewoon geen prioriteit gegeven, er waren belangrijkere dingen te bouwen.

[SBTweaker]

Wat bedoel je met complexiteit?

[Kees]

Gewoon http->https redirect aanzetten was niet genoeg, we moesten ook alle (user)content bij langs gaan om mixed content issues te voorkomen. En een proxy opzetten voor (user)content die niet via https aangeboden kan worden etc.

Het was niet zo triviaal als een ssl certificaat regelen en een redirect in de apache config zetten.

[MonotoneJeroen]

Ik had vroeger op mijn phpbb forum een probleem met mixed content.
Ik zag dat GitHub gebruikt maakt van Camo en dat er een extension is voor phpbb dat automatisch afbeelding src rewrite.

Het duurde eventjes, maar ik heb camo geïnstalleerd op mijn dedi en de phpbb extension werkt nu ook.
Ik heb nog niet klachten gehoord van gebruikers en ik draai het nu al een lange tijdje.

hwhat

Edit: Dit is de phpbb extension dat URLs rewrite naar Camo: https://github.com/phpbb-extensions/camosslimageproxy

[Reactie gewijzigd door MonotoneJeroen op 22 juli 2024 16:55]

[defixje]

Uhm ik zie 3 keer Performance, zo kan ik er ook nog wel een paar verzinnen om mijn bericht kracht bij te zetten.

[Kees]

uhuh

Het was ook de belangrijkste reden om het niet eerder te doen. Maar die performanceredenen zijn met http/2 en ecdsa certificaten grotendeels nietig geworden en dus kunnen we overstappen.

[Ge Someone]

Volgens mij kon je Tweakers al een hele tijd met https bereiken (ik gebruik https everywhere). Er was alleen nog wat mixed content en er wordt uitgelegd wat er aan de historie, de fora en de blogs moest gebeuren. Dit artikel lijkt mij meer om aan te geven dat het project nu afgerond is, en hoe het gedaan is.

[Frenziefrenz]

En het staat nu standaard aan natuurlijk, niet enkel als je er specifiek om vraagt.

[Inperiosus]

Als je het artikel volledig had gelezen, had je het geweten:

We hebben ruim een jaar geleden ons dilemma om wel of geen https te nemen aan de bezoekers van Tweakers voorgelegd. Uiteindelijk hebben we daarna besloten om de introductie van https uit te stellen. Een van de redenen was dat de voor encryptie benodigde rekenkracht en vooral de connection setup van https, zoals het uitwisselen van certificaten, ten op zichte van http nog een zichtbare invloed op de prestaties van de website hadden.

Intussen is de wereld echter veranderd. De benodigde rekenkracht is minder relevant geworden, onder andere door de verdere opkomst van snellere cpu's en aes-instructies in die cpu's. Daarnaast is de bijbehorende software verder geoptimaliseerd. Ten slotte hebben we zelf ook meer geleerd over https, zoals welke tunables er bestaan en welke encryptievormen sneller werken dan andere.

[koku]

Voor een site als Tweakers is het wat meer werk dan even een certificaatje uploaden, zoals je kan lezen in dit artikel. In onderstaand artikel zie je ook nog wat afwegingen: plan: Dilemma: moet Tweakers https inzetten?

[Reactie gewijzigd door koku op 22 juli 2024 16:55]

[SBTweaker]

Zie de top reactie bij dat artikel die de meeste argumenten al ontkracht.

[YangWenli]

ArsTechnica.

In dat geval was het iets met reclame.

[SampleUser]

Wat ik mij afvraag: hoe verifiëren jullie Tweakers.net bij Let's Encryptie? Aangezien jullie meerdere servers hebben waarover de load wordt verdeeld lijkt het me even te duren voordat het verificatie bestandje overal zichtbaar is..

[Anoniem: 9278]

Wat je normaliter doet is je certificaat op de loadbalancer (LB) installeren. Vanaf daar is het allemaal HTTP verkeer. Zo werkt dat in ieder geval bij AWS (Amazon Web Services). Zodoende kun je makkelijk servers toevoegen/verwijderen, en heb je alleen op de LB extra CPU cycles nodig voor de encryptie.

[Kees]

Het gaat hier niet over de certificaten instaleren, maar over het verkrijgen van de certificaten. Letsencrypt doet dit door tegen de letsencrypt server te zeggen 'ik wil een certificaat voor tweakers.net'. De server zegt dan 'bewijs maar dat jij tweakers.net beheert, dat kun je doen door dit bestandje op je webserver te plaatsen onder https://tweakers.net/ .well-known/acme-challenge/sdkj239isd9213lksd'. Vervolgens vraagt die server dat bestand op en als de inhoud overeenkomt met wat hij ons stuurde dan bewijst dat dat wij inderdaad de (volledige) controle over tweakers.net hebben en krijgen wij het certificaat.

Echter, in ons geval kan 'tweakers.net' op 8 verschillende fysieke webservers terecht komen zonder dat ik van te voren weet op welke server het terecht gaat komen. Dan moet je dus de challenge van LetsEncrypt naar 8 verschillende webservers distributeren want anders loop je het risico dat de check faalt en je geen certificaat krijgt.

Om dit op te lossen heb ik in de loadbalancer ingesteld dat al die letsencrypt requests naar 1 specifieke server gaan en dat was de vraag die hij stelde

[Reactie gewijzigd door Kees op 22 juli 2024 16:55]

[Kees]

Op de loadbalancers vang ik alle requests naar /.well-known/acme-challenge/* af en die stuur ik door naar de (ene) server waar letsencrypt draait. Letsencrypt draait overigens in standalone mode en is dus alleen bereikbaar als ik certificaten aan het opvragen ben.

[fvanottele]

Netjes, een goede A rating (ben niet anders gewend van letsencrypt)

https://www.ssllabs.com/s...s%3A%2F%2Ftweakers.net%2F

[Rafe]

Het certificaat van Let's Encrypt heeft daar maar deels invloed op, als serverbeheerder kan je ook de onveilige protocollen (SSL v3) en algoritmes aan laten staan die je score daar omlaag halen. Daarom ook even bij https://mozilla.github.io...tls/ssl-config-generator/ of https://cipherli.st kijken voor de juiste configuratie.

[Ikkerens]

Je hebt deels gelijk.

Ja het is van invloed op de serverbeheerder, maar de auto-wizard van LetsEncrypt geeft je standaard al een apache/nginx configuratiebestand met de als-goed-bevonden ciphers en protocollen.

[CyBeR]

Ik gok zomaar dat kees niet de auto-wizard van LE gebruikt heeft.

[Ikkerens]

Daar ben ik het met je eens, mijn comment sloeg ook meer op LetsEncrypt als geheel, wat bij Rafe ook het geval was volgens mij.

Desondanks is de meegeleverde configuratie nog steeds een mooi uitgangspunt.

[Armin]

(ben niet anders gewend van letsencrypt))

Alleen het overweldigende merendeel van de A-rating is niet het certificaat, maar de server configuratie. Credits dus voor Tweakers, niet LetsEncrypt

[fvanottele]

Ja dat is waar, mijn fout. Desondanks is LetsEncrypt een geweldig initiatief.

[CAPSLOCK2000]

Daar heeft LE niks mee te maken, die score wordt bepaald door de configuratie van de systeembeheerder, en zoals het Tweakers beaamd is het goed geconfigureerd. Hoe tof LE ook is, hier hebben ze niks mee te maken.

[Anoniem: 407039]

Ik had toch A+ verwacht.. Zoals op mijn sites.

[Yggdrasil]

Er is niks mis met A hoor. Dat is een uitstekende score.

A+ is alleen mogelijk als je ook HSTS inschakelt. Ik kan me voorstellen dat Tweakers dat pas over enkele maanden doet als alles bewezen heeft goed te functioneren. Het wordt dan immers vrijwel onmogelijk om HTTPS nog uit te schakelen, mocht er iets mis zijn.

[REDSD]

Heeft de overstap naar https ook als reden gehad dat zoekmachines prioriteit willen geven aan websites met https ondersteuning?

[fvanottele]

Dat is altijd mooi meegenomen:)

[Inspector]

Dit heeft dermate weinig impact op de SEO dat dit geen (misschien voor enkele een heel kleine) reden was.

[Sgreehder]

Lijkt mij een voorbarige conclusie. Het geeft misschien niet juiste signaal af aan bezoekers, maar het zou in de context van Tweakers waarschijnlijk het belabgrijkste argument voor zijn.

Zie bijv. ook:

https://webmasters.google...ps-as-ranking-signal.html

[koku]

Nee zover ik weet niet. Maar het is mooi meegenomen natuurlijk.

[WeAreLegion]

Zoals jullie al zeggen heeft het op zich weinig toe te voegen, maar vind het wel netjes dat jullie overgestapt zijn. Alle beetjes helpen en of dat nou voor de abn amro site is of voor tweakers dat maakt in dat geval niet zoveel uit.

[mailis]

De enige extra toevoeging van HTTPS is volgens mij dat Google een standaard de HTTPS variant gaat indexen en Chrome in de toekomst geen errors gaat geven. In het artikel wordt daar indirect naar verwezen, maar ben benieuwd of dit uiteindelijk voor de ranking in Google ook nog een positief effect heeft.

[stier]

Als je zoekt is dat nog niet geïndexeerd.

[ACM]

Ik denk niet dat het voor ons heel serieus meetbare effecten gaat geven op Google's ranking. Het is een van de vele factoren die ze mogelijk mee wegen, de inhoud van een pagina is alsnog wel belangrijker dan dat soort factoren.

[NotSoSteady]

Ze doen het niet alleen voor jullie, HTTPS is sinds enige tijd ook een rankfactor in Google, oftewel hogere posities in de zoeklijsten.

[JPtjeeNL]

"Helaas heeft Let's Encrypt geen ondersteuning, en plannen, voor wildcardcertificaten, waardoor we met name het certificaat voor *.tweakblogs.net alsnog los moeten blijven voeren."

Misschien eens goed om te kijken bij WordPress.com. WordPress.com gebruikt voor *.wordpress.com blogs ook Let's Encrypt en genereert die certificaten achteraf. Correct me if I'm wrong.

[teunw]

Je kunt certs laten maken via de commandline, dat zal wel de manier zijn waarop WordPress dat doet

[JPtjeeNL]

Ja waarschijnlijk gebruiken ze de Let's Encrypt agent met een cronjob. Ik heb dat ook draaien op een Ubuntu server.

[Ventieldopje]

Met @Teunwillems, gewoon op inhaken en een certificaat genereren bij het aanmaken van een blog. Let's Encrypt heeft volgens mij een goeie API om dat te doen.

[teunw]

Ja, en nog een automatische configurator voor Apache servers. Dat kan ook nog, als je op die manier Wordpress host.

[MsG]

Tweakers zou gedeeltelijk het probleem met mixed content ook kunnen oplossen door de afbeeldingsuploadmogelijkheden van Tweakers grondig te moderniseren, zodat veel meer afbeeldingen bij Tweakers zelf blijven, waardoor je ook niet krijgt dat hele topics kapotte plaatjes hebben, omdat de betreffende host niet meer bestaat.

Op Github kan ik met een simpele CTRL-V mijn clipboard legen, waarbij hij intern zorgt voor hosting van het plaatje. Hier bij Tweakers is het toevoegen van afbeeldingen nog redelijk veel werk helaas.

[SampleUser]

Wat dan misschien ook een idee is om een retentie in te stellen; na 2 jaar zal toch niemand meer naar een klein topic kijken. Mijn server heeft een retentie van 1,5 jaar, wil je daarna mijn afbeeldingen zien ga dan maar lekker naar de WayBackMachine of zo.

[MsG]

1.5 jaar is voor zo'n kennisbank als GoT echt heel kort. Dan nog niet eens te spreken van de bredere topics in de Tweakers Huiskamer.

[Anoniem: 457607]

Eens. Om heel eerlijk te zijn vind ik hotlinken zonder expliciete toestemming (wat in feite gebeurd wanneer je gebruikers willekeurig plaatjes laat embedden) uiterst onbeschoft. Het is bandbreedte diefstal.

Uiteraard kan een derde partij zich hier tegen beschermen en het niet toestaan, maar het principe blijft overeind, tenzij de derde partij expliciet hotlinken toestaat of zelfs aanmoedigd (zoals imgur).

Buiten dat is het gewoon een gebrekkige implementatie waarvan je zeker weet dat op termijn ongeveer al je image content onbruikbaar wordt.