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?
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.
If you implement tree style tabs as well as can handle javascript in multiple tabs without bringing the entire browser to its knees, I'll gladly switch from Firefox.
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.
Part of Brave's adblocking was replacing site ads with their own ads, and then a slice of the ad revenue back to the user. So you'd get a 15% cut of the revenue and only see Brave-provided or Brave-approved ads. You could then choose to reinvest that and give the money back to the sites that you visit.
Brave does not do any ad-replacement; this is part of a potential opt-in model [in the future]. Today, out of the box, Brave blocs ads, trackers, prevents fingerprinting, and more.
Brave Payments launched recently, which allows each user to fund their own Brave Wallet, and distribute micro-donations to sites they visit on a monthly basis.
brave should do ad replacement implement horizontal ad targeting based on sites you visit and then pay publishers and users. users don't want to pay for content (we're spoiled by free), they don't really care about ads as long as they are relevant (to a point), and publishers are stuck right now implementing "native ads" which is just sneaky clickbait crap. brave is onto something but paying with bitcoin will reduce the value of the potential from an everyone market to a much much much smaller one.
Blocking ads is one thing, lets just say for the sake of argument that users have a right to not execute stuff on their own computer.
But replacing ads on websites is quite another. I don't understand how this wouldn't be downright copyright infringement made for profit reasons. And if they share that revenue with users, then users can get sued as well.
I also think such a business model is incompatible with what it says on the box. On one hand, this browser is advertised as being more privacy friendly, on the other hand users would be willing to submit their browsing history to yet another third-party for ads targeting.
Mozilla was harshly criticized on HN for wanting to include ads in Firefox with an implementation that was never communicating with any Mozilla servers, all the targeting being done offline.
I surely hope HN isn't guilty of double standards.
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.
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.
> 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.
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.
It sounds like you're trying to make arguments on my behalf, and then tear them down. I'm not interested in participating in a conversation like that, especially since they're either directly opposite of the ones I'd make for myself, or just weird and orthogonal to the points I was making.
> 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.
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.
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.
> Brave on Android is [...] basically Chrome with ad blocking.
This is what I've needed for the past four years!
Ads on mobile have gotten ridiculously out of hand. Half of the websites I visit are downright unusable with their extreme bandwidth consumption, scroll hijacking, impossible-to-click/dismiss ad overlays, etc.
I'm downloading this immediately. I'm sold.
edit from Brave on Android: this is amazing in the way Firefox mobile never was. I'm so stoked right now! This is fantastic.
How have I not known about this before!? Sluggish Firefox performance with uBlock has been annoying me for ages and the horrible ads on Chrome are unbearable. Brave has just become my new browser on Android.
I also used Firefox+uBlock in the past but it was waaaay to slow. I'm now using Adguard (which blocks with a VPN lookalike but only locally) and Chrome. Adguard+Chrome are faster than Brave, I can use whitelisting and better Anti-Adblock support. I can also use the data saver functionality in Chrome. Brave stutters and especially the HTTPS-only slows down mobile browsing experience. But nevertheless I keep an eye on Brave... I hope it can improve.
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.
Because many people do not want to root (it's also a security risk). I btw. I also had bad experience with Adaway... it's sometimes too restrictive and sometimes no way to disable it quickly when a certain website does not work.
fwiw I've been using "bluhell firewall", and it captures the vast majority of ads with no perceptible cost. It has problems opening tracking links that I actually don't care about (i.e. it fails utterly), but that's work-around-able.
That and the open-tab-in-background "tab queue" keep me 100% preferring Firefox over Chrome. Plus it's Firefox - I'd much rather give them the activity than anyone else.
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).
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.
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). 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...).
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). 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.
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.
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.
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.
That’s how I ended up briefly moving to [Vivaldi](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.
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.
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".
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 ;)
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.
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?