• Новый баг в Telegram Desktop позволяет прочитать последнее сообщение
    +4
    Грустно, что по такому незначительному багу (см. уточнения выше — можно увидеть только одно сообщение, только на одном устройстве и только до перезапуска приложения, пока сообщение висит в оперативной памяти, и только то сообщение, которое ты сам только что удалял) затем пишутся статьи с заголовками «Ошибка в Telegram позволяет прочитать удаленные сообщения» — вроде и правда, но кликбейт.
  • Новый баг в Telegram Desktop позволяет прочитать последнее сообщение
    0
    Баг действительно есть, но он не только редкий, но и незначительный и локальный. «Восстановить» можно только одно сообщение, которое только что было перед вами на экране.

    — Нельзя восстановить всю переписку.
    — Нельзя восстановить ни одно сообщение, которое только что не отображалось в приложении.
    — Нельзя восстановить ни одно сообщение, которое было удалено не вами в этом приложении (скажем, если переписку удалял ваш собеседник или вы, но с другого устройства, ничего не восстановится).
    — Сообщение некорректно очищается из оперативной памяти, то есть его можно просмотреть локально, но только из этого запуска этого приложения (если посмотреть с другого устройства, например телефона, или хотя бы перезапустить приложение, сообщения уже не будет).
  • Почему Telegram Passport — никакой не End to End
    0
    А где бонус?
  • Telegram представил собственный сервис Passport для верификации и авторизации пользователей
    0
    > Если они хранятся в зашифрованном виде, то Телеграм не может их предоставить другим. Подозреваю, что возможность расшифровки для себя Дуров все-таки оставит.

    Это не так. Они хранятся в зашифрованном пользовательским паролем виде. Когда пользователь предоставляет их какому-то другом сервису, он вводит пароль и ключ для расшифровки данных отправляется напрямую стороннему сервису, без участия серверов Телеграм. Сервис получает зашифрованные данные от сервера Телеграм и ключи для расшифровки от клиента Телеграм, где они были получены с использованием пользовательского пароля.

    То, что официальные сборки клиентов ведут себя именно так, как описано, проверить снаружи нельзя (получается доверие команде Телеграм), однако при желании можно взять код этих клиентов, проверить что по коду они ведут себя именно так, собрать его самостоятельно и быть уверенным, что на сервера Телеграм данные уходят только зашифрованные, а ключи для расшифровки уходят только тому сервису, которому пользователь решил их предоставить.
  • Проверка Telegram с помощью PVS-Studio и наоборот
    +2
    Какие-то баги репортил (несколько), какие-то мелочи для себя правил (может у них так и задумано, что альт-стрелка при переходе влево на маке должно за пробелом останавливаться, а не перед) + от патча не удастся избавиться совсем потому что некоторые фичи очень специфически реализованы и в основной код в таком виде явно не пойдут, когда пойдут в другом — возможно перейду на дефолт реализацию. + как я уже писал нужен доступ к внутренностям библиотеки.
  • Проверка Telegram с помощью PVS-Studio и наоборот
    +7
    А что делать. На винде в Qt если в диалоге выбора файла вставить ссылку на изображение в интернете, то винда его загрузит, но Qt его в приложение не отдаст — пришлось патчить. На маке в Qt с ошибками реализован grab виджетов, не сделать переключение вкладок сочетаниями Ctrl+Tab / Ctrl+Shift+Tab, не сделать желаемое поведение трей-иконки — пришлось патчить. Для быстрого вывода и ресайза текстов со смайлами пришлось писать свою низкоуровневую обертку для вывода текста со ссылками и смайлами, для получения доступа к низкому уровню пришлось патчить…
  • Проверка Telegram с помощью PVS-Studio и наоборот
    +3
    В проекте MetaEmoji нужна была работа с графической библиотекой и шрифтами, выбор шрифта по умолчанию (чтобы в него загрузить другую font family) чего-то проще всего на тот момент было сделать через QGuiApplication, возможно это делается правильно как-то иначе.

    Про рабочий метод через таймер — это совсем старое что-то, копипаста какой-то болванки консольного Qt-приложения из интернета, потом просто менять не стал, хотя разумеется это избыточно.

    Про патч — вывод текста со смайлами делается своими силами, для этого пришлось получить доступ к внутренностям Qt (через патч) + там есть немного багфиксов и немного фич. Но совсем без патча бы не получилось сделать его таким образом (приемлемая скорость отрисовки и скролла истории с сотней тысяч сообщений, которые могут содержать графические смайлы).
  • Проверка Telegram с помощью PVS-Studio и наоборот
    +3
    Конкретно в этом месте приведен код из маленькой утилитки Updater, которая написана на WinAPI без использования Qt и занимается только обновлением бинарника и перезапуском приложения при автообновлении. Однако в местах, где работа идет с WinAPI напрямую, а не через Qt, используются массивы WCHAR и в коде основного приложения.
  • Релиз KPHP и движков
    0
    Нету этого слоя сервисов, написанных на нормальных языках ООП =(
  • Clickjacking от А до Я
    0
    Большое спасибо за баг-репорт. А не подскажете, что за XSS фиксилась 3 месяца и куда именно вы об этой уязвимости сообщали?
  • Почему не стоит разрабатывать приложения для VK.com
    0
    Про поддержку — теперь она основная / единая по указанному адресу, там разбираются все вопросы, так что если вы когда-нибудь передумаете и станете что-либо делать у нас опять — имейте ввиду. Что там во вкладке в редактировании приложения — не знаю, возможно диалог об одобрениях и блокировках, но никак не служба поддержки. Так что верю и без скриншотов, что там могли не отвечать на вопросы.

    Да, это проблема. Единая система рекламы была призвана эту проблему решить, но вас она, увы, не устраивает. Разрешать черную монетизацию, увы, тоже не решение.
  • Почему не стоит разрабатывать приложения для VK.com
    +1
    Вы должны понимать, что есть нарушения, после которых действительно идет неизбежная блокировка, причем скорее всего навсегда (или на очень-очень длительный срок).

    Реклама смс-подписок (как и фишинг-сайтов) всегда относилась и будет относится именно к таким, крайним нарушениям. Черные методы монетизации недопустимы в крупных приложениях ни на каких условиях, независимо от того, какая сторона виновата — автор приложения или сеть, размещающая рекламу.

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

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

    Касательно общения с саппортом: то есть вы утверждаете, что обращались в поддержку по адресу vk.com/support и вам за полгода в одном случае и две недели в другом никто не ответил? Я как-то слабо верю, потому что мы отвечаем там абсолютно на все обращения, в течении максимум двух дней. Или что-то другое имеется ввиду?
  • Об одном недостатке VK API вслух
    0
    По моим наблюдениям магазины внутри нашей сети — одни из главных генераторов спама, наравне с смс-разводами :) Все эти угги, реплики часов и прочий ужас только и делают, что спамят. Ну да ладно, это уже не по теме все…
  • Об одном недостатке VK API вслух
    0
    Я сдаюсь.
  • Об одном недостатке VK API вслух
    0
    Хм… А какие магазины — нормальные? Я сначала не подумал об этом, но сейчас реально если вспомнить, то от ozon-а до amazon-а и все подряд сыпят на email кучей мусора, это факт. То, что от этого мусора можно отписаться, роли не играет.

    Конечно, можно начать закапываться в эту сторону. Сделать в диалоге с сообщением через API кнопку <<забанить это приложение и отправителя навсегда, почистив все за ним>>, но потом встанет вопрос поддержки всей этой ерунды в мобильных клиентах и т.д. И ведь действительно — личные сообщения не совсем email, и возможно их не стоит в него превращать.
  • Об одном недостатке VK API вслух
    +1
    Чего-то я не понял… blank.html сделан _только_ для токенов с десктоп-правами, для веб приложений их, считайте, не существует. Против чего вы собственно? %)

    Все методы, которые разрешены для веб-приложений, делаются с токенами, которые выдаются через возврат на сайт, а не на blank.html, без костылей. Все токены, которые уходят на blank.html, не предполагается использовать в веб-приложениях, и уже описано почему — потому что это расширенные методы, только для desktop-приложений.
  • Об одном недостатке VK API вслух
    0
    Ну ок, да. Причины озвучил выше, судьба будет обсуждаться…
  • Об одном недостатке VK API вслух
    0
    Неужели у FB и с диалогом с разработчиками и выполнением пожеланий к API все хорошо? %)
  • Об одном недостатке VK API вслух
    0
    Да, скорее всего это «ну на фиг», увы. До тех пор, пока не назреет масштабно что-то реформировать.

    В этом проблема маленькой команды — в данный момент (и на неопределенный период времени) все, допустим, четверо человек, которые имеют хоть какое-то отношение к решениям в общей схеме работе API весьма заняты своими весьма важными делами, из которых реально активно занимается API один. И из того, что внимание будет привлечено, не следует, что будет обещано что-то сделать в какие-то сроки…
  • Об одном недостатке VK API вслух
    0
    Мне все-равно не нравится :( Но я API почти не занимаюсь, посмотрим…
  • Об одном недостатке VK API вслух
    0
    Ну это совсем другая ситуация, да. По обсуждению-то получается, что хочется иметь возможность запросить доступ к личке любого пользователя, что нонсенс для более 95% добропорядочных приложений. Это же другая проблема — проблема цивилизованного способа выдачи полноценного токена конкретному юзеру, скажем, админу приложения или еще кому-нибудь…

    Сейчас действительно можно сделать это через копирование токена из blank.html — но надо понимать, что это вы сами копируете для своего же приложения, а не пользователям предлагаете это делать (против чего мы собственно и, например, написали текст на этом blank.html). Можно подумать, как сделать более человеческий интерфейс для этого действия…

    В конце концов, это может быть вообще ваше какое-то серверное десктоп-приложение, через которое работает ваш этот робот-пользователь — к пользовательскому веб-приложению, в котором пользователь дает в браузере разрешение на доступ к каким-то своим данными этот кей автоматической отправки сообщений от своего робота ведь не имеет никакого отношения!
  • Об одном недостатке VK API вслух
    +1
    Не любой, а с доступом к расширенным методам. У FB, похоже, нет расширенных методов в принципе — то есть он половину наших расширенных методов не дает вообще никому, а вторую записывает в обычные методы. Ну, про каждый конкретный метод тут можно говорить отдельно — надо ли его делать расширенным.

    Про постинг на стене без уведомления владельца страницы — я думаю, что надо, незачем сайтам мне лить что-то без моего ведома на страницу. Постить с уведомлением владельца страницы (через бокс постинга) могут даже встроенные приложения, по идее и сайтам должно быть можно. Если нету, то можно сделать, наверное. Про остальные методы — ну, надо смотреть.
  • Об одном недостатке VK API вслух
    0
    Возвращает назад веб-приложению токен с доступом к чтению личных сообщений?
  • Об одном недостатке VK API вслух
    0
    А чего там у FB? Любой сайт, авторизовавший юзера с нужными правами, может читать его личные сообщения?
  • Об одном недостатке VK API вслух
    0
    Я понимаю, что к мобильным приложениям эта логика прикладывается чуть хуже, чем к десктопным — но они и появились позднее, к ним просто ее применили готовую. Ну и ограничения нельзя делать для мобильных приложений просто потому что там _необходимы_ полноценные клиенты :) Чего не скажешь о вебе.

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

    А зачем вам в веб приложениях коммерции и услуг доступ к личным сообщениям пришедшего к вам и авторизующегося у вас пользователя? О_о
  • Об одном недостатке VK API вслух
    +1
    (попробую тоже..)

    brainfucker, может добавишь / поправишь чего-нибудь из выше-написанного?..
  • Об одном недостатке VK API вслух
    +2
    (нифига себе, работает..)

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

    (только вот давайте без этой туфты про «это же данные пользователя! как вы за него решаете! вдруг он хочет сам отдать свои сообщения на растерзание всем нехорошим людям этого мира!» — все так, для этого есть standalone приложения, вирусы, которым он может хоть номера своих кредиток слить, и т.д.)

    Можно конечно говорить «Но ведь как же? Его же спрашивают разрешение! Он сам дает доступ!», но как мне кажется, урон от необдуманных решений по доступу к личным сообщениям для сторонних приложений будет значительно выше получаемого профита. То есть веб — это такая песочница, люди там совсем невнимательно читают что-то и нажимают кнопки, соглашаются со всем и т.д. и какую бы кричащую предупреждающую плашку в боксе разрешения мы не повесили — все будут не читая пропускать, потому что сейчас цель у них — получить доступ к тому, к чему они пытаются, и никакие окошки их не остановят.

    Теперь на счет десктоп — та логика, в принципе, та же, за исключением того, что бессмысленно ставить ограничения :) Потому что если пользователя убедили установить себе бинарник, то от плохих ребят его уже ничего не спасет — он установил уже себе снифер, кейлогер, вирус, что угодно… Поэтому десктоп пусть работает через API, делает клиенты — там нечего особо защищать. И если для доступа к сайту, к примеру, от юзера требуется не в окошке нажать «Разрешаю», а скачать и установить какой-то софт, то это сдерживает все же значительно больше народу — а главное, если не сдерживает это, то уже ничего не поможет.

    + не надо забывать, что сторонние сайты, будучи быть может хорошими приложениями сами по себе, легко могут иметь XSS-уязвимости, в результате чего доступ ко всему разрешенному получит еще кто угодно… и если бы им было все разрешено, они конечно бы каялись и клялись, что все исправили и верните, пожалуйста, доступ… ну и действительно, XSS — бывает же, чего там, казнить за это приложение навсегда как-то странно… однако разовый договоренный допуск такой XSS может принести очень не мало денег и будет очень соблазнителен приложениям с точки зрения монетизации — и это все аргумент, опять же неактуальный для десктоп софта.

    То есть приложение, которому можно давать доступ ко всему, потому что оно и так имеет доступ ко всему, если захочет — это, по определению, и есть те, кто могут вытащить токен из oauth.vk.com/blank.html

    Так и получилось разделение на два класса методов. Ну а потом десктоп-разрешения переехали в мобайл. И вряд ли это в ближайшее время изменится (хотя кто знает?..) То есть можно обсуждать перенос конкретных методов из расширенных в обычные (которые туда типа случайно попали), хотя обсуждать все конкретные методы лично мне, например, некогда. А вот отмену всей схемы — едва ли.
  • «Вконтакте» выдаёт личные данные в поиске по документам
    +3
    Ага, не поленитесь, скачайте «Мои логины и пароли к сайтам(со скриншотами).docx» — прям «документы, переписки, пароли...», правда?
  • «Вконтакте» выдаёт личные данные в поиске по документам
    +5
    Прямые ссылки на документы привязаны к IP-адресу и ни у кого больше здесь не открываются.
  • «Вконтакте» выдаёт личные данные в поиске по документам
    +5
    Вот тут на роеме пример привели:

    «Яндекс выдает всем желающим личные данные юзеров». Вот пример:

    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

    Или тут та же пурга будет, что «сам ничего не хранит, только индексирует»? Результат одинаковый — вбиваем запрос и видим те данные, которые кто-то не понимающий, что он делает, загрузил в доступное для индексации место.
  • ВКонтакте пошел навстречу правообладателям?
    +1
    При регистрации, после ввода логина и пароля, пришедшего на телефон, проходятся три шага регистрации, на третьем все принимают правила использования.
  • Диалог с властью
    0
    Речь же про российских пользователей? Или имелось ввиду, что «медведа» привлекла вся аудитория фб, а не российская?
  • 24-летний студент начал войну против Facebook
    0
    Это просто указание этого номера на главной странице для регистрации или приглашение кем-то из участников.
  • Диалог с властью
    0
    Наверное, меня учили какому-то другому закону больших чисел, который ничего не говорит ни о вероятности наличия, ни об (абсолютном) количестве. Возможно имелось ввиду относительное количество (доля) умных и продвинутых, но тогда стоило бы так и говорить.

    Потому что для любой публичной фигуры (должно быть?) важнее абсолютное количество (всех или же умных и продвинутых, зависит от фигуры) читающих, а не относительное.
  • Счастливо, Фермер!
    +1
    Никто никого на Одноклассников не посылал, это какой-то тупняк был у топик-стартера.
  • Кнопки социальных сетей на сайтах в зоне .РФ
    0
    Украсть что ли у Facebook безглючную работу с кириллическими доменами… Хотя нет, не стоит, опять все в плагиате обвинят. (а так глядишь, и этот.рф-идиотизм сам загнется :)
  • StatCounter: в декабре Chrome обгонит Firefox и станет браузером № 2 в мире
    0
    Да, так хитро у них устроено кросс-доменное взаимодействие: кнопка — это фрейм, для взаимодействия им нужна специфическая страница на исходном домене, открытая внутри кнопки во фрейме (получается — третьего уровня), и чтобы облегчить установку кнопки они просто открывают исходную страницу там со специфическим параметром, а их скрипт на исходной странице js-ом заменяет ее всю на нужную специфическую страницу. Но счетчики успевают отработать, да. И скрипты. Может начать играть что-нибудь во второй голос :)
  • Как был взломан Вконтакте.ру
    0
    Чего?
  • Авторизация через ВКонтакте, Mail.ru и другие для самых начинающих — 2
    +3
    Пока пароль не введен куда-нибудь — вряд ли уведут :)
  • Эксплуатируемая уязвимость в почте Mail.ru
    +1
    Да, я имел ввиду iframe на другом сайте. Токены, да. Уязвимости разного порядка, но одной природы, одного типа. Так что предлагать post как метод исправления уязвимости — некорректно.