FWD:Everyone(fwdeveryone.com)
fwdeveryone.com
FWD:Everyone
https://fwdeveryone.com/
142 comments
One thing you almost certainly want to change is the site's behavior with Javascript disabled - right now, it just shows a white screen with the text "Loading FWD:Everyone".
It's a bit of a pet peeve for me to see pages like this that are primarily static but are not accessible without JS, but I can understand that making a page built with a JS frontend work without it might be more work than it's worth, at least for an early stage project.
However, you really should put up some sort of notice to users - while being able to read a short blurb about what the site is nice, even just "<noscript>This site requires Javascript to view.</noscript>" is better than a blank page or permanent loading screen.
It's a bit of a pet peeve for me to see pages like this that are primarily static but are not accessible without JS, but I can understand that making a page built with a JS frontend work without it might be more work than it's worth, at least for an early stage project.
However, you really should put up some sort of notice to users - while being able to read a short blurb about what the site is nice, even just "<noscript>This site requires Javascript to view.</noscript>" is better than a blank page or permanent loading screen.
Good suggestion on the noscript.
There is actually a bunch of animation and interactivity on the site though. E.g. if you click on anyone in a thread, you see their bio and their other threads. And when you hover over a user’s popsicle stick on the newsfeed it pops up, which is stupid but oddly satisfying... We tried to give it the feel of popping bubble wrap.
Anyway prerendering more stuff is on our roadmap, so once that’s set up we can reevaluate.
There is actually a bunch of animation and interactivity on the site though. E.g. if you click on anyone in a thread, you see their bio and their other threads. And when you hover over a user’s popsicle stick on the newsfeed it pops up, which is stupid but oddly satisfying... We tried to give it the feel of popping bubble wrap.
Anyway prerendering more stuff is on our roadmap, so once that’s set up we can reevaluate.
It's called CSS3 mate.
You're absolutely right! We'll get this up ASAP. Thanks for your interest in the site.
This also applies to the case where JS fails. What if the browser supports js, but the request failed, or there was a syntax error, or some other fatal that halts js? Your users will be left on a lark without anything to look at.
> - Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment.
This is horrible! I mean, people can always be jerks, and publish private email. But you're facilitating that. This could readily be used, as an example, as a type of revenge porn. Sure, victims can anonymize themselves. But only after the information has been published, and potentially scraped. And you know that jerks will be scraping your site, for just this reason.
The default must be requiring explicit permission from all participants. Without permission, even anonymization is insufficient to protect against abuse.
This is horrible! I mean, people can always be jerks, and publish private email. But you're facilitating that. This could readily be used, as an example, as a type of revenge porn. Sure, victims can anonymize themselves. But only after the information has been published, and potentially scraped. And you know that jerks will be scraping your site, for just this reason.
The default must be requiring explicit permission from all participants. Without permission, even anonymization is insufficient to protect against abuse.
> The default must be requiring explicit permission from all participants.
That's still the default. There are lots of legitimate use cases for publishing stuff without permission though, e.g. emails from Steve Jobs or whatever.
Normally when social sites get a lot of traction and then die it's because they go into a death spiral of negativity: e.g. Secret, Whisper, Yik Yak, etc. The best practice for avoiding this is to err on the side of too much friction when launching, and then to reduce friction for people who are contributing positively to the community.
That's basically the model we're following. The whole point of the site is to showcase positive interactions between people. E.g. showing conversations between VCs, between academics, lawyers, etc. I think the site is too wonky to get overly negative, but if it starts going that way then we'll be very quick to change things up again.
That's still the default. There are lots of legitimate use cases for publishing stuff without permission though, e.g. emails from Steve Jobs or whatever.
Normally when social sites get a lot of traction and then die it's because they go into a death spiral of negativity: e.g. Secret, Whisper, Yik Yak, etc. The best practice for avoiding this is to err on the side of too much friction when launching, and then to reduce friction for people who are contributing positively to the community.
That's basically the model we're following. The whole point of the site is to showcase positive interactions between people. E.g. showing conversations between VCs, between academics, lawyers, etc. I think the site is too wonky to get overly negative, but if it starts going that way then we'll be very quick to change things up again.
> That's still the default.
That's good to know.
> There are lots of legitimate use cases for publishing stuff without permission though, e.g. emails from Steve Jobs or whatever.
Just because he's dead, and was a public figure, is it morally acceptable to publish private email? Or even legal, without permission from his estate?
A quick search gives me the following.
https://blogs.findlaw.com/law_and_life/2018/04/is-it-legal-t...
https://writersweekly.com/this-weeks-article/legal_emails
https://law.stackexchange.com/questions/3980/is-it-legal-to-...
Edit: Also:
http://nulawreview.org/extralegalrecent/do-not-forward-why-p...
That's good to know.
> There are lots of legitimate use cases for publishing stuff without permission though, e.g. emails from Steve Jobs or whatever.
Just because he's dead, and was a public figure, is it morally acceptable to publish private email? Or even legal, without permission from his estate?
A quick search gives me the following.
https://blogs.findlaw.com/law_and_life/2018/04/is-it-legal-t...
https://writersweekly.com/this-weeks-article/legal_emails
https://law.stackexchange.com/questions/3980/is-it-legal-to-...
Edit: Also:
http://nulawreview.org/extralegalrecent/do-not-forward-why-p...
Of course if he is dead and is a public figure and the other part discloses it the exchange is now part of history. What is wrong with that?
I love to read correspondence from folks like Newton[1] for example and I want my grandchildren to be able to read Jobs exchanges as well.
[1] http://www.newtonproject.ox.ac.uk/texts/correspondence/all
I love to read correspondence from folks like Newton[1] for example and I want my grandchildren to be able to read Jobs exchanges as well.
[1] http://www.newtonproject.ox.ac.uk/texts/correspondence/all
Based on the cites that I listed, it's not that simple.
Edit: Perhaps there's now legitimate public interest for most everything about him. But maybe some Apple-related stuff is still off limits.
Edit: Perhaps there's now legitimate public interest for most everything about him. But maybe some Apple-related stuff is still off limits.
In terms of legality there are two separate issues, invasion of privacy and copyright. Things like privacy / libel / slander generally don't apply to the deceased, so in this case I think we can safely ignore that.
With respect to copyright, when you send someone an email you're using an agreed upon protocol (RFC 5322, RFC 5598, etc.) that implicitly grants the recipient a copyright. Now you can say this is a bad argument because no one ever reads those, which is true. But if this weren't true legally, then every time you replied to an email it would be illegal since (in most clients) the full text of the previous email gets copied below the new text. Users also can't really use the platform to violate the copyrights of third parties (e.g. by attaching music or whatever), since the platform is tied to their email account.
From an ethical perspective, the reason we specifically excluded whistleblowers as a user story is that you can't build a sustainable business around it, since you can only be a whistleblower once. we've designed it to force uploaders to have skin in the game. E.g. they can't anonymize themselves, and they're forced to link their Gmail accounts. I think that's enough to prevent the vast majority of bad behavior. E.g. you could also copy and paste someone's private email into a HN post, but it's just not done. The only thing we really do is make the process easier by letting people making redactions, anonymize people, send permission requests, etc., but that's not exactly a selling point for people who would be egregiously abusing the site.
With respect to copyright, when you send someone an email you're using an agreed upon protocol (RFC 5322, RFC 5598, etc.) that implicitly grants the recipient a copyright. Now you can say this is a bad argument because no one ever reads those, which is true. But if this weren't true legally, then every time you replied to an email it would be illegal since (in most clients) the full text of the previous email gets copied below the new text. Users also can't really use the platform to violate the copyrights of third parties (e.g. by attaching music or whatever), since the platform is tied to their email account.
From an ethical perspective, the reason we specifically excluded whistleblowers as a user story is that you can't build a sustainable business around it, since you can only be a whistleblower once. we've designed it to force uploaders to have skin in the game. E.g. they can't anonymize themselves, and they're forced to link their Gmail accounts. I think that's enough to prevent the vast majority of bad behavior. E.g. you could also copy and paste someone's private email into a HN post, but it's just not done. The only thing we really do is make the process easier by letting people making redactions, anonymize people, send permission requests, etc., but that's not exactly a selling point for people who would be egregiously abusing the site.
IANAL, and so don't know how libel and slander apply to the deceased. I can imagine how estates might have claims. But ??? And even so, there are all the non-deceased correspondents.
I had no clue that email protocols "implicitly grants the recipient a copyright". What are cites for that? Neither https://tools.ietf.org/html/rfc5322 nor https://tools.ietf.org/html/rfc5598 includes "coptright" except in the "Copyright Notice".
But anyway, I get your point about "forc[ing] uploaders to have skin in the game." Maybe that will be enough. Because, as you say, there are many other ways to leak confidential stuff.
I had no clue that email protocols "implicitly grants the recipient a copyright". What are cites for that? Neither https://tools.ietf.org/html/rfc5322 nor https://tools.ietf.org/html/rfc5598 includes "coptright" except in the "Copyright Notice".
But anyway, I get your point about "forc[ing] uploaders to have skin in the game." Maybe that will be enough. Because, as you say, there are many other ways to leak confidential stuff.
The protocols don’t talk about copyright explicitly, but they talk about replying and forwarding. Both of those behaviors are only legal if there is an implicit grant of copyright to the recipient.
IANAL, but...
Replying is always legal (copyright-wise, at least, notwithstanding other laws that might prohibit it for some other reason, e.g. CANSPAM), so long as your reply does not include my original message or a portion thereof (aside from parts that I didn't really author in a meaningful way, e.g. email headers).
Replying with quotes, forwarding, or sending a paraphrased/summarized equivalent to my email may or may not be automatically legal depending on your jurisdiction's laws around fair use. Unless you know that it falls under fair use, it's almost certainly safer to treat it as illegal without prior authorization.
Replying is always legal (copyright-wise, at least, notwithstanding other laws that might prohibit it for some other reason, e.g. CANSPAM), so long as your reply does not include my original message or a portion thereof (aside from parts that I didn't really author in a meaningful way, e.g. email headers).
Replying with quotes, forwarding, or sending a paraphrased/summarized equivalent to my email may or may not be automatically legal depending on your jurisdiction's laws around fair use. Unless you know that it falls under fair use, it's almost certainly safer to treat it as illegal without prior authorization.
That line of logic doesn't work. A protocol is neither legal not illegal. It would be like saying that Swedish is illegal. The law largely doesn't care how you do something.
It's also not a necessary condition because an internal company mail server wouldn't run into copyright issues since the company owns the copyright on all their employees' work.
"Uploading a copyrighted work that I downloaded via GET with POST must be legal otherwise HTTP would be illegal."
It's also not a necessary condition because an internal company mail server wouldn't run into copyright issues since the company owns the copyright on all their employees' work.
"Uploading a copyrighted work that I downloaded via GET with POST must be legal otherwise HTTP would be illegal."
> A protocol is neither legal not illegal.
My point is that when you send someone something you've written as an email, it constitutes an informal agreement (essentially a private contract) with the recipient.
> It's also not a necessary condition because an internal company mail server wouldn't run into copyright issues since the company owns the copyright on all their employees' work.
That's true, but anyone with a company email address is legally considered a representative of the company. (That's why you always need to deactivate people's email addresses when they leave.) So while the company (almost) always owns the copyright over work created, the employee is able to dual license that content by sending it via email.
Anyway just to be clear we're not saying you should go ahead and dox all your friends. We're not ad supported, that doesn't benefit us at all. (If your first experience with the site is getting doxxed, you're probably not going to sign up, and almost certainly aren't going to start paying for the business product.)
My point is that when you send someone something you've written as an email, it constitutes an informal agreement (essentially a private contract) with the recipient.
> It's also not a necessary condition because an internal company mail server wouldn't run into copyright issues since the company owns the copyright on all their employees' work.
That's true, but anyone with a company email address is legally considered a representative of the company. (That's why you always need to deactivate people's email addresses when they leave.) So while the company (almost) always owns the copyright over work created, the employee is able to dual license that content by sending it via email.
Anyway just to be clear we're not saying you should go ahead and dox all your friends. We're not ad supported, that doesn't benefit us at all. (If your first experience with the site is getting doxxed, you're probably not going to sign up, and almost certainly aren't going to start paying for the business product.)
Granted that sending an email implies an informal agreement. But this agreement has to be thought of as giving exactly the rights needed to facilitate the email communication, and nothing more.
That means:
- copyright is still with the sender (or their employer)
- no rights to publish the message.
The users of your service will regularly violate copyrights if they didn't get explicit permission to publish.
That means:
- copyright is still with the sender (or their employer)
- no rights to publish the message.
The users of your service will regularly violate copyrights if they didn't get explicit permission to publish.
> it constitutes an informal agreement (essentially a private contract) with the recipient.
Is there any precedent you're basing this opinion on? Because it's not like your company just gets to decide this.
What are the terms of this supposed contract? If JK Rowling sent you the text of Harry Potter do you believe you have the right to distribute it through your site?
Do you believe that there would be a meaningful difference between Netflix sending you the same bits over email vs HTTP?
Is there any precedent you're basing this opinion on? Because it's not like your company just gets to decide this.
What are the terms of this supposed contract? If JK Rowling sent you the text of Harry Potter do you believe you have the right to distribute it through your site?
Do you believe that there would be a meaningful difference between Netflix sending you the same bits over email vs HTTP?
> Is there any precedent you're basing this opinion on?
There's no clear precedent. Clearly a judge isn't going to let us host a PDF of Harry Potter or whatever. If it ever came down to it I think there would just be a multi-pronged test, along the lines of the current test for fair use and securities law.
In the case of Harry Potter it's an exogenous work that was created and copyrighted outside of an email client, it has significant economic value on its own, and there would be substantial economic harm done from us hosting it. In the case of normal email conversations most of those factors wouldn't apply, especially since in many cases seeing how people interact with one another is more valuable that the content of any individual message.
Regardless, I paid my $6 to the library of congress to become a registered DMCA agent, so the copyright issue really doesn't apply unless we A) start ignoring DMCA takedown requests B) actively induce people to violate copyright.
There's no clear precedent. Clearly a judge isn't going to let us host a PDF of Harry Potter or whatever. If it ever came down to it I think there would just be a multi-pronged test, along the lines of the current test for fair use and securities law.
In the case of Harry Potter it's an exogenous work that was created and copyrighted outside of an email client, it has significant economic value on its own, and there would be substantial economic harm done from us hosting it. In the case of normal email conversations most of those factors wouldn't apply, especially since in many cases seeing how people interact with one another is more valuable that the content of any individual message.
Regardless, I paid my $6 to the library of congress to become a registered DMCA agent, so the copyright issue really doesn't apply unless we A) start ignoring DMCA takedown requests B) actively induce people to violate copyright.
You really, really, really need to get a lawyer, because this sounds like you're just spitballing here.
Again, IANAL. But copying in replies seems readily distinguishable from forwarding and publication.
But anyway, sorry about taking this down the legality path. It is a cool service that you're providing. And I would never argue that you're legally responsible for what users do. I'm just concerned about the abuse potential.
Maybe you could enable publication without explicit authorization only when all correspondents were registered users. That would encourage users to get their contacts to register, increasing your userbase.
But anyway, sorry about taking this down the legality path. It is a cool service that you're providing. And I would never argue that you're legally responsible for what users do. I'm just concerned about the abuse potential.
Maybe you could enable publication without explicit authorization only when all correspondents were registered users. That would encourage users to get their contacts to register, increasing your userbase.
Careful stating this so matter-of-factly. The law doesn't care about implementation details and implied copyright grants are tough to argue for. If I allow you to download a copyrighted work from my site it doesn't give you an implicit right to upload it to other people just because your browser has that feature.
Check out section A of http://nulawreview.org/extralegalrecent/do-not-forward-why-p....
Check out section A of http://nulawreview.org/extralegalrecent/do-not-forward-why-p....
Sending an email gives an implicit copyright license, but that license is related to how emails are normally understood to be used. It's not a total license to do anything with.
> The default must be requiring explicit permission from all participants
If you send me an e-mail, absent an NDA, I generally have permission to disclose it to third parties. If FWD:Everyone required permission from all participants, they would simply fall prey to FWD:Everyone2 who didn't.
If you send me an e-mail, absent an NDA, I generally have permission to disclose it to third parties. If FWD:Everyone required permission from all participants, they would simply fall prey to FWD:Everyone2 who didn't.
If you send me an e-mail, absent an NDA, I generally have permission to disclose it to third parties
While technically true, I remember the days when publishing private messages was considered heinously rude. We didn’t need disclaimers and contracts and legalese for everything, because people - even on the Internet - behaved like decent human beings.
While technically true, I remember the days when publishing private messages was considered heinously rude. We didn’t need disclaimers and contracts and legalese for everything, because people - even on the Internet - behaved like decent human beings.
I guess those were the days...
Before you use this service, I recommend to verify that it is legal in your jurisdiction to use this. E-mail, by default, is meant to be private (though the "private" aspect can be organization A plus customer X or organization A plus organization B or sysadmin logging the conversation and backing it up). If its meant to be public, there are mailing lists for that. And if GPG is used to encrypt the content, it for sure isn't meant to be shared!
Before you use this service, I recommend to verify that it is legal in your jurisdiction to use this. E-mail, by default, is meant to be private (though the "private" aspect can be organization A plus customer X or organization A plus organization B or sysadmin logging the conversation and backing it up). If its meant to be public, there are mailing lists for that. And if GPG is used to encrypt the content, it for sure isn't meant to be shared!
Yeah, I remember that from Usenet and mail-list etiquette.
From a GDPR perspective,sending an email gives the recipient the implicit permission to store and read the contents and metadata of the email, but not to transfer it to other parties (except the data processors that process the email) or publish it.
Does that mean I'm not allowed to forward emails you send me?
Hard to say, because the law is new. My guess is that it is legal as long as it is not in a professional/commercial context, or you remove my PII, or you have a clear and legitimate business reason, e.g. forwarding to a colleague within the company who is responsible for the subject matter.
Examples of illegal behavior would be publishing it, forwarding it to a marketer, or eg. for a recruiting agency forwarding to a company fir which I haven’t given permission.
Examples of illegal behavior would be publishing it, forwarding it to a marketer, or eg. for a recruiting agency forwarding to a company fir which I haven’t given permission.
Nobody is going to be able to give you a definitive answer because it hasn't been tested in the US in the context of copyright or in the EU under the GPDR.
My guess is that forwarding would be fine but publishing wouldn't (in the US) and that you as an end user don't have to worry about the GPDR.
My guess is that forwarding would be fine but publishing wouldn't (in the US) and that you as an end user don't have to worry about the GPDR.
You have permission to disclose it to 3rd parties, but reproducing and publishing the content is a different beast.
This is one of those cases where the CS logic of "If I can show one person I can show n people" doesn't apply.
This is one of those cases where the CS logic of "If I can show one person I can show n people" doesn't apply.
"If you send me an e-mail, absent an NDA, I generally have permission to disclose it to third parties."
Permission from whom? Certainly not from me.
Permission from whom? Certainly not from me.
I am surprised about this point of view. When I send mail to someone, I do it in the belief the recipient can discuss it with whomever they want, even in public. Its their mail not mine. Also helps people behave nicely over mail if this pov holds true.
Guys, this is obviously situation-dependent.
If I e-mail a support engineer who is helping a customer with a problem, I expect they may tell the customer everything I say.
If I e-mail a colleague saying I'm worried our new product isn't up to our usual quality standards, I expect them to share that with other insiders but not risk embarrassing the company by releasing it publicly.
If I e-mail HR asking if our medical insurance covers syphilis, I expect them to keep that private even from other insiders :)
If I e-mail a support engineer who is helping a customer with a problem, I expect they may tell the customer everything I say.
If I e-mail a colleague saying I'm worried our new product isn't up to our usual quality standards, I expect them to share that with other insiders but not risk embarrassing the company by releasing it publicly.
If I e-mail HR asking if our medical insurance covers syphilis, I expect them to keep that private even from other insiders :)
[deleted]
I had few people on my contact list sharing this pov a couple of decades ago. Hope they’re fine.
What about claims for public disclosure of private facts?
https://injury.findlaw.com/torts-and-personal-injuries/invas...
https://injury.findlaw.com/torts-and-personal-injuries/invas...
I really hope this does well (because I'd like to discover more interesting and useful content).
I've been on the home page a few times and haven't yet signed up.
My behavior on the homepage has been to click the "more example threads" button.
I'd guess that the thing that would make me more likely to sign up is to be able to see/discover more great threads before signing up. (Similar suggestions that people have given to twitter, i.e. provide max utility for logged out users so people who aren't yet converts can experience the magic. I think that might apply to your site)
Hope this helps and I'll look forward to seeing the site succeed!
Tl;Dr I'd personally be interested in seeing more cool threads on the homepage and perhaps displayed in a way that makes it easier to find ones that are particularly interesting to me, so that I can get "hooked" on the service.
(Makes me think of Chamath's talk, where he talked about facebook's magic moment being 7 friends in 10 days https://ryangum.com/chamath-palihapitiya-how-we-put-facebook... - I wonder if your magic moment is getting people to discover a thread that is both really useful or interesting to them and that they feel is secret/that they likely wouldn't have been able to find elsewhere on the internet)
I've been on the home page a few times and haven't yet signed up.
My behavior on the homepage has been to click the "more example threads" button.
I'd guess that the thing that would make me more likely to sign up is to be able to see/discover more great threads before signing up. (Similar suggestions that people have given to twitter, i.e. provide max utility for logged out users so people who aren't yet converts can experience the magic. I think that might apply to your site)
Hope this helps and I'll look forward to seeing the site succeed!
Tl;Dr I'd personally be interested in seeing more cool threads on the homepage and perhaps displayed in a way that makes it easier to find ones that are particularly interesting to me, so that I can get "hooked" on the service.
(Makes me think of Chamath's talk, where he talked about facebook's magic moment being 7 friends in 10 days https://ryangum.com/chamath-palihapitiya-how-we-put-facebook... - I wonder if your magic moment is getting people to discover a thread that is both really useful or interesting to them and that they feel is secret/that they likely wouldn't have been able to find elsewhere on the internet)
> I really hope this does well (because I'd like to discover more interesting and useful content).
Thanks! Expect to see more content in the near future.
And we definitely need to redo our front page and incorporate more cool content. It's a lot better than when we launched, but I feel like we haven't quite hit a level of professionalism that's reflective of the rest of the site.
We’re trying to avoid raising capital, so what we’re really looking for right now is a larger company (1,000+ employees) to adopt us for a year so that we can keep evolving the internal tooling and make sure it’s satisfying a real need. (If anyone is interested, send me an email.)
Thanks! Expect to see more content in the near future.
And we definitely need to redo our front page and incorporate more cool content. It's a lot better than when we launched, but I feel like we haven't quite hit a level of professionalism that's reflective of the rest of the site.
We’re trying to avoid raising capital, so what we’re really looking for right now is a larger company (1,000+ employees) to adopt us for a year so that we can keep evolving the internal tooling and make sure it’s satisfying a real need. (If anyone is interested, send me an email.)
Best of luck :)
If you want the old school Fortune 500 folks you should take aim at Sharepoint. It's still how this kind of thing (internal corporate blogging) gets done at big old corporate beasts.
Do you even have a sharepoint add-in?
Do you even have a sharepoint add-in?
Thanks for the advice. We've been talking with a couple Fortune 500 companies who are using Exchange and Sharepoint, so if we end up building out an enterprise deployment for them then we'll probably end up doing this. I don't want to start building out enterprise stuff though until we have a paying enterprise customer who is asking for specific things. The product is good enough for enterprise, the real issue is just making sure the upload process is aligned with the workflows of people within the company so that way the effort and cognitive overhead of contributing is low enough that lots of documentation gets created.
> - You can now anonymize any message contributor.
[...]
> - Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment.
This is a really an abuse of trust. When I send an email, I expect it to exist for a certain audience that's it. If I wanted it to be public, I would have posted it on a public forum. It's not up to the recipient to decide what should be done with my content. I'm the one that decides that. If you want to get legal about it, as the author, the copyright is mine, not the person I send it to.
Not only are you running afoul of privacy, and abuse issues, you're running afoul of legal issues.
This is a really abusive idea.
[...]
> - Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment.
This is a really an abuse of trust. When I send an email, I expect it to exist for a certain audience that's it. If I wanted it to be public, I would have posted it on a public forum. It's not up to the recipient to decide what should be done with my content. I'm the one that decides that. If you want to get legal about it, as the author, the copyright is mine, not the person I send it to.
Not only are you running afoul of privacy, and abuse issues, you're running afoul of legal issues.
This is a really abusive idea.
> If you want to get legal about it, as the author, the copyright is mine, not the person I send it to.
Are you sure about this? I doubt that communication can be copyrighted. Once you sent me your email, it's mine, not yours.
Otherwise email forwarding in general is completely illegal.
Are you sure about this? I doubt that communication can be copyrighted. Once you sent me your email, it's mine, not yours.
Otherwise email forwarding in general is completely illegal.
Disclaimer: IANAL. This comment is not a substitute for legal counsel.
"Are you sure about this? I doubt that communication can be copyrighted. Once you sent me your email, it's mine, not yours."
If you and the recipient both reside in countries which are signatory to the Berne Convention, then this is very much incorrect. Copyright is automatic, and goes to the author. The medium by which I distribute my copyrighted works does not somehow invalidate that automatic copyright.
"Otherwise email forwarding in general is completely illegal."
In a strict sense, yeah, probably. This is why the FSF and OSI don't consider programs without any license to be suitable for FOSS: in the absence of a license, most countries - thanks to the Berne Convention - assume no permission from the copyright holder at all by default unless otherwise established via a license agreement.
Of course, the average person is not going to start suing you for every email from said person you've forwarded without explicit permission; indeed, the average person probably won't know you've ever violated that implicit copyright at all if you're only forwarding it privately. That dynamic changes entirely, however, if you then go on and publish that email as part of a blog post.
"Are you sure about this? I doubt that communication can be copyrighted. Once you sent me your email, it's mine, not yours."
If you and the recipient both reside in countries which are signatory to the Berne Convention, then this is very much incorrect. Copyright is automatic, and goes to the author. The medium by which I distribute my copyrighted works does not somehow invalidate that automatic copyright.
"Otherwise email forwarding in general is completely illegal."
In a strict sense, yeah, probably. This is why the FSF and OSI don't consider programs without any license to be suitable for FOSS: in the absence of a license, most countries - thanks to the Berne Convention - assume no permission from the copyright holder at all by default unless otherwise established via a license agreement.
Of course, the average person is not going to start suing you for every email from said person you've forwarded without explicit permission; indeed, the average person probably won't know you've ever violated that implicit copyright at all if you're only forwarding it privately. That dynamic changes entirely, however, if you then go on and publish that email as part of a blog post.
This may depend on your jurisdiction but I'm 99% sure this isn't how things work in Germany.
First of all, the author retains ownership of the copyright. They can freely redistribute copies of what they have written unless they're subject to an active contract limiting their use of those rights (e.g. a time-limited exclusive license -- IANAL but AIUI there is no such thing as a permanent exclusive license unless you also get perpetually reimbursed).
So if you're sent a copyrighted work by its author, you may legitimately infer that you have the right to access it but you don't have the right to republish it or make copies accessible in any commercial way (like an ad-sponsored online platform).
Additionally communications are subject to privacy laws. So you may be in violation of the author's personal rights even if you publish their e-mails non-commercially because you violate their "reasonable expectation of privacy".
This is not entirely dissimilar to the case of "revenge porn" by the way: if you send your loved one an intimate picture for private use, you can not only ask that they destroy the picture at any point but they are also prohibited from publishing it without your approval. Of course in this case the violation of personal rights also stems from the fact the photo is a depiction of the author.
But if you really need a clear example, imagine you are sent the draft of the next Game of Thrones season (or what have you) by its author. Unless you have explicit permission, you have no reason to assume you would then be allowed to go on and publish that document. Even without an NDA there's likely a "reasonable expectation" you will treat it as confidential and you'd be in violation of that by passing it on.
Note that I'm talking about my understanding of German (and likely by extension EU) laws, not necessarily American laws. I'm well aware the US has different laws and I suspect those might vary on state level too.
First of all, the author retains ownership of the copyright. They can freely redistribute copies of what they have written unless they're subject to an active contract limiting their use of those rights (e.g. a time-limited exclusive license -- IANAL but AIUI there is no such thing as a permanent exclusive license unless you also get perpetually reimbursed).
So if you're sent a copyrighted work by its author, you may legitimately infer that you have the right to access it but you don't have the right to republish it or make copies accessible in any commercial way (like an ad-sponsored online platform).
Additionally communications are subject to privacy laws. So you may be in violation of the author's personal rights even if you publish their e-mails non-commercially because you violate their "reasonable expectation of privacy".
This is not entirely dissimilar to the case of "revenge porn" by the way: if you send your loved one an intimate picture for private use, you can not only ask that they destroy the picture at any point but they are also prohibited from publishing it without your approval. Of course in this case the violation of personal rights also stems from the fact the photo is a depiction of the author.
But if you really need a clear example, imagine you are sent the draft of the next Game of Thrones season (or what have you) by its author. Unless you have explicit permission, you have no reason to assume you would then be allowed to go on and publish that document. Even without an NDA there's likely a "reasonable expectation" you will treat it as confidential and you'd be in violation of that by passing it on.
Note that I'm talking about my understanding of German (and likely by extension EU) laws, not necessarily American laws. I'm well aware the US has different laws and I suspect those might vary on state level too.
I know US HN sometimes has a problem understanding consent and fair use, but those are essential if you want to intuit whether forwarding an e-mail is legal or not.
If you're not sure whether the author of an e-mail is okay with it being forwarded, maybe try asking them? If you don't think they'd allow you to (and there's no legal reason to ignore their wishes, e.g. to submit the e-mail as evidence of harassment), maybe you shouldn't?
If you're not sure whether the author of an e-mail is okay with it being forwarded, maybe try asking them? If you don't think they'd allow you to (and there's no legal reason to ignore their wishes, e.g. to submit the e-mail as evidence of harassment), maybe you shouldn't?
Yes it can, emails that are more than a few words meet all the criteria for a copyright protection. So it's a case where not every email is copyrighted but almost all non-trivial ones are.
"Once you sent me your email, it's mine, not yours."
"Once you let me download Star Wars, it's mine, not yours."
Email forwarding in general isn't illegal. There are plenty of times where you could forward an email where there are no issues of copyright. Like an autogenerated notification for example, that email wouldn't be copyrighted at all. On the flip side if I send you a copy of my book in an email you certainly don't have the right to forward it as that would be an unauthorized reproduction. The question is generally where certain types of personal and professional communication fall.
"Once you sent me your email, it's mine, not yours."
"Once you let me download Star Wars, it's mine, not yours."
Email forwarding in general isn't illegal. There are plenty of times where you could forward an email where there are no issues of copyright. Like an autogenerated notification for example, that email wouldn't be copyrighted at all. On the flip side if I send you a copy of my book in an email you certainly don't have the right to forward it as that would be an unauthorized reproduction. The question is generally where certain types of personal and professional communication fall.
Well... it is weird. I kinda like that.
I recall an app that (I want to say it was for Mac) that turned the trash into a recycle bin and actually "recycled" the content in the sense that files were then sent to other users to look at and if they took them out of the trash the file was gone for everyone else (as if it was a physical print out).
It was kinda neat... weird... probabbly a security nightmare... but interesting.
I recall an app that (I want to say it was for Mac) that turned the trash into a recycle bin and actually "recycled" the content in the sense that files were then sent to other users to look at and if they took them out of the trash the file was gone for everyone else (as if it was a physical print out).
It was kinda neat... weird... probabbly a security nightmare... but interesting.
The security story will definitely be better once we have the plugin, but it's already quite good. So under the current read-only OAuth model:
- Tokens can only be used from our servers, and their use is logged by both us and Google
- Tokens are rate limited on Google's end, both per user and per app.
Both of these combine to make any sort of large scale breach essentially impossible. We also don't access and store any email messages until you've already chosen to publish them, and even then they're stored encrypted unless they're publicly accessible. (E.g. the remain encrypted if not everyone gives permission or if you're publishing with a private repository.)
I filed a feature request ticket with Google asking them to log when an app accesses a full message, so that way we can prove that we aren't accessing any emails except the ones you choose you upload. So we'll see if that gets added.
We also have very extensive tests for everything privacy and security related on the back end, which helps.
The main thing to note is that we're explicitly not designed to be a platform for whistleblowers. One of the design decisions we made is to associate threads with email addresses rather than usernames. This is useful because it let's people give permission or anonymize themselves without first making an account, and then later have their threads associated with their account. Great for usability, but it also means that if you want to be an anonymous whistleblower there are other platforms that are better suited for that.
Anyway once we have the Gmail Add-on, that will make it so we only have read-only access to the currently active thread where you activate the add-on. It's only a couple weeks of work, right now I'm just hoping we can get Google to add a couple more API wrappers so that we don't need to write any new code to parse threads.
- Tokens can only be used from our servers, and their use is logged by both us and Google
- Tokens are rate limited on Google's end, both per user and per app.
Both of these combine to make any sort of large scale breach essentially impossible. We also don't access and store any email messages until you've already chosen to publish them, and even then they're stored encrypted unless they're publicly accessible. (E.g. the remain encrypted if not everyone gives permission or if you're publishing with a private repository.)
I filed a feature request ticket with Google asking them to log when an app accesses a full message, so that way we can prove that we aren't accessing any emails except the ones you choose you upload. So we'll see if that gets added.
We also have very extensive tests for everything privacy and security related on the back end, which helps.
The main thing to note is that we're explicitly not designed to be a platform for whistleblowers. One of the design decisions we made is to associate threads with email addresses rather than usernames. This is useful because it let's people give permission or anonymize themselves without first making an account, and then later have their threads associated with their account. Great for usability, but it also means that if you want to be an anonymous whistleblower there are other platforms that are better suited for that.
Anyway once we have the Gmail Add-on, that will make it so we only have read-only access to the currently active thread where you activate the add-on. It's only a couple weeks of work, right now I'm just hoping we can get Google to add a couple more API wrappers so that we don't need to write any new code to parse threads.
I would like a way to proactively opt out of your application/service, so that there is no chance you ever host an email thread I'm on. Do you provide some mechanism for this? Frankly, I'll take legal action if one of my emails ever ends up on your site.
If there’s a need for this we’ll build it. Right now we’ve had a bunch of people express concern about getting too many permission requests or about having emails they don’t want posted without their permission, but neither scenario has materialized yet.
The other option would be to have threads go live in X hours unless someone opts out. Right now our main goal is to have the permission options be clear, intuitive, and consistent so that people start to build up a mental model of how it works.
The other option would be to have threads go live in X hours unless someone opts out. Right now our main goal is to have the permission options be clear, intuitive, and consistent so that people start to build up a mental model of how it works.
"If there’s a need for this we’ll build it."
There's a need for this. Please build it.
"neither scenario has materialized yet."
Well yeah, it's a young product. Only a matter of time before it's abused.
"The other option would be to have threads go live in X hours unless someone opts out."
Substitute "hours" with "days" and I might be okay with this. "Hours" is way too short.
There's a need for this. Please build it.
"neither scenario has materialized yet."
Well yeah, it's a young product. Only a matter of time before it's abused.
"The other option would be to have threads go live in X hours unless someone opts out."
Substitute "hours" with "days" and I might be okay with this. "Hours" is way too short.
I’m really impressed by the email parsing success. How did you tackle the hellscape that is parsing replies out of emails?
Thanks! I didn't really understand all the email specs when I started working on the parser, so it was mostly written using guess and check.
For plaintext emails without forwards, we use a slightly modified version of Email Reply Parser to strip replies. We made a couple changes so that messages with inline replies aren't stripped.
The next step is running everything through through BeautifulSoup. We use this to strip out most of the garbage from the HTML and rewrite it to make it beautiful. For example, paragraph text within divs gets unwrapped and placed within paragraphs. And text within divs that's styled to look like blockquotes gets placed within actual blockquote elements. This is not only good for SEO, but makes it easy for us to normalize the typography and style across threads to create a consistent reading experience.
There's also some logic here for formatting emails from things like Zendesk and Mixmax correctly. And this is also where the highlighting and redaction get applied.
Right now we just unwrap text within tables and place it in paragraph elements, I need to change this algorithm a little though to allow actual tabular data.
The next step is running the text through Bleach, first to linkify any plaintext URLs (and sanitize URLs), and next to remove all the remaining markup and attributes we don't allow.
Then you enter the death field of regex. The algorithm we use to unwrap text within divs and tables creates some extra whitespace before and after the newly created elements, so when you have nested divs and tables some of this needs to be stripped. We also strip out semantically invalid markup and empty elements. E.g. there is a lot of stuff that looks vaguely like this:
body = body.replace('<li></ol>', '</ol>')
The last step is that we run everything through BeautifulSoup again to make sure the whole thing is idempotent. I hear this isn't the Computer Science approved method of guaranteeing idempotence, but in this case it works. (Basically there are just a couple cases where the regex can lead to having unbalanced tags, so we need to make sure it's valid markup again.)
Overall the whole process is pretty easy to read and understand, and it generally produces better results than Gmail so I'm pretty happy with it. If we were processing millions of emails per hour I'd probably put more work into making it more efficient, but for now it's fast enough to feel instantaneous even for threads with dozens of messages.
For plaintext emails without forwards, we use a slightly modified version of Email Reply Parser to strip replies. We made a couple changes so that messages with inline replies aren't stripped.
The next step is running everything through through BeautifulSoup. We use this to strip out most of the garbage from the HTML and rewrite it to make it beautiful. For example, paragraph text within divs gets unwrapped and placed within paragraphs. And text within divs that's styled to look like blockquotes gets placed within actual blockquote elements. This is not only good for SEO, but makes it easy for us to normalize the typography and style across threads to create a consistent reading experience.
There's also some logic here for formatting emails from things like Zendesk and Mixmax correctly. And this is also where the highlighting and redaction get applied.
Right now we just unwrap text within tables and place it in paragraph elements, I need to change this algorithm a little though to allow actual tabular data.
The next step is running the text through Bleach, first to linkify any plaintext URLs (and sanitize URLs), and next to remove all the remaining markup and attributes we don't allow.
Then you enter the death field of regex. The algorithm we use to unwrap text within divs and tables creates some extra whitespace before and after the newly created elements, so when you have nested divs and tables some of this needs to be stripped. We also strip out semantically invalid markup and empty elements. E.g. there is a lot of stuff that looks vaguely like this:
body = body.replace('<li></ol>', '</ol>')
The last step is that we run everything through BeautifulSoup again to make sure the whole thing is idempotent. I hear this isn't the Computer Science approved method of guaranteeing idempotence, but in this case it works. (Basically there are just a couple cases where the regex can lead to having unbalanced tags, so we need to make sure it's valid markup again.)
Overall the whole process is pretty easy to read and understand, and it generally produces better results than Gmail so I'm pretty happy with it. If we were processing millions of emails per hour I'd probably put more work into making it more efficient, but for now it's fast enough to feel instantaneous even for threads with dozens of messages.
Cool, much thanks for the detailed reply!
Certainly intriguing. I _really_ like the notion of automatically correlating and tagging work emails to internal business content, or wiki. Not sure about the "public" tracking side of the site.
Both of us come from situations where this product would have saved so much time and energy in a business setting. It really influenced our design of the org and repo features. Let us know if you have any questions or want to kick the tires in an organization setting.
[email protected]
[email protected]
I registered and verified my email address, and then tried to log in only to find it didn't accept my password. The "reset password" doesn't respond or do anything so I'm unable to log in or reset my password.
The reset password button should send an email, there just isn't currently a modal giving any indication that it did anything. The front end is currently in a feature freeze until we finish the React re-write, but then we'll fix this.
In general though there is no max length on the passwords and all characters are valid.
In general though there is no max length on the passwords and all characters are valid.
Please reach out to myself or Alex to get this worked out:
[email protected] [email protected]
[email protected] [email protected]
[deleted]
I'm sorry, but the idea of a product designed specifically to facilitate the mass redistribution of communications normally assumed to be private by default is deeply disturbing. Do I need to start including EULAs in every email I send? In what multiverse is this sort of thing okay?
Unless permission requests are mandatory and forever will be (regardless of anonymization), I will automatically refuse to communicate via email (and possibly any other implied-private medium, including one-to-one chats, mail, and SMS) with anyone I know to be using this service; instead, the only communications from me with these people will be through systems/services in which communications are already assumed to be public or shared (e.g. forums, mailing lists, public social media posts, blog posts / webpages, etc.). Likewise, I will never use this service myself; there are plenty of services out there that facilitate public-record written electronic communication while being upfront about it.
To reiterate: my emails to others should be considered private between myself and the recipient unless both of us explicitly consent to their publication, anonymized or otherwise. That's basic fucking courtesy - courtesy which FWD:Everyone seems to be explicitly designed to violate.
Unless permission requests are mandatory and forever will be (regardless of anonymization), I will automatically refuse to communicate via email (and possibly any other implied-private medium, including one-to-one chats, mail, and SMS) with anyone I know to be using this service; instead, the only communications from me with these people will be through systems/services in which communications are already assumed to be public or shared (e.g. forums, mailing lists, public social media posts, blog posts / webpages, etc.). Likewise, I will never use this service myself; there are plenty of services out there that facilitate public-record written electronic communication while being upfront about it.
To reiterate: my emails to others should be considered private between myself and the recipient unless both of us explicitly consent to their publication, anonymized or otherwise. That's basic fucking courtesy - courtesy which FWD:Everyone seems to be explicitly designed to violate.
It requires opt-in from all participants in the conversation, as Alex posted down this thread last week:
https://news.ycombinator.com/item?id=17401425
> We actually currently require double opt-in permission for each message contributor in a thread to share stuff publicly. That might change in the future, we're still playing around with the model.
And yes, it does violate basic expectations - that's on purpose.
https://news.ycombinator.com/item?id=17401425
> We actually currently require double opt-in permission for each message contributor in a thread to share stuff publicly. That might change in the future, we're still playing around with the model.
And yes, it does violate basic expectations - that's on purpose.
Per Alex's comment on this post (and, in fact, the current top comment):
"Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment."
It requires opt-in from all parties now, but there's already a publicized plan to change that.
"And yes, it does violate basic expectations - that's on purpose."
I'm not sure how "don't worry guys, we're intentionally building a product to facilitate the wholesale violation of decades-old email etiquette and common courtesy" is supposed to make this idea sound any less horrific.
"Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment."
It requires opt-in from all parties now, but there's already a publicized plan to change that.
"And yes, it does violate basic expectations - that's on purpose."
I'm not sure how "don't worry guys, we're intentionally building a product to facilitate the wholesale violation of decades-old email etiquette and common courtesy" is supposed to make this idea sound any less horrific.
So just to clarify, we're changing the product to make it possible to upload stuff without permission, but we're not trying to induce bad behavior.
E.g. Gmail has a reply all button and a forward button, but they don't encourage users to abuse them. They're just there for situations where it's (hopefully) appropriate, and they trust users to exercise good judgment. And for the most part it works, since there are only so many times you can abuse those features before people stop sending you emails.
There are many times when it's easy to get verbal permission from someone, but difficult or impossible to get email permission, e.g. if their email address has changed.
E.g. Gmail has a reply all button and a forward button, but they don't encourage users to abuse them. They're just there for situations where it's (hopefully) appropriate, and they trust users to exercise good judgment. And for the most part it works, since there are only so many times you can abuse those features before people stop sending you emails.
There are many times when it's easy to get verbal permission from someone, but difficult or impossible to get email permission, e.g. if their email address has changed.
"Gmail has a reply all button and a forward button"
Last I checked, neither of those buttons are designed to publish the whole conversation to the whole world via the World Wide Web. Your product is. Therefore:
"we're changing the product to make it possible to upload stuff without permission"
Then you're changing the product in a way that is absolutely unacceptable for privacy reasons.
"we're not trying to induce bad behavior"
I'm not trying to induce meth addiction; I'm just selling it and hoping it won't be abused.
"And for the most part it works, since there are only so many times you can abuse those features before people stop sending you emails."
Then you're missing the point: I want to minimize the potential for abuse to ever happen in the first place. Hence the ultimatum in my top-level comment: if I know someone is using this service, then I'm going to refuse to communicate with that person via implicitly/semantically-private channels (in fact, it'd be nice if there were some way to programmatically get a list of email addresses registered with this service so I can maintain a blacklist on my SMTP servers and prevent myself from sending anything to them by accident). I might waver from that if FWD:Everyone offers the ability to preemptively register my email address(es) in an "automatically deny permission" list.
"There are many times when it's easy to get verbal permission from someone, but difficult or impossible to get email permission, e.g. if their email address has changed."
Then that request for verbal permission should be along the lines of "hey, I want to post our conversation from a while back to FWD:Everyone; do you mind logging in real quick and approving it since the request probably went to your old email?". Even better if FWD:Everyone would keep track of who owns what emails and send requests to alternate emails if not approved in a certain amount of time.
Otherwise, tough beans. Just because Disney didn't respond to my email asking for permission to sell bootleg copies of Frozen on the black market (e.g. because I sent it to the wrong address or because it's obviously going to be a "no") doesn't mean I'm automatically allowed to do so.
In other words: if I'm unable to provide consent, then assume that I do not consent. Inconvenient, sure, but that ain't my problem.
Last I checked, neither of those buttons are designed to publish the whole conversation to the whole world via the World Wide Web. Your product is. Therefore:
"we're changing the product to make it possible to upload stuff without permission"
Then you're changing the product in a way that is absolutely unacceptable for privacy reasons.
"we're not trying to induce bad behavior"
I'm not trying to induce meth addiction; I'm just selling it and hoping it won't be abused.
"And for the most part it works, since there are only so many times you can abuse those features before people stop sending you emails."
Then you're missing the point: I want to minimize the potential for abuse to ever happen in the first place. Hence the ultimatum in my top-level comment: if I know someone is using this service, then I'm going to refuse to communicate with that person via implicitly/semantically-private channels (in fact, it'd be nice if there were some way to programmatically get a list of email addresses registered with this service so I can maintain a blacklist on my SMTP servers and prevent myself from sending anything to them by accident). I might waver from that if FWD:Everyone offers the ability to preemptively register my email address(es) in an "automatically deny permission" list.
"There are many times when it's easy to get verbal permission from someone, but difficult or impossible to get email permission, e.g. if their email address has changed."
Then that request for verbal permission should be along the lines of "hey, I want to post our conversation from a while back to FWD:Everyone; do you mind logging in real quick and approving it since the request probably went to your old email?". Even better if FWD:Everyone would keep track of who owns what emails and send requests to alternate emails if not approved in a certain amount of time.
Otherwise, tough beans. Just because Disney didn't respond to my email asking for permission to sell bootleg copies of Frozen on the black market (e.g. because I sent it to the wrong address or because it's obviously going to be a "no") doesn't mean I'm automatically allowed to do so.
In other words: if I'm unable to provide consent, then assume that I do not consent. Inconvenient, sure, but that ain't my problem.
[deleted]
The thing is, they could easily extract participants and require opt-in from all parties.
Sync my inbox? So basically, if you get hacked, all my emails are public. Or at the very least, an untrusted third party (you) gets to read everyone's private email?
No way I'll use it, nor allow anyone else I know to do so.
No way I'll use it, nor allow anyone else I know to do so.
Sadly you won't have any say in the latter.
I feel like this would be a good use case to use blockchain where the code would be public and your email messages could be encrypted.
There was an IOTA "random" wallet generator where they posted the codebase online, but they had additional code on the page that made the range of generated wallets really narrow. The owner eventually robbed everyone.
I'd still be skeptical.
I'd still be skeptical.
I actually thought it was a joke.
> * Less work than blogging, way more benefits
>
> * Build a community around your inbox
>
> * Only share the emails you intend to
It's just a fancy mailing list then? Minus the SMTP leg, plus privacy/consent issues and moving to a non-free storage format as well as concentrating the presence of the "thread" at one site.
The best email lore out there is saved to mailing list archives and can be linked to and shared just as easily. And mailing lists take "forwards" too.
It's just a fancy mailing list then? Minus the SMTP leg, plus privacy/consent issues and moving to a non-free storage format as well as concentrating the presence of the "thread" at one site.
The best email lore out there is saved to mailing list archives and can be linked to and shared just as easily. And mailing lists take "forwards" too.
> It's just a fancy mailing list then?
It's more of a social network built around email conversations. E.g. we make it easy to not only to leave comments and share on social, but also to embed threads within any other site.
Unlike email lists, we're also designed to make it easy to share great conversations after the fact, rather than having everyone copied on every message as it happens. I think one good use case for the site is sharing the best conversations from otherwise private mailing lists. (With everyone's permission, or if the list specifically allows it.)
> moving to a non-free storage format
If you look at the API response for our threads, it's actually much easier to parse than any archival format.
That said we're not (currently) an archival product; we don't store the original raw messages, and we don't output them into archival formats designed for longterm storage. I would like to integrate with some archival products in the future though. Right now when you donate your email archives to a university, they are only readable in the reading room of the university after signing an NDA with the librarian. I think we offer a good solution for making it easy to redact some of the more interesting threads and get them on the web, and I think a lot of that stuff would be super interesting.
It's more of a social network built around email conversations. E.g. we make it easy to not only to leave comments and share on social, but also to embed threads within any other site.
Unlike email lists, we're also designed to make it easy to share great conversations after the fact, rather than having everyone copied on every message as it happens. I think one good use case for the site is sharing the best conversations from otherwise private mailing lists. (With everyone's permission, or if the list specifically allows it.)
> moving to a non-free storage format
If you look at the API response for our threads, it's actually much easier to parse than any archival format.
That said we're not (currently) an archival product; we don't store the original raw messages, and we don't output them into archival formats designed for longterm storage. I would like to integrate with some archival products in the future though. Right now when you donate your email archives to a university, they are only readable in the reading room of the university after signing an NDA with the librarian. I think we offer a good solution for making it easy to redact some of the more interesting threads and get them on the web, and I think a lot of that stuff would be super interesting.
Might as well build a tool to blogify mailing list archives. If the list is private you can always publish the blog-form summary if you have the authority to do it. But there's no way to monetize that -- you have to provide much more than that, and centralize things in the process, in order to monetize.
For corporate customers who want to publish into an org, rather than the world, this service might actually be very valuable. For non-corporate uses this might make some sense, but for me... I'd not let a third party read my email.
For corporate customers who want to publish into an org, rather than the world, this service might actually be very valuable. For non-corporate uses this might make some sense, but for me... I'd not let a third party read my email.
I'm really struggling to find a good use for this.
Putting content in a blog post means the author thought the information was worth at least copying and pasting (and possibly even editing). A lot of blog posts aren't even worth the time reading the title. This is somehow less than that.
Putting content in a blog post means the author thought the information was worth at least copying and pasting (and possibly even editing). A lot of blog posts aren't even worth the time reading the title. This is somehow less than that.
[deleted]
Really thought this was some high-brow joke - nope! This is a real product/service to share your emails.
I think this is a truly terrible idea. But what do I know? google thought it was a good idea to have copies of the usernames/passwords for all the sites I visit stored on their servers. I think that's also a truly terrible idea - but they're a billion dollar company.
I would never use (to share) and I am doubtful I would find any thread between two other people worthwhile. But if they can find a paying userbase, mazel tov.
I think this is a truly terrible idea. But what do I know? google thought it was a good idea to have copies of the usernames/passwords for all the sites I visit stored on their servers. I think that's also a truly terrible idea - but they're a billion dollar company.
I would never use (to share) and I am doubtful I would find any thread between two other people worthwhile. But if they can find a paying userbase, mazel tov.
Interesting idea, but anything that wants to read my email is a big Nope.
No OAuth is needed to make an account. For most social sites (e.g. HN), 95% of the content comes from 5% of the users. We're not trying to be any different, beyond the fact that it's also a useful business tool.
Also, when our Gmail plugin gets released the OAuth story will be much better. Basically they have a scope that's read-only OAuth, but the plugin only gets access to the thread that's currently open when the user activates the plugin for that thread. That's exactly how it should work. There are still a couple features missing, we can build it without them but we're trying to work with Google to save some duplicated code on our backend.
Also, when our Gmail plugin gets released the OAuth story will be much better. Basically they have a scope that's read-only OAuth, but the plugin only gets access to the thread that's currently open when the user activates the plugin for that thread. That's exactly how it should work. There are still a couple features missing, we can build it without them but we're trying to work with Google to save some duplicated code on our backend.
Would be much easier and persuasive to the privacy-sensitive to provide an email address to send emails to and process them from there.
I think it would be better to use reddit or hn threads; using them as an outline for a blog post. I do that manually anyway.
Email would only be viable if it was a self hosted script. You're not getting access to my IMAP server. Duck that.
Email would only be viable if it was a self hosted script. You're not getting access to my IMAP server. Duck that.
Beyond the privacy concerns raised by others, I am not sure what this would amount to. Interesting conversations don't happen everyday, so this site might become just a collection of random email conversations that people submit that think is interesting. I am not sure if anyone wants to read them either.
Further, I don't think everything is "communityfiable". Like I said earlier, interesting conversations don't happen often, so stuff like following a person due to his one email upload or whatever, recommendations etc all seem a bit too much. Following would make sense if it is someone who uploads stuff often, but in this case anyone who does it would be breaching someone else's privacy unless the uploader is part of the conversation and everyone agrees to share it. But, again, as I said earlier, interesting conversations happen only once in a while.
That said, I remember how twitter was derided in the beginning as being a platform for people to share boring stuff that no one cares about, but it turned out to become something else, though not by design but only by chance, and is now quite successful.
Further, I don't think everything is "communityfiable". Like I said earlier, interesting conversations don't happen often, so stuff like following a person due to his one email upload or whatever, recommendations etc all seem a bit too much. Following would make sense if it is someone who uploads stuff often, but in this case anyone who does it would be breaching someone else's privacy unless the uploader is part of the conversation and everyone agrees to share it. But, again, as I said earlier, interesting conversations happen only once in a while.
That said, I remember how twitter was derided in the beginning as being a platform for people to share boring stuff that no one cares about, but it turned out to become something else, though not by design but only by chance, and is now quite successful.
These things sometimes evolve in unexpected ways, and sometimes it just takes a while for people to figure out how to really use something.
Use cases I think are especially compelling:
- Industry leaders who get asked the same questions a lot
- Professors and notable intellectuals who already give their email archives to a university when they die, and would like some of the accessible on the web.
- Politicians. Their emails are already published under FOIA, but I think it would be super useful to folks campaigning also.
- YouTubers, bloggers, Twitch folks, etc.
And then there are dozens of business use cases also for sharing stuff internally.
I’m sure there are lots of other uses beyond these though!
Use cases I think are especially compelling:
- Industry leaders who get asked the same questions a lot
- Professors and notable intellectuals who already give their email archives to a university when they die, and would like some of the accessible on the web.
- Politicians. Their emails are already published under FOIA, but I think it would be super useful to folks campaigning also.
- YouTubers, bloggers, Twitch folks, etc.
And then there are dozens of business use cases also for sharing stuff internally.
I’m sure there are lots of other uses beyond these though!
The last time I hit reply all by accident I lost my job.
What, did you call a client a Giraffe or something?
It was something like 'Giraffe', but rhymes with 'punt'.
Lesson I learned early in my career, luckily not on my own: never write something that you really don't want someone to see, especially bosses and clients and especially swearing.
Mails are replied to, mails are forwarded, long chains of emails happen, your stuff gets out.
A colleague at one of my first work places made fun of a client. 10-20 replies and forwards later, his mail was sent to a client. Luckily I think his message was buried too deep in the resulting mail and the client didn't see it.
I did, though, as did several people from my team. We didn't say anything but we all learned a lesson that day :)
Mails are replied to, mails are forwarded, long chains of emails happen, your stuff gets out.
A colleague at one of my first work places made fun of a client. 10-20 replies and forwards later, his mail was sent to a client. Luckily I think his message was buried too deep in the resulting mail and the client didn't see it.
I did, though, as did several people from my team. We didn't say anything but we all learned a lesson that day :)
This type of thing was always inevitable from the day top-posting became acceptable (and pretty much mandated by the email clients)
Before then, you would reply to points in line and trim unneeded information. The entire conversation wasn't bolted on to be ignored by 99% of people.
Before then, you would reply to points in line and trim unneeded information. The entire conversation wasn't bolted on to be ignored by 99% of people.
It would be harder, but still possible. The "trimmer" could keep the offensive bits in, causing even more damage because of the higher visibility.
Just don't write offensive stuff :)
Just don't write offensive stuff :)
Ahh this is such a great idea for a website!! Hope it takes off, it would be so great to see correspondences between professors or politicians.
Thank you! We hope so too. There's so much first hand knowledge locked up in inboxes that people would like to share.
Recently I've been thinking about writing a service which simply has an email address you forward an email to and it makes it publicly available via a URL - useful for things like open letters etc. I'm not sure if this is the same thing, or whether I should just go ahead and make it..
We used this at the editorial house I'm at to organize the editing pipeline. Super helpful when there are a bunch of people passing around different parts of a project over email. Really hope this succeeds.
I've been friends with the Alex duo for years now and I'm so impressed with how they've stuck with this core vision. Glad to see the engagement this is getting.
[deleted]
I signed up, but I cant figure out how to delete my fweveryone account- is that not an option?
You can use Postman or whatever to send a DELETE request to https://api.fwdeveryone.com/account with your authorization token, but it's not in the front end yet.
Alternatively just send us an email and I'll delete it.
Alternatively just send us an email and I'll delete it.
Thanks! I like the website, and probably will stick around. Was just curious about not having the delete option :)
This is a cool concept, have to think about all the good things I may have spread across years of random PST files or gmail accounts. Hopefully at least one in there!
One of the features we have is a naive suggestion engine. Upon signing up you can feed the app a list of keywords. These key words are used to surface relevant threads from your inbox.
You can see this in action in this video: https://youtu.be/MqbTUDCvYB8
You can see this in action in this video: https://youtu.be/MqbTUDCvYB8
So basically have Twitter expand its character limit and ask everyone to replace their emails with Twitter? How cool is that? :)
Quora and Reddit would serve essentially the same purpose for readers.
That fact that it's email makes it more likely for an accidental leak of personal information.
That fact that it's email makes it more likely for an accidental leak of personal information.
I joined up, how do I ask for accomodation advice for a week in London in August? Do I have the right idea of the app?
Other way around. If you have conversations in your inbox that you think would be interesting or useful to others, then you should post them! We have a suggestion engine though, so if you enter in your hobbies / interests / work projects into the relevant field on the settings page then we do a pretty good job of surfacing relevant threads. (At least as good as we can do just using metadata search, since we don't actually access anything in your inbox except the stuff you choose to upload.)
But yeah we have a bunch of travel advice like that, it's definitely fun to read.
But yeah we have a bunch of travel advice like that, it's definitely fun to read.
I don't use Gmail. Is there a way to forward an email as the name implies, or does it only work with Gmail?
Currently we rely on the gmail API, but it is on our roadmap to expand to the other major email providers. Is there one in particular that you would like to see on FWD:Everyone?
[deleted]
[deleted]
> We use OAuth to sync with your Gmail inbox so we’ll never ask for the password to your inbox.
Fuck. No.
If this is (and to be honest I didn't read it that closely) just about making a particular email public, why not just have an inbound address?
[email protected]
I'd actually consider using a service that did that.
Fuck. No.
If this is (and to be honest I didn't read it that closely) just about making a particular email public, why not just have an inbound address?
[email protected]
I'd actually consider using a service that did that.
> why not just have an inbound address?
We'd love to! Unfortunately going from just the last email in the thread to being able to reconstruct the entire thread would be exceedingly difficult.
Also, being able to use DKIM / SPF / DMARC / ARC to ensure the authenticity of conversations is very important to us. If you get a permission request from our site, we want you to be 100% confident that what you see when you preview the thread is going to be what you actually wrote, and that the uploader wasn't able to change the text at all. We support making redactions and anonymizing folks, but are strongly against people being able to change the text of what they or others wrote after the fact.
The whole magic of the site is being able to have the experience of looking over other people's shoulders into their inbox, and seeing how they actually talk with one another when they're not on stage. We're all for reducing friction, but we'd rather do it by just making a really slick Add-on so that we don't have to compromise on that core value.
As for the Gmail OAuth situation, I completely agree and have been raising awareness of this on HN since long before this became a big issue the other day. You can see my tickets requesting narrower OAuth scopes here:
https://issuetracker.google.com/issues?q=reporter:alex.krupp...
We'd love to! Unfortunately going from just the last email in the thread to being able to reconstruct the entire thread would be exceedingly difficult.
Also, being able to use DKIM / SPF / DMARC / ARC to ensure the authenticity of conversations is very important to us. If you get a permission request from our site, we want you to be 100% confident that what you see when you preview the thread is going to be what you actually wrote, and that the uploader wasn't able to change the text at all. We support making redactions and anonymizing folks, but are strongly against people being able to change the text of what they or others wrote after the fact.
The whole magic of the site is being able to have the experience of looking over other people's shoulders into their inbox, and seeing how they actually talk with one another when they're not on stage. We're all for reducing friction, but we'd rather do it by just making a really slick Add-on so that we don't have to compromise on that core value.
As for the Gmail OAuth situation, I completely agree and have been raising awareness of this on HN since long before this became a big issue the other day. You can see my tickets requesting narrower OAuth scopes here:
https://issuetracker.google.com/issues?q=reporter:alex.krupp...
> The whole magic of the site is being able to have the experience of looking over other people's shoulders into their inbox, and seeing how they actually talk with one another when they're not on stage.
I am having a hard time understanding if this is written sincerely or as satire.
I hope you are being humorous here because if this is indeed true, it does not look like something I would appreciate. I really don't want anyone to have the experience of looking over my shoulders into my inbox to see how I actually talk with others when I am not on stage.
I have always perceived email as a private mode of communication. Has this perception changed recently among the new generation of application developers?
I am having a hard time understanding if this is written sincerely or as satire.
I hope you are being humorous here because if this is indeed true, it does not look like something I would appreciate. I really don't want anyone to have the experience of looking over my shoulders into my inbox to see how I actually talk with others when I am not on stage.
I have always perceived email as a private mode of communication. Has this perception changed recently among the new generation of application developers?
I feel like everyone here is misinterpreting what the author meant. The site doesn't publish your messages without consent. In fact, from their FAQ:
> When uploading a thread as an individual, we email a permission request to each non-anonymized person who contributed at least one message to conversation. A thread will only go live if there is unanimous consent. This means that if even one person hits 'Decline' or doesn't respond to the permission request, the thread will remain private.
> When uploading a thread as an individual, we email a permission request to each non-anonymized person who contributed at least one message to conversation. A thread will only go live if there is unanimous consent. This means that if even one person hits 'Decline' or doesn't respond to the permission request, the thread will remain private.
"Permission requests are becoming optional": https://news.ycombinator.com/item?id=17460708
"Unfortunately going from just the last email in the thread to being able to reconstruct the entire thread would be exceedingly difficult."
Good. That's the way it should be.
"The whole magic of the site is being able to have the experience of looking over other people's shoulders into their inbox, and seeing how they actually talk with one another when they're not on stage."
What you call "magic" is a blatant and disgusting violation of my privacy. Those messages are "not on stage" for a reason; if I wanted them to be "on stage", then I would put them there myself. You have no business "looking over [my] shoulder" at all, let alone inviting everyone else in the world to do so.
Good. That's the way it should be.
"The whole magic of the site is being able to have the experience of looking over other people's shoulders into their inbox, and seeing how they actually talk with one another when they're not on stage."
What you call "magic" is a blatant and disgusting violation of my privacy. Those messages are "not on stage" for a reason; if I wanted them to be "on stage", then I would put them there myself. You have no business "looking over [my] shoulder" at all, let alone inviting everyone else in the world to do so.
> Also, being able to use DKIM / SPF / DMARC / ARC to ensure the authenticity of conversations is very important to us.
Are you sure you have really tried? when you forward an email, it includes all the headers you need to for your validations.
Are you sure you have really tried? when you forward an email, it includes all the headers you need to for your validations.
I'm pretty sure most mail clients will not directly include any of the headers from the original e-mail, unless you do "forward as attachment"
[deleted]
It only includes the headers of the last email in the thread. But that doesn't guarantee that the person forwarding the email hasn't changed what someone else wrote in the quoted reply text. To me that's actually a serious security issue, and in the long term is more serious than the OAuth thing (which I'm confident that Google will eventually fix).
If I'm wrong and it's possible to do then by all means I'll do it though. The one approach that would work is building an InboxSDK plugin and having it forward every message in a thread automatically, because that way you'd have the header of each message. But then the security story is arguably much worse than OAuth.
If I'm wrong and it's possible to do then by all means I'll do it though. The one approach that would work is building an InboxSDK plugin and having it forward every message in a thread automatically, because that way you'd have the header of each message. But then the security story is arguably much worse than OAuth.
I don't believe that is correct. If you check the email source, it includes all the emails with their headers.
What email client are you using? In Gmail the only thing I see between quoted replies are blocks like:
--000000000000061f91056a2a279c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
--000000000000061f91056a2a279c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
They want that juicy juicy inbox data. Nope. Nope. Nope.
This, just as we find out that sometimes, authorized "apps" are just proxies for mechanical turks, and people's eyes are reading your messages. [0]
[0] https://news.ycombinator.com/item?id=17446459
[0] https://news.ycombinator.com/item?id=17446459
Agreed 100%. The premise of this service is already sketchy enough as-is; in light of the neverending parade of seemingly-benign "services" that eventually turn around and sell out their users to advertising agencies and the like, I have precisely zero reason to trust that FWD:Everyone will be any different in that regard.
I initially thought this was satire based on 3rd party apps reading your email
[deleted]
Four wheel drive? WTH? Can you please offer a ..... :(
Very cool product! Will follow this and I hope it is successful.
I sure hope they aren't. This is terrifying, from a privacy perspective.
True, but only because it is OAuth. I like the overall concept if I don't have to share access to my inbox. Better if it was via forwarding to a specific address.
We are actively working on a gmail add-on which would allow you to not give us access to your inbox, rather, publish single threads to the site through the gmail interface. We have a few tickets open with Google to narrow the scope of the permissions available to us for exactly that reason! :)
It blows my mind that people are having "Group Chat" conversations like that via Email. Have they never heard of WhatsApp?
Email is much better for longer, well thought out replies and keeping track of multiple threads of conversation, each of which may have no activity for days at a time. Whatsapp is fairly limited to quick, short replies (mostly because of interface restrictions). Even chat-like email threads have much longer messages interspersed than what you would see on WhatsApp. Email also has much better tools for finding old messages than WhatsApp
- 99%+ of non-commercial email threads now parse correctly, better than Gmail in most cases. E.g. check out the inline reply parsing here: https://www.fwdeveryone.com/t/Gb8CYKvGS6uFSXdb_hwiTA/blog-po...
- We now support oEmbed, so you can embed email directly within Reddit and Medium posts. And also within Confluence, your own site / blog, and hundreds of other places. C.f.: https://www.reddit.com/r/nyc/comments/87a7my/restaurants_wor...
- The site now works really well on mobile and tablet.
- We've added organizations. Organizations can have public and private repositories. When publishing email to a public repository, by default permission request emails only go out to non-members of the organization. (And permission is never required to publish stuff to a private repository.)
- You can now anonymize any message contributor. Anonymized message contributors don't receive permission requests. Users can later anonymize or de-anonymize themselves at any point. (This works even if message contributors haven't yet created an account.)
- Threads are now SEO optimized. We basically take all the incoming garbage HTML that is modern email, and output it as really clean and minimalist HTML. (This also ensures that the redaction feature never breaks.)
- We now have pretty decent video tutorials: https://www.youtube.com/watch?v=Zwh9TJWoG6k&list=PLJAEYmnEjI...
- Users and organizations now have RSS feeds of their email, e.g.: https://api.fwdeveryone.com/user/inbox.atom?username=alex391...
- Lots of recirc features, e.g. trending threads.
New features in the pipeline:
- Permission requests are becoming optional, at least for now. Previously we required permission for all non-anonymized message contributors, now there will be an option to publish stuff immediately and let people anonymize themselves later if they want. If this is excessively abused we'll re-evaluate this, but we've tried to build things to incentivize good judgment.
- The front end is being completely re-written in React. Right now the front end loads in about 800ms, we're hoping to get it down to half that or less. (In comparison, the oEmbed loads in 80 - 130ms, hard to get much better without changing the speed of light.)
- We're building a Gmail plug-in. This will allow people to publish directly from their Gmail, and it won't require read-only access to the user's entire inbox. (Even though our privacy policy is very good!)
When we built the site we knew that no one needs or is looking for a new social network, so we figured that we aren't going to get many sign ups until people have read at least 100 really good threads on the site. We're not quite there yet, in terms of having enough content and traction for this to be a real business yet, but we're trending in the right direction and I'm hopeful we'll be close by the end of the year.
But yeah, overall we're basically just trying to make the Internet fun and weird again, the way I remember it when I was a kid but with a more modern twist. And also a real business model, no BS advertising, ever.
Also, for all the stuff that gets published about how addictive social networks are, try actually building one; nothing is more addictive (or inspiring) than a blank page.