As protection against data collection, the BSI recommends blocking the connections to the Windows telemetry servers at the DNS level and blocking the resolution of the DNS names into IP addresses. This blockade must take place outside of Windows, as Windows Defender blocks the usual use of the file "% windir% \ system32 \ drivers \ etc \ hosts" to block the tracking server at DNS level for this purpose.

source: https://www.privacy-handbuch.de/handbuch_90a2.htm
&&
translated in engels: https://translate.google.com/translate?hl=en&sl=de&tl=en&u=https%3A%2F%2Fwww.privacy-handbuch.de%2Fhandbuch_90a2.htm&sandbox=1

Ik zou zeggen begin hier met lezen en ga vanuit daar verder: https://www.seniorweb.nl/computerwoordenboek/t/tcp-en-ip

Dat is mogelijk, maar vanuit beheer gezien niet de juiste oplossing. Maak gebruik van een firewall of ander stuk software om domeinen te blokkeren.

Er wordt niet altijd een hostname meeverzonden. Is het dan gebruikte IP-adres niet geblokt zul je toch verbinding maken.

Er komt steeds meer software die resultaten uit de hosts file negeert als die niet geldig lijken te zijn (of gewoon altijd negeert).
Zal dus steeds lastiger worden om het op die manier aan te pakken, zeker als je bijv probeert om Google Chrome om de tuin te leiden mbt Google services.
(dit geldt ook voor malversaties met certificaten)

Bedankt voor de antwoorden hierboven, maar de vraag blijft:

TS

Waarom niet gewoon opvoeren in je firewall?

Little Snitch (MacOS) houd dat soort dingen prima tegen.

Het adres 127.0.0.1 is een benaderbaar IP-adres, het adresseert werkelijk een machine op het internet, namelijk de machine waarop de code die het adres opvraagt zelf draait. De betekenis van 0.0.0.0 is hangt af van de context, het kan betekenissen hebben als "ongeldig", "onbekend", "niet van toepassing", maar ook "alle adressen" of "val terug op een default-adres". De interpretatie die eraan gegeven wordt is in de code die de opvraging doet geprogrammeerd.

Een proefje met een willekeurige website (nrc.nl) die Google tag manager gebruikt wijst uit dat als ik alle JavaScript blokkeer er helemaal niets van googletagmanager.com wordt opgevraagd, en als ik JavaScript van de site zelf toesta dan wordt er wel een poging gedaan iets van googletagmanager.com op te halen. Dat betekent dat het benaderen van googletagmanager.com vanuit de eigen JavaScript-code van de website wordt geïnitieerd.

In de JavaScript van die website zie ik niet dat ze vanuit JavaScript een DNS-lookup naar googletagmanager.com doen (maar ik heb maar oppervlakkig gezocht en kan makkelijk iets gemist hebben). Je kan niet uitsluiten dat er websites zijn die proberen het blokkeren van de hulpmiddelen die ze gebruiken weer te blokkeren. En dan is het denkbaar dat die bij 0.0.0.0 geprogrammeerd hebben dat ze terugvallen op een default-IP-adres of een DNS-lookup doen die de hosts-file overslaat (ik heb althans de indruk dat dat met bijvoorbeeld node.js mogelijk is).

Hoe dit werkt hangt dus af van welke code uiteindelijk de DNS-lookup doet en wat die doet als die 0.0.0.0 als antwoord terugkrijgt. Je kan, als je daar zin in hebt, er wat experimenten mee doen: krijg je verschillende uitkomsten voor verschillende websites? Krijg je verschillende uitkomsten met verschillende browsers? Als die verschillen optreden zijn het aanwijzingen dat het de code in de websites (JavaScript) respectievelijk de browsers is die bepalend is voor hoe 0.0.0.0 wordt afgehandeld.

Geachte vraagsteller,
Dit bewijst weers eens dat veel mensen niet goed lezen en ook dat ze zich niet erbij kunnen neerleggen dat ze iets niet weten en steeds maar weer proberen eromheen te lullen. Ikzelf heb meerdere keren geprobeerd een precies gestelde vraag beantwoord te krijgen en kreeg een hoeveelheid onzin.
Voor uw vraag: geef het op, deze mensen weten het niet!

Als Google Chrome je host file negeert en eigen services installeert en gebruikt om dns informatie te ontsluiten, dan leidt Google jou om de tuin.

Op die manier maakt Google het jou erg moeilijk om je systeem veilig te krijgen.

Zoals iemand eerder al eens naar hint is verdiep je in TCP/IP. Als wat je beschrijft inderdaad klopt dan is mijn vermoeden is dat 127.0.0.1 altijd wel geaccepteerd wordt als localhost en de applicatie dus braaf naar het lokale systeem verbinding maakt, wat verder geen reactie oplevert in het algemeen. Het IP adres 0.0.0.0 is een bijzondere, die ook op verschillende manieren gebruikt wordt. Sommige applicaties zullen het antwoord 0.0.0.0 mogelijk dus niet zien als een opdracht om geen verbinding of lokale verbinding te maken. Mogelijk vallen ze dan terug op een andere manier om het IP adres op te zoeken.

Je leest de vraag niet want die firewal is er en doet dat ook.

De vraag gaat over het verschil bij gebruik van 0.0.0.0 en 127.0.0.1.

Zelf gebruik ik voor het blokkeren een DNS server die beide kan terug geven en ik gebruik het loopback adres. Ik meende me te herinneren dat 0.0.0.0 een snellere response geeft maar minder betrouwbaar is. Zoals hier nu ook blijkt. Het lijkt erop dat hij bij het 0.0.0.0 antwoord alsnog op zoek gaat naar een alternatieve dns opvraag.

Ik denk dat het antwoord in het js script zit dat de Googletagmanager aanroept.

Het IP adres 0.0.0.0 heeft een aparte betekenis: https://en.wikipedia.org/wiki/0.0.0.0

Gezien die betekenis zou het kunnen zijn dat je OS het antwoord 0.0.0.0 (op basis van je hostfile) interpreteert als het mislukken om via die weg de naam te resolven en doorgaat naar de volgende methode (DNS). Als je 127.0.0.1 in je hostfile zet is wél een valide antwoord en zal het proces stoppen.

Het begint al bij DNS: Er wordt een DNS-request voor googletagmanager gedaan.
Dit zou niet moeten gebeuren. Geen enkele van de andere websites die d.m.v. het hosts-bestand zijn geblokkeerd doet dit.

Maar ik bedenk me opeens dat er misschien nog iets van googletagmanager in de cache heeft gestaan.
Ik lees net: https://wizardassistant.com/how-to-edit-hosts-file-and-clear-cache/:
Maar dan zou 127.0.0.1 voorrang hebben boven de cache, en de cache juist weer voorrang hebben boven 0.0.0.0 ???...
Ik moet even in de gelegenheid zijn om het uit te proberen, maar dan laat ik het hier nog wel weten

TS

Nou ja, iets dergelijks heb ik inderdaad ook al over zitten denken: wat doet je PC met 0.0.0.0? Waar belandt dat?
Zou het misschien ook kunnen dat het naar je router gaat? (de bestemming 0.0.0.0 is óók de router van je lokale netwerk)

Wat verder bijzonder is, is dat dns resolve van www.googletagmanager.com aangeeft dat er ook nog een alias (cname) is:
www-googletagmanager.I.google.com.
En als ik me niet vergis liet wireshark zien dat de DNS-request dus naar die alias ging.
Ook dat ga ik nog eens even verifiëren, en dan hoort u het nog.

TS

Waarschijnlijk omdat je OS - wat je niet genoemd hebt - de interpretatie 0.0.0.0 = weggooien niet gebruikt.

je formuleert je vraag overigens alsof *alleen* googletagmanager de 0.0.0.0 ontwijkt maar het wel 'werkt' voor andere hosts entries ? Is dat wat je bedoelt te zeggen ?

0.0.0.0 is geen geldig IP adres .
Misschien dat de "iemand ergens" die beweerde dat dit als effect geeft dat een verbinding niet opgezet wordt dat gewoon uit z'n duim zoog. Of dat het slechts zo werkte op het OS/versie van degene die het beweerde.

Een hosts file is een manier om, naast DNS , een koppeling tussen naam en IP te maken.

127.0.0.x is een geldig IP adres, met als vaste betekenis "deze lokale computer" .
Draai je zelf een webserver op de lokale computer, dan kun je daarmee verbinding via 127.0.0.x . (het hoeft niet 127.0.0.1 te zijn - zelfs 127.255.255.255 moet werken)

0.0.0.0 is geen geldig IP adres. Het heeft , in routing, de betekenis van 'default route' - maar als adres is het niet geldig.

Het zou kunnen dat al bij het opvragen van de naam uit de hosts file de conclusie getrokken wordt 'kanniet goed zijn', en dus geen antwoord gegeven wordt . Dan is de volgende stap een normale dns lookup, net alsof de naam helemaal niet in de hosts file stond.

Dat moet zijn: www-googletagmanager.l.google.com ( met de "l" van Leo).

Hmm...
0.0.0.0 werkt bij mij altijd, zowel in Linux als in Windows; echter niet wanneer ik DNS over HTTPS (DoH) gebruik in Firefox.
Dan wordt het hosts bestand omzeild.

Er zijn op het internet heel veel sites die hosts files aanbieden met als doel sites te blokkeren. Meestal doen ze dat via 0.0.0.0, dus ik neem aan dat dit bij alle os-en werkt.

b.v. https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts

Beeldscherm schoongemaakt? ;)

Dat is goed om te weten! Maar in mijn geval was hier geen sprake van.

Inmiddels heb ik zoals in post 14:07 gemeld het probleem nog eens geprobeerd te reproduceren.
En wat denk je? Niks aan de hand. Alles werkt nu gewoon met 0.0.0.0 zoals het hoort.
Pffff. Sorry dan maar. Beetje onbevredigend dit.
Mogelijk had het met die dns-cache te maken, of anders heb ik een bord voor de kop gehad en een aantal keren achter elkaar niet door gehad wat ik steeds fout deed. Kan eventueel ook iets heel onnozels zijn geweest. Geen idee.

Nou ja, so far so good dan maar. Mocht het toch weer terugkomen dan klim ik wel weer op het toetsenbord.
Allen dank voor het meedenken.

TS

Om je scherp te houden: het gaat hier niet om wat je PC doet met 0.0.0.0 maar om wat specifieke programmacode die op je PC draait ermee doet. Je PC is te algemeen, het is heel goed mogelijk dat het ene programma op je PC er iets anders mee doet dan het andere programma op je PC, en zelfs dat JavaScript die van de ene website komt er iets anders mee doet dan JavaScript die van een andere website komt. De vraag is dus niet hoe 0.0.0.0 in het algemeen wordt afgehandeld, want dat kan nogal verschillen, maar hoe het in een heel specifieke situatie door heel specifieke software wordt afgehandeld.

Nee nog niet. ;)

Maar toch blijft het 'www-googletagmanager.I.google.com' wanneer ik scroll.

Nee dat is onzin...
Je kunt de default route zien als een route naar 0.0.0.0/0 maar daarin is het de /0 die het een default route maakt, niet de 0.0.0.0.

Het probleem is dat alles met schreefloze fonts opgemaakt wordt, die geen verschil tonen tussen een "I" en een "l". Pas als je een font met schreven gebruikt, zie je het verschil.


en


Dat is de reden dat je voor belangrijke zaken (zoals codering) altijd een font moet gebruiken die alle verschillen duidelijk weergeeft. Ik gebruikte vroeger altijd het monaco font van Apple omdat die een 0 altijd weergaf met een streep erdoor. Totdat een of andere domme graficus besloot die streep er uit te halen. (Gelukkig is die fout onderkend en zit die streep er weer in (-: )

Dit board gebruikt het font Courier voor code weergave, wat ook de bug heeft van een nul zonder streep, wat verwisseling van 0 en O in de hand werkt. Menlo of Monaco zou een betere keuze zijn. Apple is tegenwoordig overgestapt op Menlo als default font bij weergave in de Terminal.

Hmm...
Dan ben ik zeker blond. ;)

Wanneer ik je bovenstaande post kopieer en plak in Libre Office, zie ik toch duidelijk verschil (Noto Sans font).
Screenshot:
https://dl.dropboxusercontent.com/s/9j9b1rdgqmqlak0/screenshot-I%26l.png

Dat is een fout in het font. De toevoeging "Sans" betekent dat het zonder schreven (serif) moet zijn. Dat klopt bij alle letters in Noto Sans, behalve bij de hoofdletter I, de ze toch schreven hebben gegeven. Beter tegen verwisseling, maar het klopt niet met de naam.

Al met al dus toch een typefout van TS (CNAME letterlijk uit zijn post overgenomen):

en met de werkelijke CNAME:

Pech. Verkeerd gegokt van mij.
Heb bij het formuleren van het topic wel even gedacht: Is dat nou een I of een l of een 1?
Maar als ik het me niet verkeerd herinner, dacht ik toen:
ach daar kom ik/ze/we vanzelf achter als het toch nog relevant mocht worden.
Had een beetje ha...haast ook na al dat eerste gezoek van mij naar de oorzaak.
In mijn ogen leek het aanvankelijk niet direct het belangrijkste onderdeel van het topic.
Maar wel netjes dat je het corrigeert, dus dank!

TS

Graag gedaan hoor!

Het viel mij direct op, omdat ik de browser zo heb ingesteld, dat altijd het Noto Sans font wordt weergegeven en geen externe fonts worden geladen.