FWD:Everyone
31–40 of 143 posts
Re: FWD:Everyone
#32Earlier quoted context omitted.
> 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 pre…
> 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.
Re: FWD:Everyone
#33Thanks for submitting this, I was surprised to load HN and see it here. I've been meaning to do a proper update on what we've been up to for a while, but basically things that we've done since launching: - 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 supp…
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.
Re: FWD:Everyone
#34Earlier quoted context omitted.
> 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 i…
> 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-i…
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
Re: FWD:Everyone
#35Earlier quoted context omitted.
> 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 i…
> 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-i…
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.
Re: FWD:Everyone
#36Earlier quoted context omitted.
> 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.
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"
Re: FWD:Everyone
#37Earlier quoted context omitted.
> 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.
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 th…
Re: FWD:Everyone
#38Earlier quoted context omitted.
> 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-i…
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
Edit: Perhaps there's now legitimate public interest for most everything about him. But maybe some Apple-related stuff is still off limits.
Re: FWD:Everyone
#39Earlier quoted context omitted.
> - 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…
> 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.
https://injury.findlaw.com/torts-and-personal-injuries/invas...
Re: FWD:Everyone
#40Thanks for submitting this, I was surprised to load HN and see it here. I've been meaning to do a proper update on what we've been up to for a while, but basically things that we've done since launching: - 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 supp…
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 intere…
- 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.