You can whine all you want in my mentions about a couple tweets that I posted retracting my endorsement of Brave while saying I still considered it a better choice than Firefox. You did the opposite of changing my mind about not supporting it. I will actively fight you scumbags.
Conversation
Hmm - publicly calling out a project as nefarious absent any evidence / rationale, getting a strong response from project team, then dismissing it as 'whining' and doubling-down on 'scumbags' language all seems very bad faith tbh.
3
1
1
I gave evidence and rationale. This conversation has been incredibly strong evidence. Calling out someone for being completely dishonest, misrepresenting my arguments and doubling down on ridiculous spin is absolutely called for and I wasn't the one showing up acting that way.
1
1
Appreciated you elaborating on concerns, then asked for clarification of logical inconsistencies and don't see them resolved. Questions still have:
* weak or all attestation bad?
* 1 or all vendors bad for using attestation?
* what model works to provide ad-fraud and privacy?
2
Attestation is a useful feature. It can be used to build valuable security features. Strong attestation based on pairing / provisioning is very useful. I put enormous time into Auditor and AttestationServer to make it useful to users and organizations:
attestation.app/about
1
1
1
Attestation via verifying up to a trusted root is a weak form of it. It has some genuine use cases, but it's inherently a weak approach and only really serves as a mild barrier to an attacker. Auditor uses it to bootstrap trust but I explicitly document and show that it's weak.
1
1
I don't think it has much value for security, and I only use it because it's there. If I was implementing the feature from the bottom up in hardware, it's not how I would approach it. The root of trust is primarily for DRM use case for the feature. It's flawed for security uses.
1
1
I would be perfectly happy with an attestation implementation without the root of trust. I'd consider that as essentially nothing of value being lost. In my opinion, pairing is far more compelling and deserves to have thought put into improving the API to better support it.
1
1
I don't care about ad fraud. Advertising is inherently manipulative and abusive. It's the gaslighting industry. I don't see why I should want it to survive. The internet worked fine before it was totally plastered with advertising and commercialized and will work fine without it.
2
1
5
That's a totally reasonable, coherent philosophical position about modern-day capitalism and how it communicates with its 'consumers'.
But in that case why ever recommend Brave, and why take issue with ad-fraud implementation when you don't care about it?
2
I recommended the Android app specifically, and primarily because Chromium on Android doesn't support extensions and implementing privacy features in the core browser is more robust than an inherently broken API like webRequest, along with being able to do much more than that.
I came to realize over time that they weren't as focused on privacy as I had perceived. I think Apple is shipping the best work in this area. They've got a great content blocking implementation and some nice work on meaningful privacy improvements for the core browser (not all).
1
The mobile Brave didn't support the ads or attention token stuff when I recommended it, and my expectation was that it was a silly idea and would die off because there's too much wrong with it. I expected them to refocus on making a privacy-focused browser based on Chromium.
1
Show replies
Ah okay gotcha - that makes sense.
So considering the ad model is opt-in, wouldn't it be fine then to continue recommending it but stressing users should not opt-in, or is your fear where this leads over longer term?