Hacker News Reader

Comment by danfang | Hacker News Reader

Founder here.

This is great feedback. My interpretation of the clause is that we can use services like Mailchimp to send you marketing materials for when we release new products and features. These would be strictly opt-in.

I'm not a legal expert, but I will try to come up with a policy that more clearly expresses that you will NOT receive marketing about third-party services and our only usage of these services would be to update you all on our new product offerings.

We're considering offering E2E encryption, but we believe that we can deliver a ton of value by allowing users to search through their messages and for us to efficiently organize and categorize your content. I think there is a middle ground where we can encrypt non-pertinent data, but still preserve metadata so we can provide some intelligence on top of the content you choose to share on the platform.

View on HN

> I'm not a legal expert, but I will try to come up with a policy that more clearly expresses that you will NOT receive marketing about third-party services and our only usage of these services would be to update you all on our new product offerings.

You do not need to be a legal expert to state this in your policy in plain language.

Examples:

"We will collect your contact information for the purpose of updating you about this product."

"We will not collect analytic data."

"If this policy changes, you will be notified 60 days before data collection begins."

You do not need to predicate openness and honesty on legal expertise.

Fixed.

It now reads: "We may disclose personal information to: third parties, including agents or sub-contractors, who assist us in sending direct marketing about our new products and features"

What I meant about legal expertise is that we don't want to be in violation of our privacy policy if we decide to use tools to understand our users better, or if we decide to email users about new products and features. Which is why I left some room in the privacy policy to enable such features.

still leaves wiggle room. Suppose a "direct marketing sub-agent" opens up shop, helps you send a couple of emails, so technically they are assisting you in sending direct marketing, but then that allows you to maybe sell all of your users' personal info to that third party who just set up shop out of a vacuum.

Even if you have good intentions and don't sell them the information, what's the guarantee that these third parties won't use the information you provided them for personal gain anyway?

Two things.

1. We'll be transparent about the services that we use. That way you'll know who your data is being shared to, and what data will be shared.

2. We'll try to take an Apple-like approach of anonymizing data as much as possible and only sharing the few pieces of information we need to deliver a better product.

I'm sorry there's no fool-proof way to guarantee perfect data privacy - at some point you'll have to trust us to do the right thing with your data. We hope that our incentives will . be aligned. Our service is predicated on keeping your information private and that's what you'll be paying for.

> We may disclose personal information

This alone will be enough of a deal breaker for privacy nuts, such as myself. If I'm going to use your service, you just champion privacy. This means no marketing gimmicks.

Sorry. For me this comes no way close to being an iMessage alternative. Even if you become a privacy champion, you still need to expect us to trust your servers, which is a tricky thing without end to end encryption.

Maybe an alternate model is to get funding from big corporate sponsorship and have a distributed network that could be hosted on our own droplets (using open source, of course). You can then have a paid hosted saas for those not technically ready to self host. Until there's a solution out there that does just that, I'm very unlikely to bite.

Yeah - I don't see Thread as the right product for privacy nuts, as you refer to yourself. There are better services for that, like Signal.

I imagine Thread as a company that focuses more on delivering products that allow people to build more meaningful relationships and connections in a way that benefits their long term mental/social health. I believe we can do that in a way that delivers an 80/20 on privacy too, by not using targeted advertising, and having 0 incentives to sell your data.

If you're not willing to trust our servers, I don't think the product is right for you. Hopefully we build trust as a company that does right by our users in the long run, unlike what I'm seeing from companies today.

I'm definitely not your target audience here so please take this with a grain of salt (as I might misunderstand what people value about privacy), but isn't "using tools to understand our users better" exactly what privacy-first people _don't_ want? Gathering that kind of metadata about what users on the platform are doing, instead of making it end-to-end encrypted so you (as the provider) can't see into what people are doing?

> We're considering offering E2E encryption, but we believe that we can deliver a ton of value by allowing users to search through their messages and for us to efficiently organize and categorize your content.

Why must you organize the data? I’d like to be able to perform searches client-side, just like iMessage.

I think you're right that you can probably get some value out of pure client-side search and parsing. Here's my take:

1. I like being able to search through old archives and interactions that might have happened a long time ago. I believe there's value in preserving history and being able to easily look back on it.

2. We can provide value by doing basic message parsing. Right now, if your message includes a Youtube link or Spotify URL we'll give you a player to view that content in-line. If your message has a Yelp link, we'll pull the restaurant details such as where it is, how expensive it is, etc...

Our mission is to provide the best service to allow people to build meaningful, long-term relationships, because _that_ is a need that's not being addressed. A lot of the features we want to offer will require some centralized processing. If you want a purely anonymized, E2E encrypted service, I would recommend Signal or Telegram.

Reply on news.ycombinator.com