Nieuwssites tonen porno bij oude artikelen door verlopen domein van Vidme

Het domein van videostreamingdienst Vidme is deze maand ogenschijnlijk verlopen en opgekocht door een pornosite. Daardoor lieten meerdere websites, waaronder nieuwsmedia, deze week de frontpage van een pornosite zien waar eigenlijk een Vidme-video-embed moest staan.

Vidme was vroeger een videostreamingdienst die net als bijvoorbeeld YouTube door websites geëmbed kon worden. Die embeds laten sinds deze week een snapshot van pornowebsite 5 Star HD Porn zien. Ook de url van Vid.me redirect naar de pornowebsite.

Volgens Motherboard lieten websites, zoals The Washington Post, New York Magazine en Huffington Post, deze week de afbeelding van de pornowebsite zien in plaats van de juiste Vidme-embed. Op de afbeelding van de pornowebsite zien gebruikers expliciete snapshots van pornovideo's die nu door andere gebruikers worden bekeken. Websites halen nu handmatig de Vidme-embeds weg.

Vidme werd in 2014 opgestart en drie jaar later stopte het bedrijf weer. Daardoor zal het voornamelijk om oude artikelen gaan waarbij de video-embeds zijn vervangen door een afbeelding van de pornowebsite. Volgens Whois is het domein voor vid.me op 7 juli geüpdatet.

Bron: Gizmodo

Door Hayte Hugo

Redacteur

23-07-2021 • 10:16

88 Linkedin

Submitter: fapkonijntje

Reacties (88)

88
87
48
4
0
28
Wijzig sortering
Wel handig van die websites dat ze nog een domein opgenomen hebben van een dienst die in 2017 al gestopt is. Dat wordt ook goed bijgehouden dan. Oude artikelen of niet, dit hoort ook bij websitebeheer.

Nu gaat het alsnog om reclame, zij het dan van porno, maar je had natuurlijk ook met malafide intenties het domein kunnen gebruiken voor malware, dan heeft het nog veel meer impact gezien het bereik met wat voor websites (The Washington Post, New York Magazine en Huffington Post) het om gaat...

[Reactie gewijzigd door dutchgio op 23 juli 2021 10:27]

Je hebt gelijk. Sowieso verbaast het me altijd dat er zoveel sites met gebroken links zijn. Zo lastig is dat toch ook weer niet te controleren. Bescherm je gebruikers een beetje!

In dit geval wordt er natuurlijk wel een specifieke content weergegeven. Da's wat flauw want dan krijg je niet gewoon een 404 en moet je al naar certificaten of inhoud gaan kijken.
Uh, zo lastig is het niet? T.net zit volgens het ID op inmiddels bijna 185.000 artikelen. Hoe wil je die (deels automatisch) gaan controleren?

Gebruikers beschermen lijkt me moeilijk. Een certificaat helpt niet als je aan embed doet, je kunt aan de andere kant gewoon elke URL opvangen en iets anders ervoor terugsturen.

Verder vind ik beschermen allemaal zo.. kunnen we dan nergens meer tegen of iets zelf doen? T.net heeft een rapporteer functie onder elk artikel, daar kun je prima aangeven dat er mogelijk iets ongewenst wordt getoond. Genoeg andere websites die dat hebben of ergens waar je naartoe kan mailen. Tevens bestaan er tools die je gebruikers kunnen beschermen zoals tegen p0rn of andere zaken.
Daarom moet je ze ook zelf hosten… zolang ook tweakers dat niet doet is een ad blocker een must.
Weet je hoe duur zelf hosten is?!

Dan kan tweakers alleen abbos van 15 eur per maand vragen en geen gratis toegang meer...
Op zich ben ik voor zoveel mogelijk zelf hosten. Dan heb je meer controle.

Maar het kan ook grote nadelen hebben. Zo gebruik ik liever jquery vanaf hun CDN bijvoorbeeld, voor caching. Want geen enkele bezoeker zal example.com/jquery.js in zijn cache hebben, maar verbazingwekkend veel bezoekers zullen de versie uit het CDN van jquery zelf in hun cache hebben wat leidt tot kortere laadtijden voor deze bezoekers. (niet dat ik jquery nog gebruik maar is wel een goed voorbeeld).

En soms heb ik letterlijk meer vertrouwen in de andere partij. Ik bedoel ja, ik denk dat Facebook beter een betrouwbaar user management systeem in de lucht kan houden dan ik zelf. En dus is Login with Facebook een prima optie voor mijn website. Want controle betekent ook verantwoordelijkheid. Als ik snel een of ander username password systeem bouw en dan fouten maak dan riskeer ik de gegevens van al die gebruikers. En een goed user management systeem bouwen kost veel tijd en geld.
Ik heb geen AdBlocker(ook al vinden sites dat wel), maar uMatrix. En meestal klik ik gewoon verder als de site daarmee niet laadt. Tijdelijke uitzonderingen voeg ik zelden toe. Jammer dan, dan ga ik wel verder zoeken is mijn devies. :)
Het hadden ook ogenschijnlijk onschuldige advertenties kunnen zijn die malware serveren. Ik vind dat er veel te makkelijk met advertenties en content van derden omgegaan wordt, dat is voor mij dan ook de voornaamste reden om een ad blocker te gebruiken.
In dit geval had je dit niet geholpen omdat het een embed was van een legitiem niet-advertentie domein. Wellicht had 't geholpen een paar uur nadat dit bekend werd door een update van de lijst met blacklisted-domains, maar zeker niet standaard.
In dit geval had je waarschijnlijk ook niks ongewenst op je PC gehad. Qua virussen en spyware.
Nu was het domein gekocht door een pornosite maar waarom zou een malwareverspreider hier niet op in kunnen springen?

Maak een lijst van embedded content aanbieders.
Hou in de gaten wanneer er een stopt.
Koop snel het domein.
Vervang dan de content voor je eigen malware.

En in plaats van 5 sterren porno toon je dan een onschuldige foutcode dat de content aanbieder niet meer actief is.
Daar zal men dan niet van opkijken, want ja, het is ook zo.
Als het iemand ooit lukt om het domein analytics.google.com over te nemen kun je pas echt lachen. Staat op honderden miljoenen websites. In Google we trust. Of verdiep je eens in de standaard code vanuit Facebook voor een Login with Facebook integratie. Wat als iemand dat domein ooit te pakken krijgt? Enzovoorts.
Ah check, ik dacht dat het hier om video advertenties ging.
Je kan een hash maken van de inhoud wanneer je de inhoud embed, en die met regelmaat automatisch controleren of deze nog hetzelfde is gebleven. Zelfs automatisch uitschakelen kan dan om vervolgens een signaal te geven aan de beheerder dat het gecontroleerd moet worden.
Maar dat is een relatief recente ontwikkeling; bijv. subresource integrity is een feature die 'pas' ~6 jaar in Chrome geimplementeerd is. Dat zijn features die niet zo snel opgepakt worden door bijv. nieuws websites of aangeboden door video hosting sites.
Er zijn echter meer browsers dan Chrome ;-)
De inhoud wil echter nogal eens varieren. Bij Youtube filmpjes heb je advertenties en comments. Disquss is comments en verandert continu. Google Maps toont nieuwe locaties. Etc etc. De meeste embeds zijn niet statisch. Juist dat ze dynamisch zijn maakt ze krachtig.
En één kleine CSS aanpassing later op de ge-embedde site .....
Dit lijkt mij iets dat je kunt voorkomen met een goede Content-Security-Policy. En dan één iemand aanstellen die regelmatig de domeinen in de policy controleert.
En dan één iemand aanstellen die regelmatig de domeinen in de policy controleert.
Vind ik iets te simpel.

Vervang 'regelmatig' maar door 'voortdurend' want als je vorige maand nog gecontroleerd hebt of alles er goed uit zag word je vandaag toch alsnog verrast door ineens porno op je website? Ik bedoel dezelfde URL op hetzelfde domein serveert gewoon ineens andere content.

Wat je zou kunnen doen is automated de URL opvragen en alle gegevens rondom het certificaat opvragen en verifieren en wellicht zels de inhoud analyseren. Maar ik werk nu bijna 20 jaar in web development en heb heel wat systemen gezien maar het is echt uiterst zeldzaam dat websites zo ver gaan. Vergeleken met de paar regels code die je nodig hebt om een embed in je HTML te plakken is zo'n verificatie systeem vele malen complexer en dus moeilijker/tijdrovender/duurder om te bouwen en beheren. Ik ben zoiets dus letterlijk nog nooit tegen gekomen, hoewel ik er van overtuigd ben dat de echt grote jongens zoals Youtube, Facebook, Twitter etc dit wel doen.Voor de meeste websites zijn de extra kosten (10 keer zoveel als de embed zelf is ws nog optimistisch) voor een systeem waar je alleen wat aan hebt als je content toch al kapot is onmogelijk te verantwoorden.
alle posts en artikelen zitten toch in een database,

dan run je een sql qeury voor alles wat begint met http en doe je een wget, voor elke item dat timed out haal je de link weg.

it aint rocket science
Ja maar het doet geen timeout... er zit een werkende porno site achter.

Nog steeds geen rocket science, maar... er zitten nog een paar gradaties van moeilijkheid tussen "kinderlijk eenvoudig" en "rocket science".
Aangezien de dienst sinds 2017 al offline is lijkt het mij dat er 4 jaar lang een timeout is geweest.
sinds wanneer doet een broken link geen time out meer, het gaat er over om broken links die niet meer werken uit de database te halen of aan te passen niet om weer werkende pron links aan te passen.

Wel even lezen waar je op reageert aub,
voor elke item dat timed out haal je de link weg.
En dan is er eens een outage ergens en gooi jij vrijwillig je eigen content weg. Vervolgens komt de dienst weer terug en mag jij al je artikelen gaan repareren, vragen van gebruikers ('why does the vid not play?') beantwoorden etc.

Dus je moet het long term monitoren en pas actie ondernemen als iets lang down blijft of handmatig laten controleren etc.

Terwijl, een link in de DB toevoegen is maar ergens een string in een tabel wegschrijven. De kosten baten analyse valt gewoon niet goed uit.
toch niet zo moeilijk, alleen dan gaan we in details wat ik juist niet wil doen in een simple post,

Elke error schrijf je naar DB en dan kijk je er een keer naar en bepaal je of je de deletes doorvoerd,

die lijst is eecht niet zo groot als je het maandelijks doet en je verwijerd alleen zelfe linkszoals heel vid.me
Ja, dat is wel lastig.
The average URL has a two-year half-life. Within two years after releasing your info product to the world, half of the links in it won't work anymore.
Bron

Ik heb laatst een ebook geschreven met daarin ~150 externe links en in het half jaar dat ik ermee bezig was waren de eerste links al dood. Het is ondoenlijk om links werkend te houden in zoiets kleins als een ebook, laat staan een website als Tweakers.
Links in een ebook zou je via een redirector URL kunnen doen, is de link dood/veranderd dan kan je de redirector URL aanpassen waardoor de link in het ebook weer werkt.
Ik gebruik de tool in de link ;)
Ja ik blader weleens door een oud forum en alle gratis picture hosting services zijn inmiddels over de kop.

Maar YouTube is voor de eeuwigheid daar heb ik wel respect voor 10 jaar oude filmpjes doen het nog.
Mmmm nee. Ga eens naar je history en scroll naar beneden. Hoe verder je naar beneden gaat, hoe vaker je "video deleted" of een variant daarvan tegenkomt. Ook Youtube videos zijn onderhevig aan politiek en censuur. Denk bijvoorbeeld aan het imploderen van Machinima, toch wel een aardige set populaire Youtube videos verdwenen van de een op de andere dag.
Zolang je content niet op je eigen computer hebt staan loop je altijd het risico dat je er niet meer bij zal kunnen.

Net zoals dat vroeger de bibliotheek op een moment een bepaald boek uit de collectie kan halen.
Dit is niet eens een hypothetisch probleem, sites van Sanoma en De Pers Groep (eigenaar van Tweakers) hebben al meermalen malware aan hun lezers geserveerd door middel van reclame-netwerken.
In het maandag verschenen rapport van het Nederlandse Nationaal Cyber Security Centrum gaat de organisatie in op de ontwikkeling van malware die wordt verspreid via advertentienetwerken. Deze malvertising blijft populair bij internetcriminelen.
nieuws: 'Advertentienetwerken blijven populair bij internetcriminelen'

Ook daarom ben je veiliger op het internet met een AdBlocker. Nieuwssites willen geen juridische verantwoordelijkheid dragen voor de potentiële malware die ze serveren (AV, 13.1), dus wees ook niet zo dom deze dan ook daadwerkelijk in te laden.

Toegift, Tweakers neemt tot tweemaal toe afstand van de verantwoordelijkheid voor malware op hun reclame netwerken. In 9.3 ontdoet tweakers zich nogmaals van elke verantwoordelijkheid. Grappig, want volgens Arnoud kan dat niet zomaar.

[Reactie gewijzigd door Eonfge op 23 juli 2021 11:08]

Ik begrijp je punt niet echt hierin. Je betoog heeft niets met dit onderwerp of artikel te maken. Dit zijn embedded filmpjes als content bij artikelen, zoals YouTube of Vimeo, geen ads. Je adblocker, of het wel of niet serveren van ads als bedrijf staat hier compleet los van, want dit heeft niets met advertenties te maken. Het is meer een soort CDN constructie hier. Je adblocker had dit niet gepakt namelijk en zo wel blokkeert ie zaken die geen ads zijn en is je adblocker bagger.

Iemand heeft een bestaand domein overgenomen waar vroeger filmpjes op stonden die als contend diende voor artikelen. Niet een advertentienetwerk. Dat die urls nu allemaal verwijzen naar reclame voor een pornosite is heel wat anders.

Dat er malafide reclames zijn en dat dat een puinzooi is overal, is een feit. Maar dat heeft echt helemaal niets met de inhoud van dit artikel te maken.
@dutchgio heeft het over de beveilingsrisico's die dit mogelijk kan introduceren.

Het veranderen van domeinen betekend dat elke partij die ooit zaken heeft gedaan met zo'n domein, nu opeens blootgesteld wordt aan risico's. Het embedden, reclame of anders, is een beveilingsrisico en dat is dan ook de strekking van mijn post. Had het er misschien iets helderder in moeten zetten, maar ik zie daar wel een relatie in.
Hier op GoT forum ook al een aantal tegengekomen.
Via report toch maar aangemeld ivm de nsfw, ook al kan de gebruiker er niks aan doen dat zijn oude post nu maar zoiets verwijst.
Oude artikelen of niet, dit hoort ook bij websitebeheer.
Dit is sarcastisch bedoeld mag ik hopen? Dat is me nog eens een duur geintje. Slecht management als een manager aan zoiets prioriteit geeft.
Is het geen idee om automatisch alle embed functies in een artikel na +1 jaar uit te schakelen en om te vormen naar platte links met een waarschuwing dat de links niet meer gecontroleerd zijn.
Succes met de (imago)schade als via jouw website naar illegale praktijken gelinkt wordt. Porno, malware, phishing, etc.
Ik ben zelf freelance journalist, maar ik kan je verzekeren dat ik echt geen (ruim) 55.000 artikelen doorloop van mijn grootste opdrachtgever op kapotte links e.d. Sterker nog, al zou ik die vinden, dan kan ik die bij artikelen ouder dan 2016 niet eens meer wijzigen wegens een servermigratie die geen front-end meer heeft. Ik zou dus direct in SQL moeten duiken, waartoe ik als freelancer geen toegang heb. Ik denk ook dat met name nieuwssites gevoelig zijn voor dit soort problemen, want deze sites houden in het kader van historisch besef en perspectief hun volledige archief vaak online. Daar staat tegenover dat vrijwel niemand die oude artikelen meer bezoekt. Een enorm probleem is het dus óók weer niet. Het zou fijn zijn als CMS'en voor uitgeverijbedrijven automatisch kapotte links en embeds zouden scannen, hoewel dan (het restant van) 55.000 artikelen nog niet te doen is om handmatig na te lopen. Nog even buiten beschouwing gelaten dat daar dit specifieke probleem niet eens mee opgespoord zou zijn.
Nu gaat het alsnog om reclame, zij het dan van porno, maar je had natuurlijk ook met malafide intenties het domein kunnen gebruiken voor malware...
Als bedrijf X op z'n website code van bedrijf Y toelaat, is 't mede de schuld van bedrijf X zelf als bezoekers van bedrijf X getroffen worden door de malware. Dat je iets statisch (een jpg) van een 3rd party laadt; ok... daar kan geen malware in zitten.
Aan de andere kant helpt het in stand laten van oude links om informatie terug te vinden. Ik heb regelmatig via de naam van bestanden in oude links via de Wayback Machine of Google de bron terug kunnen lezen.
Of soms bestaat het doel nog, maar heeft het artikel een nieuwe naam gekregen omdat ze op een andere CMS over zijn.
Als ik zo naar het nieuws van de afgelopen jaren kijk denk ik dat je met het opkopen van de juiste domeinnamen echt flink wat schade kan aanrichten... Een kleine selectie:
nieuws: RTL: bsn's van miljoenen Nederlanders online te zien door verlopen do...
nieuws: Jeugdzorg liet medische dossiers uitlekken via verlopen domeinnaam
nieuws: Politierapporten liggen op straat door verlopen domeinnamen

En dan los nog even het feit hoe deze domeinnamen zijn beschermd. Ik vraag mij ten zeerste af of de meeste bedrijven 2FA hebben bij hun domain registar. Dit is een heel groot probleem waar meer aandacht voor zou moeten zijn.
Ik denk aan een paar mogelijke oplossingen:

- Permanente pagina's - "echt" permanent, gehost door het internet (distributed?), URLS die nooit gewijzigd kunnen worden, hashes om de integriteit te garanderen, en domeinnamen die nooit kunnen verlopen.
- Video's zelf hosten en dat proces makkelijker maken. Beter om zelf een video te hosten dan een embed van een 3e partij. Ja je moet dan je eigen video hosting, conversion, etc infrastructuur opzetten maar daar zijn genoeg pakketten en -diensten voor (bijv. https://aws.amazon.com/elastictranscoder/).
Klinkt goed, maar even vanuit een mediabedrijf met vaak zeer beperkte middelen geredeneerd; waar ga je zelf video's hosten? Dat is voor bijvoorbeeld lokale omroepen echt onhaalbaar.

Toevoeging: ik denk dat dit soort problemen fundamentele denkfouten zijn uit het begin van het internet. Net zoals dat maar weinig mensen voor online kopij (inclusief ikzelf overigens) betalen. Daar lopen we nu tegenaan.

[Reactie gewijzigd door Kastermaster op 23 juli 2021 12:33]

Dat is nog eens een slimme actie van 5 star om meer bezoekers te krijgen :+

Domein naam opkopen die net verlopen is maar op veel websites embedded staat.
Ik vraag me af hoe bewust dit is, want vid.me is ook gewoon een fijne URL voor een videodienst :).
Aangezien ze zorgen dat op de oude URL's actief nieuwe content getoond wordt denk ik vrij bewust, daarnaast waarschijnlijk ook gewoon voor andere doeleinden omdat het inderdaad een mooie URL is.
Valt wel mee. Een website wilt gewoon geen 404 serveren, want dat staat erg knullig. In Apache staan daarom meestal .htaccess files met redirects erin. ErrorDocument 404 /index.html bijvoorbeeld Bestaat een pagina dan niet en zou de client een 404 krijgen dan ondervangt Apache dat en krijg je netjes de index pagina te zien (of een speciale 404 pagina die je gebruiksvriendelijk heb gemaakt met links naar je site).
Hetzelfde geldt voor vhosts. De eerste host in Apache is ook altijd de default host. De tweede de www. vhost en eigenlijk is dit vrij standaard - ook bij andere serveroplossingen. Tweakers doet dit bv. ook. Probeer maar eens naar wwwwwww.tweakers.net te gaan of woy.tweakers.net.
Maar aangezien het om embedded video's gaan zou dat niet werken als de redirect gewoon naar de main page is ( wat gebruikelijk is ). Ik heb het niet helemaal gecontroleerd, maar de tekst doet mij vermoeden dat ze gewoon een andere video serveren, dan is het niet waarschijnlijk met een standaard 404 redirect om dit per ongeluk te doen.
Ook embedded video's (en zeker op een pornosite) kunnen bij een 404 redirect worden naar een reclamevideo. In een wereld waar pornosites massaal geindexeerd worden door derde sites die deze indexeren en met takedown verzoeken ed. is dit altijd beter voor je naam dan een error. Is de video er niet meer dan krijg je de promovideo van de site. Normale gang van zaken en zeker geen argument om te stellen dat ze dit bewust hebben gedaan zoals jij suggereert.
Natuurlijk kan dat, maar dat zal niet zo snel per ongeluk gebeuren, want er zal dan al rekening gehouden moeten zijn met de het oude URL schema. Een globale 404 redirect die "per ongeluk" deze video's af zal vangen zal logischerwijs altijd naar een homepage o.i.d. verwijzen. Het feit dat er video's getoond worden maakt mij ieder geval vrij zeker dat dit een bewuste actie is om andere content te serveren voor reclame.

[Reactie gewijzigd door Woy op 23 juli 2021 12:49]

Hoezo zal dat niet zo snel gebeuren dan? Een site die video's serveert als primair doel zal een niet bestaande link naar een video redirecten. Een site die plaatjes serveert als primair doel doet dit met plaatjes. Dit wordt overigens zelfs gedaan als een site niet wilt dat je deeplinked naar hun content.

Het oude URL-schema heeft hier niks mee van doen en er wordt niets gediscrimineerd. Bestaat .mp4 niet? Redirect dan naar /promo.mp4, bestaat .jpg niet redirect dan naar /promo.jpg en bestaat .html niet, redirect dan naar /index.html en zo kan je dat voor iedere content apart regelen.

Wil je dat er niet gedeeplinked wordt dan is dat ook vrij eenvoudig. Is de referer niet mijnsite.nl en er wordt een .jpg opgevraagd redirect dan naar /foei/betaaljeeigenhosting.jpg en natuurlijk idem met alle andere content.

Een globale 404 zal idd. meestal naar een index.html verwijzen. Echter nogmaals als je voornamelijk video's of plaatjes serveert dan ben je gewoon een erg slechte webadmin als je deze content onder een globale 404 laat redirecten. Immers je browser verwacht bv jpg content maar krijgt dan opeens html en zal vermoedelijk dit niet eens kunnen parsen. Je hebt dan een bezoeker (en bezoekers zijn geld) op je server die niet eens weet dat die door ontbrekende content op je server zit. Beter is hem dan iets anders te serveren zodat jij er ook bekendheid of clickthroughs op krijg.
In dit geval ieder geval niet, ik heb de site in kwestie even gechecked, en zelfs op hun eigen site bij het opvragen van een niet bestaande video url geven ze een 400 bad request terug. Ik kan zo snel even niet een oude vid.me embed url vinden om het verschil te bekijken, maar het is 100% duidelijk dat dit erg bewust gedaan is.
Nou ik ben ben je meegegaan en heb het even verder bekeken. De embeds van Vidme geschiedden in 99% van de gevallen middels een iframe. (zeg maar een frame waarin een externe pagina wordt geladen). Dus het is nog niet eens zo dat de embeds direct naar de video verwijzen zoals ik eerder dacht, maar gewoon een iframe inladen. Je krijgt dan een html code die er ongeveer zo uitziet:

<iframe src="https://vid.me/e/Q8TA?stats=1" width="640" height="360" frameborder="0" allowfullscreen webkitallowfullscreen mozallowfullscreen scrolling="no"></iframe>

Gezien de link in de code zou dit normaliter een parser moeten zijn (zoals je die ook wel kent van Youtube watch?v=uniekvideonummer), maar deze staat niet meer online en vid.me redirect gewoon alle requests naar een ander domein: 5 Star HD Porn. Zonder deze parser weet die laatste site niet wat ie met je request moet doen en geeft dan een global 404 redirect naar zijn index.html. (als die uberhaubt al de urlstring meekrijgt en niet gewoon zonder referer redirect)

Wat zie je dan in het iframe verschijnen? Geen embedded video, maar gewoon de index pagina in de resolutie die in het iframe bepaald is. Aangezien die porno site zijn layout dynamisch heeft gemaakt lijkt het erop dat je naar iets embedded zit te kijken, maar dat is dus absoluut niet het geval. Je ziet natuurlijk ook nergens voorbeelden van hoe het op de 'getroffen' sites eruit zag. Kregen mensen een filmpje of gewoon een iframe met een porn site te zien? Zoals ik het zie gewoon een iframe met een porn site waarbij je door de beperkte dimensies van het iframe nauwelijks aan je trekken komt. (pun intended).

Hoe je dus met 100% zekerheid kan zeggen dat dit bewust is gedaan blijft me bevreemden. Het is gewoon een gevalletje domein kopen, (nog) niks mee kunnen, redirecten naar een andere site en verouderde iframes die iets anders inladen wat de bedoeling was. Er is in ieder geval geen enkel technisch bewijs dat de boel zo is opgezet om mensen porno voor te schotelen zonder dat ze dit wilden.

[Reactie gewijzigd door liberque op 23 juli 2021 15:32]

Dit doen ze natuurlijk 100% bewust. Slimme marketing.
Als het deftig is opgelost serveer je de pagina die je wilt. Dat kan een eigen ontworpen 404 zijn. Maar geeft de server wel netjes de 404 status door. Zo kun je ook je home pagina serveren - maar wel met de URL ongewijzigd, zodat de 404 hout snijd.
Als je het echt deftig oplost dan laat je je server geen 404 genereren, maar een 410. Indexsites en bijvoorbeeld Google weten dan dat de content is verwijderd en niet meer terugkomt. Daar kunnen ze dan (al dan niet automagisch) actie op ondernemen. Echter hoe vaak ben je de error 410 tegengekomen? :)
Dat is natuurlijk ook prima. Als de resource elders te vinden is kun je ook een 301 of 303 gebruiken. In de praktijk zie je meestal vooral de 200 en 404 voorbij komen.
goeie marketing,

nu gaat het om porno, maar dit had natuurlijk ook kunnen gebeuren met een phishing site, dan hadden er veel slachtoffers kunnen zijn denk ik.
Wie weet is dat er ook wel. Komt zo'n fragment bij een goed stukje, moet je eerst registreren en ja dan slaan ze toe. ;)
Kijk, en daarom staat mijn ad-blocker + anti-tracker permanent aan. Porno, okay, maar voor hetzelfde geld heeft een malafide partij de url opgekocht en serveert er stiekem spyware/malware mee. Zou dit probleem opgemerkt zijn als er géén porno op stond maar visual nog gewoon de oude content? Is er überhaupt achter te komen en weten we niet of dit zich al elders heeft voorgedaan?
Die staan bij mij ook aan, maar volgens mij blocken die standaard geen embedded video's. Ik kan in elk geval gewoon embedded-youtube video's kijken met de adblocker aan, bij mij zou ik deze content waarschijnlijk nog steeds gewoon zien.

Of heb jij 't anders ingesteld?
Ik neem wel aan dat zodra zo'n domein gekocht wordt en voor zaken als tracking/malware gebruikt wordt het vrij snel op de lijst staat van dingen die geblokkeerd moeten worden.
Wel een top domein naam trouwens voor een video streaming website. :)

Tja, wat kan je hier tegen doen? Genoeg oudere artikelen die linken naar iets dat niet meer bestaat of een domein dat te koop staat. Hier op T.net zullen genoeg artikelen zijn die links hebben die niet (meer) werken. Het enige dat echt kan, is actief gaan scrapen en met een allow-list werken, maar dan kunnen alsnog sommige sites (tijdelijk) onbereikbaar of aangepast zijn.
Heel simpel.. zelf de ads hosten… dat is geen kinderspel voor een miljoenen bedrijf zoals de pers groep.
Dit probleem is natuurlijk al zo oud als het internet zelf. Http is gebouwd rondom hyperlinks (en afgeleiden, zoals hotlinks). Elke site owner is zelf verantwoordelijk voor zijn content.

Als je dat wil voorkomen, moet je niet linken naar een webpagina, maar bijvoorbeeld naar ipfs, waar de link gelijk de hash is van de content.
Dubbele whammy want de echte exposure komt natuurlijk door artikelen zoals dit. Heel slim van de betreffende pornosite. Ik hoop niet dat ik zelf tegen zoiets aanloop. Als ik er aan denk dat ik bij het bezoek van een pornosite opeens nieuws artikelen zie moet ik huiveren. O-)
Prachtig dit. Ik stel mij al voor dat je in een Team meeting je scherm deelt en daar staat dan ineens porno op het scherm. Lul je daar maar eens uit... :+
Kan je op werk zeggen dat je gewoon naar het nieuws kijkt :P
Submitter: fapkonijntje
Username checks out :p

Op dit item kan niet meer gereageerd worden.

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee