All streams
Search
Write a publication
Pull to refresh
9
0.1
Василий @binque

был(а) 15 минут назад

Send message

Есть способ отслеживания пользователя через специально закэшированные файлы.

Слышал, надо будет изучить. Спасибо.

Получить информацию о версии браузера/OC не сложно

Это уже и так есть в User-Agent.

Да, но динамический он в определенных границах.

Не всегда. Но да, есть мысль добавить сравнение первых двух октетов от адреса.

выявить те аккаунты, которые лайкают только одного пользователя. Или наоборот, аккаунт, у которого большинство лайков только с нескольких аккаунтов.

Это совсем необязательно будет так. Чтобы иметь возможность лайкать, человек должен получить приглашение на сайт. А для этого ему нужно написать посты, которые лайкнут несколько других людей. И дополнительные аккаунты обычно используются не чисто для лайков себя или троллинга, а и как обычные дневники.

чтобы все сделанные им лайки откатывались обратно

Конечно, при бане аккаунта за лайки удаляем его голоса за последнее время.

Ага, уже шутили с другими админами, что единственный гарантированный способ — регистрация по паспорту.

У нас подтверждение аккаунта через почту. Человек со скриншота в статье создает себе адреса на Яндексе для регистрации у нас. Так что это немного усложит ему работу, но не остановит. К тому же, не все люди пользуются Яндексом и Гуглом, и мы так себе ограничим аудиторию.

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

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

Я пока плохо представляю, какие паттерны поведения отслеживать. Самолайки могут быть не на каждый пост, а время от времени. С дополнительных аккаунтов могут лайкать и других людей. Чтобы иметь возможность лайкать, надо написать несколько постов и получить приглашение, то есть это не совсем пустые аккаунты. Но у нас много и обычных малоактивных аккаунтов. И для разных профилей люди могут придумывать разные личности со своими историями и вести дневники об этом. Могут заходить редко и в разное время.
Если говорить про троллинг, то дополнительные аккаунты для этого могут совсем не использоваться. Но начнут, как только мы забаним основной. И хочется это предупредить.

Буду благодарен, если поделитесь полезными статьями по теме.

Можно убрать из класса сигнал и вместо его излучения вызывать QMetaObject::invokeMethod(this, &SignalBasedAsyncQDebugPrinter::handleNextMessage, Qt::QueuedConnection);

Ношу часы Fitbit Versa 2. На них есть приложение для ОС. Умеет вибрировать днем с заданной периодичностью для проверки реальности; вибрировать ночью во время фазы сна с настройкой силы, количества повторений, паузы, продолжительности; или будить вибрацией во время сна. Установил из любопытства, но сам до испытаний никак не дойду.

Это вы смотрите со стороны своего бэкенда. Миллионы пользователей, много мест, где возможны задержки, поэтому они случаются постоянно. Это понятно. А если смотреть со стороны одного отдельного клиента, то как часто ему приходится делать запросы повторно? Именно по вине задержек на бэкенде, а не сети.
Но основной мой вопрос про сеть. Допустим, на улице зима, я зашел погреться в подземный переход. Сеть ловит, но очень нестабильно. Хочу вызвать такси. Приложение будет бесконечно молча повторять запросы?
Приложение, не уведомляя пользователя, сразу сделало перезапрос и получило 404

А зачем делать повторный запрос, не уведомляя пользователя? Таймаут — это, скорее всего, проблема с соединением, которую должен решить пользователь. Подойти к окну, включить вайфай. Если ответы так и не будут доходить, то рано или поздно об этом все равно придется сообщить пользователю. И лучше сделать это раньше, чтобы не заставлять его ждать впустую, не питать ложных надежд, не заставлять перезапускать приложение. Тогда бы и этой проблемы с появлением ошибки при успешном выполнении не возникло бы.
Я просто хочу понять вашу логику. За пост спасибо, интересно.
Недавно анонсировали порт Sailfish OS на кнопочные телефоны. Очень интересно, что у них получится.

Очень интересная мне тема, спасибо за статью. Остался один вопрос, если он глупый, не пинайте сильно. Статью про DSSM просмотрел, ответа там тоже не увидел. Как я понял, если в запросе встретилась определенная триграмма (или слово, словосочетание), то на соответствующий ей вход сети подается единица. Для тех триграмм, которых в запросе нет, на входы подаются нули. А если триграмма встречается в запросе несколько раз, это как-то учитывается? Или это неважно, главное, что она есть?
Им не стыдно делать столько ошибок в падежных окончаниях? Пункт «Подача заявлениЕ в Мосгорсуд в отношении приложения — нарушителЮ» особенно сложно понять с первого раза. На сайте в PDF уже поправили, и то хорошо.

Information

Rating
3,923-rd
Location
Белград, Белград, Сербия
Registered
Activity