"Slecht dat je niet eens kan inloggen wanneer je advertenties blokkeert."

Nee, slecht dat je advertenties blokkeert met een hosts file. Dat is een methode die te grofstoffelijk werkt, het kan
best zijn dat een host die advertenties levert ook betrokken is bij andere functionaliteit op een site.
Als je dit niet wilt moet je meer gedetaiileerd ingrijpen op de URL dus een adblocker gebruiken die in de browser werkt.

Gebruik je Windows? Een hosts bestand gebruiken is in een Windows omgeving geen niet te omzeilen methode, omdat Microsoft al lange tijd het hosts bestand, wanneer zij dat een goed idee vindt, negeert. Lang leve closed-source security-though-obscurity!
Gebruik een pi-hole als je een gebruiksvriendelijke gemakkelijk oplossiing op dns-niveau zoekt.

RTLXL is een waardeloze website, maar wat wil je? Het is een geval van een commercieel televisie bedrijf. Je weet wel, een dino. Wel was het iig tot voorkort mogelijk addblocking via een plugin in een van de betere browsers te gebruiken voor de website van RTL.

Oke bedankt voor deze (nutteloze) informatie.

Jij doet iets op jouw machine, die niet ondersteund is door RTL, en daardoor werkt er iets niet meer. En dan leg je de schuld bij RTL? Volgens mij moet je bij je zelf kijken.

Ook hier weer, Ja. Jij doet dingen die RTL XL niet test en ondersteund. Werkt het niet, dan heb jij gewoon een probleem.

WTF is dit nu voor iets inderdaad. Bij mij gewerkt alles gewoon goed. WTF doe jij dan voor vreemde dingen.
Het probleem zit hem in jouw configuratie, niet iets bij RTL.

Heb je hier ook een bron van?

Gebruik gewoon Chrome met uBlock Origin. Beste oplossing tegen advertenties en andere ongewenste content, IMO.

Een van de meest commerciele portals zonder commercials... right.

Interessant: Een goed bijgehouden hostsbestand (met bijvoorbeeld een tool als hostsman) is in staat tot honderdduizenden domeinen te blokkeren. Er zijn zelfs complete communities die ongewenste ip adressen bijhouden en waar complete hostsbestanden gedownload kunnen worden....Ik gebruik deze methode naar volle tevredenheid en blokkeer momenteel 604.000 malware/ad/domeinen. Beter dan welke adblocker ook!! Ik hoor heel graag wat meer informatie van je over deze onbetrouwbaarheid.

Rinjani, kan je het niet beter anders aanpakken?

Ik gebruik in Firefox (onder Debian) de add-ons NoScript en Privacy Badger. NoScript blokkeert al alle uitvoerbare code (en dus malware) tenzij je aangeeft een site te vertrouwen, en Privacy Badger vangt vervolgens af wat van tracking-sites geladen wordt (niet op basis van blacklists maar van inspectie van wat er eigenlijk geladen wordt; als meerdere sites uit dezelfde bron laden zou het wel eens een tracker kunnen zijn, dat soort logica).

NoScript alleen al is voldoende om content die malware kan bevatten te blokkeren. Dat is namelijk altijd uitvoerbare code en dat is nou net wat NoScript blokkeert. Privacy Badger vangt vervolgens in wat er nog wel geladen wordt zaken af die uit privacyoverwegingen ongewenst zijn. Het hangt af van welke sites je bezoekt, natuurlijk, maar bij mijn websurfgedrag doen de meeste websites het goed genoeg om de inhoud te kunnen zien, en laden ze nog eens aanzienlijk sneller dan zonder de genoemde add-ons omdat ontzettend veel meuk wordt geblokkeerd.

Maar er zijn sites die amper aan de praat te krijgen zijn, zeker als je probeert selectief dingen toe te staan in NoScript terwijl je niet kan beoordelen wat voor de werking echt nodig is en wat niet. Daarvoor heb je een voorziening nodig om een minder gelimiteerde browser te kunnen starten die toch geen schade kan aanrichten.

Daarvoor gebruik ik firejail, een sandbox-programma voor Linux. Het wordt geleverd voor profielen voor allerlei programma's, waaronder firefox. Voor gewoon gebruik op mijn systeem werkte dat niet lekker, dus heb ik een aangepast profiel gemaakt. Het vergt wat uitproberen en aanpassen. De interessante mogelijkheid van firejail voor dit doel is de commandline-optie --private, waarmee een programma, hoewel je onder je eigen user draait, een lege home-directory voorgeschoteld krijgt en dus draait alsof het initieel gestart wordt (in het geval van Firefox dus zonder add-ons). Wijzigingen die het programma aanbrengt worden niet bewaard, het is een wegwerpsessie. Let op dat je Firefox met de optie --no-remote start, anders krijgt een lopende Firefox een signaal dat het de opgegeven URL moet openen. Er is een mogelijkheid om ook dat af te schermen (de optie --x11 van Firejail, die drie manieren ondersteunt om de browser van de X11-sessie af te schermen).

Met de add-on Open With kan je vanuit je reguliere Firefox-sessie een website in een jail openen via de rechtermuisknop.

Als je echter je reguliere Firefox-sessie zelf al in (een minder restrictieve) firejail hebt draaien werkt dat niet. Sandboxen nesten gaat niet goed omdat ook de capaciteiten die nodig zijn om een sandbox te creëren worden afgeschermd door de sandbox. Dat kan wellicht ook met de aangekondigde ingebouwde sandbox van Firefox een probleem gaan vormen (Debian werkt met Firefox ESR, dus het duurt nog even voor ik daarmee te maken krijg). Ik heb dat voor mezelf opgelost door met Open With de te openen URL in een bestandje te schrijven op een locatie onder /tmp waar de reguliere sandbox toegang toe heeft, en een monitorproces dat ik als onderdeel van mijn grafische sessie start pakt dat op en start de restrictieve sandbox. De details zijn te omvangrijk om hier te publiceren, en zitten vol met mijn persoonlijke voorkeuren en eigenaardigheden. Maar weet dat het kan.

Maar je kan het met wat handwerk ook zonder dat soort constructies doen, en als, zoals hier, om een website gaat die je vaker gebruikt kan je een commando in een bash-script zetten:

nee, het is gesloten bron.

Of gebruik gewoon https://pi-hole.net/ Super!!!!!!!!!!!!!

Goed, hierbij een aanvulling op de reactie van donderdag 18:50

Een hosts bestand is er niet voor niets, maar Microsoft doet liever haar eigen ding zoals wel vaker.
Dat microsoft de hosts file te regelmatig negeert moet ik nogmaals aanwijzen.

%WINDIR%\system32\dnsapi.dll beval bijvoorbeeld hardcoded ip-adressen.
microsoftupdate.microsoft.com, msn.com, etc

Hosts die reclame en daarmee de bijbehorende malware serven blokkeren is natuurlijk een prima idee. De betere netwerk firewalls en routers hebben er ook opties voor.
Lokaal op Windows is het bijhouden van de dns-lijsten is eenvoudig te regelen m.b.v. een programma als HostsMan van abelhadigital.com .
Een dns blokkade voor adds op netwerk-niveau is echt eenvoudig te regelen met een Pi-hole.

Jij claimt dat het advertentieservers zijn. Maar wellicht is dat helemaal niet zo, zijn het alleen servers voor het
aanleveren van onderdelen van de website waaronder wellicht advertenties of dingen die jij als advertenties ziet.
(zoals plaatjes, maar vanaf dezelfde server ook javascripts die voor het inloggen nodig zijn)

Nee, het blokkeren van een hele server omdat die toevallig advertenties levert is niet de meest handige en
betrouwbare manier om ads te blocken.

Als zowel advertenties als iets wat voor inloggen nodig is vanaf hetzelfde domein of subdomein geserveerd worden zou ik daar zenuwachtig van worden. Alleen gaat het hier om blokkeren met een hosts-file, op IP-niveau in plaats van domein-niveau, en qua domein keurig gescheiden zaken kunnen vanaf hetzelfde IP-adres geserveerd worden zonder dat het iets met elkaar te maken heeft. Vanuit dat perspectief gezien is blokkeren met een hosts-file onhandig. Aan de andere kant lijkt het me nogal onwaarschijnlijk dat een advertentienetwerk geen eigen IP-adressen heeft. Als die ook login-code leveren is er reden om zenuwachtig te worden.

Verder erger ik me aan de toenemende mate waarin websites (en CMS'en en CMS-themes) van alles en nog wat van JavaScript afhankelijk maken dat rechtstreeks door HTML ondersteund wordt. Laat een hyperlink alsjeblieft gewoon een hyperlink in HTML zijn, en laat een formulier, zeker een loginformulier alsjeblieft gewoon een ouderwets HTML-formulier zijn dat geen JavaScript nodig heeft om te werken. Een zonder JavaScript werkende HTML-basis blokkeert in het geheel niet de mogelijkheid om vervolgens JavaScript de zaak over te laten nemen, als je een niet werkende basis met JavaScript tot iets werkends om kan bouwen kan je een wel werkende basis tot exact hetzelfde ombouwen met JavaScript. Dat heeft een directe relatie met de toegankelijkheid van een website voor mensen met beperkingen, inclusief de beperking van het werken op een systeem dat minder krachtig is dan dat van de ontwikkelaars met een internetpijplijn die minder bandbreedte heeft. Dat veel websitebouwers dat negeren is ook een deel van het probleem hier, lijkt me.

Je hebt gelijk, ik was kennelijk nog niet helemaal wakker.

Wie zegt dat het gaat over een advertentie netwerk?? Volgens mij heeft hij gewoon een server die onderdeel is van
het betreffende domein in zijn hostsfile gezet omdat er advertenties vanaf kwamen, wellicht gewoon een paar plaatjes
die men lokaal gehost had (een static content server), en nu blijkt dat er ook andere dingen vanaf gehaald worden en
gaat het mis.

Bovendien kun je wel allerlei beelden hebben over wat "netjes gescheiden kan worden" maar zo'n site wordt gebouwd
om geld mee te verdienen niet om netjes te zijn, en het zou zelfs kunnen dat die bouwers heel goed weten dat er
op naieve wijze ads geblokkeerd worden en JUIST dingen doen om de mensen daar nat mee te laten gaan.
Wellicht is er ergens iemand die zijn adsite hostfile nu maar weer weg gehaald heeft en dat is dan een punt gescoord
voor de sitebouwer in de wedstrijd tussen verdienen en ads blokkeren.

Wanneer je inlogt met je RTL XL account, komen er verbindingen tot stand richting Gigya. Gigya biedt 'Registration as a service' aan, maar lijkt ook haar hand niet om te draaien voor wat tracking en het profileren van gebruikers.

Van de Gigya dev page:
Ik gok dat hierdoor een aantal domeinen van Gigya in de 'blacklist' van StevenBlack staan :)

Wat is eigenlijk een goede lijst, die onderscheid maakt tussen veilige en onveilige IDs tracking.

gigya dot com valt dan binnen de onveilige categorie: Gigya had dus gemakkelijk SSL kunnen implementeren, maar doet dat niet. Waard om te blokkeren.
en slecht van RTL XL management communicatie en marketing om met een tracker zonder 'best practices' in zee te willen gaan. Maar van dat soort zaken hebben ze geen bal verstand en er zullen wel andere overwegingen de doorslag hebben gegeven. Jammer beveiliging blijft "a last resort issue". Maar ja met maar een aantal van 11% actieve gebruikers van adblokkers, zal het de niet-beveiligers worst zijn. Hobbel maar mee op de onveiligheid. Eigenlijk moet zoiets afgestraft worden.

luntrus

Hoi Rinjani,

RTLXL heeft zo te zien gekozen om met Gygia samen te werken, en Gygia zorgt ondermeer voor identificatie e.d.
Dat inloggen zonder Gygia niet werkt, is met dit gegeven dus eigenlijk ook wel logisch.
(misschien wat vergelijkbaar met de case van MoneYou, die zijn cookiescript van een andere website haalt. Zou best eens kunnen dat je daar niet kunt inloggen zonder antwoord op een cookiescript. (inschatting, niet 100% zeker)

Verder heb ik niet "natuurlijk de third-party cookies aangevinkt", maar "cookies van originating website only" (firefox).
Zonodig kan ik dan third party cookies nog whitelisten. ;-)