facebook backfeed via email notifications

[snarfed]

this is a kinda crazy, somewhat dangerous, generally inadvisable idea that we almost certainly shouldn't do...at least, not as a public facing service for everyone. 😎

@chrisaldrich had the interesting idea yesterday that since facebook sends email notifications for comments, likes, etc. i tried it, and i was surprised to find that they send email for individual likes, shares, etc as well as comments, and the comment emails include the full contents!

relevant part of the HTML email contents:

<a style="text-decoration:none;color:#3b5998" href="https://www.facebook.com/nd/?snarfed.org&aref=...&medium=email&mid=...&bcode=...&n_m=...%40ryanb.org">Ryan Barrett
</a> commented on the
<a href="https://www.facebook.com/nd/?permalink.php&story_fbid=1654822044842700&id=100009447618341&comment_id=2253353148322917&aref=...&medium=email&mid=...&bcode=...&n_m=...%40ryanb.org" style="text-decoration:none;color:#3b5998">link
</a> you shared.

looks like i can get the commenter's profile URL, the comment URL, and the post URL out of that.

hmm...

[snarfed]

the key problem with this is that users would have to add a bridgy-owned email to their facebook account, and i believe make it the primary email, which would give me the ability to password reset, etc, and log in as them. that's pretty much unacceptable.

[snarfed]

i'm doing a sweep and closing issues that i don't plan to do myself or accept a PR for. apologies for the bad news, or if this is a surprise. feel free to reopen if you feel strongly.

[grantcodes]

Not necessarily a good idea, but I don't think it's too complicated for most people to set up email forwarding, so they could theoretically set up any email from facebook.com to get forwarded to a bridgy address.

I'm not sure if that would avoid the password reset issue as bridgy would probably still receive the emails, but the user would receive the email to their account too.

Also potentially interesting for other silos too, as bridgy could easily map the user email address to their url and figure out what the email means.

[snarfed]

thanks @grantcodes!

i could come up with gmail, sieve, etc email filters for people to install that would forward all facebook emails except password resets. or maybe only notification emails. still seems iffy security wise, and awful UX, but...meh?

quick poll time. hey @aaronpk @chrisaldrich @jgmac1106 @grantcodes @dshanske @tantek and others: if you could get facebook backfeed again by setting up an email filter like this, but it'd be somewhat sketchy security wise (discussion above), and might be inconsistent and incomplete, and the bridgy UI might be weak or nonexistent...would you do it? feel free to emoji respond 👍 for yes, 👎 for no. also feel free to @-mention anyone else who might vote.

[chrisaldrich]

I should have outlined this originally... Likely safer (for Bridgy and the end user) would be to follow the model of posting to WordPress via email (or services like Reading.am which allow posting to it via custom email addresses). Bridgy could provide users with a private hashed email address like 123xyzABC@brid.gy which could be linked to their particular account to which they could manually (or automatically) forward the relevant Facebook notification emails. Upon receipt, Bridgy would know which account sent it and could also match it to the user's post URL as a check before sending the appropriate webmentions.

This would leave Bridgy free from being the potential source for security leaks and put the onus on the end user. You'd naturally need to have the ability to reset/change the user's hash in the case that they accidentally allowed their custom email address to leak, although generally this isn't a huge issue as emails which don't match the user's account/endpoints would be dropped and not send webmentions in any case. (In some sense it's roughly equivalent to my being able to visit https://brid.gy/twitter/schnarfed and clicking on the Poll now or Crawl now buttons. It's doable, but doesn't give a bad actor much. You'd probably want to rate limit incoming emails to prevent against mass spam or DDoS sort of attacks against Bridgy.)

A side benefit of all of this is that those who have kept their old email notifications could relatively easily get much of their past missing back feed as well. Or if they're missing back feed for some reason, they could easily get it by re-sending the relevant emails instead of some of the current manual methods. Perhaps allowing preformatted emails with those same manual methods could be used to do back feed for Facebook or other providers as well?

We could also put together some forwarding filters for common platforms like gmail to help people set up autoforwarders with appropriate keywords/data to cut down on the amount of false positive or password containing emails being sent to Bridgy.

The one potential privacy issue to consider(?) is that this set up may mean that Bridgy could be sending webmentions for private messages since users get both private and public message notifications whereas the API distinguished these in the past. To remedy this, the comment URL could be tested to see if/how it renders as a test for public/private prior to sending. Separately, since Bridgy doesn't need to store or show these messages (for long?), private messages could be sent, but potentially with a payload that allows the receiving end to mark them as private (or to be moderated to use WordPress terminology). This would allow the user's website to receive the notifications and give them the decision to show or not show them, though this may be a potential moral gray area as they could choose to show responses that the originator meant to be private communication. The API would have prevented this in the past, but this email method could potentially route around that.

(Originally published at https://boffosocko.com/2019/04/28/55750290/)

[aaronpk]

quick poll response without catching up on the full thread:

1. I generally trust bridgy to not abuse its access to things I authorize it
2. when I don't trust an app to access my email, I will go into gmail and set up a forwarding rule to send specific emails to a forwarding address so that I know it can only see those things
3. with those two things in mind, I would gladly authorize bridgy to read my emails and look at only the facebook ones, but would also gladly set up a forwarding rule to send facebook notifications to a special address

[snarfed]

thanks guys! tentatively reopening.

Bridgy could provide users with a private hashed email address like 123xyzABC@brid.gy which could be linked to their particular account to which they could manually (or automatically) forward the relevant Facebook notification emails.

yup! i expected i'd need to use account-specific, secret email addresses like this to protect against spoofed notification emails.

Bridgy could be sending webmentions for private messages since users get both private and public message notifications whereas the API distinguished these in the past. To remedy this, the comment URL could be tested to see if/how it renders as a test for public/private prior to sending.

ugh, true. worse, "could be tested" means i'd have to scrape, which...bleh.

private messages could be sent...though this may be a potential moral gray area as they could choose to show responses that the originator meant to be private communication.

right. you'd need the responder's permission too, which is why bridgy has generally drawn a hard line on backfeeding only fully public responses.

[snarfed]

ugh, true. worse, "could be tested" means i'd have to scrape, which...bleh.

looking at this example post, here's the bit of HTML for the audience indicator. it looks more or less usable. (sigh.)

<a class="uiStreamPrivacy inlineBlock fbStreamPrivacy fbPrivacyAudienceIndicator _5pcq"
   aria-label="Shared with: Public" href="#" role="button" data-hover="tooltip"
   id="u_0_o" data-tooltip-content="Shared with: Public">
  <i class="lock img sp_-... sx_..."></i>
</a>

[snarfed]

rough, in progress task breakdown for if we try to do this:

• docs for which FB notification emails to turn on
• email filter that matches only FB notification emails and forwards them
• new FacebookEmail source with per-user email addresses: [TOKEN]@brid-gy.appspotmail.com
  • what's short name? facebook-email? fb-email?
  • new email feature?
• new model for storing notification emails themselves
• notification email HTML parser
• new mf2 handler that renders from stored notification emails
• handler to receive emails (API docs)
  • fetch FB post on web, scrape, check that it's public
  • create Response, insert propagate task

create accounts and email addrs manually for now.

open questions:

• do i put any of this in granary? or just make a fake GR_CLASS?
• still probably need OPD. so do we still poll, and do just OPD in it, no actual silo polling?

[aaronpk]

Just remembered this other relevant detail... Google now requires a security review in order to get access to the email API.

https://cloud.google.com/blog/products/g-suite/elevating-user-trust-in-our-api-ecosystems

Part of the review is hiring an outside consultant to do an audit, which has an expected cost of "$15,000 to $75,000 (or more)". So I say scrap the API plan and just do the forwarding rule version.

Gmail does require verification of the forwarding address before you can add the rule, so Bridgy will also need to provide a minimal "inbox" at the forwarding address so that the user can see the confirmation email Google sends and click the link there to confirm it.