1430541 - Grant activeTab permission to omnibox.onInput* events

Status: RESOLVED WONTFIX

(WebExtensions :: Frontend, enhancement, P5)

Description

[MrOtherGuy]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20100101

Steps to reproduce:

-


Actual results:

-


Expected results:

This isn't actual bug but an enhancement request for omnibox API.

Currently activeTab permission is only granted when the user interacts with: context menus, pageAction, browserAction and keyboard shortcut. Shouldn't omnibox input events be treated as direct interaction too?

I can see that this would allow leaking current tab url to external service if input is sent somewhere. But I don't think there is really any incentive to use this for malicious purposes instead of just requesting tabs permission.

This would allow extensions to select the omnibox behavior based on tab url which I think could be pretty useful. If I'm not mistaken, it would also allow injecting javascript to the current page from urlbar much like bookmarklets, which would be really handy.

Comment 1

[Caitlin Neiman [:caitmuenster]]

Hi jastekken, this has been added to the agenda for the January 23, 2018 WebExtensions APIs triage. Would you be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting: https://wiki.mozilla.org/WebExtensions/Triage#Next_Meeting
* Meeting agenda: https://docs.google.com/document/d/1Mc0h5OVd30WBjCORssdifZRXYQrk6WcTqX1cw6ADO9k/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 2

[MrOtherGuy]

Sure, I'll try to join via IRC.

I've made two simple extensions to test this which work as follows:

* Register omnibox keyword "omnitest"
* Type "omnitest alert('Hello World')" to location bar
* Content page alerts 'Hello World'

The first one has host permissions for everything via *://*/* as well as tabs permission - This works as intended
The second one only has activeTab permission and doesn't work.

The purpose of this bug is to make the second one work. Host permissions for everything + tabs is way too broad when you only want to interact with current tab. I would argue that activating omnibox keyword is deliberate action from the user and it should  thus grant activeTab permission like clicking browserAction or menuitem.

Comment 3

[Kris Maglione [:kmag]]

We discussed this and unanimously agreed that that this is not worth the risk.

When users type into the URL bar, they're generally not conscious of the fact that they're interacting with an extension, and they generally don't associate that action with the current page. Their intent is to navigate away from the current page, so we don't feel that granting the active tab permission, either during input or after selecting an entry, is appropriate.

If you want to implement functionality like this, you'll need to explicitly request URL permissions.

Sorry.

Comment 4

[skomorokh]

Ran into this because I was going to report much the same. Actually have a concrete use case for it though: re-running the last search against a different engine. Now that we have the search API, it was easy enough to implement, though I do need to parse the query out of the current URL since no search history is exposed. To do this, I must request the `tabs` permission which felt quite excessive--is there an alternative?

https://addons.mozilla.org/firefox/addon/search-again/

I notice that Chrome does seem to permit it for the `omnibox.onInputEntered` handler:

https://developer.chrome.com/extensions/activeTab#invoking-activeTab