логин: 
Другие записи за это число:
2011/09/28_mail - Наша почта №064
<< предыдущая заметкаследующая заметка >>
28 сентября 2011
Про сервер binoniq и концепции безопасности

Думаю, где-то в ноябре всерьез взяться за проект, чтобы к Новому году наконец открыть binoniq.net как публичный дневниковый сервис, и пусть уже начнет жить. А то этот долгострой мне уже самому надоел. Размышляю над концепцией безопасности.

Как известно, концепций безопасности три. Грубо говоря:

1. «ПНХ — Пожалуйста не хулиганьте!» Это концепция Виндоус, когда предполагается, что почти все люди честные, а если кто-то проник на территорию нечестный, то его пусть найдет специальный мент-антивирус, который время от времени патрулирует территорию.

2. «ДПС — Документы покажи сцуко!» Это концепция UNIX, в ней предполагается доступ на территорию только для проверенных лиц, имеющих такие документы, которые подделать невозможно.

3. «ХЕК — Хоть ебись конем!» Это концепция UNIX-Jail и, например, нынешних устройств Apple. В ней чужая программа может творить всё, что угодно, но она так надежно изолирована от остальных, что никому вреда причинить не может.

Например, в моем дневнике работает концепция ДПС: админский доступ имею только я, админ, которому сервер может безгранично доверять. В ЖЖ, например, концепция безопасности, близкая к ПНХ: специальные системы многократно проверяют контент пользователя и DOM-модели, чтобы вычистить любой вредоносный код, который мог бы внести в свою страницу какой-нибудь из пользователей.

Мне почему-то кажется, что для binoniq.net надо попытаться брать Эпловскую концепцию — ХЕК. То есть разрешать любой JS и не париться. Ей богу, при том объеме возможностей, которые я хочу давать пользователю (включая создание собственного дизайна), я не осилю фильтрование всех пользовательских скриптов, онкликов и уязвимостей css, которые постоянно изобретаются все новые и новые. Да и зачем? Лучше спроектировать систему так, чтобы пользовательский JS не смог причинить вреда другим пользователям. И пусть каждый владелец дневникового аккаунта получит право писать у себя любой JS в коде страницы. А что страшного?

Собственно, что может сделать злоумышленник, способный разместить JS?

1. Накидать всяких вирусов и понастроить говна, но это мы просто удалим, как заметим, а у кого уязвимый браузер, тот может подцепить вирус и в другом месте, это не наши проблемы.

2. Украсть чужие куки авторизации.

3. Заставить другого посетителя от своего имени невольно выполнить какие-то действия в своем блоге, например сделать новый пост или удалить свою последнюю заметку.

С кражей чужих кук — вопрос решается привязкой куки к IP. Если ты украл чужую авторизацию, то она у тебя с твоего IP не заработает. А если у самого пользователя сменился IP? Это решается введением второго домена, недоступного для атак. В принципе, если речь идет о куках, нам бы даже хватило домена www.--//-- — с точки зрения браузера (поправьте, если я ошибаюсь, но мне помнится, что во всех браузерах так) — это совсем другой сайт со своими куками. Но вроде бы другие хранилища данных (браузерные хранилища, например) так не считают, и http://www.site для них такой же, как http://site, разве нет? Впрочем, не беда, не зря же мы регистрировали вместе с binoniq.net еще и binoniq.ru — вот он и пригодится как вторая поляна.

Система простая: у посетителя есть две авторизованные куки — одна для binoniq.net (где зоопарк аккаунтов и чужих скриптов), и она привязана к IP. Другая для binoniq.ru (закрытый неприступный сайт с одной лишь страницей) — к IP не привязана. Если сменился IP, посетитель временно перекидывается на binoniq.ru, там проверяется его кука для binoniq.net, и если авторизация есть, то возвращается на binoniq.net с командой восстановить куку binoniq.net для нынешнего IP. И с этой кукой посетитель живет, пока снова IP не сменится. Злоумышленник со своими скриптами сможет украсть у посетителя только куку с того же binoniq.net, привязанную к IP, а куку вспомогательного сайта украсть не сможет — вспомогательный сайт недоступен для запуска скриптов.

Остается лишь последняя проблема: как сделать так, чтобы твой браузер от твоего имени не выполнял команды админа, продиктованные злоумышленником, чей дневник ты зашел почитать. Например, я зашел почитать дневник pupkin.binoniq.net, а там JS-команда majax('editor.php',{action:'delete',zametka:345}) — и мой браузер послал на сервер аякс-сигнал от моего имени удалить в моем дневнике заметку 345.

Я думаю, эта проблема тоже решается — созданием уникальных хэшей, при которых команды админа действовали бы только при открытии своего домена leo.binoniq.net или страниц, принадлежащих админу.

Но вот эту часть я пока не очень продумал, потому что в пределах РОДНОГО домена существует возможность подгрузить в невидимом iframe любую другую страницу. То есть, если я правильно понимаю, злоумышленник может сперва средствами JS подгрузить в iframe leo.binoniq.net/245.html, получить доступ к содержимому этого iframe целиком, прочитать там любой секретный хэш и использовать его, сформируя команду: majax('editor.php',{action:'delete',zametka:345,secret_hash:0B34C4A3F8E})

Вопросы к вам:

1. Какие еще неприятности, кроме трех вышеописанных, могут появиться после разрешения использования JS любым пользователям?

2. Каким еще остроумным способом можно запретить браузеру на чужих страницах выполнять команды от имени админа?

PS: В связи с невероятным количеством кретинов в комментах, которые сразу начнут засирать поляну и петросянить, все комментарии скрываются, и я буду раскрывать только ваши — которые умные и по делу.

<< предыдущая заметка следующая заметка >>
пожаловаться на эту публикацию администрации портала
Страницы, которые привлекли мое внимание за последние дни, рекомендую:
2017-11-22 В июне 1982
архив ссылок

Комментарии к этой заметке скрываются - они будут видны только вам и мне.

Оставить комментарий
Linux Opera
3
2
[email protected]Дмитрий (kastaneda)
Во-первых, всегда нужно делать CSRF protection (да, это решается через уникальные хеши). Следует исходить из того, что злоумышленник всегда может сделать img src=admin.php?action=delete или POST с аналогичным смыслом через hidden iframe, причём сделает это не сам, а сделает это твой браузер с твоими куками на странице злоумышленника.

Во-вторых, в пределах одного домена лучше не пытаться ничего разграничивать. А за пределы домена враг JS не пройдёт — средствами JS подгрузить левый iframe ты сможешь, но не сможешь ничего оттуда прочесть.
Linux Firefox
 Москва
1
0
Проблема в том, что у нас на одном домене есть два дневника: lleo.binoniq.net и hacker.binoniq.net Это данность многопользовательского сервиса. И надо сделать так, чтобы браузер lleo, зашедший случайно на hacker.binoniq.net, не выполнял его JS-команд так, чтобы это имело последствия.

Где я должен разместить уникальный хэш? Допустим, сервер выдает уникальный хэш "var unichash=356124356712;" только админу lleo и только при запросе его родных страниц lleo.binoniq.net/* Но что мешает хакеру с hacker.binoniq.net заставить браузер lleo открыть iframe 1x1 lleo.binoniq.net, а затем прочитать его содержимое - сервер-то один, binoniq.net?
Windows Safari Chrome
2
0
taskmgr
Домены lleo.binoniq.net и hacker.binoniq.net - это разные домены
Linux Firefox
 Москва
0
0
Вот это неясный для меня вопрос, буду рад, если кто-то прояснит.

Например, я точно знаю, что куки lleo.aha.ru во многих браузерах изумительно читались на mat.lleo.aha.ru - из-за этого пришлось закрыть пару очень нужных и симпатичных проектов ;)

Но это только куки. А хотелось бы понимать это еще и для браузерных хранилищ.
Windows Safari Chrome
0
0
taskmgr
насколько я понимаю, куки читались только потому, что mat.lleo.aha.ru - это поддомен домена lleo.aha.ru
В хранилищах я профан
Windows Safari Chrome
0
0
Артём (#1023153)
надо просто идти в другую сторону - можно ли читать куки от mat.lleo.aha.ru на lleo.aha.ru, и на xren.lleo.aha.ru? скорее всего ответ - нет, и значит "действия" можно навесить на bioniq.net, а "данные" можно тянуть с *.binoniq.net и тогда каждый iframe окажется в песочнице.
Windows Firefox
1
0
Crio (#1026007)
Насколько я знаю, совместимость идет сверху вниз.
Таким образом, куки lleo.aha.ru будут читаться на mat.lleo.aha.ru. Но куки mat.lleo.aha.ru не должны читаться на nemat.lleo.aha.ru
Linux Firefox
2
0
AVEL (#1092431)
>Например, я точно знаю, что куки lleo.aha.ru во многих браузерах изумительно читались на mat.lleo.aha.ru

Это верно. Поддомены могут читать куки своих родителей.

А вам предлагали сравнить разные домены - pupkin.bionic.ru и lleo.bionic.ru, а не pupkin.bionic.ru и bionic.ru

В этом случае прочитать куки можно будет только в том случае, если они записаны с общим путем. То есть pupkin.bionic.ru сохранил куку c путем bionic.ru и lleo.bionic.ru ее прочитал, потому что кука привязана к его поддомену.
Windows Firefox
2
0
Илья Весенний (#433679)
Гугловый blogspot.com никак не ограничивает размещение JS-скриптов, но почему-то о проблемах с этим я не слышал.

Возможно, удастся подсмотреть, какими средствами гугл обеспечивает безопасность юзеров своего сервиса, посещающих страницы других юзеров этого же сервиса? Леонид, если есть на это время, то Вы или поймёте, как они это сделали, или найдёте дыру в их системе, что тоже будет полезно :)
Linux Firefox
 Москва
0
0
Интересно. И приятно, что такое возможно. К сожалению, у меня нет возможности изучать blogspot - это огромное количество человекочасов, да и не факт, что удастся понять принцип "снаружи", не имея доступа к коду серверной части. Может, у кого-то есть предположения? Или кто-то из пользователей blogspot сможет рассказать о каких-то особенностях авторизации, как она происходит и в каких случаях слетает, и по этим косвенным сведениями мы сможем догадаться о принципах?
Windows Safari Chrome
5
0
Артём (#1023153)
Исследовал вопрос как это работает в blogspot - сами посты открываются c farafonoff.blogspot.com, а навигационная панелька с действиями - с blogger.com. Форма комментария аналогично находится в другом iframe. Итого, все будет работать если каждый элемент страницы будет загружаться в свой iframe со своего домена. Тогда пост от hacker.binoniq.net попадет в свой iframe.
Windows Safari Chrome
4
0
Артём (#1023153)
1) На вскидку - есть много сайтов с уязвимостью типа XSS. С помощью вашей системы их станет легче эксплойтить.
2) Флэш - окошки на весь экран.
3) процессорожрущий js

это все варианты проблемы 1, и ваше решение "просто удалим" видится мне очень трудоемким.

по проблеме 3.

Единственное на мой взгляд решение - использовать капчу. Я говорю не про цифры на картинке, а про идею разделения людей и роботов интеллектуальной задачкой. в тот момент когда злоумышленник загрузит свой javascript на странице - он сможет делать все что может делать с этой страницы пользователь. Если там есть кнопка удалить - он сможет на нее нажимать. Ну или как вариант требовать повторной авторизации для совершения таких действий. Не зря ведь для смены пароля на всех сервисах спрашивают старый пароль - это единственная защита от xss.

Описание конкретной дырки на vkontakte
http://habrahabr.ru/blogs/infosecurity/62283/

Обзор последствий xss на сайте.
http://habrahabr.ru/blogs/infosecurity/66057/
Linux Firefox
 Москва
2
0
Нет, бесплатно решать на СВОЕМ сервисе проблемы ЧУЖИХ сервисов - эта идея запредельно странная. Если на сервисе Пупкина есть уязвимость, пусть он ее и затыкает. А не бегает по сети и не просит всех остальных запретить у себя JS, чтобы с вашего сайта кто-нибудь вдруг не атаковал мой, где дырка была, есть и будет.

Я не вижу в вашем перечислении опасности для остальных пользователей сервиса. Допустим, некто завел аккаунт hacker.binoniq.net и и установил там рекламные баннеры, флэш на весь экран, загрузку пользовательского процессора и скрипты для атаки на сайт Одноклассников. И что? Кто к нему зайдет на hacker.binoniq.net? Первый же, кто зайдет - напишет жалобу, и аккаунт будет удален. А регистрация нового аккаунта у нас будет стоить, например, 15 рублей - специально, чтобы таких мудаков отсечь. Иди регистрируй hacher2 - но и его тоже закроют, когда заметят. В чем проблема?

Это всё та же концепция ХЕК. Теоретически, вы можете написать для iPhone вредоносную программу, залить ее на iStore и продавать или раздавать бесплатно - никто в Apple ваш код детально изучать не станет. Но остальным пользователям iPhone она не сможет причинить вреда, никакие данные выкрасть не сможет (ибо Jail), а по первому же сигналу ее из iStore выпилят и аккаунт вам закроют.

Идея с капчей, конечно, хороша и достаточно логична. Но она, увы, очень неудобна. Особенно в моем движке, где все админские действия заточены под мгновенное реагирование.
Windows Safari Chrome
0
1
Артём (#1023153)
Передать уникальный хэш из фрейма в фрейм на самом деле возмножно - вот что нашел в интернете:
http://javascript.ru/ajax/cross-domain-scripting

Соответственно статику, навигацию и всякие кнопки добавить-удалить надо тянуть с другого, доверяемого домена (bioniq.ru). Правда тогда в нем будет далеко не одна страница.

XhrIframeProxy

Из смеси XMLHTTPRequest и Iframe получается оригинальный хак, называемый XhrIframeProxy. Он позволяет делать кросс-доменные запросы XmlHttpRequest, и успешно протестирован в Internet Explorer 6/7, Firefox 1.5+, Safari 2.0.3 и Opera 9.

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

Идентификатор фрагмента - это то, что идет в URL после решетки: http://site.com/path/to/file.html#fragment.

Документ, загруженный в IFrame, может менять идентификатор фрагмента родительского документа (т.е документа, содержащего iframe). Изменение фрагмента не приводит
к перезагрузке страницы. И, аналогично, родительский документ может менять идентификатор фрагмента в ифрейме.

Путем последовательных изменений #фрагмента образуется поток данных, который может передаваться в обе стороны. Т.к идентификатор фрагмента - текст, то все данные для передачи приходится (де)сериализовать, т.е превращать в JSON.
Linux Firefox
 Москва
1
0
Тут вы не понимаете, о чем говорите.

Чтобы передать что-то из iframe в РАЗНЫХ сайтах, надо чтобы ОБА сайта приложили некоторые усилия по организации этого транспорта. Если страница, загруженная с binoniq.ru, не собиралась ничего передавать в главное окно на binoniq.net (использовать протокол message в новых браузерах или шевелить #фрагментом url в старых), то никакого транспорта не выйдет, хоть ты там бейся лбом.

Другое дело, если iframe загружен с ТОГО же сайта. Здесь, насколько я понимаю, можно хоть его document.innerHTML посмотреть, хочет он того или нет, - такова политика браузерной безопасности.
Windows Safari Chrome
0
0
Артём (#1023153)
соответственно надо всю навигацию грузить с binoniq.ru, тогда все будет правильно.
Linux Firefox
 Москва
3
2
Зашел по ссылке.

...«vkontakte.ru», к скрипту, выполняющему поиск. Как известно, после процедуры поиска текст запроса выводится обратно пользователю, этим (а также отсутствием должной фильтрации) и воспользовались спамеры...

Бля, ну это ж вообще детский сад, это ж азы безопасности. Если целая команда профессиональных программистов, сидящих на зарплате, в таком глобальном проекте, допускает ТАКИЕ дыры, я считаю, их надо расстреливать.
Windows Opera
 Подольск
0
0
Tiger (#1079102)
По поводу безопасности вот такая неплохая статейка http://habrahabr.ru/blogs/infosecurity/126409/

Можно взять на вооружение основные способы оттуда (в частности все эти формы с автосабмитом и прочее) и заранее сделать защиту.
Windows Safari Chrome
0
0
Артём (#1023153)
Искал эту статью, чтобы показать lleo, но нашел пару других. В целом самое здравое - использовать разовые токены на каждое действие.
Linux Ubuntu Safari Chrome
0
0
Максим (#1119063)
фишинг? нарисовать страничку как страничка логина и упереть логин с паролем, например.
Linux Firefox
 Москва
1
0
Да не, это детский сад. Если пользователь не удивился тому, что у него потерялась авторизация (а мы будем делать так, чтобы ее потерять было затруднительно), да еще готов ввести пароль на странице, не поглядев, что там... То это он может сделать и на любом другом сайте. Зашел на пупкин.com - там предложили ввести пароль в дизайне для binoniq.net :)
Windows Firefox
0
0
slurmer
Сразу предупрежу - я в этих ваших программированиях ничерта не смыслю, НО. Возможно вы как-то сможете использовать идею.
В электронном банке, которым я пользуюсь есть так называемые "картинки безопасности". Т.е при регистрации я выбираю одну из предложенных картинок. И в дальнейшем, когда ввожу пароль - всегда вижу эту картинку рядом с окном ввода. Суть мне кажется в том, что никто кроме меня эту картинку не видти, и не знает, которую я выбрал при регистрации. Соответственно если злоумышленник делает фишинговый сайт и копирует мой дизайн, картинку безопасности он один фиг правильную не подберет (подберет с очень малой вероятностью, которая тем меньше, чем больший выбор картинок).
Linux Firefox
 Москва
0
0
Это относится лишь к очень чужому сайту, откуда делается фишинг.

Если фишинг делает сосед по сайту, не вопрос вытянуть имя именно вашей картинки. Если же по имени не понятно, то есть теперь canvas HTML5, который может заполучить содержимое картинки.

У меня, правда, пока не удалось, я не очень разбирался, но говорят, работает. Отныне содержимое картинки - не секрет, известный лишь тому, кто смотрит снаружи на поверхность дисплея.
Linux Ubuntu Safari Chrome
0
0
Максим (#1030743)
Ну если можно украсть куку то можно и стереть её, или сменить на левую. И авторизация действительно потеряется. А на настоящую ссылку для логина навешать обработчик, чтобы перекидывал куда надо злоумышленнику, домен будет правильный, и более того система потом сможет нормально залогиниться, а логин\пароль налево уйдут. Я не говорю, что это прям 100% надёжная уязвимость. Но захватить несколько аккаунтов невнимательных пользователей можно. Кстати, помимо 2-го домена, можно рассмотреть вариант с etag, он тоже для JS недоступен, а серверу браузеры его возвращают.
Windows Firefox
0
0
Maxim Starikov (#1001352)
Насколько я понимаю, использование поддоменов полностью решает вопрос с безопасностью: www.lleo.me и lleo.me будут РАЗНЫМИ доменами для браузерных кук если при создании куки это указать (с.м. параметр 5 для PHP фунции setcookie) по умолчанию субдомены одного сайта видят куки родительского сайта но вот если указать только один конкретный - то ситуация волшебным образом изменится к лучшему. Для авторизации же пользователей на разных поддоменах и можно использовать тот волшебный редирект о котором вы писали для идентификации пользователя при смене IP.
Linux Firefox
0
0
murrmax (#1060384)
ну например, если ваш сервис будет использоваться как хранилище вредоносов, которые будут загружаться с каких-нибудь других, чуть менее уязвимых но более посещаемых сайтов через XSS, то претензии хостеров и борцунов с вирусами будут идти к вам, что может закончиться отключением сервера или разделегированием домена.
Linux Firefox
 Москва
1
0
Вам же русским языком говорят: сервис не будет использоваться как хранилище вредоносов, все вредоносы будут удаляться, как только обнаружатся. Вас послушать, так вообще никакой сервис не надо делать, и даже комментарии у меня в дневнике следует запретить - вдруг их кто-нибудь использует для публикации детской порнографии, рецептов наркотиков или инструкций по взлому чужих компьютеров?
Windows
0
0
[email protected]Леша (lesha)
Еще можно подумать в сторону вики-стиля.
В том смысле что не делать необратимых действий (любое можно отменить) и вести лог для пользователя что "он" недавно сделал из админ-команд.

Это требует больше ресурсов для хранения, но более лояльно для пользователя.

Т.е не переспрашивать "вы действительно хотите удалить это сообщение", а удалять сразу, но при этом чтобы была возможность его восстановить.

Мысль не новая - всякие "Trash" в почтах, для файлов и т.п Ну и в вики движках - история редактирования.

Применимо для защиты от вреда пользователю (удаления, правки), но не применимо при рассылке спама.

Заодно защитит пользователя от себя же (в состоянии опьянения или под дулом пистолета ;) или от краж техники (мобилок, ноутов).
Linux Firefox
 Москва
0
0
Это тоже будет, но позже. Другой уровень защиты и сервиса, не о том сейчас.
Windows Firefox
1
0
Никк
>а у кого уязвимый браузер, тот может подцепить вирус и в другом месте, это не наши проблемы

Тогда посетители будут кричать, что "там вирус, пацаны", и посещаемость резко снизится
Linux Firefox
 Москва
4
1
Бля, посещаемость... Да нахуй она нужна, посещаемость? К нашему берегу приплывет - не говно, так палка. Тут не знаешь, как ее снизить, посещаемость, а он напугал... :)
Windows Firefox
0
0
Reist
http://my.opera.com/yngve/blog/?id=267415

Here at Opera we went for the rule-of-thumb method: When Opera is checking a cookie whose target domain matches certain criteriea (e.g. it is not a .com domain), we do a DNS name lookup for the target domain, to see if there is an IP address for that domain. If there is an IP address for the domain (e.g. example.no) we assume that the domain is a normal company domain, not a co.uk like domain, and therefore safe. If there is no IP address we assume that the domain is co.uk-like and therefore unsafe, and only allows the cookie to be set for the server that sent the cookie.

По-моему все браузеры обрабатывают подобную ситуацию по-разному. Единственный вариант, который я для тебя вижу - не использовать куки на этом домене вообще.

В общем случае name.lleo.me может ставить куки и на name1.lleo.me, и на lleo.me
Windows Firefox
0
0
Reist
Вообще, почему бы тебе не сделать все действия как в социальных плагинах для контакта или фейсбука, принципиально на другом домене? То есть будет два домена, binoniq.net который может только читать и binoniq-authorize.net в котором люди будут регаться, логиниться, админить блоги, и через который будут отправляться посты (видимо через iframe)
Linux Firefox
 Москва
1
1
Ну примерно о том и речь, но хотелось бы все-таки изучить возможность использования одного домена как admin.binoniq.net vs все-остальные.binoniq.net

В частности потому, что я строю не столько binoniq.net, сколько движок ВООБЩЕ, который предлагается для свободной установки на любой домен, чтобы получившийся конгломерат движков имел такие преимущества, как общая система френдлент, френдования, обмена интересами и т.п. Не прикольно строить новый сайт-блогохостинг, их и так дофига, прикольно строить распределенную сеть. Которую никто больше строить не будет, потому что все хотят застолбить домен и нарубить под проект бабла, а я ради чистого искусства ;)
Windows Firefox
0
1
Reist
А как ты в таком случае представляешь себе работу, например, френдленты, или списка друзей?

Если ты хочешь сделать движок с возможностью установки его на свой сервер, то я вижу три варианта:
1) Центральный сервер (примерно как сейчас работают коменты для фейсбука, только с немного другими функциями)
2) Клиентский вариант с загрузкой необходимой информации (тормоза при просмотре профиля, вообще не понятно, как быстро загрузить вторую страницу френдленты)
3) Кеширование данных на конечном сервере (Возможная рассинхронизация при простейшей реализации, потенциально куча других проблем)

Если же ты просто хочешь хостить все на своей машине, но на любом домене, то я опять-таки рекомендую обратиться к схеме фейсбука, потому что она на 100% отвечает твоим критериям: единая система, которая обрабатывает действия пользователей (facebook.com), и куча сайтов со своими скриптами и потенциальным желанием украсть авторизацию. Хочу особо отметить, что в твоем случае сайт будет не настолько громоздким, потому что не требуется загружать сами коменты в iframe.
Linux Firefox
 Москва
1
0
Френдлента работает так:

http://lleo.me/blog/friends

Во всем остальном - я лучше сперва сделаю, а потом объясню. Уже много писал о том, что такое распределенная сеть движков и как она должна работать, поэтому любое повторение сейчас лишь будет отодвигать нас от достижения цели.
Windows Safari Chrome
2
2
imka (#1021029)
Слушай, а ты ТОР-сервер уже прикрутил туда хотя бы? Дело полезное, пока то да сё решаешь, он бы уже работал =)
Linux Firefox
 Москва
1
1
Что это такое?
Windows Safari Chrome
0
0
imka (#1021029)
The Onion Router, TOR, — гибридная анонимная сеть луковой маршрутизации; система, обеспечивающая анонимность в интернете. http://ru.wikipedia.org/wiki/Tor
Nokia-E90 Safari
3
1
LLeo Nokia E90 (#1165175)
Ну, это нам вообще нахрен не нужно.
Windows Safari Chrome
0
0
imka (#1021029)
ну это пока никто не обзовёт распутина "пидорасом", очевидно же.
Леонид, доброго дня!
С интересом слежу за Вашими придумками насчёт Биноника, многое из озвученного кажется крайне интересным. Если будет возможность, хотелось бы зарегистрировать свой дневник.
Вот такие два вопроса назрели по Бинонику, один из них некоторым образом связан с вопросами, интересующими Вас, второй - оффтоп, хотя и про будущий проект.

1. Как Вы относитесь к идее создания в Бинонике нескольких уровней аккаунтов (по примеру ЖЖ, только похитрее как-то)? Например, базовый функционал (свой несложный html/css-дизайн без скриптов, публикация постов, формирование френд-ленты) разрешить всем сразу после регистрации, а для каких-то более сложных манипуляций, вроде выполнения произвольного JS сделать премиум-аккаунты, которые можно будет получить либо за денюжку, либо за хорошее поведение (а-ля "активно попользовался дневником N лет без жалоб со стороны других юзеров - получи цацку"). Может ли такая схема помочь или нет смысла?

2. Будет ли в Бинонике в будущем возможность интернационализации интерфейса? Раз разрабатывается не только блогохостинг, но и универсальный движок в целом, резонно предположить, что им захочется воспользоваться не только русскоговорящим пользователям.

Извиняюсь, если вопросы покажутся глупыми и неинтересными - с веб-программированием знаком слабо :)
Nokia-E90 Safari
0
0
LLeo Nokia E90 (#1165175)
Коротенечко нашел в Мариотте ВайФай.

1. Конечно будет. Но сперва надо запустить базис.

2. Национализация интерфейса предусмотрена уже в нынешнем движке. Она пока не везде, но механизм прост: есть текстовый файл ru.lang со всеми переменными. Просто создается рядом fghfghc.lang c построчным переводом, а язык системы меняется в конфиге на "fghfghc".
Windows Firefox
0
0
Руслан (#1167916)
Я смотрю на $_SERVER['HTTP_ACCEPT_LANGUAGE'] ,вырезаю первые два символа,проверяю их на совпадения с массивом разрешенных языков и подключаю:
include 'lang/'.$lg.'.php';
В lang/ru.php находится массив типа
$n['Берёза']=$n['Берёза'];
...
...
А в lang/en.php находится массив
$n['Берёза']=$n['Birch'];
...
плюс ещё парсер и редактор
этих языковых файлов в parser.php
Nokia-E90 Safari
 Москва
2
0
LLeo Nokia E90 (#1165175)
У меня структура языка немного хитрее, она позволяет писать сложные переменные с подстановками и даже условными ветвлениями:

http://lleo.me/dnevnik/module/lang/ru.txt

Тут главный вопрос, чтобы когда сервис заработает, кто-нибудь перевел, как сайт нахуй :)
Windows Firefox
0
0
petr (#408931)
> а у кого уязвимый браузер, тот может подцепить вирус и в
> другом месте, это не наши проблемы.
браузер сегодня неуязвимый, а завтра дыру нашли.
поэтому лучше сделать так:
- завести базу проверенных скриптов, для начала положить туда, например, скрипты этого движка.
- если страница содержит что-то непроверенное, выдавать пользователю сообщение что-то типа "тут скриптотворчество автора страницы, мы предупредили, за него не отвечаем, за Вас тоже"
- чтоб это сообщение не заебывало, галку "Вася мой лепший кореш, я ему доверяю, больше на его странице мне окошко с хуйней не показывать" Ключевой момент - чтоб оно помнило, что Васиным скриптам я доверяю, а не Васины даже с бесплатной порнухой не хочу открывать.
- для совсем в себе уверенных галку "мой браузер неуязвим, ни о чем меня не спрашивать"
Linux Firefox
 Москва
1
0
Концепция биноника будет разрешать любому пользователю писать ЛЮБОЙ свой скрипт.

Задача движка лишь в том, чтобы обезопасить остальных пользователей от кражи авторизации и выполнения админских действий в чужих аккаунтах. Это чисто техническая задача.

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

Все остальные проблемы - не наши проблемы. Если вы считаете, что вам в интернете может встретиться вредоносный скрипт, который нанесет ущерб вам и вашему браузеру, то вы вообще не должны свободно серфить по интернету. Вам следует пользоваться лишь двумя-тремя "проверенными" сайтами типа gmail.com

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

всего комментариев: 74

<< предыдущая заметка следующая заметка >>