<a href="https://www.livechat.com/chat-with/14893845/" rel="nofollow">Chat with us</a>, powered by<!-- --> <a href="https://www.livechat.com/?welcome" rel="noopener nofollow" target="_blank">LiveChat</a>
Multilogin | New Multicores Release Hits Industry First

Multilogin hits another industry first with multicores release


Multilogin has again solidified its position as the safest and most secure stealth browser with its latest multicores release. This newest addition means users can now run browser profiles on different browser versions with the corresponding browser core – reducing detectability and protecting against account bans. Here’s how it works.

What is the importance of browser cores?

The average user of Multilogin is using our software to grow their business through running multiple accounts, into as much as the hundreds or even thousands.

Our virtual browser profiles each have their own distinct and unique browser fingerprint (the collection of information which forms a trackable identity of you online). This means that – unlike many of our competitors – we don’t block third parties from reading the fingerprint, but rather allow them to read it as a genuine, native device.

Among the elements that make up your browser fingerprint is your browser core.

This makes it of high importance to your detectability, but the understanding of that has changed over time. To demonstrate the importance of our new multicores release, let’s have a quick look at how understanding of fingerprinting in relation to browser cores has evolved. We’ll then return to our current understanding and explain how our update will help protect against account bans.

How has understanding of browser cores and fingerprinting evolved?

Early days: static fingerprints and variable browser cores

In the very early days of antidetect browsers, the goal was to randomize fingerprints as much as possible.

This means that a user on, for example, browser core version 80 could be given a whole range of fingerprints as old as 40 up to even several versions newer than 80.

The understanding of browser cores were that they were there to maintain website functionality and not a necessary requirement for good stealth.

Then, in 2018, our research at Multilogin found that websites were paying attention to the pattern of a new core but unchanged fingerprint. Wider ranges of versions also made it easier for websites to pick up on discrepancies. For instance, finding a mismatch between core 80 and fingerprint pattern from version 86 would be much easier than between 86 and 87.

 In November 2018, we became the first solution in the world to address this problem through:

1.      Releasing a browser profile update mechanism to simulate regular browser updates

2.      Committing to releasing browser profiles every four versions

Further changes: discrepancy reduction and more frequent updates

Our research never stops, and by 2019 we had ascertained that, one the one hand, having a discrepancy between a browser core and a simulated browser fingerprint is often detrimental to stealth. On the other hand, using a lot of profiles with the same browser version does not negatively impact success rates.

Based on this, we introduced Strict mode, which limited the range of possible fingerprints to those directly matching the browser core (eg only fingerprint v.80 on core v.80).

Then, in late 2020, we discovered that anti-fraud systems were increasingly focusing on specific areas of browser fingerprint manipulation, including focusing on analyzing popular browsers like Google Chrome.

In terms of browser cores here, the key turned out to be speed. In the case of Chrome, the majority of users have automatic updates turned on and use Chrome at least once a month, meaning over 90% of them get browser updates within the two weeks after their release.

Therefore, in terms of browser fingerprinting, an old browser core is a suspicious red flag.

We reacted fast and began updating even more frequently for both Stealthfox (based on Firefox) and Mimic (based on Chromium).

Recent developments: the problem of teamwork

The solution we had arrived at above worked excellently for single users. But what about teams?

As you know, Multilogin has a feedback mechanism that lets users report account restrictions if they happen. The largely occur due to reasons outside of our control, such as user input and behavior or the quality of a proxy.

Nonetheless, we noticed some patterns and hypothesized that suspensions were more common in teams.

It had seemed logical that when one team member updated Multilogin, all team members would do the same. However, nothing could have been further from the truth! We found teams using as many as 15+ different versions of the applications, with seven different browser core versions. This same team was then routinely launching the same profile on different cores.

Interestingly, our competitor analysis also shows that there was not a single stealth tool that married best practice in antidetection with convenience to the user. In fact, most models are still stuck in the static fingerprints and variable cores, even though we live in 2022!

Our development teams therefore set about resolving the issue – and our innovative multicores update took shape.

What is the multicore solution?

To recap on the above, we needed a solution that offered the following:

·        Elimination of the discrepancy between a browser fingerprint and browser core version

·        Leaving the user to choose whether to update the fingerprint

·        Leaving the user to choose whether to update their Multilogin application

The first point might seem in conflict with the last two, and many others would give up – but we have made it possible.

Multicores is a design in which each browser profile can have a fingerprint of a different version. At the same time, that profile is always – and can only be – launched on a browser core that corresponds to that version. For example, fingerprint version 80 will never be launched on core version 82.

This means that with multicores, we ship all necessary cores to any version of the application. In practice, this may mean that in Multilogin version 6.2 you will have browser cores version 99, 101, 103 etc. All required cores are downloaded automatically whenever a user needs them or after a new core update was released.

We also provide users with the familiar tool that replicates the browser update process. If you need to update a browser profile to a newer core, click “Update” on the right-hand panel and an update to the latest available core will be performed automatically.

What does this mean for you?

Our multicores update is an industry first that means all browser core discrepancies are fixed not just when working alone but also in a team – even when different team members have different preferences for updating Multilogin.

You have maximum flexibility within the framework of the industry-leading security that you expect from Multilogin!

To get the latest beta version of our software, including the multicore update, visit the Download page.