Cookie muur mag wel uit voor oa wallabag.it

[hans3702]

Met komst van de koekjes muur is de deze sites een stuk minder aangenaam geworden.

Een interessant bericht is niet meer bruikbaar/ herkenkbaar op te slaan op bv https://www.wallabag.it/en
Door een pagina in de browser met een bookmarklet ( https://app.wallabag.it/howto) aan je wallabag toe te voegen loopt je te pletter op een cookie wall

Ook onenote op mijn smartphone kan geen tweakers pagina's opslaan dit geeft een KAN NIET DOWNLOADEN controleer de internet verbinding.

https://play.google.com/s...soft.office.onenote&hl=nl

Ik zou het heel fijn vinden als deze bijwerkingen van de Cookies verholpen kunnen worden, deze zijn echt buitengewoon klant onvriendelijk en onwenselijk in mijn ogen.

[crisp]

Dat is geen bug, dus iets voor ons productteam ->Mooie Features

[hans3702]

Whats in a name, als iets eerst wel werkte en na een update / aanpassing niet meer, zou ik het zeker geen "Mooie Features" willen noemen, maar een DIKKE VETTE BUG
Maar als het onder Mooie Featurer eerder opgelost is vind ik het prima

[crisp]

hans3702 schreef op woensdag 24 oktober 2018 @ 20:53:
Whats in a name, als iets eerst wel werkte en na een update / aanpassing niet meer, zou ik het zeker geen "Mooie Features" willen noemen, maar een DIKKE VETTE BUG
Maar als het onder Mooie Featurer eerder opgelost is vind ik het prima

Het gedrag is 'as intended'. Bij de invoering van de AVG hebben we onze cookiemuur voor de hele EU 'aangezet' in plaats van alleen voor bezoekers vanuit Nederland en daarom heb je daar nu waarschijnlijk last van.

We kunnen bepaalde partijen op basis van bijvoorbeeld combinaties van useragent/bepaalde http headers/ip-adressen uitsluiten van de cookiemuur, maar of we dat voor deze partijen willen doen is een beslissing die door ons productteam genomen moet worden. Het is dus maar de vraag of we die moeite wel willen doen.

[Voor 3% gewijzigd door crisp op 25-10-2018 11:15]

[hans3702]

Het gedrag is mijn inziens zeker niet als intended!

Op de RSS feed heeft deze site ook geen Cookie muur zitten
en ik vermoed dat u de spider van bv google ook niet eerst een cookie vraag gaat stellen.

Om aan de avg regels te voldoen werpt tweakers een cookiemuur op en negeert, mijn inziens, de werking van spiders / craweler te handhaven en komt met een "As intend" opmerking welke ik Tweakers onwaardig vind in deze!

Ook een opmerking als "Het is dus maar de vraag of we die moeite wel willen doen." ervaar ik als klant ontvrienlijk of iedergeval niet klantgericht en mijn keuze om betaald abonnee te worden til ik maar even over de jaarwisseling heen.

Ik hoop echt dat andere reacties mogelijk zijn dan op het nivo van YouTube: 3FM Jingle - Ik zal kijken wat ik voor je kan doen

PS deze vraag / opmerking kan ook van toepassing zijn voor bv
https://evernote.com/
https://www.google.com/keep/
https://www.instapaper.com/

Google keep gaat goed maar die neemt ook alleen maar de url over in een deel / opsla actie

[WCA]

Misschien vragen aan je contentverzamelaar om hier iets op te vinden? Hoe is Tweakers in godsnaam verantwoordelijk voor het feit dat jouw 3rd party site er niet mee werkt?

[hans3702]

Een 3rd party als google krijgt wel toegang tot tweakers en een wallibag in frankrijk niet?
Voor mij is dat gelijk aan dat jij met je auto na een aanpassing ( handhaving AVG) nog wel bij Shell kan tanken maar niet meer bij de merkloze pomp om de hoek omdat je voor het gemak de aanpassing zo gemaakt hebt dat dit het gevolg is.
Terug naar deze website een cookiemuur hoort blijkbaar bij een levende bezoeker. Het is dus volgens mij niet netjes om wel voor google een uitzondering te maken en niet voor kleinere partijen.

Veder is het woord verantwoordelijk echt woord van deze tijd, verdeel alles maar naar verantwoordelijkheid en veeg je eigen straatje schoon ipv de hersenen te gebruiken en naar een concept werkwijze te kijken en te zien hoe het beter handiger enz kan.

en mbt: Misschien vragen aan je contentverzamelaar....
Stel je bent verplicht je huis van hang en sluit werk te voorzien voor de inbraak verzekering.
en je pakt dit dusdanig voortvarend aan dat je de verplichting voldoet maar daarbij ook het voor de hulpdiensten het onmogelijk maakt bij je binnen te komen bij een brand?
Moet dan ook de brandweer maar een tank kopen om naar binnen te rijden of zou je dan toch het hang en sluitwerk is beter op maat moeten maken ( lees voor spiders en crawers je site toegankelijk )
Ik wens je zeker niet de situatie toe dat je bij een brand niet gered kunt worden dus maak zinnige keuzes!

In deze is het dan zeker aan tweakers om ergens aan te geven hoe men als 3rd party site door de cookwal heen kan spideren als ze zelf geen actieve rol willen spelen in het vrijgeven van useragent/bepaalde http headers/ip-adressen.

Maar een link naar deze info mocht die bestaan is mij ook nog niet gegeven

Ik heb ook eerst ( hoewel niet vermeld) contact gezocht met wallibag maar dat ontneemt mij niet het recht om de vraag / opmerking / verzoek ook bij de veroorzaker neer te legen

[crisp]

hans3702 schreef op donderdag 25 oktober 2018 @ 13:21:
Een 3rd party als google krijgt wel toegang tot tweakers en een wallibag in frankrijk niet?
[...]

Ja, voor google hebben we herkenning ingebouwd, maar het is praktisch onmogelijk om dat voor alle mogelijke bots en spiders te doen (voor zover ze al exclusief herkenbaar zijn ten opzichte van gewone bezoekers).

Er zijn hier ook geen standaarden of iets dergelijks voor, en een mogelijke 'workaround' geven wij liever ook niet publiekelijk vrij omdat het dan vrij snel in allerlei extensies wordt opgenomen waarmee gebruikers voor zichzelf de cookiemuur kunnen omzeilen en wij mogelijk niet meer aan onze wettelijke verplichting voldoen (het informeren van gebruikers en expliciete toestemming verkrijgen voor het gebruik van o.a. cookies).

Ja, de cookiemuur is vervelend, maar voorlopig moeten we het ermee doen en kunnen gebruikers daar last van hebben...

[hans3702]

Fijn het kan dus, een antwoord waar ik het niet mee eens hoef te zijn maar wat wel aangeeft waar er speelt en wat de motivaties zijn.

Tnx Crisp

Voor het productteam, mogelijk zijn er aan de hand van de logboeken voor zover die met de AVG nog gebruikt mogen worden mogelijkheden om spiders te herkennen aan gedrag in de tijd van AI toch een prima opdracht voor een stagiaire :-)
En anders een vrijgave verzoek formulier of contact gegevens waar ik wallibag naar kan verwijzen opdat het voor iedereen op de bedoelde wijze werkt, de cookie muur. Ik denk wel dat het laatste bericht aangeeft dat de wettelijke verlichting boven alles gaat.

Als je echter voor google de deur open zet blijf ik wel vinden dat je ook voor MS de deur open moet zetten en dan bedoel ik voor Onenote. In deze is tweakers denk ik de kleine partij en is bij MS aankloppen voor mij geen zinnige actie.
Aangezien het programma onenote gratis is te gebruiken op windows 10 en op een smartphone zou dat voor het productteam niet heel moelijk moeten zijn om de juiste parameters uit een log te vissen en voor dit product de site weer toegankelijk te maken.

[ACM]

hans3702 schreef op donderdag 25 oktober 2018 @ 14:20:
Voor het productteam, mogelijk zijn er aan de hand van de logboeken voor zover die met de AVG nog gebruikt mogen worden mogelijkheden om spiders te herkennen aan gedrag in de tijd van AI toch een prima opdracht voor een stagiaire :-)

Dat is helaas onbegonnen werk. Er komen letterlijk honderden, zoniet duizenden, spiders elke dag langs. Veel daarvan komen van buiten Europa en krijgen de cookiewall daardoor sowieso niet. Maar veel van die spiders willen we eigenlijk helemaal niet toestaan (ze zijn lang niet allemaal in het belang van onszelf of van onze bezoekers of maken niet duidelijk wat ze uberhaupt doen), waarbij de cookiewall dus eigenlijk juist handig is

En anders een vrijgave verzoek formulier of contact gegevens waar ik wallibag naar kan verwijzen opdat het voor iedereen op de bedoelde wijze werkt, de cookie muur. Ik denk wel dat het laatste bericht aangeeft dat de wettelijke verlichting boven alles gaat.

We zijn best bereid meer uitzonderingen in te bouwen, maar dat moet natuurlijk wel voldoende meerwaarde geven ivt de benodigde inspanning en daadwerkelijk concreet herkenbaar zijn. Ik kende tot dit topic Wallabag niet eens. Ik kan me trouwens voorstellen dat Wallabag dezelfde gedachte aanhoudt en dat daardoor de kans dat ze bij 'elke' website zo'n formulier willen invullen klein is.

Wat helpt om onze inspanning te beperken is ze toe te laten, is deze dingen weten:
- Welke useragent gebruiken ze
Wallabag en onenote komen bijvoorbeeld niet voor in de afgelopen 30 dagen gebruikte useragents...
- Vanaf welke ip-ranges kunnen we ze verwachten

Als je echter voor google de deur open zet blijf ik wel vinden dat je ook voor MS de deur open moet zetten en dan bedoel ik voor Onenote. In deze is tweakers denk ik de kleine partij en is bij MS aankloppen voor mij geen zinnige actie.
Aangezien het programma onenote gratis is te gebruiken op windows 10 en op een smartphone zou dat voor het productteam niet heel moelijk moeten zijn om de juiste parameters uit een log te vissen en voor dit product de site weer toegankelijk te maken.

Google en Bing (en nog diverse anderen) zijn open gezet. Maar het is best veel werk om elke applicatie die mogelijk zoiets wil doen te installeren (en vaak moet je dan ook nog eerst e.o.a. account maken), uit te zoeken hoe de betreffende handeling werkt en daarna te doen wat jij allemaal beschrijft.

Dus laten we het vooral omkeren, want we hebben heel veel gebruikers die dergelijke tools vaak gebruiken. Zij (en nu dus jij) kunnen daar dus prima mee helpen
De snelste manier om de useragent duidelijk te maken is door een unieke url te gebruiken. Je kan een willekeurige url van Tweakers pakken en daar met ? iets achter plakken. Dus https://tweakers.net/?ditIsEenTestVoorDeTweakersCrawler.

Het is dan wel handig als je die url vervolgens niet zodanig deelt dat tientallen mensen 'm gebruiken

Overigens moet het dan alsnog voldoende herkenbaar blijken en natuurlijk ook wel een beetje een veelgebruikte partij zijn. We willen niet honderden uitzonderingen voor allerlei obscure partijen die 1 request per week doen

[Kees]

Ik heb even de requests van Wallabag getest. Die doen een aantal zaken fout:
- Zeggen dat ze een echte browser zijn (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.92 Safari/535.2)
- Zeggen dat ze een heeeeel erg oude browser zijn (Chrome/15...)
- Geven een fake referer mee (http://www.google.co.uk/url?sa=t&source=web&cd=1)

Ik wil prima een whitelist entry voor ze maken, maar dan moeten ze gewoon een fatsoenlijke useragent gebruiken (en het liefst ook niet de referer faken)

[F_J_K]

FWIW: zowel 'Send to Onenote' op de iPhone als in IE op de PC werken hier prima.

[hans3702]

Dank voor de constructive reacties die ook mogelijk zijn.

F_J_K: Onenote dacht ik als alternatief voor Wallabag te gaan gebruiken. en heb het toen alleen op mijn Android telefoon getest. zal eens gaan uitzoeken met mijn eigen website en de logs hoe het onnote werkt.

Kees: zal proberen die persoon in Frankrijk hiervan te overtuigen.

Dat Wallabag zich als een echter browser voordoet zou ook kunnen omdat andere site hem anders weer weigeren en dan gaan we in een rondje lopen. Een internet volgens de RFC is helaas een utopie. Maar mogelijk is er hoop. laten we daar van uit gaan

ACM: Zal je met een PM de ?...... doorgeven

[Voor 6% gewijzigd door hans3702 op 26-10-2018 10:20. Reden: aanvullig als duidelijker]

[hans3702]

F_J_K schreef op vrijdag 26 oktober 2018 @ 09:28:
FWIW: zowel 'Send to Onenote' op de iPhone als in IE op de PC werken hier prima.

OneNote op android

ik heb dit even met een herkenbare url op een site waar ik bij de log kan getest

Ik zie dan één regel in de log met het public ip adres van mijn telefoon maar daarna neemt 52.166.195.221 het over en dit is een MicoroSoft IP wat in NL zit dus loopt het tegen de cookie muur op.

https://whatismyipaddress.com/ip/52.166.195.221

Of dit het enige ip adres is of range is die dan een free pass voor de cookie wall nodig heeft heb ik (nog) geen kijk op.

Onenote voor Android doet dus het crawelen en renderen van een website op een azure server en niet op de de CPU en brouwser van het device (android 7.x samsung flagship)

De complete log is ook via een PM naar Tweakers verzonden.

Mogelijk of blijkbaar is dit op de PC en Iphone anders.

Op de PC met Windows 10 en MS Edge is er in de browser een deel optie naar Onenote en dan geeft in de log van de website slechts een melding van de brouwser die de pagina openend, edge geeft dan de content door aan Onenote, dit is dus anders dan op Android. ook ziet de vermelding er anders uit, nl een 4kante versie van de hoofdafbeelding en 1 aliena tekst met een link om de rest online te lezen
op de telefoon krijg ik een "jpg van de site te zien ( tumbnail) en een link of als ik wil de tekst. De foto wordt dus zeker door een MS Azure server gemaakt.

[Voor 30% gewijzigd door hans3702 op 26-10-2018 18:01. Reden: Aanvulling mbt ONENOTE op de PC]

[ACM]

Dat ip van Onenote gaat helaas weer niet gepaard met een useragent en dan zouden we heel (die NL) Azure moeten whitelisten, hoewel ze blijkbaar phantomjs gebruiken om de aanvullende data op te vragen...

[hans3702]

ACM schreef op vrijdag 26 oktober 2018 @ 21:47:
Dat ip van Onenote gaat helaas weer niet gepaard met een useragent

De useragent wordt ook gebruikt door website om verschillende content aan te leveren dus uit het standpunt van Onenote die gelijke content wil zien als de gebruiker lijkt mij dit verdedigbaar.

Hoe je dit om in lijn met de wetgeving moet oplossen heb ik ook geen kant en klaar antwoord op. Ik zie wel dat de Tweakers cookie muur een van de strengste is, ik kom het bij andere site niet zo tegen dat het met onenote of wallabag niet het niet werkt of je alleen maar de cookie melding krijgt.

Een Cookie muur die alle Android onenote gebruikers in de EU buiten spel zet lijkt mij ook niet de juiste weg.

Zoals jullie zelf al aangeven is er er ondank vele RFC niet overal een standaard voor of houden mensen zich om noodzakelijke redenen niet aan.

[hans3702]

ACM schreef op vrijdag 26 oktober 2018 @ 21:47:
.... ze blijkbaar phantomjs gebruiken om de aanvullende data op te vragen...

Ik moest even opzoeken wat phantomjs is ( Wikipedia: PhantomJS )
Ik mis je punt dan een beetje mbt een useragent als PhantomJS is a scripted, headless browser used for automating web page interaction. Als dit herkenbaar voor je is vanuit de headers dan lijkt het mij duidelijk dat een ondoordringbare cookie muur hiervoor niet noodzakelijk is, en ik hoop dat de wet dat ook niet verplicht.

[ACM]

hans3702 schreef op zaterdag 27 oktober 2018 @ 18:04:
[...]


Ik moest even opzoeken wat phantomjs is ( Wikipedia: PhantomJS )
Ik mis je punt dan een beetje mbt een useragent als PhantomJS is a scripted, headless browser used for automating web page interaction. Als dit herkenbaar voor je is vanuit de headers dan lijkt het mij duidelijk dat een ondoordringbare cookie muur hiervoor niet noodzakelijk is, en ik hoop dat de wet dat ook niet verplicht.

Dan heb je niet goed naar de logs gekeken

De eerste request die ze doen is met een useragent-loze browser. Dus een die we niet betrouwbaar kunnen onderscheiden van 'de rest'. Daarna halen ze de resources (js, css, etc) op met phantomjs.
Maar die eerste request krijgt uiteraard de cookiewall, niet die resources.

Als het allemaal phantomjs was, dan was het inderdaad makkelijk geweest.

[MsG]

Even zijdelings op inhakend, is dit ook de reden waarom Whatsapp nooit een mooie preview geeft van een Tweakers link, zoals wel bij het merendeel van andere sites gebeurt? Of is dat een ander fenomeen waarom dat niet werkt.

[hans3702]

ACM schreef op zondag 28 oktober 2018 @ 08:44:
[...]
De eerste request die ze doen is met een useragent-loze browser. Dus een die we niet betrouwbaar kunnen onderscheiden van 'de rest'. Daarna halen ze de resources (js, css, etc) op met phantomjs.
Maar die eerste request krijgt uiteraard de cookiewall, niet die resources.

Dan heb je mijn PM niet geheel gelezen

x.y.x.81 is het ip van de 4G verbinding van mijn telefoon

daarna neemt 52.166.195.221 het over en dit is een MS IP wat in NL zit dus loopt het tegen de cookie muur op.

in de log met 52.166.195.221 zie ik overal phantomjs staan

Maar het kan natuurlijk dat die eerste log regel al niet door de muur heen komt, via onenote en wel via de brouwser dit is een log naar mijn website die geen cookie muur heeft op niveau van Tweakers

[ACM]

hans3702 schreef op zondag 28 oktober 2018 @ 09:00:
[...]


Dan heb je mijn PM niet geheel gelezen

x.y.x.81 is het ip van de 4G verbinding van mijn telefoon

daarna neemt 52.166.195.221 het over en dit is een MS IP wat in NL zit dus loopt het tegen de cookie muur op.

in de log met 52.166.195.221 zie ik overal phantomjs staan

Maar het kan natuurlijk dat die eerste log regel al niet door de muur heen komt, via onenote en wel via de brouwser dit is een log naar mijn website die geen cookie muur heeft op niveau van Tweakers

Het is een beetje vreemde logoutput, maar je allerlaatste regel is de 'echte' request naar die test-pagina, de rest is het opvragen van allerlei resources. En bij die ene request heeft ie geen useragent. Waarom het deze volgorde krijgt bij jou weet ik niet, maar ik vermoed dat ze ofwel een 'blob html' doorsturen (dus van jouw client naar onenote) of eerst met e.o.a. robot de 'blob html' ophalen (maar dan dus zonder useragent) en daarna die pagina proberen te renderen (wellicht om er meer info uit te halen of om er een screenshot van te maken) met phantomjs.

[hans3702]

MsG schreef op zondag 28 oktober 2018 @ 08:58:
Even zijdelings op inhakend, is dit ook de reden waarom Whatsapp nooit een mooie preview geeft van een Tweakers link, zoals wel bij het merendeel van andere sites gebeurt? Of is dat een ander fenomeen waarom dat niet werkt.

Met een snelle blik in de code van de pagina lijkt het er op dat Tweakers alleen een favicon.ico heeft een de favicons in andere formaten en voor andere platformen niet aanbied

<link rel="shortcut icon" href="https://tweakers.net/favicon.ico" type="image/x-icon">

=wat dan "ontbreekt" en waar Whatsapp de afbeelding vandaan kan halen
<link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/apple-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/apple-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="/apple-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="/apple-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-icon-180x180.png">
<link rel="icon" type="image/png" sizes="192x192" href="/android-icon-192x192.png">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="96x96" href="/favicon-96x96.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="manifest" href="/manifest.json">
<meta name="msapplication-TileColor" content="#ffffff">
<meta name="msapplication-TileImage" content="/ms-icon-144x144.png">

https://realfavicongenerator.net/

Maar omdat Whatsapp van FB is kan het ook de opengraph zijn die ze gebruiken
<meta property="og:title" content="The Rock" />
<meta property="og:type" content="video.movie" />
<meta property="og:url" content="http://www.imdb.com/title/tt0117500/" />
<meta property="og:image" content="http://ia.media-imdb.com/images/rock.jpg" />

http://ogp.me/

en die zie ik zo snel ook niet terug in de code


Als mijn gedachtes de juiste zijn en het niet met de Cookiewall van doen heeft dan mogelijk hier een nieuwe draadje van te maken. Is het wel een cookiewall item dan is het ook op zijn plek denk ik.

[Voor 7% gewijzigd door hans3702 op 28-10-2018 15:52. Reden: idee om hier een nieuw onderwerp van te maken? / foto ter verduidelijking / opmaak]

[hans3702]

ACM schreef op zondag 28 oktober 2018 @ 09:05:
[...]

Het is een beetje vreemde logoutput, maar je allerlaatste regel is de 'echte' request naar die test-pagina, de rest is het opvragen van allerlei resources. En bij die ene request heeft ie geen useragent.

Nu ik "weet" waar ik naar moet kijken zie ik het.

52.166.195.221 - - [26/Oct/2018:14:53:15 +0200] "GET /contact?TextOmHetInDeLogTeHerkennen HTTP/1.1" 200 30377 "-" "-"

TNX

==================
Blijf een beetje staan ik ben "klant" van tweakers en heb last van de bijwerking van de cookie muur
voor Onenote is het op een android device anders dan op een PC ( getest en werkt goed) en een Iphone ( zelf niet getest) en ik zie geen mogelijkheden om dit zelf te fixen

Voor Wallabag is het "lastig" om met Frankrijk in contact te komen/ dan wel reactie te krijgen. Wat ik kan doen is het script zelf te gaan hosten en dan of de useragent aan te passen dan wel (gescript) het betreffende cookie te activeren die de cookie muur uit zet.

Overdenking: van alle pagina's die ik wil wallabaggen of in onenote wil verzamelen zijn tot nu toe alleen die van de persgroep een probleem. tvg de cookiewall. Nu heeft iedereen zijn info bubble dus ik kan niet voor alle website aangeven of ze wel of een "overactive" cookiewall hebben

Wat zijn de mogelijkheden om dit te Fixen?

[Voor 1% gewijzigd door hans3702 op 28-10-2018 15:50. Reden: opmaak en anoniem maken log]

[ACM]

hans3702 schreef op zondag 28 oktober 2018 @ 09:32:
Wat zijn de mogelijkheden om dit te Fixen?

Je kan bij wallabag toch ook credentials ingeven voor sites die dergelijke restricties opgeven? Of werkt dat bij ons ook niet?

[hans3702]

ACM schreef op zondag 28 oktober 2018 @ 09:41:
[...]

Je kan bij wallabag toch ook credentials ingeven voor sites die dergelijke restricties opgeven? Of werkt dat bij ons ook niet?

Wat ik gelezen heb in de hosted versie voor een beperkt aantal Franse kranten. en gaat het over paywall, dus dat je info uit de krant waar je een abo voor nodig hebt kunt wallabaggen
als je zelf host kun je deze scripts zelf aanpassen. Om te proberen wel ingevuld maar werkt niet in de cloudversie.
Merk nu dat als je inlogt je de cookiewall niet met een OK hoeft toe te staan, maar mogelijk doet dat de login button al voor je.

https://www.wallabag.it/en/doc

List of supported websites
Les Jours
Mediapart
Le Monde Diplomatique
Next INpact
Courrier International
Soon:
Alternatives Économiques
Telegraph.co.uk
Le Figaro
Le Monde
L'Équipe

[Voor 7% gewijzigd door hans3702 op 28-10-2018 15:51. Reden: opmaak]

[ACM]

hans3702 schreef op zondag 28 oktober 2018 @ 09:49:
Merk nu dat als je inlogt je de cookiewall niet met een OK hoeft toe te staan, maar mogelijk doet dat de login button al voor je.

Niet echt, we bewaren de toestemming op account-niveau. Dus je kan er altijd voorbij door in te loggen als je al een keer toesteming had gegeven.

[eric.1]

Als je op GitHub door de issues en feautures loopt zie je dat dit een bekend probleem is. Zie bijv. https://github.com/wallabag/wallabag/issues/3656 . Echt niet alleen de persgroep hoor .

Er zijn al issues uit 2016 met een cookie-wall probleem.

De echte oplossing moet vanuit wallabag komen lijkt me....anders zit je zo voor meerdere sites te morren.

[hans3702]

eric.1 schreef op zondag 28 oktober 2018 @ 09:55:
Als je op GitHub door de issues en feautures loopt zie je dat dit een bekend probleem is. Zie bijv. https://github.com/wallabag/wallabag/issues/3656 . Echt niet alleen de persgroep hoor .

Er zijn al issues uit 2016 met een cookie-wall probleem.

De echte oplossing moet vanuit wallabag komen lijkt me....anders zit je zo voor meerdere sites te morren.

Punt echter iets met berg enz ( https://www.dbnl.org/teks...stoe002nede01_01_0208.php)
Als het rechtdoor niet lukt ( wallabag en onenote) probeer ik het linksom ( tweakers) en als dat niet wil evt rechts om door de dienst zelf te hosten.
Maar realiseer je wel dat de de oorzaak de Cookie wall is en dat deze op meerdere manieren gemaakt kan worden en dat het merendeel van de sites wel werkt met onenote en wallabag.
Welke motivatie hier achter zit geen idee, mogelijk heeft de persgroep hele goede juridische afdeling en cookie wall bouwers en alle andere site niet.
Ik voel mij niet geroepen daar een mening over te hebben( in deze context), als klant van tweakers probeer iets voor mij en mogelijk andere wekend te houden wat voor AVG / 25 mei 2018 prima voldeed.

Ik herken zoeken naar een oplossing niet als morren. Ik ervaar na een aantal reacties juist een constructive meedenken insteek van bijna iedereen.

[Voor 5% gewijzigd door hans3702 op 28-10-2018 10:22. Reden: typos]

[WhatsappHack]

MsG schreef op zondag 28 oktober 2018 @ 08:58:
Even zijdelings op inhakend, is dit ook de reden waarom Whatsapp nooit een mooie preview geeft van een Tweakers link, zoals wel bij het merendeel van andere sites gebeurt? Of is dat een ander fenomeen waarom dat niet werkt.

Goede vraag, noch de titel noch de content wordt van Tweakers opgehaald; die lijkt ie idd niet te vinden.
Was mij ook al eens opgevallen maar boeide te weinig.

Ik zie dat WhatsApp wel netjes een useragent meegeeft. Inclusief versie.
(Dat mag van mij dan wel weer wat algemener. )
Zo is het bij mij op de iOS beta (draai nu huidige release candidate) als volgt:

[28/Oct/2018:12:45:57 +0100] "GET / HTTP/1.1" 200 376 "-" "WhatsApp/2.18.101 i"

(die "i" weet ik niet of dat standaard is of tikfoutje in de laatste user-agent van deze beta )

Daar loopt al een draadje over zie ik net (al heel erg lang )
JossiEnd in "Thumbnail en titel van artikel bij delen via WhatsApp"

De UA van de Desktop app is ietsjes anders, maar verschilt niet veel. Toch werkt het daar wel.

[28/Oct/2018:12:54:59 +0100] "GET / HTTP/1.1" 200 376 "-" "WhatsApp/0.3.1242 N"

Zal wel niet aan de User-Agent liggen dan en dus mogelijk niet aan die cookie-muur...
Verkeerd gekeken. Daar werkt het ook niet! Zowel WhatsApp Desktop (UA staat hierboven) als Web (heeft UA van je telefoon.) heeft hetzelfde probleem. Dan ligt het mogelijk wél aan de cookie-wall. Zou wel fijn zijn als dat bevestigd kan worden, dan weten we of het in dit topic thuishoort of elders, nu er toch gekeken wordt naar 't hele zaakje Of misschien kunnen we sowieso beter in dat topic van JossiEnd daar dan verder vragen over stellen, al is dat topic al behoorlijk oud dus gok dat het geen prioriteit heeft of er een reden is dat het niet aangepast is.

[Voor 63% gewijzigd door WhatsappHack op 28-10-2018 13:00]

[crisp]

De discussie over WhatssApp kan inderdaad beter in Thumbnail en titel van artikel bij delen via WhatsApp

Als het een cookie-wall issue is dan is die user-agent daar in ieder geval nuttige informatie

[hans3702]

crisp schreef op zondag 28 oktober 2018 @ 13:07:
De discussie over WhatssApp kan inderdaad beter in Thumbnail en titel van artikel bij delen via WhatsApp

Als het een cookie-wall issue is dan is die user-agent daar in ieder geval nuttige informatie

Als je naar de bron code van de CookieWall pagina kijkt

==============
<!doctype html><!-- © 1998 - 2018 de Persgroep Online Services B.V. -->
<html lang="NL">
<head>
<title>Tweakers</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-15">
<meta http-equiv="x-ua-compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="stylesheet" href="https://tweakimg.net/x/styles/framework/main.css?1540320184">
<style type="text/css">
==============

Komt dit overeen wat je in WhattsApp zie nl alleen de url en de tittle tag



als je zelfde pagina na de Cookiewall bekijkt

===============
<!doctype html><!-- © 1998 - 2018 de Persgroep Online Services B.V. -->
<html lang="NL"><head>
<base href="https://tweakers.net/">
<meta name="description" content="Welkom op Tweakers, sinds 1998 de grootste website in Nederland over technologie en elektronica met nieuws, reviews en de bekroonde Pricewatch.">
<meta http-equiv="content-type" content="text/html; charset=iso-8859-15">
<meta name="referrer" content="origin-when-cross-origin">
<meta property="fb:app_id" content="188199811217403">
<meta name="viewport" content="width=device-width">

<title>Tweakers - Wij stellen technologie op de proef</title>
<link rel="navigator" title="Spring voorbij navigatie" href="https://tweakers.net/#contentArea">

<link rel="shortcut icon" href="https://tweakers.net/favicon.ico" type="image/x-icon">
<link rel="alternate" title="Tweakers Mixed RSS feed" type="application/rss+xml" href="https://tweakers.net/feeds/mixed.xml">
=====================

Dan verwacht ik:

"Tweakers - Wij stellen technologie op de proef"
"Welkom op Tweakers, sinds 1998 de grootste website in Nederland over technologie en elektronica met nieuws, reviews en de bekroonde Pricewatch."

te zien in het Whats App bericht. Ik heb dit met een website van mijn zelf getest en krijg van een pagina in Whatts app inderdaad de Tittle + de <meta name="description" tag in het bericht te zien naast de URL. mocht er OG tages zij zal Whattsapp mogelijk hier de voorkeur aan geven/

Op https://stackoverflow.com...or-whatsapp-link-sharing/ staat wat info mbt wat wenselijk / noodzakelijk is maar naar de weergave in Whatsapp en de header kijkend is lijkt het mij toch duidelijk ook hier de CookieWall die het delen van de tweakers pagina's naar WhattsApp gebruikers onvriendelijk maakt.


Conclusie
Ik denk dat deze info dus hier zeker op zijn plek is dat dus naast Wallabag en Onenote ook WhatsApp vastloopt op de Cookiemuur en dat dus zowel juist als onjuist gebruik van de user-agent hier geen verschil in maakt.

[Voor 9% gewijzigd door hans3702 op 28-10-2018 13:59. Reden: + conclusie en opmaak]

[crisp]

hans3702 schreef op zondag 28 oktober 2018 @ 13:21:
[...]

Conclusie
Ik denk dat deze info dus hier zeker op zijn plek is dat dus naast Wallabag en Onenote ook WhatsApp vastloopt op de Cookiemuur en dat dus zowel juist als onjuist gebruik van de user-agent hier geen verschil in maakt.

Dat maakt wel verschil, ware het niet dat we (ook nog) geen specifieke uitzondering voor WhatsApp hebben ingesteld

[hans3702]

crisp schreef op zondag 28 oktober 2018 @ 14:35:
[...]

Dat maakt wel verschil, ware het niet dat we (ook nog) geen specifieke uitzondering voor WhatsApp hebben ingesteld

Laat ik nu uit een eerdere reactie begrepen te hebben dat het: 'gedrag is 'as intended' was.

Hoe groot moet je zijn wil de deur voor je opgezet worden?

This statistic shows a timeline with the amount of monthly active WhatsApp users worldwide as of December 2017. As of that month, the mobile messaging app announced more than 1.5 billion monthly active users, up from over 1 billion MAU in February 2016. The service is one of the most popular mobile apps worldwide.

https://www.statista.com/...ly-active-whatsapp-users/

[Voor 45% gewijzigd door hans3702 op 28-10-2018 14:57. Reden: + link]

[crisp]

hans3702 schreef op zondag 28 oktober 2018 @ 14:51:
[...]

Laat ik nu denken dat het: 'gedrag is 'as intended' was.

Hoe groot moet je zijn wil de deur voor je opgezet worden
[...]

Geen idee, uiteindelijk is dat aan ons productteam om te beslissen... Ondertussen vind ik je cynische ondertoon eerlijk gezegd wel wat aanmatigend waardoor ik eigenlijk weinig zin heb om hier zelf nog energie in te stoppen..

[Xander]

hans3702 schreef op zondag 28 oktober 2018 @ 13:21:
Conclusie
Ik denk dat deze info dus hier zeker op zijn plek is dat dus naast Wallabag en Onenote ook WhatsApp vastloopt op de Cookiemuur en dat dus zowel juist als onjuist gebruik van de user-agent hier geen verschil in maakt.

Het maakt wel verschil, voor WhatsApp is het eenvoudig om een uitzondering op de cookiewall te maken.

Dat dit nog niet gebeurd is, is een ander verhaal.

[ACM]

hans3702 schreef op zondag 28 oktober 2018 @ 14:51:
Hoe groot moet je zijn wil de deur voor je opgezet worden?

Ongeacht de grootte moet er ook aan gedacht zijn en moet het technisch praktisch uitvoerbaar zijn. Onenote en wallbag voldoen niet aan die laatste. Whatsapp blijkbaar wel, maar daar was vooralsnog niet aan gedacht.

[hans3702]

ACM schreef op zondag 28 oktober 2018 @ 21:22:
[...]

Ongeacht de grootte moet er ook aan gedacht zijn en moet het technisch praktisch uitvoerbaar zijn. Onenote en wallbag voldoen niet aan die laatste. Whatsapp blijkbaar wel, maar daar was vooralsnog niet aan gedacht.

Arjen, dank je wel voor je duidelijke, constructieve en eerlijke antwoorden!
Is toch mooi dat we via een draadje tot verbeterinningen kunnen komen ieder geval voor één dienst.

Voor Wallabag denk ik dat ik overstap naar selfhosting via https://yunohost.org/ dan kan ik zelf een UA instellen. wie weet kom ik er dan doorheen als ik daar "WhatsApp" invul :-) Krijg niet de indruk dat jullie de IP adressen van een ISP in Frankrijk gaan vrijstellen van de Cookiewall

Voor Onenote weet ik geen workaround anders dan hopen dat jullie voor een lege UA en/of de MS azure IP adressen de muur neerhalen.

Hopelijk kan iemand nog uitleggen waarom de cookiewall van de persgroep op zo dicht zit dat deze genoemde en mogelijk andere sites/diensten er niet doorheen komen en bij andere cookiemuren wel.

Ook dank aan de andere die met info en aanvullingen het tot een waardevol draadje hebben gemaakt, deze personen hebben dan ook een +1 thumb up van mij ontvangen.

[Voor 0% gewijzigd door hans3702 op 28-10-2018 23:29. Reden: typos]

[F_J_K]

hans3702 schreef op zondag 28 oktober 2018 @ 22:38:
Voor Wallabag denk ik dat ik overstap naar selfhosting via https://yunohost.org/ dan kan ik zelf een UA instellen. wie weet kom ik er dan doorheen als ik daar "WhatsApp" invul :-) Krijg niet de indruk dat jullie de IP adressen van een ISP in Frankrijk gaan vrijstellen van de Cookiewall

Sterker nog: als je alleen wat IP-adressen zou doorgeven dan moet zwart-wit de wetgeving bekeken de cookiewall vooral intact blijven. Als bekend is dat er 1 gebruiker is van jouw dienst, is alles herleidbaar tot jou als persoon, zijn er dus persoonsgegevens, maar is er nog geen akkoord op plaatsen van cookies.

Hopelijk kan iemand nog uitleggen waarom de cookiewall van de persgroep op zo dicht zit dat deze genoemde en mogelijk andere sites/diensten er niet doorheen komen en bij andere cookiemuren wel.

Ik ben maar een simpele vrijwilliger en heb geen zicht op de beslissingen 'op kantoor', maar het lijkt me heel simpel: AVG en vooral Telecommunicatiewet art.11 (ePrivacy voorstel). Bij gebruikers geen niet technisch noodzakelijke cookies plaatsen zonder toestemming. Uitzondering bij diensten die 'niet een gebruiker zijn' klinkt valide, maar anders moet de webserver weten dat er toestemming is voordat cookies worden geplaatst. En 'dus' voordat er content wordt getoond.

Als er partijen zijn die wetgeving negeren en cookies gewoon plaatsen, dan is dat negeren misschien vanuit commercieel oogpunt of hopende dat er 'simpelweg' geen capaciteit is om te handhaven (hoge boetes maar lage pakkans). Maar ja...

Wetgeving: leuker kunnen ze het niet maken, lastiger wel Dat mensen die al lang een keer akkoord hebben gegeven alsnog er last van hebben, zuigt. Maar daarvoor moet je niet een ontwikkelaar hier aanspreken. Als je algemene discussie wilt over juridische vs praktische zaken rond cookies en het ePrivacy wetsvoorstel / de AVG, dan zou ik suggereren in Privacy & Beveiliging te kijken / daar een topic te openen zodat de devvers / het productteam hier kunnen focussen op kijken of/hoe een en ander technisch is te regelen om overlast waar mogelijk te minimaliseren.

Ook dank aan de andere die met info en aanvullingen het tot een waardevol draadje hebben gemaakt, deze personen hebben dan ook een +1 thumb up van mij ontvangen.

offtopic:
Sja, eerlijk gezegd vind ik je sneren richting crisp vervelend over komen. Misschien heb je zijn 'as intended' verkeerd begrepen (de muur is bewust opgeworpen, de overlast is ook getuige zijn post daarover natuurlijk geen doel). Er zaten potdorie twee ontwikkelaars op hun vrije zondag met je mee te denken.

[ACM]

hans3702 schreef op zondag 28 oktober 2018 @ 22:38:
Voor Wallabag denk ik dat ik overstap naar selfhosting via https://yunohost.org/ dan kan ik zelf een UA instellen. wie weet kom ik er dan doorheen als ik daar "WhatsApp" invul :-) Krijg niet de indruk dat jullie de IP adressen van een ISP in Frankrijk gaan vrijstellen van de Cookiewall

Van wat ik uit de code kon afleiden voldoet de standaard useragent (die van Guzzle) die ze in hun open source versie gebruiken al... Dus als je ziet dat jouw versie toch zo'n rare oude "nep echte" useragent krijgt, dan kan je kijken of je dat kan aanpassen.

Hopelijk kan iemand nog uitleggen waarom de cookiewall van de persgroep op zo dicht zit dat deze genoemde en mogelijk andere sites/diensten er niet doorheen komen en bij andere cookiemuren wel.

Dat zal in veel gevallen van de implementatie afhangen. De Persgroep is onlangs tot de conclusie gekomen dat de cookiewall voor heel Europa moet gelden, ipv alleen Nederland. Als de anderen alleen nog Nederland oid doen, dan zal dat allicht minder problemen geven omdat veel van dergelijke diensten buiten Nederland gehost zijn (zoals de Duitse en Ierse Amazon AWS-omgevingen).

Verder zijn er een paar die het stiekem met Javascript oplossen, waardoor het technisch eigenlijk onjuist is (kans is groot dat je al cookies hebt gestuurd dan), maar in dit specifieke scenario wel beter opgelost wordt.
Verder zijn er wat 'off the shelve' proxies/services hiervoor die vast wat actiever achter whitelisting aanzitten, maar wat als groot nadeel heeft dat je dan afhankelijk wordt van zo'n service (voor iedere nieuwe bezoeker moet je dan eerst aan zo'n service vragen of de gebruiker het al goedgekeurd heeft).

Ik heb overigens PhantomJS en Whatsapp toegevoegd (zal waarsch. niet helpen voor OneNote), wat volgende week dinsdag met de release meegaat.

[Voor 3% gewijzigd door ACM op 29-10-2018 10:41]

[hans3702]

F_J_K schreef op maandag 29 oktober 2018 @ 08:53:
[...]

Sterker nog: als je alleen wat IP-adressen zou doorgeven dan moet zwart-wit de wetgeving bekeken de cookiewall vooral intact blijven. Als bekend is dat er 1 gebruiker is van jouw dienst, is alles herleidbaar tot jou als persoon, zijn er dus persoonsgegevens, maar is er nog geen akkoord op plaatsen van cookies.

Ik denk niet dat dit voor een dienst als Wallabag relevant is ik ben vast niet de enige user. dat ben ik wel al ik hem zelf ga hosten en het niet deel met anderen maar dit is een een cloud dienst die net als velen andere in opdracht van een klant een pagina leegzuigt net als Facebook of Whatsapp bij delen of elke zoek machine dat doet. Dus ik doelde op een headless server in een Frans data center waarvan het ip als data center staat genoteerd en niet als thuis aansluiting.
Ik snap ook wel dat een Terminal server in een datacenter of in Azure daar een uitzondering op is maar is dat een gangbaar en realistisch scenario om dan ook maar elke server / service te blokkeren.

[...]
......Wetgeving: leuker kunnen ze het niet maken, lastiger wel Dat mensen die al lang een keer akkoord hebben gegeven alsnog er last van hebben, zuigt. Maar daarvoor moet je niet een ontwikkelaar hier aanspreken. Als je algemene discussie wilt over juridische vs praktische zaken rond cookies en het ePrivacy wetsvoorstel / de AVG, dan zou ik suggereren in Privacy & Beveiliging te kijken / daar een topic te openen zodat de devvers / het productteam hier kunnen focussen op kijken of/hoe een en ander technisch is te regelen om overlast waar mogelijk te minimaliseren.

Mijn vraag was / is meer technisch bedoelt maar dank voor je uitgebreide antwoord.
Wat mij gedachte was/is andere sites tonnen wel de content maar zetten geen cookies tot je op ok drukt en tweakers toon niks tot je ok bent met de cookies.
Wat zou kunnen, zit ik mij nu te bedenken, is dat als de cookie muur van Tweakers de tittle en meta desc. van de pagina waar de trigger vandaan komt zou overnemen dat dan een groot deel nadelen van deze muur al veel dragelijker zijn, maar wat hier de gevolgen op gebied van wetgeving van zijn heb ik geen zicht op.

ACM schreef op maandag 29 oktober 2018 @ 10:40:
Ik heb overigens PhantomJS en Whatsapp toegevoegd (zal waarsch. niet helpen voor OneNote), wat volgende week dinsdag met de release meegaat.

Ik kijk er naar uit en denk dat velen het fijn vinden dat links in Whatsapp er vanaf dan beter uit zien.
Ik dank je hartelijk voor alle interessante en informatieve reacties en dat we zo samen toch weer de site handiger hebben kunnen maken

[Voor 9% gewijzigd door hans3702 op 29-10-2018 11:43. Reden: reactie op tweede andere post in een bericht]

[F_J_K]

hans3702 schreef op maandag 29 oktober 2018 @ 11:38:
Wat zou kunnen, zit ik mij nu te bedenken, is dat als de cookie muur van Tweakers de tittle en meta desc. van de pagina waar de trigger vandaan komt zou overnemen dat dan een groot deel nadelen van deze muur al veel dragelijker zijn

Hmm. Lijkt me inderdaad een mooie oplossing voor alles dat niet in de whitelist kan (en scheelt misschien zelfs verzoeken in de whitelist te komen, dat de "content" https://tweakimg.net/g/cookies/backdrop.jpg blijft lijkt me niet zo belangrijk voor iets als de WA-links).

(@Devvers: handig als zoiets in een los MF-topic wordt geopperd?)

[crisp]

F_J_K schreef op maandag 29 oktober 2018 @ 12:46:
[...]

(@Devvers: handig als zoiets in een los MF-topic wordt geopperd?)

Je zou dat kunnen opperen, maar met de huidige setup van onze cookiewall is dat technisch een nogal lastige exercitie, dus ik acht de kans klein dat we een dergelijke feature zullen overwegen. De vraag is ook nog wat de ePrivacy verordening uiteindelijk voor de cookiewall zal gaan betekenen.

[hans3702]

Whats app ziet er goed uit


One note geeft helaas nog een foutmelding bij delen op een android telefoon maar dat komt door die aanroep met een lege UA en de cookiemuur. lag in de lijn der verwachting

TZT nog een keer de OG tags in de pagina's opnemen zou leuk zijn
https://stackoverflow.com...or-whatsapp-link-sharing/

Aanleiding van dit bericht: plan: Releasenotes development-iteratie #143

[ACM]

hans3702 schreef op dinsdag 6 november 2018 @ 14:59:
TZT nog een keer de OG tags in de pagina's opnemen zou leuk zijn
https://stackoverflow.com...or-whatsapp-link-sharing/

Welke og-tags mis je specifiek?

Want als je naar de bron kijkt, zie je o.a. bij je .plan-link gewoon og-tags staan, die hebben we al jaren.

[hans3702]

Denk dat ik het wat onhandig vermelde, de Whatsapp toont nog niet de afbeelding in de link wat voor mij de trigger was om het zo op te schrijven. Als ik nu in de bron kijk zie ik wel de og ik heb dus nu even geen idee waar het mis gaat, maar ik heb pas ook een tweakers pagina bekeken die de og vermeldingen niet had. dus dat zat ook nog in mijn hoofd. (geen idee meer welke en waar enz)
Ik had dus in

Deze afbeelding verwacht
https://tweakers.net/i/iq...in/67x67/i/2001558181.png

zoals een link naar de krant wel toont

[ACM]

Van je eigen stackoverflow-link: "Image(JPG or PNG) of size less than 300KB and minimum dimension of 300 x 200 pixel is advised"

Die maat hebben we niet, dus onze afbeeldingen zullen vaak wel genegeerd worden. Overigens pakken we al de wat grotere afbeeldingen van bijvoorbeeld een review-aankondiging als we die hebben, maar we hebben vooralsnog geen systeem (of plannen) om speciaal voor social media aparte afbeeldingen toe te voegen aan artikelen die we verder zelf niet gebruiken.

[Voor 39% gewijzigd door ACM op 07-11-2018 08:25]

[hans3702]

Heb hem door :-)
Op de tweakers pagina is de OG afbeelding 67x67 px.
Het is best wel lastig dat een paar partijen je voorschrijven hoe je met OG enz om moet gaan terwijl er volgens mij ook prima een 67x67 gebruikt kan worden in de WhatAap berichten enz.

Voor mij ook een uitdaging om het met de sites die ik maak om hier wel of niet rekening mee te houden.

tnx

[hans3702]

TER INFO: https://www.wallabag.it/en werkt sinds kort prima met Tweakers.net.
blijkbaar een aanpassing links(daar) of rechts(hier)

Ik ben er blij mee!