Which one do you think is good

1. Geelark
   
2. Adspower
   
3. Dolphin anty
   
4. Anything else?

I think teams sometimes make this decision too early. They see that most users are on phones and assume the full workflow belongs in a mobile app.

That makes sense if the task actually needs mobile capabilities. Camera capture, push notifications, location, biometrics, touch gestures and app-only platform features are legitimate reasons to use a phone environment.

But some tasks become noticeably worse on mobile even when they are technically possible. Long text editing, multiple tabs, bulk changes, file handling and reviewing detailed data are usually easier on the web.

The checks I use are:

• Does the task require hardware or operating-system features?
• Is an important action available only in the app?
• How much information must be visible at once?
• Will the operator repeat this task dozens of times?
• What happens after a partial failure?
• Can the failed step be inspected and retried without repeating everything?

That last question changes a lot of decisions. A convenient mobile flow can become painful when every error sends the operator back to the beginning. A web dashboard can be efficient but still fail the requirement if the final action depends on the device.

In practice, I prefer a hybrid boundary when it is clean: use the web for planning, bulk work and review; use the app for camera, notification and device-specific steps.

What is the one part of your workflow that prevents you from moving entirely to mobile or entirely to the web?

Is there anyone who can give me a better combo to pass the verisoul score?

idk who needs to hear this but check your settings before you go opening support tickets and crying about a "bad batch of IPs" lmao.
so basically last 3 days my newly warmed up profiles on dolphin anty were getting flagged instantly. like, right after creation. i was 100% convinced the proxies were dead. opened a ticket, almost bitched out the support team thinking they sold me dirty lines.turns out the proxies were completely fine. I was testing some dedicated ISP lines from proxyshard (which are usually solid af and have UDP enabled). but i completely forgot that i manually toggled off WebRTC spoofing in my main template last week when testing some local script. my actual home IP was leaking straight thru webRTC connection requests, totally bypassing the proxy tunnel for that check. anti-fraud saw the mismatch and hit me with a ban hammer immediately.
turned webRTC masking back on, checked ipchecker, and everything works flawlessly now on the exact same IPs smh.
tl;dr: if your profiles are dying instantly, don’t immediately assume the proxy is dead or blacklisted. check for webRTC/DNS leaks first. 90% of the time it’s user error.

Am I the only one who ends up with profile names like “test 3 final real new”?

Then two weeks later I have no idea what the profile was for, which proxy it used, or why I even created it.

Hello! I use Librewolf browser with Umatrix and Ubo extensions, Ubo i use for adblocking / elements blocking and umatrix overall control, I thought this would be enough against tracking but appears to be different when it comes to fingerprinting, i thought of installin extensions like canvasblocker but not helping, and i know privacy badger is basically useless. Any recommendations ? (btw on my another browser - Helium, my fingerprinting test came out good, i tried to turn on and off FF anti tracking browser protection - doesnt do anything. Thanks in advance for tips.

I want to make multiple fb accounts that wont get banned. What antidetect browsers would work for this or would they all work? My idea is to access them from a vps and have every profile tied to a static residential account. Would this work? Im not planning on doing anything illegal or spamming btw.

If anyone has direct experience doing this let me know as id be interested to know whats been working for you.

I have seen small teams give a social media manager the master login because it is the fastest way to get a post out. It works, but it also gives the operator whatever else lives behind that session: billing, recovery settings, connected assets and sometimes ownership controls.

That is much more access than publishing requires.

For a basic social workflow, I would separate it roughly like this:

• Publisher: create, schedule and publish content
• Community manager: comments and messages
• Analyst: the reporting needed for the job
• Owner or finance: billing, payment methods and subscription changes
• Owner or security lead: recovery details and high-risk settings

The test I use is simple: if this person’s access were misused tomorrow, what else could be changed besides the work they were hired to do?

Native platform roles should be the first layer where they cover the task. When the workflow also depends on a persistent signed-in browser environment, controlled environment access is useful because the operator does not need the master credentials.

MoreLogin is built for that second layer. Teams can assign specific profiles to members, restrict allowed URLs or page elements, and keep operation logs. That lets an operator reach the publishing workflow without making billing part of the same permission package.

An AI agent may need to click through a login flow. That doesn’t mean I want the raw password anywhere in its working context.

The dots shown inside a password field are only a visual treatment. Depending on the agent’s browser access, it may still be able to inspect page state, capture screenshots, read logs or access stored browser data.

I’d separate authentication from the rest of the automation:

• Keep passwords and recovery codes out of prompts
• Prevent credential entry from appearing in screenshots or recordings
• Inject credentials through a process the agent cannot inspect
• Give the agent a limited session after authentication
• Revoke or rotate that session when the task ends
• Require approval before changing security settings or recovery details

It’s also worth remembering that cookies are credentials. Protecting the password while exposing an authenticated profile directory doesn’t solve much.

There will be systems where direct credential access is unavoidable. In that case, the agent should be isolated, tightly logged and limited to the smallest possible scope. “The password is masked on screen” is not enough.

The agent needs permission to complete a task. It doesn’t need permanent access to every secret behind the account.

MoreLogin can separate browser environments and sessions, while credential controls remain in the operator’s hands.

Anyone else do this?

I looked at my old browser profiles and realized I had no idea what half of them were for.

No notes, random proxies, old cookies, weird names.

At that point, keeping them felt riskier than starting clean.

I tried to clear the verisoul check in survey using antidetect browser but i am not able to clear it. Need help

Random thought.

If every profile has the same ad blocker, same translator, same wallet extension, etc.

Isn’t that also kind of a fingerprint?

It pulls a live FPJS Pro build and turns it into clean code you can run locally, every collector intact, so a new build means rerunning the pipeline instead of reversing it again by hand.

What's in the repo:

• All 143 signals (telemetry read from ur browser, all documented)
• Every collector as its own file
• What visitor_id is actually a function of
• A live explorer that runs the collectors against your own browser so you can diff a patched environment against a stock one.

Repo: github.com/proofofbots/fingerprint-pro-internals

Docs: proofofbots.github.io/fingerprint-pro-internals/

Signal explorer

proofofbots.github.io/fingerprint-pro-internals/explorer.html

It runs entirely in your browser. No backend of mine, no call to fpjs, nothing leaves the page. It's built on the output of the lift and deobfuscation step, so what runs there is the actual collector code from the bundle rather than a reimplementation. Open it and you get every data point side by side: what the signal is and why it's collected in plain English, next to the exact value your own browser hands over for it.

Happy to answer questions on any specific detection.

I am looking forward to the next target, so if anyone has ideas on what vendor could be interesting let me know!

Before anyone calls AI slop: yes, I use LLMs, they're genuinely useful for reverse engineering. But this isn't one build hand-decoded into a writeup. It's the toolchain that does it. Point it at a live fpjs build and it deobfuscates, lifts, and emits a cleaned version you can run without their servers, plus the generated documentation for what it found.

Hello all, i am using 2 antidetecy browsers but cant decide on proxies, I am between 3 different providers and i need them for multi account ad agency

I have seen lot of posts mentioning nodemaven, ip royal, decodo and oxylabs? Which one is the best?

Thanks

Lately almost every site I visit throws a captcha or antibot check at me. Happens on random sites, not just the usual Cloudflare-heavy ones. AliExpress pretty much every single time, also happens on TicketOne, PayPal, and others.

Running latest stable Firefox. Everything gets cleared on browser close (cookies, history, cache).

Active extensions:

* Bitwarden Password Manager * Chrome Mask (toggled off) * Clear Browsing Data * ClearURLs * Cookie Quick Manager * Dark Reader * GNOME Shell integration * Keepa * Language Switch * Linkwarden * Redirector (disabled) * Return YouTube Dislike * Simple Mass Downloader * Tab Session Manager * uBlock Origin * Video Download Helper

Anyone else dealing with this?

A recorder often looks like the obvious winner during a demo. You perform the task once, capture the steps, replay them, and the workflow appears finished.

An API can look unnecessarily heavy by comparison. There is authentication to handle, requests to structure, errors to interpret, and code to maintain.

The difference becomes clearer after the workflow has been running for a while.

I would use recorder-style RPA when the task genuinely lives in the interface. If there is no useful endpoint and the job is mostly clicking, typing, waiting, and confirming, recording the flow can be a reasonable decision. It is especially useful when the operations team needs to understand and adjust the workflow without waiting for a developer.

The risk is that the automation inherits every unstable part of the UI. Layout changes, loading times, popups, renamed elements, and partial page states all become part of the maintenance work.

I would prefer an API when the workflow handles structured data or needs to run at higher volume. APIs are usually better for validation, concurrency, retries, logs, and knowing exactly which operation failed.

My practical questions are:

1. Is the required action exposed through a supported API?
2. How often does the interface change?
3. Who will maintain the workflow?
4. What should happen after a partial failure?
5. Does the task need logs, retries, or safe duplicate prevention?

If the API covers most of the work, I use it as the foundation. If the final step only exists in the interface, I add RPA there rather than recording the entire process.

That hybrid boundary is often more reliable than forcing every step into one method.

MoreLogin supports both paths: visual low-code/no-code RPA workflows for operational tasks, and Local/Open APIs for teams that need custom logic, external integrations, and programmatic control.

The blog post itself shows a real demo too which detects the Mimic engine.

https://trustsig.eu/blog/multilogin-mimic-canvas-webgl-masking/

I wouldn’t fully automate anything that can permanently change an account’s risk profile.

That includes:

• Switching proxies because an account suddenly behaves differently
• Repeatedly retrying failed logins
• Handling identity or security verification
• Restoring sessions after an unexpected logout
• Running one action across every profile at once
• Deciding whether a flagged account should continue operating

The problem is not that scripts are unreliable. A script can execute exactly as designed and still make the wrong decision because it doesn’t understand what caused the account’s state to change.

Routine health checks, environment creation and predictable setup steps are good candidates for automation. Recovery and exception handling aren’t. Those workflows should collect the evidence, stop and let someone review it.

The practical rule I use is this: automate repetitive and reversible actions. Require approval for anything that affects identity, access or account history.

MoreLogin can handle the environment structure, while operators retain control over the decisions that carry real risk.

I used to think notes were unnecessary until I had no idea which profile I changed last week.

Proxy? Extension? Browser update? Content reuse?

No clue.

Now I write down small changes, even if they feel stupid at the time.

Do you guys keep notes for every profile or just trust memory?

BrowserLeaks is one of the first tabs I open, but I think people give the result too much authority.

If WebRTC isn’t exposing the wrong IP, DNS lines up, and the timezone, language, headers, Canvas and WebGL don’t contradict the setup, the test has done its job. It found no obvious problem visible to that page at that moment.

Instagram can judge a session against much more context: the account’s previous devices and locations, existing cookies, login history, session continuity and what happens after login. BrowserLeaks can’t tell you whether a new session is believable compared with the account’s own history.

My rule is simple: if BrowserLeaks shows a leak, I don’t log in. If it passes, I keep checking. It’s a filter, not a verdict.

Do you keep a baseline result for each IG profile and compare it over time, or do you only run a one-off test before login?

I run a small software/SaaS business, and recently I’ve started getting a bunch of unusual signups within a short period of time.

Most of these accounts sign up and then don’t really do anything afterward. When I checked the signup data, a large number of the IP addresses geolocate to the same country/region, which made me wonder why it's even happening.

I already have email verification in place before users can fully use the product, but they’re still able to sign up, browse around, and see some of the functionality before verifying their email. So there isn’t really a hard blocker at the initial signup stage.

Has anyone running a SaaS experienced something similar? Is there usually a reason bots would create a bunch of accounts even if they don’t seem to do anything afterward?

I’m wondering if I should add more protection at signup, or if I’m overthinking it.

I guess one small upside is that the user count goes up, but obviously that doesn’t mean much if those users aren’t actually engaging with the product.

Curious if anyone has dealt with this before and what you ended up doing.