Классификация данных на основе контента — это открытая задача. Традиционные системы предотвращения потери данных (DLP) решают эту проблему путем снятия отпечатков с соответствующих данных и мониторинга конечных точек для снятия отпечатков. Учитывая большое количество постоянно меняющихся ресурсов данных в Facebook, этот подход не только не масштабируется, но и неэффективен для определения того, где находятся данные. Эта статья посвящена сквозной системе, построенной для обнаружения чувствительных семантических типов в Facebook в масштабе и автоматического обеспечения хранения данных и контроля доступа.

Описанный здесь подход — это наша первая сквозная система конфиденциальности, которая пытается решить эту проблему путем включения сигналов данных, машинного обучения и традиционных методов снятия отпечатков для отображения и классификации всех данных в Facebook. Описанная система эксплуатируется в производственной среде, достигая среднего балла F2 0,9+ по различным классам конфиденциальности при обработке большого количества ресурсов данных в десятках хранилищ. Представляем перевод публикации Facebook на ArXiv о масштабируемой классификации данных для обеспечения безопасности и конфиденциальности на основе машинного обучения.

7 августа Facebook представил Pysa — ориентированный на безопасность статический анализатор с открытым исходным кодом, помогающий работать с миллионами строк в Instagram. Раскрыты ограничения, затронуты проектные решения и, конечно, средства, помогающие избегать ложных положительных срабатываний. Показана ситуация, когда Pysa наиболее полезен, и код, в котором анализатор неприменим. Подробности из блога Facebook Engineering под катом.

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

Менеджер процессов для продакшна с балансировщиком нагрузки. Обёртки над отладкой и хуками Git, защита express-приложений через HTTP-заголовки, утилита в более чем 180 функциями для работы с датами и другие инструменты, которые сэкономят ваше время. Подборка особенно полезна начинающим разработчикам NodeJS, но может порадовать опытных скептиков.

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

Еще у части специалистов есть пунктик на тему красоты почты. Хочется красивый, короткий, запоминающийся адрес, который бы показывал, что вы не просто gmail-холоп, а вполне самостоятельная боевая единица на полях IT-сражений. А кто-то хочет просто экспериментов. Эти люди уже сами собирали ядро системы, тонко настроили домашний медиа-сервер, научили роутер качать все подряд с файлообменников без участия ОС. Теперь нужно поднять свою почту, приватный VPN, а дальше можно посмотреть в сторону написания драйверов или на другие активности уровня «хардкор».

У многих IT-специалистов существует запрос, который публичный почтовый сервис удовлетворить не способен. Вот только не все отдают себе отчет, чего им это будет стоить. Так что давайте разберемся, на самом ли деле вам нужен почтовый сервер или стоит приложить свою энергию в каком-то более перспективном направлении.

Пояснительная часть

Недавно мне попалась статья в журнале "Код" под названием "Сравнение: классы против функций". Я прочитал ее и она показалось мне… странной. Журнал позиционирует себя как издание для начинающих программистов. Но даже со скидкой на уровень аудитории статья вызывает много вопросов.

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

Подчеркну особо — на протяжении текста я рассматриваю статью глазами новичка. У меня в этом скромный опыт: я делал уроки по программированию, писал обучающие статьи, занимаюсь менторством. Поэтому придираюсь только по одному критерию — как усвоит информацию начинающий программист. Мне кажется, это совпадает с тематикой издания.

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

Для полноты контекста прочитайте оригинал, это не займет много времени.

Все началось с того, что мне подарили пульсометр. Точнее, сначала я решил, что надо бы как-то бороться с возможными последствиями сидячей работы, и начал бегать. Как любой гик, начавший бегать, тут же поставил себе соответствующее приложение, чтобы отслеживать пробежки и делиться ими с друзьями. И вот уже после этого, когда мне подарили пульсометр и я несколько раз пробежался, замеряя пульс, товарищи попытались мне объяснить, что себя надо беречь и стараться, чтобы пульс во время пробежки не зашкаливал за 180. Я по неопытности думал, что в беге — чем быстрее, тем лучше. Но в процессе изучения матчасти выяснилось, что результат тренировки сильно зависит от того, с каким пульсом ты бегаешь — и для некоторых целей нужен низкий пульс (и, соответственно, низкий темп).