По мне так и такое тоже решение проблемы. Да ход не самый красивый с точки зрения пиара, но вы уверены что у них был большой выбор? А сохранение дистрибутива это уже плюс для многих его поклонников
The binaries distribution is available for testing purposes.
Поглубже порыл.
Нашел ветку форума —
Там написано «Вы можете скомплилить салом для винды, как это сделать —
так что опять ручками и напильником :) Что то меня размер напугал… 400 мегов?
Мне кажется что $5 в год за 20 Гб — это нормально. Сам пользуюсь, и всем рекомендую. Скорость закачки — хорошая, + много фишек в виде тег имён, комментов к фоткам, распределением прав между пользователями для просмотра альбома и многое другое. :)
Забыт один из основных пунктов: этот протокол не должен (или должен с большим трудом) баниться всякими фаерволами.
Логика то простая: если нельзя прослушать, то можно тупо отрезать
Всегда кажется, что тут сидят маньяки-кодеры.
Есть нужная программка? Нету. Ррррраз, и сами запрограммировали :)
Недавно купили цифрик, поэтому вопрос о фотках в самый раз. Сейчас складываю тупо по папочкам. Смотрелка — стабильно IrfanView, особенно люблю за то, что пачками конвертировать умеет.
Вопрос: Какие функции должны быть в «идеальном» каталогизаторе? Тоже искать буду…
1. Мой трафик может попасть в чужие руки, только если и у меня и у всех моих собеседников проблема соединиться из-за файерволов-маршрутизаторов?
Давайте, по порядку.
1. Сценарий без шифрования, SIP (udp/tcp), RTP.
1.1 P-T-P: Тут могут прослушать на пути p-t-p (аттака )
1.2. Proxy: 1.1 + на стороне proxy, начиная от обыкновенного зеркалирования RTP трафика, заканчивая различными 'ами)
2. Сценарий с шифрования сигнализации SIP (udp/tcp), и без шифрования RTP.
2.1. Тут все то же самое, что и в первом пункте, но задача усложняется тем, что вам нужно расшифровать сигнальный трафик, чтоб понять, где у вас ходит (по каким портам) RTP трафик, после чего вы так же спокойно можете его перехватить.
3. Сценарий с полным шифрования сигнализации SIP (sips/tls), и шифрования RTP ( (AES-128)/ HMAC-SHA1/AES-128/AES-256).
3.1 По этому сценарию атака mintm невозможна, т.к. все зашифровано, на стороне же сервера данные можно перехватить в случае проксирования данных, т.к. сервер будет знать информацию о ключах и сможет эти данные распаковать. Как пример, когда на двух сторонах устройства не поддерживают одинаковые кодеки (например, с одной стороны g711, с другой g729), тогда используется проксирование медиатрафика, и на стороне медиа-сервера идет перекодирование RTP потока. Без наличия ключей, RTP поток нельзя будет расшифровать и перекодировать.
2. Будет ли поддержка более двух человек в разговоре? (конференц)
да, video/audio/data (desktop sharing, games, etc), бесплатно.
3. Под какие платформы пишется софт? Мобильные платформы?
все что поддерживает QT (*nix, win, mac, Symbian/S60, Maemo, MeeGo, Windows Mobile)
4. Какова стойксть шифрования, которое вы используете? В переводе на кол-во хайэндовых компов помноженных на часы(дни/года) хотелось бы =).
Пока максимально AES-256, но скорей всего будет возможность выбирать, для продвинутых пользователей.
5. Будет ли открыт код хотя бы для того, чтобы каждый мог сделать его ревью и убедиться в безопасности.
клиент будет полностью открыт, не вижу причин зажимать исходники.
6. Во всей этой схеме наверняка присутствуют деньги. Где они?
Исходящие звонки на ТФоП, телефонные номера (DID), продажа пространства на нашем , если кому-то нужно будет сверх лимита, что дается бесплатно, для записи audio/video/im разговоров, приема и хранения факсов (fax2email, email2fax), приема и хранения голосовых сообщений (voicemail) и распознаных текстов из голосовых сообщений и пр.
А ещё очень хочется поучаствовать в контексте составления юз-кейсов, фич-листов, баг-репортов =)
всенепременно. как только запустим альфу, будет открыт альфа тест, а потом и бета, по инвайтам.
О, круто!
Правильно ли я понимаю, что:
1. Мой трафик может попасть в чужие руки, только если и у меня и у всех моих собеседников проблема соединиться из-за файерволов-маршрутизаторов?
И ещё вопросы:
2. Будет ли поддержка более двух человек в разговоре? (конференц)
3. Под какие платформы пишется софт? Мобильные платформы?
4. Какова стойксть шифрования, которое вы используете? В переводе на кол-во хайэндовых компов помноженных на часы(дни/года) хотелось бы =).
5. Будет ли открыт код хотя бы для того, чтобы каждый мог сделать его ревью и убедиться в безопасности.
6. Во всей этой схеме наверняка присутствуют деньги. Где они?
А ещё очень хочется поучаствовать в контексте составления юз-кейсов, фич-листов, баг-репортов =)
Я так понимаю, голосовые звонки будут ходить по sip'у.
А раз так, то это централизованно — через sip-провайдеров, которые помимо того, что знают когда и кому я звонил, так наверняка могут и слушать мой трафик.
А с ними и каждый негодяй в погонах под предлогом, что я террорист.
Если про Facetime я всё правильно понял, значит он не подходит.
да, Facetime базируется на сигнальном протоколе SIP со всем вытекающим функционалом.
Но SIP так, же как и skype:
1. может работать p-t-p,
2. а так же через сервер (sip registrar) с полным проксированием медиа и сигнального трафика или
3. только сигнального трафика.
В 1 и 3 случае RTP трафик ходит напрямую, как и в скайпе, во втором через центральную систему, которая может быть размазана по всему земному шару.
Кстати, skype так же, прослушивается спецслужбами, поэтому особо доверять суждениям, что он якобы защищен от прослушки я бы не стал:
Вот это интересно. А где о вас или вашей разработке почитать можно?
как только закончим разработку и тестирование, обязательно опубликуем тут и на других ресурсах информацию о сервисе с детальным описание архитектуры и исходными кодами.
У вас всё тоже централизованно?
У нас схема, описанная выше:
1. Базовый обмен данными (im, voice, video, data) идет p-t-p
2. Если проблемы с p-t-p (nat, firewall), то идем через stun/turn/ice
3. Если проблемы с stun/turn/ice то идем через полное проксирование
Сама система размазана по миру и при DNS запросах выдаются данные по ближайшему кластеру к клиенту, для уменьшения latency.
А новый функционал, на мой взгляд, может и подождать до следующего релиза. ;-)
В некоторых ситуациях новый функционал может быть очень критичен.
В виндах, например, свежий релиз юзер может сразу скачать и поставить. Вот чтобы так же можно было и в убунте, делают эту поддержку, как я понял.
Поглубже порыл.
Нашел ветку форума —
Там написано «Вы можете скомплилить салом для винды, как это сделать —
так что опять ручками и напильником :) Что то меня размер напугал… 400 мегов?
irc://irc.freenode.net:6667/fireforge
188.40.64.42
ЗЫ: куда стучаться, когда fireforge падает?
Логика то простая: если нельзя прослушать, то можно тупо отрезать
Есть нужная программка? Нету. Ррррраз, и сами запрограммировали :)
Недавно купили цифрик, поэтому вопрос о фотках в самый раз. Сейчас складываю тупо по папочкам. Смотрелка — стабильно IrfanView, особенно люблю за то, что пачками конвертировать умеет.
Вопрос: Какие функции должны быть в «идеальном» каталогизаторе? Тоже искать буду…
если есть идеи, пишите в личку.
если в планах такой фичи нет, то обязательно реализуем, в зависимости от фичастости фичи, раньше или позже. ;-)
нет проблем, как только откроем, скину invite в личку.
btw мы тут большой offtopic развели.
А сейчас нельзя в какой-нить багтрекер фичреквестов написать?
И альфатестером хочу =)
Давайте, по порядку.
1. Сценарий без шифрования, SIP (udp/tcp), RTP.
1.1 P-T-P: Тут могут прослушать на пути p-t-p (аттака )
1.2. Proxy: 1.1 + на стороне proxy, начиная от обыкновенного зеркалирования RTP трафика, заканчивая различными 'ами)
2. Сценарий с шифрования сигнализации SIP (udp/tcp), и без шифрования RTP.
2.1. Тут все то же самое, что и в первом пункте, но задача усложняется тем, что вам нужно расшифровать сигнальный трафик, чтоб понять, где у вас ходит (по каким портам) RTP трафик, после чего вы так же спокойно можете его перехватить.
3. Сценарий с полным шифрования сигнализации SIP (sips/tls), и шифрования RTP ( (AES-128)/ HMAC-SHA1/AES-128/AES-256).
3.1 По этому сценарию атака mintm невозможна, т.к. все зашифровано, на стороне же сервера данные можно перехватить в случае проксирования данных, т.к. сервер будет знать информацию о ключах и сможет эти данные распаковать. Как пример, когда на двух сторонах устройства не поддерживают одинаковые кодеки (например, с одной стороны g711, с другой g729), тогда используется проксирование медиатрафика, и на стороне медиа-сервера идет перекодирование RTP потока. Без наличия ключей, RTP поток нельзя будет расшифровать и перекодировать.
да, video/audio/data (desktop sharing, games, etc), бесплатно.
все что поддерживает QT (*nix, win, mac, Symbian/S60, Maemo, MeeGo, Windows Mobile)
Пока максимально AES-256, но скорей всего будет возможность выбирать, для продвинутых пользователей.
клиент будет полностью открыт, не вижу причин зажимать исходники.
Исходящие звонки на ТФоП, телефонные номера (DID), продажа пространства на нашем , если кому-то нужно будет сверх лимита, что дается бесплатно, для записи audio/video/im разговоров, приема и хранения факсов (fax2email, email2fax), приема и хранения голосовых сообщений (voicemail) и распознаных текстов из голосовых сообщений и пр.
всенепременно. как только запустим альфу, будет открыт альфа тест, а потом и бета, по инвайтам.
Правильно ли я понимаю, что:
1. Мой трафик может попасть в чужие руки, только если и у меня и у всех моих собеседников проблема соединиться из-за файерволов-маршрутизаторов?
И ещё вопросы:
2. Будет ли поддержка более двух человек в разговоре? (конференц)
3. Под какие платформы пишется софт? Мобильные платформы?
4. Какова стойксть шифрования, которое вы используете? В переводе на кол-во хайэндовых компов помноженных на часы(дни/года) хотелось бы =).
5. Будет ли открыт код хотя бы для того, чтобы каждый мог сделать его ревью и убедиться в безопасности.
6. Во всей этой схеме наверняка присутствуют деньги. Где они?
А ещё очень хочется поучаствовать в контексте составления юз-кейсов, фич-листов, баг-репортов =)
да, Facetime базируется на сигнальном протоколе SIP со всем вытекающим функционалом.
Но SIP так, же как и skype:
1. может работать p-t-p,
2. а так же через сервер (sip registrar) с полным проксированием медиа и сигнального трафика или
3. только сигнального трафика.
В 1 и 3 случае RTP трафик ходит напрямую, как и в скайпе, во втором через центральную систему, которая может быть размазана по всему земному шару.
Кстати, skype так же, прослушивается спецслужбами, поэтому особо доверять суждениям, что он якобы защищен от прослушки я бы не стал:
как только закончим разработку и тестирование, обязательно опубликуем тут и на других ресурсах информацию о сервисе с детальным описание архитектуры и исходными кодами.
У нас схема, описанная выше:
1. Базовый обмен данными (im, voice, video, data) идет p-t-p
2. Если проблемы с p-t-p (nat, firewall), то идем через stun/turn/ice
3. Если проблемы с stun/turn/ice то идем через полное проксирование
Сама система размазана по миру и при DNS запросах выдаются данные по ближайшему кластеру к клиенту, для уменьшения latency.
В некоторых ситуациях новый функционал может быть очень критичен.
В виндах, например, свежий релиз юзер может сразу скачать и поставить. Вот чтобы так же можно было и в убунте, делают эту поддержку, как я понял.