Coder Social home page Coder Social logo

oil's Introduction

Project state

We very much regret that we, the previous OIL development team, are no longer able to support the OIL project with immediate effect. It will not be developed any further by us and we will not provide any bugfixes or security patches from now on. As an open source project it will remain available. If you want to take over the project as a maintainer, please file an issue.

For this reason OIL.js is no longer a registered CMP and does not support TCF v2.0. If you want to continue using OIL or develop it further, please register yourself at IAB.

The latest version of OIL is still available in master branch

oil's People

Contributors

atoiv avatar fumler avatar hypery2k avatar jtamary avatar ltparis2018 avatar marcelb avatar ninam2 avatar paulgreg avatar phogel avatar ptc avatar rbuer avatar smic1909 avatar sschenke avatar subsend avatar tbtz avatar timonberlin avatar tumminelli avatar waschnick avatar weian3000 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

oil's Issues

advanced_settings_purposes_default doesn't work with custom purposes

Setting advanced_settings_purposes_default to true doesn't work with custom purposes.

It works as expected for all the default purposes, setting them selected, but not for custom purposes, which are left unselected.

Custom purposes are created per example in oil/src/demos/advanced-settings-custom-purposes.html, with the following configuration:

"customPurposes": [
    {
      "id": 25,
    },
    {
      "id": 26,
    }
],

This was tested to be broken in master branch.

poi_list URL is based on publicPath, not poi_hub_origin

When configuration contains publicPath and poi_hub_origin URL for poi_list is based on publicPath which is inconsistent with documentation [1].

How to reproduce:

Create configuration with publicPath with different URL than hub_origin. Oil will try to fetch POI List from __OIL_PUBLIC_PATH__ + 'poi-lists/' + groupName + '.json'[2]

How it should work:

POI List should be fetched from __POI_HUB_PATH__+'poi_lists/' + groupName + '.json'

[1] http://oil.axelspringer.com/docs/#poi-power-opt-in
[2]

fetchJsonData(__webpack_public_path__ + 'poi-lists/' + groupName + '.json')

Vulnerability Auditing

Crurrent statistics of npm audit is showing several issues for oil regarding vulnerabilities:

found 63 vulnerabilities (13 low, 27 moderate, 17 high, 6 critical) in 24331 scanned packages
  run `npm audit fix` to fix 9 of them.
  20 vulnerabilities require semver-major dependency updates.
  34 vulnerabilities require manual review. See the full report for details.

Publish to NPM

Hi!

We are looking into oil and think we will use it in production, but it's always hard to keep track of the latest development. Could you consider pulishing this to npm?

This way we can use greenkeeper or similar tool to check if we are up to date.

Google Support

Hello,

I have a website with Google Analytics (and only Google Analytics at the moment).

I wanted to quickly install oil.js to be compliant with the GDPR.

But I do not understand why Google in not in the vendor list.

I believe that the whole list is downloaded by the user when the user clicks on the advanced settings.
Is it possible in this kind of case (few vendors), that this list is declared within the configuration?

Thank you in advance.

Regards

Antoine

How can I enable oil only for GDPR countries

Hi,

I saw that in the stub you have a boolean field "gdprAppliesGlobally" for ping if it's supported for all geos or just EU.
On the other hand I saw that in the cookie and interface there is a boolean field ''gdprApplies". However, I cannot understand the flow how to show the UI only for EU countries.

Thanks,
Jonathan

Clarification about CMP registration in the docs missing

I'd like to have some clarification on the requirement for registration as CMP by IAB Europe: Does the registration of OIL as CMP cover any self hosted deployment of OIL or would any publisher who wants to use OIL as their IAB Europe CMP in production have to register their deployment as a new CMP with IAB Europe?

In the IAB Europe webinar it was mentioned that signals from unregistered CMPs are considered invalid, so just to make sure: If a publisher follows the docs, which at this time do not mention getting registered as CMP, would the self hosted OIL deployment pass as a valid CMP?

Kind regards

Markus

hub.1.2.2-SNAPSHOT.min.js is searched in DocumentRoot instead of publicPath

As I have discovered some localization bugs in release 1.2.1, I tried it with the current snapshot. I have set
"publicPath": "//my.host.tld/1.2.2-SNAPSHOT/",
"poi_activate_poi": true,
"poi_hub_origin": "//my.host.tld",
"poi_hub_path": "/1.2.2-SNAPSHOT/hub.html"

In this constellation, oil tries to fetch hub.1.2.2-SNAPSHOT.min.js from //my.host.tld/hub.1.2.2-SNAPSHOT.min.js instead of //my.host.tld//1.2.2-SNAPSHOT/hub.1.2.2-SNAPSHOT.min.js

Specifying the parent domain to put the consent cookie on

We have a website (say, example.com) which is translated into different languages and is available as www.example.com, fr.example.com, de.example.com etc.

If I use oil.js in SOI-mode, each translated version will try to set its own consent cookie. While it is acceptable, we would prefer to have a single cookie set on the parent domain ".example.com" and covering all translations. After all, this is one organisation.

What is your view on allowing to specify the cookie domain in the oil.js configuration?

Uncaught SyntaxError at JSON.parse

I am seeing console errors when OIL tries to parse a string that is not JSON on this line.

It looks like this is because the message handler registered by OIL can pick up messages sent by other sources that do not contain a valid JSON string.

Below is the console error I'm seeing.

Uncaught SyntaxError: Unexpected token a in JSON at position 0
       at JSON.parse (<anonymous)
       at n (oil.1.2.5-RELEASE.min.js:16)

I'm happy to provide more information if needed.

Thanks

better options for npm dependents (cjs, module, browser)

When I add oil as a npm dependency (via yarn add @ideasio/oil.js) the main field of the package.json points to a dev server. A better option would be:

{
  "main": "dist/latest/oil.cjs.js",
  "module": "dist/latest/oil.esm.js",
  "browser": "dist/latest/oil.umd.js"
}

See example with rollup (I could not find an example with webpack): https://github.com/rollup/rollup-starter-lib

For ES6+ project the import would be: import '@ideasio/oil.js';

Info: When I install the latest version (1.2.4) the oil.min.js says /*! 1.2.4-SNAPSHOT */. I think thats not correct.

SNAPSHOT.min.js is huge

The oil.js framework offers a lot and is easy to use, thus I want to thank you for your contribution.

Currently I see one following design problem: It brings a lot JS overhead to the table when directly using the compiled releases. The already minified compiled SNAPSHOT.min.js of latest release 1.2.5 has a size of 76KB, which is almost the size of a minified jQuery and not proportionate to what it usually does in the end.

For what it does in the end, an estimated size of 10KB to 20KB would be reasonable. The framework already uses chunks to be dynamically loaded when needed, maybe this concept can be enlarged to reduce the size of the initially required SNAPSHOT-min.js script.

No third parties

Hello - and thank you this project.

I have a relatively basic website that doesn't use any third-party functionality. I would like for the "Third Parties" list to appear empty on the "Cookie Preference Center" form, or better yet, rather than displaying a list of vendors, have a label that says something like "No third party services used".

I've tried played with alternatively setting "iabVendorWhitelist" to "[]" (without quotes), and adding (for example) a single item to "iabVendorBlacklist" (i.e., [1]) (with "show_limited_vendors_only" set to true), but I still see the complete vendor list.

Is there a way to achieve this configuration? To help the visualisation:

example screenshot

Entirely separately, I don't know if this will be useful to anyone, but I added a little extra script to link scrolling on the "Cookie Preference Center" form to the anchors at the side of the form. So when scrolling reaches the "Third Parties" content, for example, the active anchor switches to "THIRD PARTIES", and visa versa. It's a bit crude (and I've mixed in some JQuery), but it seems to work:

https://pastebin.com/mYRchJgY

POI?

Been trying to work out how this works.
Documentation is sparse.

I have two pages on different domains is it possible to generate consent for both pages using this?

e.g.
abc.com/index.html
First pages leads to
xyz.com/index.html

Is it possible to get consent from the first page with the second pages listed on it so that the second page doesn't additionally require a permission...

Description

the repo description has a typo "Open Source GPDR..."

It should start "Open Source GDPR ..."

Faulty Consent String after CPC "DEACTIVATE ALL"

For example

  • on load, the consent strong is “BOk0p0DOk0p0DBQABBENCfAAAAApmAAA”, which doesn’t include any of the vendors ID’s,  which is correct. 
  • If you “ACCEPT” then it becomes "BOk0p3_Ok0p3_BQABBENCf-AAAApmAbAAFAAoACwAGgAZAA4ACAAEgAKgAXAA0ACLAEwATQAoABSAC2AHEAPwAhABSACtAGUARYAnABOwCngGBAOoA” which includes all vendor ID’s, which is correct.
  • However, if you got to “More Information”, and  "DEACTIVATE ALL”, or select some of the features on/off, you still get the consent string above, BOk0p3_Ok0p3_BQABBENCf-AAAApmAbAAFAAoACwAGgAZAA4ACAAEgAKgAXAA0ACLAEwATQAoABSAC2AHEAPwAhABSACtAGUARYAnABOwCngGBAOoA”. 
     
    So basically, no matter how you customize it, once you hit “ACCEPT” you get the same result. We can’t find anything in configuration that could help with fixing that. 
     
    Adding didn’t make a difference. Is there a way to 
  • fix how “ACCEPT” buttons responds to the different settings? 
  • add another button that opt our?  
  • add a close button that opts out too?

Support local storage

As I see so far the users choices are stored in a cookie (oil_data). Also test setting are stored in cookies like oil_preview. From what I see so far however there's no need to store this information in a cookie but it could be stored in local storage.

At least for the Site-Opt-In case. The benefits of using local storage opposed to a cookie is that we save bandwidth on all requests as cookie's are always added to the header of every request for its domain. Local storage support is also pretty widespread (see https://developer.mozilla.org/de/docs/Web/API/Window/localStorage) and all major browsers (even IE 8) support it for quite a while. From what I see the server is usually not interested in the cookie values either, so I see no reason to send this data to the server.

Is this something you looked in or are looking into in the near future? Could be put behind a config flag to not break existing implementations.

document.body.insertBefore is called before the body is available

I have placed all the oil code quite high in the head of my page.
as a result I get this error 8 times out of 10.
image
Inspecting the code it comes from document.body.insertBefore(t, document.body.firstElementChild),

which is called by the renderoil function.

If I move the oil main js file to the bottom of the head then the errors don't happen anymore.
It appears the code expects the body to be available while there is 0 guarantee it will be.

Is there a way to hide irrelevant third parties?

I was assuming that IabWhitelist would hide any providers not whitelisted but it doesn't appear to work...

I have these as my settings for testing but it's refusing to hide anything not in the array...

"iabVendorListUrl" : "https://service.cmp.oath.com/cmp/v0/vendor_list/global", "iabVendorWhitelist" : [42,164],

getVendorConsents called too soon

Just for testing, I pasted this into the console on your sandbox page:

__cmp("getVendorConsents", {}, (data, success) => console.log({data, success}));

The callback gets immediately invoked, while the consent dialog is still open and no cookie has been set, and the supplied object has all 5 standard purposeConsents all set to false.

I believe this is incorrect according to the API spec, which states:

The vendorIds array contains the vendor ids (as identified in the Global Vendor List) for which consent is being requested. If vendorIds is null or empty, the operation will return consent status for all vendors in the vendor list. The callback function will be called with a VendorConsents object as the parameter. If vendorIds is provided and not empty, then VendorConsents.vendorConsents will only included IDs from vendorIds. The callback is called only after consent is obtained from the UI or existing cookies.
The consent will be returned false ("No Consent") for any invalid vendorId. The boolean success parameter passed to the callback indicates whether the call to getVendorConsents() was successful.

The specification makes sense to me on this point: if the user has neither consented, nor indicated non-consent, we don't in fact know the consent state at all yet - it has to be established first, by some form of user interaction with the UI.

In accordance with the spec, invoking my callback with vendorConsents all set to false indicates the user has denied consent to all cookie purposes.

That's very different from merely not knowing yet.

I've seen other cookie consent scripts apparently making the same mistake, and I've seen people working around this by polling via calls to setTimeout() or setInterval() and actively waiting for consent - which may never come, and some scripts even give up after some number of attempts. But according to the spec, you're supposed to be able to ask once and get a reply when a reply becomes available.

If I wanted to, say, load non-targeted ads after the CMP script has loaded an initialized, I could use the ping command to achieve that - e.g. queue calls to ping and getVendorConsents, one of them clearing (or setting) a flag in the parent scope of my two callbacks; without any unnecessary delays from polling.

So I think the spec is right on this point and everyone is just implementing it wrong? 🤨

Calling __cmp from iframes do not work

Hello.

Thank you for making this project, it's great!

One of our advertisers noticed that calling __cmp from an iframe does not work. They are following the specc: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/CMP%20JS%20API%20v1.1%20Final.md#how-can-vendors-that-use-iframes-call-the-cmp-api-from-an-iframe-

Reproduction:
index.html

<!DOCTYPE html>
<html>
    <head>
        <script id="oil-configuration" type="application/configuration">
        {
            "publicPath": "https://oil.axelspringer.com/release/1.2.1"
        }
        </script>
        <script>
        /*! 1.2.1-RELEASE */!function(e){var t={};function n(r){if(t[r])return t[r].exports;var o=t[r]={i:r,l:!1,exports:{}};return e[r].call(o.exports,o,o.exports,n),o.l=!0,o.exports}n.m=e,n.c=t,n.d=function(e,t,r){n.o(e,t)||Object.defineProperty(e,t,{configurable:!1,enumerable:!0,get:r})},n.r=function(e){Object.defineProperty(e,"__esModule",{value:!0})},n.n=function(e){var t=e&&e.__esModule?function(){return e.default}:function(){return e};return n.d(t,"a",t),t},n.o=function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},n.p="//oil.axelspringer.com/release/1.2.1/",n(n.s=115)}({115:function(e,t,n){"use strict";!function(e,t){e.__cmp||(e.__cmp=function(){function n(){return!(!e.AS_OIL||!e.AS_OIL.commandCollectionExecutor)}(e.attachEvent||e.addEventListener)("message",function(t){e.__cmp.receiveMessage(t)},!1),function e(){if(!(t.getElementsByName("__cmpLocator").length>0))if(t.body){var n=t.createElement("iframe");n.style.display="none",n.name="__cmpLocator",t.body.appendChild(n)}else setTimeout(e,5)}();var r=[],o=function(o,a,c){if("ping"===o)!function(e){if(e){var r=!0,o=t.querySelector('script[type="application/configuration"]#oil-configuration');if(null!==o&&o.text)try{var a=JSON.parse(o.text);a&&a.hasOwnProperty("gdpr_applies_globally")&&(r=a.gdpr_applies_globally)}catch(e){}e({gdprAppliesGlobally:r,cmpLoaded:n()},!0)}}(c);else{var l={command:o,parameter:a,callback:c};r.push(l),n()&&e.AS_OIL.commandCollectionExecutor(l)}};return o.commandCollection=r,o.receiveMessage=function(e){var t=e&&e.data&&e.data.__cmpCall;t&&r.push({callId:t.callId,command:t.command,parameter:t.parameter,event:e})},o}())}(window,document)}});
        </script>
        <script type="text/javascript" src="https://oil.axelspringer.com/release/1.2.1/oil.1.2.1-RELEASE.min.js"></script>
        
    </head>
    <body>
        <iframe src="http://localhost:8081/iframe.html">
        </iframe>
        <script type="text/javascript">
            // Workaround we use to try and fix below
            
            // function cmpMsgHandler(event) {
            //     var msgIsString = typeof event.data === "string";
            //     var json = msgIsString ? JSON.parse(event.data) : event.data;
            //     if (json.__cmpCall) {
            //         var i = json.__cmpCall;
            //         window.__cmp(i.command, i.parameter, function(retValue, success) {
            //             var returnMsg = {"__cmpReturn": {
            //             "returnValue": retValue,
            //             "success": success,
            //                 "callId": i.callId
            //             }};
            //             event.source.postMessage(msgIsString ?
            //             JSON.stringify(returnMsg) : returnMsg, '*');
            //         });
            //     }

            // }
            // var result = null
            // window.__cmp('ping', null, function(res) { console.log(res); result = JSON.stringify(res) })
            // document.querySelector('.test').innerHTML = result

            //window.addEventListener('message', cmpMsgHandler)
        </script>
    </body>
</html>

iframe.html

<!DOCTYPE html>
<html>
<head>
</head>
<body>
    This is an iframe
    <script type="text/javascript">
        // find the CMP frame
        var f = window;
        var cmpFrame;
        while (!cmpFrame) {
            try {
                if (f.frames["__cmpLocator"]) cmpFrame = f;
            } catch (e) {
                console.log("Catched: ", e)
             }
            if (f === window.top) break;
            f = f.parent;
        }
        var cmpCallbacks = {}
        /* Set up a __cmp function to do the postMessage and
           stash the callback.
           This function behaves (from the caller's perspective)
           identically to the in-frame __cmp call */
        window.__cmp = function (cmd, arg, callback) {
            if (!cmpFrame) {
                console.log("no cmpFrame")
                callback({ msg: "CMP not found" }, false);
                return;
            }
            console.log('have cmpFrame')
            var callId = Math.random() + "";
            var msg = {
                __cmpCall: {
                    command: cmd,
                    parameter: arg,
                    callId: callId
                }
            };
            cmpCallbacks[callId] = callback;
            cmpFrame.postMessage(msg, '*');
        }

        /* when we get the return message, call the stashed callback */
        window.addEventListener("message", function (event) {
            console.log('message')
            var json = typeof event.data === "string" ? JSON.parse(event.data) : event.data;
            if (json.__cmpReturn) {
                var i = json.__cmpReturn;
                cmpCallbacks[i.callId](i.returnValue, i.success);
                delete cmpCallbacks[i.callId];
            }
        }, false);

        /* example call of the above __cmp wrapper function */
        __cmp("ping", null, function (val, success) {
            console.log("val=", val, " success=", success)
        });
    </script>
</body>
</html>

And serve these files on localhost:8081

With that code you will not get the val= success= logs, but if you uncomment the commented code, you will.

CPC settings are reset to default when navigating between screens

When navigating between screens, the settings previously set in the CPC view are reset to whatever default is defined in the config. This may result in users inadvertently opting in to purposes they specifically wanted to opt out of.

Steps To Reproduce:

  1. Go to the oiljs sandbox
  2. In the default view, click 'More information'
  3. In the CPC view, Opt in on some purposes
  4. Click the 'back' button, and then the 'More information' button

Expected result
Advanced settings previously set should be maintained

Actual result
Advanced settings are set back to the default setting

getVendorConsents callback not called when library is still loading

Hello everybody,

first of all thank you very much for creating this project. It is really easy to implement and helps us a lot.

During implementation to our sites i think that i found a bug.
After loading the stub and before completing the loading of the other parts ( chunks) of oil the stored callbacks are not called after loading and initializing process is done.

I reproduced this behaviour on that demo site:
https://s3-eu-west-1.amazonaws.com/media.das.tamedia.ch/testing/playground/dev/oil/test.html

I am first loading the stub
Then calling
__cmp('getVendorConsents', null, (results) => {   | console.log("Got vendor consent", results);   | });

And after that i am loading the rest of the library. The defined callback is never fired.
Is this a bug or do i understand something wrong?
Thank you very much for your help
Torsten

Improvement: Build with LTS version of Node and AppVeyor

The current travis configuration uses Node 7 to build. It would be better to stick to Node 8 or the upcoming NodeLTS version, see here for more.
Node 8 also improves overall install performance an dev machine. Maybe it would be also a good idea to test several NodeJS version, like here.
Besides that a ci build on AppVeyor would also ensure that the setup works on Windows machines.

I could sent a PR for these both issue.

the event 'oil_shown' is always sent in a certain configuration

When using the gdprApplies conditionally, the event 'oil_shown' is always sent even when the UI is not shown since it's not a GDPR country.

I think that the problem is because the user haven't opted in if he's not from a GDRP country:

and we check the gdprApplies only in:
https://github.com/as-ideas/oil/blob/master/src/scripts/userview/userview_modal.js#L126

but we send the event when optin is false:

sendEventToHostSite(EVENT_NAME_OIL_SHOWN);

Thanks,
Jonathan

Development status of this project

Hi,

One of our advertisers is telling us that they strongly advise us against using OIL for our websites; they specifically claim that OIL does not comply with the current status of the IAB standard and that there has been a severe lack of development in the last months. The last release is now indeed two months old and there hasn't been a lot of commit activity since.

Has AS dropped active development of OIL or are you still fully committed to maintaining an OSS IAB CMP solution? If so, is that claim by our advertising agency just FUD on behalf of their preferred commercial CMP? Is there a roadmap for future OIL releases?

Kind regards

Markus

Opt out confirmation doesn't work on Preference Center

If using the Oil Preference Center on a page with
<div id="oil-preference-center"></div>and window.AS_OIL.showPreferenceCenter();
and the configuration option "require_optout_confirm": true, the following JavaScript error occurs, blocking the opt-out:

Uncaught (in promise) TypeError: Cannot read property 'insertBefore' of null
    at 0.1.2.5-RELEASE.chunk.js:1
    at new Promise (<anonymous>)
    at s (0.1.2.5-RELEASE.chunk.js:1)
    at HTMLInputElement.p (0.1.2.5-RELEASE.chunk.js:1)

It looks like this is caused by looking for a hardcoded #as-oil-cpc although I'm not too sure. As a workaround I've disabled the option on that page.

mismatched and unresponsive styling of the Cookie Preference Center

The CPC (Cookie Preference Center), where the user customizes their cookie settings, appears differently depending on how it's opened, and further is not fully responsive.

Mismatched CPC styling:
Case 1 - The user enters the CPC via an optional 'advanced' link in the consent banner they see on their first-visit to the website. Here the CPC is styled in a similar fashion to the main consent banner... a fixed box at the bottom of the screen. It also takes on the dark or light theme as configured in the plugin settings via "theme": "dark".

Case 2 - The user enters the CPC via API call window.AS_OIL.showPreferenceCenter();. What appears is always a light theme, and is always a plain div injection, never a modal like the case 1 CPC.

2a - If called on a specific page, and injected into the page content, it looks ok especially if the page is a typical white-background policy page. On a side note: the "OKAY" button doesn't communicate anything once pressed. Is there success? How do we guide the user to do something after the fact? At least a "Thank you" and home page link, or something?

2b - If called from a custom "Cookie Settings" link at the bottom of every page, among other legal links, as commonly done on many websites... one expects to see a modal appear centered on screen, as many other major cookie managers do. Here the CPC is obviously injected wherever<div id="oil-preference-center"></div> is placed, and in my case I placed it directly after <body>, originally expecting a modal rendering. Instead, the CPC renders as a plain div at the top of my page before content (undesired).

Currently I'm manually styling this as a modal, however I don't want to hack in closing functionality ('X' icon, close button and/or clicking dimmed background).

Responsiveness

Regardless of rendering, the CPC isn't fully mobile optimized. It does breakdown, however for small screens it's still painful to use.

Suggestions:
1 - showPreferenceCenter() should be configurable as to rendering as a modal or plain div injection, should take on the theme of the first-visit banner. The modal should have standard dismiss/close features.

2 - Work on the responsiveness of the CPC, especially for mobile.

3 - A template system so HTML of any banners and CPC can be customized. I feel like restructuring the CPC for my purposes... option for "standard" vs "tabs" view is not enough.

Withdraw consent

In order to be compliant, the user should be able to withdraw consent.
However, there doesn't seem to be any documented way of re-opening the CMP after choices have been made.
There should be an API to re-open the overlay and change the settings, other than clearing the cookie.

Improve the diff/snaphot-testing for HTML-Templates

Currently we do the HTML diff to check the templates ourself. We should use a better library for this, or improve it otherwise.

How it currently works:

In the test:

expect(document.querySelector('.as-oil')).toEqualWithDiff(readFixture('gold-master/cpc.html'));

And this is used: oil/test/utilsHtmlDiff.js#customMatchers.toEqualWithDiff with the html-differ library.

Problem: The reporter can't handle the diff and it looks ugly - you don't see much.

Release Notes

Since oil is quite new and new releases are published (nearly) on a daily base, it would be good to see what in exactly changed. Therefore I would to see some release notes in order to assess if it is worth to update.

Improve event-handling for analytics

  • Collect all oil.js events in a queue, so when the tracking tool is not loaded yet the events aren't lost
  • Add a description how to create reports for oil.js with Google Analytics
  • Detailed documentation

showPreferenceCenter() without cookies

Hi,

I found a strange behavior with "Preference Center" integration as explain in the doc here (v1.3.0): https://oil.axelspringer.com/release/1.3.0/docs/index.html#oil-cpc-api

When I have optin or optout, integration works as expected on my page:
image

But when I didn't give consent and I want to see my page with details. I got full page preference center hover my page content:
image

In the first case, the html is inserted inside


In the second case, html is inserted at the top of the body.

I look into the code and specially at : oilShowPreferenceCenter function inside userview_modal.js and it seems that if wrapper (.as-oil div) exist it insert it inside else it goes to the entryNode (#oil-preference-center).

General Questionnaire Quickstart - ENGLISH

In my Company we want to track again Users Data, of course compatible with GDPR. We founded Oil.js the best option for our Enterprise.
Despite that the Documentation was so clearly, we have some question:

1.- Is Oil.js compatible with Wordpress?
We use the famous Third Party Vendor Wordpress for our Website, we have the question if there is problems with PublicPath, Local_url, or Locale when we use it in Wordpress
2.- Oil.js doesn’t blocked automatically the Data Tracking. How could we do that?
For the moment, we added this term in our Website:
window['ga-disable-UA-XXXXXX-Y'] = true;
That was a Google Analytics requirement; I ask if with Oil.js the need this term more or we can remove it. If we remove it, are we completely conform with GDPR? I’m worry because Axel Springer says:
“OIL creates a standard for the Opt-In but can’t automatically stop your site from tracking your users. So to actually make your page respond to opt-ins you also need to do the following:
Make sure your page doesn’t track the user in its default state.”
Is so then the Soft Blocking of DOM sufficient for block automatically the Data Tracking?
3.- Get Vendors Consent
If we do not change the Integrate OIL code (that we can find in the documentation as Integrate Oil, the Second Step in the Quickstart) should we add the getVendorConsents Code too?
The same for getConsentData and getPublisherConsents.
4.- How works the Data Delivery Process?
First of all, How track Axel Springer our Data? And so importante your us to know how send Axel Springer these Data to Google Analytics?
I’m worry if we can lose some Data in this process. Shoul I understand that every work automatically with this term?
} if (window.ga && window.ga.loaded && event && event.data && eventDataContains('oil_optin_done')) { // event name
var nonInteraction = true; // should be set to false for non-click events
window.ga('send', 'event', 'OIL', 'oil_optin_done', {'nonInteraction': nonInteraction}); }
Thank you so much your our time and our attention
Kind regards
Daniel Pastor

Support for custom vendors

  • configuration option to list custom vendors with name, purposes, leg-int and opt-out-link
  • display custom vendors under the iab list in the CPC and in the 3rd party view
  • do not forget testing

Vendor Based Opt-Out for Users

Right now it is only possible for a user to opt-in/out for the different purposes but not on a per vendor basis.

So there is no way to say for a user: „I‘m totally fine with personalized ads, but not from company XYZ since I don‘t trust them.“
I am not a legal expert, but in my understanding GDPR (and the upcoming E-Privacy Directive) are aiming at exactly such a use case.

Is this a feature that you considered to be activated via a config option?
What‘s the reasoning behind not having such a feature (optionally)?
Are there any workarounds for this done by others?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.