
Loading Chrome Extensions in Brave - jonathansampson
https://blog.brave.com/loading-chrome-extensions-in-brave/
======
the_duke
Haha, so to use extensions I have to download the source code, manually
download the extensions with an npm package I have to install, and then use
actual code to register it.

It's nice that it supports extensions, but I probably would have skipped the
blog post before there's a more convenient method.

Also, the only distinguishing features mentioned seem to be a built in
Adblocker and Https redirect?

~~~
jonathansampson
Worth noting that this article is for developers wishing to assist the Brave
team in determining whether an extension can be supported straight-away. This
is not intended for your average user.

~~~
the_duke
Ok that makes more sense then.

Still, I would recommend implementing some crappy UI only enabled on dev to do
this.

~~~
jonathansampson
That's a fair request; I'll take it to the team for consideration. Thank you
for the feedback!

~~~
the_duke
That would most certainly make it easier to quickly test out various
extensions.

~~~
jonathansampson
It's a challenging issue; Extensions run in multiple contexts. As such, some
gaps in support may be realized in the browser's engine, the browser's chrome,
or in UX/UI artifacts.

We have been researching ways to more easily test extensions, and will
continue to explore this in the future.

------
dorianm
Full source of 130k+ extensions: [https://crx.dam.io/](https://crx.dam.io/)

Github repo: [https://github.com/mdamien/chrome-extensions-
archive](https://github.com/mdamien/chrome-extensions-archive)

~~~
carussell
Neat!

Fun fact: The main way to peruse the source of the various Mozilla projects[1]
was to use MXR[2], and we[3] tried to get Mozilla Corp to index the extensions
that are published through addons.mozilla.org, but they weren't willing to
provide any support. This was a big problem because if you recall, every time
a new Firefox release dropped, it would cause massive breakage because APIs
would be obsoleted and removed within the same release cycle. As a Mozilla
contributor, even if you wanted to bend over backwards and check which
extensions you would be breaking with any given patch to mozilla-central (and
maybe send fixes to the extension maintainers if you were really nice), there
was no way to do it short of setting up a crawler yourself (to spider AMO) and
either running an instance of some shiny code indexing tool yourself on
localhost, or more likely just dumping all extensions' source off a
subdirectory of $HOME and running a slow recursive grep every time you wanted
to check on some symbol use. It would be hard to overstate how many patches
never got written and upstreamed because of this.

As a Mozilla contributor, you had the choice of either throwing in and piling
on to the bonfire of wanton breakage, or quietly opting to take no action when
running into instances where you could improve and even stabilize the
underlying "platform". The former was actually an uneasy thing to think about,
because it was clear that TPTB didn't give a damn about one of the single
biggest driving forces behind Firefox user retention, which was the extension
ecosystem[4]. Opting for the latter was "safer" because although it kept the
codebase in a poorer state than it could have been in, it might stem the flow
just enough so that the number of users bleeding out wasn't so bad as to cause
Mozilla to lose its negotiating power. And when the future is still not
guaranteed, you can hold out hope that maybe people will come around and start
doing the right thing.

Eventually, an index of add-on sources did get built and grafted onto MXR.
Only problem is Mozilla allowed proprietary add-ons to be published on AMO,
and whoever set it up chose to put those in the index, too. So they threw it
behind an HTTP auth wall that you could only get through by logging in with
your LDAP password. Just another example of the uphill battle it was to be
working on Mozilla but not from behind an @mozilla.com email address.

1\. For example, Firefox, SpiderMonkey, the web properties, and less popular
client software like Thunderbird and SeaMonkey

2\. MXR was a heavily modified version of the LXR tool, which itself was meant
to make it less painful to browse and search the Linux kernel sources

3\. "We" here just means the set of people who pushed for this over the years,
not like a consolidated effort coming from a single team that I happened to be
part of or anything

4\. To some, this will probably read as run-of-the-mill lamentations of
someone's pet use case not being prioritized and coddled, but it's not so. I'm
not and never have been a heavy extension user, but a) it was stupid not to
recognize that extensions were highly valued by both the vocal minority and
silent majority that were responsible for the number of Firefox holdouts, and
b) making an end-user-hackable browser was, like, the natural consequence to
be working on if you were serious about all rhetoric the people from your camp
were spewing about making something that really was aiming to be a "user
agent" meant to "put end users in control" so they could "experience the web
on their own terms".

\----

Anyway, this got really long. That link to the repo of Chrome extensions is a
nice thing. I'm on record as not being too much of a fan of GitHub, but it's
neat how it enables something like this to exist, even if it still takes a lot
of manual work to keep things reasonably up to date. If it had been clearer
that git was going to win the DVCS battle and the timing were better so that
cheap symbol lookup (in the form of GitHub's code search) were available in
the timeframe when all this was taking place, then it would have been nice to
throw something like this together for extensions in the Mozilla add-on
ecosystem, back when it could have made a difference.

~~~
gcp
IMHO your rant does boil down to the fact that making the browser "end-user-
hackable" through extensions was an untenable situation. I mean, you're both
saying

"This was a big problem because if you recall, every time a new Firefox
release dropped, it would cause massive breakage because APIs would be
obsoleted and removed within the same release cycle."

and

"it was stupid not to recognize that extensions were highly valued by both the
vocal minority and silent majority that were responsible for the number of
Firefox holdouts, and b) making an end-user-hackable browser was, like, the
natural consequence to be working on if you were serious about all rhetoric
the people from your camp were spewing about making something that really was
aiming to be a "user agent" meant to "put end users in control" so they could
"experience the web on their own terms"."

I don't buy the argument that a searchable source index is what made or broke
this. For starters, the approach you describe obviously doesn't scale. It's
fixing a leaking roof with buckets. Resources _were_ in fact better spent
elsewhere, so yes, it's exactly "run-of-the-mill lamentations of someone's pet
use case not being prioritized and coddled".

The idea that Firefox's add-on ecosystem was an asset rather than a liability
did much to set the browser and the users' experience with it back for years,
and it'll continue to do so as users lash out when their unrealistic
expectations of XUL addons continuing to work are broken.

~~~
carussell
> making the browser "end-user-hackable" through extensions was an untenable
> situation

This is in response to a blog post where extension support is being _added_.
And those extensions exist in great numbers. Targeting the most popular
browser in the world. And there's no sign that they are being deprecated. So
how untenable are extensions? Is Chrome untenable?

> I don't buy the argument that a searchable source index is what made or
> broke this.

I'm very glad, then, that I didn't say that.

> it's exactly "run-of-the-mill lamentations of someone's pet use case not
> being prioritized and coddled"

I'm flummoxed at this comment. There's no way this is an instance of that, nor
would it even be possible for it to be, because it's not even my use case. I
think I made that clear enough in my original comment.

~~~
gcp
_So how untenable are extensions?_

An extension API that has a well-delineated API border and limits the internal
surface that is exposed is obviously tenable.

A full "end-user-hackable" browser where add-ons can access all browser
internals is not.

 _There 's no way this is an instance of that, nor would it even be possible
for it to be, because it's not even my use case. I think I made that clear
enough in my original comment._

Your use case was to try to limit the breakage caused by changing the exposed
internals. You explicitly said so. This use case entirely hinges on
maintaining a fundamentally broken design.

Firefox's XUL add-on system is a perfect example of sunk cost fallacy.

~~~
xg15
> _A full "end-user-hackable" browser where add-ons can access all browser
> internals is not [tenable]._

Why not? Please explain.

You seem to imply that Mozilla's continously-breaking-extensions problem is
proof that this is untenable, but I don't see any obvious connection between
the two.

~~~
gcp
_You seem to imply that Mozilla 's continously-breaking-extensions problem is
proof that this is untenable, but I don't see any obvious connection between
the two._

Because the breakage is inevitable as internals invariably change. That's why
Firefox extensions break: the internals change, and add-ons depend on them.
This causes a huge add-on churn each time the browser significantly changes,
leads to abandoned add-ons, user and ecosystem frustration. It causes a
pushback on the developers to make far-reaching changes (e10s being a clear
example). It adds overhead as others try to mitigate the compatibility impact
of changes (which was what the original poster was attempting and failing at
doing, as was Mozilla's AMO team). The unrestricted power of the add-ons also
leads to huge review queues, causing more ecosystem frustration.

Mozilla has given up on it. I would say the burden of proof is now on someone
else to say it can work, because there's no more examples left: everyone who
came after Firefox saw the problem and enforced a stable add-ons API that
limits the internals' exposure.

------
mdeeks
My favorite thing about Brave on Android is that it is basically Chrome with
ad blocking. Firefox with uBlock on Android becomes unbearably slow and chugs
after using it for a bit on my brand new Pixel. Opera crashed on me twice in
the span of two days. And I don't particularly trust any of the other third
party browsers out there.

I just want the speed and quality of Chrome but no obnoxious ads while I surf.
Brave gives me exactly that. The only thing missing from my total joy is some
sort of 1password integration. Hopefully extensions can give us that.

~~~
ecliptik
Try Warp Browser for Android too,

[https://play.google.com/store/apps/details?id=com.em.warp.br...](https://play.google.com/store/apps/details?id=com.em.warp.browser&hl=en)

It includes ad blocking, Do Not Track, and other privacy features. It's based
off Chromium and is just as fast and reliable as stock Chrome is on my Pixel.

~~~
therealmarv
this seems shady. Who is this eMbience Inc? I would be careful trusting
unknown browser companies.

------
bsclifton
Disclaimer: I am also a Brave Software employee :)

Jonathan Sampson, author of the article, has been using similar methods to
test popular extensions with Brave to ensure we have support for them (and if
not, to identify what's missing).

You can track the progress that he and team have made here:
[https://github.com/brave/browser-
laptop/projects/1](https://github.com/brave/browser-laptop/projects/1)

------
Outpox
I have been looking for a new browser to replace Chrome (2017 is the year when
I try to get some distance from all those Google services) and gave a change
to Brave. I tried to add my own extension by naively copying their folder
inside the Brave extension folder, but it failed.

I'm currently using Vivaldi and even set it as my current browser for now,
because of the ease of adding extensions.

------
sperm
Time to port the Ask Toolbar to Brave

( ͡° ͜ʖ ͡°)

~~~
jonathansampson
Run through the document; let me know how well it works :)

------
penpal223
Originally, I was opposed to the model used to build the Brave browser. A
payment and ad-replacement system seemed like something better suited for a
browser plug-in than a browser fork. It seems harder to convince users to
change browsers than to install a plug-in. Looking at the scope of changes and
features listed today, it makes more sense to me now why they chose to fork.

It does seem odd to me that they chose to fork Chromium instead of Firefox.
Google is obviously vested in keeping the existing ad revenue streams flowing,
so Brave getting traction could be seen as a threat to Google's revenue.
Google also seems fairly well placed with Chrome to be able to apply pressure
on Brave. Is that a realistic concern for Brave? Could Google make life
difficult for Brave? Firefox seems like a safer place to start, fewer
conflicted interests. Maybe Brave would be able to pivot before Google could
apply pressure.

The Brave privacy page mentions their "Ad Replacement" feature
([https://brave.com/about_ad_replacement.html](https://brave.com/about_ad_replacement.html)).
I've seen people complain about it before on HN. As far as I can tell, the
replaced advertisement doesn't generate any revenue for the viewed website.
It's a clever way to make more money for Brave, but it doesn't really feel
like fair play. I wonder if that would cause publishers to view the Brave
browser poorly.

Thinking about what would happen if Brave gained serious traction... Brave
works well for publishers if more people who currently use ad blockers switch
to Brave instead. Brave works poorly for publishers if people who currently
don't use ad blockers switch to Brave. In theory users could add their own
money to Brave which could cause publishers to realize similar or larger
revenue, although I wouldn't expect enough users to do that for it to matter.
So overall, it seems like Brave would shrink the revenue available to
publishers. Publishers may come to this conclusion and want to discourage the
use of Brave. With the ad-blocker detection tricks gaining popularity, I
wonder if publishers would just block Brave users. Maybe that's part of why
Brave no longer uses a unique user agent string
([https://github.com/brave/browser-
laptop/blob/master/CHANGELO...](https://github.com/brave/browser-
laptop/blob/master/CHANGELOG.md)).

I am also a little concerned about Brave's ability to respond to security
issues. I trust Google and Mozilla with Browser security based on how they
have handled issues. Since Brave is a fork of Chromium I expect a lag time
when security patches are released. The lag time is mentioned here
([https://github.com/brave/browser-
laptop/issues/840](https://github.com/brave/browser-laptop/issues/840)). I
don't have good a insight into how Brave security tests the code they
add/modify, so I can't comment there.

FWIW I don't plan to use Brave, but I am very interested to see how it
evolves. It's a fantastic idea.

~~~
gcp
_It does seem odd to me that they chose to fork Chromium instead of Firefox_

WebKit/Blink/Chromium have a large webcompat advantage due to superior
marketshare, and Firefox's embedding story is weak. WebKit is big enough that
it's hard for Google to bully out users even if they can make piggy-backing on
Blink more annoying. It depends on how hard you depend on Chromium vs how hard
you depend on the underlying rendering engine.

IIRC at least their first Android browser did fork Firefox, simply because it
had a much superior embedding/customization story than the desktop version.

------
shortformblog
Opera has a similar plugin:

[https://addons.opera.com/en/extensions/details/download-
chro...](https://addons.opera.com/en/extensions/details/download-chrome-
extension-9/)

The fact that these browsers share similar bones is really nice from a
functionality perspective.

------
redthrow
One thing that's lacking in Brave that I miss from Opera: the arrow button
that appears on the right side when you scroll that takes to the top/bottom of
the page. This is so handy and I hope Brave adds the feature.

------
abhv
Has anyone tested the Dashlane extension in this way for Brave? If so, I would
consider using it as my desktop browser. I currently use Brave on mobile, and
it is great.

~~~
charrondev
That’s how I ended up briefly moving to
[Vivaldi]([https://vivaldi.com](https://vivaldi.com)). It’s basically chromium
with new browser chrome. It was fun playing with the new UI, but it seemed to
suck down memory like no ones business. It is compatible with all the chrome
extensions though.

~~~
pixelcloud
It is surprisingly slow.

~~~
jonathansampson
Brave is surprisingly slow? If so, I'd love to have more information so I can
file issues, and we can work to improve. Thanks!

~~~
jdormit
I think the parent was talking Vivaldi, not Brave.

------
duiker101
the only struggle I have with many of this really nice browsers, is that many
don't offer a way for plugins to change the new tab page. I do not want your
speed dial. I want mine. Chrome seems and Firefox to be the only ones that do
it.

------
hrayr
Completely off topic: What are the chances that I would type "brave" to search
on this page precicely at the moment the cartoon playing for my children on
the TV will say "brave".

~~~
jonathansampson
It's a sign; download Brave today and give it a week

------
Globz
Why Brave does not enable DNT by default?

~~~
jonathansampson
With it being off for so many others (including Edge), it would be a means by
which Brave users could be fingerprinted. Not to mention, it isn't really
effective. Brave prevents tracking not by polite request, but by forcefully
ripping it out of the user's session ;)

------
Rickasaurus
Is this related to the Brave Sentry spyware?

~~~
jonathansampson
This is related to the Brave Browser; a JavaScript-based browsing environment
that blocks ads, trackers, and more out-of-the-box. Check it out online at
[https://brave.com](https://brave.com).

------
alexnewman
Been working with brave for a while. God they are a bunch of badd$ss.... Super
impressed with the vision and what we have built.

