Вы обязаны предоставлять старым работодателям доступ к защищенным ресурсам? [закрыто]

Во-первых, отказ от ответственности. Этот вопрос заключается не в том, что я недовольный сотрудник, планирующий скрыть какой-то вредоносный код, с которым я могу позже шантажировать своего работодателя. Я действительно очень люблю людей, с которыми я работаю - просто любопытно.

Итак, если бы старый работодатель нуждался в пароле для некоторого ресурса, который у меня был только. Должен ли я предоставить их им или я мог (вероятно, неразумно) придерживаться их и отказываться или взимать возмутительную «консультационную» плату за предоставление этого пароля?

Или что, если я разработал для них какой-то компонент, например, какой-то базовый зашифрованный уровень безопасности, для которого нужен какой-то хэш-ключ, который у меня был, я должен был бы предоставить его им?

Эти два сценария, как правило, являются ошибкой работодателя, но что, если в третьем сценарии я построил этот компонент в хитрости, без их фактического знания? Я не обязательно подразумеваю, что компонент был построен с единственной целью заблокировать работодателя в будущем, он, возможно, действительно послужил хорошей цели - он просто никогда не документировал, как он функционировал, потому что у компании были плохие процессы документации или разработчики тоже занят и т. д.

В этом случае, когда они, наконец, понадобится этот хэш-ключ, я должен был бы его предоставить?

6 голосов | спросил RoboShop 27 AMpWed, 27 Apr 2011 07:44:23 +040044Wednesday 2011, 07:44:23

4 ответа


10

Если это предыдущий работодатель, то есть работа, которую вы сделали для них, принадлежит им, а затем да , вы должны отдать их им. На самом деле вы можете быть юридически обязаны. В идеале вы должны были дать им все, прежде чем уйти. Еще более идеально, прежде чем вы ушли, вы должны были дать им все и не сохранить его копию.

Когда речь заходит о таких вещах, как алгоритмы, которые они не могут понять или ваш преемник не может понять ... это не ваша проблема. Помогите им или не помогите им, как вам нужна ваша совесть и кошелек.

ответил GrandmasterB 27 AMpWed, 27 Apr 2011 07:55:36 +040055Wednesday 2011, 07:55:36
13

Не указывать ключи в описанных ситуациях:

  1. неэтичное
  2. Непрофессиональные
  3. Незрелые
  4. .. Я не юрист, поэтому я не буду говорить «незаконно», но я скажу, что ваш бывший работодатель, вероятно, имеет в своем распоряжении больше адвокатов, чем вы, и есть хороший шанс, что вы окажетесь зарычал в иске.

Вы правы, чтобы сказать, что было бы «неразумно» пытаться привязать его к бывшему работодателю, воспользовавшись их плохой документацией, чтобы удерживать их для выкупа.

ответил Carson63000 27 AMpWed, 27 Apr 2011 07:53:09 +040053Wednesday 2011, 07:53:09
2

Итак, если бы старый работодатель нуждался в пароле для некоторого ресурса, который у меня был только. Я оставил все ключи и т. Д. Если бы я забыл что-нибудь, что бы отправить его по электронной почте. Я согласен с другими комментариями и Carson63000, это более безопасный вариант. Однако вне этого вы не обязаны предлагать какую-либо поддержку или оказывать им какую-либо помощь. Хотя, если вы создали свой собственный сторонний API вне работы и продавали этот API другим третьим сторонам, или вы создали его до работы на своей предыдущей работе. Ну, я не юрист, я не верю, что у них есть право на источник. Быть профессионалом - это всегда лучший способ для вашего собственного будущего в отрасли.

ответил Nickz 27 AMpWed, 27 Apr 2011 08:59:46 +040059Wednesday 2011, 08:59:46
1

Я не буду трогать юридические аспекты этого, но я скажу, что я буду действовать так, как хотелось бы, чтобы кто-то другой действовал, если бы я был боссом. IE Не будьте рывком.

Если ничего более высокотехнологичного мира недостаточно, чтобы получить репутацию и рывок - это хороший способ убить будущие рабочие места. Действительно Если вы оставите, убедитесь, что пароли изменены, и доступ отменен. Это защитит вас от головных болей позже.

ответил Zachary K 27 PMpWed, 27 Apr 2011 23:35:12 +040035Wednesday 2011, 23:35:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132