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.
Conversation
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.
2
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
I recommended it in spite of that. I never supported that part of the project. Recently, I looked BAT, Brave Ads, etc. more deeply and my impression is that it's sketchy as hell and quite possibly totally illegal to launch it and manage it the way they have. It deserves scrutiny.
1
That stuff was never in the Android app and the Android app is what I closely looked into and then recommended in the past. The reason I looked into the project more deeply recent was because I found it sketchy as hell to have a feature that requires DRM to be viable.
1
The response I got on those 2 issues from that developer was off-putting so I posted about it on Twitter and ended up getting into a mild debate (not a fight or flame war) about whether it's difficult to avoid a hard requirement on Play Services, especially when Chromium does.
1
Eventually, after thinking about it for quite a while, I posted the initial tweets here and I intended to simply remove the mention of Brave as an alternative from my documentation. I'm going to need to do much more than that now and I feel bad about ever recommending it...
As an onlooker it still appears to me that your primary complaint is around Brave using an Android-provided attestation API for part of their optional ad rev-share feature, and this weak foundation is used to mark them as a terrible / dishonest etc org.
Doesn't seem good faith.
2
It's not an Android API. The relevant Android API is key attestation. They use SafetyNet attestation, which is a Google Play Services API. Google Play Services isn't part of the official definition of Android. CTS / CDD don't include it. My issue with it is not it being weak.
1
Show replies