|chrome:///settings/searchEngines totally flooded with custom search engine entries|
|Reported by hora...@gmail.com, Jul 31||Back to list|
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36 Steps to reproduce the problem: 1. Right click into the Omnibar, select 'Edit search engines...' 2. 'Manage search engines' settings page appears 3. 'Other search engines' list is filled up with thousands of entries What is the expected behavior? Chrome does not save OpenSearch / Tab-to-search integration from any random website without any confirmation whatsoever, potentially compromising security/privacy of the user. What went wrong? Literally ANY website can add their OpenSearch integration into Chrome, without any control of the user. Did this work before? No Chrome version: 60.0.3112.78 Channel: stable OS Version: 10.0 Flash Version: Please, allow some control over this behaviour. I opened the custom search setting page and was shocked to see the insurmountable amount of search engines stored in Chrome. Just been using Chrome normally for maybe over a year on this system, surfing the web and stuff, and this list is full of search engine spam. Adding insult to injury, the entries cannot be edited as a group. I had to select every single one of them, clicked the 'Edit' button and removed them...
Able to reproduce the issue on windows 7, Ubuntu 14.04 and Mac 10.12.6 using chrome version 60.0.3112.78 and canary 62.0.3171.0. This issue is observed form M45 old versions also. Marking it as Untriaged to get more inputs from dev team. Thanks,
@tbuckley: This is not about the UI, but rather about the OpenSearch feature and how it is handled. Do you know who would be the right person to talk to about this?
email@example.com: recording tab-to-search strings is working as intended. This information is stored as an aid to the user and the site can make no use of it without the user explicitly choosing to select a search engine in the omnibox. But I totally agree with you that if they are undesired, we should make it easier to remove them. dpadpad: Would it be possible to get a "clear all" button here? Or at least a link to chrome://settings/clearBrowserData? (Although I don't know what custom search engines are covered by. "Cookies and other site data"?)
They're covered by one of the clear browsing data options (I think history, I forget). We don't "make it easier to remove" because they'll just be readded, and users will be even more frustrated when they can't prevent certain ones from coming back. And we're not going to add blacklisting because then you'd need UI to edit the blacklist; etc. Basically, there's no use case we think easy removal enables; there's no known security, privacy, or performance issue caused by this list, so we don't currently have a reason to add more tools to manage it. And there are lots of higher-priority things we'd like to do to the list (e.g. add editing of suggest URLs). Recommend WONTFIX.
Agree with pkasting. @jdonelly: Adding a button to "clear all" in the UI would be pretty trivial, but I would first like to understand what is the exact problem we are solving here? As a heavy-user of custom search engines, I never had a problem about custom search engines entries I am not using, and "clear all" would clear the ones I am using, so it would be pointless. If anything, being able to easily clear a subset of the displayed search engines, might be useful. Also note that at  I am adding a filtering/search functionality which will make navigating this list much easier, as well as previous discussion about that UI at . From the original post above: "Chrome does not save OpenSearch / Tab-to-search integration from any random website without any confirmation whatsoever, potentially compromising security/privacy of the user." Can you provide a concrete example of how privacy/security is compromised? Say I navigate to somewebsite.com which registers a custom search engine with the keyword somewebsite.com (open-search declaration can't dictate the keyword AFAIU). As a user the only way to trigger this is to type in the omnibox somewebsite.com<Tab><my query>. In which case the <my query> would be sent to the website. Is this really a security/privacy vulnerability, given that the action that needs to be taken by the user is very explicit?  https://bugs.chromium.org/p/chromium/issues/detail?id=731467#c11  https://bugs.chromium.org/p/chromium/issues/detail?id=632378
> Can you provide a concrete example of how privacy/security is compromised? I don't particularly like that folks can see the websites I've visited by looking through my search engines. Perhaps that's what the user is talking about?
If somebody other than you has physical access to your machine, they can already go to chrome://history and see more than just search engines. On top of that, if let's say you allowed other users to access your machine but wanted to not allow access to you browsing history, you can clear browsing history from the CBD dialog which also clears such search engine entries. Also if you do browse in incognito mode, no search engine is automatically added, which is the same behavior for browsing history (try new profile, go to github.com and see whether this list is updated).
> @jdonelly: Adding a button to "clear all" in the UI would be pretty trivial, but I would first like to understand what is the exact problem we are solving here? I'd like to solve the problem that we have a remove action in the UI for individual entries, so we're advertising that getting rid of them is a thing a person might legitimately want to do. But then we're not offering a way to do this more than one at a time, despite the fact that it's common to have a large number of them in the list. > We don't "make it easier to remove" because they'll just be readded, and users will be even more frustrated when they can't prevent certain ones from coming back. And we're not going to add blacklisting because then you'd need UI to edit the blacklist; etc. The same can be said of cookies and yet chrome://settings/content/cookies offers a "REMOVE ALL" button. And ok, yes, the cookies settings offers a blacklist feature so you can further prevent particular sites from re-adding an entry. But at the end of the day, if there's no significant difficulty in adding such a button, why not give users that control over their own data, even if it is somewhat temporary? I don't buy that they'll be *more* frustrated by clicking one button and then coming back later to see entries reappear than they would be by being forced to click dozens or hundreds of times if they really don't like seeing all those entries.
Removal of individual engines can make sense in cases of manually-added engines, or in rare cases of auto-added engines that are interfering with something different that uses the same keyword (both cases that have come up at Google). The remove button facilitates solving those use cases. It is not intended as usability theater. As for cookies, the behavior of cookies is so opaque (sites being governed by hundreds of cookies stored under different hostnames) that "remove all" is usually the only button that works to fix bad-local-state problems. If there were a simple way to "remove all cookies that affect site X", then yes, that would be a more compelling feature to build. (Also, who said I agreed with the cookie UI -- I've long said that allowing users to disable cookies to begin with was one of Netscape's biggest mistakes, and if they hadn't given people the expectation they could or should do so, hardly anyone would have learned to care!) Anyway, having triaged the bugs on this where users remove these and are furious they're readded, I definitely buy that they will be more frustrated adding this. Having a product give you a veneer of control but not actually respect your choices feels more dishonest than just telling you "you can't do this". In that sense, I do kinda wish we could rip out the individual "remove" ability, but as noted above, there are real cases of individual engines breaking things that that helps solve.
+bettes: Ultimately is up to UX to decide whether a "Remove all" button is desired here. > we're not offering a way to do this more than one at a time Less inline editing is a common theme in the new MD Settings (compared to old Options) and has been discussed before. For example the "Startup URLs" list also allows the user to remove startup URLs but only one at a time, see screenshot. I am not saying that this is ideal, instead I am just saying that UX thought about inline editing as a whole, and they did not think it was as important in those cases.
I'll accept that there's not an obvious good answer here. But this UI is so accessible (not only an omnibox right-click menu entry but the last one, which really sticks out) that we ought to figure out something. Right now it feels a bit like a trap designed to draw in and then confuse or frustrate users. Can we just get rid of the "Edit search engines" action in the omnibox menu altogether? I can see why it was added. It's a smart, contextual way of accessing a setting that drives omnibox behavior. But if it doesn't lead to a UI with information and actions that make sense to all users, we shouldn't put it right in their faces.
Are you saying that the lack of "Remove all" makes you conclude that this UI doesn't make sense to users? I think the UI overall needs help (see the many bugs I've filed on it over the years), but I don't think it's broken or confusing to the level you're implying. More critically, if it _is_ that broken, then it seems like "hide it more" is the wrong response. Broken UI should be fixed or removed, not buried where it decreases our urgency to fix it, and makes users even more frustrated when they can't figure out how to do what they wanted at all. If this is "a smart, contextual way of accessing a setting that drives omnibox behavior", then I think removing the access point would be a bad change. I still haven't heard a use case that "Remove all" really addresses well, and I'm loathe to design UI around "do what users ask" rather than "meet the needs they were trying to address". But if there's tension here over use cases we're not meeting well, then let's continue trying to figure out ways to address those.
I don't think that the UI is bad. I just think that anything involving URLs and wildcards is not useful to 99+% of our user population. Offering a handy (and smart and contextual) shortcut to power users that they'll use once in a while is not worth prominently presenting something that has probably enticed millions of people to waste their time looking at.
I disagree vehemently about that "prominently presenting" part. It's not that this would ever jump into the users' faces unprompted, so I think your 99+% concern for target demographics is a bit of a straw man. Unless I'm interpreting this not entirely correct, and your main idea here was only to remove the "Edit search engines.." entry from the context menu from the Omnibar. Fair enough, if it can still be accessed otherwise, and the UI to deal with OpenSearch entries gets improved at all.. And trying to spin this as a "power users" issue seems also a bit dishonest to me. A browser is an user agent, and that is not coincidentally named this way. Because, ultimately, this is about control of the user over his or her data. I'm very fine with simplifying/streamlining the user experience, but please don't take away any "advanced" options that allow us control and help avoid to being forced anything down the users' throat. I also have a small suggestion to add regarding a 'Clear All/Remove All': This alone does not really help, because, as mentioned here before, removing entries the user actually wants to keep is not really good. The current status is: The list of search engine integrations is divided into two groups. 1. Default search engines 2. Other search engines This could be extended by a new group, like "User search engines", or "Preferred search engines", or whatever you want. Right now, any search engine that gets automatically added lands on "Other search engines". Add a function that allows users to "promote" theses entries _manually_ into the new group. Lastly, make the 'Clear All/Remove All' functionality only clean up the "Other.." group, allowing the user to keep the entry he wants. > Basically, there's no use case we think easy removal enables; there's no known security, privacy, or performance issue caused by this list, [...] Regarding Privacy: I think this is on the same level as the browser history in general. And as another commenter here pointed out before, if you use the standard "Clear Browser Data" function to remove the browsing history, the search engines gets removed as well. Ironically, this is the same issue mentioned earlier, also removing any search engine entries our user wants to keep. But there is an additional privacy issue: Shoulder surfing. Because right now, whenever you use the Omnibar, and enter anything every match with the search engine keyword or key sequence (in my case, for example "g" for Google) immediately triggers the display of a Tab-to-search hint on the right hand side of the Omnibar, which leads us to this, as mentioned before: "I don't particularly like that folks can see the websites I've visited by looking through my search engines." Regarding Performance: Well, at some point this surely becomes an issue, depending on the size of the list. I don't know if anyone ever tested this, but if there is no mechanism implemented to handle this, the data will grow indefinitely.
@17: The proposal you're responding to in comment 13 was indeed simply to remove "Edit search engines" from the omnibox dropdown menu. Discussing multiple groups of search engines is a solution; we need to define the problem. I have repeatedly hypothesized that there is no real use case we're solving with making search engines easier to clear, so it's good that the end of your comment discusses the problems, since that's the critical bit to debate. As noted, the privacy issue is exactly the same as with history, which is why these are cleared when clearing history; and since the suggestions in the omnibox dropdown are from history, the tab-to-search hint provides little or no information to shoulder surfers that isn't already being displayed more obviously in the omnibox dropdown at the same time. So I stand by my claim that the mechanisms we already have to clear search engines, that are tied to clearing history, are the right ones. Regarding performance, the data will not grow indefinitely, because users don't visit an indefinite number of distinct websites. Realistically, if the user uses Chrome heavily for years without clearing, they might have a couple of thousand entries, which should pose no noticeable performance problem.
One solution is to add a syncable pref that prevents websites from adding search engine entries. That way, users who care about curating their own search engine list can use CBD dialog to clear all their search engines, then check that pref and manually curate their search engine list.
Again, what problem is that solution aiming to solve? Moving back to Untriaged, because unless we agree on concrete use cases that we believe are deficient today, we should WontFix this. People have concerns about privacy and security, but the existing behaviors already address most of the concerns, and the additional proposals don't seem to offer meaningful benefits on that front. People want better UX in general for the edit dialog, but this doesn't provide that. People want nice short lists of things because it feels cleaner, but don't seem to take into account the functionality downsides doing this will entail.
> what problem is that solution aiming to solve? The problem is that users who open this dialog feel overwhelmed with the list. They'd like to clean it up, but clean it up a way that isn't as painful as looking at and evaluating each search engine and deciding what to do with it. One solution to this problem (which is mainly a problem for those of us who care about neatness and attention to detail) is a revised UI, a la that mention in comment #17. I would prefer something like 1. default search engines 2. user created / modified search engines 3. auto-generated search engines This helps make clearer a distinction that Chrome makes internally. Auto-generated search engines can be revised at any time by the server. User created/modified ones will never be altered without a user doing something. This kind of structure makes it easy for users who want to clear many auto-generated search engines without having to think as actively about each item on the list: did I add this myself or was this auto-generated? This kind of structure also makes it more obvious the source of search engines and whether they can change without the user's explicit modification.
I'm still looking for more clarity on "they'd like to clean it up". Wanting to clean up is a solution; what is the problem? * I want the list shorter because there are important engines in here I can't find. * I want the list shorter because I don't know why these are here and I don't see any reason for Chrome to have information visible that I don't care about. * I want the list shorter because I'm worried that someone is tracking my actions. etc. Unless we can clearly define the source of feeling overwhelmed and wanting to clean up, it's difficult to debate what, if any, solutions are useful.
When I make the list shorter, it's because there are engines there that I don't use and don't want/need reminders of them. For example, I don't want engines that I used years ago to keep following me around if I have no interest in them. (It's like deleting bookmarks you no longer want or need.) Otherwise, for instance, they get in the way when I'm looking to actively see or change the settings for other engines or to find if I have an engine that does something. The original reporter may have a different opinion.
OK, so in your case, they're making it more difficult to find other entries of value within the list? This might argue that even without easy mass-deletion abilities, things like sortable column headers and a search box would be useful. The multi-section proposal you had would also help here. I wonder, if we did those sorts of things, whether mass deletion would be all that necessary.
I use chrome://settings/searchEngines to manage keyword searches that I add manually (short keywords with no dot), and I almost never find automatically-added search engines useful, while the searches I do find useful don't automatically add themselves (e.g. search YouTube by recently-uploaded; GitHub code search for a specific language). Rethinking this whole thing from scratch, if the goal is to automatically set up useful search engines for users: maybe don't add search engines that websites suggest; have Chrome look through browser history to identify search engines the user actually uses frequently (query history for "similar-looking URLs navigated to immediately after entering text into an input field"? magic here); suggest adding those and prompt for a keyword. I really wish there were a way to turn the current auto-adding behavior off though, because all of the proposed workarounds on https://superuser.com/q/276069/316749 are insane or non-working (I also tried DELETE FROM keywords WHERE keyword LIKE '%.%'; on Web Data but Chrome synced back the unwanted keywords.)
I agree that current situation is not very helpful. And the proposal about having Chrome propose search engines based on history is not that crazy, but not very simple either. How about the following approach, which is already familiar to users (and potentially simpler)? Treat adding a search engine as a permission request. When user navigates to a site that tries to add itself as a search engine provider, show a confirmation bubble, similar to the "know your location" bubble, see screenshot. The user can accept, or block this website from that permission, which would prevent the popup bubble to show up on future visits to that website. On top of that, the permission bubble could have a link to the Settings UI, or even an inline text field, so that the user can immediately customize the trigger keyword.
Websites don't "try to add" themselves as search engines, and gating addition of them on a user permission completely breaks tab-to-search for most users. I am reasonably convinced that the primary problem here is not that the engines exist at all but that the current organization structure of the menu makes it difficult to find and edit search engines that are interesting, because they're buried in a sea of other things. Basically the first bullet in comment 22. This is consistent with e.g. comment 23 and 25. I think the multi-section proposal, sortable column headers, and a search box would all be welcome additions to this interface. I am moderately opposed to any major changes to the engine addition pipeline unless we have first implemented those and still found them wanting.
> Websites don't "try to add" themselves as search engines Technically you are correct. I meant websites declare an OpenSearch manifest file, effectively asking the browser to be included as a search provider. > gating addition of them on a user permission completely breaks tab-to-search for most users. I don't have data to accept or deny this. My personal use case (heavy tab to search user), I handpick all search engines I use. > a search box would all be welcome additions to this interface Already done, see screenshot (top-right search box performs a search engines specific search).
> I don't have data to accept or deny this. My personal use case (heavy tab to search user), I handpick all search engines I use. Just as another data point. I'm also a heavy tab to search user, and I love the fact that engines get automatically added. I don't want to have to think about this and it's nice that, with no effort on my part, I have a bunch of useful search engines available (Amazon, Wikipedia, IMDB to name a few).
The fact that sites can auto-add themselves without approval, and a simple space triggers them, is a UX disaster. I have more than one website that squats a common word (or a single letter - Time Warner likes the letter 'c') Beyond malicious pages, the auto-add is useless to most users - you have no idea what abbreviations are available to you. How would I know what triggers e.g. an amazon search, except by accidentally stumbling across it? That doesn't mean we necessarily need to kill the feature, but we need to address discoverability and user consent.
@30: I don't understand your comment because it seems to assume sites get auto-added with short keywords (common words, letters, abbreviations). They don't; they're only ever added with a keyword of the full domain name, so to trigger via space you'd have to type the full domain name and space (e.g. "youtube.com taylor swift" would likely auto-search for taylor swift on youtube, which is probably what users want). Auto-addition is very much useful to users because it's what powers tab-to-search, which won't work at all without it. If you are seeing engines associated with shorter keywords, and you didn't manually set that up yourself, you're seeing some kind of strange keyword duping/cross-association bug that we're not aware of. Please comment if this does not address your concerns.
+pkasting - I invite you to be less trusting of ISPs DNS :) IIRC, many of the search engines I manually cleaned up were added by various ISPs that outfit their "site not found" response with a search engine. Next: Clear browsing data does IIRC not clean out search engines. I have some questions around that. There's also the point that I do not want 90% of those search engines. Personal preference, but one that I know I'm hardly alone with. Again - I'm not proposing we completely ditch this, I propose we handle it better.
> Next: Clear browsing data does IIRC not clean out search engines. I have some questions around that. I am not able to reproduce this. Clearing the "Browsing history" clears such search engines entries. See screencast for the repro steps I am using. Note that if I edit the search engine manually (by changing the trigger keyword), then clearing "Browsing history" does not remove the search engine anymore, which I think is intentional.
@32: Oh, I don't trust ISP DNSs. We have anti-DNS-hijacking code in Chrome. Maybe it's not hooked up to the right signals; we use it to prevent the accidental search infobar from appearing on DNS hijacks, but I bet we don't use it to prevent adding search engines from such a site. We should. I filed bug 779682 for this. That said, typing such words should search by default in Chrome, so I'm curious how you wound up navigating to these to begin with (to get the bad engines added). As comment 33 mentions, clear browsing history should clear auto-added engines. If it's not, something is strange. The "I don't want these engines" part is much of what the rest of this bug discusses. To "handle it better" we need to understand what "better" means; the discussion on here previously has narrowed down the ill effects of these engines more to aspects like interfering with the management, use, and customization of engines that are wanted, which is why the proposal in comment 27 talks about items to address those.
Yesterday (30 hours ago),
@21,23,25 https://bugs.chromium.org/p/chromium/issues/detail?id=750534#c21 https://bugs.chromium.org/p/chromium/issues/detail?id=750534#c23 https://bugs.chromium.org/p/chromium/issues/detail?id=750534#c25 Exactly. I agree. That is what I had in mind. I think we can all agree that this should be handled better from a UX perspective. Already some good proposals in here(sortable columns,search box, multi-section) Personally, I am also in favor of an option to turn the current auto-adding behavior off.
Today (117 minutes ago),
Issue 711379 has been merged into this issue.
|► Sign in to add a comment|