You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Materiale davvero interessante...
da una veloce occhiata mi facevo qualche domanda teorica:
1)le prove forensi non dovrebbero essere legate al provvedimento cautelare? il senso giuridico di poterle mettere in modo libero qual è? oltre al fatto non possono essere vagliate come pertinenza né come attendibilità.
2)Com'è che le prove si possono caricare fino a 24h dopo, ma il blocco deve avvenire in 30 min?
3)Gli isp vengono valutati sulla base dei tempi di risposta, ma questo accade utilizzando come dato il cambio stato (o il timestamp allegato al cambio stato se presente), nessuno controlla davvero il blocco sia eseguito e quando
4)le api isp permettono il download di un ticket (sapendo l'id) o di tutti i ticket, fine. Non permettono ad esempio di scaricare tutti i soli ticket non processati, quindi in base allo stato. Ha senso che vengano richiesti e scaricati json da migliaia di oggetti (di cui il 99.9% inutili) potenzialmente ogni pochi secondi?
5)La documentazione di processed/unprocessed dell'isp è a dir poco carente: non c'è modo di specificare un ticket id? se l'azione riguarda più di un campo tra ipv4, ipv6 e nome avendo solo value nel json bisogna inviare più json?
E nel caso di errorri isp? non esiste il ticket error come il segnalatore.
Nel caso di cambi stati differenti sulla medesima risorsa? tipo segnalo processed e poi unprocessed (con uno dei bellissimi stati proposti, tipo unknown) e non blocco nulla a livello pratico, che accade?
6)il senso di avere whitelist personali? non dovrebbero essere oggettive e quindi condivise? E dato dalla documentazione mi pare di capire vengano fornite vuote, riempirle è un ulteriore onere (almeno per gli isp, i segnalatori credo siano immuni da qualsiasi conseguenza penale/civile, non so in base a cosa). Se l' isp dimentica di riempire per bene le whitelist e blocca una risorsa in buona fede (per una segnalazione), ne ha responsabilità o è immune anche lui?
e se sono tutti immuni, perchè avere whitelist? tanto non è colpa di nessuno.
E anche qualcuna pratica:
1)io sono un cagnaccio, ma il senso di fare centinaia di eccezioni, tutte belle divise, tutte con un commento pertinente e chiaro e poi come contenuto.... pass e basta. Senza un log, una propagazione, nulla...
2)ci sono vagonate di import non utilizzati e nei modelli ci sono attributi non dichiarati ed allegramente assegnati nei metodi.
I repo pubblicati sono davvero relativi alla versione di produzione? è quasi incredibile funzioni.
Ovviamente non mi aspetto risposte, ma magari può dare spunti per un confronto interessante con idee di altre persone.
The text was updated successfully, but these errors were encountered:
Le guide si riferiscono alla versione 2.4.1, mentre la versione più recente (che è anche quella dell'api) è 2.5, quindi potrebbero esserci delle discrepanze sulle informazioni date dalle guide, e sul codice scritto.
Materiale davvero interessante...
da una veloce occhiata mi facevo qualche domanda teorica:
1)le prove forensi non dovrebbero essere legate al provvedimento cautelare? il senso giuridico di poterle mettere in modo libero qual è? oltre al fatto non possono essere vagliate come pertinenza né come attendibilità.
2)Com'è che le prove si possono caricare fino a 24h dopo, ma il blocco deve avvenire in 30 min?
3)Gli isp vengono valutati sulla base dei tempi di risposta, ma questo accade utilizzando come dato il cambio stato (o il timestamp allegato al cambio stato se presente), nessuno controlla davvero il blocco sia eseguito e quando
4)le api isp permettono il download di un ticket (sapendo l'id) o di tutti i ticket, fine. Non permettono ad esempio di scaricare tutti i soli ticket non processati, quindi in base allo stato. Ha senso che vengano richiesti e scaricati json da migliaia di oggetti (di cui il 99.9% inutili) potenzialmente ogni pochi secondi?
5)La documentazione di processed/unprocessed dell'isp è a dir poco carente: non c'è modo di specificare un ticket id? se l'azione riguarda più di un campo tra ipv4, ipv6 e nome avendo solo value nel json bisogna inviare più json?
E nel caso di errorri isp? non esiste il ticket error come il segnalatore.
Nel caso di cambi stati differenti sulla medesima risorsa? tipo segnalo processed e poi unprocessed (con uno dei bellissimi stati proposti, tipo unknown) e non blocco nulla a livello pratico, che accade?
6)il senso di avere whitelist personali? non dovrebbero essere oggettive e quindi condivise? E dato dalla documentazione mi pare di capire vengano fornite vuote, riempirle è un ulteriore onere (almeno per gli isp, i segnalatori credo siano immuni da qualsiasi conseguenza penale/civile, non so in base a cosa). Se l' isp dimentica di riempire per bene le whitelist e blocca una risorsa in buona fede (per una segnalazione), ne ha responsabilità o è immune anche lui?
e se sono tutti immuni, perchè avere whitelist? tanto non è colpa di nessuno.
E anche qualcuna pratica:
1)io sono un cagnaccio, ma il senso di fare centinaia di eccezioni, tutte belle divise, tutte con un commento pertinente e chiaro e poi come contenuto.... pass e basta. Senza un log, una propagazione, nulla...
2)ci sono vagonate di import non utilizzati e nei modelli ci sono attributi non dichiarati ed allegramente assegnati nei metodi.
I repo pubblicati sono davvero relativi alla versione di produzione? è quasi incredibile funzioni.
Ovviamente non mi aspetto risposte, ma magari può dare spunti per un confronto interessante con idee di altre persone.
The text was updated successfully, but these errors were encountered: