3

I recently made a Chrome Extension (FrontPage) which uses the New York Times API.

I send an AJAX request to the API and it responds with JSON. However, in order to be able to do so, I need to set permissions in the manifest.json file to be https://api.nytimes.com/* thusly:

  ...
  "permissions": [ "https://api.nytimes.com/*" ],
  ...

in order to not have the Extension crash and burn and give a Cross Origin rejection.

However, any time a user installs my Extension from the Web Store, they get a scary looking warning along the lines of: "[The extension] Can access all your data on api.nytimes.com".

All I'm doing is sending a request and receiving + parsing a response from a public API. The warning seems excessive. I'm not storing in any way, any user data.

Is there a way around this i.e. is there a way to use an API in a Chrome Extension without displaying to the user this warning? Am I approaching this in a non-canonical way?

Community
  • 1
  • 1
ShivanKaul
  • 687
  • 1
  • 8
  • 21
  • I suppose unless google offers some more granular permissions, then your extension technically *can* access all user data on the website. Which means that the warning is rightfully placed. – Jozef Legény May 20 '15 at 12:06

3 Answers3

2

There is no way to do what you are asking. chrome is just informing users what your app can do. They have no way to trust you. What I suggest you do and what I have seen others do is inform potential down-loaders of the warning on your apps description page.

Something like

`Warning: you may get a scary warning message blah blah because my extension blah blah, I don't do anything with your data, I encourage you to look at the source if you are curious."

Most people are used to seeing and accepting these warnings by now anyways. Yours actually make a lot of sense, because users can intuitively see how that page is related to your extension.

Read and modify all your data on all websites you visit

Is a bit more tricky to deal with.

To more directly deal with your original question: Its the stuff you put in the "permissions" array that determines what warnings (if any) get generated.

Here is a list of all of the possible warning messages and the permissions they apply to. The page also contains a listing of the permissions which don't generate any warning messages.

abraham
  • 46,583
  • 10
  • 100
  • 152
Luke
  • 5,567
  • 4
  • 37
  • 66
2

If the API is public, then chances are that it has permissive CORS headers enabled.

Some anecdotal evidence from the developers forum suggests it is the case for NYTimes API, for at least some endpoints (can't test it without an API key). If it's not enabled for the endpoint you are using, you can request that.

In that case, you don't need a permission for cross-origin requests to that API, XHR should succeed anyway.

Xan
  • 74,770
  • 16
  • 179
  • 206
  • NYTimes API does have permissive CORS headers, but because it's a Chrome Extension, I think it's required that I set permissions, based on what I'm reading off of [the Cross Origin Chrome Extension resource](https://developer.chrome.com/extensions/xhr). – ShivanKaul May 31 '15 at 22:54
  • Nope, if CORS is set to * you don't need permissions. You can override restrictive (or missing) CORS headers with permissions. – Xan May 31 '15 at 23:08
1

Answers by Xan and Luke are of course correct but haven't mentioned an important alternative that will help you:

You can make it an optional permission and request it later at run time prefaced with an explanation as to why it's needed (better yet first ask for it, and if the user declines then explain them they must accept).

Just remember optional permissions must be asked after a user action, so show a modeless dialog with a button and ask for permission when the button is clicked. i had a similar issue in my extension.

In my case i just needed to create and read a specific google spreadsheet but that means asking for their entire google drive for read/write.

Zig Mandel
  • 19,571
  • 5
  • 26
  • 36
  • yay i usually do that a little after once I get to my laptop – Zig Mandel May 20 '15 at 12:55
  • to the editor that made edit #3, its not a good idea to show a modal dialog as it would prevent the user from interacting with the site when they dont care about the extension right then. Thus I reverted that part of your edit and put back "modeless". – Zig Mandel May 20 '15 at 23:36