chrome.management.setEnabled allow some evil developers to disable others chrome extension.
Reported by
fangzho...@hiretual.com,
Jul 26
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Steps to reproduce the problem: 1. Install https://chrome.google.com/webstore/detail/social-lead-machine/ikcleedhpnkajcggbaehhbpldeeogkkd 2. The extension is enabled. 3. Install https://chrome.google.com/webstore/detail/dux-soup-for-linkedin/ppdakpfeaodfophjplfdedpcodkdkbal?_asi=1 What is the expected behavior? The first installed chrome extension is being disable by the second one. What went wrong? An harmful behavior happened. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 67.0.3396.99 Channel: stable OS Version: Ubuntu 18.04 Flash Version:
,
Jul 27
Able to reproduce the issue on reported chromium version 67.0.3396.99 also on latest chrome 70.0.3503.0 using Mac 10.13.5, Ubuntu 17.10 and Windows 10. Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged. Thanks!
,
Jul 27
,
Jul 27
Thanks for the report! While this is scary, it is largely WAI. The purpose of the management.setEnabled() function is to allow extensions to toggle the enabled state of other extensions. This is why we have the permissions warning for the extension API. I could see potentially tightening this to require more user interaction (e.g., requiring a user gesture, possibly displaying a dialog, etc), but it's not something that's on our road map at the moment, and I don't think we'll completely remove this API.
,
Jul 27
I should point that we considered setEnabled in bug 178319 and that was mainly the reason that bug is still open. Leaving the behavior unchanged sounds reasonable to me (I'll close bug 178319).
,
Jul 27
It is frustrating for a developer whose extension get disable by it's competitor's extension (as reported in this bug). What should the developer do in this situation?
,
Jul 27
> I should point that we considered setEnabled in bug 178319 and that was mainly the reason that bug is still open. Leaving the behavior unchanged sounds reasonable to me (I'll close bug 178319 ). To be clear, I'm not against adding some additional hurdles here (like a one-time dialog); I only WontFix'd this bug because I don't think the fundamental ability for one extension to disable another is something we'll want to change. > It is frustrating for a developer whose extension get disable by it's competitor's extension (as reported in this bug). What should the developer do in this situation? In general, we treat extensions as acting on the user's behalf, so when an extension disables another extension, we treat that as the user's intention. As such, there isn't much (by design) that an extension can do to prevent this. I can understand that this could be worrisome if the extension *isn't* acting on the user's behalf (and is instead, e.g., using this as an anticompetitive measure as described here). The steps to mitigate this would probably be to have stronger user confirmation of what the extension is doing (again, user gesture, dialog, etc). I'm not opposed to having that discussion, because this *is* a scary API. If that's something you think would be be beneficial, we can file a separate bug to track that (or re-open 178319).
,
Jul 27
Have a clear confirmation of what the extension is doing sounds a good idea. I will re-open bug 178319 to keep track of this. At the same time, what is the best way for the developers to complain/resolve similar anticompetitive abuses?
,
Jul 28
Thanks for taking care of this issue but I feel disappointed to see it is wont fix. I am a developer from Hiretual and our extension is being disabled by the extension, dux-soup, mentioned in the description above. And from their source code(the attachment), they disabled more than 10 chrome extensions, our extension id is the last one in the list. This behavior harms our business already and brings troubles to our customers. We didn't notice it until one of our customers reported it to us, so it is hard to know the real number of affected users and how much lose caused by it. As our business depends on chrome extension a lot, I believe it will be a lot. If Google keeps allowing this behavior, we may consider leaving the chrome extension market and find another way. Also, I think this malicious behavior could ruin the chrome ecosystem very easily. 1) If one developer could benefit from it, then there will be a lot of followers. In fact, the dux-soup has more than 30,000 weekly users, which means about 30,000 * 10 = 300,000 extensions are being disabled by it, and most of the users may not even notice it. It is not a small number for the enterprise industry. 2) Others like us, have to take some effort to defend this behavior, either disable their extension or do something else. It will transfer the chrome extension market into a battlefield and bring costs to companies and troubles to the users. There will be no winners at the end expect those evil people, just following Gresham's Law. Please think twice about it, thanks.
,
Jul 28
> At the same time, what is the best way for the developers to complain/resolve similar anticompetitive abuses? There's an option to report abuse for an extension in the webstore detail page. That's likely the best channel. |
||||
►
Sign in to add a comment |
||||
Comment 1 by vamshi.kommuri@chromium.org
, Jul 27