Скріншот форми для юридичного підтвердження натискання одного з прапорців?

Ми отримали запит від одного з наших клієнтів, і оскільки я ніколи раніше не стикався з таким запитом, я навіть не знаю, з чого почати шукати.

Наш клієнт - мережа коледжів, і ми будуємо їм сайт. На цьому веб-сайті, серед іншого, з’явиться форма, яку потенційні здобувачі можуть заповнити, щоб отримати більше інформації про дослідження в одному з коледжів. Після того, як користувач заповнить цю форму - включаючи вказівку свого електронного листа та / або номера телефону - відповідний коледж потім зв'язується з ними відповідною інформацією.

Тепер з юридичних причин клієнт просить, щоб у цій формі також було встановлено прапорець, який потенційний заявник перевіряє, щоб вказати, що вони згодні отримати рекламні матеріали з цих коледжів. Звичайно, це не проблема. Але ось приходить дивна частина запиту:

Деталі кожної заповненої форми мають бути збережені надійним способом. Мабуть, збереження значень форми у базі даних - стовпчик із зазначенням, чи користувач погодився чи не погодився - недостатньо, тому що БД може бути змінено після того, як користувачі надіслали форму. Наш клієнт стверджує, що інші портали коледжів створюють скріншот заповненої форми і зберігають її десь у спеціальній папці таким чином, щоб легко знайти такий спосіб, як надання файлу імені, що включає ім’я користувача, та дату і час.

Моє запитання таке: ви чули про використання скріншотів як методу доказування, що користувач фактично заповнив форму? Чи існують інші методи, які вважаються надійними?

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

EDIT Крім того, я маю на увазі WTF? оскільки ви не можете отримати скріншот чужого екрану через Інтернет, вам, очевидно, доведеться реконструювати сторінку на сервері та зробити знімок екрана, а тоді хто скаже, що ви цього не зробили?

Я знаю, що я починаю цю відповідь питанням, але в мене є пункт:

Не викликаючи сумнівів у передбачуваній безглуздість запиту, якщо це типовий веб-додаток на базі браузера HTTP, як би один програмно зафіксував скріншот і надіслав його на сервер?

Я сподіваюсь, що це неможливо, оскільки це буде серйозною проблемою безпеки та конфіденційності браузера.

А тепер уявіть, чи був номер екрана кредитної картки на екрані під час зйомки екрана. Тепер ви ненавмисно збираєте інформацію про кредитні картки, і тепер ваша система повинна бути сумісною з PCI. Це ще одна проблема, яка викликає занепокоєння.

Єдиний спосіб зробити це, ймовірно, використовувати плагін сторонніх веб-переглядачів, таких як Flash, Silverlight, Java Applets або елемент управління ActiveX з підвищеними системними привілеями. Компонент потрібно буде підписати, і користувач повинен погодитись на компонент, що має доступ для запуску коду на своїй машині.

У цьому плані занадто багато дірок, і я серйозно сумніваюся, що інші коледжі реалізують щось подібне. Я, звичайно, ніколи не чув про це у своїй професійній кар’єрі, принаймні, не з веб-додатком.

Редагувати:

Я просто подумав про інший варіант, який, мабуть, значно більше відображатиме те, що я думаю, що ваш клієнт насправді просить.

У мене була програма, яку я зробив для клієнта, де клієнт повинен був погодитись та підписати документ NDA, щоб отримати доступ до програми. Я домігся цього за допомогою сигнального PDF-документа. Ви можете мати поле підпису в документі PDF, що або за допомогою USB-компонента з ручкою + килимок або просто натисканням на нього, щоб підтвердити, це буде так само добре, як якщо б ви фізично підписали документ вручну.

Це називається електронним підписом, і вони справді тримаються в суді.

Документ PDF після його підписання шифрується, а разом із ним зберігається хеш, який підтверджує, що документ НЕ був підроблений після підписання. Сучасні зчитувачі PDF, такі як Adobe, насправді можуть передавати підписаний документ на сервер, де ви можете зберігати його в системі управління документами або базі даних для безпечного зберігання.

У будь-який час користувачі адміністратора можуть відкликати один із цих документів та роздрукувати їх.

Це може відповідати тому, що насправді потребує ваш клієнт, але у нього не було достатнього часу для належного пояснення.

Я думаю, що справжнє запитання було б, чи справді людина, чиє ім’я фігурує у формі, заповнила форму?

Іншими словами, якщо хтось переходить на веб-сайт і вводить ім’я "Білл Гейтс" і натискає на поле "все добре, надішліть мені електронну пошту", як би скріншот довів, що це справжній Білл Гейтс?

Чи розглядали вони, що роблять багато сайтів, і це надсилання електронного листа для підтвердження з унікальним посиланням, яке хтось повинен натиснути, щоб підтвердити? Принаймні, у вас є запис про те, що у вас є підтвердження від того, хто має доступ до цього облікового запису електронної пошти.

Немає такого

Це обговорення потрібно розпочати з розуміння того, що немає жодного способу абсолютно довести, що людина погодилася. Це справедливо навіть у фізичному світі. Навіть якщо ви відеозаписуєте особу, яка фізично підписує форму, і кладеть на форму краплю її крові, вони можуть сказати, що відео було підробленим, кров від них взяли без їх відома, а підпис підробили. Але абсолютний доказ не потрібен; просто розумна кількість доказів.

У цифровому світі будь-які дані - текст, зображення, дані в базі даних чи електронну пошту - можуть бути підроблені. Найближче доказ, який ми можемо мати, - це користувач зашифрувати щось за допомогою приватного ключа та показати, що їх відкритий ключ розшифрує його. Однак наразі це не під силу більшості користувачів, і вони все ще можуть сказати, що їх приватний ключ був викрадений.

Найкраще, що ми можемо зробити:

• Дістати щось, що було б важко (хоча і не неможливо) підробити
• Погодьтеся, що юридично цих доказів достатньо
• Зручте користувачеві відмовитися від передплати

Збереження зображення, а не тексту, нічого не додає з точки зору доказу; все це робить процес повільніше і дорожче.

Електронні підписи

На моїй роботі у нас є додаток, де користувачі підписують заяву. Юридично, юрисдикції, в яких ми працюємо, ухвалили закони, які стверджують, що користувач, який вводить свою електронну адресу у форму, може вважатися електронним підписом. Ми вже перевірили, що вони мають доступ до адреси, надіславши посилання, на яке вони повинні натиснути. Це не є абсолютним доказом, але це було визнано досить хорошим для наших цілей.

Незалежно від інформації, яку ви збираєте, я пропоную також фіксувати часову позначку , тому ви можете сказати, "ви погодилися в цю точну дату та час". Я не впевнений, чи має це юридичне значення, але це здається мені більш переконливим, оскільки це дає більше можливостей користувачеві довести інше ("У мене є доказ того, що я не був за комп’ютером у той час", наприклад ).

Божевільний з цим

Деякі речі , які ви могли б зробити , які могли б бути розглянуті докази:

• Захопіть часову позначку, IP, браузер тощо, щоб ви могли стверджувати обставини підпису
• Потрібна перевірка електронної адреси
• Потрібно від користувача ввести свій пароль в момент підписання
• Упорядкуйте, щоб там працював сторонній веб-сервіс, який працює лише для запису, який отримає, як тільки користувач підпише, HTTPS POST від вашого додатка з інформацією про підпис. Якщо третя сторона може засвідчити, що їх служба працює лише для запису, що вони отримали запис в той момент, і ваша копія є ідентичною, ви можете стверджувати, що ви не змінювали дані з тих пір.
• Надішліть користувачеві електронний лист у той момент, що "спасибі за реєстрацію, ось як скасувати підписку". Їх постачальник електронної пошти або ваш може виявити, що електронний лист було надіслано відразу після підписання користувачем.

IANAL

Будь ласка, не сприймайте нічого з цього як юридичну пораду.

Іншим варіантом було б увімкнути сировину HTTP Post від клієнта. Це матиме їх IP, звідки вони беруться, який браузер тощо, не вимагаючи знімка екрана. Потім ви можете ввійти це у таблицю, що вставляється лише у сирому вигляді, або у простий плоский файл журналу ...

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

Скріншот легко виготовляється, якщо ви настільки схильні. Як і будь-який тип хешування, позначення часу тощо, без криптографічної основи. Можна припустити, що існує певна сувора нормативна вимога, щоб колегія могла довести, що вони отримали позитивну згоду перед тим, як надсилати маркетингові матеріали людям або торгувати їх інформацією третім сторонам.

Єдиний надійний спосіб зробити це - вимагаючи від користувача криптографічного підпису. Для прикладу див. Те, як веб-сайт http://launchpad.net просить вас криптографічно підписати Кодекс поведінки Ubuntu.

Це має силу закону лише в юрисдикціях, де на юридичному документі може бути використаний криптографічний підпис, але, підписуючи певний фрагмент тексту, користувач може надати підтвердження своєї згоди, яке згодом може бути перевірено. Коледжу було б практично неможливо підробити правильний підпис з того ж відкритого ключа.

Зауважте, що коледж все ще триває: оновити свою базу даних і, таким чином, перевернути поле згоди, а також замінити відкритий ключ на інший, для якого вони знають приватний ключ, і створити дійсний підпис для цього ключа.

Тому без ключів підпису сторонніх осіб, щоб засвідчити, що вони належать певній особі, все це досягає того, що користувач може перевірити, чи підробляв коледж свої налаштування конфіденційності чи ні - без підпису третьої сторони це їх слово проти коледжу.

Якщо ви ще більше вимагаєте, щоб усі права власності на ключ були підтверджені, а ключ підписаний однією або декількома довіреними третіми сторонами, колегія не зможе підробити, мабуть, дійсні підписи без значно більшої експозиції (їм доведеться обманювати або спільно вибирати довірена третя сторона, щоб підписати їхні фальшиві ключі). Складність цієї атаки збільшуватиметься із кількістю необхідних підписів сторонніх осіб, але, як зазначає інший плакат, це неможливо.

Отже, підсумовуючи:

• Користувач повинен володіти або генерувати приватну / відкриту пару ключів
• Потім користувач повинен отримати підпис для свого відкритого ключа від однієї або декількох довірених третіх сторін
• Користувач повинен завантажити свій відкритий ключ, принаймні, до коледжу та, бажано, до сховища сторонніх ключів
• Користувач повинен підписати відомий простий текст і надати підпис як доказ, який він погодився на обмін своїми приватними даними

Практичні проблеми:

• Мало хто розуміє криптографічні підписи
• Вартість сторонньої сертифікації може бути дорогою
• Це виглядає як дуже багато роботи, щоб захистити прапорець для небажаної пошти на сторінці завантаження проспекту коледжу

Я б почав з читання електронних підписів для країни / держави клієнта з акцентом на з'ясування, які методи та вимоги є юридично обов'язковими. Я впевнений, що жодна країна чи держава з розумом не вимагали б скріншот як єдиного методу доказування обов'язкового електронного підпису.

Наприклад, у США 47 держав прийняли Закон про уніфіковані електронні транзакції , який, серед іншого, застосовується до "урядових питань" і, таким чином, швидше за все стосується вимог коледжу. У ній є такі частини, які можуть допомогти:

..

• Електронний підпис - означає електронний звук, символ або процес, приєднаний до або логічно пов'язаний із записом і виконаний або прийнятий особою з наміром підписати запис.

..

• Розділ 7 надає юридичне визнання електронним підписам, записам та договорам
  • (a) Запису чи підпису не може бути відмовлено в законному ефекті чи придатності до виконання лише тому, що вони є в електронній формі.
  • (b) У контракті не може бути відмовлено в юридичній дії чи підлягає виконанню лише тому, що при його формуванні був використаний електронний запис.
  • (c) Якщо закон вимагає письмового запису, електронний запис задовольняє закону.
  • (d) Якщо закон вимагає підписання, електронний підпис задовольняє закону.

..

Як тільки я знав закони, я би оцінив вартість найкращого методу електронного підпису проти вартості методу скріншота.

Нарешті, я б обговорив з ними свої висновки. По-перше, я б пояснив їм найкращий варіант проти запропонованого варіанту. Далі я поясню їм скільки часу це додасть проекту. Нарешті, якби мені було місце для цього, я б сказав їм, що ця "особливість" додасть до долара остаточну купюру x доларів. Я б дуже впевнений, що використає для мене додаткову вартість як виправдання додаткової вартості.

Якщо вони все-таки не зруйнують з місця, я б побачив, чи є у них супервізор, з яким я міг би мати ту саму зустріч.

* Я не юрист, тому, будь ласка, зверніться до юридичної ради, якщо ви нічого не знаєте.

Зважаючи на юридичне питання, реальна відповідь, звичайно, залежатиме від національного та, можливо, навіть місцевого законодавства та конкретних обставин. Тож очевидно, справжня відповідь може прийти лише від юриста.

Однак, що стосується моїх (обмежених) правових знань, я не бачу причин вважати, що скріншот вважався б свідченням чогось, оскільки це, очевидно, дуже легко підробити.

Ваш найкращий спосіб дії - це, мабуть, пояснити своєму клієнту, що це по суті юридична проблема, і що потрібна допомога юриста. Потім обговоріть з ними, чи хочуть вони, щоб ви обговорили це з юристом, чи хочуть вони це зробити самі.

Щоб отримати можливе рішення, ви можете зайнятися обговоренням самостійно (якщо клієнт погодиться). Якщо ви не хочете цього клопоту (або боїтесь, що вони можуть не бажати платити вам за це), дозвольте їм це зробити.

Якщо ви хочете перевірити, що документ залишається незмінним (запис бази даних, що б там не було), "найкраща практика" йде так:

• Серіалізувати дані відтворюваним способом, включаючи будь-які поля, які можуть бути спірними (наприклад, адреса електронної пошти, чи встановлено прапорець.)
• Візьміть хеш цього запису (наприклад, sha1)
• Використовуйте відкритий ключ для довіреної третьої сторони (тобто незацікавленої третьої сторони), щоб зашифрувати цей хеш
• Розміщуйте дані публічно, щоб встановити дату, на яку вони існували, наприклад, група новин.
• Для перевірки третя сторона може розшифрувати хеш і порівняти його з теперішнім значенням хеша.

Це було використано для гарантування того, що страхові записи не були підроблені; однак, "третя сторона, якій довіряли", ми заплатили певну суму грошей, оприлюднили хеши, оскільки вони були підписані нам самим та декільком іншим клієнтам, тому було декілька зберігачів записів, які потенційно могли бути винесені в суд, щоб отримати доказ.

Це явно смішний тягар для чогось на кшталт перевірки булевого поля. Але, якщо ви покажете клієнтові пов’язані витрати, вони, ймовірно, перестануть бути тупими.

Хоча сам запит є абсурдним, і ви не можете мати законно підтвердженого юридичного підтвердження того, що особа "А" поставила прапорець під час заповнення форми, всередині вашого запитання є питання, на яке можна реально відповісти:

[Як переконатися, що дані не були змінені пізніше, тоді як] БД можна було змінити після того, як користувачі надіслали форму?

Це, власне, технічно зробити простіше.

1. Зберігайте доказ того, що дані не були змінені

Надсилання електронного листа до себе (до спеціалізованої поштової скриньки) зі значеннями, які фактично надсилаються користувачем, є простим (ну, це може бути, залежно від конфігурації вашого сервера, порогу, шансів відфільтрувати як спам кількість відправлених електронних листів за секунду тощо), і цього достатньо, щоб показати, що дані не були змінені після надсилання . Наприклад, якщо у мене немає необмеженого доступу до серверів Google , я майже впевнений, що кожен переконається, що я не в змозі змінити вміст електронних листів, які я надсилав на свою власну адресу GMail.

2. Зберігайте доказ правильності даних

Швидше за все, клієнт не буде задоволений, оскільки навіть якщо у вас є докази того, що дані згодом не були змінені, як ми можемо бути впевнені, що дані не були змінені між поданням форми та надсиланням інформації електронною поштою (і взяти на себе базу даних)? У цьому випадку наступним кроком є:

1. Видаліть прапорець,
2. Позначте всіх, хто заповнив форму як небажання отримувати рекламні матеріали зі спамом від вашої компанії клієнтів,
3. Вкажіть відвідувачам, що вони повинні надіслати електронний лист (із заздалегідь визначеним заголовком та порожнім тілом) на спеціалізовану поштову скриньку, щоб отримати комерційні пропозиції спаму .

Їх електронні листи можуть бути потім оброблені автоматично і зберігатися як доказ.

3. Зберігайте доказ того, що дані є достовірними

Тепер, коли у вас є доказ того, що особа, яка використовує вказану адресу електронної пошти, насправді хоче отримати спам, клієнт може все-таки бути незадоволеним (що зазвичай трапляється з клієнтами, які мають такі шалені запити). Що робити, якщо хтось зламав чужу поштову скриньку лише для того, щоб зареєструвати хакея, щоб отримати ваш спам?

На цьому рівні божевілля ви все ще можете технічно реагувати на вимоги. Тепер, замість того, щоб надсилати електронну пошту для відмови, користувач веб-сайту повинен:

1. Надішліть електронний лист із копією посвідчення особи / паспорта та листом із підписом, у якому сказано, що ця людина дійсно хоче отримати спам.

2. Підтвердьте адресу електронної пошти через секретний код, який буде надісланий назад.

Але перш ніж це зробити, переконайте замовника здійснити те, що я описав у частині 2, і перевірити його. Клієнт побачить, що через місяць-два ніхто ніколи не надсилає електронну пошту, яка відмовляється, і із задоволенням забуде про юридичні докази та змінені дані в базі даних.

Правовий статус того, що ви робите, не залежить від технічних достоїнств рішення.

Наприклад :

Протягом багатьох років британські члени парламенту ігнорувалимуть електронні петиції, оскільки закон вимагав, щоб петиції мали підпис для кожної людини. Потім хтось помічає, що хеш адреси електронної пошти, дати, часу та коментаря - хоча він не містив секретного ключа - являє собою "цифровий підпис" в очах закону Великобританії.

Тому знайдіть адвоката, який скаже вам, що робити, і зробіть це. Не хвилюйтеся, чи це звук.

Або зробіть те, що просить ваш клієнт, довірившись, що вони перевірилися у юриста. Переконайтеся, що є запис дискусії.

Наскільки ви повинні отримати скріншот? У вас є HTML і все, що ви надсилаєте клієнту, та електронна відповідь від клієнта. Жоден з них не включає скріншот.

Скріншот - це те, що відображає браузер, і дещо відрізнятиметься в залежності від використання браузера та налаштувань та обладнання на іншому кінці. Особисто я переглядаю Firefox, Chrome, Opera, Mobile Safari, зрідка Lynx, а іноді навіть трохи IE.

Ви можете візуалізувати сторінку в стандартному браузері на своєму кінці та зробити знімок екрана, але виготовлення власного документа та його запис не справить враження на суддю. Ви можете попросити користувача надіслати скріншот, але вдало застосуйте це. Не всі пристрої для перегляду мають очевидний спосіб зробити і надіслати знімок екрана (як це зробити на iPhone?). Якщо ви маєте справу з клієнтом із порушенням зору, використовуючи зчитувач екрана, на кінцевому підсумку клієнта може бути зовсім не візуальне представлення. (Я бачив, як кілька моїх сліпих друзів користуються портативним комп'ютером, який не мав жодного дисплея.)

Тож поясніть замовнику, що не існує способу отримання скріншота, і може навіть не бути екрана для фотографування.

Насправді можливо створити обов'язковий контроль доступу спільно з довіреною часовою маркою плюс цифровим підписом для бази даних, щоб гарантувати, що значення стовпця можна довіряти. Скріншоти не є правильною відповіддю. Є, однак, рішення з надійних обчислень, які досягають саме того, чого ви хочете досягти. Якщо ви хочете отримати більше деталей, можете розпочати спілкування зі мною.

Як уже зазначалося, ви не можете реально довести, що людина погодився чи не напевно найкращим рішенням є:

а) Запропонуйте особі підтвердити свою згоду за посиланням, надісланим на електронну адресу (це гарантує, що вони не просто ввели billgates@microsoft.com)

b) Дайте їм можливість скасувати підписку на маркетинг / просування

Схемою, найбільш близькою до захисту від несанкціонованого доступу, було б генерувати пара публічних / приватних ключів, коли користувач заповнював форму за допомогою Javascript, а потім надсилав вміст форми, відкритий ключ та підпис на сервера та представити користувачеві приватний ключ та попросити його взяти до відома та зберігати його десь у безпеці.

За допомогою цієї схеми ви зможете довести, що неможливо підробити дані форми, оскільки ви не знали приватного ключа, який використовується для генерації підпису. Слабка слабкість цієї схеми полягає в тому, що ви повинні мати можливість довести, що ви ніколи не торкалися приватного ключа, і що користувач не повинен втрачати свій приватний ключ.

Оскільки ви повинні бути в змозі довести, що у вас ніколи не було доступу до приватного ключа, можливо, вам доведеться включити HTML і весь Javascript під час генерації підпису форми; це доводить точну форму, яку користувач використовує для подання даних (тому доводить, що ви не змінювали форму / javascript з моменту їх надсилання, тому доводимо, що ви не використовували javascript для крадіжки їх приватного ключа).

Ця схема є складною, і як і у будь-якій складній системі, я не можу гарантувати, що в ній немає діри (насправді я досить впевнений, що існує, і хтось, ймовірно, міг би це вказати).

Скріншот не був би великим доказом, оскільки немає способу підтвердити, що скріншот справжній. Це так легко можна підробити. Що стосується більше технічних рішень, то існує механізм зберігання архівівдля MySQL, який підтримує лише вставлення та вибір. Видалити зі таблиці взагалі не можна. Майте на увазі, можливо, ВИМІРНУТЬ ТАБЛИЦЮ в інший механізм зберігання даних, видаліть запис, а потім ALTER TABLE, щоб змінити двигун назад, не помічаючи, але сподіваємось, ви можете обмежити це корінцем і дозволити кореневі входити лише локально . Тоді ви могли просто відслідковувати входи на фактичну локальну машину баз даних, щоб з'ясувати, хто можливо її змінив. Ви також можете проаналізувати двійкові журнали або включити необроблений журнал запитів, щоб побачити, хто міг видавати запити, що призвели до такого роду діяльності. Я не впевнений, якою технологією баз даних ви користуєтесь, але, швидше за все, вам слід створити рішення, яке не дозволяє легко змінювати дані.

Я рекомендую вам сісти і прочитати закон про ЗНО . Цей статут охоплює те, що є, а що не потрібно для запису електронного підпису, щоб воно було юридично обов'язковим. У попереднього роботодавця ми виявили, що найскладнішим законодавчим перешкодом було можливість зробити підписи та документи читабельними протягом 10-15 років у майбутньому.

Деталі кожної заповненої форми мають бути збережені надійним способом. Мабуть, збереження значень форми у базі даних - стовпчик із зазначенням, чи користувач погодився чи не погодився - недостатньо, тому що БД може бути змінено після того, як користувачі надіслали форму. Наш клієнт стверджує, що інші портали коледжів створюють скріншот заповненої форми і зберігають її десь у спеціальній папці таким чином, щоб легко знайти такий спосіб, як надання файлу імені, що включає ім’я користувача, та дату і час.

Як зазначали інші, скріншот - це те, чого неможливо зробити. Це може бути підробленим, оскільки всі "магічні" шоу - це чиста фабрика: ви бачите, що хтось розпилюється навпіл, але насправді вони не пиляються навпіл.

Я раніше мав справу зі своєю часткою божевільних. Я можу придумати деякі технічні рішення, але чому б не повернутися до клієнта і запропонувати переформулювати питання на тему "Ви не хочете отримувати маркетингові електронні листи?" (чи подібне формулювання) та чи дозволяти людині відмовитися? Тоді вам не потрібен знімок екрана.

Як усі зазначали, технічна та юридична заслуга запиту на функцію відсутня. Однак, є можливість, якщо дозволити користувачеві вручну робити та завантажувати скріншот як додаток до форми.