InformAction Forums

Randomly this popup appears:



Could it be caused by another WbeExtension? (e.g. my Emoji toolbar) But AFAIK it could not as WebExtensions are separated from each other.
But I also could not find out to which page it belongs.

So why does NoScript even show a "[…]" where the domain of the origin of this request would – presumably – be shown?`What could that be constantly making requests to EmojiOne with a, obviously, broken URL? (I mean {seoImage} is surely meant to be replaced by something…) And why is that even triggerig the XSS filter?

The current assumption is that all the [...] originating calls are from the new firefox "hub" start page loading previously visited pages. For icons or precaching.
Deactivating content on that hub page removes the unsolicited calls.

It would be strange if they contact EmojiOne… There is not even Emoji displayed.

rugk wrote:It would be strange if they contact EmojiOne… There is not even Emoji displayed.

Why would there need to be emoji displayed for FF thinking that you might revisit the page you got an addon from?

It has been shown that specifically the [...] calls often originate from exactly that internal source, which would explain why it has no URL as source given.
There were even users for who after a while (visiting enough other pages) the target of those calls changed to something newer.

Another common threat is that they generally call an image, which would also fit in with how the new hubpage is built.

Okay, reported upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1421095

rugk wrote:Okay, reported upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1421095

You do understand that it's not a bug, right?
It's an XSS call. Firefox does them, Noscript reports them.
It's not like an XSS call is a virus or anything. It just USED to be understood as a rather treacherous way of doing it, and now everybody and their uncle are doing it.

And again, the fact that it is to the emoji site is YOUR doing for having downloaded the addon, thus triggering the site to be something FF thinks you will revisite.
For other people it is other sites.

Just configure your FF new tab page properly.

edit: aaand it's already closed.

It is closed, because they say it is a bug in NoScript, which I can understand…

Hmm, yeah, but it is more surprising that this works at all. Because should not WebExtensions have no access to about:newtab as it is a Firefox-internal site? At least it looks as if they do not have, as all add-ons do not display any information about the site. Same with NoScript. It is labelled "NoScript" there and clicking on it takes you to the settings…

So why does the XSS detection would work there?

rugk wrote:It is closed, because they say it is a bug in NoScript, which I can understand…

Hmm, yeah, but it is more surprising that this works at all. Because should not WebExtensions have no access to about:newtab as it is a Firefox-internal site? At least it looks as if they do not have, as all add-ons do not display any information about the site. Same with NoScript. It is labelled "NoScript" there and clicking on it takes you to the settings…

So why does the XSS detection would work there?

I very much think it is entirely ok for no script to be able to block XSS calls that Mozilla in their god given freedom decided to push on us.
If something talks to the web without explicetly being asked to, I would like to be able to be notified about that and block it.
Why would Mizillas new tab page be different?

Again, I still don't understand why you are talking "addon" and not "webpage". It's prefetching a thumbnail WITHOUT ASKING YOU from a webpage that you have visited (in you case COINCIDENTALLY the webpage that you got an addon from, but for others just SOME webpage they visited, among them some news site, or a gamer site they visited).
If you have visited a questionable site, that may cause someone to abuse this functionality to trigger something you might not want, and this a warning is entirely warranted.

What is your argument that these CSS shenanigans should NOT be monitored by a tool that promises to do exactly that?

Where is the bug here? And they closed it because you phrased it entirely wrong. The correct bug would be "FF initiates XSS calls from new "newtab" functionality" and initiates these in the background even when not explicitly calling the newtab page.

And how to you call it "FF internal" when it explicitly calls out to webpages. That is the core issue. It isn't INTERNAL if it just calls out to wherever.

Basically if you have "snippets" or "highlight" activated on your newtab page (which is the DEFAULT BEHAVIOUR of FF no less), Mozilla might at an point initiate contact to webpages and load data via XSS.
How is that acceptable to the point of you insisting on calling monitoring and blocking them "a bug".

You completely miss the point. (that WebExtension should not be able to access browser-stuff or other add-ons is a technical point, not my opinion, e.g.) But I've found two ways I can express this issue to the Firefox devs, indeed, and one is why EmojiOne was loaded in the first place (because contrary to what you suggest it is not an image on a tile, these are mostly created locally or loaded from Pocket – if enabled – as you can see with the inspector).

rugk wrote:You completely miss the point. (that WebExtension should not be able to access browser-stuff or other add-ons is a technical point, not my opinion, e.g.) But I've found two ways I can express this issue to the Firefox devs, indeed, and one is why EmojiOne was loaded in the first place (because contrary to what you suggest it is not an image on a tile, these are mostly created locally or loaded from Pocket – if enabled – as you can see with the inspector).

The fact of the matter is that it is DIRECTLY connected to the "highlights" or "snippets" feature. And more importantly the pictures these load from the websites you have visited.
1.) Disabling those removes the popup
2.) they aren't just thumbs for the page, they are ACTIVE new content from those pages, which get fetched on loading the newtab page.

I don't fundamentally disagree with the "browser stuff and other addons", except for ONE case.
Namely the hub page, which basically is just a webpage fetching both locally cashed content (for the recently visited tiles), but more pertinent here, also calls recently visited websites and actively uses their scripts to deliver content.
Shielding those from an addon that is EXACTLY meant to prevent unwanted scripts from running under the argument that this is "browser stuff" rather than a webpage that warrants screening is not a technical point.

The XSS warning is NOT about the addon, and it is NOT interacting with your addon. It is with FF using their websites scripts to deliver you "highlight" content. That is an XSS and Noscript is right in seeing it that way.

It is from a security standpoint not understandable why you would advocate that unsupervised script execution by webpages you might have visited should be shielded from control.
I understand that it is entirely correct that you can't block about:newtab from running scripts. That argument stops at XSS. Because then it's not Mozilla JS that gets executed, but god knows what code.

Please access about:newtab, press F12, select network inspector. Click on reload there. You'll see where they are loaded from.

And as I cannot reproduce the initial issue right now anyway… so there is no need to discuss that further.

Also we are getting of-topic.

Does this answer your question?



Now you try.

The page another user had was nrc.nl which is a dutch news site.

https://forums.informaction.com/viewtop ... 794#p92275

Just visit it, and then open a new tab with the highlight feature enabled.

Ah thanks, that screenshot was very useful. And from my point of view, this is really a bug and *not* expected behaviour…

I can literally not understand how executing 3rd party scripts at untouchable browserlevel can be seen as "ok" to begin with.

How come all the other pages can do without it.
If anything the bug is FF allowing XSS there to begin with.

Each modern browser uses JavaScript everywhere. In the DevTools, in the settings page, etc. That's just how you develop things… And as long as these pages are still sandboxed (and not elevated inm contrast to usual pages) that's not really bad.
I mean nowadays we even have whole desktop applications out of JavaScript & co (Electron).