1376793 - Ability to customize the about:neterror page through WebExtensions

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, enhancement, P5)

Description

[Hector Zhao [:hectorz]]

Beijing office is customizing the style and content of about:neterror with an extension. We place a Baidu search form below the original content, and prefill it with the extracted keyword for a failed search with Google.

Comment 1

[Andy McKay]

I'm a little concerned about allowing access to extension authors to this page. Primarily because you could do things like hide a serious network error (eg a SSL error) and present that as something else. I'm not sure what kind of error about:neterror covers though.

I think the Beijing office places content below the error in a specific area which is less worse than overriding the whole page. But still changing a page like this still worries me.

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I agree with your concerns here Andy. It sounds useful, but we need to ensure that we constrain this feature somehow so that it can't interfere with the important information provided by about:neterror. At a minimum I would want to see:
- web extension content is constrained to an area of the screen so that it can't overlay on top of important messages 
- web extension overlay code is segregated from chrome privileged content (i.e. something like option pages where the extension content is segregated)
- We might also want to consider some kind of visual hint that the content is coming from an extension (not the browser) if we plan to open this API up (e.g. show a border, and maybe the web extensions icon and title etc) This however is probably a topic we want to think about more broadly

Comment 3

[Johann Hofmann [:johannh]]

I don't really see the attack vector, an extension could simply inject a content script that overwrites the entire content of a page or silently keylogs your password anyway, right? What's to gain by hiding certificate errors?

Personally I still support the idea of having a segregated area for extension content, simply because

- The cert/neterror page is a huge entangled mess of code that I don't want to expose to content scripts right now, also to avoid opening up attack possibilities for obtaining Chrome privileges or access to settings we don't want to expose by exploiting the strange message passing that's going on.
- It's probably a pain for us to maintain that page with extension authors messing around with it.

Comment 4

[Andy McKay]

(In reply to Johann Hofmann [:johannh] from comment #3)
> I don't really see the attack vector, an extension could simply inject a
> content script that overwrites the entire content of a page or silently
> keylogs your password anyway, right? 

At the very least, they'd need to ask for permission to do that and users will be prompted about it.

Comment 5

[Caitlin Neiman [:caitmuenster]]

Hi Hector, this has been added to the agenda for the December 19, 2017 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/1KwfTum8Ow5w4afPAOvShpu_d_MNtahhOIqL3-Em9lLc/edit#
* Vision doc for WebExtensions: https://wiki.mozilla.org/WebExtensions/Vision

Comment 6

[Paul Theriault [:pauljt] (no longer reading bugmail)]

(In reply to Andy McKay [:andym] from comment #4)
> (In reply to Johann Hofmann [:johannh] from comment #3)
> > I don't really see the attack vector, an extension could simply inject a
> > content script that overwrites the entire content of a page or silently
> > keylogs your password anyway, right? 
> 
> At the very least, they'd need to ask for permission to do that and users
> will be prompted about it.

Extensions can't inject content script into about: pages. If it was an iframe they could inject into the parent page, but in that case the parent page can do that already.

Totally agree with you about the segregation though. 

One thing I was curious about: it looks as though we listen on the chrome global for the custom events sent about:neterror:
https://searchfox.org/mozilla-central/source/browser/base/content/content.js#237 

I don't see any checks on the events there (like checking that the event came from about:neterror), so if for example, we allow web extensions to inject content into an iframe inside about:neterror, what happens if they fire the same custom events? Even if the frame is sandboxed, will it still be caught on the chromeGlobal?

Comment 7

[Geoffrey De Belie (Smile4ever)]

I would use it to add extra buttons for archive.org (Wayback Machine), Google Cache, ...

Comment 8

[Mike Conca [:mconca]]

Policy Review Comments (https://wiki.mozilla.org/WebExtensions/policy)

There appear to be concerns with security and privacy (II) with this proposal. Right now, extensions are prohibited from modifying any about: page.

I also have concerns about exposing one particular about: page for one particular use case. That runs counter to providing API that are high-level, useful and provide broad utility.

Comment 9

[Andy McKay]

The most valid use case here is to show the user an informative error message on an error. There are better ways to do this, rather than get into customising this page. For example: an extension can occur when an about:neterror is shown and then we could show a popup notification bar on the page.

As per comment 2, anything that alters this page would need to be heavily locked down and that really doesn't seem worth the effort. A generic solution that would allow: a) an extension author to detect when the error page is shown and b) show some sort of notification to the user, would seem like a better fit to me.