Hacker Newsnew | past | comments | ask | show | jobs | submit | bbondy's commentslogin

This is a new rewrite built into Chromium from scratch. No shared code with the original MetaMask fork.


Brave Wallet supports that use case. Only use your Ledger and connect it to Brave. That will delegate signing of transactions to the hardware wallet. The private key does not leave the hardware wallet.

It's all about being a Dapp browser. The use case is getting access to Dapps.


> there isn't a way to opt-out as far as I have found.

Navigate to: brave://settings/wallet

Set Default cyrptocurrency wallet to None, and set Show Brave Wallet icon on toolbar to off


Thank you for your help.

1) I'm probably dumb, but on iOS putting brave://settings/wallet into the address bar puts me into Brave search results. No leading or trailing spaces.

2) This setting will disable in-app marketing messages? I'm interested in disabling the "Brave Rewards" in app notifications.


> I'm interested in disabling the "Brave Rewards" in app notifications.

That's in settings, too... but aren't those opt-in? I could have sworn they were when I set up my profile for the first time. I'm going to re-install in a clean VM and see what their first-time user UX is like these days.


[flagged]


I am aware of about:kitchensink and related config from the mozilla codebase. I've used about:config on desktop many, many times.

Blaming the user isn't the best path to ADUs. Brave's settings have many options and I wasn't sure which one would disable in-app advertisements. I think it is "Brave Rewards".


Workflow isn’t the same on iOS, which is what GP was talking about.


You could consider using the admin policy for disabling the Tor functionality: https://github.com/brave/brave-browser/issues/454


Not my choice to make anymore: literally cannot run Brave anymore -- it's blocked at the binary executable level (via CarbonBlack).


run the usb pendrive version perhaps?


brave://settings/shields and you can change the Trackers & ads blocking setting to disabled.


thank you!


Some things are very wonky with the experiment:

Brave is intentionally slow on parsing and do as much work there because it doesn't parse from client code, it only use already parsed lists from memory.

"The memory usage of Brave could not be evaluated using the devtools and thus is not included in this section." That doesn't make sense, I wonder if it's maybe using a very old version based on the old muon code base? If you can get the memory from Chrome you can get it from Brave.

No information was given about versions that were tested.

Total parsed rules is too small.


> Some things are very wonky with the experiment:

Thank you for taking the time to read this study. We do not think we claimed anything that was false in this study (although the scope might not be as wide as some would expect or desire); this is not a reason to be dismissive. We have ourselves a lot of respect for the work done at Brave.

> Brave is intentionally slow on parsing and do as much work there because it doesn't parse from client code, it only use already parsed lists from memory.

That was indeed one of the things measured, but not the most important one. In fact we explicitly say that this is a one time operation and does not necessarily matter, especially if as you suggest you can perform this work backend-side and ship the serialized version to clients. What is more interesting is the time it takes for matching requests.

> "The memory usage of Brave could not be evaluated using the devtools and thus is not included in this section." That doesn't make sense, I wonder if it's maybe using a very old version based on the old muon code base? If you can get the memory from Chrome you can get it from Brave.

If we got this thing wrong we would be very happy to update the results with the correct measurements. The version we used was the latest version from `master` on the following repository: https://github.com/brave/ad-block

> No information was given about versions that were tested.

This is indeed unfortunate and we will be correcting this. The measurements were performed last week with the latest version of each projects but we should definitely indicate the exact version used.

> Total parsed rules is too small.

Too small for what exactly? Easylist is one of the most popular lists and it's pretty common to use it as a base-line for comparison. It is trivial to re-run the experiment with different lists given that all the code is open-source.


Hi Im Brave's CTO.

There's a balance between breaking the web and being as strict as possible. Saying we fully allow Facebook tracking isn't right [1], but we admittedly need more strict-mode like settings for privacy conscious users.

We do block Facebook at least as good as uBlock origin with EasyPrivacy. The referenced code is in a separate component which does the same as Disconnect blocking.

We're taking this seriously internally and we'll iterate on where we are to improve the situation. We're looking at if we can polyfill a local JS resource instead for example as one option if it doesn't make further requests.

[1]: https://github.com/brave/adblock-lists/blob/f25b698aff4666bb...

https://github.com/brave/adblock-lists/blob/f25b698aff4666bb...

https://github.com/brave/adblock-lists/blob/f25b698aff4666bb...


I'm a co-founder on Brave. Brave was actually built on Graphene, which is Gecko at the start, similar to Mozilla's browser.html project which was created by paulrouget, Gozala, and gordonbrander.

We switched to Chromium within the first few months for various reasons including performance and HTML JS based APIs being ready across platforms.

We do want to move to Servo once it's in a more complete state, it just has a lot of years until it is ready.


That makes total sense, thanks a lot!



There is no recommendation.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: