Well, I’m glad this has been happening as well. Though my day-job involves information security, I’ll admit to having let others pick up the load on GDPR as our organisation is pretty well governed in regard to privacy. But I really hadn’t grasped the range and depth of issues it would raise until this thread.
It will be a “fun” year while all of this sorts itself out.
Regarding the Tweet internal shortcode. It uses the oEmbed endpoint pretty much like Instagram.
Also I discovered that Twitter offers publishers a way to opt-out from having their websites used for personalization. See here.
But that doesn’t really mean anything. As soon as the Twitter library widgets.js is executed platform.twitter.com sets a total of 13 cookies (with a 2 year expiration date) and 2 persistent Local Storage keys in a visitor’s browser.
Again no way to turn this tracking off unless the Tweet internal Hugo shortcode is rebuilt from scratch.
I also had a look at the oEmbed JSON that Twitter exposes to the world and some things like hearts count and timestamps are not included.
Anyway building a Tweet shortcode without the tracking is doable but boring and it takes time. I’ll try to submit another proposal on GitHub by the end of the week.
@onedrawingperday At this point, it seems like the YT embed cookies/tracking are out of the Hugo community’s control. Does it make more sense at this point to just include some text and references in the docs? A new shortcode with a lot of embedded JS might be impractical considering the sheer number of sites already using the built-in codes right?
I haven’t proposed anything JS related for the YouTube internal shortcode, only a switch to the more privacy oriented youtube-nocookie.com domain, but that’s still not an ideal solution.
The shortcodes of the various 3rd party services already contain a lot of JS that generates the HTML and the user tracking so I don’t think that it would be a problem to modify them internally, as long as the basic input structure of the shortcodes is not changed.
What kind of text and references do you have in mind for the Docs?
This week Facebook, Twitter and Yahoo’s parent company Oath have all started gathering user consent in anticipation of the GDPR. (Google still hasn’t shown its hand, at the time of writing this).
The general attitude is more or less: agree to our user tracking, personally identifiable profiling or stop using our services. LOL!
It seems that big tech has already decided that they are not going to change their business models in light of the GDPR. They may claim that what they’re doing is compliant but they’re really not giving users a choice.
I had already figured out that much though by the complete lack of official tools to stop user tracking through embedding content from Social media and video services.
Anyway. I’m very interested to see what @bep has in store for the Hugo GDPR release that is coming.
Right now I think I’m not going to work more on the internal shortcodes because there is no point. The public noembed API for Twitter and Instagram does not expose information that users may want displayed.
And if a site admin uses the authenticated APIs the generated embeds come with user tracking.
Anyway I have already posted a proposal for the Instagram internal shortcode without user tracking. If my help is needed for the Twitter shortcode just ask me.
OK, good idea. Though I was just thinking about a flag on the shortcode - which might still be useful. The config file would provide the defaults with the shortcode parameter providing an override if needed.
Certainly the config file setting would be the most useful overall having briefly thought through the use cases.
I think I’m missing something about GDPR. I never thought the intent was to somehow eliminate (or even reduce) user tracking as much as it was to increase transparency around it and provide inroads for reviewing the data collected.
YouTube embeds have never been fully “free,” right? The idea is that now every user—-rather than just developers, other web professionals, or other technically minded folks—-has the right to know this from the jump, right?
Wouldn’t it be easier to just add a separate TOU to the Hugo site that is compliant with the new standards? I would imagine gohugo.io has to make the same choice anyone else is making and either self-host these embedded assets or decide to omit them altogether. Doesn’t the docs site need a typical cookies warning now regardless? One that links to a TOU/legal/privacy page?
What I’ve been wondering about for static sites is how to track whether the user has agreed to the banner/toast/modal. This is one of the areas where it seems like DB-driven sites have an advantage. I’m assuming, however, that I’m missing something here, and this is by no means an endorsement of going back to something like, say, Wordpress
Obviously courts will decide at some point whether these practices are compliant with the GDPR once it comes into force. There is an entire process after all: first a warning, then a reprimand, then a cease and desist, then a fine.
There are going to be new GDPR versions of the Hugo internal templates & shortcodes, that will be possible to enable through a site’s config.
There will be some missing features in the new GDPR templates because the public APIs of the various 3rd party services do not expose everything. But all tracking will be disabled with the new Hugo templates.
The old internal templates & shortcodes will continue to exist in their present form for legacy reasons and also because if a Hugo site admin chooses to handle user consent in a different way they can use these embeds as they would in the past.
I think that offering the ability to build websites without 3rd party tracking out-of-the-box will differentiate Hugo from other frameworks in a big way.
I think the imortant signal we give with this work is that we take this serious, we care, we try. I think most people are confused about this, and really trying to do something about it should go a long way.