
Browser extensions are kernel modules for browsers - luu
http://composition.al/blog/2015/02/27/browser-extensions-are-kernel-modules-for-browsers/index.html
======
Animats
Firefox has "add-ons", which are just Javascript which can do cross-platform
network connections and look at pages, and "plugins", which are native
programs. "Plugins" are mostly video players, and you can (and should) set
most of them to "Ask before running".

Add-ons come in two flavors, "old" and "new" (Jetpack). This feature is only
available to "old" add-ons. The direction with Firefox has been to narrow what
add-ons can do.

~~~
mconley
(Full disclosure - I'm an engineer that's working on multi-process Firefox).

> Add-ons come in two flavors, "old" and "new" (Jetpack). This feature is only
> available to "old" add-ons. The direction with Firefox has been to narrow
> what add-ons can do.

This is false.

SDK (Jetpack) add-ons can do everything that "old" add-ons can do. The SDK
just offers nicer APIs to allow add-on authors to do common things, and adds a
layer to help protect add-on authors against changes in Firefox's code-base
(the SDK has very strict deprecation policies, for example). Another advantage
of SDK add-ons is that, if all goes well, very few (if any) SDK-based add-ons
will need to be changed in order to work in multi-process Firefox. The SDK API
layer will change to accommodate multi-process, and SDK-based add-ons should
"just work".

js-ctypes, which this blog post talks about, is very much accessible from SDK-
based add-ons[1]. SDK-based add-ons can also get direct access to the same
old-style XPCOM components that power "old" add-ons[2].

Nothing about the SDK makes those add-ons weaker - if anything, it makes them
more resilient to change.

[1]: Here's a simple SDK add-on I wrote to quickly crash the selected tab in
multi-process Firefox: [https://github.com/mikeconley/tab-
crasher](https://github.com/mikeconley/tab-crasher) It uses js-ctypes to
dereference a null pointer and segfault the content process.

[2]: [https://developer.mozilla.org/en-US/Add-ons/SDK/Low-
Level_AP...](https://developer.mozilla.org/en-US/Add-ons/SDK/Low-
Level_APIs/platform_xpcom) \- but note the "unstable" header, since the
interfaces for these components are not frozen, which makes add-ons that use
them more prone to incompatibility across Firefox versions.

~~~
Animats
I didn't think that "Cu.import("resource://gre/modules/ctypes.jsm")" was
allowed in a Firefox add-on.

This is bad. Add-ons should not be allowed that much power. Especially since
Wips has been buying up add-ons and putting in adware and spyware.[1][2][3] It
looks like if you have the right connections, you can get malware approved
into Firefox.

[1] [https://addons.mozilla.org/en-
US/firefox/addon/blocksite/](https://addons.mozilla.org/en-
US/firefox/addon/blocksite/) [2]
[http://forums.mozillazine.org/viewtopic.php?f=38&t=2737553](http://forums.mozillazine.org/viewtopic.php?f=38&t=2737553)
[3] [http://www.howtogeek.com/180175/warning-your-browser-
extensi...](http://www.howtogeek.com/180175/warning-your-browser-extensions-
are-spying-on-you/)

~~~
mconley
That blocksite looks pretty annoying, but according to our Add-on Dev
Relations Lead (jorgev), since the tracking in blocksite is "opt in", it
doesn't actually violate any of the AMO policies.

Note that I haven't actually installed the add-on or looked at the source[1],
but just echoing what I'm reading in this bug:
[https://bugzilla.mozilla.org/show_bug.cgi?id=903799](https://bugzilla.mozilla.org/show_bug.cgi?id=903799)

"Add-ons should not be allowed that much power" \- this is tricky. We want
add-ons to be powerful enough that users can customize Firefox to their liking
down to the tiniest detail. And yet, we want to make sure that the add-ons are
not doing completely evil things to your machine.

Our solution to that problem is code review and static analysis of add-ons
that are submitted to AMO. For add-ons that you install outside of AMO...
well, you're on your own there.

It's tricky. We do very much want to make the browser safer for our users, and
eliminating evil add-ons is high on our list of priorities, but there's a lot
of stop energy put against our solutions[2].

I'm not in charge of add-ons, but I the predicament is clear. Add-on authors
want the power to make the browser do amazing things. Users want add-ons to do
amazing things. Bad actors want add-ons to do evil things. We want to protect
the user, but we also want to respect the user's right to do or install
whatever they'd like on their machines.

It's a fine balance.

[1]: Which is something our AMO editors do - they review the source of all
add-ons that go up to AMO.

[2]: [https://blog.mozilla.org/addons/2015/02/10/extension-
signing...](https://blog.mozilla.org/addons/2015/02/10/extension-signing-
safer-experience/) is one solution we're going after. Check out the comments
for some of the fors and againsts.

~~~
Animats
_" According to our Add-on Dev Relations Lead (jorgev), since the tracking in
blocksite is "opt in", it doesn't actually violate any of the AMO policies."_

I know, but it says something about the Mozilla Foundation that they let that
through.

~~~
the8472
It says that they value their user's freedom? Including the freedom to apply
footguns to themselves if they are clearly told that they are dealing with a
footgun?

Also note that spying on the user can be done without system-level access.
Since addons generally are allowed to do arbitrary XHRs anyway, so they can
just record in-browser data and send it via XHR. No access to the filesystem
needed. So this issue is somewhat orthogonal to access to the rest of the
system, besides the aspect that a malicious addon can do more damage that way.
It can still be malicious when restricted to just the browser.

------
seanwilson
I have both Chrome and Chrome Canary (beta version of Chrome) installed. On
Chrome I install only a few extensions I trust (e.g. LastPass, Chromecast) and
use that for personal browsing. Canary is overloaded with lots of useful
developer extensions that tend to have the scary "read and change all your
data on the websites you visit" permission and use that for development only
so I don't need to trust those extensions.

------
derefr
I don't think they're _meant_ to be. If you can do something malicious with
this currently, it's probably a bug or design flaw, and would likely be
changed in later releases after it was pointed out.

This is the difference between NPAPI and PPAPI in Chrome, for example: while
both are methods for writing native code and having it execute in the browser,
NPAPI _is_ like kernel extensions (you get whatever privileges the browser
itself gets), while PPAPI puts you in the same sandbox browser extensions
execute in; a sandbox which is _supposed_ to have a level of isolation only
slightly less than the one webpages themselves get. It can call a few more
APIs, but it should still be in "ring 3", to follow the metaphor.

~~~
the8472
You're basically arguing in favor of a walled garden that is safe but can only
does what the API designers deem an acceptable use.

For some users that may be sufficient so they can sleep sound at night, not
worrying about potential malware.

But powerusers often have eccentric use-cases that can only be tackled in ways
that API designers didn't foresee and thus require unrestricted access to,
well, everything. It's not malicious by default. It's dual-use.

If you want to be in the former group, fine. But you shouldn't argue that the
latter group should be denied access to their tools.

------
notfoss
off-topic: It's been a while since I visited an octopress based site! I
thought it had died or something.

