Tipi multipli di tracciamento

1

In un sistema in cui ho recensioni di prodotti, per evitare recensioni false ho pensato di fare quanto segue:

  1. Limita una recensione per ogni account - > Per bypassare questa misura, l'utente potrebbe creare più account.
  2. Limita l'impronta digitale del browser per ciascun prodotto. Per bypassare questa misura, la creazione di un nuovo account non funzionerà per l'utente malintenzionato. Ma poi potrebbe cambiare il browser per ottenere una nuova impronta digitale.
  3. Limita un IP per la revisione di ogni prodotto. La mia domanda riguarda questo passaggio. Se limito un IP per ciascun prodotto, so che le aziende o le scuole hanno lo stesso IP statico per un vasto pubblico, ma il problema non è questo. Il mio problema riguarda gli IP dinamici. Se un utente legittimo riceve un IP registrato in precedenza di un altro utente, non può creare una nuova recensione. Quindi, dovrei usare solo i primi due passaggi? Quali sono le reali probabilità di due persone, membri di questa app, di voler scrivere una recensione sullo stesso prodotto, ricevendo lo stesso IP? È solo paranoico o potrebbe essere uno scenario reale? Bene, l'utente malintenzionato potrebbe ottenere facilmente un nuovo IP, quindi questo passaggio è davvero facile da ignorare.
  4. Non sono interessato a cose come evercookie.
  5. C'è un altro modo per monitorare?
posta user2990084 21.08.2015 - 01:48
fonte

3 risposte

1

Limitare per IP è troppo severo secondo me:

  • Come hai detto, c'è un problema con l'IP dinamico. Ma questo da solo potrebbe forse essere risolto se si applica questo limite solo entro un intervallo di tempo specifico perché l'IP non cambia così spesso.
  • Ma le aziende e le istituzioni usano spesso indirizzi IP privati all'interno e hanno pochi gateway Internet. Ciò significa che tutti gli utenti hanno lo stesso IP in uscita.
  • E poi tu DS-Lite e metodi di accesso simili. Qui gli utenti ricevono solo un indirizzo IPv4 privato e condividono lo stesso indirizzo IPv4 pubblico perché non ci sono abbastanza indirizzi IPv4 pubblici per tutti. Di solito hanno un indirizzo IPv6 unico però. Questo tipo di accesso influisce probabilmente sulla maggior parte delle reti mobili, in gran parte dell'Asia ma anche su alcuni ISP in Europa o in America.

Penso che il modo migliore sia limitare le recensioni per account e quindi rendere difficile la creazione dell'account, ad esempio utilizzare i captcha ecc. Esiste anche una ricerca per rilevare account fasulli in modo da poter chiudere gli account in un secondo momento e rimuovere le recensioni, per esempio Aiutare il rilevamento di account falsi in servizi online social su larga scala dalla recente conferenza USENIX.

Ovviamente tutto ciò che fai per limitare l'abuso potrebbe renderlo più complesso potrebbe dissuadere alcuni utenti benevoli dall'usare il tuo sistema. Ma se c'è troppo abuso il tuo sistema è inutile anche per loro. Probabilmente è molto difficile trovare il giusto equilibrio e se si guardano i social network, i web mailer gratuiti ecc. Cambiano costantemente le loro procedure per rendere più facile per gli utenti benevoli l'uso del sistema, ma è difficile per gli spammer abusarne. Dal momento che gli spammer evolvono anche le loro tecniche, probabilmente devi regolare il tuo sistema regolarmente. Oppure potresti provare a trarre profitto dalle convalide di google etc sui loro account e invece di fare tutto il processo di creazione e convalida dell'account, fai in modo che l'utente effettui l'accesso con i loro account Google o Facebook.

    
risposta data 21.08.2015 - 07:36
fonte
0

Perché non utilizzare l'autenticazione in due passaggi? Qualsiasi utente che esegue la revisione dovrebbe ottenere un codice di autorizzazione sul suo numero di cellulare. Dopo aver fornito quel codice sul browser, è stato possibile eseguire la revisione del prodotto.

Dovrebbe esserci un limite al numero di celle: un utente con un numero di cellulare specifico può controllare per una volta.

    
risposta data 21.08.2015 - 17:36
fonte
0

Analisi tecnica dei meccanismi di identificazione del cliente da Google descrive molti browser e euristiche a livello di rete per browser / utenti di impronte digitali:

1.1 HTTP cookies
1.2 Flash LSOs
1.3 Silverlight Isolated Storage
1.4 HTML5 client-side storage mechanisms
1.5 Cached objects
1.6 Cache metadata: ETag and Last-Modified
1.7 HTML5 AppCache
1.8 Flash resource cache
1.9 SDCH dictionaries
1.10 Other script-accessible storage mechanisms
1.11 Lower-level protocol identifiers

Puoi trovare un'implementazione di esempio con queste tecniche e altre ancora su BrowserLeaks .

    
risposta data 21.09.2015 - 00:36
fonte

Leggi altre domande sui tag