Open fredvd opened 6 years ago
hvelarde
commented
6 years ago I don't understand, the facebook_app_id field is not required and is not hardcoded in the template; it's only displayed if filled:
what's exactly what we shouldn't be including to obey GDPR?
fredvd
commented
6 years ago @hvelarde It's the condition on the link.pt template for the facebook plugin that has a hardcoded check on an existing app_id. The link.pt template is used when 'no tracking' is activated in the control panel.
hvelarde
commented
6 years ago I see; I don't remember why @keul implemented that way in #54, but I found a couple of sites that generate code that could be used for this:
seems easy to fix; isn't it? :)
keul
commented
6 years ago @fredvd @hvelarde sorry, it was ages ago... I really don't remember why! 😕 Maybe it's simply a mistake or something changed from FB side?
Sorry!
With the upcoming GDPR deadline in Europe I have been checking if we can activate the 'disable tracking' feature of sc.social.like. Most buttons work, but the facebook plugin in sc.social.like requires a facebook app_id , it's hard coded in the template.
Facebook really really doesn't want you to use anything other than their javascript tracking enabled SDK, but there is https://www.facebook.com/sharer/sharer.php, which seems to have been deprecated/disabled in the past, but works (again?). I've created a quick demo fix to use sharer.php if no tracking is enabled and no fb appid is available at https://github.com/zestsoftware/sc.social.like
It's not a like button as we had before but a share button, but it works for now as a quick solution to conform to some privacy guidelines organisations are setting up now due to GDPR.
There's https://github.com/collective/sc.social.like/issues/117 which suggests that the facebook js integration in sc.social.like still needs to be updated, correct?
The problem with 'just get an app_id' is that for websites you don't have a logical app and some organisations website and facebook management are separate departments without technical knowledge. (Also facebook itself writes you don't need an app_id for websites, but that's with their js sdk, chicken and egg :-P )
Long term:
For other solutions, another direction privacy focuessed websites have taken is to 'wrap' the javascript SDK's of the different social media platforms in of 'disable/enable' toggle. The german publisher Heise online experimented first with https://github.com/panzi/SocialSharePrivacy (fork) but outdated, Heise's current solution for this 2 step activation is https://github.com/heiseonline/shariff . For which also a Plone add'on has been made at https://github.com/collective/collective.shariff/ , but is not updated to the latest shariff js bundle.
I guess this kind of wrapping is more fragile and you have to follow up very quickly if one of the supported social media platforms changes their javascript code and/or policies again (and again), but if you can depend on an external well maintained project like shariff, could this be more functional no tracking alternative to also support? sc.social.like does much more than just showing the social media buttons (like opengraph metadata, CT selection, image handling) and would like to keep that integration.