Jump to content

PrivacyWire - Cookie Management & async external asset loading


joshua

Recommended Posts

@joshua thx again.

Works great for iframes.
Is there also a solution to have it for external content which loads through scripts and divs. For example GoogleMaps. Right now i can do this:

// this puts content into #myMap
<script type="text/plain" data-type="text/javascript" data-category="external_media" data-src="gmaps.js"></script>

<div id='myMap'></div>

But unlike the your-iframe solution i cant have a ask-consent-button. It would be nice to have links like this integrated:

<a href="#" class="privacywire-allow-category" data-category="external_media" data-ask-consent="0">Allow Cookies for external media</a>


 

Link to comment
Share on other sites

That's right - you cann add a button (or link, whatever you prefer) with this css class and the data-consent-category attribute. PrivacyWire will handle it 😉

I definetely have to update the documentation with all the added features - will do that in the next weeks.

  • Like 2
Link to comment
Share on other sites

40 minutes ago, joshua said:

I definetely have to update the documentation with all the added features - will do that in the next weeks.

Hehe. Documentation often lags far behind development. 🙃

Link to comment
Share on other sites

Hey @joshua!

I'm not sure if this is a real bug, but on one site I have a script like this:

<script id='taeggie-feed-widget-script-xxx' type="text/plain" data-type="text/javascript" data-category="marketing" data-ask-consent="1">
  jQuery.getScript(...);
</script>

This works and the consent info/request box is displayed. If I click the "accept" button from this info box it goes away and the script gets executed, so all is good in that case — but if I instead click the "accept all" button from the (separate) cookie management banner, the info and accept button next to the script are not removed.

Note that the script works as expected regardless of which accept method I use, so the only issue here seems to be that the info box / accept button are not removed. If I refresh the page, they are gone.

Is that a bug, feature, or user error? 🙂

  • Like 1
Link to comment
Share on other sites

Awesome — thanks Joshua!

Just a heads-up: I've opened a new PR for you to check out at https://github.com/blaueQuelle/privacywire/pull/10. This is quite opinionated, so let me know if you don't feel it's a great match with the module. Basically what I've added is support for the textformatter module to replace embedded media/video iframes with PrivacyWire enabled ones.

It's mainly a compatibility layer for TextformatterVideoEmbed 🙂

  • Like 4
Link to comment
Share on other sites

Hi Joshua,

just an idea. If there were a counter for all closes of all finished user decisions and a separate one only for the "accept all" decisions, it would give me a perfect idea of the accept ratio of the specific site. Either generally (probably enough), or even per month in a table (to monitor changes in behaviour). In the module, or in logfiles or a CSV file with a row limit? Basically, sort of mini-statistics.

I have guesswork right now regarding Analytics' / Matomo's result changes and of how many users (in percent) those analytics results represent?

  • Like 2
Link to comment
Share on other sites

Hi @ceberlin,

sounds like an good idea to me. To allow this kind of "tracking" we would need to send this decission via JS to an endpoint which connects to the ProcessWire API.

I will think about an way to implement this feature. I'm also open for a PR, if you already have an idea how to realize this feature.

Link to comment
Share on other sites

I tried to disable or hide a "Remember me" checkbox. My HTML is

<div class="field has-text-right">
    <label class="checkbox">
        <input type="checkbox" name="rememberme" value="<?=(int) input()->cookie->rememberme?>">
        <?=__('Remember me')?>
    </label>
</div>

The code I'd prefer would be (notice the two "disabled" attributes on the label and the input)

<div class="field has-text-right">
    <label class="checkbox" disabled>
        <input type="checkbox" name="rememberme" value="<?=(int) input()->cookie->rememberme?>" disabled>
        <?=__('Remember me')?>
    </label>
</div>

Although I could live with only hiding it, which is what I've tried by adding

data-category="functional" data-ask-consent="0" data-ask-consent-rendered="1"

to the div, the label or the checkbox. And it hides them all right. The issue is that PrivacyWire does not care about innerHTML of my poor div, or about its class. I changed o.innerText=e.innerText with o.innerHTML=e.innerHTML directly into js/PrivacyWireUnstyled.js and I got my checkbox back, but without its initial class. I think it is the code at line 231 in src/js/PrivacyWire.js.

I know almost no JavaScript, so start throwing tomatoes - in the priw_updateAllowedElement there is no way to let the old element live instead of copy into a new one > insert the new one in the DOM > delete the old one?

Also, it feels to me that flipping between two attributes or two CSS classes should be all PrivacyWire needs to do in regard to the elements that need consent.

LATER: hmm, maybe not in regard to scripts. Leaving for the coffee machine...

 

hmmm.jpg.d15604314fa2490e9b29acac524ac0bc.jpg

 

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Hi @The G,

thanks for noticing this behavior! During the development of PrivacyWire I never thought of showing or hiding divs or "regular" elements - only thought of scripts, videos, media ... So, good catch!

I refactored that part of the priw_updateAllowedElement function to fix this bug.

Cloning is required for everything, where media, scripts or other external stuff gets loaded...
Waaaait a minute... While I was writing these lines of nonesense, I realized that this idea is wrong! 🥳 You're right - keeping the elements alive and just update the attributes works for scripts, images, iframes and of course divs and other elements, too. I refactored again and tested the new version with all kind of elements and media...

Only script tags need to be a new added element, as they will not run otherwise: https://html.spec.whatwg.org/multipage/scripting.html#script-processing-model

0.4.2 fixed it!

Edited by joshua
Added another bug within the old bugfix. It's fixed now :D
  • Like 3
  • Thanks 1
Link to comment
Share on other sites

On 11/25/2020 at 5:59 PM, joshua said:

@teppo Thanks alot for your PR with the TextformatterVideoEmbed integration! I tested and merged your PR today.

I like the idea of adding more and more integrations with other modules like TextformatterVideoEmbed.

@teppo & @joshua does this mean, that iframes generated via TextformatterVideoEmbed will use PrivvacyWite data-attributes and are hidden untill given consent?

 

Link to comment
Share on other sites

12 minutes ago, ngrmm said:

does this mean, that iframes generated via TextformatterVideoEmbed will use PrivvacyWite data-attributes and are hidden untill given consent?

If enabled in the TextformatterPrivacyWire settings, yes.

grafik.png.64904c7279fe590b671b1e8cc053cf74.png

But it's disabled by default.

  • Like 3
Link to comment
Share on other sites

47 minutes ago, joshua said:

If enabled in the TextformatterPrivacyWire settings, yes.

But it's disabled by default.

Ok. Then i'm doing something wrong.
I installed PrivacyWire and TextformatterVideoEmbed and added them both to my textarea-field as textformatters.
After that i choosed ExternalMedia to as you suggest above.
Now when i add a YouTube-Link inside my textarea and external-media-cookies are off, i still can see the Iframe.

I also installed TextformatterVideoEmbedOptions and activated YouTube: Enable privacy-enhanced mode.

All Modules are updated to newest version. 

Link to comment
Share on other sites

13 minutes ago, ngrmm said:

I installed PrivacyWire and TextformatterVideoEmbed and added them both to my textarea-field as textformatters.
After that i choosed ExternalMedia to as you suggest above.
Now when i add a YouTube-Link inside my textarea and external-media-cookies are off, i still can see the Iframe.

Just checking: TextformatterVideoEmbed is listed before TextformatterPrivacyWire? If it's the other way around, this won't work.

13 minutes ago, ngrmm said:

I also installed TextformatterVideoEmbedOptions and activated YouTube: Enable privacy-enhanced mode.

This could potentially affect the situation. I would make sure if it makes difference, i.e. try disabling it and see if that changes anything.

So far this has worked for me, but let us know if the issue persists 🙂

Edit: if TextformatterVideoEmbedOptions runs before TextformatterPrivacyWire, this will definitely break things due to this line: https://github.com/blaueQuelle/privacywire/blob/master/TextformatterPrivacyWire.module#L51. Seems like an easy fix, though. Admittedly the order of the modules is a bit fragile, but part of it is really due to the way textformatters work and there's not much that can be done about that.

Edited by teppo
  • Like 2
Link to comment
Share on other sites

TextformatterPrivacyWire.module works fine here as long as:
1) the iframe contains www.youtube.com/embed/ and not www.youtube-nocookie.com/embed/ and
2) as long as its the second textformatter (or at least the textformatter after VideoEmbed).

Just played around with it here in my testing setup.

  • Like 2
Link to comment
Share on other sites

Thank you all!

I had the formatters not in the right order!
So for all noobs like me: 

Textarea Text Formatters:
1. Video embed for YouTube/Vimeo
2. PrivacyWire Textformatter

and i guess after updating to 0.4.3 then:
1. Video embed for YouTube/Vimeo
2. Apply options for embedded YouTube and Vimeo videos
3. PrivacyWire Textformatter

Link to comment
Share on other sites

Well... while this works (1):

screenshot-20201201163234.thumb.png.e4dd9af8b3bc380aa5a12fdb87892825.png

This doesn't (2):

screenshot-20201201163315.thumb.png.10bf47160908c66aa4c539c5dc245d96.png

I use a slightly modified version of Ryan's Video embed for YouTube/Vimeo module which already saves the "no cookie" domain to the database.
Users would paste the URL as usual, the module fetches the oEmbed data but in my case the domain will be replaced.

Around line 104 in Ryan's module I changed that part:

$embedCode = str_replace('youtube.com', 'youtube-nocookie.com', $data['html']);

 

  • Confused 1
Link to comment
Share on other sites

@joshua thanks for the module.

I unchecked the module config checkbox "CSS: Add basic CSS Styling" and added via <script> the PrivacyWire.js (which, as of module implementation, seems to include CSS itself), but the PrivacyWireUnstyled.js still loads in network (i.e. a HTTP request is made to get it).

Is there a way to include "manually" all the JS files (including PrivacyWireUnstyled.js)?

That is, to make possible something like this:

<script src="/site/modules/PrivacyWire/js/PrivacyWire.js"></script>
<script src="/site/modules/PrivacyWire/js/PrivacyWireUnstyled.js"></script>

so it would be the developer choose to minify and merge files, and to manage for less HTTP requests.

 

Maybe a config option? 

Link to comment
Share on other sites

You have the "Render Banner and Header Content Manually" option in the module settings. After checking it you can insert the module generated code wherever you'd like. The script tags are generated by the folowing snippet:

$modules->get('PrivacyWire')->renderHeadContent()

Disclaimer: didn't tested my suggestion, this is just what I saw in the module's code.

Why would you want to include both PrivacyWire.js and PrivacyWireUnstyled.js? AFAIK they only differ in including or not the module's CSS for the frontend. Including PrivacyWireUnstyled.js would only waste resources if PrivacyWire.js is included.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...