Fare i check via JS

[vekexasia]

Ho notato che attualmente i check vengono fatti server-side.

Anche se questo funziona rimuove la possibilità di cachare le pagine per gli utenti che non hanno accettato la cookie policy.

Oltre a inficiare nelle prestazioni del server e di risposta (e di crawling) potrebbe portare a DOS del sito dato che viene bypassata la creazione della cache di W3TC.

La soluzione è printare la configurazione del plugin nella pagina sottoforma di JSON e utilizzare un javascript nel frontend che valuti il da-farsi (mostrare|non mostrare).

Grazie.

[andreapernici]

Ciao vekexasia,

a questo purtroppo una soluzione che va sempre bene non c'è. La legge a quanto pare non contempla le implicazioni delle cache etc etc perché fatta da persone poco competenti quindi il problema rimarrebbe perché comunque si va ad inficiare in ogni caso i meccanismi di cache a meno di stravolgere come funzionano i plugin di cache.

In ogni caso si potrebbe aggiungere una opzione, ma non sarebbe una soluzione quindi se hai tempo e voglia puoi anche aiutarci a sviluppare una opzione come l'hai descritta tu sopra.

Considerando sempre che bisogna contemplare anche i casi dove il JS non è abilitato.

[vekexasia]

Non avevo considerato la possibilità del JS non abilitato. Però adesso che ci penso la maggior parte (forse tutte?) le attuali implementazioni di sistemi che potrebbero usare i cookie utilizzano JS. Dal like button ad adsense e (ovviamente) google analytics.

in ogni caso, se non erro ma non ho avuto modo di controllare in modo approfondito, il click viene registrato via javascript?

Appena avrò un po di tempo potrei implementare.

[acardinale]

Come potrebbe essere possibile rimuovere gli script via Javascript? Significherebbe che siano già stati inviati al browser (nel DOM).

Una cosa possibile lato server ci sarebbe, ma non posso implementarla adesso.

[image: Andrea Cardinale]Andrea Cardinale Follow me: [image: Google plus] https://plus.google.com/105123558530541749555/posts[image: Linkedin] http://it.linkedin.com/in/andreacardinale[image: Twitter] http://twitter.com/CardinaleAndrea[image: Facebook] http://it-it.facebook.com/Andrea.Cardinale.80 E-mail: a.cardinale80@gmail.com Mobile: +39 3929620242 Personal Site: http://www.andrea-cardinale.it Company Site: http://www.webandtech.it

Skype: cardinaleandrea

Il giorno 12 giugno 2015 14:34, Andrea Baccega notifications@github.com ha scritto:

Non avevo considerato la possibilità del JS non abilitato. Però adesso che ci penso la maggior parte (forse tutte?) le attuali implementazioni di sistemi che potrebbero usare i cookie utilizzano JS. Dal like button ad adsense e (ovviamente) google analytics.

in ogni caso, se non erro ma non ho avuto modo di controllare in modo approfondito, il click viene registrato via javascript?

Appena avrò un po di tempo potrei implementare.

— Reply to this email directly or view it on GitHub https://github.com/ItalyCookieChoices/italy-cookie-choices/issues/79#issuecomment-111477158 .

[vekexasia]

@acardinale sinceramente opterei per un approccio javascript. Invece di evitare l'inclusione dei javascript che settano i cookie io "watcherei" la variabile document.cookie e interverrei ad ogni cambiamento.

In questo modo l'output della pagina è sempre uguale e tutto il lavoro viene fatto client-side. More info: https://gist.github.com/eligrey/384583 e https://github.com/melanke/Watch.JS/

[overclokk]

L'idea iniziale era quella di limitare il più possibile il codice da aggiungere alla pagina per mostrare il banner (odio dover aggiungere codice inutile, vedi emoji) ed evitare che venga ripetuto tutto il processo alla seconda visita infatti se esiste il cookie il plugin non esegue nulla e vengono ripristinate le prestazioni iniziali (odio anche i plugin che rallentano i siti perché eseguono codice anche se non c'è bisogno), facendo il controllo via js io devo eseguire tutto il processo di analisi dell'HTML comunque ad ogni visita perché lo snippet andrà sempre stampato nell'HTML, poi se non c'è il cookie lo si mostra (display:block), se c'è il cookie non lo si mostra (display:none), capisco che non cachare la prima visita possa essere un contro senso ma possiamo (ed è nella lista di cose da implementare) fare un controllo sullo user agent così da restituire la pagina cachata a tutti i bot.

Per quanto riguarda gli attacchi DOS possiamo implementare una pagina nella wiki dove spieghiamo la configurazione da usare con i plugin per sicurezza più usati come iTheme security così da bloccare direttamente gli spambot.

Detto questo però non escludo che non si possa implementare una tale funzionalità, la cosa importante è che un eventuale implementazione dovrà essere sempre una scelta dell'utente (dove indicheremo i pro e contro delle due opzioni) quindi non cambiare il funzionamento attuale ma aggiungere un'opzione per attivare quello alternativo che potrà essere usato appunto in casi come quello indicato, quindi @vekexasia se hai voglia di sviluppare questa soluzione alternativa saremo bel lieti di testarla ed eventualmente integrarla nel plugin.

[andreapernici]

Quella di rimozione selettiva dei cookie lato JS se non erro va anche contro le TOS di Adsense ad esempio e secondo me non è un grande approccio.

L'ideale sarebbe quello di avere una doppia cache che in teoria è anche possibile con W3TC.

[overclokk]

La doppia cache sarebbe l'ideale e taglierebbe la testa al toro

Comunque il cookie va bloccato prima non rimosso dopo. (anche se ad oggi non sappiamo ancora cosa sia da bloccare e cosa no.)

[vekexasia]

Potrei dire una puttanata ed essendo da mobile mi risulta difficile controllare ma non credo AdSense setti alcun cookie sul dominio! Credo che i cookie vengano settati nel dominio di google per permettere il re marketing.

Quindi non andremmo incontro ad alcuna violazione dei TOS (per ora).

Per quanto riguarda invece il dos non é solo alla prima visita il problema.

Inoltre introdurre check sull user agent potrebbe essere ancora più distruttivo a livello caching : ad esempio non sarebbe più possibile utilizzare cloudflare come front proxy e cachare le pagine perché, per l'appunto, non sono supportati behaviour diversi per useragent diversi. (A meno che qualcuno non voglia pagare 5k/mese). Questo é solo uno dei problemi ad utilizzare un check sull useragent oltre che, a mio avviso, complicare lo sviluppo.

PS: anche io ho le mie paranoie e son curioso. Perche non vuoi codice inutile? Semplicemente perche credi appesantisca il render? Il 12/giu/2015 04:24 PM, "Andrea" notifications@github.com ha scritto:

Quella di rimozione selettiva dei cookie lato JS se non erro va anche contro le TOS di Adsense ad esempio e secondo me non è un grande approccio.

L'ideale sarebbe quello di avere una doppia cache che in teoria è anche possibile con W3TC.

— Reply to this email directly or view it on GitHub https://github.com/ItalyCookieChoices/italy-cookie-choices/issues/79#issuecomment-111511942 .

[overclokk]

@vekexasia giusto, non avevo pensato a servizi come cloudflare, allora rimane la doppia cache di W3TC quella più papabile.

PS: anche io ho le mie paranoie e son curioso. Perche non vuoi codice inutile? Semplicemente perche credi appesantisca il render?

Tutto ciò che aggiungi nella pagina può essere potenzialmente un problema di performance e quindi l'obiettivo è quello di ridurre al minimo indispensabile il problema che creiamo inserendo codice superfluo (finché non aboliscono questa legge direi purtroppo inevitabile)

PS: non era riferito al tuo codice ma in generale (vedi ultima trovata di dover per forza avere codice per gli emoji senza possibilità di poter disabilitare tranne tramite codice o plugin)

[andreapernici]

Premesso che il Ddos se te lo vogliono fare te lo fanno lo stesso.

Non credo che sia la Cache a salvarti da un Ddos, ma solo un buon firewall.

I DDos sono altra cosa e quelli di cui parli tu secondo me sono semplici attacchi lanciati a software fatti male da questo punto di vista come lo è in parte WP.

Insomma chiamerei le cose con il loro nome.

Se poi ci sono X complessità perché vuoi gestire vari livelli di cache, cloudflare e chi più ne ha più ne metta credo che non sia un plugin la soluzione più opportuna per te, ma qualcosa di custom tagliato su misura per il tuo caso.

Comunque se vuoi aiutarci ad implementare una nuova funzionalità nel senso che auspichi sei il benvenuto.