Protezione della paternità del codice MQL in MT5. - pagina 7
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
per esempio
Acquirente: trova informazioni su Internet, scrive di voler comprare
Venditore: Descrive il meccanismo di pagamento - se non vuoi dare i dettagli del pagamento, ti verrà chiesto di fornire le tue informazioni personalizzate.
l'acquirente: paga e invia i dati di personalizzazione, il numero di conto o il nome completo, che è la chiave
Venditore: invia la merce assegnata ai dati personali.
idealmente questo è tutto!
Ho tali casi, e non pochi
Purtroppo, questo non rende la vita più complicata ad alcuni scrocconi (persone che sono in argomento). Anche il legame a un conto non è la soluzione di tutti i problemi, qualsiasi "copiatore di transazioni" competente trasferirà tutti i dati a qualsiasi altro conto (specialmente se i dati sono copiati da MT5 a MT5).
A mio parere non solo gli esperti ma anche gli script, gli indicatori, le librerie e altro codice dovrebbero essere protetti. Secondo me, questo è un tema più interessante e importante.
Perché è più importante?
Come sappiamo, tutti gli strumenti che possono essere implementati utilizzando MQL si dividono in: sistemi automatici, sistemi semi-automatici e strumenti per il trading manuale.
C'è anche una divisione in sistemi: "scatole nere", "scatole grigie" e sistemi "bianchi" (sistemi con open source e logica esplicitamente descritta).
Così, quasi tutti gli MTS presentati nel settore commerciale saranno scatole nere o grigie. Il loro peso specifico non sarà così grande (penso che non supererà il 30-40%). Allo stesso tempo tali soluzioni saranno piuttosto inflessibili (perché implementano essenzialmente una sola strategia).
Script, librerie e indicatori separati sono un'altra cosa. Queste soluzioni software saranno presenti in tutte le aree del trading manuale e meccanico. Allo stesso tempo, potranno essere utilizzati come elementi di base del costruttore.
PS
Qui secondo me è necessario per massimizzare la protezione, e per non violare i diritti degli sviluppatori e degli utenti. L'unico modo ottimale di protezione in questo caso? Per come la vedo io, ce n'è solo uno: legarsi all'hardware.
Qualunque cosa si possa pensare, legarsi all'hardware non è più un metodo efficace di protezione. A proposito, per una persona che conosce a malapena Asmus (e ce ne sono molte di più) la rimozione di tale protezione è una questione di minuti. E non importa a cosa vi legherete. Leggete i forum di programmazione (leggi hacking) e tutto vi sarà chiaro. :) E per quanto riguarda la "buona organizzazione", provate per il gusto di sperimentare a legare una parte della vostra produzione di massa all'hardware e sono sicuro che dopo un po' (circa un mese o due) capirete quello che volevo dirvi.
Come se ci fossero altre opzioni di protezione?
Mi sorprende che tu me lo chieda. Certo che ci sono. E molti di loro. Dai semplici ricodificatori, ai generatori di licenze, ai metodi di protezione hardware-software come HASP, ecc. Ma quasi tutti, indipendentemente dal loro costo e dall'affidabilità dichiarata, sono stati craccati per molto tempo, e i codici di cracking, keygen e altri software girano per Internet in libero accesso. E oserei dire che questi metodi di protezione sono diversi ordini di grandezza più affidabili del semplice legame all'hardware.
Nel contesto di MT4/MT5 MQL4/MQL5 + DLL il binding può essere fatto non all'hardware, ma al numero di conto (numeri), per il nome reale e/o familiare, in alternativa il secondo nome
Questo modo è il più semplice in termini di sicurezza (per questa situazione specifica) - è mobile e non richiede il collegamento all'hardware.
Iniziando questo thread abbiamo avuto ('ognuno'!) il nostro certificato rilasciato da Metakwots. È chiaro che questa non è ancora un'autorità di certificazione ben riconosciuta. Ma questo argomento (emissione e mantenimento di certificati) si è arenato, anche se il 4 ha presumibilmente una tale capacità di autenticazione.
Quindi un vincolo all'hardware per la protezione dell'autore è, credo, un regresso "profondo".
L'idea (nelle prime pagine) era di implementare l'algoritmo di compilazione "normale" per il file ex5.
Il sogno è approssimativamente il seguente.
Il programmatore è in grado di compilare il suo programma in modo che possa essere percepito accuratamente dal terminale solo in presenza di una sottochiave di traccia - una concatenazione complessa della chiave dello sviluppatore e dell'utente.
Le firme necessarie della chiave dello sviluppatore starebbero nel programma così come la chiave dell'utente nel programma e nella chiave del terminale specifico.
Allora la presenza di questa "license-subkey" renderebbe possibile il suo utilizzo.
La generazione dovrebbe essere fatta dal Meta-editor, cioè lo sviluppatore stesso - avendo ricevuto una parte della chiave dal cliente.
Così è stato immaginato...
Ma qualcosa non esce dalla nebbia.
Mi sembra che la possibilità di generare la chiave dello sviluppatore dall'autorità di certificazione "МТ5" e la presenza nel terminale di procedure di decrittazione ex5 che utilizzano quella chiave e una parte della chiave dell'utente risolverebbe più problemi di quel "servizio nativo" - i cui meccanismi e la cui adeguatezza non possono essere discussi qui.
;)
Se parliamo di protezione delle chiavi, l'intera Internet sarà inondata proprio da queste chiavi. In altre parole, invece di protezione, sarà una finzione con un'implementazione complessa che costringe l'acquirente a gestire le chiavi.
Il modo migliore è guardare lo schema di vendita AppStore/iTunes di Apple che funziona. Il cliente semplicemente clicca e acquista il software senza il fastidio di dover trasferire o usare le chiavi. Un cliente deve solo avere un account MQL5.com per mantenere la sua storia di acquisti e riattivare i programmi precedentemente acquistati.
Quando si acquista un programma, l'utente riceve una copia appositamente ricompilata/riprotetta, che protegge il venditore molto meglio delle chiavi. L'intero processo di protezione personale sarà automatico al momento dell'acquisto.
Il nostro obiettivo è quello di rendere il processo di acquisto/vendita il più facile possibile.
Penso che ci sia un'altra caratteristica importante che manca in questo thread: il periodo di prova o le restrizioni della demo. I potenziali acquirenti vogliono giustamente vedere prima cosa stanno comprando. A tal fine, da qualche parte devono essere nascoste (criptate) le informazioni sulle date e/o il tempo durante il quale il prodotto acquistato funzionerà senza restrizioni. Mi sembra che incorporare un meccanismo di crittografia con un paio di chiavi (a la pgp) nel linguaggio stesso possa risolvere non solo questo ma molti altri problemi.
Ha senso vendere solo a un cliente che lavora su un conto reale (come se avesse / dovesse avere i mezzi per comprare). Questo numero (forse + qualche altra informazione come il nome del server, la frase chiave o altro) è usato come chiave per la decrittazione. Il fornitore dovrebbe avere un meccanismo integrato per generare coppie di chiavi e criptare i file con esse.
Cosa otteniamo? Lo sviluppatore crea un file con i dati iniziali: es. contenente il numero di conto e due date da e verso le quali lavora su questo conto. questo file è criptato. e viene dato insieme all'esperto/script/indicatore all'acquirente. La piattaforma riceve (e solo il cliente ha sul conto) la seconda chiave, legge e decripta il file criptato (è possibile controllare il checksum e non restituisce nulla se la chiave si è rivelata sbagliata) e lo dà come stringa all'Expert Advisor / Script / Indicatore.
Il codice stesso che riceve questi dati determinerà se funziona in modalità demo o normale. Può anche memorizzare i parametri del funzionamento dell'EA: ad esempio, l'incrocio di MAXX - l'algoritmo sarà evidente anche dopo la decompilazione, ma i parametri esatti con cui questi MAXX lavorano in profitto possono essere "segreti", e non ha senso decompilare un EA senza conoscere questi parametri. Certo, ci sono delle lacune e ci sarà qualcosa da compromettere, ma non conoscendo i dati in un file criptato (che non si può ottenere con Asm), tutto diventa molto più complicato che comprare semplicemente il prodotto e il suo supporto dall'autore.
In conclusione: bisogna fornire un contenitore criptato, e poi ognuno può metterci dentro i dati di cui ha bisogno e organizzare la protezione più sofisticata.
Signori, non dimenticate che questo è un mercato di massa.
Voi pensate che nelle categorie di lavoro 1:1, l'acquirente e il venditore negozieranno insieme, si scambieranno le offerte e si manderanno le chiavi a vicenda. Naturalmente, in questo modo non potrete vendere molto. Noi, invece, offriamo un negozio di vendita rapida dove il venditore non deve nemmeno alzare un dito per le vendite. E l'acquirente deve solo premere il pulsante "compra" e non preoccuparsi di nessun numero di conto o generazione di chiavi.
Tutto è già stato pensato. Se volete sapere come funziona, provate un iPhone/iPad, comprando un software per esso dall'AppStore.
A mio modesto parere, l'opzione di protezione legata all'hardware è ideale, sia in termini di implementazione che di facilità d'uso. C'è un altro desiderio su questa variante, ma ve ne parlerò di seguito.
Le opzioni di collegamento ai numeri di conto/nome del proprietario e altre non sono convenienti, anche se questo non è ovvio a prima vista. All'acquirente piace cambiare broker e aprire nuovi conti ogni settimana, quindi che dire della compilazione di un prodotto per lui ogni volta, e se ci sono decine o centinaia di utenti del prodotto? Le chiavi possono essere fuse in rete - non è nemmeno un'opzione.
Riguardo al legame con l'hardware. Un utente potrebbe voler lavorare con il prodotto su diversi computer e allora la possibilità di legarsi a diverse versioni hardware dovrebbe essere fornita. E se l'utente vorrà aggiornare l'hardware disponibile, allora forse in questi casi, dovrete dargli, diciamo, 1 ora durante la quale l'aggiornamento sarà eseguito. E così via. Dobbiamo pensare a questi punti. Legare il prodotto a una/due/tre macchine per l'eternità è sbagliato e ingiusto per il cliente.
Per quanto riguarda il legame con l'hardware. L'utente potrebbe voler utilizzare il prodotto su diverse macchine, quindi dovrebbe essere fornita la possibilità di legarsi a diverse opzioni hardware. E se l'utente vuole aggiornare l'hardware disponibile, allora forse in questi casi, si dovrebbe consentire, diciamo, 1 ora durante la quale l'utente passa al nuovo hardware. E così via. Dobbiamo pensare a questi punti. Legare un prodotto a una/due/tre macchine per sempre non è giusto e corretto nei confronti del cliente.
Ma allo stesso tempo, permetteremo di eseguire nel tester (agente tester) EA protetti, in modo che gli utenti possano verificare in modo indipendente le prestazioni dell'EA nel tester e non comprare un pig in a poke.
Ci sono EA che hanno la storia cucita dentro. O che sono in grado di leggere la storia dalla base della storia. Tali EA fittizi mostrano risultati notevoli nel tester. Ci sarà una protezione contro questo tipo di frode? Soprattutto se l'Expert Advisor viene consegnato insieme a una DLL.
Come combatterà il servizio per la sua reputazione in caso di MQL5-code + DLL dannose (da spyware a virus)?