Cookies op Tweakers.net

[Puch-Maxi]

Ik vroeg mij af hoe cookies werken op Tweakers.net, gewoon ter lering en vermaak . De eerste keer dat je de site bezoekt krijg je een cookiewall, dit is een gevolg van de Europese cookiewet. Wij klikken dus op 'Ja, ik accepteer cookies' zodat we de website normaal kunnen gebruiken, prima. Maar welke cookies hebben we nu verkregen?

Als we kijken op: https://tweakers.net/info...rden/cookies/#functioneel dan staat daar een algemene sessiecookie: TnestID en nog een aantal andere cookies tc, LastVisit, SessionTime, pl met betrekking tot het laatste bezoek. Als wij nu gaan kijken naar welke cookies er daadwerkelijk zijn, dan zien we: __Secure-TnetID (dit zal wel de opvolger van het TnestID zijn?) maar ook een lastConsentChange (dit heeft te maken met de cookiewall).

Nu gaat mijn vraag over hoe de cookies worden gezet middels het cookieAcceptForm, dat gaat met een POST naar https://tweakers.net/my.tnet/cookies/ en een aantal hidden inputs, 'tweakers_token' en de locatie waar je naartoe wil, bijvoorbeeld de homepage. Vervolgens krijg je op magische wijze je Secure-TnetID? .

Ik heb dit eerdere topic gevonden over cookies op Tweakers.net: Cookies, wel of niet (verplicht)?
Maar ik ben dus meer geïnteresseerd in de techniek erachter .

[Señor Sjon]

Dit gaat meer over het forum zelf.

AZ >>> LA

[Demonitzu]

__Secure- is een zogeheten cookieprefix, een relatief nieuwe techniek waarmee cookies niet overschreven kunnen worden vanuit een http bron. Momenteel alleen ondersteund in Chrome en Firefox, maar werkt op progressieve wijze.

[Snake]

Toshin schreef op dinsdag 12 februari 2019 @ 17:51:
__Secure- is een zogeheten cookieprefix, een relatief nieuwe techniek waarmee cookies niet overschreven kunnen worden vanuit een http bron. Momenteel alleen ondersteund in Chrome en Firefox, maar werkt op progressieve wijze.

Wat is het verschil tussen dat en

code:

secure

?

https://developer.mozilla...cure_and_HttpOnly_cookies

[ Voor 10% gewijzigd door Snake op 12-02-2019 18:03 ]

[RobIII]

Snake schreef op dinsdag 12 februari 2019 @ 18:02:
[...]
Wat is het verschil tussen

quote: https://googlechrome.github.io/samples/cookie-prefixes/

__Secure-, which signals to the browser that the Secure attribute is required.

[ Voor 16% gewijzigd door RobIII op 12-02-2019 18:13 ]

[ACM]

Puch-Maxi schreef op dinsdag 12 februari 2019 @ 16:31:
Nu gaat mijn vraag over hoe de cookies worden gezet middels het cookieAcceptForm, dat gaat met een POST naar https://tweakers.net/my.tnet/cookies/ en een aantal hidden inputs, 'tweakers_token' en de locatie waar je naartoe wil, bijvoorbeeld de homepage. Vervolgens krijg je op magische wijze je Secure-TnetID? .

De Set-Cookie header is al aardig wat jaren onderdeel van de http-specificatie (de rfc is blijkbaar van rond 1997)

En die header wordt meegegeven op die cookies-pagina (of elke andere pagina buiten de cookiewall die je bezoekt). Dat __Secure- deel is domweg letterlijk onderdeel van de cookienaam (die van de Set-Cookie header), maar is vooral gedaan voor de eerder genoemde reden om af te dwingen dat browsers die alleen via https sturen. Dat is een van de actuele beveiligingsadviezen voor websites. Als je maar 1 domein hebt, is __Host- zelfs aanbevolen.

[Puch-Maxi]

Toshin schreef op dinsdag 12 februari 2019 @ 17:51:
__Secure- is een zogeheten cookieprefix, een relatief nieuwe techniek waarmee cookies niet overschreven kunnen worden vanuit een http bron. Momenteel alleen ondersteund in Chrome en Firefox, maar werkt op progressieve wijze.

Thanks, dat wist ik nog niet. Heb er wat over gevonden: https://www.sjoerdlangkemper.nl/2017/02/09/cookie-prefixes/

Het valt mij op dat de waarde meegegeven bij de cookies request afwijkt van de cookies response, bij het __Secure-TnetID staat er een punt voor.

edit:
Bij nader inzien is TnestID gewoon een typefoutje .

[ Voor 16% gewijzigd door Puch-Maxi op 12-02-2019 19:21 ]

[ACM]

Puch-Maxi schreef op dinsdag 12 februari 2019 @ 19:12:
Het valt mij op dat de waarde meegegeven bij de cookies request afwijkt van de cookies response, bij het __Secure-TnetID staat er een punt voor.

Je moet natuurlijk wel alle tweakers-responses volgen en de Set-cookie headers bekijken

Een cookie kan bij iedere response weer veranderen. De reden dat we dat doen is omdat er in de praktijk heel veel "clients" maar 1 request/pageview doen naar Tweakers, danwel de cookies niet bewaren. Omdat het voor ons wel handig is voor iedereen een sessie uit te delen (bijv om de cookiewall-acceptatie te bewaren), willen we toch alvast bij iedereen een sessie-id uitdelen. Maar we slaan ze nog niet per se al op. Die . is er om te herkennen dat het zo'n eerste uitgifte is.
Door alvast dat sessie-id uit te delen, kunnen we bovendien triviaal die eerste request koppelen aan latere requests... Wat we overigens niet geautomatiseerd doen en het is daarom vooral interessant als we vreemd gedrag zien en dat nader willen onderzoeken in de logs.

[Puch-Maxi]

@ACM Bedankt voor de uiteenzetting . Anders zou de database met sessies wel erg groot worden.

[XWB]

Snake schreef op dinsdag 12 februari 2019 @ 18:02:
[...]
Wat is het verschil tussen dat en

code:

secure

?

https://developer.mozilla...cure_and_HttpOnly_cookies

De secure flag zorgt er alleen voor dat cookies uitsluitend door https websites gelezen kunnen worden. Echter kunnen die cookies nog steeds door niet-https websites overschreven worden. Om dat laatste op te lossen zijn de cookie prefixes (__Secure- en __Host-) in het leven geroepen.

[AW_Bos]

Wat wel grappig is, is dat Tweakers ook een verborgen cookies-trommel kent, waarin je kan zien welke cookies er bestaan: https://gathering.tweakers.net/forum/cookiemonster

Is het een idee om deze weer een nieuw leven in te blazen zodat er een mooi overzicht is over cookies die Tweakers (of derden) hebben aangemaakt, zodat je er controle over kan houden en e.v.t. kan verwijderen? Ik denk dat in deze tijd wel enige transparantie fijn zou zijn over welke cookies er zijn, en deze lijkt alles via $_COOKIE te detecteren, dus mocht een externe partner een nieuwe cookie aanmaken, dan staat die er bij.

Helaas is deze niet meer up-to-date en missen er een hoop cookies en uitleg erbij.

[Freee!!]

AW_Bos schreef op donderdag 28 februari 2019 @ 23:21:
Wat wel grappig is, is dat Tweakers ook een verborgen cookies-trommel kent, waarin je kan zien welke cookies er bestaan: https://gathering.tweakers.net/forum/cookiemonster

Is het een idee om deze weer een nieuw leven in te blazen zodat er een mooi overzicht is over cookies die Tweakers (of derden) hebben aangemaakt, zodat je er controle over kan houden en e.v.t. kan verwijderen? Ik denk dat in deze tijd wel enige transparantie fijn zou zijn over welke cookies er zijn, en deze lijkt alles via $_COOKIE te detecteren, dus mocht een externe partner een nieuwe cookie aanmaken, dan staat die er bij.

Helaas is deze niet meer up-to-date en missen er een hoop cookies en uitleg erbij.

Bedankt voor dat cookiemonster, zie twee onbekende cookies die direct terugkomen na verwijderen (wt_cdbeid en wt_rla).

[XWB]

AW_Bos schreef op donderdag 28 februari 2019 @ 23:21:
Wat wel grappig is, is dat Tweakers ook een verborgen cookies-trommel kent, waarin je kan zien welke cookies er bestaan: https://gathering.tweakers.net/forum/cookiemonster

Nee, op die pagina zie je alleen de cookies die je hebt, en niet per se alle cookies die bestaan. Voor dat laatste is er https://tweakers.net/info/algemene-voorwaarden/cookies/

[AW_Bos]

XWB schreef op donderdag 28 februari 2019 @ 23:59:
[...]


Nee, op die pagina zie je alleen de cookies die je hebt, en niet per se alle cookies die bestaan. Voor dat laatste is er https://tweakers.net/info/algemene-voorwaarden/cookies/

True, maar doelde met 'bestaan' als in 'op je device bestaan'

[Generaal Pep]

Lieve Adjes en devs op het Tweakers kantoor,

Bedankt voor de nieuwe cookie-wall. Top dat ik nu cookies van derde mag weigeren, zonder ervoor te betalen!

[RobIII]

plan: Forum trackingvrij en shopfilterverbeteringen - Development-iteratie #214

Doe daar maar even ipv deze ouwe koei

[ Voor 9% gewijzigd door RobIII op 18-08-2021 09:21 ]