[patrickyeon]

This is breaking some links. You might believe it "shouldn't", and a server "should" ignore the added params, but the reality is it's breaking them. This past weekend, I posted a link to an image on Facebook, and FB generated the preview fine, but created a link that 404's.

My link: https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg

Facebook made: https://pbs.twimg.com/media/Byv5uWSIIAEf38C.jpg?fbclid=IwAR2...

I guess if FB really wants, they could make a second fetch to ensure that their added params don't break the third party server. Or could they add a whitelist of domains that use their first-party tracking?

I really don't like the end result right now, looking like "the web works" from inside FB, but not when you try to follow this link out of it. I don't believe at all that that is FB's intent here, but it's just one more time that some silo breaks another part of the ecosystem, and to an untrained eye it looks like the third party is the culprit.

[mtkd]

I had a quick look at the protocol but couldn't see anything on handling that case

Regardless of the protocol - it's not unreasonable to return a 422 or 403 by default for that (malformed) request when first seen - as it would indicate that something sketchy may be going on - which can be whitelisted later

[basch]

I believe it was breaking all NYMag links today, appears fixed on NYMags end now.

https://www.facebook.com/NewYorkMag

[patrickyeon]

Sure, where "fixed on NYMags end" means "NYMags has implemented a workaround because FB broke things".

[lousken]

it also broke a couple of safe paste sites for me, that's /r/assholedesign