Грустно, что по такому незначительному багу (см. уточнения выше — можно увидеть только одно сообщение, только на одном устройстве и только до перезапуска приложения, пока сообщение висит в оперативной памяти, и только то сообщение, которое ты сам только что удалял) затем пишутся статьи с заголовками «Ошибка в Telegram позволяет прочитать удаленные сообщения» — вроде и правда, но кликбейт.
Баг действительно есть, но он не только редкий, но и незначительный и локальный. «Восстановить» можно только одно сообщение, которое только что было перед вами на экране.
— Нельзя восстановить всю переписку.
— Нельзя восстановить ни одно сообщение, которое только что не отображалось в приложении.
— Нельзя восстановить ни одно сообщение, которое было удалено не вами в этом приложении (скажем, если переписку удалял ваш собеседник или вы, но с другого устройства, ничего не восстановится).
— Сообщение некорректно очищается из оперативной памяти, то есть его можно просмотреть локально, но только из этого запуска этого приложения (если посмотреть с другого устройства, например телефона, или хотя бы перезапустить приложение, сообщения уже не будет).
> Если они хранятся в зашифрованном виде, то Телеграм не может их предоставить другим. Подозреваю, что возможность расшифровки для себя Дуров все-таки оставит.
Это не так. Они хранятся в зашифрованном пользовательским паролем виде. Когда пользователь предоставляет их какому-то другом сервису, он вводит пароль и ключ для расшифровки данных отправляется напрямую стороннему сервису, без участия серверов Телеграм. Сервис получает зашифрованные данные от сервера Телеграм и ключи для расшифровки от клиента Телеграм, где они были получены с использованием пользовательского пароля.
То, что официальные сборки клиентов ведут себя именно так, как описано, проверить снаружи нельзя (получается доверие команде Телеграм), однако при желании можно взять код этих клиентов, проверить что по коду они ведут себя именно так, собрать его самостоятельно и быть уверенным, что на сервера Телеграм данные уходят только зашифрованные, а ключи для расшифровки уходят только тому сервису, которому пользователь решил их предоставить.
Какие-то баги репортил (несколько), какие-то мелочи для себя правил (может у них так и задумано, что альт-стрелка при переходе влево на маке должно за пробелом останавливаться, а не перед) + от патча не удастся избавиться совсем потому что некоторые фичи очень специфически реализованы и в основной код в таком виде явно не пойдут, когда пойдут в другом — возможно перейду на дефолт реализацию. + как я уже писал нужен доступ к внутренностям библиотеки.
А что делать. На винде в Qt если в диалоге выбора файла вставить ссылку на изображение в интернете, то винда его загрузит, но Qt его в приложение не отдаст — пришлось патчить. На маке в Qt с ошибками реализован grab виджетов, не сделать переключение вкладок сочетаниями Ctrl+Tab / Ctrl+Shift+Tab, не сделать желаемое поведение трей-иконки — пришлось патчить. Для быстрого вывода и ресайза текстов со смайлами пришлось писать свою низкоуровневую обертку для вывода текста со ссылками и смайлами, для получения доступа к низкому уровню пришлось патчить…
В проекте MetaEmoji нужна была работа с графической библиотекой и шрифтами, выбор шрифта по умолчанию (чтобы в него загрузить другую font family) чего-то проще всего на тот момент было сделать через QGuiApplication, возможно это делается правильно как-то иначе.
Про рабочий метод через таймер — это совсем старое что-то, копипаста какой-то болванки консольного Qt-приложения из интернета, потом просто менять не стал, хотя разумеется это избыточно.
Про патч — вывод текста со смайлами делается своими силами, для этого пришлось получить доступ к внутренностям Qt (через патч) + там есть немного багфиксов и немного фич. Но совсем без патча бы не получилось сделать его таким образом (приемлемая скорость отрисовки и скролла истории с сотней тысяч сообщений, которые могут содержать графические смайлы).
Конкретно в этом месте приведен код из маленькой утилитки Updater, которая написана на WinAPI без использования Qt и занимается только обновлением бинарника и перезапуском приложения при автообновлении. Однако в местах, где работа идет с WinAPI напрямую, а не через Qt, используются массивы WCHAR и в коде основного приложения.
Про поддержку — теперь она основная / единая по указанному адресу, там разбираются все вопросы, так что если вы когда-нибудь передумаете и станете что-либо делать у нас опять — имейте ввиду. Что там во вкладке в редактировании приложения — не знаю, возможно диалог об одобрениях и блокировках, но никак не служба поддержки. Так что верю и без скриншотов, что там могли не отвечать на вопросы.
Да, это проблема. Единая система рекламы была призвана эту проблему решить, но вас она, увы, не устраивает. Разрешать черную монетизацию, увы, тоже не решение.
Вы должны понимать, что есть нарушения, после которых действительно идет неизбежная блокировка, причем скорее всего навсегда (или на очень-очень длительный срок).
Реклама смс-подписок (как и фишинг-сайтов) всегда относилась и будет относится именно к таким, крайним нарушениям. Черные методы монетизации недопустимы в крупных приложениях ни на каких условиях, независимо от того, какая сторона виновата — автор приложения или сеть, размещающая рекламу.
Вы должны понимать последствия размещения в крупном приложении (на миллион пользователей!) хорошо подготовленной рекламы, скажем, фишинг-сайта — если в результате можно отделаться чем угодно, кроме потери приложения (исправлением, снятием такой рекламы в дальнейшем, хоть сколько-то разумным штрафом и т.д.) — тогда все крупные приложения будут регулярно (или по крайней мере разово, но гарантированно) монетизироваться именно таким образом, что категорически недопустимо.
Так что увы, если вы — неважно каким образом и через каких партнеров — размещаете в своем приложении рекламу, через которую по черному монетизируетесь (или не вы, а ваши партнеры, это неважно) — будьте готовы потерять приложение.
Касательно общения с саппортом: то есть вы утверждаете, что обращались в поддержку по адресу vk.com/support и вам за полгода в одном случае и две недели в другом никто не ответил? Я как-то слабо верю, потому что мы отвечаем там абсолютно на все обращения, в течении максимум двух дней. Или что-то другое имеется ввиду?
По моим наблюдениям магазины внутри нашей сети — одни из главных генераторов спама, наравне с смс-разводами :) Все эти угги, реплики часов и прочий ужас только и делают, что спамят. Ну да ладно, это уже не по теме все…
Хм… А какие магазины — нормальные? Я сначала не подумал об этом, но сейчас реально если вспомнить, то от ozon-а до amazon-а и все подряд сыпят на email кучей мусора, это факт. То, что от этого мусора можно отписаться, роли не играет.
Конечно, можно начать закапываться в эту сторону. Сделать в диалоге с сообщением через API кнопку <<забанить это приложение и отправителя навсегда, почистив все за ним>>, но потом встанет вопрос поддержки всей этой ерунды в мобильных клиентах и т.д. И ведь действительно — личные сообщения не совсем email, и возможно их не стоит в него превращать.
Чего-то я не понял… blank.html сделан _только_ для токенов с десктоп-правами, для веб приложений их, считайте, не существует. Против чего вы собственно? %)
Все методы, которые разрешены для веб-приложений, делаются с токенами, которые выдаются через возврат на сайт, а не на blank.html, без костылей. Все токены, которые уходят на blank.html, не предполагается использовать в веб-приложениях, и уже описано почему — потому что это расширенные методы, только для desktop-приложений.
Да, скорее всего это «ну на фиг», увы. До тех пор, пока не назреет масштабно что-то реформировать.
В этом проблема маленькой команды — в данный момент (и на неопределенный период времени) все, допустим, четверо человек, которые имеют хоть какое-то отношение к решениям в общей схеме работе API весьма заняты своими весьма важными делами, из которых реально активно занимается API один. И из того, что внимание будет привлечено, не следует, что будет обещано что-то сделать в какие-то сроки…
Ну это совсем другая ситуация, да. По обсуждению-то получается, что хочется иметь возможность запросить доступ к личке любого пользователя, что нонсенс для более 95% добропорядочных приложений. Это же другая проблема — проблема цивилизованного способа выдачи полноценного токена конкретному юзеру, скажем, админу приложения или еще кому-нибудь…
Сейчас действительно можно сделать это через копирование токена из blank.html — но надо понимать, что это вы сами копируете для своего же приложения, а не пользователям предлагаете это делать (против чего мы собственно и, например, написали текст на этом blank.html). Можно подумать, как сделать более человеческий интерфейс для этого действия…
В конце концов, это может быть вообще ваше какое-то серверное десктоп-приложение, через которое работает ваш этот робот-пользователь — к пользовательскому веб-приложению, в котором пользователь дает в браузере разрешение на доступ к каким-то своим данными этот кей автоматической отправки сообщений от своего робота ведь не имеет никакого отношения!
— Нельзя восстановить всю переписку.
— Нельзя восстановить ни одно сообщение, которое только что не отображалось в приложении.
— Нельзя восстановить ни одно сообщение, которое было удалено не вами в этом приложении (скажем, если переписку удалял ваш собеседник или вы, но с другого устройства, ничего не восстановится).
— Сообщение некорректно очищается из оперативной памяти, то есть его можно просмотреть локально, но только из этого запуска этого приложения (если посмотреть с другого устройства, например телефона, или хотя бы перезапустить приложение, сообщения уже не будет).
Это не так. Они хранятся в зашифрованном пользовательским паролем виде. Когда пользователь предоставляет их какому-то другом сервису, он вводит пароль и ключ для расшифровки данных отправляется напрямую стороннему сервису, без участия серверов Телеграм. Сервис получает зашифрованные данные от сервера Телеграм и ключи для расшифровки от клиента Телеграм, где они были получены с использованием пользовательского пароля.
То, что официальные сборки клиентов ведут себя именно так, как описано, проверить снаружи нельзя (получается доверие команде Телеграм), однако при желании можно взять код этих клиентов, проверить что по коду они ведут себя именно так, собрать его самостоятельно и быть уверенным, что на сервера Телеграм данные уходят только зашифрованные, а ключи для расшифровки уходят только тому сервису, которому пользователь решил их предоставить.
Про рабочий метод через таймер — это совсем старое что-то, копипаста какой-то болванки консольного Qt-приложения из интернета, потом просто менять не стал, хотя разумеется это избыточно.
Про патч — вывод текста со смайлами делается своими силами, для этого пришлось получить доступ к внутренностям Qt (через патч) + там есть немного багфиксов и немного фич. Но совсем без патча бы не получилось сделать его таким образом (приемлемая скорость отрисовки и скролла истории с сотней тысяч сообщений, которые могут содержать графические смайлы).
Да, это проблема. Единая система рекламы была призвана эту проблему решить, но вас она, увы, не устраивает. Разрешать черную монетизацию, увы, тоже не решение.
Реклама смс-подписок (как и фишинг-сайтов) всегда относилась и будет относится именно к таким, крайним нарушениям. Черные методы монетизации недопустимы в крупных приложениях ни на каких условиях, независимо от того, какая сторона виновата — автор приложения или сеть, размещающая рекламу.
Вы должны понимать последствия размещения в крупном приложении (на миллион пользователей!) хорошо подготовленной рекламы, скажем, фишинг-сайта — если в результате можно отделаться чем угодно, кроме потери приложения (исправлением, снятием такой рекламы в дальнейшем, хоть сколько-то разумным штрафом и т.д.) — тогда все крупные приложения будут регулярно (или по крайней мере разово, но гарантированно) монетизироваться именно таким образом, что категорически недопустимо.
Так что увы, если вы — неважно каким образом и через каких партнеров — размещаете в своем приложении рекламу, через которую по черному монетизируетесь (или не вы, а ваши партнеры, это неважно) — будьте готовы потерять приложение.
Касательно общения с саппортом: то есть вы утверждаете, что обращались в поддержку по адресу vk.com/support и вам за полгода в одном случае и две недели в другом никто не ответил? Я как-то слабо верю, потому что мы отвечаем там абсолютно на все обращения, в течении максимум двух дней. Или что-то другое имеется ввиду?
Конечно, можно начать закапываться в эту сторону. Сделать в диалоге с сообщением через API кнопку <<забанить это приложение и отправителя навсегда, почистив все за ним>>, но потом встанет вопрос поддержки всей этой ерунды в мобильных клиентах и т.д. И ведь действительно — личные сообщения не совсем email, и возможно их не стоит в него превращать.
Все методы, которые разрешены для веб-приложений, делаются с токенами, которые выдаются через возврат на сайт, а не на blank.html, без костылей. Все токены, которые уходят на blank.html, не предполагается использовать в веб-приложениях, и уже описано почему — потому что это расширенные методы, только для desktop-приложений.
В этом проблема маленькой команды — в данный момент (и на неопределенный период времени) все, допустим, четверо человек, которые имеют хоть какое-то отношение к решениям в общей схеме работе API весьма заняты своими весьма важными делами, из которых реально активно занимается API один. И из того, что внимание будет привлечено, не следует, что будет обещано что-то сделать в какие-то сроки…
Сейчас действительно можно сделать это через копирование токена из blank.html — но надо понимать, что это вы сами копируете для своего же приложения, а не пользователям предлагаете это делать (против чего мы собственно и, например, написали текст на этом blank.html). Можно подумать, как сделать более человеческий интерфейс для этого действия…
В конце концов, это может быть вообще ваше какое-то серверное десктоп-приложение, через которое работает ваш этот робот-пользователь — к пользовательскому веб-приложению, в котором пользователь дает в браузере разрешение на доступ к каким-то своим данными этот кей автоматической отправки сообщений от своего робота ведь не имеет никакого отношения!