Dovrei includere un metodo di autodistruzione alle mie applicazioni?

Di recente ho avuto un'esperienza negativa, in cui il cliente ha salvato la fattura, ma il mio intermediario ha già caricato il nostro software e il design sul server client. Il client si è rivelato un criminale noto e, naturalmente, ha cambiato tutte le possibili password del server.

Tuttavia, posso ancora accedere al pannello di amministrazione del CMS. Purtroppo si scopre che il mio software è molto sicuro .. Ho provato a SQL-injection, falsi il caricamento di immagini ecc. Ecc. Tuttavia, non posso hackerare il mio software .. Comunque, mi sto preparando a fare causa a questa persona, quindi non lo è il problema .. Sto solo pensando ora, che forse dovrebbe esserci un metodo di autodistruzione di backend. Quindi, se si verifica un caso simile, ho la possibilità di uccidere il software.

La mia idea è quella di nascondere alcune funzioni nei file core. Codificalo con base64, quindi non sarebbe ovvio. Quindi qualcosa del genere:

eval(base64_decode('ZWNobyAnSGVsbG8gd29ybGQhJzs=')); // echo 'Hello world!';

E fondamentalmente crea un piccolo script, che prende tutti i file del software, chmod è sicuro e poi li elimina.
Le mie versioni più recenti del CMS dispongono tutte di file manager che potrei usare per facilitare l' hacking . Ma cosa succede se l'accesso al pannello di amministrazione è limitato.

Per essere molto chiari , questo è pensato solo per i software in fase di sviluppo, nel mio server personale o nel server client (l'ultima parte è eticamente discutibile.) Quindi se il mio client dovesse rubare il mio software .. Questo non sarà incluso in uno spot -Software.
E per essere ancora più chiari , stiamo parlando di quei rari lavori freelance. Penso che sia abbastanza logico, che il lavoro a contratto non abbia bisogno di tali metodi. Quindi stiamo parlando di quei client jumprisk, solo in modalità di sviluppo - quando il progetto è pronto, ovviamente questa sarebbe una backdoor molto non etica da avere all'interno del tuo software.

1. Eticamente è una buona idea? (Tenendo presente che ovviamente lo rimuoverò, quando il progetto sarà stato al 100% e tutto sarà pagato)
2. Avete mai dovuto hackerare il vostro software, a causa di problemi simili con i client?
3. Qualche consiglio su questa idea, codice e metodo saggio?
4. Quali possono essere i possibili inconvenienti o ripercussioni degli script di autodistruzione?

La mia conclusione su questo

È un po 'triste che tutte le risposte siano state mirate sui casi contrattati. In realtà è stata colpa mia, non ho chiarito meglio la mia domanda ... ho solo pensato, è abbastanza chiaro, che non c'è motivo nel kill switch ... quando sei protetto dal contratto.
Tuttavia, se stai eseguendo un contratto di lavoro ... questo dovrebbe essere indicato nel contratto - questo lo rende legale, anche all'interno del server del cliente. Tuttavia, avere kill-switch all'interno del mio server personale è davvero un affare di nessuno (questo è quello che volevo davvero sapere.)

Ho deciso di creare lo script kill switch per il mio CMS. Principalmente, perché sembra una sfida interessante. Ma anche che potrei usarlo per i miei lavori senza contratto in cui il client è amico di un amico di un amico .. Probabilmente non lo userò sul server client, ma ... per i casi, in cui il client o alcuni gli intermediari hanno accesso al mio server .. E il mio software viene rubato o "spostato a mia insaputa", quindi non vengo pagato e tagliano l'accesso al software.

Ho letto molti argomenti qui, in cui raccomandano di inviare un avviso e quindi di chiudere la pagina. Bene, ho visto un problema in esso, come quando ho a che fare con una persona ... che lo copierà altrove (forse lo cambierà di nuovo e lo venderà) e mi dice che è stato rimosso. Inoltre, non "spegnerei il sito", ma lo eliminerei. Tuttavia, immagino che sia ancora illegale accedere al mio server client ed eliminarlo. O almeno, accedervi tramite backend e non dall'FTP. Per questo ringrazio tutti voi, che avete risposto.

Non sono un avvocato. Sembra che tu ne abbia già uno allo scopo di citare in giudizio il tuo cliente; mentre tu lo hai in custodia, consiglierei di ottenere i loro consigli su questo.

Ci sono alcune altre domande su questo sito che riguardano "kill switch" e altri modi per disabilitare il software per il quale lo sviluppatore non ha ricevuto un compenso. Di solito è considerata una cattiva idea semplicemente inserirne uno nel software "chiavi in ​​mano" (dove lo svilupperai e poi trasferirai i diritti completi al cliente), senza che il contratto abbia stabilito questa possibilità.

Prima di tutto, se il contratto non prevede specificamente che è possibile disabilitare il software per mancato pagamento o che il cliente non ha alcun diritto sul software fino a quando il pagamento non viene ricevuto per intero, non è possibile attivare alcun "kill switch" senza essere in violazione del contratto. In assenza di parole contrarie, "il possesso è nove decimi della legge", quindi è il suo software una volta che gli viene dato il possesso, e distruggerlo sarebbe come dinamizzare un nuovo edificio per uffici che avresti costruito per lui se non lo avesse fatto non pagare per questo.

Segue il secondo punto; qualsiasi contratto che offri a qualsiasi cliente dovrebbe avere una clausola relativa all'effetto di: "Trasferimenti di proprietà intellettuale sulla soddisfazione del contratto" . Ciò significa che anche se gli hai dato una copia del software da utilizzare, fino a quando non ti avrà pagato per intero, non lo possiede. Questo DOVREBBE darti il ​​diritto di disabilitare la sua o qualsiasi copia del software per qualsiasi motivo fino a quando il pagamento completo è stato ricevuto, perché è ancora tuo e puoi fare come ti pare. Ora, ha violato il contratto e tu non l'hai fatto, quindi il caso è MOLTO più facile da presentare per il tuo avvocato, e nel frattempo il tuo cliente non ottiene alcun beneficio dai suoi beni malefatti.

L'analogia con un imprenditore edile vale: una volta che un edificio in costruzione è in grado di essere protetto contro l'ingresso illecito, lo è, e l'appaltatore in genere manterrà tutte le copie di tutte le chiavi dei locali fino a quando il lavoro non sarà completo e firmato, e pagamento ricevuto per intero. Anche dopo che le chiavi sono state consegnate, se il pagamento fallisce, può attaccare un privilegio sulla proprietà e, all'estremo, farlo rientrare in possesso. Lo stesso vale qui; potresti fornire al cliente una chiave per accedere al software, ma tieni premuto il tasto "master" e non ottiene l'accesso amministrativo fino a quando non sei pagato per intero. Se può entrare ora e non ti paga, puoi semplicemente "cambiare i lucchetti" e bloccarlo fuori dal software.

Tuttavia, hai dato al tuo client la chiave "master" del software, e lui è andato e ha cambiato tutti i blocchi, quindi ora NON puoi entrare. Non è così che dovrebbe funzionare. Puoi ancora richiedere il risarcimento dei danni, ma nel frattempo il tuo cliente storto può usare il software, copiarlo altrove (è una grande cosa che non può succedere a un appaltatore; se riprende il suo edificio non deve preoccuparsi che tu hai fatto una copia gratuita esatta su un altro lotto), ecc. Fondamentalmente, il tuo unico rimedio è di applicare il pagamento per intero, perché non puoi garantire di aver recuperato tutte le copie del software. Probabilmente non saresti felice di riavere il tuo software anche se potessi garantire che non avesse altre copie; è probabilmente un lavoro personalizzato che non puoi semplicemente girare e vendere a qualcun altro.

Comprendi che, indipendentemente dai tuoi diritti sul software, i suoi dati appartengono a lui. Non puoi toccarlo. Puoi interrompere il suo accesso al software che hai creato, ma se distruggi i suoi dati, è come bruciare i suoi averi dopo aver riposizionato l'edificio che hai costruito per cui non ha pagato. Non hai alcun diritto su tali dati e devi lasciarli sul posto sul loro computer intatti o se i dati non sono accessibili in modo ragionevole senza il tuo software, devi rimuoverli dall'entanglement con il tuo software e darli a lui in un formato utilizzabile (come un database di consumo umano o copie stampate o elettroniche).

Nel concetto hai ragione. La tua esecuzione è tutta sbagliata.

Devi fornirgli le licenze di prova che scadono. Dopo il pagamento completo dargli la licenza "per sempre" finale. Tutto in anticipo e onesto.

No. Se i tuoi clienti lo scoprissero verrai linciato. Non è affatto sicuro. Qualcuno, alcuni scopriranno come attivarlo e poi all'improvviso hai il compito di contattare tutti i tuoi clienti per parlarne e perché devono fare una patch di emergenza.

Se lo fai, ti stai anche aprendo a procedimenti penali. Presumo che tu abbia la prova di possedere ancora il sito? Che hai il diritto di accedervi? Il costo per la sua attività potrebbe essere "astronomico"

Ci sono alternative accettabili. Inserisci una filigrana sul sito, in modo che ogni pagina visualizzi un messaggio. A pagamento è possibile rimuovere la filigrana.

Sembra una pessima idea che potrebbe farti finire in prigione.

1. Non è etico. Il cattivo comportamento del tuo cliente non ti rende giusto hackerare il suo sistema.
2. È illegale. Ciò è accaduto in precedenza , con risultati negativi per le parti colpevoli.
3. È inutile. Cosa potresti fare con questa backdoor che non ti metterebbe nei guai? Ricatteresti il ​​cliente?
4. È stupido Anche se tu potessi farlo senza essere scoperto, i potenziali rischi superano di gran lunga qualsiasi possibile guadagno.

Per favore, non chiedere ai programmatori, chiedi a un avvocato. Immagino almeno che tu voglia includere una clausola nel tuo contratto dicendo che hai il diritto di fare ciò che la tua domanda prevede di fare. (La clausola "danno irreparabile" di alcuni contratti non ti consente di ottenere un ordine del tribunale per chiudere immediatamente il software fino a quando il tribunale non ha la possibilità di risolverlo?) Penso che un ordine del tribunale sarebbe molto più sicuro per te di un bomba a codice (che potrebbe essere considerata criminale, se un tribunale avesse scoperto che non possedevi il software potrebbe essere una distruzione di proprietà, negli Stati Uniti potrebbe rientrare nelle sezioni di crittografia digitale del Digital Millennium Act, ecc. immaginare di ottenere un risarcimento in tribunale civile e di essere ancora condannato in tribunale penale).

Le regole varieranno a seconda di dove tu e il tuo cliente vivete e operate, quindi penso davvero che vorreste un avvocato.

Eticamente è una buona idea?

Assolutamente no. Non solo ti fa sembrare poco professionale nei confronti di clienti onesti e onesti, ma ritengo che sia anche dannoso per la professione nel suo insieme. Gli ingegneri del software hanno delle responsabilità nei confronti del loro cliente o datore di lavoro, compresa la consegna di software di altissima qualità. In caso di controversie su pagamenti o contratti, esistono canali appropriati. Ridurre la qualità del tuo software non è un canale appropriato.

Avete mai dovuto hackerare il vostro software, a causa di problemi simili con i client?

Mai, anche se non ho mai svolto un lavoro a contratto o freelance. Sono sempre stato un dipendente di un'organizzazione più grande (che, in alcuni casi, lavorava con un contratto). Per me il pensiero è impensabile. Preferirei distribuire software di cui sono orgoglioso di avere il mio nome attribuito e di essere ingannato da una piccola percentuale di clienti piuttosto che ridurre la qualità del mio software e le mie responsabilità etiche nei confronti degli utenti del sistema.

Qualche consiglio su questa idea, codice e metodo saggio?

Non farlo

Quali possono essere i possibili inconvenienti o ripercussioni degli script di autodistruzione?

Oltre alle ovvie questioni etiche, sarei preoccupato per i problemi legali. Non sono sicuro che sabotare il tuo lavoro sia legale e, anche se lo è, usare un tale exploit potrebbe non esserlo.

Basta implementare un modulo di licenza con licenze a tempo limitato che disabiliterà il software alla scadenza. Questa è una pratica ben nota nel settore del software e i vostri clienti non dovrebbero opporvisi, poiché in seguito rimuoverete la limitazione.

Ciò potrebbe rivelarsi utile quando si desidera limitare le funzionalità e offrire diverse versioni del prodotto.

Gli interruttori di uccisione hanno semplicemente troppi rischi e non ne valgono la pena.

Una caratteristica segreta di autodistruzione è un'idea orrenda . Sì, sarai intelligente e potresti avere l'opportunità di attaccarlo a un terribile cliente in futuro, ma è sicuramente più un problema che un valore.

1. Non sarai ancora pagato per il lavoro svolto. Sì, l'altra persona non utilizzerà il tuo codice; ma soffrirai comunque della mancanza di pagamento. Pensi che alcuni criminali decideranno di pagare una persona che ha già abbattuto il loro sito una volta da remoto? Troveranno un nuovo chump per rendere il loro sito gratuitamente.

2. Utilizzando la sequenza di autodistruzione, ti rende responsabile per i tuoi problemi legali. A seconda delle giurisdizioni, potresti facilmente essere visto come un hacker / distruzione dei loro dati (quando stavano per pagare e avevano molte circostanze attenuanti per il motivo per cui non avevano pagato prima). Anche se non sei stato condannato / citato in giudizio con successo, potresti comunque sostenere pesanti spese legali e avere molti più problemi del suo valore.

3. Che cosa succede se un buon client pagante naviga il tuo codice in un secondo momento (o ha un amico CS che lo ha appena sfogliato per fare una piccola modifica), vede la funzione con una strana parte base64, è come questo, prova a eseguirlo e cancella accidentalmente l'app Web (e lo fa mentre sei in vacanza, quindi ci vuole un po 'di tempo per risolvere)? O pubblica un sacco di recensioni pubbliche su di te in tutto il mondo dichiarando di non essere etico e di lasciare backdoor nel tuo lavoro? Sicuramente potresti rimuoverlo dal prodotto finito dopo che hanno pagato, ma con VCS possono sfogliare la fonte più vecchia o non volerti sul loro server dopo aver pagato (e sarebbe una conversazione imbarazzante; sì, ho bisogno di un nuovo account, perché non ho rimosso la backdoor segreta che si autodistrugge).

4. Cosa succede se il criminale esegue il backup dei propri dati? Eliminate il loro server web con una backdoor segreta, il sito è offline per un giorno o due mentre loro (o un amico) trovano la funzione offensiva backdoor e la sua back online.

In futuro, fai in modo che le persone firmino un semplice contratto, ti paghino per fasi e non lasciare che il codice lasci il server di sviluppo e il computer che controlli solo fino a quando non sei stato pagato. (Se ne hanno bisogno per essere attivo prima che tutto il lavoro sia finito, assicurati di aver pagato all'incirca la frazione di codice che sta diventando attivo). Se vogliono vedere il lavoro come in fase di sviluppo, fagli dare alcuni indirizzi IP che aprirai il firewall per il tuo server di sviluppo (e forse con un CNAME intelligente per l'effetto diunpaid_work_in_development.example.com). Non dare alcuna garanzia di uptime del tuo server di sviluppo, e se stai ricevendo molto più traffico di quanto dovresti essere (ad esempio, scopri che stanno reindirizzando molte persone al tuo sito) chiudi il firewall fino a quando non pagano. Se hanno bisogno di contribuire con il contenuto al tuo server web, fagli inviare un'email con i suggerimenti sul contenuto o crea una cartella condivisa dropbox per loro che ha solo le autorizzazioni per scrivere nel piccolo sottoinsieme di file (sotto il controllo VCS al di fuori del dropbox) che loro può contribuire in modo significativo a (ad esempio, i modelli HTML).

Hai fatto la domanda sbagliata. La cosa su cui lavorare e migliorare non è aggiungere una sorta di kill switch remoto (aggiungendo una vulnerabilità che tu o qualcun altro puoi usare), ma per risolvere il tuo vero problema, che era un modo scarso di organizzare il pagamento e la consegna. Sembra che tu abbia bisogno di un migliore sistema di deposito a garanzia (o come si chiama un tale concetto dove vivi).

Non sprecare il tuo tempo con un kill-switch, scopri dove hai fatto una cazzata nell'affare.

Penso che inventerei una sorta di meccanismo di licenza. Questo potrebbe essere basato su un numero qualsiasi di idee commerciali o fatte in casa e potrebbe causare l'interruzione del funzionamento del software dopo la scadenza della licenza. Nel momento in cui il sistema viene accettato dal cliente e hanno pagato, è possibile fornire una licenza completa che non scade.

Questo approccio richiede anche l'approvazione di un avvocato nel tuo territorio, ma ha il vantaggio di non dover disabilitare in remoto il software e puoi stipulare che questo fa parte del sistema in anticipo. Tuttavia mi sembra molto triste che tu abbia a che fare con persone che si rifiutano di pagare in primo luogo.

Non si chiama DRM? Finché rimuovi la "bomba" dopo aver ricevuto il pagamento non vedo alcun problema legale con esso. Assicurati solo di avere una patch prontamente disponibile per coprire il culo e dimostrare che non hai avuto intenzioni dannose.

Mi ricorda la disposizione sulla "pillola del veleno" nell'atto costitutivo di alcune società che viene attivata in caso di acquisizione ostile.

Vale a dire, la mentalità espressa da alcuni degli altri poster qui mi ricorda perché alcuni programmatori vengono calpestati continuamente. Se più persone inserissero tali bombe nel loro codice, penso che i programmatori potrebbero essere pagati più rapidamente ... Non avrei assolutamente alcun problema se questa fosse la norma. Alla gente piace rubare il duro lavoro degli altri. Periodo. E se Apple, et al. riescono a fare DRM all'infinito, quindi penso che anche i programmatori freelance possano ...

In pratica, sicuramente il client controllerebbe i propri registri, troverebbe la richiesta di kill, ripristinerebbe il codice da un backup, rimuoverà il kill switch e la ridistribuirà.

I dettagli della tua domanda chiariscono che questa sarebbe un'idea assolutamente orribile. Il primo client a scoprire un tale kill switch (possibilmente dopo averlo usato e si sono ripristinati da un backup) avrebbe pubblicato il kill switch e il fatto che lo avevi incluso nel codice che gli hai consegnato. La tua reputazione verrebbe quindi completamente distrutta.

E prima che tu dica "beh, sarebbero un punto morto, come distruggeranno la mia reputazione?" Prendi in considerazione uno scenario come questo: il cliente è in regola, ma uno dei suoi dipendenti prende una copia del codice. Sparano a quell'impiegato, guarda il codice, capisce il kill switch e lo usa. Indovina chi ha la colpa? (Suggerimento: sei tu.)