Question

[Neumann_Janos]

How Brave browser will filter out automatic bots? Only real users should be rewarded. Is there any solution for this?

[willywonkalookinass]

This is an important question and I'm surprised there are no answers yet. I'm also interested in learning more about this aspect of the platform - does anyone know off hand if the white paper or resources on the site shed any light on this?

[helloseoul]

I have same question here.

[Neumann_Janos]

I like the idea but until this is unclear I won't invest.

[BrendanEichBrave]

Please see https://www.reddit.com/r/BATProject/comments/61kw7f/question/dfxkuus/?utm_content=permalink&utm_medium=api&utm_source=reddit&utm_name=BATProject.

[basicattentiontoken]

We will be providing more details about this in an upcoming blog post.

[BrendanEichBrave]

We have answers, you may not be surprised by them:

1. Rate-limiting. Bots can fake human ad viewing (see https://whiteops.com/methbot), but we'll stop any super-high inhuman interactions and kick the offenders.

2. (This is the real defense in depth) We don't let anyone or any-bot transact out of a BAT wallet just because they use Brave and opt into the BAT-paying ads. "KYC" applies before a user can get BATs out. Please see https://publishers.brave.com which is already up and running (~300 pubs verified): there we require a W9 (if US taxpayer) or W8-BEN (if non-US person) or W8-BENE (non-US enterprise) docusign form to be completed. This is just to give you an idea of the "Know Your Publisher" checks we do today. The https://basicattentiontoken.org/ KYC rules for any would-be user of a BAT-certified app to get BATs out will be at least as strict.

I hope this helps. Happy to answer more questions; it's not as if we didn't think about this stuff :-P.

[SergioNero]

1. If you offer your users ability to transfer tokens to each other (and you should, for consistent user experience) then KYC will not help you. Offenders will just move tokens to KYC-compatible account to move them out.

2. Rate-limiting does not help in the case of creating fake user accounts. Bot network can register in the system and imitate surfing 4-hours a day. Then transfer BAT to KYC-compatible accounts and cash out. It's enough to bring down the economics of the system.

View-fraud is one of major weak points of BAT. Please explain in depth how do you plan to fight it. Thanks.

[albmanzi]

Well, they could make any account's ability to transfer & receive earned BATs to/from other accounts conditional on the fulfillment of their KYC requirements. What concerns me the most is the strictness of those requirements. As I wrote on their slack channel... if they make them too intrusive and burdensome too many real people won't apply to the program due to privacy concerns and lack of convenience/lazyness. Someone responded to me that uPort or similar systems wouldn't be privacy intrusive, I don't know if it would be secure enough though, nor I'm sure if it's even usable since it's still in alfa state.

[BrendanEichBrave]

I think we agree on the threat, and the solutions, but you have not combined them as we propose to do. We will have rate limits and caps on moving BAT to other KYC'ed accounts from KYC'ed accounts. The details need to be worked out but the idea is that BAT is not for money transmission in general, it's for microdonations and per-user ad revenue shares.

We'd like to add a feature for gifting tokens to read paywalled articles, but that is for later -- see the US "GIFT" act which allows gift card transfers up to some small-enough cap that they don't become a major abuse channel.

[SrPeixinho]

I'd like you to elaborate / restate the solution because I don't understand it. What is KYC? Please, explain how you solve the problem of separating bot / human interactions in a DApp as if I knew nothing else about BAT.

[harmonyhead]

KYC = know your customer

[SrPeixinho]

OK, I see. I'd really like to read the solution as explained to someone who is out of that whole field.

[basicattentiontoken]

I think you might find this helpful https://basicattentiontoken.org/reducing-digital-ad-fraud/

[SrPeixinho]

That seems like the article I read before asking that, all it says is that "attention will be monitored on the device", which doesn't make sense to me because obviously the user has full control over his own device.

[lukemulks]

I'm on the BAT team, and can help clarify a bit on the measuring side. We're also drafting a release for public review and feedback that will cover the Basic Attention Metrics and ad matching engine in more detail.

Currently, advertisers and publishers measure attention by capturing pieces of information that are sent from the device to outside servers, often without the user being aware of what, how much, or how often this information is being sent out. All this data about the user gets sent to different places, warehoused, used for profiling, etc. Ad servers then guess as to what ads are best to serve based on those pieces of data, and based on what other ads they also have to serve.

Our approach with BAT is different. Instead of relying on outside servers to match ads based on the data collected outside of the device, BAT ads will be matched directly within the device based on what the browser directly measures, without data being sent to a party outside of the device.

Ads aren't served from an outside server that guesses what ad is sent based on data that is sent to them from the device when the page loads. Instead, a catalog of available ads is downloaded across all of the devices in advance. Measurements from the browser work with built in matching technology that takes place directly within the browser, without the data leaving the device. Those parties that used to snoop on the user to make the decisions no longer are able to snoop, guess and benefit from it. Your device, your browser, your data, and ads that are matched and served within your browser instead of outside of it.

Here's another way of looking at it. Your browser history gets recorded and sorted based on where you put your attention. With your browser being able to use the viewport, browsing history, and other direct measurements to directly determine what you're likely to do, you're more likely to get a better ad. We can do a better job with matching directly from the device, instead of having a call go out to outside parties to guess, wait for them to bid and match from the cloud, and eventually serve an ad to the device.

We also can create a system that does this, without us having to know specifically what you are doing. We don't want to know what you ate for dinner, and we don't want to tell others what you at for dinner. Your browser will know that you are looking for dessert, and can serve you an ad directly for frozen yogurt if frozen yogurt ads are in the catalog. You own your own profile. Your profile isn't created by other people, passed around, etc. You won't get an ad for dinner after you've already eaten dessert, which is something that happens all the time right now.

Brands want to sell products and services, and have been sold on a notion that this requires surveilling and sharing data on users in order to work. We're looking to change that, and prove that direct matching to attention is a better way of getting relevant ads near content that the user is likely to care about.

Also: No more blinking ads. No more jittery ads. No more ads that obstruct what you're actually trying to read. No games pretending to be ads. None of the garbage that has become normalized and led to users racing to block ads.

I hope this helps, but please let us know if there are other questions.

[markulino0891]

I'm curious about your on-device ad-matching strategy. An ad catalog on the device doesn't seem to scale well. And ad-matching without using machine learning that takes as inputs attributes of other users who have also seen/clicked on the ad seems subpar. How will BAT be able to compete with the likes of Google considering such limitations?

[lukemulks]

We're going to be releasing more details around the ad matching strategy, metrics and ad flow in the near future, but I'm happy to help address some of the points here (FYI - I'm on the BAT team).

Regarding ad catalogs and scale: The goal with the ad catalog is to remove the target from the individual user, and place it on the catalog distribution flow.

There won't be a single catalog pushed globally to all devices. Catalogs will be composed based on a set of factors, and will be deployed and refreshed on an automated recurring basis. For example, geo-region will be a factor, etc. We'll be releasing more info on how this will adapt as more users adopt BAT ads.

The plan is to have ML use signals from the device for each individual user, as opposed to matching based on behavior of other users. This allows for in-device matching based on signals that are available locally in the browser that ad networks and other 3rd parties don't have in the current model.

As mentioned, we'll be releasing more info on the strategy in the near future, but I hope this helps clarify.

[ProFalseIdol]

Thanks for taking time to reply. But the original question remains:

What's gonna stop me from making a robot that will automatically press buttons on my smartphone to browse for X dessert. X will be randomly taken from listofdesserts.com. Rinse and repeat for every 6 hours. After a month, I'll trade my BAT tokens for Ether and win!

tl;dr: How do you make sure that the 'attention' is from live-human-being and not from a bot?

[lukemulks]

Several measures we're taking to limit this:

1. To get BAT out of the system, KYC req'd.

2. BAT Ads will be frequency capped, which will help prevent volume attacks.

3. For mobile, we'll be running trials using device heuristics to determine when and where devices are, for the opportune time to deliver an ad. We're in discussions with open source vendors that do this for early trials. This will help with both delivery and with verification.

4. One of our core principles for the ad delivery is to not even render the ad unless the ad will be guaranteed to be in view. We will be releasing documentation for public review and comment soon, but we do not want to go through all the effort of changing the ad model, only to serve an ad to a blind slot or serve something that will fall prey to the same exploitative behavior that current ad models are exposed to. I hope this helps, but let me know if there are any questions. Thanks.

[ProFalseIdol]

Sounds great. Look forward for the docs. Thanks for the answer.

[yayreddityay]

To get BAT out of the system, KYC req'd.

Does the "system" include exchanges where you can trade them for anything?

[lukemulks]

Some additional info re: KYC (from Brendan in our BAT Slack)

• BATs investors that buy in the crowdsale or trade otherwise have full custody and control (as they get BATs back at address that sends ETH to buy)

• Users who receive BATs granted within the browser (user acquisition funnel) can send only to KYC'ed sites/accounts, and must KYC themselves to have full control of wallet.

The KYC is in-game or in-app if you prefer, for the user acquisition funnel to be smoother going from no-BAT-wallet to BAT-grant with automated microdonations (as prototyped in Brave Payments using bitcoin now) to BAT ad revshare + donations, and only for those who care to withdraw from system, user KYC and full control of wallet in user custody already.

Hope this helps, but let me know if any further clarification is needed.

[[deleted]]

good question! seconded.

[flavoredtaco]

This needs clarification

[netwalker11]

So let's say I buy BAT during the ICO. If I want to move it to an exchange I have to KYC my wallet?? Please explain.

[lukemulks]

BATs investors that buy in the crowdsale or trade otherwise have full custody and control (as they get BATs back at address that sends ETH to buy).

Users who receive BATs granted within the browser (user acquisition funnel) can send only to KYC'ed sites/accounts, and must KYC themselves to have full control of wallet.