Comments 12
Интересно было, мне понравилось, но имхо самые классные проекты в конце были. И кроме проектов еще круто было бы рассказать про круглый стол по предпринимательству (хотя от всего 45 мин. был).
интересно, и желательно побольше слов, интересно о идеях проектов. ну а так же победителях и о всем остальном.
Моя девушка выступала на конференции с идеей подобной первой год назад и получила там диплом, я делал что-то подобное второй идее (и даже почти доделал на самом деле) и мне и ей в универе сказали что это на диплом не катит и вообще сомнительно перспективно, в связи с чем обе разработки были заброшены… Интересно что сказали этим реализаторам идеи?
ну по поводу «Лукоморья» жюри сошлось на мнении что дети это важно, но уж очень сырой проект (2 месяца). Идей много: разные костюмы для разных регионов, совместное прохождение квестов, подстройка игры под каждого ребёнка и многое другое, а показали они только видео с выбором персонажа и настройки. А про РГУ им. И. Канта согласен, что идея не нова и большинство вроде как раз утыкались в железную составляющую. Жюри задавали вопросы в основном по начинке браслетов и взаимодействии с домашними приборами. На первый вопрос разработчики ответили, что пока у них нет прототипа, есть что то наподобие Wii, но это только для доработки ПО, а потом они сделают. А на второй, по их идее, «человек будет управлять ближайшим устройством, т.е. устройством для которого будет наибольшим сигнал...»
кстати vikds можно поздравить как руководителя проекта MobiEcash, занявшего второе место…
Я насчет MobiEcash не понял, если во время передачи аппарат накрылся, деньги теряются? или как? А вообще болел за них и Канта. Меня как-то Москвичи разочаровали :( Я то думал мы что-нить поинтересней покажем…
Сегодня вечером напишу, а руководитель MobiEcash пообещал ответить на все вопросы, но только завтра (они летят домой сейчас)
Отличный вопрос! =)
Мы тоже об этом думали. Но решили не отягощать презентацию, и немного «умолчали». На самом деле в момент оплаты, протокол выплаты несколько «хитрее»:
1. Пользователь перед началом выплаты берет некоторый хэш beg_proof = hash(random(pass), 'begin'), где пароль генерируется устройством (мобила, КПК) и 'pass' сохраняется на устройстве. И пересылает его магазину, доказывая с нулевым разлашением что он точно знает 'pass'
2. Магазин сохраняет эту «штуку» beg_proof, при этом не зная от кого она (анонимность)
3. Происходит выплата, та которая описана в протоколах.
4. В конце вылаты, происходит передача end_proof = hash(random(pass), 'end'). В качестве подтверждения от пользователя.
Это позволяет: Только пользователю начавшму платеж, его закончить (для Internet-платежей), оставаясь при этом полностью анонимным: он после разрыва связи «доказывает» что знает pass. Pass никогда не передается. Магазин не «услышав» 'pass' не выдает товар. А если получит (от смарт-карты, КПК) этот 'pass', то магаз может проверить что он «подходит» для beg_proof, и end_proof. И сохраняет его в БД.
Все это реализовано, и не сильно нагружает систему. =)
Если я про что-то умолчал — обязательно расскажу «наше видение» решения проблемы. =)
Спасибо за вопрос.
(В криптографии тоже немалый потенциал кроется) =)
Мы тоже об этом думали. Но решили не отягощать презентацию, и немного «умолчали». На самом деле в момент оплаты, протокол выплаты несколько «хитрее»:
1. Пользователь перед началом выплаты берет некоторый хэш beg_proof = hash(random(pass), 'begin'), где пароль генерируется устройством (мобила, КПК) и 'pass' сохраняется на устройстве. И пересылает его магазину, доказывая с нулевым разлашением что он точно знает 'pass'
2. Магазин сохраняет эту «штуку» beg_proof, при этом не зная от кого она (анонимность)
3. Происходит выплата, та которая описана в протоколах.
4. В конце вылаты, происходит передача end_proof = hash(random(pass), 'end'). В качестве подтверждения от пользователя.
Это позволяет: Только пользователю начавшму платеж, его закончить (для Internet-платежей), оставаясь при этом полностью анонимным: он после разрыва связи «доказывает» что знает pass. Pass никогда не передается. Магазин не «услышав» 'pass' не выдает товар. А если получит (от смарт-карты, КПК) этот 'pass', то магаз может проверить что он «подходит» для beg_proof, и end_proof. И сохраняет его в БД.
Все это реализовано, и не сильно нагружает систему. =)
Если я про что-то умолчал — обязательно расскажу «наше видение» решения проблемы. =)
Спасибо за вопрос.
(В криптографии тоже немалый потенциал кроется) =)
Упс… «в момент оплаты» деньги не теряются.
Магазин, собственно, тоже заинтересован в получении денег. А «жулики, затевающие зловещие планы» из рассмотрения исключаются.
Зачем магазину принимать 200 монет и потом «удалить» их из Бд. Где же прибыь?
А пользователь может сохранить их (сгенерированные монеты) — чтоб потом Банку доказать, что он их пересылал. Под сомнением магазин, с подозрением в «нечестной игре».
Огранизацонно-правовые методы реализации для Нас — темная лошадка. Но решение этих конфликтов, кроется где-то там.
(Сорри, за опечатки: только после самолета и работы… need sleep)
Магазин, собственно, тоже заинтересован в получении денег. А «жулики, затевающие зловещие планы» из рассмотрения исключаются.
Зачем магазину принимать 200 монет и потом «удалить» их из Бд. Где же прибыь?
А пользователь может сохранить их (сгенерированные монеты) — чтоб потом Банку доказать, что он их пересылал. Под сомнением магазин, с подозрением в «нечестной игре».
Огранизацонно-правовые методы реализации для Нас — темная лошадка. Но решение этих конфликтов, кроется где-то там.
(Сорри, за опечатки: только после самолета и работы… need sleep)
У некоторых отвратительные презентационные слайды. Выгнал бы со сцены.
Sign up to leave a comment.
Фоторепортаж с Imagine Cup 2009. Часть первая