Jump to content

Sperber

Approved members
  • Posts

    29
  • Joined

  • Last visited

Everything posted by Sperber

  1. At first glance it may look like this. Since the beginning of 2018 I have the dubious pleasure to work myself through the GDPR, national supplement laws, legal advices by the IT-lawfirm consulted and to implement the needed changes with the IT-desk into the websites of the company I am working for. There is light at the end of the tunnel and we will be complying with the IOC regulations end of this week. But in short: it´s a pain in the arse and there are litarally hundreds of possibilities to make a wrong turn. Now, I am using Revive on my personal websites. I am afraid, but you´re going wrong in assuming, Revive wouldn´t handle and process personal data. Of course it does, if you take a look at the GPDR and the definitions within which data is defined as personal data. It´s a long list and in summary every data Revive gets from the browser informations of a visitor, IP-adresses and of course even setting cookies prior to the consent of the visitor and reading the cookie informations back, to serve the "right" ads at a time. Not to mention geotargeting or how data of customers with access to Revive are processed. When you now say Revive wouldn´t handle and process personal data, then - for my understanding how Revive works - Revive coudn´t technically be able to deliver a single ad, as it couldn´t even detect, that there is a website visitor in the first place. Absolutly, I agree. That´s why I am asking, wether there are plans to make Revive complying with the GDPR or not. If not, we pubilshers with users from the EEA will be forced to shutdown Revive - and that´s the last thing we want to. But as we are all assumed to be some sort of for-profit companies, with the GPDR it only needs 2 people getting mad at you and filing a complaint with the national data protection agency and you´ll face a 25.000 EUR fine. There isn´t really a choice wether you, as a publisher or website owner, comply with the GPDR or not. I just can´t afford that bill and I doubt that any other publisher can afford this. Such a scenario may be won´t happen on may, 25th. Not even in the weeks or months to follow, if you are lucky. The point is, that, if we don´t take the plunge to work and close these risk gasps, I´ll garantee us, somebody will and we´ll find us in serious - and for many ruinous - trouble. Unfortunal, regarding Revive it´s both. Sure, primarily it´s a legal issue. The problem with this is, that - at the time of writing - there are no technical functions available in Revive to be able to comply with them. Just to name a few and to make the problems more visible: Under Article 17 of the GDPR individuals have the right to have personal data erased. This is also known as the ‘right to be forgotten’. The right is not absolute and only applies in certain circumstances. (https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-erasure/) The right to data portability gives individuals the right to receive personal data they have provided to a controller in a structured, commonly used and machine readable format. It also gives them the right to request that a controller transmits this data directly to another controller. (https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-data-portability/) or the users right to be informed as stated in https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/individual-rights/right-to-be-informed/ You must provide individuals with information including: your purposes for processing their personal data, your retention periods for that personal data, and who it will be shared with. We call this ‘privacy information’. You must provide privacy information to individuals at the time you collect their personal data from them. You must regularly review, and where necessary, update your privacy information. You must bring any new uses of an individual’s personal data to their attention before you start the processing. and prior to all that, the lawful basis for processing as stated in https://ico.org.uk/for-organisations/guide-to-the-general-data-protection-regulation-gdpr/lawful-basis-for-processing/ Consent means offering individuals real choice and control. Genuine consent should put individuals in charge, build trust and engagement, and enhance your reputation. Consent requires a positive opt-in. Don’t use pre-ticked boxes or any other method of default consent. Keep evidence of consent – who, when, how, and what you told people. Last, but not least, all this has to be documented in a way, that agencies - like your national data protection agency - can check at any given time, wether you are complying with the GPDR or not. All of this in fact is a technical issue, as we publishers would need integrated tools for that. With your given answer by now, I understand that there won´t be any - or some kind GPDR-solutions - available. May be I can inspire you to think your decision over again. Would be a pity to give up on Revive. Regards, Chris.
  2. Due to the fact, that on may 25th the GDPR comes into effect, is there anything in the pipe to make Revive complying with the EU-regulation? Actual, Revive processes a whole of bunch of personal data and and the use of it will be penalized in the end through fines. I am wondering that there is not one official statement about the whole GDPR-thing, as this needs to be clearified by Eric ASAP. Else we all have to shut down our Revive-Installations or we have to face drastic fines for using it beyond may 25th. 20 days to go, plus the rest of today.
  3. I was talking about the german antivirus company. In short, their warning is stating: "Website blocked. Access denied by security suite. [...] This page contains infected code. [...] Virus found while loading their content." Every browser has some security flaws here and then. Some more often, some more popular, some don´t publish em - or fix em properly or in a timely manner. Coders can make use of those exploits with targeting some code on a simple website to attack the browser and via the security leak inject malicious code - e.g. viruses - into your system. That´s a drive-by, as you are doing nothing really dangerous instead of websurfing like everyone else. The false positive rate with those is huge, depending on the AV-suite you are using. That´s why GData leaves you in nearly all those situations the option to bypass their warning and to continue surfing. First time ever I would have to deactivate the complete web protection module to go on. Erm - guess I don´t.
  4. GData has this website listed as injecting malicious code via drive-by surfing and blocks access right away, without having the chance to bypass the blocking - which is very unusual for GData, too. Normally they only show a warning and leave it up to you, to go on or not. Mhm..
  5. I´m not sure if it´s allowed to ask for here in the forums - if not, please give me a hint. But to be able to serve responsive ads is a breaking point. For that reason I would even pay a developer or coder, to implement the needed changes for us. If there is anyone out there who is capable of and interested, please drop me a note and include a quote, please.
  6. Duh.., these are bad news. In times where responsive ads have become crucial (guess we all are - at least - backfilling from ad-networks), is there any workaround? Even a quick and dirty one - I´ld be fine with that. Meanwhile we serve responsive ads for over 85 % and most requests to advertise with us are for responsive ads - so this has becomes more and more critical. On the other hand it seems to be the breaking point for other webmasters to utilize Revive on their seites, as I found out in the past. From a dev-view: is it that hard to include a new preset "Responsive" without dimension settings?
  7. Hi there, I am trying to serve responsive linkblocks from AdSense and could need some help on setting it up in Revive. I want to deliver the linkblock without any dimension preset by Revive, so AdSense can determine how far to expand the linkblock. As I have found out by now is, that zones can be set up with a "x" for width and height. How can I now setup a banner without a predeterminated dimension value? All in all: I want Revive to just put the pure unaltered AdSense code into the source of the website without any dimension values. How can I achieve this with Revive? (Of course I know that the AdSense code can be inserted directly into the website - but for some reasons I need them to be delivered by Revive.) Help appreciated. Regards, Chris.
  8. @tobiasmadsen, finally and through Andre´s help the asynch-tags are working for us now. I guess he´ll release an official note to this issue, when this is gone through the dev-chain. At least I can tell, in our case it was related to a server setting, redirecting http to https on server level, which leads to a 301 Revive can´t handle by now. Expect this issue to be resolved in one of the upcoming releases. For now and if this is the same scenario for you: just disable the 301 redirecting and you´ll be good. All props belong to Andre! Thanks ;)
  9. Hello Andre, we use Zend and don´t have varnish installed on our server. If it may help you investigate further on, here is our phpinfo for troubleshooting purposes: https://www.dropbox.com/s/syd5zzp74gtekoh/phpinfo.png Regards, Chris.
  10. Hello Tobias, unfortunal we were´nt able to bring the asynch-tags to work, nor could we narrow down the problem any further to at least give a feedback if this is more a server side problem regarding php limits & exec time (no errors logged in Revive or the server logs), a browser issue or a native bug in Revive. The asynch function just don´t work for us and I´ve seen no Revive instance - beside the one that delivers the ads in this forums here - that does by now. It´s a pity. If you manage to get them working, please let us others know about it. Regards, Chris.
  11. Thanks Ian, indeed that fixed the problem, as we had 7.1.3 running. Is it planned to update Revive to work with the latest PHP versions, since they have some features we would like to benefit from?
  12. The error log shows this: [Wed Apr 12 11:11:51.147917 2017] [proxy_fcgi:error] [pid 5734] [client 207.89.67.46:33966] AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Using $this when not in object context in /var/www/vhosts/mydomain.com/httpdocs/1/lib/pear/HTML/QuickForm.php:602\nStack trace:\n#0 /var/www/vhosts/mydomain.com/httpdocs/1/lib/pear/HTML/QuickForm.php(568): HTML_QuickForm::_loadElement('createElement', 'select', Array)\n#1 /var/www/vhosts/mydomain.com/httpdocs/1/lib/OX/Extension/bannerTypeHtml/bannerTypeHtml.php(78): HTML_QuickForm::createElement('select', 'adserver', 'Alter HTML to e...', Array, Array)\n#2 /var/www/vhosts/mydomain.com/httpdocs/1/plugins/bannerTypeHtml/oxHtml/genericHtml.class.php(40): Plugins_BannerTypeHTML->buildForm(Object(OA_Admin_UI_Component_Form), Array)\n#3 /var/www/vhosts/mydomain.com/httpdocs/1/www/admin/banner-edit.php(517): Plugins_BannerTypeHTML_oxHtml_genericHtml->buildForm(Object(OA_Admin_UI_Component_Form), Array)\n#4 /var/www/vhosts/mydomain.com/httpdocs/1/www/admin/banner-edit.php(261): buildBannerForm('html', Array, Object(Plugins_BannerTypeHTML_oxHtml_genericHtml), false)\n#5 {main}\n t...\n', referer: https://mydomain.com/1/www/admin/campaign-banners.php?clientid=3&campaignid=59 Would appreciate any help.
  13. Mhm.. . Any ideas where these blank pages evolve from? Or how to fix this?
  14. Has anyone mentioned before, that - after an upgrade to the latest version - the Banner pages with javascript-code as ad-code are coming up as blank? Our situation: we moved from dedicated hosting into the cloud, upgraded PHP from 5.x to 7.1.0, upgraded Revive Adserver to the latest version and since then everything is running fine for now over 2 weeks. Today I installed new geoip-files and wanted to test them on an AdSense-Banner - and that´s when I stumbled over the blank pages. It´s not only limited to AdSense-Code, even to Media.net and others who utilize javascript codes. The banner pages with static banners instead are working and I can alter them as usual. As I don´t have an idea how to fix that, can you gimme an advice? Could that be, that Revive is somehow incompatble with PHP 7.x? Regards, Sperber
  15. Hi Erik, may be you´ve missed, that we are not using the lazyloader with asycns in mind. Revive could handle this pretty neat by itself. We are using the loader to show different ads (regarding px size) for different screen resolutions. With the lazy loader it reloads the ad location, i.e. changing a phone from landscape to portrait, and comes up with a now scaled ad that fits best to the new screen resolution - without having the user to reload the whole page just because the ads overlap the new screen resolution, breaking the layout or making the text unreadable. In short - we have to use the lazy loader for this, since there seems to be no alternative to have the mobile styles mobile friendly over all different types of resolutions and devices.
  16. Hey there, I´m really not a developer but I guess my question fits best in here. What´s it all about: Revive offers javascript invocation codes. These codes are the most recommendend as they even can be used for asynch requests. That´s great, but there is a downside with that because the javascript codes contain strings like: "<!--" and " -->" . Why is this a problem? We are using an own local lazy loader to server different ads on different screen resolutions to make our ads mobile friendly. To serve a leaderboard on a mobile device with a resolution of 300px obviously makes no sense. So we are wrapping the ad locations with a lazy loader request and a conditional, that targets the screen resolution: <div class="ad" data-lazyad data-matchmedia="only screen and (min-width: 800px)"> <script type="text/lazyad"> <!-- [HERE GOES THE INVOCATION CODE] --> </script> </div> Of course, we have 4 different requeste per ad location to fit the most used screen resolutions. So we can cover almost 99% of all mobile visitors. Blows up the source code, but heck, it works and by now we couldn´t find a better solution we are capable to implement. As you can see in the lazy loader code above, the lazy loader recognizes the start and end of the ad code by the elements "<!--" and "-->" . If you are now using a javascript invocation code and put this in the lazy loader request, it looks like this - and I guess the problem becomes visible to most of you: <div class="ad" data-lazyad data-matchmedia="only screen and (min-width: 800px)"> <script type="text/lazyad"> <!-- <script type='text/javascript'><!--// <![CDATA[ OA_show(1); // ]]> --></script><noscript><a target='_blank' href='https://xyz.com/1/www/delivery/ck.php?n=96d7740'><img border='0' alt='' src='https://xyz.com/1/www/delivery/avw.php?zoneid=1&amp;n=96d7740' /></a></noscript> --> </script> </div> The request would now be interpreted by the lazy loader like this: <div class="ad" data-lazyad data-matchmedia="only screen and (min-width: 800px)"> <script type="text/lazyad"> <!-- // <![CDATA[<!--<script type='text/javascript'> OA_show(1); // ]]> --> and would create a corrupt request, as the lazy loader would stop "reading" the rest of the request: </script><noscript><a target='_blank' href='https://xyz.com/1/www/delivery/ck.php?n=96d7740'><img border='0' alt='' src='https://xyz.com/1/www/delivery/avw.php?zoneid=1&amp;n=96d7740' /></a></noscript> --> </script> </div> This has forced us all the time to only use iframe invocation tags, since they don´t utilize the "-->" string. Now we want to bundle the javascript requests from 3 to 4 per page to only one call - and unfortunal, this only works with the invocaion code format above with "-->" . Has anyone an idea how to solve that problem? Regards, Sperber.
  17. The group itself is closed, right, but you should see the Join-Button on top. Is this different in the us version of facebook as in our europeans?
  18. Mr. Wigly, what you describe is wether inside the scope of my initial posting nor do I jump your train. May be (?) I´ve got you wrong - but in my world we have bills to pay and creating a free software doesn´t necsessary mean, there will be support. Or this forum. Or a github-project site. Or anything else. Users like me take all benefits from what the coders initially created with OpenX and nowadays with the successor Revive. May be it just sounds to me that way, that you´re takin that for granted - and sure it isn´t. If you ever coded something by yourself, you should be well aware that all participating coders must have put thousands of hours, their knowledge and expertise into this software. Since years and years you can get it and use it - still ! - for free, work with it and we all make money with and through it. And do I understand you correct, that you are now complaining that they´ve build a business upon with additional services? I guess you get paid by your customers like I do, else we both wouldn´t do a thing for them, or? It´s nothing to argue about, when the coders are making some business and money out of what they have created. Support needs time, to be able to spend that time needs another source of income to have the money you meanwhile can live from. Somehow I feel like someone has spent you a gold dime - and you´re now complaining that it´s not polished.. There is an old saying that says it all: Love it, change it or leave it. For me, in terms of support, I´ve decided to try it with "change it".
  19. Hi there, we all can imagine, that the Revive-Team has a hell of work to do and can´t be around the support forums that often. For people running into problems - may it be with upgrading, first timers, experienced ones with more sophisticated problems or even developers which need a helping hand or a hint - this sometimes can be a frustrating experience, to be forced to wait a few days or sometimes weeks, until they receive a reaction to their post. Revive is for free and open source - so you really can´t expect, that there is a professional support around 24/7. The Revive guys have a life, too - or at least they had one before Revive became so popular While waiting for response to a problem I run into, I thought "Hey, why not making a Revive selfhelping group in facebook? Faster replies, far more reach, quicker communication - and may be someone already knows a solution to a problem users may run into." So, in short, I did it and now I´m inviting everyone to the group. I´m just a Revive user so I guess, I am not really someone who could help with bigger problems. But I guess over time there could and will be a nice crowd, some more experienced ones, may be one or the other developer or even someone from the Revive-Team itself (which will be recognizable per the assigned Administrator-Status in the group). You can find it here: https://www.facebook.com/groups/142121312790362/ . I hope Revive don´t mind, that I am using the Revive logo for the group - but what would fit better than this. Hop in - you´re welcome Regards, Chris
  20. So, it´s even getting more weird. Yesterday night - somehow - I managed to get the asynch AdTags working. I guess, so funny it may sound, this was related to disabling tracking for standard html code. Unfortunal, a few hours later Revive refused to deliver the ads, even when the adtags were properly inserted into the website. So this problem persists and I had to switch back to js-tag. Meanwhile I did a little testing, cause our site uses 4 asynch calls for each page. I was thinking wether this could be to much for Revives asynch.php. At least this seems to be one part of the problem. With one asynch active and the rest as js-tags, it worked. Not every time (every third or forth time), but finally the Ads came through. That brings me to the point, wether our machine is deprecated or outdated (8 cores 3.2Ghz, 16 GB...don´t think so with only ~80 active users on website/minute), something went wrong while upgrading or the whole thing could be a part of a possible bug. Guess Erik should have a look into this (if you need site access, please drop me line to my registration mail-adress.) Anyone out there who could confirm this for his Revive instance?
  21. Thanks for your hint, but I´ve already deleted the cache files this this morning without any effect. The code is delivered and inserted into the sites source code, but the ads still won´t appear. Mhm..anyone experienced this before? Weird..
  22. Hi folks, I was becoming wet hands as I found out, 3.2.1 can provide asynchronous tags. Nice work But: I upgraded today without any issue, logged in, created the asynch tags for all of my zones and inserted them in our website. So far so good. When I visit our website I can see how the browser tries to fetch the advertiser-url-sources in the status bar, but in the end not a single Ad appears. This isn´t restricted to one of our advertisers - it´s for all of them. AdSense, Affili, Premium Partners, etc... Somehow I get the feelin that may be I forget to activate something, even when I´m sure the upgrade instructions are pretty idiotproof. Anyone who could help me out with a clever hint? Much appreciated. Regards, Chris.
  23. This morning it went worse. The adserver stopped delievering the content of the ad-code. In the source of the site the call was still in there, but revive deliviered no ads. In a more desperate than smart try, I´ve deleted all generated files in the var-directory that looked like temp and cache files. That worked. Revive is now deliviering ads again - but how long? And what is causing that problem? Do I have to expect that the adserver will crash again, when I´m in the baltic sea with no internet connection? Would really appreciate any help or advice on that issue. Regards, Sperber
  24. I´m a little bit desperate, cause I´m not really in depth familiar with revive. We have installed revive a few months ago and encountered non-displaying ads. I detained the cache to be a problem, so I logged in as administrator and run all of the maintainance tasks. After the very last maintainance job in the line I´d tried to switch back to the manager account and received an error in the browser Content encoding error I remember that the last maintainance job had to do with a utf translation, that should convert content which was not already utf-8 into it. So I guess this did something nasty and thats the reason, why I can´t load revive and receiving this error instead. Has anyone an idea, what I can do now? Sure, I have a backup. But unfortunal thats a month old and since that I have a bunch of new customers, which are all running ads. I have no idea, how many ads everyone has left and even worse, of course the ads are not in the backup included. Is there anything I can do to reverse that last step of the maintainance I described above? Would really appreciate any help - and sorry for my broken english. I´m german and I really don´t have to use it here very often. Regards, Sperber
×
×
  • Create New...