Libreria Javascript: per offuscare o non offuscare – questa è la domanda

Ho bisogno di scrivere una libreria javascript relativa alla GUI. Darà al mio sito un po ‘di vantaggio (in termini di funzionalità che posso offrire) – finché i miei concorrenti non giocheranno con esso abbastanza a lungo da capire come scriverlo da soli (o infine hackerare lo script scaricato). Posso accettare il fatto che verrà emulato nel tempo – questo è il par per il corso (la sua parte di attività). Voglio solo avere qualche mese di spazio per respirare dove la gente va “Wow – come l’hanno fatto?” – che mi dà qualche mese di pubblicità gratuita e un po ‘di slancio per passare ad altre cose.

Per essere chiari, non sono nemmeno preoccupato per gli hacker hard core che continueranno a hackerare la fonte – è una battaglia persa che non vale la pena combattere (e in ogni caso accetto che il mio codice non sia “così prezioso”). Tuttavia, ciò che non sopporto, è l’idea di fare in modo efficace, semplicemente consegnando tutto il duro lavoro che sarebbe andato in biblioteca ai miei concorrenti, usando un semplice javascript che chiunque può scaricare e usare. Se qualcuno userà ciò su cui ho lavorato, allora di sicuro non voglio semplicemente consegnarlo a loro – voglio che lavorino sodo per decodificarlo. Se riescono a decodificarlo, meritano di avere il codice ( molto probabilmente scopriranno che avrebbero potuto scrivere un codice migliore da soli – semplicemente non avevano il buonsenso di mettere tutti i componenti [plain vanilla] in quel particolare ordine ) – Quindi, non sto sostenendo che nessuno avrebbe potuto scrivere questo (che sarebbe in ogni caso assurda affermazione) – ma piuttosto, quello che sto dicendo è che nessuno (fino ad ora) ha fatto la funzionalità che sono parlando, disponibile per questo particolare settore – e io (pensando come un imprenditore piuttosto che un geek / coder ), voglio mungerlo per tutto il suo valore, finché dura cioè fino a quando (inevitabilmente) viene violato.

È un dato di fatto che non un sito web nel settore che sto “attaccando” ha questa funzionalità, quindi il valore di una tale libreria è innegabile e non è in discussione (cioè questo non è quello che sto chiedendo qui).

Quello che sto cercando di scoprire sono i pro e i contro di offuscare una libreria javascript, in modo che io possa arrivare a una decisione finale.

Due delle mie più grandi preoccupazioni sono il debugging e gli errori sottili che possono essere introdotti dall’offuscatore.

    Mi piacerebbe sapere:

    1. Come posso gestire questi rischi (essere in grado di eseguire il debug del codice errato, garantendo / minimizzando gli errori di offuscamento)

    2. Ci sono degli offuscamenti standard di buona qualità che puoi raccomandare (preferibilmente qualcosa che usi tu stesso).

    3. Quali sono le tue esperienze nell’uso del codice offuscato in un ambiente di produzione?

    Se riescono a decodificarlo, meritano di avere il codice (molto probabilmente scopriranno che avrebbero potuto scrivere un codice migliore da soli – semplicemente non avevano il buonsenso di mettere tutti i componenti [plain vanilla] in quel particolare ordine ).

    Quindi, davvero, stai cercando di risolvere un problema aziendale con misure tecniche.

    Chiunque valga la pena saltarlo come programmatore Javascript dovrebbe essere in grado di ricreare qualsiasi cosa tu faccia abbastanza facilmente guardando solo il prodotto stesso, nessun codice necessario. Non è che stai inventando qualche nuova cosa magica mai vista prima, stai solo mettendo insieme i pezzi in un modo nuovo, come ammetti tu stesso. È solo Javascript.

    Anche se offuscate la sceneggiatura, continuerà a funzionare così com’è, i concorrenti potrebbero semplicemente prenderlo e correre con esso. Alcune personalizzazioni non dovrebbero essere troppo difficili anche con codice offuscato.

    Nella tua attività di nicchia, probabilmente noterai abbastanza rapidamente se qualcuno “ruba” la tua sceneggiatura. Se ciò accade, è un problema legale. Se i tuoi concorrenti vogliono essere in chiaro legalmente, dovranno comunque riscrivere il copione da zero, che ti comprerà automaticamente un po ‘di tempo.

    Se i tuoi concorrenti non sono tecnicamente in grado di copiare il tuo prodotto senza rubare il codice, non farà alcuna differenza se il codice è in chiaro o offuscato.

    Mentre puoi percorrere la lunga e pericolosa strada degli offuscatori, in genere non li vedi usati nelle applicazioni di produzione reali per il semplice motivo che in realtà non fanno molto. Noterai che le app di Google, che sono davvero un mucchio di JavaScript proprietario e di grande valore quando ci si arriva, sono davvero ridotte al minimo e non sono offuscate, anche se il modo in cui i minimizzatori funzionano ora, sono altrettanto offuscati. Hai davvero bisogno di sapere cosa stai facendo per estrarre il significato da loro, ma quelli determinati avranno successo.

    L’altro problema è che il codice offuscato deve funzionare, e se funziona, le persone possono semplicemente strapparlo all’ingrosso, non comprenderne gran parte e usarlo come ritengono opportuno in quella forma. Certo, non possono modificarlo direttamente, ma non è difficile stratificare su alcune patch che reimplementano parti che non piacciono senza dover entrare troppo in profondità. Questa è semplicemente la natura di JavaScript.

    La ragione per cui Google e simili non soffrono di un’eruzione di concorrenti “taglia e incolla” è perché il JavaScript è solo una parte del pacchetto. Per avere un certo grado di controllo su come e dove queste cose sono usate, un grande componente deve essere basato sul server. La buona notizia è che puoi sfruttare elementi come Node.js per semplificare la suddivisione del codice client e server senza dover reimplementare parti in un linguaggio completamente diverso.

    Quello che potresti voler investigare non è tanto offuscare, ma dividere la tua applicazione in parti che possono essere caricate su richiesta da qualche tipo di servizio, e poiché queste parti possono essere altamente interdipendenti e per lo più non funzionali senza questo nucleo server, è ansible avere un maggiore grado di controllo su quando e dove viene utilizzata questa libreria.

    Puoi vedere elementi di questo nel modo in cui Google si sta spostando in una meta-libreria che funge semplicemente da caricatore per le altre librerie. Questo è un passo verso l’unificazione delle chiamate di carico per Google Apps, Google AdSense, Google Maps, Google Adwords e così via.

    Se vuoi essere un po ‘furbo, puoi essere come Google Maps e aggiungere una pillola avvelenata alle tue librerie JavaScript mentre vengono servite dynamicmente in modo che funzionino solo in un determinato sottodominio. Ciò richiede la loro generazione in base alle necessità e, sebbene possa sempre essere rimosso con sufficiente esperienza, impedisce l’uso di copia-incolla all’ingrosso dei file JavaScript. Inserire una chiamata intelligente che convalida document.href non è difficile, e trovare tutte queste istanze in un file minimizzato in modo aggressivo sarebbe particolarmente irritante e probabilmente non ne vale la pena.

    Fogli di obsolescenza Javascript:

    • Nessuno può offrire un offuscamento javascript gratuito al 100%. Ciò significa che con il tempo e la conoscenza ogni offuscamento può essere “annullato”.
    • Minify! = Offuscamento: quando si minimizza l’objective è: ridurre la dimensione del codice. Il codice minisito sembra completamente diverso ed è molto più complesso da leggere (suggerimento: jsbeautifier.com). Obfucation ha un objective completamente diverso: proteggere il codice. Le trasformazioni utilizzate provano a proteggere il codice offuscato da debugging e intercettazioni. L’offuscamento può persino produrre una versione ancora più grande del codice originale che è completamente contraria agli obiettivi della minificazione.
    • Obfuscation! = Encryption: questo è ovvio ma il suo errore comune è commesso da qualcuno.
    • L’offuscamento dovrebbe rendere il debug molto più difficile, il suo uno degli obiettivi. Quindi, se è fatto correttamente, puoi aspettarti di perdere un sacco di tempo cercando di eseguire il debug del codice offuscato. Detto questo, se è fatto correttamente, l’introduzione di nuovi errori è un problema raro e puoi facilmente trovare se è un errore di offuscamento di sostituendo temporaneamente il codice con codice non offuscato.
    • L’offuscamento NON è una perdita di tempo: è uno strumento. Se usato correttamente, puoi far perdere agli altri molto tempo;)

    Javascript obfuscation fiction: (salterò questa sezione;))

    Risposta a Q2: strumenti per l’offuscamento di zuccheri:

    • Per un elenco completo di obfuscator di javascript: malwareguru.org . La mia scelta personale è jscrambler.com.

    Risposta a Q3: esperienze nell’uso del codice offuscato

    • Ad oggi nessun nuovo bug introdotto dall’offuscamento
    • Molto meglio la fidelizzazione del cliente. Devono venire alla fonte per ottenere la fonte;)
    • I falsi positivi occasionali segnalati da alcuni strumenti anti-virus. Può essere testato prima di distribuire qualsiasi nuovo codice utilizzando uno strumento come Virustotal.com

    Risposta standard alle domande di offuscamento: sta utilizzando un obfuscator abbastanza per proteggere il mio codice JavaScript?

    IMO, è una perdita di tempo. Se i concorrenti riescono a capire il tuo codice in chiaro (supponendo che sia qualcosa di più di qualche migliaio di righe …), non dovrebbero avere problemi a mascherarlo.

    Come posso gestire questi rischi (essere in grado di eseguire il debug del codice errato, garantendo / minimizzando gli errori di offuscamento)

    L’offuscamento causerà più bug, potrai gestirli spendendo il tempo necessario per eseguirne il debug. Dipende dalla persona che ha scritto l’offuscamento (si tratti di te o di qualcun altro), alla fine sarà solo perdere un sacco di tempo.

    Quali sono le tue esperienze nell’uso del codice offuscato in un ambiente di produzione?

    1. Essere completamente aggirato da attacchi ai canali laterali, attacchi di replay, ecc.
    2. Bugs.

    Il Compilatore di chiusura di Google offusca il tuo codice dopo aver finito di scriverlo. Cioè, scrivi il tuo codice, eseguilo attraverso il compilatore e pubblica il js ottimizzato (e offuscato).

    Devi stare attento se usi js esterni che si interfacciano con la lib anche perché cambia i nomi dei tuoi oggetti in modo da non sapere cosa sia cosa.

    L’offuscamento automatico del codice completo è finora disponibile solo nella modalità avanzata del compilatore di chiusura.

    Il codice compilato con la modalità di chiusura avanzata è quasi imansible da decodificare, anche passando attraverso un abbellitore, poiché l’intera base di codice (inclusa la libreria) viene offuscata. È anche il 25% in media.

    Il codice JavaScript che è semplicemente minified (YUI Compressor, Uglify ecc.) È facile da decodificare dopo essere passato attraverso un beautifier.

    Se si utilizza una libreria JavaScript, considerare Dojo Toolkit che è compatibile (dopo piccole modifiche) con la compilation in modalità avanzata del compilatore di Closure.

    http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

    È ansible adottare un modello di business open source e concedere in licenza i propri script con GPL o Creative Commons BY-NC-ND o simili

    Mentre l’offuscamento in generale è una brutta cosa, IMHO, con Javascript, la storia è un po ‘diversa. L’idea non è quella di offuscare lo stesso Javascript ma di produrre una lunghezza di codice più breve (la larghezza di banda è costosa e gli utenti che per la prima volta potrebbero essere incazzati aspettando il caricamento di Javascript per la prima volta). Inizialmente chiamato minification (con programmi come minify), si è evoluto un bel po ‘e ora è disponibile un compilatore completo, come il compilatore YUI e il compilatore Google Closure. Tale compilatore esegue il controllo statico (che è una buona cosa, ma solo se si seguono le regole del compilatore), minification (sostituire il nome di variabile lungo con ‘ab’ per esempio) e molte altre tecniche di ottimizzazione. Alla fine, ciò che ottieni è il meglio di entrambi i mondi, la codifica in codice non compilato e la distribuzione di codice compilato (, minificato e offuscato). Sfortunatamente, avresti bisogno di testarlo anche in modo più approfondito.

    La verità è offuscatore o no, qualsiasi programmatore che valga il suo sale potrebbe riprodurre qualunque cosa tu abbia fatto in circa il tempo che ti ci è voluto. Se hanno rubato quello che hai fatto, potresti denunciarlo. Quindi, dal punto di vista del business, dal punto di vista del business, hai la stessa quantità di tempo che hai impiegato per implementare il tuo progetto fino a quando un concorrente non raggiunge il traguardo. Periodo. Questo è tutto l’inizio che ottieni. Il resto sta innovando più velocemente dei concorrenti e lo commercializza almeno quanto loro.

    Scrivi il tuo sito web in flash, o meglio ancora in Silverlight. Ciò darà alla tua azienda una GUI ineguagliata, che i tuoi concorrenti saranno entusiasti. Ma la natura compilata di flash / dotnet non consentirà loro di scegliere facilmente il codice. È una situazione win / win per te;)