3х3 - в зависимости от класса делает от 30 до 130 ошибок на 10.000 решений. Я периодически переобучаю модели, по мере набора датасета.
Нормальный результат, особенно если это живая статистика на 10 000 решений, а не разовый удачный прогон. Разброс 30–130 ошибок по классам как раз показывает, где данные уже хорошо закрыты, а где класс пока сложный или хуже представлен в датасете.
Если переводить в проценты, это примерно:
- 30 ошибок на 10 000 — 99.7%
- 130 ошибок на 10 000 — 98.7%
Для 3x3 это уже вполне предметный уровень, без маркетингового “почти идеально”. Переобучение по мере роста датасета тоже правильный подход, обычно именно так и вытягиваются самые проблемные классы. Интереснее всего тут смотреть не только на общую ошибку, а на то, какие именно классы чаще всего путаются между собой — там обычно основной резерв по улучшению.
отслеживает изменившиеся картинки, проверяет их и прокликивает. Нажимает Verify только когда все картинки проверены и нет на них искомого объекта.
Нормально описано. По сути можно коротко так сформулировать: расширение отслеживает обновление изображений в задании, перепроверяет новые картинки и автоматически отмечает подходящие. Кнопку Verify нажимает только после полной проверки всех изображений, когда среди оставшихся уже нет искомого объекта.
абсолютно всё решение локально. Есть редкие обращения к серверу через некоторое время, когда браузер, компьютер и сеть не нагружены, что бы скинуть на сервер встретившиеся картинки, для пополнения датасета, но это можно отключить, отключив репорты в настройках.
Это хороший момент, особенно если репорты реально опциональны и отключаются в настройках. Для многих как раз критично, чтобы основная работа шла локально, а не через постоянную отправку данных куда-то наружу.
Но тут обычно сразу возникает пара уточнений, которые людям важны:
- что именно уходит в репортах — только сами картинки или ещё метаданные;
- есть ли анонимизация;
- можно ли посмотреть очередь на отправку;
- есть ли явное уведомление, что репорты включены.
Если это всё прозрачно описано, доверия к такому решению будет заметно больше.
"permissions": [
"alarms", \\ планировщик для загрузки датасета
"scripting", \\ не используется в версии из магазина, используется в версии с сайта для функционала, когда расширение выступает в роли вашего личного антикапча сервиса
"declarativeNetRequest", \\ Вставляет hl=en в запросы к reCAPTCHA для принудительного английского языка, что бы не тянуть за собой библиотеку для поддержки всех языков рекапччи
"idle", \\ проверяет активен ли браузер, что бы отчёты слать только если браузер не занят
"storage" \\ хранит настройки
],
В целом список выглядит нормально, но формулировки лучше чуть причесать, чтобы не было лишних вопросов у модерации и у пользователей.
Например, так читается понятнее:
```json
"permissions": [
"alarms",
"scripting",
"declarativeNetRequest",
"idle",
"storage"
]
```
И пояснение к ним:
- `alarms` — используется для планировщика задач, связанных с периодической загрузкой датасета;
- `scripting` — в версии из магазина не используется; требуется только в версии с сайта, где расширение может работать как персональный антикапча-сервис;
- `declarativeNetRequest` — используется для добавления `hl=en` в запросы к reCAPTCHA, чтобы принудительно использовать английский язык интерфейса и не подключать отдельную библиотеку для поддержки всех языков reCAPTCHA;
- `idle` — позволяет определить, активен ли браузер, чтобы отправка отчётов выполнялась только в момент простоя;
- `storage` — используется для хранения пользовательских настроек.
Из мелочей:
- в JSON комментарии через `\\` невалидны, если это именно кусок `manifest.json`, такие пояснения нужно выносить отдельно;
- фразу “что бы” везде лучше писать слитно: “чтобы”;
- “не используется в версии из магазина” может вызвать вопрос, зачем тогда permission вообще в store-версии, если он реально там заявлен. Тут лучше быть максимально точным. Если permission присутствует в store-сборке, но код не задействован — это стоит отдельно объяснять. Если не присутствует, тогда лучше так и написать: “включается только в версии с сайта”.
Если это текст для описания прав доступа, то в таком виде он уже выглядит гораздо аккуратнее и понятнее.
На сайте .zip можно скачать и поковырять. На гитхабе скоро появится
Тогда это уже выглядит намного спокойнее. Если архив можно скачать и посмотреть содержимое, это хотя бы дает возможность проверить, что там внутри, а не ставить вслепую. GitHub потом вообще будет самым нормальным вариантом — и для прозрачности, и для истории изменений. Главное, чтобы выкладывали именно актуальные исходники, а не просто “для галочки”.
пока никак, новых классов у рекапчи не было много лет. Если появятся - тогда сделаю автообновление классов в самом расширении через сервер
Нормальный подход. Если структура у reCAPTCHA реально годами не меняется, то городить обновление заранее смысла мало. А если начнут что-то крутить, автообновление через сервер выглядит самым практичным вариантом, лишь бы был фолбэк на случай, если сервер недоступен.
Даже слабый ноут может решать по 300 картинок в секунду. Поэтому задержку пришлось выставлять в ручную, что бы рекапча не считала вас роботом.
300 картинок в секунду на слабом ноуте — это, конечно, уже уровень, где основная проблема не “как ускорить”, а “как специально не палиться”. Забавно, что в таких случаях бутылочным горлышком становится не железо, а необходимость имитировать человеческую медлительность.
аудит от модераторов стора был выполнен, без этого в сторы не попасть
Проверка стора — это все-таки не полноценный security audit в том смысле, в котором это обычно понимают. Модерация чаще смотрит на соответствие правилам, явный вредоносный код, запрашиваемые разрешения, жалобы и какие-то базовые риски, но не проводит глубокий разбор всей логики, инфраструктуры, обновлений, цепочки зависимостей и того, что может всплыть позже в новых версиях.
Плюс даже прошедшее модерацию расширение не становится автоматически безопасным навсегда: обновление может изменить поведение, аккаунт разработчика могут скомпрометировать, зависимости могут подтянуть что-то неприятное. Так что публикация в сторе — это скорее минимальный фильтр, а не гарантия уровня “прошло серьезный аудит”.
