Тень

Полиграф, полиграф. Осталось экстрасенсов подключить..

А какие такие права? Актуално, аж финиш. Блин, у меня домашний интернет сильно дороже, чем вы тут написали. Контора не может себе такое позволить? Значит, конторе не нужна конкурентная разведка.. Права нарушены... гыы..

Российские налоговики нашли новый способ «обеления» зарплат. На интернет-сайте одной из региональных налоговых служб появились на первый взгляд безобидные анкеты, позволяющие посетителю сайта определить, «белую» или «серую» зарплату он получает. Подвох в том, что узнать это можно, лишь указав сведения о работодателе, злостно нарушающем права персонала. Экс­перты убеждены, что те компании, на которые поступят жалобы, подпадут под пристальный налоговый контроль в первую очередь. Приглашая принять участие в анкетировании на сайте, специалисты управления Федеральной налоговой службы по Орловской области убеждают налогоплательщиков, что они «должны отстаивать свои законные права» и «получать полный объем социальных гарантий». Чиновники предлагают ответить на вопросы: в какой форме сотрудник получает зарплату, подписывал ли он трудовой договор, как он относится к выплате «серой» зарплаты? Кроме того, у респондента выясняют аргументы работодателя, который выплачивает часть зарплаты нелегально. Есть и два во­проса-сочувствия: о том, сталкивался ли человек с проблемами при получении кредита или соцгарантий, а также о том, сообщил ли ему работодатель о негативных последствиях выплаты «серой» зарплаты. Анкета казалась бы вполне безобидным соцопросом, если бы не одно обстоятельство: чтобы ее отправить, нужно в обязательном порядке указать название компании-работодателя. Причем назвать можно не только своего работодателя, но и те организации, которые выплачивают зарплату в конверте родственникам, друзьям и знакомым. Таким нехитрым образом мытари получают полноценную информацию о компании — нарушителе законодательства. «Очень вероятно, что, получив сведения о конвертных зарплатах, налоговики сразу же по­ставят такое предприятие в график налоговых проверок, — полагает замгендиректора аудиторской компании МКПЦН Наталья Малофеева. — При проверках у них будут отслеживать источники поступления наличных средств для выплаты неофициальной зарплаты, прежде всего искать среди партнеров фирмы-однодневки». Впрочем, вряд ли кто-то, не имеющий претензий к работодателю, будет заполнять подобную анкету, даже с целью выяснить легальность своей зарплаты, рассуждает руководитель департамента налогов и права ООО «Бейкер Тилли Русаудит» Эдуард Кучеров. «Шквала информации против работодателей ждать не стоит», — убежден он. Те, кто хотел пожаловаться на работодателя, давно могли сделать это, например, по телефонной горячей линии», пишет РБК Daily. http://rbcdaily.ru/2008/05/08/focus/341701

Управлением ФСБ России официально запрещен сайт odnoklassniki.ru 2008.03.21 Эта новость - новость лишь для тех, кто не работает в спецслужбах. А для тех, чья профессиональная деятельность как-то связана с ФСБ, ФСО и прочими подобными органами, выпущена внутренняя директива о запрете размещения своих данных на сайте odnoklassniki.ru. Получив доказательства данного факта, наша редакция планировала написание этой статьи в стиле фельетона на тему очередной шпиономании. Но перед этим провела консультацию с нашими сотрудниками - ветеранами спецслужб. Их вердикт оказался менее комичным. Бывшие (которые бывшими не бывают) разведчики однозначно назвали сайт odnoklassniki.ru серьезной угрозой безопасности нашей страны. Такая мощная систематизация данных по городам, учебным центрам, предприятиям, войсковым частям с указанием дат службы, личным данным россиян с набором фотографий и т.д. отсутствует даже в ФСБ России. Структура сайта odnoklassniki.ru позволяет выявить личные и профессиональные взаимосвязи граждан, сферы их взаимодействия, интересы и круг общения. Такие разделы как «мои друзья», «друзья друзей», «сообщества», куда иерархически входят учебные заведения, военная служба, профессиональные учреждения и прочее, являются классическим примером сбора разведывательной информации. А то количество - десять миллионов россиян, которое уже включено в этот шпионский справочник, вызывает откровенное опасение. Управление ФСБ России запретило всем сотрудникам российских спецслужб размещать на этом сайте какую-либо информацию о себе под страхом увольнения. Подобные случаи жестко отслеживаются и пресекаются. По данным ФСБ собственником сайта odnoklassniki.ru является немецкая разведка, которая выкупила его у российских создателей за баснословную сумму. Похоже, коммерческая деятельность этой организации все больше развивается, недавно только отгремел скандал с банковской базой клиентов графства Лихтенштейн, которую немецкая разведка купила у одного из банковских сотрудников за два миллиона евро. Увы, даже мы вынуждены констатировать, что информация сайта odnoklassniki.ru является идеальным средством для вербовщика, т.к. содержит личные, профессиональные и даже исторические данные и взаимосвязи как на каждого человека в отдельности, так и на целые группы людей, пересекающихся по тем или иным смысловым направлениям. Если задаться целью, то легко можно найти выход на того или иного человека через знакомых, друзей и родных. На сайте указываются не только реальные данные (обязательное условие функционирования), но и фотографии, что безусловно облегчает обработку интересующих лиц. И хотя на обычных граждан запрет ФСБ не распространяется, надо сказать, что такой сайт может быть опасен и с точки зрения простого криминала. Поэтому наши специалисты не советуют размещать почтовые адреса и фотографии родных, а также демонстрировать свое финансовое благополучие. Тем не менее, структура сайта устроена так, что даже без почтовых адресов даже посторонний человек сможет вычислить ваше местонахождение. Поэтому уж точно не светитесь, если кого-то сильно не желаете встретить на улице forum.msk.ru

Является ли XML панацеей? Дон Петерсон (Don Peterson) В этой статье Дон Петерсон анализирует, почему ему? не нравится XML! Здесь есть несколько интересных утверждений, и, если вы раньше не задумывались, что XML значит для вас как для администратора баз данных, то эта статья заслуживает внимания. Когда у меня появились первые наброски этой статьи, XML был одним из самых модных терминов. Он вел всех нас в абсолютно новый мир, где системы будут легко интегрироваться силами этих маленьких магических тэгов? Только представьте, как было бы замечательно хранить все данные в формате XML! Системы управления базами данных на основе XML, несомненно, станут следующим эволюционным шагом, который наконец уничтожит impedance mismatch (несоответствие объектной и реляционной моделей). Каждый уважающий себя поставщик программного обеспечения просто должен будет использовать XML везде! Все, что преподносилось как неоспоримые преимущества этого решения, вызвало у меня подозрения. Я решил разобраться в причинах такого ажиотажа. После многих месяцев исследований и тестирования я пришел к выводу, что XML не только не является решением любой глобальной проблемы управления или обмена данными, но что это достаточно глупый ответ на все неправильные вопросы! Более того, стало ясно, что XML фактически является гигантским прыжком в неверном направлении, увековеченным теми, кто не знает или не понимает основ управления данными. Изначально статья была внутренним документом, который я отправил менеджерам в попытке урезонить программистов, которые вставляли XML в большие поля varchar в базе данных. Мои усилия были в основном успешными. Политика компании изменилась, позволяя теперь программистам использовать XML только для коммуникации, но не для хранения в базе данных. К сожалению, многие из наших по?ставщиков изменили свои продукты для использования XML, и во всех без исключения случаях мы столкнулись с проб?лемами ? от увеличившегося объема для хранения данных до сильно раздувшихся файлов журнала и абсолютно неэффективных запросов. По предложению моего менеджера я отредактировал документ и отослал его в SQL Server Central. Я никогда не думал, что он будет опубликован, поскольку он противоречил мнению большинства и был, как сказали бы некоторые, подстрекательским. К моему удивлению, я получил много содержательных и поддерживающих мое мнение комментариев. Сейчас XML уже не является модным термином, но, к сожалению, он крепко укоренился почти в каждом подходе к управлению данными. Я, как и многие другие, все еще придерживаюсь глубокого убеждения, что XML не решает никаких проблем, и, если подробно изучить этот вопрос, оказывается, что XML в действительности вызывает даже больше проблем, чем может потенциально решить. Несмотря на маркетинговые требования главных поставщиков и желание шагать в ногу со временем, было бы разумным точно проверить, какие преимущества предлагает XML, и сравнить их с затратами, прежде чем необдуманно погружаться в XML с головой. Идея XML довольно проста: вы просто добавляете тэги в файл данных. Эти тэги иногда интерпретируются как метаданные. XML по своей сути строго иерархичен. Ниже представлены основные преимущества, которые усиленно расхваливаются: самоописание данных; облегчение межплатформенного совместного использования данных или ?свободное соединение? приложений; простота моделирования ?неструктурированных? данных. Самоописание данных Идея самоописываемых данных звучит великолепно, но давайте разберемся в подробностях. Ниже представлен классический пример самоописания данных в XML: <Product>Shirt <Color>Red</Color> <Size>L</Size> <Style>Hawaiian</Style> <InStock>Y</InStock> </Product> Возможный эквивалентный текстовый документ выглядит так: Red,L,Hawaiian,Y В отличие от простого текстового документа, документ XML можно просмотреть и определить значение каждого элемента. Но преимущество ли это? В конце концов, файлы данных будут читать не люди, а машины. Что более эффективно для машины: считывать данные или генерировать? Что лучше для ограниченной полосы пропускания сети? Файл XML занимает в 6 раз больше места, чем текстовый файл. В моих исследованиях файлы XML были в 45 раз больше, чем такие же файлы с разделителями. Изза раздутой сущности XML поставщики аппаратного обеспечения уже предлагают ускорители для компенсации этой проблемы. Что еще хуже, появляется все больше и больше нестандартных анализаторов XML, которые написаны для ?оптимизации? XML, но полностью уничтожают всякую иллюзию о ?совместимости?. (Смотрите http://techupdate.zdnet.com/techupdate/sto...2896005,00.html .) Некоторые пытались доказать, что сжатие помогает компенсировать фактор раздутости XML. Даже без детального анализа можно убедиться, что это полный нонсенс. Если вы начинаете с файла, в 4 раза большего, чем его эквивалент, и потом сжимаете его, то вам, возможно, посчастливится уменьшить его до размера файла без XML, но что будет, если сжать этот самый файл без XML? Кроме того, данный аргумент подразумевает, что сжатие является ?бесплатным?. Сжатие действительно увеличивает пропускную способность и экономит дисковое пространство, но требует времени на обработку. Облегчение коммуникации Самодокументирующаяся сущность XML часто расценивается как помощь в коммуникации между приложениями: мы можем посмотреть на файл XML и сделать разумные предположения, так как значение данных основано на тэгах. Также формат файла может меняться, не влияя на коммуникацию, потому что он основан на тэгах, а не на расположении данных. Однако если тэги изменяются или не подходят, то коммуникация будет прервана. Запомните хотя бы сейчас, что компьютеры не умеют строить догадки. Независимо от использования специальных средств коммуникация между системами требует со?блюдения двух условий: 1. соглашение по тому, что будет отправляться (что обозначают данные); 2. соглашение по формату. XML не меняет эти требования, и несмотря на уверения в обратном это не упрощает дело. Для эффективной коммуникации между системами с помощью текстового файла и отправитель, и получатель должны сначала согласовать, какие элементы будут отправляться (это определяется по расширению файла и означает, что значение каждого элемента уже определено) и позицию каждого атрибута в файле. При использовании XML каждый элемент должен быть определен и все соответствующие тэги должны быть согласованы заранее. Заметьте, что самих тэгов недостаточно для верного описания данных и их значения. Для этого необходимы бизнес?правила, которые управляют использованием данных, пока не будет соз?дан универсальный стандарт, который определяет соответствующий тэг для каждой возможной сущности, которая может быть описана в документе XML (см. http://www.well.com/~doctorow/metacrap.htm). То, что тэги XML расцениваются как самоописывающиеся, приводит многих к дальнейшим ошибочным предположениям, что определенные тэги будут правильно передавать точное значение данных. В лучшем случае сами тэги передают примерное значение, а этого недостаточно. В действительности было замечено, что тэги XML являются метаданными, только если вы не понимаете саму суть метаданных (см. http://www.tdan.com/i024hy01.htm). Способ передачи данных не играет роли; усилия по правильной идентификации данных и их значения остаются теми же. Единственное отличие, привносимое XML, ? это дополнительная большая нагрузка на вашу систему. Неструктурированные данные Сама идея неструктурированных или полуструктурированных данных ? это сочетание противоположностей. Без среды, в которой данные создаются, изменяются и используются, сами данные ? всего лишь тарабарщина. Из?за риска избыточности данные имеют определенное значение лишь в пределах бизнес?правил, в которых они создаются и изменяются. И это не преувеличение. Очень простой пример: данные '983779009?9937' не поддаются расшифровке без правила, указывающего, что это верный номер определенной запчасти. Другой пример, который часто приводят сторонники XML, ? это книга. Но она состоит из частей, глав, абзацев, слов и букв, и все они расставлены в определенном порядке, так что не говорите мне, что книга неструктурированна! Опять же, какое преимущество дает XML? Никакого. Данные по?прежнему должны быть смоделированы, так как их значение должно быть сохранено, но XML по своей сути иерархичен, что переносится и на данные. Было также замечено, что XML ? это просто возврат к иерархическим базам данных прошлого. Проблема заключается в том, что не все данные иерархичны. Реляционная модель данных по своей сути не иерархична, но она безусловно способна сохранять существующие иерархии. Они не являются нейтральными, поэтому иерархия, которая хорошо работает в одном приложении или одном варианте просмотра данных, будет абсолютно неправильной для других случаев, разрушая независимость данных (см. http://www.geocities.com/tablizer/sets1.htm). Именно здесь и содержится настоящая проблема. Не имеет значения, каким большим и неэффективным может быть XML для передачи данных, но он абсолютно ужасен в управлении данными. Иерархические базы данных вымерли, как динозавры, десятилетия назад, и по простой причине: они негибки, и ими очень трудно управлять. Я могу понять, почему многие программисты, работающие с объектно?ориентированными структурами, любят XML. И объектно?ориентированные структуры, и XML иерархичны, и, если вы привыкли мыслить в терминах деревьев и наследования, то множества могут показаться вам абсолютно чуждыми. Это одна из основных трудностей объектно?ориентированной парадигмы, а сейчас как раз то время, когда профессионалы по управлению данными обучаются основам. Теория множеств и логика предикатов (основы реляционной модели данных) оказались лучше иерархических СУБД, основанных на теории графов. Почему же никто не вспоминает о целостности данных, когда какой?нибудь программист кричит о impedance mismatch, несоответствии между объектно?ориентированной структурой и реляционными данными? Почему всегда автоматически подразумевается, что ?ошибка? находится в области технологий баз данных? (См. http://www.geocities.com/tablizer/oopbad.htm.) Я добиваюсь от многих команд разработчиков, чтобы они не хранили XML в базе данных как столбец varchar большой длины или text. Это превра?щает ее в не более чем простое хранилище XML. Конечно, это нарушает один из принципов устройства базы данных ? атомарность, или, в очень свободной трактовке, ? один столбец, одно значение. Как может СУБД поддерживать какую?либо целостность в столбце, содержащем XML? Как я узнаю, что разные строки XML, хранящиеся в данной таблице, имеют какие?то отношения? Индексирование и оптимизация по такой схеме невозможны. (На заметку: когда эта статья была впервые опубликована, Microsoft как раз упомянула, что Yukon будет иметь тип данных XML. Сейчас SQL Server 2005 практически готов, и в нем планируется встроенная в базу данных поддержка XML. Независимо от того, насколько хорошо Microsoft сможет реализовать сжатие и индексирование на типе данных XML, он все равно подходит только для иерархических данных и не годится для общего управления данными.) Поставщики Почему главные поставщики аппаратного и программного обеспечения полны такого энтузиазма по поводу XML, если он настолько плох? Ниже представлено несколько предположений. 1. Незнание. Отделы маркетинга управляют разработкой продукта и очень хотят, чтобы он содержал какой?нибудь модный термин. Незнание частью общества потребителей реального положения вещей позволяет маркетологам увлечь нас разговорами. 2. Глупость. Технические ?эксперты? часто неграмотны, и, так как этому нет никаких оправданий, я назову это глупостью. Я провел несколько часов на последнем SQL PASS Summit, пытаясь найти хоть кого?то из команды SQL Server, кто мог бы предоставить хотя бы одну хорошую причину для использования XML. К концу диалога вокруг стола собралось как минимум пять ?экспертов?, и никто из них не мог привести разумных аргументов. Некоторые ответы были просто шокирующими. Один из них утверждал, что самое большое преимущество XML в том, что программисты могут легко подстраивать базу данных под изменяю?щиеся требования, ?загружая? столбцы с множе?ством атрибутов, чего база данных сделать не может! Здесь я понял, что зря трачу время. Через два часа я покинул их с нарастающим чувством тревоги за будущее SQL Server. Уверен, что они были рады моему уходу, так как смогли вернуться в свою фантастическую XML?нирвану. Вместо того чтобы предпринять какие?либо шаги для более глубокой реализации реляционной модели, они гоняются за своими хвостами, пытаясь внедрить неудачную идею ушедших десятилетий. 3. Жадность. Недавно я прочитал статью, превозносящую возможности XML. По мнению автора, компании полагают, что ?XML улучшит их информационные возможности, но также это приведет к необходимости обновления основных систем? (http://www.dbta.com/frontpage_archives/9?03.html). Примечательно, что он не уточняет, как именно XML ?улучшит? чьи?либо возможности, кроме благосостояния поставщиков программного и аппаратного обеспечения. Вы должны иметь в виду, что основные поставщики необязательно ставят именно ваши интересы во главу угла. Я уверен, что, когда XML признают плохой идеей, вам помогут все исправить? за дополнительную плату. Заключение Не поддавайтесь расплывчатым речам и притягательной рекламе. Как профессионалы по управлению данными, вы ответственны за безопасность данных вашей компании и не можете эффективно выполнять свои обязанности, не зная основ или игнорируя их. Прочитайте статьи ?An Introduction to Database Management Systems? (Chris Date) и ?Practical Issues in Database Management? (Fabian Pascal) и чувствуйте себя уверенно, основываясь на известных принципах управления данными. Альтернатива? Можете тратить время, пытаясь угнаться за последней причудой индустрии, отдавая деньги поставщикам и консультантам на каждом круге этой гонки. Источник не указываю, така как статья взята с внутренней корпоративной конференции

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

Манипуляция не доведена до конца и ИМХО не будет доведена до конца когда-либо (будет получено письменное согласие субекта ПД, отвечающие требованиям закона). Почему Вы решили, что человек однозначно идентифицирован? Вам когда-либо приходилось писать что-нибудь от чужого имени? Вы слышали что-нибудь о "работе под контролем"? Вы уверены, что в блоге писал именно он? Может блог был взломан? Или пароль позаимствовали студенты? А может человек писал под псевдонимом? Можно перечислить еще множество вариантов, не секрет, что идентификация личности в интернет задача не тривиальная (особенно если личность этого не хочет)

По моему ясно видно, что человек в вежливой форме дал понять, что такое общение с Вами для него не интересно, а не выразил согласие на обработку ПД. Согласие на обработку ПД дается субъектом ПД в ПИСЬМЕННОМ виде, и в 152ФЗ объясняется в каком виде.

А можно интренет использовать не на рабочем месте и не из дома. только и всего :)

А вы уверены, что скртие IP - скрытие всей инфы о вас, любимых ?

Ну IP-адрес они временами и скрывают. Чего не скажешь о другой интересной информации, передаваемой через HTTP-запрос.. как минимум типп операционки, время и тд.. а если использовать не нормальную ОС, а виндовс - так вообще раздолье :) Управление К в экстазе :)

По поводу изначально поставленной задачи. Во всей ветке нет ни одного упоминания об IT службе/специалисте организации. Как было замечено, не во всех организациях (особенно мелких) есть секретарь, а вот "мальчик по компьютерам" есть везде. Эти люди страшно "любят" секретарей, бухгалтеров, менеджеров и т.д. Их практически нереально обучить основам элементарной безопасности (не давать информацию неизвестным лицам), наоборот, т.к. они часто отвечают на вопросы "юзверей", то отвечают просто на автомате. Они зачастую не знают штат организации (можно представится новым сотрудником), зато владеют полной информацией об внутриконторской телефонии: нужные номера, возможность тонового донабора, дополнительные прямые номера шефа, время его появления в конторе и т.д. Тел. IT службы можно узнать у того-же секретаря:) Данный метод всегда помогал на практике:) И вобще админы ценный источник информации:)

Сейчас закончу с критикой и внесу:)

Если Вы это серьезно Затопление: ТОПу обычно фиолетово, т.к. он не сантехник, чтобы перекрыть трубу, и не электрик, чтобы обесточить здание, штукатурка мокрая с потолка не сыпется... Поэтому максимум будут даны инструкции секретарю. Пожар: есть ответственность за заведомо ложное сообщение о... СОРМ пока еще работает:) Вычислят, потом никогда в жизни вы не продлите свою лицензию частного охранника:) Проверяющие органы: в такой ситуации руководство вобще покрывается, дабы быстро выяснить обстановку откуда ветер дует, а все подчиненные резко уходят в несознанку Пьяный и буйный клиент: задача службы безопасности или милиции. Еще неизвестно что хуже:) Ревизор: поверьте моему опыту, о ревизорах госструктуры предупреждают задолго до... При чем с указанием сроков работы, областью проверки, ФИО проверяющих и т.д. Распродажа косметики: вряд ли заинтересует даже секретаря

Не путайте секретаря с проституткой. Она конечно перезвонит, но как только поймет (а она обязательно поймет, т.к. времени "окучивать" ее пару месяцев нет) что Вы ее банально используете (второй вариант купили) вы больше никогда не сможете появится не только в этой организации но и в соседних. Женская обида и женская солидарность страшные вещи, а настоящих Казанов увы мало, особенно когда временной ресурс ограничен.