Intent to Implement & Ship: Add `webdriver` property to navigator

[Sergey Shekyan]

Contact emails

she...@gmail.com, bo...@chromium.org

Spec

https://w3c.github.io/webdriver/webdriver-spec.html#interface

Summary

Add enumerable, non-configurable, readonly property `webdriver` to navigator object of a window global object. Property is `true` if CommandLine has either “enable-automation“ or “headless“ switch. Otherwise is `false`.

Motivation

Currently, web developers use various non-obvious ways to infer if user agent is controlled by an automation. This change exposes a standard way for a co-operating user agent to inform a website that the user agent is controlled by automation.

Interoperability and Compatibility Risk

Should it also be exposed on navigator if global object is WorkerGlobalScope?

Edge: No signals

Firefox:No signals

Safari: Shipped

Web developers: Positive

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/723900

Link to entry on the feature dashboard

Requesting one

Requesting approval to ship?

Yes.

[PhistucK]

Will it be possible to return false somehow despite using WebDriver/headless?

The use case is for processing websites that block crawlers/other automated processors due to this value.

It will be pretty wasteful and an overkill to build a customized version of Chromium just for returning false there.

Does the question under the risk section have a multiple-vendor answer?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPkvmc98QJr3-RrVpdj%2B1%2BzvDVcCtmvtQZoM1zEYfdqS-ixEbw%40mail.gmail.com.

[Anne van Kesteren]

On Mon, May 22, 2017 at 7:59 AM, Sergey Shekyan <she...@gmail.com> wrote:
> Spec
>
> https://w3c.github.io/webdriver/webdriver-spec.html#interface

Thanks for the heads up, filed:

https://github.com/w3c/webdriver/issues/922
https://github.com/w3c/webdriver/issues/923

(As a periodic reminder, this is not an endorsement on behalf of Mozilla.)


--
https://annevankesteren.nl/

[Philip Jägenstedt]

I've tested Safari 10.1 and found something strange: navigator.webdriver is undefined, but 'webdriver' in navigator is true. I don't think that behavior particularly makes sense, but it could be achieved by changing the Web IDL type from boolean to any, and making the prose return true or undefined.

Sergey, what behavior were you hoping to ship? Can you make sure that https://github.com/w3c/web-platform-tests/blob/master/webdriver/interface.html is updated to match whatever ends up in the spec and Blink?

FWIW, I think it'd make sense to use [RuntimeEnabled=Something] for this, and make sure that Something is enabled in these circumstances. That'd make it such that 'webdriver' in navigator is false. The spec would have to say something a bit unusual like "the following partial interface must only be supported when ..."

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78hDO5ZhjDz%3DA3pxBcC0d2ARn1uU3LjqHua5x%2BT48aHuhQ%40mail.gmail.com.

[Sergey Shekyan]

> Will it be possible to return false somehow despite using WebDriver/headless?

It is possible to override WebSettings for testing purposes, but I didn't plan to disable the feature through any other mechanisms. 

> Does the question under the risk section have a multiple-vendor answer?

WebKit shipped it.

[Sergey Shekyan]

Philip, 

> I've tested Safari 10.1 and found something strange: navigator.webdriver is undefined, but 'webdriver' in navigator is true. I don't think that behavior particularly makes sense, but it could be achieved by changing the Web IDL type from boolean to any, and making the prose return true or undefined.

I am trying to address returning boolean in https://bugs.webkit.org/show_bug.cgi?id=171997. CC-ing Chris Dumez from Apple. 

> Sergey, what behavior were you hoping to ship? Can you make sure that https://github.com/w3c/web-platform-tests/blob/master/webdriver/interface.html is updated to match whatever ends up in the spec and Blink?

What I was hoping to ship was aligned with the draft of the spec on GitHub. With Anne's comments, [Unforgeable] is reverted and WorkerNavigator should be covered as well. I'll make sure to align WebKit and Blink to the spec that we'll agree on.

[Sergey Shekyan]

Thanks!

[mk...@google.com]

Hey Sergey!

Can you help me understand what use cases you anticipate this property supporting? The spec suggests that it's generally thought of as a protection against denial-of-service attacks, but it's not clear to me that it's effective in that effort. It seems to boil down to an "evil bit" that attackers would simply compile of their attack code (and it seems that DOS attacks are generally happening at the network layer today; JavaScript doesn't enter into the equation).

I skimmed through the WICG thread (https://discourse.wicg.io/t/proposal-to-advertise-ua-automation/1962/11) which raised similar questions about use cases and delivery mechanisms (mnot@'s note about needing to `vary` responses is particularly resonant), and it's not at all clear to me that they've been answered. :)

-mike

[Philip Jägenstedt]

On Mon, May 22, 2017 at 7:58 PM Sergey Shekyan <she...@gmail.com> wrote:

Philip, 

> I've tested Safari 10.1 and found something strange: navigator.webdriver is undefined, but 'webdriver' in navigator is true. I don't think that behavior particularly makes sense, but it could be achieved by changing the Web IDL type from boolean to any, and making the prose return true or undefined.

I am trying to address returning boolean in https://bugs.webkit.org/show_bug.cgi?id=171997. CC-ing Chris Dumez from Apple. 

Thanks. I didn't read all of the discussion, but the latest patch there makes it match the current spec.

 

> Sergey, what behavior were you hoping to ship? Can you make sure that https://github.com/w3c/web-platform-tests/blob/master/webdriver/interface.html is updated to match whatever ends up in the spec and Blink?

What I was hoping to ship was aligned with the draft of the spec on GitHub. With Anne's comments, [Unforgeable] is reverted and WorkerNavigator should be covered as well. I'll make sure to align WebKit and Blink to the spec that we'll agree on.

Yes, by the spec I mean the most up-to-date copy, that's what we should always link to and use as the implementation target.

Matches WebKit and the spec would take care of any compat concerns, but like mkwst@ I wonder if the API can really achieve its purpose. Even without recompiling the binary, one could presumably inject a script to run `delete Navigator.prototype.webdriver` and circumvent this?

[Sergey Shekyan]

Hi Mike, Philip, 

many websites may try to prevent automated account creation, credential stuffing, etc by going beyond CAPTCHA and try to infer from different signals of the UA if it is controlled by automation.

Processing all those signals on every request is often expensive, and if a co-operating UA is willing to inform a website that it controlled by automation, it is possible to reduce further processing.

For instance, Selenium with Chrome is adding a specifically named property on document object under certain conditions, or phantomJS is adding a specifically named property on global object. Recompiling the framework/browser engine to change that identifier to circumvent the detection is always possible.

WebDriver specification is just standardizing a mechanism to inform a website that co-operating user agent is controlled by automation. I don't think denial-of-service attack is the best example, so hopefully this change will clarify the goal. 

Maybe you can help to extend the message to cover concerns raised in WICG thread, to ensure websites are not mis-using it and not making decisions based on this flag that would lead in unexpected results, but that would be a decision of the website, and WebDriver spec is not making things any worse. 

[PhistucK]

Determined "attackers" would simply remove the property, be it by re-compiling Chromium, or by injecting an early script (removing [Unforgeable] makes sure the latter is possible, I believe).

Even non-determined ones could, when using the latter (it will simply be a built in part/option of the package for automated testing libraries).

I think it provides no protection whatsoever and makes websites have some false sense of assurance.

It is like using Content-Security-Policy and forget about any other client side protection - what about browsers that do not support it? What about browsers without that feature (manually disabled, using about:config, --disable-blink-features and the like, or customized builds)?

I mean, it could be a nice property for other purposes (determining test mode and running some helper code that exposes a stable API for identifying key elements in the user interface, say, though I do not think that is a best practice), but certainly not for any abuse prevention.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPkvmc932LNm%3Dfr_fL287hdDA%3DrLKnf5r64yeRXWhVg%3DgyDGUg%40mail.gmail.com.

[Sergey Shekyan]

This is not a protection from anything. If website decide to use it as a protection, good luck with it and they can set the same flag by inferring other signals (and recompiled UAs would hide this or that flag just like in case of navigator.webdriver). This is a standardized way to inform websites that UA is controlled by automation.  

This property is not adding anything or removing. It is standardizing how good UAs deliver that flag. If you believe it can add confusion for web developers, then lets work on the description of feature in the specification.

Also, WebKit exposes this flag for a while know and I haven't heard about any confusions.

[PhistucK]

I was commenting on your words, actually.

> many websites may try to prevent automated account creation, credential stuffing, etc by going beyond CAPTCHA and try to infer from different signals of the UA if it is controlled by automation.

> Processing all those signals on every request is often expensive, and if a co-operating UA is willing to inform a website that it controlled by automation, it is possible to reduce further processing.

Oh, you probably referred to the positive case where no one overrides anything and so the property returns true, so no need to process further because it is really an automation. Yes, this is true. I just hope that it does not make websites skip the checks if this returns false.

So no objections (as if it matters), as long as this is configurable.

☆PhistucK

[Philip Jägenstedt]

Do we have any web developer signals for this that you could link to? The "possible to reduce further processing" bit seems odd, because it'd be a tiny proportion of clients who are controlled by a cooperating UA, so could it really make a measure difference to resource usage or anything like that?

I do think it'd be an improvement if the attribute doesn't exist on the prototype chain at all when not controlled by webdriver. That way, there's no chance that content in the wild could come to depend on it in any way for the majority cases where it's a real user. Not incidentally, that's also how I think we should expose any other test-only APIs that only exist while under WebDriver control, like the APIs in https://wicg.github.io/webusb/test/.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPkvmc932LNm%3Dfr_fL287hdDA%3DrLKnf5r64yeRXWhVg%3DgyDGUg%40mail.gmail.com.

[Rick Byers]

Agreed.  And in the case of APIs enabled only under webdriver, no "intent to ship" should be necessary since the change isn't "web exposed".

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYespbQ1ofVK7sc0agu%3Do9JuKRm4bPwRVjvNZGXnHjB2%3DA%40mail.gmail.com.

[Sergey Shekyan]

Philip, Rick

web developers that are concerned with automated traffic tend not to talk much about their approaches publicly, but discussions online hint that many would benefit from standardized signal that is exposed in this or that form anyway already [1], [2]. 

I like the idea not to expose it on the prototype chain when UA is not controlled by automation.

I'll propose the change in the spec and existing implementations. 

Since I didn't get enough LGTMs, is there a formal way to revoke this Intent To Ship?

[1] https://stackoverflow.com/questions/33225947/can-a-website-detect-when-you-are-using-selenium-with-chromedriver

[2] https://groups.google.com/forum/#!topic/selenium-users/ZlZMIfw1_PU 

[Philip Jägenstedt]

There's no formal incantation to revoke an intent, but I've marked it as "blocked on spec change" to take it off the radar until you poke the thread again.

[Philip Jägenstedt]

In https://bit.ly/blinkintents that is.

[kere...@google.com]

Note that this is now in the webdriver spec.

I believe Edge and Safari already implement it and I know Firefox intends to, so I think we should as well.