CODEWITHSUNDEEP
javascriptpuppeteer
Kex
Kex

Reputation: 8599

Confusion over args for Puppeteer

I am a little confused over the arguments needed for Puppeteer, in particular when the puppeteer-extra stealth plugin is used. I am currently just using all the default settings and Chromium however I keep seeing examples like this:

let options = {
    headless: false,
    ignoreHTTPSErrors: true,
    args: [
        '--no-sandbox',
        '--disable-setuid-sandbox',
        '--disable-sync',
        '--ignore-certificate-errors'
    ],
    defaultViewport: { width: 1366, height: 768 }
};

Do I actually need any of these to avoid being detected? Been using Puppeteer without setting any of them and it passes the bot test out of the box. What is --no-sandbox for?

Upvotes: 3

Views: 10010

Answers (1)

Tibebes. M
Tibebes. M

Reputation: 7548

these are chromium features - not puppeteer specific

please take a look at the following sections for --no-sandbox for example. https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#setting-up-chrome-linux-sandbox

Setting Up Chrome Linux Sandbox
In order to protect the host environment from untrusted web content, Chrome uses multiple layers of sandboxing. For this to work properly, the host should be configured first. If there's no good sandbox for Chrome to use, it will crash with the error No usable sandbox!.

If you absolutely trust the content you open in Chrome, you can launch Chrome with the --no-sandbox argument:

const browser = await puppeteer.launch({args: ['--no-sandbox',
'--disable-setuid-sandbox']});

NOTE: Running without a sandbox is strongly discouraged. Consider configuring a sandbox instead.

https://chromium.googlesource.com/chromium/src/+/HEAD/docs/linux/sandboxing.md#linux-sandboxing

Chromium uses a multiprocess model, which allows to give different privileges and restrictions to different parts of the browser. For instance, we want renderers to run with a limited set of privileges since they process untrusted input and are likely to be compromised. Renderers will use an IPC mechanism to request access to resource from a more privileged (browser process). You can find more about this general design here.

We use different sandboxing techniques on Linux and Chrome OS, in combination, to achieve a good level of sandboxing. You can see which sandboxes are currently engaged by looking at chrome://sandbox (renderer processes) and chrome://gpu (gpu process).\

. . .

You can disable all sandboxing (for testing) with --no-sandbox.

Upvotes: 3

Related Questions