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.
There is a way to make the existing Instagram internal shortcode GDPR compliant.
See my proposal on Github. Reviews and modifications are welcome:
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.
I have been looking more into alternative ways to embed YouTube videos without any Google tracking.
As I said on GitHub serving videos from youtube-nocookie.com may not set cookies but once playback commences it creates persistent local storage keys in users’ devices.
But there are services out there that expose the video URL from Google’s internal CDN googlevideo.com.
Using this URL as the source of a video object does not have any tracking.
The downside is that the googlevideo.com CDN URL is constructed dynamically based on location, so if one uses a URL that is meant for Europe, playback will be slower in other regions.
Also this solution cannot be implemented with Hugo’s internal shortcode for YouTube since the video URL is different from video to video and it has nothing to do with the YouTube video ID.
EDIT
The URLs from Google’s internal CDN include a user’s IP, a proxy IP, location coordinates and on top of everything else they expire after a few hours.
So no way to use these. Also I am amazed that they transmit this sort of information in this manner, even if it’s through HTTPS.
@alexandros 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.
Here, here.
This the new consent box that appears when one clicks on a YouTube video search result via DuckDuckGo.
Now that can be easily incorporated into the YouTube Hugo shortcode.
And since Google is not giving users the option to disable tracking, I think it’s a great idea to call them out.
Of course from a UX perspective this puts another button for the user to click (and that is not cool).
But… I have yet to find a privacy oriented video hosting service.
That’s great! Can we make it optional via a flag though? There may well be occasions where the UX trumps the privacy.
[quote=“onedrawingperday, post:47, topic:11526”]
Anyway. I’m very interested to see what @bep has in store for the Hugo GDPR release that is coming.
[/quote]an
That is a good question … I got distracted with anothe four letter acronym EXIF, which is a little bit more interesting.
I will jump on this now. I will create a GDPR branch where you and others who want to join this dugnad can have commit access if you want, and we can do a quick sprint with both code and docs updates.
I will arrive shortly with an update. I will start by outlining the configuration I have been thinking about.
Yes.
My thought on this was to add a “privacy section” in config.toml where we gather all of these flags in one place. That way people can copy and paste complete privacy configs from people they trust.
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 will be glad to contribute.
So far I’ve done proposals for Instagram and Google Analytics.
I’ll do a new proposal for the YouTube shortcode with the above consent and I’ll do the Twitter shortcode (same concept as what I did for the Instagram one).
There is also Vimeo but I haven’t really looked into their public API (hopefully the above consent can be implemented in this case also).
Also @it-gro has worked on the Disqus shortcode.
Of course we will need reviews by other users. I have my limits when it comes to JS and we’ll need to use it within the GDPR versions of the shortcodes.
OK, I have sent an collabrator invite to @it-gro as well. Let us do this quickly and effective.
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 
There is a concept in the GDPR about not making user consent a precondition for a service. The GDPR consent boxes I’ve seen so far are in the form of: please agree to our terms of services and our privacy policy OR delete your account. Facebook and OATH (Yahoo) have made this pretty clear.
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.
You set a cookie or local storage key with JS. And then in your Privacy Policy you provide the user with a button to clear these cookies if she wishes. I’ve done this for a Hugo site, so it’s possible.
I think we could say “all tracking can be disabled”
Well said.
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.
You may have already received an email about the new Google Privacy Policy for the GDPR, but here it is:
https://policies.google.com/privacy/update
It’s very interesting how Google admits that it is fingerprinting the entire web:
When you’re not signed in to a Google Account, we store the information we collect with unique identifiers tied to the browser, application, or device you’re using.
No way to opt-out of that.