Extensions permitted to mask themselves as site

RESOLVED INVALID

Status

()

RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: majuki, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5 (.NET CLR 3.5.30729)

While browsing digg.com SkipScreen extension began showing some potentially dangerous behaviour.  The extension triggered an alert('Howdy'); combined with a pop-in requesting feedback.  Annoying as this was, the behaviour of the alert('howdy') was the most concerning.  It reported the alert in the title as being ->from<- the site I was currently on instead of from the extension.

Reproducible: Always

Steps to Reproduce:
1. Install SkipScreen
2. Navigate through a paged archive (ie: digg.com) until it triggers alert('howdy')
3. Observe title of dialog box
Actual Results:  
site title appears

Expected Results:  
Addon Title appears

Comment 1

9 years ago
Extensions can do anything, period.

Also, you've not provided enough steps to reproduce. I created a new profile and installed SkipScreen then went to digg.com and "clicked around" but got no unusual behavior.

I suggest you report the issue to the developers of SkipScreen. Sounds like a less than helpful error message of some kind.

Bug as-filed is INVALID; extensions are not and cannot be restricted in any way.
URL: any
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 2

9 years ago
Occurred while clicking through the pages.  (just click "1, 2, 3, 4, 5, 6" etc) until it appears.

It's not a matter of extensions being restricted, I get that they can execute whatever code they wish and there's no way of stopping that.  Firefox should not report an alert() as being from a site when in fact it is coming from the program/extension itself.

If an alert comes directly from the site's code itself it should report as from that site, if from an extension or Firefox itself the title should reflect that.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 3

9 years ago
(In reply to comment #2)
> Occurred while clicking through the pages.  (just click "1, 2, 3, 4, 5, 6" etc)
> until it appears.

This is not valid steps to reproduce. In fact, I have no idea what you're trying to convey. To file a bug you need to actually list each and every step in detail. Don't just assume I'll figure it out.

> It's not a matter of extensions being restricted, I get that they can execute
> whatever code they wish and there's no way of stopping that.  Firefox should
> not report an alert() as being from a site when in fact it is coming from the
> program/extension itself.
> 
> If an alert comes directly from the site's code itself it should report as from
> that site, if from an extension or Firefox itself the title should reflect
> that.

I don't fully know what you're talking about, because again, you haven't given me steps to reproduce this and not enough info about what you're getting. Generic chrome alerts get "[JavaScript Application]" as their titles. Non-chrome gets "The site at ___ says". Assuming what you're saying is you get the latter, the extension probably injects code into the page to do its work on it. (it does alter sites, after all, so it makes sense) If you have a problem with that then please contact those who wrote it. Just throwing up "howdy" in an alert is pretty odd as-is. ;)

In any case, this is not a Mozilla bug. An extension can do whatever it wants. If it wants to popup a window.alert from within a site with non-chrome privileges and say the site is saying it, then so be it. If the extension is modifying the the site then it *is* the (now modified) site saying it, so it is accurate. Please report complaints about extensions to their developers.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

9 years ago
On the bottom of a site like digg.com there's a list of numbers.  This represents the archive on the site.  Clicking through this archive, SkipScreen's "improvement" code triggered.  

"If it wants to popup a window.alert from within a site with non-chrome
privileges and say the site is saying it, then so be it."

Are there no concerns about legality of doing this?  I strongly believe that extensions should be prevented from this behaviour.  If anything if an extension is reported as representing itself as being from a site it does not own/operate it should be put on the bans list.  Putting it bluntly: It is illegal to falsely represent yourself as someone else.  While this is an obvious over simplification and not like "howdy" is a big deal in this case, but there are larger implications.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 5

9 years ago
Yes, I see the pager at the bottom and clicked through quite a few pages with no result. There must be something else you're not aware of that is required to trigger this, and I don't feel like screwing with this page for half an hour to find it.  ;)

(In reply to comment #4)
> Are there no concerns about legality of doing this?
...
> Putting it bluntly: It is illegal to falsely represent yourself as someone else.

Legality... what? I think you're overestimating what the law really cares about here.

(In reply to comment #4)
> I strongly believe that extensions should be prevented from this behaviour.

Good for you. I don't even disagree with part of your point here. The point that you're not getting here is that this is not POSSIBLE. Extensions become new parts of the application; they have (and need to have) all the same abilities as the application itself. If Firefox can do it than so can an extension, and Firefox is the one putting up alert dialogs so clearly an extension can do it too. It's not a matter of policy, it's a matter of design. Extensions are not CAPABLE of being restricted.

(In reply to comment #4)
> If anything if an extension is reported as representing itself as being
> from a site it does not own/operate it should be put on the bans list.

I don't know whether spoofing falls under what the ban list covers, but 4 points on that:

1) This bug was not filed for that.
2) The ban list is used very sparingly to avoid shady extension developers just mass disabling the ban list itself with their extension. (again, they can do anything) (there's also a long wait due to lots of foot-dragging... ;)
3) Before blocklisting is discussed there's the prequisite issue of listing on addons.mozilla.org (AMO), which this extension is. (and it's editor recommended, as well)
4) There's nothing vaguely malicious here. They just lazily used an alert inside injected code.

I suggest you simply contact the extension developers and ask them to clean up this issue. If it was actually trying to spoof something here, i.e. actually claiming that the site is saying something relevant, then there'd be a real issue here and I'd suggest filing a policy bug with AMO to investigate. However that's clearly not the case.

Please don't make a bigger deal of this than it is. My guess is that you're just now realizing that extensions are by design a security risk. Any software that is installed is a risk in some way. That's one of the many reasons why we have extensions on AMO undergo editor reviews to make sure these risks are mitigated as much as possible.

This bug as-filed is INVALID. Please do not change the status again.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → INVALID
(Reporter)

Comment 6

9 years ago
I do realize extensions are a security risk, I do know that they are by default given carte blanche.  What I don't understand is going to the lengths of creating anti-phishing code, patching every tiny possibility of a security threat (~115 in 3.0.x), and not doing a proper traceback on an alert() call.  I'm not talking about re-vamping the way extensions work, how they can install malicious code, and that they are trusted to a degree.  I'm talking about creating code to do a simple breadcrumb or traceback on browser dialog boxes to determine their origin and update the title accordingly.  To be specific: Only GUI elements that appear to a standard user as being part of the browser (not the site) and communicate an association with the website (ie: title bar).
Resolution: INVALID → WONTFIX

Comment 7

9 years ago
Please read the second part of comment 3 where I briefly mentioned this already. This extension injects code into the page; it changes the page, which is what throws the alert. Upon some examination, it looks like it's actually done using some recycled Greasemonkey code. Again, the alert is actually coming from the (altered) page; there is no confusion within Firefox as to where the alert is coming from. This extension is changing what the site does, and one of the things it's making the site do is throw up a stupid alert.

An extension can use a generic "[JavaScript Application]" window.alert or it can just use nsIPromptService.alert and produce an alert with absolutely any title it wants or it can just make it's own custom window with absolutely anything it so desires. Why would you expect Firefox (rather, Gecko) to know if an alert that's from a webpage was put there by an extension or not? It's not like there's something tracking every move of extensions to know this. Yes, the title will say it's from the page, but then again the extension changed the page so this is *correct*.

Please also consider the scope of what you're complaining about. Yeah, an extension can inject an alert into a page and say it's from the page. Why would you care about an alert? I'd care more about the fact that it can alter a page at will. And to that point, for the umpteenth time, extensions can do anything. (no "by default"; always)
Resolution: WONTFIX → INVALID
You need to log in before you can comment on or make changes to this bug.