Комментарии 26
безопасность в ущерб удобству — для большинства пользователей не вариант, имхо
Обратный пример
habrahabr.ru/blogs/google/98135/#comment_3019423
habrahabr.ru/blogs/google/98135/#comment_3019423
Почему в ущерб? Кто не хочет безопасность сможет использовать один пароль на все услуги.
Да и наоборот очень удобно — один раз ввел и не беспокоишься, даже если пароль сольют. Всегда можно отследить сессии, если что-то не то — поменять пароль, ведь мастер-пароль нигде не светится.
Да и наоборот очень удобно — один раз ввел и не беспокоишься, даже если пароль сольют. Всегда можно отследить сессии, если что-то не то — поменять пароль, ведь мастер-пароль нигде не светится.
В ущерб развитию функциональности. Например, некоторые сервисы могут сейчас или впоследствии начать интегрироваться друг с другом (GMail'у может потребоваться доступ к данным из Calendar, и т.п.). Если ввести систему с разными паролями, то от развития в этом направлении Google придеться либо совсем отказаться, либо придумывать какие-то очень сложные схемы с многоходовой аутенфикацией. Т.е. если существует какое-то подмножество общих данных (например контакты, статусы, и т.п.), то все сильно усложняется.
Мы говорим о API для сторонних приложений.
В вашем случае можно/нужно будет создавать доступ и наделить его правами, которые нужны для использования связки. В принципе можно будет создать визард, который поможет назначить/ограничить права правильно. И использование дополнительных паролей не запрещает использование мастер-пароля или еще дополнительного пароля с максимальными правами(кроме прав изменения мастер-пароля).
В вашем случае можно/нужно будет создавать доступ и наделить его правами, которые нужны для использования связки. В принципе можно будет создать визард, который поможет назначить/ограничить права правильно. И использование дополнительных паролей не запрещает использование мастер-пароля или еще дополнительного пароля с максимальными правами(кроме прав изменения мастер-пароля).
Как это решит проблему? Вот вы сейчас описали схему, которую практически никто из пользователей не сможет понять, к тому же она увеличит во много раз затраты на тестирование и количество багов. Например, я логинюсь в свой Календарь и половина функционала не работает. Теперь я должен думать, что я сделал не так — может надо было вводить мастер-пароль? Может надо подкрутить какие-то настройки в визарде? Может быть это просто баг календаря? Может мне надо параллельно еще в GMail залогиниться? Как я об этом узнаю? Это какой-то кошмар как с точки зрения юзабилити, так и с точки зрения разработки.
И это пример с двумя приложениями. А если мне нужна связка из семи? Сложность растет экспоненциально.
И это пример с двумя приложениями. А если мне нужна связка из семи? Сложность растет экспоненциально.
В гмайл и сейчас есть специфический функционал, который выключен по умолчанию.
То есть кто хоччет использует. И здесь тоже самое.
Я бы использовал хотя бы для гуглталка и для фидридера отдельные пароли и судя по тому, что тема поднималась ни один раз в интернете — то это актуально и для других пользователей. А пользователи, которые довольны тем что есть — ничего нового изучать не придется и менять тоже.
То есть кто хоччет использует. И здесь тоже самое.
Я бы использовал хотя бы для гуглталка и для фидридера отдельные пароли и судя по тому, что тема поднималась ни один раз в интернете — то это актуально и для других пользователей. А пользователи, которые довольны тем что есть — ничего нового изучать не придется и менять тоже.
Интеграция авторизации по OpenID и по паролю?
Хотел статью (про проблему паролей) на похожую тему написать, но думал здесь это не интересует. Если что, скажите. Напишу.
Прочитал заголовок, подумал гугл уже реализовал.
Прочитал заголовок, подумал гугл уже реализовал.
Google развивает API совсем в другую сторону и пароль собственно от аккаунта приложению не должен быть нужен. Нужен доступ к «точке доступа» для данных вашего аккаунта, а уж авторизоваться приложение должно по другому механизму.
В общем идея может быть и не бредовая, но идет в разрез с пониманием ситуации Гуглом и не будет реализована никогда.
В общем идея может быть и не бредовая, но идет в разрез с пониманием ситуации Гуглом и не будет реализована никогда.
Да, только где будет эта единая точка, если нужно использовать стороннее stand alone приложение?
В принципе ничего не мешает google сделать отдельное api дополнительной авторизации некоторых сервисов для сторонних разработчиков приложений, таких как gtalk, feed reader и т.п.
В принципе ничего не мешает google сделать отдельное api дополнительной авторизации некоторых сервисов для сторонних разработчиков приложений, таких как gtalk, feed reader и т.п.
Читайте документацию. Для каждого сервиса свои точки доступа, например ленты reader имеют www.google.com/reader/ а picasa имеет picasaweb.google.com/data/. И аккаунт контролирует доступ для каждого сервиса и для кажого приложения/сайта.
gtalk работает по XMPP и пока не имеет отдельного API как прочие сервисы
ленты Reader можно вычитать но опять же google еще не зарелизил нормальное API и как раз авторизация там не проработана.
Но развитие API для прочих служб показывает что oAuth и токены — выбор google а не велосипеды в виде отдельных паролей.
gtalk работает по XMPP и пока не имеет отдельного API как прочие сервисы
ленты Reader можно вычитать но опять же google еще не зарелизил нормальное API и как раз авторизация там не проработана.
Но развитие API для прочих служб показывает что oAuth и токены — выбор google а не велосипеды в виде отдельных паролей.
Мне, вот, наоборот не нравится что для youtube, к примеру, нужен отдельный эккаунт. Язык тоже в разных сервисах отдельно настраивать приходится (ну не хочу я локализацию (навязываемую по геолокации IP), подавайте мне английский!). IMHO было бы удобнее если бы все сервисы Гугла использовали один эккаунт для авторизации и хранения настроек и данных.
Тоже об этом думал в свое время, даже начинал писать «прокси» под это дело.
Долгое время сидел на FeedDemon, потом надоело, перешел на Reader. Не жалею :)
У Google есть двухфакторная авторизация которая решает часть Ваших предложений, а именно:
— для каждого приложения можно создать свой пароль
— имеется мастер пароль (Ваш основной + одноразовый на телефоне или другим способом)
— имеется центр управления сгенерированными паролями приложений.
Включается в настройках аккаунта.
— для каждого приложения можно создать свой пароль
— имеется мастер пароль (Ваш основной + одноразовый на телефоне или другим способом)
— имеется центр управления сгенерированными паролями приложений.
Включается в настройках аккаунта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разные пароли для разных сервисов одного аккаунта google