Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

facebook backfeed via email notifications (unlikely) #854

Open
snarfed opened this issue Dec 14, 2018 · 10 comments

Comments

Projects
None yet
4 participants
@snarfed
Copy link
Owner

commented Dec 14, 2018

this is a kinda crazy, somewhat dangerous, generally inadvisable idea that we almost certainly shouldn't do...at least, not as a service. 馃槑

@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!

fb_email_comment

fb_email_like

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 snarfed added the listen label Dec 14, 2018

@snarfed snarfed changed the title facebook backfeed via email notifications facebook backfeed via email notifications (unlikely) Jan 11, 2019

@snarfed

This comment has been minimized.

Copy link
Owner Author

commented Jan 15, 2019

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 snarfed added the speculative label Jan 15, 2019

@snarfed

This comment has been minimized.

Copy link
Owner Author

commented Jan 15, 2019

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.

@snarfed snarfed closed this Jan 15, 2019

@grantcodes

This comment has been minimized.

Copy link

commented Apr 28, 2019

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 28, 2019

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

This comment has been minimized.

Copy link

commented Apr 29, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 29, 2019

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

This comment has been minimized.

Copy link
Owner Author

commented Apr 30, 2019

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 snarfed reopened this Apr 30, 2019

@snarfed

This comment has been minimized.

Copy link
Owner Author

commented Apr 30, 2019

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

This comment has been minimized.

Copy link
Owner Author

commented May 1, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 1, 2019

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.

snarfed added a commit that referenced this issue May 24, 2019

snarfed added a commit that referenced this issue May 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.