Я понимаю, что к мобильным приложениям эта логика прикладывается чуть хуже, чем к десктопным — но они и появились позднее, к ним просто ее применили готовую. Ну и ограничения нельзя делать для мобильных приложений просто потому что там _необходимы_ полноценные клиенты :) Чего не скажешь о вебе.
Но уязвимости и хаки десктоп-приложений доступны тоже только другим десктоп приложениям, которые сами по себе могут быть просто тупо плохими. Что слегка обессмысливает весь процесс.
А зачем вам в веб приложениях коммерции и услуг доступ к личным сообщениям пришедшего к вам и авторизующегося у вас пользователя? О_о
Вообще, логику работы API я не определял, но исторически все примерно так (как я это понимаю, типа личный взгляд): есть веб-приложения и десктоп приложения. Веб-приложениям мы разрешаем то, решение о разрешении чего мы готовы возложить на пользователя (кривая формулировка, но вроде бы так). Разрешение на доступ к личным сообщениям (самый главный пример, наверное) — это то решение, которое доверить пользователю мы не готовы.
(только вот давайте без этой туфты про «это же данные пользователя! как вы за него решаете! вдруг он хочет сам отдать свои сообщения на растерзание всем нехорошим людям этого мира!» — все так, для этого есть standalone приложения, вирусы, которым он может хоть номера своих кредиток слить, и т.д.)
Можно конечно говорить «Но ведь как же? Его же спрашивают разрешение! Он сам дает доступ!», но как мне кажется, урон от необдуманных решений по доступу к личным сообщениям для сторонних приложений будет значительно выше получаемого профита. То есть веб — это такая песочница, люди там совсем невнимательно читают что-то и нажимают кнопки, соглашаются со всем и т.д. и какую бы кричащую предупреждающую плашку в боксе разрешения мы не повесили — все будут не читая пропускать, потому что сейчас цель у них — получить доступ к тому, к чему они пытаются, и никакие окошки их не остановят.
Теперь на счет десктоп — та логика, в принципе, та же, за исключением того, что бессмысленно ставить ограничения :) Потому что если пользователя убедили установить себе бинарник, то от плохих ребят его уже ничего не спасет — он установил уже себе снифер, кейлогер, вирус, что угодно… Поэтому десктоп пусть работает через API, делает клиенты — там нечего особо защищать. И если для доступа к сайту, к примеру, от юзера требуется не в окошке нажать «Разрешаю», а скачать и установить какой-то софт, то это сдерживает все же значительно больше народу — а главное, если не сдерживает это, то уже ничего не поможет.
+ не надо забывать, что сторонние сайты, будучи быть может хорошими приложениями сами по себе, легко могут иметь XSS-уязвимости, в результате чего доступ ко всему разрешенному получит еще кто угодно… и если бы им было все разрешено, они конечно бы каялись и клялись, что все исправили и верните, пожалуйста, доступ… ну и действительно, XSS — бывает же, чего там, казнить за это приложение навсегда как-то странно… однако разовый договоренный допуск такой XSS может принести очень не мало денег и будет очень соблазнителен приложениям с точки зрения монетизации — и это все аргумент, опять же неактуальный для десктоп софта.
То есть приложение, которому можно давать доступ ко всему, потому что оно и так имеет доступ ко всему, если захочет — это, по определению, и есть те, кто могут вытащить токен из oauth.vk.com/blank.html
Так и получилось разделение на два класса методов. Ну а потом десктоп-разрешения переехали в мобайл. И вряд ли это в ближайшее время изменится (хотя кто знает?..) То есть можно обсуждать перенос конкретных методов из расширенных в обычные (которые туда типа случайно попали), хотя обсуждать все конкретные методы лично мне, например, некогда. А вот отмену всей схемы — едва ли.
Или тут та же пурга будет, что «сам ничего не хранит, только индексирует»? Результат одинаковый — вбиваем запрос и видим те данные, которые кто-то не понимающий, что он делает, загрузил в доступное для индексации место.
Наверное, меня учили какому-то другому закону больших чисел, который ничего не говорит ни о вероятности наличия, ни об (абсолютном) количестве. Возможно имелось ввиду относительное количество (доля) умных и продвинутых, но тогда стоило бы так и говорить.
Потому что для любой публичной фигуры (должно быть?) важнее абсолютное количество (всех или же умных и продвинутых, зависит от фигуры) читающих, а не относительное.
Украсть что ли у Facebook безглючную работу с кириллическими доменами… Хотя нет, не стоит, опять все в плагиате обвинят. (а так глядишь, и этот.рф-идиотизм сам загнется :)
Да, так хитро у них устроено кросс-доменное взаимодействие: кнопка — это фрейм, для взаимодействия им нужна специфическая страница на исходном домене, открытая внутри кнопки во фрейме (получается — третьего уровня), и чтобы облегчить установку кнопки они просто открывают исходную страницу там со специфическим параметром, а их скрипт на исходной странице js-ом заменяет ее всю на нужную специфическую страницу. Но счетчики успевают отработать, да. И скрипты. Может начать играть что-нибудь во второй голос :)
Да, я имел ввиду iframe на другом сайте. Токены, да. Уязвимости разного порядка, но одной природы, одного типа. Так что предлагать post как метод исправления уязвимости — некорректно.
Мораль вроде должна быть не совсем такова, ведь использование POST хоть и затрудняет использование уязвимости (так как здесь, через картинку, было бы не воспользоваться), однако уязвимость не устраняет, воспользоваться ей можно все-равно.
Хм… У меня не воспроизводится. После удаления жму «выйти», слева ввожу логин пароль другой страницы — вхожу под другим человеком. При этом все время остаюсь на текущей, удаленной, но с нее можно уйти через логотип на страницу текущего пользователя или в любое другое место через левое меню.
Но уязвимости и хаки десктоп-приложений доступны тоже только другим десктоп приложениям, которые сами по себе могут быть просто тупо плохими. Что слегка обессмысливает весь процесс.
А зачем вам в веб приложениях коммерции и услуг доступ к личным сообщениям пришедшего к вам и авторизующегося у вас пользователя? О_о
brainfucker, может добавишь / поправишь чего-нибудь из выше-написанного?..
Вообще, логику работы API я не определял, но исторически все примерно так (как я это понимаю, типа личный взгляд): есть веб-приложения и десктоп приложения. Веб-приложениям мы разрешаем то, решение о разрешении чего мы готовы возложить на пользователя (кривая формулировка, но вроде бы так). Разрешение на доступ к личным сообщениям (самый главный пример, наверное) — это то решение, которое доверить пользователю мы не готовы.
(только вот давайте без этой туфты про «это же данные пользователя! как вы за него решаете! вдруг он хочет сам отдать свои сообщения на растерзание всем нехорошим людям этого мира!» — все так, для этого есть standalone приложения, вирусы, которым он может хоть номера своих кредиток слить, и т.д.)
Можно конечно говорить «Но ведь как же? Его же спрашивают разрешение! Он сам дает доступ!», но как мне кажется, урон от необдуманных решений по доступу к личным сообщениям для сторонних приложений будет значительно выше получаемого профита. То есть веб — это такая песочница, люди там совсем невнимательно читают что-то и нажимают кнопки, соглашаются со всем и т.д. и какую бы кричащую предупреждающую плашку в боксе разрешения мы не повесили — все будут не читая пропускать, потому что сейчас цель у них — получить доступ к тому, к чему они пытаются, и никакие окошки их не остановят.
Теперь на счет десктоп — та логика, в принципе, та же, за исключением того, что бессмысленно ставить ограничения :) Потому что если пользователя убедили установить себе бинарник, то от плохих ребят его уже ничего не спасет — он установил уже себе снифер, кейлогер, вирус, что угодно… Поэтому десктоп пусть работает через API, делает клиенты — там нечего особо защищать. И если для доступа к сайту, к примеру, от юзера требуется не в окошке нажать «Разрешаю», а скачать и установить какой-то софт, то это сдерживает все же значительно больше народу — а главное, если не сдерживает это, то уже ничего не поможет.
+ не надо забывать, что сторонние сайты, будучи быть может хорошими приложениями сами по себе, легко могут иметь XSS-уязвимости, в результате чего доступ ко всему разрешенному получит еще кто угодно… и если бы им было все разрешено, они конечно бы каялись и клялись, что все исправили и верните, пожалуйста, доступ… ну и действительно, XSS — бывает же, чего там, казнить за это приложение навсегда как-то странно… однако разовый договоренный допуск такой XSS может принести очень не мало денег и будет очень соблазнителен приложениям с точки зрения монетизации — и это все аргумент, опять же неактуальный для десктоп софта.
То есть приложение, которому можно давать доступ ко всему, потому что оно и так имеет доступ ко всему, если захочет — это, по определению, и есть те, кто могут вытащить токен из oauth.vk.com/blank.html
Так и получилось разделение на два класса методов. Ну а потом десктоп-разрешения переехали в мобайл. И вряд ли это в ближайшее время изменится (хотя кто знает?..) То есть можно обсуждать перенос конкретных методов из расширенных в обычные (которые туда типа случайно попали), хотя обсуждать все конкретные методы лично мне, например, некогда. А вот отмену всей схемы — едва ли.
«Яндекс выдает всем желающим личные данные юзеров». Вот пример:
images.yandex.ru/yandsearch?text=%D1%81%D0%BA%D0%B0%D0%BD+%D0%BF%D0%B0%D1%81%D0%BF%D0%BE%D1%80%D1%82%D0%B0&stype=image
Или тут та же пурга будет, что «сам ничего не хранит, только индексирует»? Результат одинаковый — вбиваем запрос и видим те данные, которые кто-то не понимающий, что он делает, загрузил в доступное для индексации место.
Потому что для любой публичной фигуры (должно быть?) важнее абсолютное количество (всех или же умных и продвинутых, зависит от фигуры) читающих, а не относительное.