/biz/ - Business & Finance

Get in here BAT holders!

>>23915983
OH SHIT THEY'RE ALL FOR YOU

The buy signal we've all been waiting for

BAT, man

>>20907960

>>13174987
I stated the fiat percentage straight after for gargoyle intelligence tier cunts like yourself.

>>12972403
You're a gem

>>12934852
Eich trampled all over this like any self respecting tech autist would.

>Update to say this is not a "backdoor" in any event, and custom headers are allowed per https://tools.ietf.org/html/rfc7231#section-5..
>Lots of confusion today about network requests or (in this case) custom but user-id-free headers vs. "tracking". A script load exception list (we will try to get rid of it; new thinking is defer until user clicks on FBConnect widget) we hardcode should be overridable and really should go away, but we are practical about not defaulting to a browser that doesn't work on too many sites to have adoption. That's on my twitter today.

>This post is about custom HTTP headers we send to partners, with fixed header values. We could have just hacked the user-agent: header but chose custom instead. There is no tracking hazard here.

In both cases, third party tracking requires some kind of persistent-in-the-client identifier, or else fingerprinting. We block 3rd party cookies and storage, also 3rd party fingerprinting. We block (dual-key, actually -- same as Safari) HSTS supercookies (HSTS added 1 bit per domain of client-persistent state, so 32 junk domains enables the Criteos of the world to make a per-user 32-bit identifier).

>As a user, I find it important to understand the diffs between requests and tracking before choosing a tracking protection solution. At first (in the '90s), I didn't grok the implications of 3rd party cookies, images, and scripts -- neither did pmarca or montulli, lol. Those genies are long out of their bottles.

>Also I find it silly to assume we will "heel turn" so obviously and track our users. C'mon! We defined our model so we can't cheat without losing lead users who would see through it. That requires seeing clearly things like the difference between tracking and script blocking or custom header sending, though.

BAT general?

>>12727525
Brendan Eich
Update to say this is not a "backdoor" in any event, and custom headers are allowed per https://tools.ietf.org/html/rfc7231#section-5..

Lots of confusion today about network requests or (in this case) custom but user-id-free headers vs. "tracking". A script load exception list (we will try to get rid of it; new thinking is defer until user clicks on FBConnect widget) we hardcode should be overridable and really should go away, but we are practical about not defaulting to a browser that doesn't work on too many sites to have adoption. That's on my twitter today.

This post is about custom HTTP headers we send to partners, with fixed header values. We could have just hacked the user-agent: header but chose custom instead. There is no tracking hazard here.

In both cases, third party tracking requires some kind of persistent-in-the-client identifier, or else fingerprinting. We block 3rd party cookies and storage, also 3rd party fingerprinting. We block (dual-key, actually -- same as Safari) HSTS supercookies (HSTS added 1 bit per domain of client-persistent state, so 32 junk domains enables the Criteos of the world to make a per-user 32-bit identifier).

As a user, I find it important to understand the diffs between requests and tracking before choosing a tracking protection solution. At first (in the '90s), I didn't grok the implications of 3rd party cookies, images, and scripts -- neither did pmarca or montulli, lol. Those genies are long out of their bottles.

Also I find it silly to assume we will "heel turn" so obviously and track our users. C'mon! We defined our model so we can't cheat without losing lead users who would see through it. That requires seeing clearly things like the difference between tracking and script blocking or custom header sending, though.

https://www.twitter.com/BrendanEich/status/1094766068554379265

>This board needs me

>>12704669
Yes

Some rough product analogies (it goes without saying that BAT is different from Google products in that it's client-side, privacy-respecting, and shares revenue with the user, etc.):

BAT Ads = Google Adwords
BAT SDK = Google AdMob
BAT Publishers = Google AdSense

But imagine in order to fly a campaign in AdWords, you had to purchase AdWords tokens. In our case, this would be BAT tokens

Get it now?

>>12349085
Nice. I wonder how many BAT/LINK bros there are on /biz/. I personally don't own any LINK (i'm all in on BAT) but these two tokens seem to be /our coins/

>>6363018

I don't think anybody really gives a shit about convincing you or other brainlets, one way or another.

BAT threads are fun threads with lots of excitement, because if you weren't a pajeet retard you'd see the potential behind Brave and the project in general. People that own BAT are excited about it, and your silly "$1 MAX" FUD isn't going to change that. Stay salty.

>>6249326

Holy fuck man. I'm a poorfag BAT enthusiast with ~600 BAT, planning on buying more, but that's more than I could even dream of.

Godspeed.

>>6192449
BAT being over $100 defeats the whole purpose of the token. If you knew anything about the project, you'd know this.

Use your brain people. Are you seriously going to fucking buy this over $100?

>>6134612

OC memes for the wonderful BAT thread.

0xb130270a594d925c4b3653c2f2601fe843f8ec51