Google выпустил руководство для вебмастеров, в котором даются советы о том, как лучше всего оптимизировать сайт под Google. 30 основных пунктов перечислены ниже.

Итак, что не cтоит делать во время оптимизации сайта:

1.выбирать заголовок, не имеющий никакого отношения к основному содержанию страницы.
2.использовать заголовки по умолчанию: «новый заголовок 1», «создать заголовок» и т.д.
3.использовать один и тот же тайтл на всех страницах сайта.
4.писать слишком длинные заголовки, не представляющие интереса для пользователей.
5.набивать тайтлы бесполезными ключевыми фразами.
6.писать описание мета-тегов которые не относятся к основному содержанию на странице.
7.использовать сгенерированные описания на подобии «новая страница», «страница о футболе».
8.наполнять тег description только ключевыми фразами.
9.копировать и вставлять весь контент на странице в тег description.
10.использовать одинаковое описание в description на всех или большей части страниц вашего сайта.
11.иметь длинные URL страниц с бессмысленными параметрами и ID сессиями.
12.выбирать для генерации страниц название на подобии «страница1.html».
13.чрезмерно использовать ключевые слова в url страницы по типу «заработок_в_сети_заработок_в_сети_заработок_в_сети.html».
14.размещать страницы сайта глубоко в подкаталогах по типу “…/dir1/dir2/dir3/dir4/dir5/dir6/
page.html”.
15.использовать имена под каталогов не относящиеся к контенту внутри их.
16.иметь страницы с тем же самым контентом на основном домене и субдомене сайта ( типа “domain.com/page.html” и “sub.domain.com/page.html”.
17.смешивать www. и без-www версии сайта на страницах.
18.использовать ЗАГЛАВНЫЕ БУКВЫ в адресах страниц.
19.создавать страницы, которые ссылаются на все содержимое сайта.
20.оставлять контент без каких либо разделителей или подзаголовков.
21.иметь на сайте навигацию, основанную на выпадающем меню, изображениях или анимации.
22.отдавать Sitemap файл с битыми ссылками.
23.создавать Sitemap содержащий только перечень ссылок на сайте.
24.разрешать вашим 404 страницам индектироваться в поисковых системах.
25.оставлять 404 страницы без вспомогательного текста лишь с записью «не найдено»
26.использовать дизайн для 404 страниц не соответствующих основному оформлению сайта.
27.писать бессмысленный текст с большим количеством грамматических и орфографических ошибок.
28.вставлять весь текст на странице в описание для изображений (в тег alt).
29.создавать страницы с большим количеством текста, без каких либо разделителей и параграфов.
30.писать (или копировать) контент не представляющий какой-либо ценности для пользователей.

Впрочем, даже если в Google действительно использовали этот источник, такое применение недокументированных функций при виртуализации процессов в Chrome – далеко не единственное.
MAC против DAC

Частью изолированной среды выполнения Chrome является новейшая (документированная и полностью поддерживаемая) функция Vista, которая применяется и в IE8. Vista дополнила модель безопасности Windows NT, внедрив концепцию под названием полномочное управление доступом (mandatory access control, MAC). Традиционная система безопасности в NT основывалась на механизме избирательного контроля доступа (discretionary access control, DAC), который не является чем-то особенным, поскольку используется во всех типичным образом защищенных операционных системах. Безопасность на основе DAC – это такая схема, при которой доступ к объектам из ОС разграничивается в соответствии с идентификацией членства пользователя в различных группах. Термин "избирательный" применяется здесь в связи с тем, что пользователь, имеющий права на доступ к объектам, может делегировать их и другим пользователям. В системах же на основе MAC, напротив, пользователям запрещено самим аннулировать действующие разрешения, и они не могут присваивать их другим пользователям.

Чтобы проиллюстрировать разницу этих концепций, приведем следующий пример. Допустим, в некой компании есть Президент А. и вахтер Б. Президент А. имеет возможность создания файлов с информацией под грифом "совершенно секретно", а Вахтер Б. ни при каких обстоятельствах не должен получать к ней доступа, даже если Президент А. захочет этой информацией с ним поделиться. В системе на основе DAC Президент может создавать файлы с совершенно секретной информацией, и, поскольку он является владельцем своих собственных файлов, он может передать права на их просмотр Вахтеру путем добавления его в список имеющих доступ к упомянутым файлам.

Однако в системах на базе MAC схема совершенно другая. Президент все также имеет доступ к файлам категории "совершенно секретно", однако все файлы, которые он создал, будут также иметь гриф "совершенно секретно", и доступ к ним получат только те, кто имеет уровень привилегий "совершенно секретно" или выше. Таким образом, Президенту не удастся снять с файлов отметку "совершенно секретно" и дать доступ к ним вахтеру. В этом случае доступ называется "полномочным" – введенные системой ограничения принудительны и не могут быть пересмотрены со стороны пользователей.

Есть два основных преимущества использования концепции MAC в зависимости от целей разработчика системы: 1) можно использовать MAC для обеспечения конфиденциальности (модель "Bell-LaPadula") и 2) можно использовать эту схему для обеспечения целостности данных (модель "Biba"). В системах, спроектированных с прицелом на конфиденциальность (как в приведенном выше примере), пользователи получают право на чтение файлов, имеющих такой же или более низкий уровень доступа, чем присвоен самим пользователям, и право на создание файлов с таким же, или более высоким уровнем доступа. Такие ограничения делают невозможным создание Президентом файла под грифом "свободный доступ" и копирование в него совершенно секретных данных, поскольку все созданные им файлы будут, как минимум, иметь категорию "совершенно секретно".

В системах, спроектированных для обеспечения целостности, правила игры меняются на противоположные. Пользователи имеют возможность записи в файлы с таким же или более низким уровнем привилегий, чем у них самих, и возможность чтения файлов с таким же или более высоким уровнем доступа. Цель такой политики состоит не в том, чтобы запретить кому-то видеть то, что он видеть не должен, а в том, чтобы не дать возможность вносить изменения в файлы, прав на внесение изменений в которые у пользователя нет. Такую интеграционную модель и поддерживает Vista. Процесс с низким уровнем привилегий в этой операционной системе может считывать файлы с более высоким уровнем доступа (чтобы, например, загрузить DLL, необходимые для его запуска), так же как и записывать файлы в каталоги с таким же низким уровнем привилегий, как у него, но ему запрещено записывать файлы в каталоги с более высоким приоритетом (так, например, он не сможет ничего записать в каталог Windows).

И Chrome и IE8 в Vista пользуются этим. Родительский процесс (ответственный за прорисовку окна и взаимодействие с пользователем) запускается со средним уровнем привилегий, а все производные процессы – с низким уровнем. Средний уровень доступа дает возможность чтения/записи профиля пользователя (позволяя, таким образом, сохранять загружаемые файлы или применять политики на основе ранее сохраненных учетных данных). Низкий приоритет позволяет считывать данные из профиля пользователя, но запись для него возможна лишь в пару временных каталогов. Ни тот, ни другой уровень доступа не позволяют осуществлять запись в каталог Windows, поскольку для этого требуется более высокий приоритет.

Chrome, однако, заходит здесь еще дальше, опять влезая на заповедную территорию.
Chrome поднимает ставки

Для Google защиты Vista недостаточно. В Google хотят, ко всему прочему, еще и ограничить возможности любого процесса по чтению/записи любого файла, запуску другого процесса и чтению/записи реестра. Чтобы это осуществить, программисты частично переписали процессы, отвечающие за вкладки и сторонние приложения, и теперь любая попытка проведения запрещенных операций проходит проверку на внутреннем анализаторе Chrome. К примеру, любая попытка открытия файла сверяется со списком допустимых мест хранения файлов, и, если файл в этот список не входит, его открытие запрещается, даже если в другом случае процесс и мог бы получить к нему доступ.

Такая переработка кода затрагивает особые процедуры API. Некоторые из переписанных заново функций документированы (например, функция CreateProcess), а некоторые – нет (например, функция чтения атрибутов файла NtQueryFullAttributesFile не является задокументированной). Многие похожие функции, используемые в коде, применяются довольно редко, даже сторонними разработчиками, и, в связи с этим, проведение некоторой работы по реверс-инжинирингу попросту неизбежно.

Все это ставит на повестку дня весьма интересный вопрос. Цель, с которой Google использует недокументированные системные процедуры, весьма благородна – ведь компания всего лишь стремится сделать свой браузер более безопасным и хочет быть уверенной в том, что влияние потенциальных уязвимостей будет минимизировано. Однако Windows не предлагает такого системного подхода к виртуализации процессов, который имеется в Chrome (хотя, очевидно, многие бы хотели, чтобы он предлагался). Поэтому перед Google стоял трудный выбор – либо пожертвовать безопасностью (что для большинства совсем не желательно), либо погрузиться в глубокое изучение операционной системы и нарушить EULA.

Так что, даже если Google действительно декомпилировал Windows, вряд ли Microsoft подаст на них в суд. Практика реверсирования широко распространена, и доказать, что Google не использовал для своей работы информацию, поступившую от третьих лиц, будет практически невозможно. Но должны ли вообще возникать сомнения в законности подобных действий? Если бы Microsoft предоставил разработчикам хотя бы самую основную документацию, этого хватило бы, чтобы создатели Chrome могли спокойно делать свою работу.
Вывод

Microsoft (не без основания) считает, что внутренние функции операционной системы, используемые в Chrome, могут меняться от одной версии ОС к другой, и поэтому с большой неохотой придает их огласке. Однако компанию все же заставили пойти на уступки, и некоторые функции NT сейчас преданы огласке либо по решению суда, либо чтобы избежать такого решения. И если бы, с необходимыми оговорками о возможном отсутствии поддержки при последующей эволюции Windows, вся основная документация по системным функциям была бы все же предоставлена, это сделало бы разработку приложений, подобных Chrome, полностью законной. При этом в компании практически ничего не теряли бы – ведь поддержку этих процедур в последующих версиях ОС можно было бы и убрать.

Аналогичным образом, снятие ограничений на изучение кода в Пользовательском соглашении (которые уже сейчас практически потеряли смысл) не стоило бы Microsoft ровным счетом ничего. Оно все равно не избавляет продукты этой компании от угроз, с которыми ей приходится сталкиваться, а если кто-то вознамерится декомпилировать код Windows, он спокойно сможет заняться этим в тех странах, где это не запрещено. А вот помощь разработчикам в выпуске более качественных приложений для ОС этой компании была бы попросту неоценима.

Конечно, в этом смысле у открытого ПО куда больше преимуществ. Но даже слегка приоткрыв завесу тайны над своими продуктами, в Microsoft могли бы создать куда более дружественную среду разработки сторонних приложений для них.

Источник Журнал ][akep

Сразу же после публикации несколько недель назад, исходный код нового браузера Chrome от Google привлек к себе пристальное внимание многих разработчиков. Тому послужило сразу несколько причин: во-первых, в состав браузера входит новая виртуальная машина V8 для выполнения JavaScript, выполняющая скрипты практически без потери скорости, а также движок для визуализации WebKit, который делает всю черную работу по корректному распознаванию и отображению веб-страниц, и, наконец, потому что в браузер внедрена новая система безопасности на основе виртуализации процессов, призванная уменьшить влияние возможных уязвимостей на работу системы. Вот она-то и привлекла в этот раз особое внимание специалистов по причине, которая, возможно, удивит многих. Анализ исходников показал, что Google декомпилировал код Windows, хотя это строжайше запрещено пользовательским соглашением.

Но, прежде чем мы вернемся к вопросу о декомпиляции, взглянем на то, как именно собран Chrome и почему его архитектура безопасности так любопытна.
Архитектура безопасности Chrome

Из всех нововведений, которые Chrome привнес на рынок интернет-браузеров, самым необычным и достойным внимания является его архитектура безопасности. Обычные браузеры (Firefox, Internet Explorer 7 и ниже, Opera, Safari) запускают для всех совершаемых ими действий один общий процесс. Тaк, один-единственный процесс могут делить между собой модули отображения пользовательского интерфейса, соединения с Интернет, разметки HTML и запуска плагинов. Прибавьте к этому и открытие различных вкладок в самом браузере.

Такая модель реализации потенциально имеет множество слабых мест. Самое очевидное из них, это то, что при сбое в одной из вкладок может произойти сбой всего запущенного процесса. Таким образом, деятельность пользователя по открытию вкладок идет насмарку. Есть и менее заметные на первый взгляд нежелательные побочные эффекты. К примеру, не существует никакой особой причины для того, чтобы потенциально опасное приложение имело возможность считывать данные из файловой системы или записывать их. Но, поскольку некоторым модулям такая функциональность необходима (скажем, для загрузки файлов), однопроцессная архитектура делает реальным доступ к этим функциям и для всех прочих частей браузера.
В Редмонде проложили путь

Windows Vista и Explorer 7 первыми нанесли Google удар, немного отступив от своей традиционной однопроцессной схемы. Internet Explorer очень долго строил архитектуру своей безопасности на основании "зон безопасности", которые позволяли применять различные политики фильтрации контента в соответствии с тем, находился ли удаленный источник во внутренней корпоративной сети или в Интернет. Такая концепция стала причиной возникновения широко известной уязвимости, когда потенциально опасные интернет-страницы выдавали себя за внутрикорпоративные и получали все привилегии безопасной зоны. Чтобы противодействовать этому, версия IE7 для Vista запрещает работу с двумя различными зонами безопасности в рамках одного и того же процесса. Браузер, открытый в "Internet Zone" теперь нельзя использовать для того, чтобы открыть страницу в "Intranet Zone"; вместо этого инициируется полностью отдельный процесс iexplore.exe.

Выпущенная ранее в этом году бета-версия IE8 отходит от принципа единого процесса еще дальше. Вместо раздельных процессов для зон безопасности, в этой версии используются отдельные процессы для каждой вкладки, контролируемые общим родительским процессом, отвечающим за интерфейс пользователя. Такой подход предоставляет собой еще более прогрессивную концепцию, чем, та, что применялась в версии IE7 для Vista, поскольку даже при открытии двух вкладок из одной и той же зоны безопасности, они все равно полностью изолированы друг от друга. Поэтому, при ошибке в одной вкладке, общей ошибки браузера не возникает.
IE8 и Предотвращение выполнения данных (DEP)

Другая основная функция защиты IE8 – это поддержка технологии DEP, предназначенной для предотвращения возникновения ошибок переполнения буфера, позволяющих внедрять в запущенный процесс вредоносный код. Традиционно на процессорах с архитектурой x86 память может быть помечена как память только для чтения и выполнения и/или как память для записи. Если ячейка памяти была ранее помечена как память только для чтения, то с нее может быть произведено считывание и выполнение кода. Такая особенность и приводит к возникновению ошибок переполнения буфера. Запущенная программа выделяет себе определенное количество памяти, которая должна быть доступна как для чтения, так и для записи, с тем, чтобы программа могла записывать и позднее возвращаться к результатам ранее произведенных вычислений. Хакеры используют это, чтобы внедрить небольшой фрагмент исполняемого кода в ту область памяти, которая предназначена для временного хранения результатов работы запущенной программы.

Функция DEP разделяет память, предназначенную для чтения, и память предназначенную для выполнения кода. Теперь она может быть помечена как память для чтения и записи, но не как память для выполнения. Это затрудняет осуществление манипуляций с переполнением буфера, но, к сожалению, не лишает их смысла полностью, поскольку для ряда приложений, выполняющих операции по доступу к памяти "на лету", непосредственно в момент проведения вычислений, возможность чтения из областей памяти, предназначенных для хранения, просто необходима. Некоторые более старые приложения, в том числе скрипты на основе ActiveX, могут некорректно работать с DEP, поскольку в свое время их разработчики не предусмотрели возможности такого разделения памяти атрибутов памяти в рамках архитектуры х86. Поэтому, чтобы обеспечить совместимость своего браузера с подобными приложениями, в Microsoft не стали внедрять поддержку DEP для IE7. Но теперь многое изменилось, и IE 8 будет обладать врожденной поддержкой DEP.

Что и приводит нас, в конечном счете, к Chrome. Точно так же, как и IE8, Chrome создает раздельные процессы для каждой из вкладок, даже более того, для каждого из плагинов. И, также как и IE8, Chrome включает DEP для всех своих процессов. Это и заставило некоторых поднять в удивлении брови.
О коде, комментариях и наработках

В Windows есть несколько способов включения DEP, лучший из них – это создание 64-битного процесса. Все 64-битные процессы в обязательном порядке поддерживают DEP и не имеют возможности для маневра. Это – правило без исключений, поэтому такие процессы по умолчанию "понимают" DEP и безопасно его выполняют. К сожалению, использование браузера в 64-битной среде весьма проблематично из-за ограниченной поддержки со стороны сторонних приложений, в первую очередь - Flash.

Поэтому Chrome работает в 32-битной среде, и оперирует 32-битными процессами. Каждый 32-битный процесс может находиться по отношению к DEP в трех состояниях: иметь эту функцию включенной (что хорошо), отключенной (что плохо), либо эмулировать ее через ATL Thunk Emulation. ATL – это библиотека, которой Microsoft снабжает программистов, пишущих приложения для Windows на языке C++ и которая широко используется для создания ActiveX-плагинов для браузеров. К сожалению, более ранние ATL версии плохо написаны и создают исполняемый код, который не помечен как исполняемый (как раз то, с чем призвана бороться DEP). Поскольку такая ситуация, похоже, несколько смущает Microsoft (ведь, в конце концов, ATL – их собственная библиотека), в операционных системах этой компании есть функция, позволяющая выявлять некорректные версии библиотек ATL и обеспечивать для них возможность включения системы защиты DEP, за исключением тех нескольких строк кода, которые вообще не совместимы.

Все это, конечно, прекрасно и дает Chrome возможность получить необходимые ему функции контроля над DEP, с тем, чтобы соблюсти баланс между совместимостью и безопасностью (браузер включает DEP для всех своих процессов и эмулирует эту функцию через ATL Thunk Emulation для сторонних приложений). Есть лишь одна неувязочка. Сама DEP дебютировала в составе XP Service Pack 2 (также ее можно увидеть и в Windows Server 2003 SP1 и во всех версиях Vista и Server 2008). А вот возможность настраивать политику ее применения со стороны процесса появилась лишь в Vista SP1 и Server 2008. В предыдущих версиях DEP также присутствовала, но никакой возможности её контроля со стороны приложений не было.

Поэтому, если мы взглянем на ту часть кода Chrome, которая регулирует применение DEP к внутренним процессам браузера, мы сможем увидеть несколько интересных комментариев:

// Try documented ways first.

// Only available on Vista SP1 and Windows 2008.

Дальше следует несколько строк кода, а затем...

// Go in darker areas.

// Only available on Windows XP SP2 and Windows Server 2003 SP1.

// http://www.uninformed.org/?v=2&a=4

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

// Completely undocumented from Microsoft. You can find this information by

// disassembling Vista's SP1 kernel32.dll with your favorite disassembler.

Данный комментарий был впервые обнаружен Скоттом Хансельманом спустя несколько дней после публикации исходного кода браузера, и он уличает Google в декомпиляции Windows, которая строжайше запрещена Соглашением с конечным пользователем (EULA) этой операционной системы.

Согласно ему, запрещено:

* Разрабатывать какие-либо технические ограничения для этой системы;
* Подвергать реверс-инжинирингу, декомпилировать или разбирать ее на части, за исключением и только в случае выданного через суд разрешения;
* Использовать компоненты системы в составе приложений, для нее не предназначенных;
* Делать больше копий ОС, чем это установлено данным соглашением или предписано законодательством;
* Выкладывать ОС в свободный доступ с целью копирования;
* Продавать, сдавать в аренду или лизинг данную ОС;
* Использовать ОС в коммерческих целях.

Google заявляет о том, что никогда ничего не декомпилировал. В связи с процитированными выше комментариями в Google заявили, что использовали код, опубликованный uninformed.org - интересным, специфическим, редко выходящим журналом по реверс-инжинирингу. По правде сказать, исходный код Chrome действительно содержит ссылку на разъяснения по поводу контроля использования DEP в XP SP2, опубликованные там.

Продолжение
Проделки Chrome: действительно ли Google реверсировал Windows? №2

Источник Журнал ][akep

Существует исключительно полезная как для делового человека, так и для обывателя хрень под названием органайзер. Чтобы записывать планы, номера телефонов, список встреч и свиданий, количество потраченного и потерянного. В качестве органайзера я часто использую сестру и друзей, но если функции оповещения они исполняют исправно, то с хранением нужной МНЕ информации бяда.

Собственно вопрос. Кто-нибудь пользуется органайзером? Если да, то каким??

В общей сложности в блогуне заработано 50 баксов. 10 потрачено на 2 домена.

Сегодня вывел первые 6 баксов из blogun.ru
Из минусов - порядком изгадил свой любимый и родной днев
Изучаемс покер, PPC, дорвеи и прочую seo лабуду