Микробраузеры повсюду. Но что мы о них знаем?

[Mako_357]

Я поставил браузер, что ты мог запустить микробраузер, пока ты смотришь в браузер.

[prs123]

С мобильными клиентами вроде бы понятно. Но вот у того же Facebook и Twitter вполне популярны и десктопные версии, в которых также показываются превью. Но при этом используется полноценный браузер. Есть ли какие-либо отличия по генерации этих превью для сайта в ссылке?

[extempl]

Никакой разницы нет. Мобильный клиент или веб сайт когда видят ссылку — загружают её и читают мета теги.

[prs123]

А javascript и куки тоже отрубаются как-то?

[extempl]

Автор статьи слишком заумно написал. По факту загружается один документ — html. И парсится как обычный текстовый xml.
Оттуда достаются несколько строк — заголовок, краткое описание и картинка. Всё что дальше в теле страницы — значения не имеет.
Это скорее ближе к краулерам, чем к браузерам.

[timurey]

Telegram вообще кэширует страницу и выдаёт кэш. Есть бот @WebpageBot, которого можно просить обновить кэш отправив ссылку.

[mxms]

Да все кэшируют, потому что парсить каждый раз это крайне накладно, да и особо не нужно.

[shifttstas]

т.е даже тут WhatsApp смогли сделать хуже всех остальных — загружать ссылку без взаимодействия с пользователем — потенциальная дыра в безопасности и раскрытие IP адреса.

Впрочем ничего нового.

[Finesse]

Судя по моим наблюдениям, одно любое превью ссылки выглядит у всех одинаково: не важно, успело оно загрузиться или нет, все увидят его так же, как ты отправил. Из этого я делаю вывод, что превью один раз загружает отправитель сообщения, поэтому раскрывается только его IP-адрес.

[rewiaca]

Ну сколько там трафика эти микро(недо)-браузеры жрут? Сервисы же кешируют превью ссылок.
Конечно хотелось бы, чтобы появился стандарт по useragent и в referer, сервисы, передавали бы хотя бы какой-нибудь абстрактный id, сохряняя пользовательские данные. Тогда можно было бы трафик распознавать не как прямой, а как социальный, он же сарафанный, вести статистику. На уровне веб сервера, конечно, не js.