Да, кстати, автор говорит, что прошло 4.5 года после того, как она отказалась от операции по удалению лимфоузлов шеи, пораженных опухолью, и она чувствует себя прекрасно и у неё нет ни малейших признаков рака. Если не рассматривать предположение о том, что кто-то потратил кучу денег на откровенную ложь, можно ведь и проверить в лабораторных условиях, какой из ингредиентов, которые она использовала, привел к подобному эффекту, и воспроизводим ли этот эффект. И если всё работает — то мисс Диана Брукс заслужила свои патентные отчисления, разве нет?
Кстати, если что-то придумает один человек, а другой запатентует это, то это основание предполагать кражу и судиться, по крайней мере в Украине.
В этом случае изобретатель крадет у патентодержателя, или наоборот? У меня сложилось общее ощущение о системе патентов, что не важно, кто придумал — важно, кто запатентовал, и в таком случае изобретатель обязан платить владельцу патента за право реализовать свое же собственное изобретение.
Что мешает зарегистрировать патент на «устройство для перемещения объектов в пространстве со скоростью выше 250 млн. метров в секунду», и ждать барышей от изобретения гипердвигателей? Работоспособность-то проверять не нужно, а «изобретение»-то вот оно.
Эта тема не всплыла бы, если бы фейсбук просто не включил данные с флагом deleted в выгрузку для австрийского студента юрфака. Я лично не вижу ничего предосудительного в этом естественном архитектурном решении.
Давайте попробуем с другой стороны — зачем что-то действительно удалять, если вам, как пользователю, абсолютно всё равно, что произошло на самом деле? Выглядит для вас всё так, как если бы данные были удалены, как и для всех обычных пользователей — ваших друзей, врагов или мимопрохожих. Я понимаю, если бы удаленные сообщения были доступны первому желающему — это да, повод для баттхерта, но видят их только вы (и по запросу), правительство и сотрудники. И то, насчет сотрудников еще можно поспорить в том плане, что, в отличие от плохих людей, ломающих аккаунты пачками с целью перепродажи спама и лайков, у сотрудников подобной мотивации нет.
Т.е. да, могут смотреть, конечно, более того — желательно исходить из предпосылки, что смотрят, но если же вы так беспокоитесь о сливе собственных данных в КГБФСБ, зачем, в первую очередь, вы доверяете данные сервису, которому не доверяете? Степень уничтоженности данных роли ведь не играет — любые удалённые данные когда-то таковыми не были.
Вот только накладные расходы создания являются неизбежными — нельзя, увы, поставить птичку «запись создана» и не заполнять больше ничего, запись нужно создать по-настоящему. А вот «удалить» можно и путем простановки флага — разницы для пользователя при этом нет никакой.
Если бы все соблюдали правила пожарной безопасности… но мы живем в реальном мире, и в реальном мире реальные пользователи часто используют `qwerty` в качестве пароля. Если заставлять делать очень длинные пароли, безопасность всё равно не будет высокой, пока сам пользователь не осознает необходимость этого.
Ну и как бы продукты делаются, чтобы зарабатывать на них деньги, а не чтобы учить пользователя быть умным.
Ну так это ж не вы их удалили, а хакер. И вы пишете в саппорт — «взломали страницу, всё удалено — переписка, твиты, посты, фотки, всё снесли :(», и саппорт отвечает — «нет, что вы. Мы не будем восстанавливать, ведь откуда мы знали, что это хакер удалил, а не вы? Мы всё снесли, помочь ничем не можем, пишите письма очаковскому раввину». Зачем так делать, когда всё равно возможность восстановить есть?
По той же причине, собственно, файловые системы отмечают файлы, как удаленные, вместо того, чтобы забивать их нулями — просто потому, что во втором случае производительность будет в районе плинтуса из-за необходимости перезаписать кучу секторов, которые находятся в физически несоединенных точках диска.
Справедливо для маленьких объемов данных, хранящихся последовательно. Для базы данных с объемами фейсбука это, скорее всего, не так:
1. база данных может иметь очень большую связность. Например, объект личного сообщения на самом деле хранится не как одна строка в БД, а как множество объектов, связанных через какую-то промежуточную таблицу — отдельная таблица для списка получателей, отдельная таблица для списка серверов, на которых дублируется блоб с текстом сообщения, отдельная таблица для хранения ревизий измененного сообщения… Если удалить только промежуточную таблицу, которая это всё связывает, как удалять «бесхозные» записи в других таблицах? Mark & sweep? Каскадно делать кучу связанных запросов с дереференсами и удалять каждую запись?
2. а что, если связность достигает таких уровней, при которых цитата чьей-нибудь реплики в личном сообщении — это не копия, а ссылка? В таком случае, «занулив» приватные данные, все упоминания этих данных тоже будут уничтожены, а это уже не совсем корректно в том плане, что личные данные, которые были разглашены даже в персональном порядке, уже не совсем личные, и частично принадлежат и тому человеку, который их «репостнул». Я не юрист и не оформлю это красивым языком, но суть в том, что если мне сказали что-то, то это моё право передать это «что-то» кому-то другому по моему усмотрению, и никто не имеет права без моего разрешения удалять-изменять мое сообщение. Копировать же все упоминания накладно, плюс это всё равно не решает проблему «хранения удаленных личных данных», еще и порождает проблемы с висящими указателями.
Любой из этих вариантов. Уверять клиента, что это именно он во всем виноват — плохая мысль с точки зрения зарабатывания лояльности клиента, каким бы он ни был, наверное.
И что значит «бэкапов нигде никаких никто не держит»? Разве это обязанность клиента делать бэкапы данных, ответственность за хранение которых взял сервис? А если всё-таки согласиться с тем, что сохранность обеспечивает сервис — чем периодические бэкапы, которые, как я понял, вы имеете в виду, лучше, чем «непрерывные», при которых никакие данные не удаляются и не замещаются?
При использовании периодических бэкапов, все данные, поступившие после последнего сохранения, будут уничтожены. Сравните «Мы восстановили все ваши данные» или «Мы восстановили все ваши данные, кроме тех, которые были добавлены на этой неделе (которые вам как раз и были нужны)» — мне кажется, второй вариант в голове пользователя равноценен «они так ничего и не восстановили — толку мне от переписки годичной давности?».
На случай, если аккаунт взломали и удалили всё, разве не разумнее помечать, как удаленное? Чтобы если пользователь потом прибежит в слезах «у меня всё удалили», можно было восстановить удаленное и получить репутационный плюсик. Ну и мне почему-то кажется, что помечать, как удаленное, более эффективно с точки зрения производительности БД.
Это уязвимость, о которой никто не знает, кроме того, кто эту уязвимость нашел и узкого круга посвященных. Как только уязвимость утекает в паблик и/или к автору софта, она перестает быть 0day.
Т.е. да, могут смотреть, конечно, более того — желательно исходить из предпосылки, что смотрят, но если же вы так беспокоитесь о сливе собственных данных в КГБФСБ, зачем, в первую очередь, вы доверяете данные сервису, которому не доверяете? Степень уничтоженности данных роли ведь не играет — любые удалённые данные когда-то таковыми не были.
пожарнойбезопасности… но мы живем в реальном мире, и в реальном мире реальные пользователи часто используют `qwerty` в качестве пароля. Если заставлять делать очень длинные пароли, безопасность всё равно не будет высокой, пока сам пользователь не осознает необходимость этого.Ну и как бы продукты делаются, чтобы зарабатывать на них деньги, а не чтобы учить пользователя быть умным.
1. база данных может иметь очень большую связность. Например, объект личного сообщения на самом деле хранится не как одна строка в БД, а как множество объектов, связанных через какую-то промежуточную таблицу — отдельная таблица для списка получателей, отдельная таблица для списка серверов, на которых дублируется блоб с текстом сообщения, отдельная таблица для хранения ревизий измененного сообщения… Если удалить только промежуточную таблицу, которая это всё связывает, как удалять «бесхозные» записи в других таблицах? Mark & sweep? Каскадно делать кучу связанных запросов с дереференсами и удалять каждую запись?
2. а что, если связность достигает таких уровней, при которых цитата чьей-нибудь реплики в личном сообщении — это не копия, а ссылка? В таком случае, «занулив» приватные данные, все упоминания этих данных тоже будут уничтожены, а это уже не совсем корректно в том плане, что личные данные, которые были разглашены даже в персональном порядке, уже не совсем личные, и частично принадлежат и тому человеку, который их «репостнул». Я не юрист и не оформлю это красивым языком, но суть в том, что если мне сказали что-то, то это моё право передать это «что-то» кому-то другому по моему усмотрению, и никто не имеет права без моего разрешения удалять-изменять мое сообщение. Копировать же все упоминания накладно, плюс это всё равно не решает проблему «хранения удаленных личных данных», еще и порождает проблемы с висящими указателями.
И что значит «бэкапов нигде никаких никто не держит»? Разве это обязанность клиента делать бэкапы данных, ответственность за хранение которых взял сервис? А если всё-таки согласиться с тем, что сохранность обеспечивает сервис — чем периодические бэкапы, которые, как я понял, вы имеете в виду, лучше, чем «непрерывные», при которых никакие данные не удаляются и не замещаются?
При использовании периодических бэкапов, все данные, поступившие после последнего сохранения, будут уничтожены. Сравните «Мы восстановили все ваши данные» или «Мы восстановили все ваши данные, кроме тех, которые были добавлены на этой неделе (которые вам как раз и были нужны)» — мне кажется, второй вариант в голове пользователя равноценен «они так ничего и не восстановили — толку мне от переписки годичной давности?».