but you can't. See the last part of my comment: "they can inject arbitrary scripts into pages to make requests for them".

>either way, if it is not a solvable problem, there is a major problem in the design.

Not really. It's like complaining that debuggers can impersonate programs they attach themselves to.

disallow that behavior?

You could also just pull that code but it might change based on request origin...

That's irrelevant. If you can make changes to the page, you can exfiltrate data. The security model for addons isn't designed with restricting an addon's network activity in mind, see my other post: https://news.ycombinator.com/item?id=25623281

This ends up effect as magically determining where it’ll call, with a lot less work.

And this was Google Play verified with a million downloads.

    this addon connects to:
    * https://484044b296.execute-api.us-east-1.amazonaws.com

It doesn't have to be as overt making it look like a proxy (eg. a endpoint that makes arbitrary http requests on behalf of the caller). It can be as simple as changing the endpoint for the spying service from https://evil.example.com/api/ to https://484044b296.execute-api.us-east-1.amazonaws.com/evil/...

> Some more investigation would be required in some cases.

The point is that the "nutrition facts label" doesn't really do anything because it's trivial to bypass. If it becomes widespread I guarantee every malicious addon maker would adopt this tactic.

One might not like Google analytics, but at least you know exactly what you’re going to get when someone calls analytics.google.com.

Is it even possible or would the sandbox prevent such an extension from functioning?

I wish I could block per-app connections on Linux like Little Snitch appear to allow on Mac.

However, if you allow everything to 80/443, the extensions would still be able to connect to their servers. Maybe the browsers should add the ability to allow/deny connections per extension.

https://github.com/gustavo-iniguez-goya/opensnitch/issues/21

Great idea!

and insert the URL of the extension, for example https://addons.mozilla.org/en-US/firefox/addon/decentraleyes... .

Should they choose to, nothing stops the site you've linked from masking malicious tidbits in code you request.

Side note: the joke goes that Perl is a write only language as it is difficult to read it and understand it. Some twisted souls decided to create the obfuscated perl content: https://en.wikipedia.org/wiki/Obfuscated_Perl_Contest

For a list of some of the winners: https://www.foo.be/docs/tpj/issues/vol4_3/tpj0403-0017.html

But yes, even that shouldn't be encrypting strings.

e.g. original code:

function NewObject()

{

var mainApiUrl="https://google.com";

}

minified code:

function NewObject(){var mainApiUrl="https://google.com";}

obfuscated code:

var _0x8275=["\x68\x74\x74\x70\x73\x3A\x2F\x2F\x67\x6F\x6F\x67\x6C\x65\x2E\x63\x6F\x6D"];function ahyt56(){var _0xb40bx2=_0x8275[0]}

function a(){var b="https://google.com"}

That's why it's difficult to read minified code even if it's not obfuscated to the further extent that you sometimes see in attack payloads.

  function a(){var b="https://google.com";}

On the other side. The chrome store starts to behave badly and ban extensions they don't like for random reason after they implement that.

About mozilla, i don't know. will they eventually be like that, or they won't?

Now, some distros like Debian have enough political power to get Mozilla to allow them to put Firefox branding on their altered user-freedoms-respecting repo editions of FF release. But most don't. So the only way to use actual release FF is to go outside your repos and use the unbranded version. Possible, of course, but tedious.

And why is this? Unless the extension source is already public, I don't see any reason why anyone would not use obfuscation

I'm not saying all obfuscation is necessarily bad, just something to look out for if you're trying to sleuth around for malicious intent by the addon's author.

Typically if you want to hide the fact you are collecting the browsing secrets of the addon's user, you would use some form of obfuscation (in order to have the addon in good standing by Mozilla and to stop a simple sweep by people like myself who first look for things like http:/https: in the source).

Note: Obfuscation is NOT the same as minification, and I don't mean minification when using the word obfuscation!

That said, any extension using those tools without source code available and build verification should definitely be viewed with suspicion.