6 ms·

Maybe Mozilla could list on the Addon's page a list of domains/IP addresses where data is being sent. A Bit like a table of Nutritional Facts for food, but for

Maybe Mozilla could list on the Addon's page a list of domains/IP addresses where data is being sent. A Bit like a table of Nutritional Facts for food, but for extensions.

blindm 6y ago
> A Bit like a table of Nutritional Facts for food, but for extensions. Great idea!
gruez 6y ago
So bad guys will route all traffic through a proxy instead? eg. this addon connects to: * https://484044b296.execute-api.us-east-1.amazonaws.com
- Triv888 6y ago
  I always considered proxies, url shorteners, etc to be suspicious in the first place. Some more investigation would be required in some cases.
  - gruez 6y ago
    >I always considered proxies, url shorteners, etc to be suspicious in the first place 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/ https://evil.example.com/api/ to https://484044b296.execute-api.us-east-1.amazonaws.com/evil/api/ 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.
    - Triv888 6y ago
      Of course it would not be the only element in the table. But either way, it would at least tell you that an extension is leaking data when it isn't supposed to leak data (for extensions that should not require an Internet connection).
    - ashtonkem 6y ago
      I personally would find such an inscrutable name suspicious.
      - gruez 6y ago
        Why? Would connecting to "api.example.com" be less suspicious? The same issue would still be present (namely, smuggling requests to "shady" domains using a mundane domain), and the only difference would be that it demonstrates the author paid $10/yr for the domain.
        ashtonkem 6y ago
        I should be able to clearly determine the intention of any domain that an extension is going to call. Anything that tries to obsfucate the actual underlying purpose is a red flag. One might not like Google analytics, but at least you know exactly what you’re going to get when someone calls analytics.google.com.
        deleted 6y ago
        [deleted]
542458 6y ago
Wouldn’t that be impossible to do as you’d have to somehow execute every code path in the plugin? The domains don’t have to exist as strings - there are lots of ways to obfuscate network requests.
- gruez 6y ago
  Depending on how you approach it you either end up having to solve the halting problem (spoiler: it's impossible), or restricting what domains an addon can connect to (also impossible given the way addons work. they can inject arbitrary scripts into pages to make requests for them).
  - Triv888 6y ago
    But you have all the code and you know which functions/methods/etc that can do requests so it should be trivial... either way, if it is not a solvable problem, there is a major problem in the design.
    - gruez 6y ago
      >But you have all the code and you know which functions/methods/etc that can do requests so it should be trivial 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.
      - Triv888 6y ago
        > they can inject arbitrary scripts into pages to make requests for them disallow that behavior? You could also just pull that code but it might change based on request origin...
        fennecfoxen 6y ago
        Lots of the best extensions are basically "change this webpage when it loads to make it work better." You can't "disallow this behavior" without crippling them.
Abishek_Muthian 6y ago
Perhaps even a need gap for 'little snitch for browser extensions' as a browser extension(Considering OS LS or similar usually gets whitelisted for 80/433 with browsers). Is it even possible or would the sandbox prevent such an extension from functioning?
- Triv888 6y ago
  Yes, there is probably many extensions that make outside connections that don't add benefit to the user by doing so. I wish I could block per-app connections on Linux like Little Snitch appear to allow on Mac.
  - dylan604 6y ago
    Isn't Little Snitch essentially an interactive firewall? Rather than silently denying/allowing traffic, it needs the user's decision until a connection is white/black listed? Why would this not be allowed on Linux? (other than the app doesn't exist, yet)
    - gus_ 6y ago
      https://github.com/evilsocket/opensnitch https://github.com/evilsocket/opensnitch 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 https://github.com/gustavo-iniguez-goya/opensnitch/issues/21
  - the8472 6y ago
    This is entirely possible. Either by isolating the application into a network namespace (e.g. via firejail or systemd units), with selinux labels, running the process under a custom gid and various other mechanisms.
    - Triv888 6y ago
      Anything is possible, but is it relatively easy to block all apps and keep a whitelist of allowed apps?

Maybe Mozilla could list on the Addon's page a list of domains/IP addresses where data is being sent. A Bit like a table of Nutritional Facts for food, but for extensions.

blindm 6y ago

> A Bit like a table of Nutritional Facts for food, but for extensions. Great idea!

gruez 6y ago

So bad guys will route all traffic through a proxy instead? eg. this addon connects to: * https://484044b296.execute-api.us-east-1.amazonaws.com

Triv888 6y ago
I always considered proxies, url shorteners, etc to be suspicious in the first place. Some more investigation would be required in some cases.
- gruez 6y ago
  >I always considered proxies, url shorteners, etc to be suspicious in the first place 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/ https://evil.example.com/api/ to https://484044b296.execute-api.us-east-1.amazonaws.com/evil/api/ 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.
  - Triv888 6y ago
    Of course it would not be the only element in the table. But either way, it would at least tell you that an extension is leaking data when it isn't supposed to leak data (for extensions that should not require an Internet connection).
  - ashtonkem 6y ago
    I personally would find such an inscrutable name suspicious.
    - gruez 6y ago
      Why? Would connecting to "api.example.com" be less suspicious? The same issue would still be present (namely, smuggling requests to "shady" domains using a mundane domain), and the only difference would be that it demonstrates the author paid $10/yr for the domain.
      - ashtonkem 6y ago
        I should be able to clearly determine the intention of any domain that an extension is going to call. Anything that tries to obsfucate the actual underlying purpose is a red flag. One might not like Google analytics, but at least you know exactly what you’re going to get when someone calls analytics.google.com.
        deleted 6y ago
        [deleted]

542458 6y ago

Wouldn’t that be impossible to do as you’d have to somehow execute every code path in the plugin? The domains don’t have to exist as strings - there are lots of ways to obfuscate network requests.

gruez 6y ago
Depending on how you approach it you either end up having to solve the halting problem (spoiler: it's impossible), or restricting what domains an addon can connect to (also impossible given the way addons work. they can inject arbitrary scripts into pages to make requests for them).
- Triv888 6y ago
  But you have all the code and you know which functions/methods/etc that can do requests so it should be trivial... either way, if it is not a solvable problem, there is a major problem in the design.
  - gruez 6y ago
    >But you have all the code and you know which functions/methods/etc that can do requests so it should be trivial 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.
    - Triv888 6y ago
      > they can inject arbitrary scripts into pages to make requests for them disallow that behavior? You could also just pull that code but it might change based on request origin...
      - fennecfoxen 6y ago
        Lots of the best extensions are basically "change this webpage when it loads to make it work better." You can't "disallow this behavior" without crippling them.

Abishek_Muthian 6y ago

Perhaps even a need gap for 'little snitch for browser extensions' as a browser extension(Considering OS LS or similar usually gets whitelisted for 80/433 with browsers). Is it even possible or would the sandbox prevent such an extension from functioning?

Triv888 6y ago
Yes, there is probably many extensions that make outside connections that don't add benefit to the user by doing so. I wish I could block per-app connections on Linux like Little Snitch appear to allow on Mac.
- dylan604 6y ago
  Isn't Little Snitch essentially an interactive firewall? Rather than silently denying/allowing traffic, it needs the user's decision until a connection is white/black listed? Why would this not be allowed on Linux? (other than the app doesn't exist, yet)
  - gus_ 6y ago
    https://github.com/evilsocket/opensnitch https://github.com/evilsocket/opensnitch 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 https://github.com/gustavo-iniguez-goya/opensnitch/issues/21
- the8472 6y ago
  This is entirely possible. Either by isolating the application into a network namespace (e.g. via firejail or systemd units), with selinux labels, running the process under a custom gid and various other mechanisms.
  - Triv888 6y ago
    Anything is possible, but is it relatively easy to block all apps and keep a whitelist of allowed apps?