Live data from Hacker News

Funding Choices – Google’s new tool for GDPR compliance and content monetization

fundingchoices.google.com

151–160 of 173 posts

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#151
post #142

Earlier quoted context omitted.

> The system is so inefficient that it finances almost the complete operation of Alphabet/Google. Since Youtube is wildly unprofitable, Alphabet/Google has to be funneling in money generated from other sources. Thus, Youtube is funded by ads, just mostly not from the ads on Youtube.

It was mentioned in a private email that the only reason YouTube exists is that Google's servers happens to have a lot of free disk space in the days before SSDs.

Is the limiting factor for youtube really disk space? I would imagine it is bandwidth.

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#152
post #142

Earlier quoted context omitted.

It was mentioned in a private email that the only reason YouTube exists is that Google's servers happens to have a lot of free disk space in the days before SSDs.

Is the limiting factor for youtube really disk space? I would imagine it is bandwidth.

[deleted]

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#153

Earlier quoted context omitted.

Brave, with the Basic Attention Token (BAT), is building exactly the client-side anonymous contribution + ad-matching system you describe. We will take BAT to other apps after proving the model in Brave. BAT in Brave is opt-in -- each user consents before anything local happens with data or zero-knowledge/blind-token attestations -- and users can get _gratis_ BAT grants right now using the stable desktop browser (thi…

Given that the individual take from this would be miniscule, what’s the advantage over an ad blocker? This sounds like a lot of faux-currency nonsense for little reward (client side at least) to fix a problem that already has a working solution. Plus, the existing solution blocks all ads, and tracking scripts, which is a huge win.

The individual take has yet to be demonstrated, but do some math. $80B gross USD (at least; the IAB said $88B) spent on digital in US last year, say across 250M people (with Dr. Augustine Fou of NYU estimating fraud took $16.2B, lots of bots too). That is $320 gross ARPU if spread evenly -- which it is not. (Note we are worldwide and build for Europe and Asia too, not just at the US.)

Many of Brave's users at this early stage are "lead users" (Eric Von Hippel, MIT) and represent off-the-grid prospects because they block assiduously, either in Brave alone or with Brave + uBO or another solid blocker. Lead users are worth much more due to their high usage of search, ecommerce, and paid services. I would not be surprised if our users can make $70/year as we bring the system up in 2019 -- when ad deals will be harder to come by and we'll subsidize revenue from BAT's User Growth Pool -- and climb by 2020 to above .7 * 320 or $224 net user revenue per year.

Let's find out! We aim to find the fair price for human attention after blocking all the fraud, arbitrage, and abuse in the current system, using the BAT ecosystem.

Note that by default, user revenue share flows back monthly and anonymously to each user's top/pinned sites and creators on YouTube, Twitch (and more UGC platforms to come). We expect most users to avoid the bank-like AML/KYC/anti-sanction/anti-fraud checks required to take out their revenue, but legit users are welcome to cash out (our partner Uphold, and more to come, can exchange BAT many fiats and cryptocurrencies/tokens).

If we are right, then most Brave users, with their individual data sets and Brave instances/agents, will in effect replace the corrupt, crowded intermediary space using and abusing remote scripts to target and confirm ads today. After we have the model performing, it's on to other browsers, games, podcast apps, and so on.

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#154
post #112

Earlier quoted context omitted.

Star Wars of all things provides a interesting vision here. Did you ever notice that for the most part the machines/robots are not networked? That AI seems to exist but is intentionally kept dumb (C3PO). I think this is a interesting model. To as society come to the conclusion that more connection of devices, smarter AI is not the right solution. That what works best is the right amount of connection and AI

See also: Butlerian Jihad.

Oh interesting

https://en.wikipedia.org/wiki/Butlerian_Jihad

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#155

Earlier quoted context omitted.

Given that the individual take from this would be miniscule, what’s the advantage over an ad blocker? This sounds like a lot of faux-currency nonsense for little reward (client side at least) to fix a problem that already has a working solution. Plus, the existing solution blocks all ads, and tracking scripts, which is a huge win.

The individual take has yet to be demonstrated, but do some math. $80B gross USD (at least; the IAB said $88B) spent on digital in US last year, say across 250M people (with Dr. Augustine Fou of NYU estimating fraud took $16.2B, lots of bots too). That is $320 gross ARPU if spread evenly -- which it is not. (Note we are worldwide and build for Europe and Asia too, not just at the US.) Many of Brave's users at this ea…

To support your numbers somewhat: iirc at one point about 5 years ago Bing was giving out ~$120 a year in Amazon gift cards if you were a heavy searcher on Bing

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#156
post #141

Earlier quoted context omitted.

Brave, with the Basic Attention Token (BAT), is building exactly the client-side anonymous contribution + ad-matching system you describe. We will take BAT to other apps after proving the model in Brave. BAT in Brave is opt-in -- each user consents before anything local happens with data or zero-knowledge/blind-token attestations -- and users can get _gratis_ BAT grants right now using the stable desktop browser (thi…

How will you prevent the user from "opting in" but then not displaying the tabs? E.g. an extension could render white boxes in another (mostly transparent) window above the browser, thus acting like an ad-blocker.

Brave's agent is C++ built into the browser, it prevails over extensions (which we will also guard against at the point of installation).

It is a mistake to think of the BAT ecosystem fraud threat (which exists, for sure) as the same as the threat with remote scripts for ad view or click attribution and confirmation as practiced by ad-tech today. Third party scripts run without any integrity guarantees, so get fooled by fraudbots and cheated by other scripts (see "cookie stacking").

The "plane of adequation" defining truth as correspondence between an ad and its observed effect is browser native code, not Nth party scripts loaded into a DOM stew on page, or extensions and their JS scripts, which have privileges above page scripts but below browser native code.

Therefore the fraud threat to the BAT platform is a botted Brave instance including the BAT SDK. This is why we are planning to use secure remote attestation enclave/zone tech to ensure SDK integrity, and sensor M/L to check all the sensors for proof of humanity.

So for fraudbot users to get money out requires a costly simulation (see AML/KYC/etc. point I made in another reply today). Just hiding ad tabs (without faking identity for KYC/etc.) to waste ad spend would require faking the payable ad actions attested by the SDK, including human-like event streams.

Fraud risk never goes to zero with humans in the loop, but with BAT's native agent code, we keep the cost of fraud way above the low cost of fooling today's ad-tech scripts on page.

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#157

Earlier quoted context omitted.

Brave, with the Basic Attention Token (BAT), is building exactly the client-side anonymous contribution + ad-matching system you describe. We will take BAT to other apps after proving the model in Brave. BAT in Brave is opt-in -- each user consents before anything local happens with data or zero-knowledge/blind-token attestations -- and users can get _gratis_ BAT grants right now using the stable desktop browser (thi…

Thank you the details. Do my ip-address, sites-i-visited, date/time of visit, geo-location ever gets stored in on a server outside (eg outside my phone or my computer I am browsing on)?

None of those get stored or even sent, except of course for IP address.

IP address is not yet masked for update pings (same as for all self-updating browsers, required for security patching) and for similar pings to check for updated ad/tracker blocklists. If you do not opt into any BAT ecosystem features (contributions or ads, which enables contributions), then your IP address is not otherwise used, but it does show up in our logs. See https://brave.com/privacy/ under "Technical Infrastructure".

(We'd like to do the update ping via Tor since we have Tor tabs already, but this is in the future.)

If you opt into BAT features and take free BAT grants from us, then IP address and a wallet identifier are used for antifraud purposes, but not otherwise. This is covered in the privacy policy at https://brave.com/privacy/ under "Payments".

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#158
post #14

Earlier quoted context omitted.

> I'm still surprised no one has yet figured out a way to store sensitive data about personal interests and preferences on the client-side and let the client itself pull appropriate ads for the user to see. When I was at Middleware2017 I saw a poster/demo about this, MoCA+: https://koreauniv.pure.elsevier.com/en/publications/demo-moc... I guess the problem is the same as with privacy techniques in general. If you ask…

I think another issue is the first rule of network security - don't trust the client.

That cuts both ways, so we trust the client (users have to, even if remote sites do not) and do not trust servers to take individual user data in the clear and use it wisely & fairly. This applies to Brave servers too. Flip the model.

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#159

Earlier quoted context omitted.

Thank you the details. Do my ip-address, sites-i-visited, date/time of visit, geo-location ever gets stored in on a server outside (eg outside my phone or my computer I am browsing on)?

None of those get stored or even sent, except of course for IP address. IP address is not yet masked for update pings (same as for all self-updating browsers, required for security patching) and for similar pings to check for updated ad/tracker blocklists. If you do not opt into any BAT ecosystem features (contributions or ads, which enables contributions), then your IP address is not otherwise used, but it does show…

[deleted]

Re: Funding Choices – Google’s new tool for GDPR compliance and content monetization

#160
post #34

Earlier quoted context omitted.

Their bandwidth bills would be a lot cheaper if they weren’t sending megabytes of JS for every kb of actual content

You have no idea what you are talking about. JS doesn't nearly cost as much as images, and most ad-related JS are minified. For many websites ad serving is the only profitable model. You won't make money off subscriptions unless you are one of the big players and don't have to worry about growing your user base.

> You have no idea what you are talking about.

No personal swipes on HN, please. Your comment would be fine without that bit.

https://news.ycombinator.com/newsguidelines.html

Post reply on HN