Test that it is possible to disable sending terms typed in address bar to google.com at latest Chrome and Chromium builds [type:missing-coverage][type:untestable]

[guest271314]

Unless mistaken the latest Chromuium dev build disabled the ability to configure the browser to not send whatever is typed in the address bar to google . com by virtue of disabling support for setting a search engine other than google . com.

The user literally has no security against sending a remote web site any and all data typed into the address bar, or "Omnibox".

At previous versions of Chromium it was possible to set the default search engine to a user defined value, for example, _ with keyword _ pointing to http://_%s then make the search engine default, where the result is an error because the site does not exist, simply did not have a requirement to search from the address bar of the browser by default or at all, in fact the expected result was forthe error to be thrown, not a redirect to a remote web site, that is, google . com for every key typed into browser address bar; or set the search engine to localhost to provide a native search feature, to serve custom content to the user: self; to not serve every key pressed to a remote service.

It is still possible to turn off search engine at address bar at Nightly 77 per https://support.mozilla.org/en-US/questions/1213978, tested at verified.

Compare the official publication by support.google.com https://support.google.com/chrome/answer/95426?visit_id=637234416111884038-1402470215&p=settings_omnibox&rd=1 which is either still true and correct or not. That needs to be verified so that, pehaps hopefully, this is only occurring here, not everywhere, eventually.

Presently, when attempting to edit default search engine "Google" the field at Settings is read-only! Meaning the user cannot not search only at google . com, and since search at address bar is not capable of being dissabled, the user must search at google . com if they use the address/navigation bar.

Have no way to verify if this is occurring at other architectures or OS'es or tip of the tree Chromium and Chrome builds.

Am not sure which specification is controlling in this matter; at first impression, perhaps navigation; certainly security: it is futile to have multiple issues surrounding UUID's; secure contexts; COOP; et al. concerning actual user security are rendered moot where the browser imposes the restriction of not being able to turn off sending every key pressed in the address bar to google . com, or at least to not be able to verify if that is not occurring.

In light of https://bugs.chromium.org/p/chromium/issues/detail?id=1072248 the evidence indicates that there is a concerted effort to not only disable the ability for user to turn off or change the search engine but also to monitor the mandatory google . com searches ("the algorithm did it") the user by way of censorship; or, resembling the historical events surrounding shipping of a certain browser with an operating system. This is insane.

Kindly find a way to verify if this is an edge case or in fact a Chrome, Chromium implementation policy to intentionally not provide a means to turn off sending every key at address bar to google . com without any option to disable or override that "feature".

[guest271314]

[guest271314]

Actually, this can be tested manually.

[jdm]

This feels to me like it falls outside the scope of testing the web platform.

[guest271314]

This feels to me like it falls outside the scope of testing the web platform.

Not at all.

"feels" is irrelevant.

Open Chromium or Chrome, try to searching, by any means, type "test" in the address bar.

The expected result is that an error should be thrown for a search engine that does not exist.

The problem is that at latest version of Chromium dev build it is not possible to not send data to a remote service. Clearly, that is a security issue for the entire Web itself, and all platforms that operate thereunder.

[guest271314]

It appears there is no way to disable default search engine provider or set a default search engine provider at UI Settings at Chromium 84.0.4122.7 dev channel.

Reading similar issues and revisiting previous experiments disabled search engine provider

$ sudo su
# echo '{"DefaultSearchProviderEnabled":false}' > /etc/chromium-browser/policies/managed/search_policy.json

and set default search engine provider as a Policy at command line

# echo '{"DefaultSearchProviderEnabled":true,"DefaultSearchProviderSearchURL":"http://localhost:8000?q={searchTerms}"}' > /etc/chromium-browser/policies/managed/search_policy.json

and verify result at chrome://policy

Policy name
DefaultSearchProviderEnabled
DefaultSearchProviderURL

Policy value
true
http://localhost:8000?q={searchTerms}

Source
Platform
Platform

Applies to
Machine
Machine

Level
Mandatory
Mandatory

Status
OK
OK

The reasons for removing the capability to disable entirely or modify search provider from the browser UI Settings is unknown. What is known is that privacy, security, and accesibility of and for the user are impacted by the change, and Set your default search engine is evidently obsolete and inaccurate information, inapplicable at Chromium 84.0.4122.7 dev channel.

A user should be able to set and disable any search engine feature at a very simple UI, without read-only fields essentially mandating sending every keypress in address/navigation field to google . com or any other site.

From perspective here the change is repugnant to any theory of an open and extensible web platform.

The extent to which the change to disable supporting changing or disabling google . com as "default seach engine" is in or not in conformace with the relevant "privacy", "security", accessibility, navigation, HTML specifications is left to the authors of those documents to determine.

[jdm]

Testing Chrome-specific UI behaviour is not part of this repisitory's goals.

[guest271314]

Testing Chrome-specific UI behaviour is not part of this repisitory's goals.

If that is the case testing any browsers' UI behaviour is not part of this repository's goals, e.g. getUserMedia() UI, https://github.com/web-platform-tests/wpt/search?q=UI&type=Issues, and all issues or PR relating to UI of any browser should be similarly closed.

[stephenmcgruer]

If that is the case testing any browsers' UI behaviour is not part of this repository's goals, e.g. getUserMedia() UI, https://github.com/web-platform-tests/wpt/search?q=UI&type=Issues, and all issues or PR relating to UI of any browser should be similarly closed.

Do you have any specific issues in mind? You linked to a list of 234 issues, the first page of which at least are (at first glance) for web-exposed, web-standardized behavior.

The Chrome address bar (not any browser's address bar) is not part of the standardized web (nor does anyone have, to my knowledge, a serious proposal for it to be). As such, it is out of scope for this project.

[guest271314]

From the first page of results for "UI" https://github.com/web-platform-tests/wpt/issues/8670. Examples at other pages of results https://github.com/web-platform-tests/wpt/issues/18492, https://github.com/web-platform-tests/wpt/issues/8278.

Manual tests exist in WPT.

When the new tab page is loaded and set to about:blank, typing "test" in navigation field should not result in a cross-origin request to a remote service by default.

(nor does anyone have, to my knowledge, a serious proposal for it to be).

If that language is not included in any reevant specification it would be useful for that to be specified. Here, do not wait for some other individual or institution to propose anything or proceed with the scientific method to verify impact of a decision or omission.

Thus, raised the issue here. This specific area of the Web can be tested. Users in the wild should not be subject to having every key they press being sent to a remote service, with no clear means to change that behaviour at basic browser settings UI. If that is not considered a "serious" privacy and security issue, then it logically follows that none of the other "privacy" and "security" concerns re "cross-origin" requests, embedded content gaining access to and storing permissions, realms, et al. are serious either - if the user cannot perfom the basic task of disabling sending requests cross-origin (from any URL the user might happen to be at, "opaque" or otherwise classified).

As such, it is out of scope for this project.

The labels "missing-coverage" and "untestable" are in the title of the issue.

Am directly stating, without rancor or ambiguity, that the decision to change the ability to not disable sending every key press to google . com in a clear and simple UI is essentially hijiacking the users' entire session - and do not need to and will not await some "standard" to recognize that prima facie fact.

Godel described the phenomenon in mathematical terms that have yet to be refuted nearly 100 years ago, although Wikipedia is not a primary source for anything, that site provides language suitable for this case:

2. The consistency of axioms cannot be proved within their own system.

If WPT choose to do nothing, not address the "missing-coverage" - then there is acquiescence to the dismissal of user privacy and security for lack of an "official" "standard" telling you to address the issue, thus the issue does not exist because nobody wrote it out yet.

There is a very slippery slope being intentionally created when individuals or institutions can basically say "nobody told me!" when the evidence is right in front 'ya, similar to how due to individuals' and even institutions' reliance on official statements for facts, while not performing their own due diligence to vet the claims, "nobody told me!" and "it's new" fail to be borne out by the primary sources: https://journals.plos.org/plospathogens/article?id=10.1371/journal.ppat.1006698 => "Funding:" => NIAD R01AI110964 => https://taggs.hhs.gov/Detail/AwardDetail?ard_AwardNum=R01AI110964&arg_ProgOfficeCode=104 - so the event horizon cannot be "new" to the institution and funded by the institution since at least 2014 at the same time. However, that narrative "works" if vetting is stopped at "it's new" => "response" instead of taking the inquiry a step further and, if possible, reaching the source.

Certainly enhancement of UI was not the goal of the change at Chromium - making it more difficult to not send arbitrary data to google . com by way of a cross-origin request - without permission being granted to do so: try to disable the default google . com search engine yourself. Just the opposite. If a user is not aware of Policy settings, which is generally intended for enterprise use, they could just get used to expecting google . com to get and store forever every key they press by default, without a clear way to disable that "feature". WPT just can't say "nobody told me".

[gsnedders]

We have to draw some line as to what is and isn't in scope; from an interoperability point of view, browser UI is largely irrelevant (certainly some parts of UI do clearly interact with web-exposed features, including, yes, any way that navigates the document), and is something relatively that can be vastly more easily changed.

How applications, including web browsers, running outwith the web platform's sandbox set expectations for user's privacy is up to them, within the degrees to which laws allow, and if users have an issue with the level of privacy the product affords them they can other applications are available.

If the goal of this issue is to make the Chromium project look bad on WPT, I think you vastly overestimate the degree to which people care about WPT results.

If the goal of this issue is more generally to influence change within the Chromium project, you're much better off either doing that within the Chromium project or by collectively grouping together with other concerned individuals to apply pressure to the project through legislative or other means to ensure they uphold your expectations of privacy.

Regardless, I think multiple people in this thread have made it clear that this is out of scope for the project. If you think the project should widen its goals, you are welcome to solicit opinions through the RFC process rather than that discussion happening in a specific issue. Thus, I'm locking this thread because this discussion isn't moving this issue forward while consuming people's time. I am happy to unlock/reopen this if the project does decide to widen its goals, should any such RFC garner broad support.

This is not the first time you've posted issues here which seem primarily to be complaining about Chromium bugs; if you believe the Chromium project is not actively paying attention to its bug tracker, this isn't the place to post them again. Please refrain from doing so again.