Интернет
badkid

Instagram не удалял ваши удалённые фотографии и личные сообщения со своих серверов

Независимый исследователь Сагат Покхарел (Saugat Pokharel) обнаружил в загруженных данных из Instagram фотографии и сообщения, которые он удалил из приложения больше года назад.

В Политике использования данных Instagram не сообщается о том, в течение какого именно времени компания в праве хранить удалённую информацию, однако источник сообщает, что обычно это занимает 90 дней. Также они заявили, что столь длительное хранение данных – это баг, который успешно устранен в этом месяце. Сагат сообщил о нем компании ещё в октябре 2019 года в рамках программы Bug Bounty.

Instagram выплатил вознаграждение в размере $6000 и поблагодарил пользователя.

0
29 комментариев
Написать комментарий...
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт заморожен

Комментарий недоступен

Ответить
Развернуть ветку
Иван Иващенко

Перепись специалистов по фрагментации на TJ. Не пишите херни.

Ответить
Развернуть ветку
Иван Иващенко

Да там же просто будет ФРАГМЕНТааааЦИЯ, будут диски медленно работать, ты что не слышал про такое? А помнишь как мы в детстве диски дефрагментировли, в надежде что игра на них все-таки поместится? Ну воооот, тут тоже самое.

Ответить
Развернуть ветку
Аккаунт заморожен

Комментарий недоступен

Ответить
Развернуть ветку
Иван Иващенко

1. Фрагментация дисков – это старая проблема HDD накопителей, которая влияла на производительность последовательного чтения. Для современных накопителей дефрагментация не только не нужна, но и вредна.

2. Стандартный размер дисковой страницы – 4кб. Это неделимый блок файловой системы. Каждая картинка занимает несколько страниц, каждая из которых учитывается отдельно. Смысла экономить на дополнительных 8 байтах адресации, теряя при этом 4кб пространства нет. Самый большой доступный размер страницы который мне известен – 128кб (ZFS). То есть скорее всего картинка занимает по крайней мере целую страницу, а не пакуется блобами внутри одной страницы.

3. Очевидно, что само содержание картинки не обязательно затирать из диска. Но тот факт, что картинка не пропала из индекса существующих картинок – это именно баг, и фрагментация тут уж точно не причем. Скорее всего Instagram окончательно удалял помеченные как удаленные в течении года картинки по расписанию, и этот скрипт не работал как ожидается.

4. Такого понятия как фрагментация индексов не существует – базы данных и так перебалансируют деревья индексов в реальном времени, даже если вы только добавляете и не удаляете данные. Таким образом, удаление изображения из индекса не должно сказываться на производительности в худшую сторону.

5. Единственная причина, по которой удаленное значение может остаться в БД, которую я вижу – использование MVCC БД (Multiversion concurrency control), таких как CouchDB. Но их использование оправданно только при необходимости обеспечения изоляции транзакций, которая не нужна для хранения картинок Instagram.

Ответить
Развернуть ветку
alexferman

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

Ответить
Развернуть ветку
Иван Иващенко

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

Ответить
Развернуть ветку
dmzkrsk

Секта свидетелей фрагментации

Ответить
Развернуть ветку
3216q114

На SSD не так.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
J S

Да ну нафиг. Если из БД удалить запись, то ничего на диске не фрагментируется.

Удаление из БД не значит, что с диска это удаляется и на это место что-то потом пишется. На диске остаётся, но удаленные данные из БД уже нельзя вернуть запросом.

А кто говорит, что не удаляет из-за фрагментации это лапша для легковерных, чтобы объяснить сбор данных)
Гугл тоже как-то говорил, что случайно из-за бага снифал уличные вайфай сети. Ага, терабайты данных получал и хранил чисто случайно))

Ответить
Развернуть ветку
dmzkrsk

ELI5, кто-нибудь?

Ответить
Развернуть ветку
Лактобацилиус

Почему тогда каждый раз подобные штуки объясняют "багом" и кабанчиком чинят?

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
gr666stlan

Instagram выплатил вознаграждение в размере $6000 и поблагодарил пользователя
и прислали сообщение "ебать спасибо , братишка"

Ответить
Развернуть ветку
badkid
Автор
 ебать спасибо, братишка, классный член кстати
Ответить
Развернуть ветку
Myemptyblog

Неплохо.
А вконтакт в принципе ничего не удаляет, всё хранится.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
badkid
Автор

Ну да, миллиард двести ежемесячно — это, считай, никто

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Амбассадор Бреда

"Длительное хранение - баг "

Блин, ну вот опять эти мерзкие баги, о которых добрый и светлый фб не знал. Ну что за невезение

Ответить
Развернуть ветку
Иван Кривых

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

Ответить
Развернуть ветку
J S

Нормальные БД не фрагментируют блоб с данными, он постоянно растет и не уменьшается от удаления записей)
Чтобы уменьшить надо склонировать базу.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
badkid
Автор

Он удалил больше года назад. Заголовок надо подправить, да, спасибо!

Ответить
Развернуть ветку
Рулон Обоев

Невозможно удалить то, чего нет ( ͡° ͜ʖ ͡°)

Ответить
Развернуть ветку
Читать все 29 комментариев
null