Chrome doesn't list all hosts for extensions
Reported by
gabr...@gsdb.net,
Mar 27 2018
|
|||||||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Steps to reproduce the problem:
manifest.json
------------------
[...]
"permissions": [
"https://www.example.com/*",
"https://www.example.co.uk/*",
"https://www.example.me/*",
"https://www.example.com.br/*",
"https://www.example.ca/*",
"https://www.example.ws/*"
]
Chrome says:
permissions:
• Read and change your data on www.example.com
What is the expected behavior?
Expected:
permissions:
• Read and change your data on www.example.com, www.example.co.uk,
www.example.me, www.example.com.br, www.example.ca and
www.example.ws
What went wrong?
Chrome does not list all hosts in the manifest.json file
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 65.0.3325.181 Channel: stable
OS Version: 16.04
Flash Version:
Tested with Chrome 49, 65 and latest Canary
,
Mar 27 2018
,
Mar 27 2018
And what if 1000 sites are listed?
,
Mar 27 2018
With 1000 sites from www.example.aaa to www.example.jjj, it shows 984.
These are missing:
$ diff expected listed
12,13d11
< www.example.abb
< www.example.abc
47d44
< www.example.aeg
87d83
< www.example.aig
113d108
< www.example.bbc
127d121
< www.example.bcg
184d177
< www.example.bid
202d194
< www.example.cab
211d202
< www.example.cba
242d232
< www.example.ceb
251d240
< www.example.cfa
254d242
< www.example.cfd
304d291
< www.example.dad
641d627
< www.example.gea
825d810
< www.example.ice
922d906
< www.example.jcb
,
Mar 27 2018
,
Apr 4 2018
Able to reproduce this issue on reported version 65.0.3325.181, on latest beta 66.0.3359.66 and on latest canary 67.0.3387.0 using Mac 10.13.3, Ubuntu 14.04 and Windows 10. Observations: 1Issue is seen in old extensions -- Here only few links are seen in permissions tab. 2. In Md-extensions only 984 links are seen (Checked by pasting those to excel and observing count). As this issue is seen from M-60, considering this issue as Non-Regression and marking as Untriaged. Thanks!
,
Jun 1 2018
We did this somewhat on purpose to try and not overwhelm the user. That said, I don't know that it's necessarily helping, and it can be misleading. meacer@, do you have thoughts on this from an enamel perspective?
,
Jun 1 2018
I didn't realize we suppressed same hosts with different ccTlds. It doesn't sound good to suppress when few hosts are present. For large number of hosts, is it possible to do something like this? " This extension can: - Read your data on example.com, example.co.uk, example.de and 997 other sites. " "Other sites" could be linkified and display the whole list when clicked (with an appropriate upper size bound)
,
Jun 1 2018
Yep, we already do this (more-or-less). See screenshots. I think one of the reasons we tried to get "distinct" hosts is because we didn't want to list google.[x] a hundred times, since it's not *terribly* useful to the user, and it can distract from another host in there (e.g., a single example.com amidst 100 google.coms). That said, this is obviously much less helpful when the hosts really are very distinct entities. Another reason is probably that we were worried about scaring people if an extension just wanted to run on google, but because of that had to request 100 different hosts. But, being scary might not be wrong here. I'm open to just showing all the TLDs, but this would be a pretty significant behavior change.
,
Jun 1 2018
Understood. And thinking again, I think this is a reasonable grouping heuristic. Obviously www.example.aaa...www.example.jjj is much less of a problem since most of those TLDs don't exist today. Perhaps a minor tweak could be to say "All example.com sites" instead of "example.com" for [example.com, example.com.br etc], but otherwise the current behavior strikes a good balance between usability and security.
,
Jun 2 2018
I think the largest concern is when the TLDs are very different entities. e.g., ca.gov vs ca.com. On the one hand, we can hope that the user will associate the "scariest" TLD with the warning, but on the other, sometimes these can be significantly different - and the TLD may carry some weight (e.g. some users may say that any extension requiring any .gov is scary). We make the mostly-arbitrary designation that .com is "the most important" TLD, but it isn't always...
,
Oct 24
Issue 894017 has been merged into this issue. |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by gabr...@gsdb.net
, Mar 27 201810.8 KB
10.8 KB View Download