Disqus - Latest Comments for czw

Re: WindTre: entra in vigore il nuovo piano Basic New a 4 euro al mese per i primi clienti rimodulati

czw — Sat, 26 Sep 2020 14:09:44 -0000

Non uso l'app, quando mi serve visito il sito; attualmente non tengo quella sim in uno smartphone, quindi non potrei fare uno sceenshot, però ho i codici della chiamata con cui ho chiesto il cambio verso "windtre basic" (che per loro è obbligatorio consentire, lo stabilisce la prima delibera che ho citato). Nei prossimi giorni chiamerò il servizio clienti per provare a risolvere, ma non ho buone sensazioni, spero di sbagliare, ma a me sembra che vogliano provare a "forzare" un po' la rimodulazione (che nel mio caso, se non l'avessi rifiutata in tempo, sarebbe dovuta avvenire il 23, e il 23 non è successo nulla). Questo "passaggio di default" è comunque irregolare, come il tentativo di bloccare i cambi di piano e non aver comunicato fin dall'inizio la possibilità di effettuare un cambio gratuito verso gli altri piani base sottoscrivibili. Negli ultimi anni altri operatori sono stati multati per motivi simili; se risolvono bene, altrimenti mi rivolgerò al garante.

Re: WindTre: entra in vigore il nuovo piano Basic New a 4 euro al mese per i primi clienti rimodulati

czw — Sat, 26 Sep 2020 11:11:26 -0000

La settimana scorsa ho chiamato il 159 e seguito la procedura per cambiare il piano con un operatore (mi sono segnato i codici della chiamata). Ho chiarito subito che intendevo rifiutare la rimodulazione e ho chiesto il cambio del piano in windtre basic, facendo riferimento alle delibere dell'AGCOM n. 326/10/CONS, art. 1 comma 2 e n. 252/16/CONS art. 4. L'operatrice mi confermava che non ci sarebbero stati costi mensili. A breve distanza mi è giunto l'SMS che confermava l'attivazione del piano WIND BASIC. Finora non ho ricevuto addebiti, però il 25/09 mi è arrivato un ulteriore SMS che mi comunicava l'attivazione del piano NEW BASIC, che risulta anche nell'area personale dell'operatore. Se in data 01/10 (o comunque nei prossimi giorni, anche dopo il 01/10) mi saranno addebitati dei costi fissi denuncerò l'operatore all'AGCOM per violazione delle suddette delibere, cambio piano non autorizzato, violazione dell'art. 70 del Codice delle Comunicazioni Elettroniche. Oltretutto, il piano Basic New non è presente nella sezione dedicata alla trasparenza tariffaria, anche questo è censurabile e sanzionabile con un'ammenda.

Edit: per la delibera 326/10/CONS si tratta dell'art. 1 comma 2, non 10 comma 1 come avevo indicato erroneamente all'inizio.

Re: SecuriTeam - Yet another Plaintext Attack on ZIP's Encryption Scheme (WinZIP)

czw — Sun, 22 Feb 2015 15:47:55 -0000

Interesting article. Is it possible to get a copy of your proof-of-concept for testing purposes?

Re: Faking 'onpaste' in Firefox - Intridea Company Blog

czw — Mon, 28 Sep 2009 22:05:03 -0000

When I wrote:
"b) get a copy of the 'onpaste' attribute and call it as needed (little trick, wrap it to build an object - something like '{pasteHandler : function(){<original code="" here="">; return; } }' - so that eval can be called once and for all, and a compiled function is called instead of an interpreted code, to increase performance a bit --- javascript is executed through a jit-compiler, whereas eval interprets the code each time)."
I meant:
"b) get a copy of the 'onpaste' attribute, erase it (element.onpaste = '') and...."

Re: Faking 'onpaste' in Firefox - Intridea Company Blog

czw — Mon, 28 Sep 2009 21:56:10 -0000

An alternative solution (I've not tested, but should be easily crossbrowser, in place of the onpaste event), could be the following:

When document loads, get every textarea element and add a 'previousValue' property initialized with the element value, then add to the textarea parent element a 'onclick' event hanlder checking for a right button click bubbling from a textarea element, so that, once such event bubbles, the appropriate code is executed. Problem: one could miss a 'CTRL+V' paste, but this is solved by adding a 'onkeypress' event to the textarea calling the same code as the onclick handler (after checking for the right control sequence). So 3 functions are needed, one to perform onpaste stuff, and two checking for a possible paste and calling the former.

Anyway, a full string comparison should be performed to guess a paste (but for the 'ctrl+v' sequence), because there are always chance to find someone doing:
a) a single character paste (thus the instruction 'value.length > previousValue.length+1' would fail), or
b) a paste operation of a string being shorter than or equal to a selection of text (thus value.length would be lesser than or equal to previousValue.length);
therefore, any comparison between strings length may fail.

Caveat: two or more textareas could share the same parent, thus, if a routine is adding handlers to an existing page, one could attach the same event handler to the same element multiple times; to avoid that, one could choose a common ancestor for both/all textareas (the body element to make it short); otherwise, one could take care of what's going on and avoid any problem. Two methods (at least) to achive that:
a) create an array to list all involved elements and check if an element is yet in the list before attaching a listener to it, or
b) let the handler remember (for instance, through a closure) what's the last evaluated event, and check if the current event is the same to stop execution.
Note that duplicate listeners with the same event type and capture flag should be discarded (as per specs), unless a bug alterates regular behaviours, thus one should avoid to add the same listener to the same element multiple times.

Morover, if an 'onpaste' attribute is present and the algorithm I'm describing is used to add crossbrowser behaviours to any existing (and otherwise unchanged) page, the handler could be called twice or more (one because of our trick, one because the onpaste event is supported). To solve this:
a) identify the browser as not supporting onpaste natively and not masking itself as IE (that is, do not check the navigator object, but look for specific properties, for instance, window.opera for Opera), and choose if it's the case to add fake support, or
b) get a copy of the 'onpaste' attribute and call it as needed (little trick, wrap it to build an object - something like '{pasteHandler : function(){<original code="" here="">; return; } }' - so that eval can be called once and for all, and a compiled function is called instead of an interpreted code, to increase performance a bit --- javascript is executed through a jit-compiler, whereas eval interprets the code each time).
The original code could avail of some properties on the paste event, in which case a fake event should be created too. If other scripts attach other event handler for the paste event to the same object... well, let's modify those scripts too! (or create a list of them all, for each element, then remove them before they can be executed).

I can't guess other problems rigth now :-P

~~~~~~~~

@Glenn Slayden
Yes, both Prototype and Prototype.Browser must exist and be objects for the above code to work properly, otherwise an exception/error may be raised.