enegnei / this-month-in-bitcoin-privacy Goto Github PK

Hello. This issue is intended to reply to this post authored by @Enegnei and make any needed changes to our (Zap/Strike) privacy policy, terms, product, and so on.

The Strike homepage describes their service as 'private.'

I agree this can be misleading. The intention is data we have is never shared and one can spend money to friends and on services through us as a proxy of sorts. However, with Cognito and Plaid, I can understand the concern with displaying Private without further clarification. This has been updated to Fast on our website.

They also reserve the right to "block access to the Services from certain IP addresses and unique device identifiers."

Of course. This is not unique to our service. If we need to block service for a user for regulatory, compliance, or malicious behavior we need to ensure we have that right.

Transaction terms

Reserving the right to change limits is based on our ongoing dialog with regulators. Currently, a LIGHT user has the following limits:

• $100 per payment
• $2,000 lifetime

I work with regulators to raise these limits and eventually remove them. This was discussed publicly (on your podcast @Enegnei)

However they also use "pixel tags / web beacons," and engage in other automated collection activities:

Technology such as Cookies is required for such features as persisting a user's login. Web beacons or pixel tags are the politically correct, lawyer-speak, way of acknowledging we use analytical tools. The definition is defined in the Privacy Policy. This is standard across all web and mobile applications.

Cognito

Yes, it is true that we use Cognito to do a wider search based on the information provided to us. I clarified publicly (on your podcast @Enegnei) that this "LIGHT KYC" effort was designed to prevent users from sharing information with a third party (Strike) if they don't have to. One of the many dangers KYC authors is a given individual's data being scattered across various services. The concept was if a user gives us their name and phone number, is that enough? If so, we aren't interested in anything else. It in theory should benefit the individual and the UX of our product.

Do you have an issue with the above? Would you like me to document this intention somewhere? How can I better communicate how we use Cognito?

VISA and Plaid

It should be fairly obvious, but our early-stage Bitcoin startup has zero relation to VISA making a multi-billion dollar acquisition. I have clarified publicly on many occasions that our relationship with VISA is through their Fast Track program and our relationship with Plaid is simply signing up, creating an account, and integrating with their API.

A user has a relationship directly with Plaid. This is outlined in their documentation
. When a user adds a payment method through Plaid (regardless of the service), they are shown the following screen:

The user, therefore, agrees to Plaid's terms and privacy policy before adding a payment method. Plaid's privacy policies can be found here.

Plaid is the number one service in the US to allow deposits from a consumer's bank account. Services such as CashApp, Venmo, Robinhood, and Coinbase use Plaid. I stated publicly (on your podcast @Enegnei) that our effort with Plaid was based on advice from others and the quickest way to accomplish an MVP. We allow users to deposit funds via a debit card currently and plan on allowing other ways for users to deposit funds.

I understand the concern that Plaid is not mentioned in our privacy policy and have reached out to our counsel with an ask to have that updated.

At this time, contrary to my initial determination, I do not believe that applying this term to Strike would be accurate

How would you define it then? Is it fair to make a distinction between full KYC and what we provide? So far, LIGHT has worked as a way to communicate the feature, however, I am open to suggestions of course.

Summary

In summary, Strike is a regulated, proprietary service. It does not market itself otherwise and does not market itself to be for those that don't want to share any personal information. It requires an individual's personal information and the ability for that given individual to deposit fiat currency. In order to support the service, third party relationships are required. If one is not comfortable with companies like VISA, Plaid, and so on, that is fair and entirely your decision.

After reviewing your piece @Enegnei it's unclear to me what exactly we need to improve on. Yes, we are regulated and require personal information by law. Yes, we require depositing fiat currency which in turn requires some form of linkage to a payment method. I believe all of our efforts have been public, transparent, and honest. I've publicly stated this project is in BETA and we have been iterating based on feedback and concerns and intend to continue doing so.

Thanks for your great work.

Follow me and / or this repository on GitHub. When a new edition comes out, I will link to it here in the readme. However, if you use this option, be aware that you may also be seeing all the changes I make throughout the month in your feed.

It's now possible to configure "Watching" repos, e.g., it's possible to watch only for releases. You may consider creating a release every time a edition is out, and then people can use this feature to subscribe.

Should I ever end up integrating some kind of privacy-respecting email marketing service in the future, I will not migrate your email address without your explicit permission.

Are you aware of https://buttondown.email/? Ignore me if you have looked into this service already.

Pasting in comments from Waxwing via: https://bitcoinhackers.org/web/statuses/104789319086625186

A couple of points: On the payjoin section, note what's new is BIP 78 (I don't think you linked it?), and the final sentence seems to suggest that compatibility is something still under discussion, but it is already done, at least, from spending side - so a JM user can pay a Wasabi user with this (including to Tor HS endpoint).

I linked to BIP-78 at "based on Nicolas Dorier’s BIP-78."

The part about compatibility was referring to the Samourai-Samourai and Joinmarket-Joinmarket PayJoins. I will re-write it to be more clear, I was just acknowledging that SW and JM already had PayJoin implementations, as mentioned in your release notes: "Note that the pre-existing Joinmarket-Joinmarket payjoin function still exists, but we will deprecate and remove it (almost certainly) when we add BIP78 receiver support to this wallet." And Samourai's is still not compatible.

On the Joininbox thing: it's very misleading to describe this as a GUI for Joinmarket; we've had that for 4 years and it's vastly improved recently; see https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/docs/JOINMARKET-QT-GUIDE.md plus various video guides linked in the readme.md. These are mostly up to date, though not 100%.

"As I covered in TMIBP01, JoinInBox is a graphical interface for the CoinJoin implementation JoinMarket, currently optimized to run on the RaspiBlitz full node."

That sentence links to a story from the first issue of the newsletter, which acknowledges that there's an existing GUI for JoinMarket and just quotes Openom's personal motivation for working on another specifically for RaspiBlitz. I will re-write and link in those docs for this newer story to make it more clear though.

Additionally I have recently been working on a demonstration of a Javascript web/electron style cross platform client: https://x0f.org/@waxwing/104711319655673159

(Also there is a Maker-in-Qt PR that has been languishing because I didn't get much positive response: JoinMarket-Org/joinmarket-clientserver#487 )

Now, of course, what Joininbox does do (and is great for this) is support Maker functionality on a RPi with a graphical menu for controlling the bot; it's a stretch to call this a "GUI for Joinmarket" although technically it is, it will mislead people to say that.

ACK, I'll add those links in.

Thanks for TMIB! It's a great way to keep up with developments in the space.

I noticed in the latest issue that the jabber link is corrupted, the URL is https://enegnei.github.io/This-Month-In-Bitcoin-Privacy/March_2021/[email protected], and I assume it should just be [email protected].