brave / ledger

Deprecated, please see

NOTE: This repo is deprecated, please see bat-ledger

Brave Ledger

The Brave Ledger is a BTC-based micropayments system for users and publishers.

Note that travis-ci is not yet operational for this repository.

Initialization

Take a look at the files in the config/ directory. When the server starts, it will look file a file called config/config.{PROFILE}.js where {PROFILE} is $NODE_ENV (defaulting to "development").

Authentication is achieved via a GitHub OAuth application. Create a developer application with an authorization callback of the form https://{DOMAIN:PORT}/v1/login and update the login.clientId and login.clientSecret properties.

Authorization is achieved by verifying that the user is a member of a GitHub organization, i.e., https://github.com/orgs/{ORGANIZATION}/teams. Set the login.organization property to the name of the organization.

Now start the server with npm start and https://{DOMAIN:PORT}/v1/login which will start the authentication/authorization process. On success, you will be redirected to https://{DOMAIN:PORT}/documentation.

When the server starts, it will create (if necessary) a persona and a wallet registrar. You will need to create a 'contribution' surveyor, go to https://{DOMAIN:PORT}/documentation#!/v1/postV1SurveyorSurveyortype, setsurveyorType to 'contribution', and enter a body like this:

{ "adFree": { "fee": { "USD": 5.00 }, "votes": 30 } }

Setup

Clone the repo: git clone [email protected]:brave/ledger.git

Install dependencies with npm install

Install MongoDB: brew update && brew install mongodb

Start MongoDB. There are a variety of ways to do this, one option on a mac: brew tap homebrew/services && brew services start mongodb

Install Redis: brew update && brew install redis

Start Redis. There are a variety of ways to do this, one option on a mac: brew tap homebrew/services && brew services start redis

StandardJS

For linting we use StandardJS. It's recommended that you install the necessary IDE plugin. Since this repo uses ES7 features, you'll need a global install of both the standard and babel-eslint packages.

Configuration

For staging or production environments configuration variables are stored as environment preferences. See config/config.production.js for a list of these variables.

For local development you can copy config/config.development.js.tpl to config/config.development.js and define the local config variables.

Running the server

Use gulp to run the server in development. This also sets up watchers and will restart the server on a file change.

Proximo

Proximo is currently used as a proxy so we can make outbound BitGo requests using a static IP. Please define process.env.BITGO_USE_PROXY as appropriate.

ledger's Issues

Clean-up some Joi-schemas

Joi.any() isn't really very helpful... not a lot of work to be done here, just a bit.

User de-anonymization through browsing summary report data

The current version of the documentation is (in my view) not yet sufficiently clear. I had a very hard time making sense of it. So, this is a preliminary assessment. A more formal outline would be useful.

The proposed format of the browsing summary report is: "a list of the top N most visited sites". This summary format suffers from a large sample space. Such list of top N sites would be pulled from a large number of possible sites, i.e. a large sample universe of say 1000 publisher. This can uniquely identify each user. The threat here is not to link a browsing history to a wallet, but to link a browsing history to a real-world identity.

For example, I am Brazilian and thus frequent both publishers with content in English and Portuguese. I am also an avid Haskell enthusiast and go to Haskell.org very frequently. Through examination of the overall universe, it may be possible to determine my browsing history.

There are 1000-choose-20 list in this format, so it may be that many users will have a unique list. To make payments, Brave will have to link real-world identities to wallets (KYC requirements). This knowledge can be used to build a "real-world profile" that can be leveraged to de-anonymize each user's browsing history.

I believe more sophisticated crypto tools may be needed here.

Sybil attack to get user share revenue

The current version of the documentation is (in my view) not yet sufficiently clear. I had a very hard time making sense of it. So, this is a preliminary assessment. A more formal outline would be useful.

This is a design bug. A malicious adversary can make 1000 "fake" ad-replacement personas that only browse the web once a month and see only 1 impression each. Through the current proposed revenue share model and those personas, the adversary would get 1000 times the revenue of the average user.

This attack shows that dividing the user revenue on a "per user" basis is subject to manipulation. I understand that the underlying motivation for this model is that:

In order to enhance privacy, the payment to each ad-replacement persona are calculated independently of the actual impressions served to each persona -- Brave Software does not keep track of which personas are served which impressions.

However, I believe the principle can still be achieved by aggregation that is not subject to this attack. One could consider a "per impression" rather than "per user" revenue share model where the number of impressions is bundled in multiples of 128 (for example) to still allow for anonymity.

transition endpoint falsely returning insufficient funds error

Skewed revenue share

The current version of the documentation is (in my view) not yet sufficiently clear. I had a very hard time making sense of it. So, this is a preliminary assessment. A more formal outline would be useful.

The proposed format of the browsing summary report is: "a list of the top N most visited sites". This summary format skews the revenue share to the most successful sites. In other words, small publishers that generate value for the web do not monetize any of the value they generate. All value generated by all web publishers will disproportionately monetized by the large sites (i.e. large publishers).

I understand that reporting every single site visited compromises privacy. I believe better crypto tools may need to be used here.

add administrative function to reset publisher ruleset

using POST we override the default ruleset, which is good for hot patches; but the administrator may wish to remove the override, esp. when a new version of the ledger-publisher package is used!

Update Website Terms of Service

Website terms of service text will need updating. Content to be reviewed by legal.

Website / PR plan

Insert PR plan here:

update eyeshade on balance changes

Improving Brave's Ad-Free mode

The Trade-Offs

In my view, the immediate trade-off between the two proposed business models can be described as:

• ad-replacement model: does not require users to pay, but users still have to see ads.
• ad-free model: requires payment from users, but provides an (almost) ad-free experience.

Neither model requires (as currently proposed) significant infrastructure change from publishers.

There is however, another difference between the two models that I believe needs to be considered carefully:

• ad-replacement model: Brave is ultimately funded by advertisers, not users.
• ad-free model: Brave is ultimately funded by users, not advertisers.

This is important because over the long run, misaligned incentives can cause Brave to lose touch with its privacy mission, independent of its initial goals. For example, consider the erosion of privacy that happened at Google since its inception. From this point of view, the ad-free business model is more appealing.

Current problems with Ad-Free

From a user's point of view, I see two value propositions in using Brave's ad-free mode:

1. Avoids visual pollution - User does not see ads and page loads faster
2. Avoids tracking - User privacy is respected

This is the value proposition I believe Brave wants to provide. However, it is not currently possible for a user to determine whether she is getting this. In other words, the current design of ad-free mode does
not provide accountability. This is because:

a. Brave does not block first-party ads, so some ads may still show up.
b. The publisher has not agreed to respect user privacy and may choose to violate it.

Avoiding visual pollution

Let us first consider (a).

If a user goes to a website and sees zero ads using Brave, the user can immediately see the value of Brave. On the other hand, if the same user goes to a website and sees fewer ads. It is almost impossible for the user to perceive any benefit in using Brave as the user has no baseline comparison level. So, fewer ads just seems like: "this adblocker is not working properly, I can still see some ads." In other words, in ad-free as currently proposed Users do not know what ad-blocking value they are getting.

In ad-free mode, the user will only perceive a clear benefit in using Brave if no ads at all are seen and, thus, even first-party ads need to be removed. Clearly, this makes the problem harder, but assume for
now that this is possible. There is still the other problem with ad-free: How much should users pay?

How much should I, as a user, be willing to pay to see ad-free content? What is a fair price? Users have no easy way to know this. Users do not know how much they should pay and as a consequence do not know whether they can afford an ad-free web experience. Even if users browsing in ad-free mode saw value in the experience, they may still think that they are over paying for it.

Here's a personal anecdote as an example:
I have been using blendle.com recently. In that website, every article comes with a different price. I find it very hard to justify paying $0.49 for most articles of the Wall Street Journal when I see that most articles from the New York Times are available for $0.19. Why the price difference? Is the Wall Street journal over charging me? (Thankfully, in Blendle I can withhold payment if the article is not good.)

I believe Brave can help users determine how much they should pay for an ad-free web visit. The current ad auctions run by 3rd-parties provide an upper-bound on the price a user should be asked to pay. Today those auctions are run based on user tracking data. But it may be possible to leverage this information to help users and automate "ad-free biding" in the browser. That's my suggestion. If users knew that an ad-free web experience costs approximately $9 a month (or whatever), they may be more willing to fork out the cash. Paying $9 a month without knowing how many ad-free days one is going to get is not a deal I would take.

Avoiding Tracking

Let us now consider (b).

Currently, publishers are not required to preserve user privacy and they have financial incentives to subvert it. Given the chance, they may come up with ingenious ways to track users. To demonstrate Brave's value proposition, Brave should require that publishers adopt an appropriate "Do Not Track policy" (e.g. https://www.eff.org/dnt-policy) before they are able to receive funds from ad-free users. This forces publishers to be accountable. It doesn't solve the problem, but now Brave users have set a benchmark and can sue publishers who violate their privacy, whereas before there was no such single friendly benchmark and, thus, it was not so easy to sue.

Conclusion: Ad-Free requires infrastructure changes

If one accepts the premise that users will not pay unless they see value, the above argument has an important consequence: Making the value of ad-free mode visible to users requires cooperation from publishers to establish a good "Do Not Track policy" and to negotiate a fair price for blocking all ads, including first-party ads. Thus, this mode may be a harder sell in the short-term despite keeping Brave on the side of users over the long-term.

As currently proposed, "ad-free mode" will not provide users with incentives to spend money as they will not see any clear value in it. I believe this can and should be addressed.