Hacker News new | ask | show | jobs
by saurik 1050 days ago
It's nice that they are changing their marketing on this a bit now that there is a wave to ride and the evils of DRM are coming for them; but, let's not forgot that, at the end of the day, Brave is just another company that makes money on ads :(, and (thereby) has most of the same anti-user incentives.

So, sure... they clearly don't want to be prevented from blocking other peoples' ads (a big part of their pitch); but, blocking their ads while still getting paid--which is, of course, extremely easy to pull off on an unrestricted computer--is an existential threat to their only actual revenue stream which they want to protect against.

The ramification: Brave's product managers--and even Brendan Eich himself (whom all of the later quotes I have in this comment were taken from, directly or indirectly)--have often talked about using the very same remote attestation technology to protect their SDK and even their browser for the same reasons as Google.

https://www.reddit.com/r/BATProject/comments/bw6sek/

https://www.reddit.com/r/BATProject/comments/b7rwbx/

> 1/ native C++/Rust code, no JS tags on page that have zero integrity. That means ability to use SGX/TrustZone to check integrity and develop private user score from all sensor inputs in the enclave; ...

> We already have to deal w/ fraud. That is inherent in any system with users and revenue shares or grants. We do it better via C++ and (under way) SGX or TrustZone integrity checking + OS sensor APIs, vs today’s antifraud scripts that are routinely fooled.

> What Brave offers that's far better than today's joke of an antifraud system for ads is as follows: 1/ integrity-checked open source native code, which cannot be fooled by other JS on page; ... (1) requires SGX or ARM equivalent, widespread on mobile.

https://www.reddit.com/r/BATProject/comments/

https://www.reddit.com/r/BATProject/comments/97trex/comment/...

> Part of the roadmap (details in update) is a BAT SDK. Obviously it would be open source, but more: we would require Secure Remote Attestation (Intel SGX broken but ARM TrustZone as used by Trustonic may be ok) to prove integrity of the SDK code in app.

1 comments

Blocking Brave's ads is literally three clicks. I don't care if I don't get paid if I block ads. What I don't want is to lose the ability to block ads or to allow websites to block me for using an unapproved system. Google seems to be working for both of those things while I don't see any chance Brave ever allows either.
You don't care... but Brave cares. The point here is that Brave has been talking up the same user-hostile tech for the same user-hostile reason: to prevent "ad fraud", as they are an ad company, like it or not.

...and, frankly, Brave isn't going to have any choice in implementing Google's plot: the web simply isn't going to work in Brave anymore if they don't, as web pages will just start refusing to give Brave any content.

The real issues are the very existence of remote attestation technology and advertisements as a business model / corporate incentive structure; imagine living in a world where we made both of these illegal.

"Men can always be blind to a thing so long as it is big enough." - GKC

We want our SDK (if we manage to build it) by which revenue share is distributed to be tamperproof and used by humans. You don't like this, turn off the BAT support in the SDK-using app, or use a different app.

Contrast this with Google WEI, which proposes that web pages (esp. the big ones, including Google's) can do this to all browser users, who get zero revshare, just battery draining ad-tech requests and malvertising risk.

See the difference? I have said openly that I'm a fan of Secure Remote Attestation but it has to be opt-in and user-first. WEI as a tool for Chrome supremacy on the browser side and Google on the ad-tech side is pretty much the opposite.