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.

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.

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.

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.

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 [email protected] 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/)

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

thanks guys! tentatively reopening.

Bridgy could provide users with a private hashed email address like [email protected] 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.

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>

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?

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.

ok all, this is ready for beta testers! let me know if you're interested.

I'm interested

@xavierroy great! grab me on IRC or email and i can set you up.

• turn on facebook email notifications: https://www.facebook.com/settings?tab=notifications&section=email&view
• see emails facebook has sent to you in the last 2 days (click on Other Emails; i think this includes notifications): https://www.facebook.com/settings?tab=security&section=recent_emails&view
• email notifications help: https://www.facebook.com/help/530847210446227/

@snarfed I've enabled them. What next?

@xavierroy great! like i mentioned, next step is to talk to me on IRC or email or somewhere else private. i need to send you your secret email address to forward notifications to.

first confirmed backfed comment! yay. https://xavierroy.com/2019/07/05/weekend-plans/#comment-3021

I'm certainly interested in trying this.

@chrismaverick sure! have you used bridgy before? I'm happy to have more beta testers, but this won't be the best entry point if you're new to the service.

@snarfed Thanks!

I actually have been playing with IndieWeb and Bridgy yesterday today as a replacement for NextScripts SNAP (SOOOOO many issues) which I used as a replacement for AddLinkToFacebook, which fell apart after Cambrige Analytica.

I have a couple different sites, my personal blog (chrismaverick.com where I'd be testing it for now) and my podcast (voxpopcast.com, where I'll be holding off until I'm satisfied). I've got over 25 years of software dev and design experience... I'm not worried about a little learning curve growing pains if you don't mind having me.

@chrismaverick sure! sounds good. I'm on vacation without my computer right now, but i can set you up when I'm back in a week.

@snarfed sent you email

Out of curiosity, did anyone else have a problem getting email notifications turned on from FB? That is, I'm not having a problem with the bridgy at all (yet) because for some reason even though I have enabled all FB email notifications, it doesn't seem to actually email me any of them. I get the push notifications but not the emails. Which sort of makes it impossible to forward anything because I have nothing to forward. Was that an issue for anyone else?

(note, they're not being spam collected or anything. According to https://www.facebook.com/settings?tab=security&section=recent_emails&view I'm not being sent any)

@chrismaverick sigh, yes, i had the exact same problem with my own facebook account. i never managed to solve it; i ended up using a different test account to get any notification emails.

(also props for finding that recent emails page! it was definitely useful for debugging.)

adoption of this has been underwhelming. one big cause may be that facebook is flaky and unreliable at actually sending email notifications, especially if you've turned them off before. see above.

bridgy hasn't received a forwarded FB email notification for over two months now. given that, i may turn this off entirely soon.

I've never gotten it to work. I even went as far as turning on ALL facebook notifications... which is 1) annoying and 2) literally sends me everything EXCEPT the one thing I care about in order to use this.

Looks like i was the only successful backfeeder. And would you know it, today I shared something on FB after a long while. FB email notifications are a bit finicky and they seem to work only when certain celestial stars are in the same line.

But it was a good effort and I guess we can shut down this experiment.

frustrating because this shouldn't be that hard except that FB makes it hard. We shouldn't even need to backfeed through email. The API is capable of handing comment over... and it used to until the Cambridge Analytica nonsense... (and still does for pages... just not personal accounts). But they turned it off for "security" after that... which is dumb, because that's not what the CA problem ever was.... if a post is publicly available, and the comments are public, there's no security issue with just copying it... I could do it manually with a crawler... it's just that that's gross.

agreed on all counts. i share your frustration!

i actually wrote that crawler you mentioned, a bit ago. www.facebook.com uses JS, so crawling that is hard, but m.facebook.com (with a logged in session cookie) is pure HTML and eminently scrapeable, and has all the comments, likes, and reactions we want. plus, i already had experience scraping in https://facebook-atom.appspot.com/ . so, i added it to granary, with the hope of eventually using it in bridgy:

https://github.com/snarfed/granary/blob/1cb18202bfd9e0ef4e8380ad6bbfc8530d94964f/granary/facebook.py#L1821-L2046

sadly, FB's bot detection caught me pretty quickly as soon as i started trying this in bulk. i tried rotating IPs, different User-Agents, and all sorts of other browser and HTTP fingerprints they might be triggering on, but never got it working consistently. they obviously have more resources for that arms race than me. 😎

so, having exhausted three different approaches - API, email, scraping - i think it's time to throw in the towel. i'm open to other ideas though!

oddly enough... I literally just got three FB comment email notifications in the last couple minutes. I have no idea why. They're not linked to a blog post and I'm not home right now to try testing.... but I may have to play with it again later. Clearly... THEY'RE WATCHING!!!

no usage for almost 3 mos, so i'm planning to turn this off. let me know if you're about to start using it again!