Loading Chrome Extensions in Brave
blog.brave.com
blog.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?
Still, I would recommend implementing some crappy UI only enabled on dev to do this.
We have been researching ways to more easily test extensions, and will continue to explore this in the future.
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.
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.
Github repo: https://github.com/mdamien/chrome-extensions-archive
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.
"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.
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.
This will be my last comment in this thread.
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.
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.
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.
https://play.google.com/store/apps/details?id=com.em.warp.br...
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.
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.
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.
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
I'm currently using Vivaldi and even set it as my current browser for now, because of the ease of adding extensions.
( ͡° ͜ʖ ͡°)
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.
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.
https://addons.opera.com/en/extensions/details/download-chro...
The fact that these browsers share similar bones is really nice from a functionality perspective.