Devo incluir um método de autodestruição em meus aplicativos?


39

Recentemente, tive uma experiência negativa, na qual o cliente pagou a conta, mas meu intermediário já carregou nosso software e design no servidor do cliente. O cliente acabou sendo um criminoso conhecido e, é claro, ele alterou todas as senhas possíveis do servidor.

No entanto, ainda posso acessar o painel de administração do CMS. Infelizmente, meu software é muito seguro. Tentei injetar SQL, falsifique o upload de imagens etc. etc. No entanto, não consigo invadir meu próprio software. De qualquer forma, estou me preparando para processar essa pessoa, para que não seja o problema .. Estou apenas pensando agora, que talvez deva haver algum método de autodestruição de back-end. Portanto, se ocorrer um caso semelhante, tenho a opção de matar o software.

Minha própria idéia é ocultar alguma função nos arquivos principais. Codifique-o com base64, para que não seja óbvio. Então, algo como isto:

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

E basicamente faça um pequeno script, que pegue todos os arquivos do software, o chmod os tenha certeza e os exclua.
Minhas versões mais recentes do CMS, todas possuem gerenciadores de arquivos que eu poderia usar para facilitar a invasão . Mas e se o acesso ao painel de administração for limitado.

Para ser bem claro , isso é apenas para os softwares em estágio de desenvolvimento, no meu servidor pessoal ou no servidor do cliente (a última parte é eticamente questionável). Portanto, se meu cliente deve roubar meu software ... Isso não será incluído em um comercial -Programas.
E para ser ainda mais claro , estamos falando sobre esses raros trabalhos freelancers. Eu acho que é bastante lógico, que o contrato de trabalho não precise de tais métodos. Portanto, estamos falando desses clientes jumprisk, apenas no modo de desenvolvimento - quando o projeto estiver pronto, então obviamente isso seria um backdoor muito antiético para ter dentro do seu software.

  1. Ética, isso é uma boa ideia? (Lembre-se de que, obviamente, eu o removerei, quando o projeto estiver 100% e tudo estiver pago)
  2. Vocês já tiveram que invadir seu próprio software, devido a problemas semelhantes com o (s) cliente (s)?
  3. Alguma recomendação sobre essa idéia, código e método?
  4. Quais podem ser as possíveis desvantagens ou repercussões dos scripts de autodestruição?

Minha conclusão sobre isso

É um pouco triste que todas as respostas tenham sido direcionadas aos casos contratados. Foi minha culpa, na verdade, que eu não deixei isso mais claro na minha pergunta .. apenas pensei, que é bastante claro, que não há sentido em matar o interruptor .. quando você está protegido pelo contrato.
No entanto, se você estiver executando um contrato, isso deve ser declarado no contrato - isso o torna legal, mesmo dentro do próprio servidor do cliente. No entanto, ter interruptores de interrupção dentro do meu servidor pessoal não é da conta de ninguém (é isso que eu realmente queria saber).

Eu decidi fazer o script kill-switch para o meu CMS. Principalmente, porque parece um desafio interessante. Mas também, que eu poderia usar isso para meus trabalhos não contratados, onde o cliente é amigo de um amigo de um amigo. Provavelmente, não o utilizarei no servidor do cliente, mas ... nos casos em que o cliente ou algum intermediários têm acesso ao meu servidor .. E meu software é roubado ou "movido sem o meu conhecimento", então eu não sou pago e eles cortam o acesso ao software.

Eu li vários tópicos aqui, onde eles recomendam enviar um aviso e depois derrubar a página. Bem, eu vi um problema nele, como quando estou lidando com uma pessoa ... que simplesmente copia para outro lugar (talvez renomeie e venda) e me diga que foi retirado. Além disso, eu não "desligaria o site", mas o excluiria. No entanto, acho que ainda é ilegal acessar o servidor dos meus clientes e excluí-lo. Ou pelo menos, acesse-o através do back-end e não a partir do FTP. Por isso, agradeço a todos que responderam.


26
Seus esforços seriam melhor gastos com a devida diligência em seus clientes!
Steven A. Lowe

14
Deixar não apenas uma vulnerabilidade de segurança conhecida, mas deliberada, no seu código não é apenas não profissional, mas deve deixá-lo aberto a riscos legais.
Kevin D

2
portas traseiras e bombas presumivelmente não fazem parte da especificação do produto; dependendo das leis de responsabilidade e contrato do seu país / estado, isso pode constituir uma quebra de contrato
Steven A. Lowe

11
Eu vejo isso e penso imediatamente: Talvez eu precise mais tarde .
Mason Wheeler

3
@ KalleH.Väravas Freeland work! = Trabalho sem contrato. Significa "alguém que trabalha por conta própria e não está comprometido com um determinado empregador a longo prazo". Fazendo o trabalho sem contrato é quase sempre vista como uma idéia muito ruim, para a razão exata que você está fazendo esta pergunta (cliente foge sem pagar para o trabalho)
thedaian

Respostas:


38

Eu não sou advogado. Parece que você já tem um com o objetivo de processar seu cliente; enquanto você o tiver em contato, eu recomendaria obter seus conselhos sobre isso.

Existem outras perguntas neste site que tratam de "interruptores de interrupção" e outras maneiras de desativar o software pelo qual o desenvolvedor não recebeu compensação. Geralmente, é uma má idéia simplesmente criar um software "chave na mão" (onde você o desenvolverá e depois transferirá todos os direitos para o cliente), sem que o contrato estipule essa possibilidade.

Primeiro, se o seu contrato não indicar especificamente que você pode desativar o software por falta de pagamento ou que o cliente não tem direitos sobre o software até que o pagamento seja recebido integralmente, não será possível ativar nenhum "interruptor de interrupção" sem violar contrato. Na ausência de palavras em contrário, "posse é nove décimos da lei", então é o software dele assim que ele recebe a posse e destruí-lo seria como dinamizar um novo prédio de escritórios que você construiu para ele se não o fizesse. pague por isso.

O segundo ponto segue; qualquer contrato que você ofereça a qualquer cliente deve ter uma cláusula no sentido de: "Transferências de propriedade intelectual na satisfação do contrato" . Isso significa que, mesmo que você tenha fornecido a ele uma cópia do software a ser usado, até que ele pague integralmente, ele não será o proprietário. Isso daria a você o direito de desativar a cópia dele ou de qualquer software por qualquer motivo, até que o pagamento integral seja recebido, porque ainda é seu e você pode fazer o que quiser. Agora, ele violou o contrato, e você não o fez, então o caso é MUITO mais fácil para o seu advogado apresentar e, enquanto isso, seu cliente não obtém nenhum benefício com os bens ilícitos dele.

A analogia com um empreiteiro de construção é válida: uma vez que um prédio em construção possa ser protegido contra entradas ilegais, é, e o contratante geralmente manterá todas as cópias de todas as chaves das instalações até que o trabalho seja concluído e assinado e pagamento recebido integralmente. Mesmo depois que as chaves são entregues, se o pagamento cair, ele pode anexar uma garantia sobre a propriedade e, no extremo, recuperá-la. O mesmo vale aqui; você pode fornecer ao cliente uma chave para entrar no software, mas você mantém a chave "principal" e ele não obtém acesso administrativo até que você seja pago integralmente. Se ele puder entrar agora e não pagar, basta "mudar as fechaduras" e trancá-lo para fora do software.

No entanto, você deu ao seu cliente a chave "mestre" do software, e ele foi embora e alterou todos os bloqueios, agora você NÃO pode entrar. Não é assim que deve funcionar. Você ainda pode reivindicar danos, mas, enquanto isso, seu cliente corrupto pode usar o software, copie-o em outro lugar (isso é algo importante que não pode acontecer com um empreiteiro; se ele retomar o prédio, não precisará se preocupar que você fiz uma cópia gratuita exata em outro lote), etc. etc. Basicamente, seu único remédio é aplicar o pagamento integralmente, porque você não pode garantir que recuperou todas as cópias do software. Você provavelmente não ficaria feliz em recuperar seu software, mesmo se pudesse garantir que ele não tinha mais cópias; provavelmente é um trabalho personalizado que você não pode simplesmente virar e vender para outra pessoa.

Entenda que, independentemente dos seus direitos sobre o software, os dados dele pertencem a ele. Você não pode tocá-lo. Você pode interromper o acesso dele ao software que você construiu, mas se você destruir os dados dele, é como queimar seus pertences depois de reposicionar o prédio que você construiu para o qual ele não pagou. Você não tem direito a esses dados e deve deixá-los intactos no computador dele ou, se os dados não puderem ser acessados ​​de maneira razoável sem o seu software, remova-os do emaranhado do seu software e dê-os a ele em um formato utilizável (como um banco de dados de consumo humano ou cópias impressas ou eletrônicas).


3
Resposta impressionante! Obrigado. Eu concordo com você 100%, exceto que esta pergunta foi direcionada para trabalhos freelancers em mente, desculpe, provavelmente não deixei claro na pergunta. Eu nunca usaria esses métodos com contrato de trabalho, é apenas senso comum e também a pergunta seria por que ... desde que eu seja legalmente coberta de qualquer maneira. No entanto, eu estou falando sobre quando você tem um contrato oral com um cara .. que quer um carro .. e você constrói para ele. Então ele quer vê-lo enquanto você o faz ... e vai embora. Então, no modo de desenvolvimento .. não seria mais fácil ter um interruptor de interrupção .. que corta a ignição ?!
Kalle H. Väravas

11
É por isso que você NUNCA realiza trabalhos de desenvolvimento para alguém que não está empregando você, envolvendo tempo ou recursos significativos, sem contrato por escrito. Ainda é um trabalho "freelancer", já que você está se representando como um contratado independente, mas o contrato permite que você e seu cliente cubram as costas deles. Ele afirma o que os dois lados fornecerão para o outro (não apenas produto e dinheiro, mas recursos como espaço de escritório e computadores), e o que acontecerá se nada disso ocorrer como acordado.
KeithS 19/09/11

Concordo, recebi minha lição. Bem, em teoria, está correto, mas foi uma daquelas raras combinações de diferentes variáveis. Amigo de um amigo, que queria barato (1000 €), o meu CMS pessoal com design personalizado. Eu acho que é mais claro como a comunidade de programadores se sente sobre isso. Obrigado por sua resposta, ele ainda estava mais focado nos casos contratados, mas deixou a imaginação para os empregos não contratados.
Kalle H. Väravas

Resposta fabulosa.
Teekin

21

No conceito, você está certo. Sua execução está toda errada.

Você precisa fornecer licenças de teste que expiram. Após o pagamento integral, conceda a ele a licença Final "para sempre". Tudo aberto e honesto.


ideia muito melhor.
Tipo anônimo

De fato, a primeira resposta que não discute sobre "por que você não contrai" ou "o uso unlink()é ilegal". Na verdade, eu realmente gosto da sua ideia, posso cozinhar algo no CRON.
Kalle H. Väravas

@ Kalle: Ninguém disse que "o uso unlinké ilegal". O que as pessoas estão tentando entender é que os EUA, pelo menos, têm leis muito amplas sobre "uso não autorizado de sistemas de computador"; pela letra da lei, é crime para a maioria de nós postar respostas aqui usando computadores de trabalho. A menos que você tenha um contrato que lhe conceda o direito de fazê-lo, desabilitar remotamente o software em execução em um computador que você não possui quase certamente violaria esta lei. Se o software que você desabilitou foi roubado ou não, provavelmente não é relevante quando a cobrança é pelo uso não autorizado do sistema em que está sendo executado.
Dave Sherohman

@Dave. Eu entendo o seu ponto, mas se você pensar sobre isso. Se não houver contrato, os termos e o que não são não estão definidos. Então, o programa é um buraco como está. Portanto, se o kill-switch estava dentro do código quando o software foi movido / roubado / entregue .. então, usar essa função do kill-switch (basicamente unlik ()) faz parte do objetivo dos softwares. Conversei com meu advogado , e ele ressaltou que invadir o software seria ilegal (usar o gerenciador de arquivos para fazer upload do script de desassociação, por exemplo). Mas se a opção de interrupção for incluída no código, como parte do software, será perfeitamente legal.
Kalle H. Väravas

19

Não. Se seus clientes descobrissem que você seria linchado. Não é nada seguro. Alguém, de alguma maneira, descobrirá como acioná-lo e, de repente, você terá a tarefa de entrar em contato com todos os seus clientes para contar sobre isso e por que eles precisam fazer um patch de emergência.

Se você o invadir, também estará se abrindo para um processo criminal. Presumo que você tenha provas de que ainda é o proprietário do site? Que você tem o direito de acessá-lo? O custo para seus negócios pode ser "astronômico"

Existem alternativas aceitáveis. Coloque uma marca d'água no site, para que cada página exiba uma mensagem. No pagamento, você pode remover a marca d'água.


Entendo. Eu entendi o seu ponto. Para constar, o kill-switch seria incluído no software não comercial e, principalmente, apenas dentro do meu próprio servidor ou, pelo menos, apenas no modo de desenvolvimento. Alguns clientes exigem que o desenvolvimento seja realizado em seus próprios servidores e isso me deixa em uma situação muito vulnerável. Atualmente, todos os arquivos são creditados, os projetos são marcados com marca d'água, meu nome é TODA PARTE - sinto-me bastante confiante de que vencerei a ação .. Acho que ter interruptores de interrupção no meu próprio servidor ainda seria uma boa ideia, caso alguém rouba-os.
Kalle H. Väravas

17

Parece uma idéia fenomenalmente ruim que pode levá-lo à prisão.

  1. É antiético. O mau comportamento do seu cliente não torna correto invadir o sistema dele.
  2. É ilegal. Isso já aconteceu antes , com maus resultados para as partes infratoras.
  3. É inútil. O que você faria com essa porta dos fundos que não causaria problemas? Você chantagearia o cliente?
  4. Isso é idiota. Mesmo se você pudesse fazer isso sem ser pego, os riscos potenciais superam qualquer ganho possível.

1
Sinto muito, mas sua resposta está faltando a parte PORQUE. Por que é uma má idéia e com base no que eu poderia ir para a cadeia? Você pode explicar um pouco mais?
Kalle H. Väravas

3
Por mais que eu concorde com o sentimento, @Kalle está certo. Por favor incldue uma razão. -1
Steven Evers

3
Você está dizendo que um interruptor de interrupção é ilegal? Se o contrato estipular que o serviço será suspenso devido a circunstâncias especificadas, pode não ser ilegal.
FrustratedWithFormsDesigner

Depende dos padrões legais de onde você faz negócios, mas, em geral, os sistemas legais punirão severamente os esforços para resolver o problema por conta própria. Eles realmente querem que você passe pelo sistema judicial. Em algumas jurisdições, simplesmente acessar um sistema de computador sem permissão é crime passível de pena de prisão. Você pode argumentar que é o seu software, mas os tribunais dirão que é para eles decidirem, não você.
Charles E. Grant,

O método kill-switch surgiu no trabalho freelance. Desculpe, esqueci de mencionar isso na minha pergunta. Eu nunca usaria esses métodos em um contrato de trabalho. As questões legais aqui (Estônia) estão em etapas precárias quando se trata de leis de direitos autorais. Temos leis de direitos autorais semelhantes, mas não as mesmas, como a Suécia e a Finlândia. Pessoalmente, nunca tive problemas com clientes antes. Alguns atrasam os pagamentos, etc., mas um bandido de verdade, que rouba seu software - isso é novo no meu livro.
Kalle H. Väravas

12

Por favor, não pergunte aos programadores, pergunte a um advogado. Eu imagino que pelo menos você gostaria de incluir uma cláusula no seu contrato dizendo que você tem o direito de fazer o que sua pergunta considera fazer. (A cláusula de "dano irreparável" de alguns contratos não permite que você obtenha uma ordem judicial para desligar o software imediatamente até que o tribunal tenha uma chance de resolver o problema?) Acho que uma ordem judicial seria muito mais segura para você do que uma código-bomba (que poderia ser considerado criminoso, se um tribunal considerasse que você não era o proprietário do software, isso poderia ser a destruição de propriedades, nos EUA, poderia estar nas seções de quebra de criptografia digital da Lei Digital do Milênio, etc. imagine ganhar indenização em tribunal civil e ainda ser condenado em tribunal criminal).

As regras variam dependendo de onde você e seu cliente moram e operam, então eu realmente acho que você gostaria de um advogado.


Bem, o interruptor de interrupção foi direcionado principalmente ao trabalho freelance. Com um contrato é muito mais fácil. Atualmente, o caso é basicamente o seguinte: Meu software, sem meu conhecimento, foi removido do meu servidor e é isso. Por outro lado, é um caso muito claro de roubo - portanto, do ponto de vista jurídico, não estou preocupado. Portanto, o interruptor de interrupção estaria principalmente no meu próprio servidor, quando meu software seria roubado. No entanto, estou começando a achar que ainda é uma má ideia. Obrigado pela sua resposta, vou me encontrar com meu advogado em alguns dias.
Kalle H. Väravas

5

Ética, isso é uma boa ideia?

Absolutamente não. Não apenas faz você parecer pouco profissional para clientes honestos e honestos, mas também acho que isso é prejudicial para a profissão como um todo. Os engenheiros de software têm responsabilidades com seus clientes ou empregadores, incluindo o fornecimento de software da mais alta qualidade. Se houver uma disputa sobre pagamentos ou contratos, existem canais apropriados. Reduzir a qualidade do seu software não é um canal apropriado.

Vocês já tiveram que invadir seu próprio software, devido a problemas semelhantes com o (s) cliente (s)?

Nunca, embora nunca tenha feito contrato ou trabalho freelance. Eu sempre fui funcionário de uma organização maior (que, em alguns casos, trabalhava sob contrato). Para mim, o pensamento é impensável. Prefiro entregar software que me orgulho de ter meu nome atribuído e ser enganado por uma pequena porcentagem de clientes do que reduzir a qualidade do meu software, bem como minhas responsabilidades éticas para os usuários do sistema.

Alguma recomendação sobre essa idéia, código e método?

Não faça isso.

Quais podem ser as possíveis desvantagens ou repercussões dos scripts de autodestruição?

Além das questões éticas óbvias, eu estaria preocupado com problemas legais. Não tenho certeza se sabotar seu próprio trabalho é legal e, mesmo que seja, usar essa exploração pode não ser.


Obrigado pela sua resposta. Editei minha pergunta para ficar absolutamente claro, que isso seria basicamente 100% oculto ao cliente. Como ele estará principalmente dentro do meu próprio servidor e apenas no modo de desenvolvimento. Então, quando alguém rouba meu software, eu posso matá-lo. No entanto, está começando a ficar mais claro que eu deveria usar a lei e não a "força".
Kalle H. Väravas

2
@ KalleH.Väravas Não importa onde esteja, mas o fato de que você o escreveu para começar. Pode-se até argumentar que colocá-lo em um ambiente de desenvolvimento e não no ambiente de produção é ainda pior, pois os dois ambientes não são mais idênticos e se torna apenas outra variável a ser tratada durante o desenvolvimento e a implantação.
Thomas Owens

3

Basta implementar um módulo de licenciamento com licenças limitadas no tempo que desativarão o software na expiração. Essa é uma prática bem conhecida na indústria de software e seus clientes não devem se opor a ela, pois você removerá a limitação posteriormente.

Isso também pode ser útil quando você deseja limitar os recursos e oferecer versões diferentes do seu produto.

Os interruptores de interrupção têm muitos riscos e não valem a pena.


2

Um recurso secreto de autodestruição é uma ideia horrenda . Sim, você será esperto e poderá ter a oportunidade de atendê-lo a um cliente terrível no futuro, mas é muito mais problemático do que vale a pena.

  1. Você ainda não será pago pelo trabalho realizado. Sim, a outra pessoa não usará seu código; mas você ainda sofrerá falta de pagamento. Você acha que algum criminoso decidirá pagar a pessoa que já derrubou o site uma vez remotamente? Eles encontrarão um novo truque para tornar seu site gratuito.

  2. Utilizando a sequência de autodestruição, você é responsável por seus próprios problemas legais. Dependendo das jurisdições, você pode facilmente ser visto como hacker / destruindo seus dados (quando eles estavam prestes a pagar e tinham muitas circunstâncias atenuantes por que não pagaram antes). Mesmo se você não for condenado / processado com sucesso, ainda poderá cobrar honorários legais elevados e ter muito mais problemas do que vale a pena.

  3. E se algum cliente pagador bom navega no seu código mais tarde (ou tem um amigo do CS que apenas o navegou para fazer um pequeno ajuste), vê a função com parte estranha do base64, é assim, tenta executá-lo e exclui acidentalmente o aplicativo da web (e o faz durante as férias, demora um pouco para ser corrigido)? Ou publica várias críticas públicas sobre você em todos os lugares, afirmando que você é antiético e deixa backdoors no seu trabalho? Claro que você pode removê-lo do produto acabado depois que eles pagam, mas com o VCS eles podem procurar fontes mais antigas ou não querem você no servidor após o pagamento (e isso seria uma conversa estranha; sim, preciso de uma conta novamente, pois não tenho removeu o backdoor secreto de autodestruição).

  4. E se o criminoso fizer backup de seus dados? Você exclui o servidor da web com uma backdoor secreta, o site fica off-line por um dia ou dois enquanto eles (ou um amigo) encontram a função backdoor da função incorreta e sua volta online.

No futuro, peça às pessoas que assinem um contrato simples, paguem por etapas e não deixem o código sair do servidor de desenvolvimento e do computador que você controla apenas até que você seja pago. (Se eles precisarem ser ativados antes que todo o trabalho seja concluído; verifique se pagaram aproximadamente pela fração do código que está se tornando ativo). Se eles quiserem ver o trabalho como sendo desenvolvido, peça a eles alguns endereços IP nos quais você abrirá o firewall para o servidor de desenvolvimento (e talvez com um CNAME inteligente para o efeito deunpaid_work_in_development.example.com) Não dê garantias de tempo de atividade do seu servidor de desenvolvimento e, se você estiver obtendo muito mais tráfego do que deveria (por exemplo, você acha que eles redirecionam muitas pessoas para o seu site), basta fechar o firewall até que eles paguem. Se eles precisarem contribuir com conteúdo para o servidor da Web, envie-os por e-mail com as sugestões de conteúdo ou crie uma pasta compartilhada da caixa de depósito para eles que só tenha permissão para gravar no pequeno subconjunto de arquivos (sob controle VCS fora da caixa de depósito) pode contribuir significativamente para (por exemplo, modelos html).


Cole-o a um cliente terrível no futuro? Isso soa algo que eu não perguntei ou sequer mencionei. E se eu não for pago, mas ele perderá o software, como é válido o seu 1º ponto? Também havia dois pontos na minha pergunta: é ético / legal ter o interruptor de interrupção dentro do meu próprio servidor e / ou no servidor do cliente. Você não mencionou qual deles você quis dizer. Tenho certeza de que posso ter interruptores de interrupção no meu próprio servidor. Então, quando alguém o copia, posso excluí-lo remotamente. E acho que bons clientes são irrelevantes, pois o interruptor de interrupção não está incluído no software. É 1 linha.
Kalle H. Väravas

2

Você fez a pergunta errada. O ponto a ser trabalhado e aprimorado é não adicionar algum tipo de comutador remoto (adicionando uma vulnerabilidade que você ou outra pessoa pode usar), mas corrigir o problema real, que era uma maneira ruim de organizar o pagamento e a entrega. Parece que você precisava de um sistema de custódia melhor (ou como esse conceito é chamado onde você mora).

Não perca seu tempo com um interruptor de interrupção, descubra onde você estragou parte do negócio.


-1 Desculpe, mas sua resposta está fora de tópico. Bons conselhos, um pouco ofensivos, mas ainda assim. Não recomendo fazer julgamentos, pois você não conhece a história completa nem sabe como eu costumo fazer negócios.
Kalle H. Väravas

2

Eu acho que planejaria algum tipo de mecanismo de licenciamento. Isso pode se basear em várias idéias comerciais ou domésticas e pode fazer com que o software pare de funcionar depois que a licença expirar. No momento em que o sistema é aceito pelo cliente e ele pagou, você pode fornecer uma licença completa que não expira.

Essa abordagem também precisa da aprovação de um advogado em seu território, mas tem a vantagem de que você não precisa desativar o software à distância e pode estipular que isso faz parte do sistema antes da mão. No entanto, parece-me muito triste que você esteja lidando com pessoas que se recusam a pagar em primeiro lugar.


Estou começando a realmente amar a idéia do software de teste. No entanto, a segunda parte é duvidosa. Basicamente, se o licenciamento de teste ou até o interruptor de interrupção fazem parte do software, então é perfeitamente legal. Dependendo do trabalho contratado ou não contratado, ele deve ser indicado no contrato.
Kalle H. Väravas

2

Isso não se chama DRM? Desde que você remova a “bomba” ao receber o pagamento, não vejo nenhum problema legal com ela. Apenas verifique se você tem um patch prontamente disponível para cobrir sua bunda e mostre que não tinha intenção maliciosa.

Isso me lembra a disposição da "pílula do veneno" nos artigos de incorporação de algumas empresas que são ativados no caso de uma aquisição hostil.

A saber, a mentalidade expressa por alguns dos outros pôsteres aqui me lembra o motivo de alguns programadores serem pisoteados o tempo todo. Se mais pessoas colocarem essas bombas em seu código, acho que os programadores podem ser pagos mais rapidamente ... eu não teria nenhum problema se essa fosse a norma. As pessoas gostam de roubar o trabalho duro de outras pessoas. Período. E se a Apple, et al. pode DRM o inferno de suas coisas, então eu acho que os programadores freelancers também podem ...


Adoro a sua resposta, ela aborda meu ponto muito melhor do que outras respostas. Eu verifiquei com meu advogado e ele disse que, depois de entrar no painel de administração e fazer upload de um script desvinculado via gerenciador de arquivos, é considerado hacking - ilegal. No entanto, se houver uma função real incorporada no software .. então faz parte do software e tem seu próprio objetivo. Obviamente, isso deve ser coberto no contrato, embora essa questão seja sobre obras não contratuais. Obrigado pela sua resposta :)
Kalle H. Väravas

0

Em uma nota prática, certamente o cliente verificaria seus logs, encontraria a solicitação de interrupção, restauraria o código de um backup, removeria a opção de interrupção e reimplementaria.


É verdade, porém isso depende do cliente, software, servidor. No meu caso, o cliente mal conseguia alterar o acesso ftp. Mas verificar os logs é impossível. Além disso, esse servidor não suporta qualquer logging..neither faz meus CMS humildes ..
Kalle H. Väravas

-2

Os detalhes da sua pergunta deixam claro que essa seria uma ideia absolutamente horrível. O primeiro cliente a descobrir essa opção de interrupção (possivelmente após você usá-la e a recuperação de um backup) publicaria a opção de interrupção e o fato de que você a incluiu no código que você entregou a eles. Sua reputação seria completamente destruída.

E antes que você diga "bem, eles seriam um caloteiro, como eles destruirão minha reputação?" Considere um cenário como este: O cliente está em situação regular, mas um de seus funcionários tira uma cópia do código. Eles demitem esse funcionário, ele olha o código, descobre o interruptor de matar e o usa. Adivinha quem é o culpado? (Dica: é você.)


Discordo. Na verdade, é uma ideia muito boa. Se você ler os detalhes cuidadosamente, entenderá que estou falando de trabalhos sem contrato. Onde, no meu exemplo de exemplo, o cliente é questionável. Sua reputação como bandido conhecido x minha tentativa de me proteger. Eu não acho que isso afetará minha reputação negativamente. Seu cenário parece trabalho contratado. Nesse caso, eu tenho um contrato, não há necessidade do interruptor de interrupção. No entanto, se não há nenhum contrato, então eles não podem obter a cópia do código quer ..
Kalle H. Väravas

Se não houver contrato, você não contratou o direito de ativar o interruptor de interrupção no hardware deles, certo? Péssima ideia.
David Schwartz

Se não houver contrato, não haverá termos do que faz parte do software. Se o interruptor de interrupção faz parte do software, então sim ... do ponto de vista dos programadores: é ético? No entanto, é legal. Como o objetivo dos interruptores de interrupção, como parte do script, deve ser ativado remotamente com o único objetivo de excluir TUDO. É legal, então por que é uma má ideia?
Kalle H. Väravas

1
Então, você está dizendo intencionalmente fazer com que o computador de outra pessoa pare de operar da maneira que ele queria que ele agisse sem a permissão deles (quando você sabe que, se você perguntasse especificamente se poderia fazer isso, eles diriam "não") é o mesmo legalmente como executar uma operação inofensiva na qual você não tem motivos para pensar que o proprietário do sistema teria alguma objeção a fazê-lo? Eu adoraria ouvir você dizer isso a um júri. (Apontar e disparar uma arma para uma pessoa é como ligar um interruptor de luz, certo?)
David Schwartz

1
A resposta que você recebe é tão boa quanto a pergunta que você faz. Por exemplo, você perguntou a eles sobre o caso que discuti na minha resposta? (Um ex-funcionário descobre como ativar o interruptor da matança.)
David Schwartz
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.