YouTube showing ads

[bsclifton]

Did you search for similar issues before submitting this one? Yes

Describe the issue you encountered: Reported via support:

I’ve been trialing Brave for the last day or so. I was enjoying no ads on youtube until about the 3rd or 4th clip, then straight up I started getting ads. How do I fix this? The ad blocker is switched on in settings.

I tried some of the video links provided and was unable to reproduce. Maybe related to

Expected behavior:

• Platform (Win7, 8, 10? macOS? Linux distro?): Windows 10
• Brave Version:
• Screenshot if needed:
• Any related issues:

[srirambv]

One more from support

[neeklamy]

Silly question, but worth asking somehow, these are definitely adverts getting through?

I ask because I have been using Brave for many months now, since 0.7, I frequent YouTube, and I’ve yet to see an advert slip through. I haven’t seen any “banner” ads pop up over videos, before the video begins or breaking up a longer video.

I would suggest this could be a few “sponsored by” sections that are part of the video (either at the beginning or end) being mistaken for adverts.

Might be an idea to ask anyone experiencing this to grab a screenshot.

[CliqueBait]

I can confirm for my install. I see no banner ads or ad breaks in the middle of a video. However, I have been seeing the occasional ad at the beginning of videos which need to be skipped in the usual way.

Ubuntu 16.04.1 LTS Brave: 0.12.4 Electron: 1.4.12 libchromiumcontent: 53.0.2785.143 V8: 5.3.332.47 Node.js: 6.5.0 Update Channel: dev

[neeklamy]

@CliqueBait, I’ve checked out the playlist you’re watching (starts here: Does Political Correctness WORK?) I’m up to the 16th video – but nothing!

• Brave 0.12.4
• OS X 10.11.6
• HTML5
• Shields up
  • Show Brave ads
  • Block 3rd Party Cookies
  • Block Phishing / Malware
• Shields down – adverts have to be showing now? Nope!
• Using a private tab

Under a guest account in OS X, I managed to get the adverts to show immediately by dropping the shields or allowing ads and tracking. Maybe this is a stuck setting somewhere, something from a previous version? It might help to blow away Brave’s config files…

[bsclifton]

@neeklamy where are you physically? I see that @CliqueBait is in the UK (thanks for the screenshot, BTW)

I wonder if they are using different code based on the region. I know this is typical because many videos are blocked based on region (and also ads are region aware)

[neeklamy]

@bsclifton, I should have said, I’m in the UK too.

When I was toggling the shields, although it showed that the shields were down, the “Ads and Trackers Blocked” count was still going up, but, no ads were showing. Which as I said, makes me think it seemed like the “ads off” setting was stuck.

At some point the adverts started showing with the shields down, and now I can toggle the shields on and off and get the expected behaviour – not terribly helpful, I know.

[Flo5701]

I have add on Youtube to (I'm in canada), i try with a VPN in sweden and no add

[CliqueBait]

@neeklamy "It might help to blow away Brave's config files..."

Um. That doesn't sound too safe/desirable if I'm going to lose anything I need but I'm willing to inspect the files and roll the dice (with backups) if it looks promising. There's a chance it might work because I've been installing each release over the prior release so there might indeed be a stuck setting somewhere.

Main thing I don't want to do is lose all of my bookmarks. I don't care about other settings. Which files do you want me to inspect/delete?

FYI, I upgraded to Ubuntu 16.10 last Friday 14th Oct.

[reesinkf]

I've always had YouTube ads showing up since I started using Brave (many months ago). I just figured they had not finished the code yet or something (since it's still a beta). It's very very annoying to say the least, and with every update I hoped they started "supporting" YouTube ads...

FYI, I'm in the Netherlands and on Windows 10.

[Dylvn]

I have the same problem for YouTube, the ads at the beginning pop! :) I'm from France for info !

[tcr]

Using Brave, an ad plays on Youtube for me for nearly every video. Located in the US. Happy to perform any tests to help diagnose the problem.

[bbondy]

Where are you located? Would any of the about:adblock regional lists help?

[tcr]

@bbondy I'm located in Boston, MA. I assume that means none of the regional lists would be useful here?

I wonder if Youtube ads are cosmetic adblock ads (which aren't supported yet?) and I'm just unlucky that I get many ads served to me and others get few. If they're URL-based adblock ads, I should be able to type in custom rules in about:adblock and seem them succeed or fail in the Web Debugger.

[bsclifton]

@bbondy I'm curious- does YouTube use Flash if it's available? Is it possible that these are Flash ads getting through? Do you have Flash installed @tcr?

[tcr]

@bsclifton I have Flash installed; but it's not enabled for YouTube, and the ad element being displayed is a <video> element.

I can dump a HTTP log if it's helpful (and if I can figure out how to do it from the Web Console).

[bbondy]

If we can find the URLs of the ads that are serving I can check if they are in the adblock list.

[tcr]

Looking into it, it seems to be serving from the same servers as YouTube videos. It skips two doubleclick domain requests successfully, then originates a video request from YouTube's servers. It might be the case that adblock is working fine and that the current adblock rules just don't work if they are routed through the normal video servers.

Also, it only serves ads when I am logged in. Logging out or a new session tab works fine. So I believe the block is working fine. Maybe cosmetic (HTML selector) rule support will fix this.

This video reproduces the issue 80% of the time for me: https://www.youtube.com/watch?v=cAo9o7zV24A

[Flo5701]

with the new update i have no add on youtube !

[CliqueBait]

Still an issue for me unfortunately:

Ubuntu 16.10 Brave: 0.12.7 Electron: 1.4.20 libchromiumcontent: 53.0.2785.143 V8: 5.3.332.47 Node.js: 6.5.0 Update Channel: dev

[srirambv]

I had not experienced this till today but I suddenly see the Ad on YouTube. Took almost couple hours of running videos for the ad to show up.

[bsclifton]

Another user reported this issue with https://github.com/brave/browser-laptop/issues/5457

• Windows 10
• Brave 0.12.7

Screen cap of issue:

[KronemeyerJoshua]

Yep. Still an issue in 0.12.8 Windows 10 Please don't make me watch scientology ads. xD

[BrendanEich]

A friendly with ad-tech chops has analyzed what's going on, hoping he'll update here shortly.

Cosmetic filters is #344 but this bug has priority and can be fixed without those, we think.

[pixelass]

I just noticed ads in the search results

[bsclifton]

+1 from support

[bsclifton]

No assignee- pushing to 0.13.1

[lukemulks]

I've been taking a look at this, primarily from autoplay on page landing.

This URL was where I did a majority of review: https://www.youtube.com/watch?v=jremlZvNDuk&feature=youtu.be

What appears to be happening, is that YT has deployed a set "prototype" labeled features for the html5 player, which the ads are a component of (referenced as INNERTUBE).

Within the watch.js player resource, there are now ad blocking functions and messaging that weren't present in the past:

   Lya = function() {
        D0("AD_BLOCKER_MESSAGING_EVENT_TYPE_LEARN_HOW");
        E0();
        g.nn(F0, !1)
    }
    ;
    Mya = function() {
        D0("AD_BLOCKER_MESSAGING_EVENT_TYPE_DISMISSED");
        E0();
        g.nn(F0, !1)
    }
    ;
    D0 = function(a) {
        var b = g.lg();
        b && (a = {
            displayPeriodMs: (0,
            g.Yf)() - Nya,
            adBlockerMessagingEventType: a,
            clientScreenNonce: b
        },
        g.In("adBlockerMessaging", a))
    }
    ;

There are a few additional flags that are specific to ad blocking now appearing in certain playback errors and conversion events. Those are definitely new.

Call Sequence & Resolution YT attempts to make the expected ad requests. When those fail, YT fails over into a separate sequence of request events.

This call is used for the Google API to get location and ads api data

Request URL:https://apis.google.com/_/scs/abc-static/_/js/k=gapi.gapi.en.FgPLF5SwqIU.O/m=gapi_iframes_style_slide_menu/exm=card,gapi_iframes/rt=j/sv=1/d=1/ed=1/rs=AHpOoo-9R8fkhlRsCMrG4wpDzgf1RI7BzQ/cb=gapi.loaded_1
Request Method:GET
Status Code:200 
Remote Address:127.0.0.1:8888

Response Headers 
age:613172
alt-svc:quic=":443"; ma=2592000; v="35,34"
cache-control:public, max-age=31536000
content-encoding:gzip
content-length:3509
content-type:text/javascript; charset=UTF-8
date:Mon, 12 Dec 2016 06:13:47 GMT
expires:Tue, 12 Dec 2017 06:13:47 GMT
last-modified:Fri, 02 Dec 2016 02:44:02 GMT
server:sffe
status:200
vary:Accept-Encoding
x-content-type-options:nosniff
x-xss-protection:1; mode=block

This call is made to autoplay

Request URL:https://s.ytimg.com/yts/jsbin/www-en_US-vfloDMEq8/watch_autoplayrenderer.js
Request Method:GET
Status Code:200 
Remote Address:127.0.0.1:8888

Response Headers
age:342888
alt-svc:quic=":443"; ma=2592000; v="35,34"
cache-control:public, max-age=691200
content-encoding:gzip
content-length:1852
content-type:text/javascript
date:Thu, 15 Dec 2016 09:18:31 GMT
expires:Fri, 23 Dec 2016 09:18:31 GMT
last-modified:Thu, 15 Dec 2016 08:48:14 GMT
server:sffe
status:200
timing-allow-origin:https://www.youtube.com
vary:Accept-Encoding, Origin
x-content-type-options:nosniff
x-xss-protection:1; mode=block

This YT JS API call is made to query & autoload the AD MODULE

Request URL:https://www.google.com/jsapi?autoload=%7B%22modules%22%3A%5B%7B%22name%22%3A%22ads%22%2C%22version%22%3A%221%22%2C%22callback%22%3A%22(function()%7B%7D)%22%2C%22packages%22%3A%5B%22content%22%5D%7D%5D%7D
Request Method:GET
Status Code:200 
Remote Address:127.0.0.1:8888

Response Headers
alt-svc:quic=":443"; ma=2592000; v="35,34"
cache-control:private, max-age=3600, must-revalidate
content-encoding:gzip
content-length:6147
content-type:text/javascript; charset=utf-8
date:Mon, 19 Dec 2016 08:33:19 GMT
expires:Mon, 19 Dec 2016 08:33:19 GMT
server:GSE
status:200
vary:Accept-Encoding
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-xss-protection:1; mode=block

Query String: 
autoload:{"modules":[{"name":"ads","version":"1","callback":"(function(){})","packages":["content"]}]}

OK - so the above call handles the AD MODULE (we should try blocking ^^^), the actual GPT (doubleclick ads) request is handled atypically when the ad blocking is enabled.

Instead of this being a standard request and response code, the GPT request is made as a 307 Internal Redirect, which responds with a base64 JS Application (embed):

Request URL:http://www.googletagservices.com/tag/js/gpt.js
Request Method:GET
Status Code:307 Internal Redirect

Location:data:application/javascript;base64,KGZ1bmN0aW9uKCkgeyB2YXIgcDsgdmFyIG5vb3BmbiA9IGZ1bmN0aW9uKCkgeyB9OyB2YXIgbm9vcHRoaXNmbiA9IGZ1bmN0aW9uKCkgeyByZXR1cm4gdGhpczsgfTsgdmFyIG5vb3BudWxsZm4gPSBmdW5jdGlvbigpIHsgcmV0dXJuIG51bGw7IH07IHZhciBub29wYXJyYXlmbiA9IGZ1bmN0aW9uKCkgeyByZXR1cm4gW107IH07IHZhciBub29wc3RyZm4gPSBmdW5jdGlvbigpIHsgcmV0dXJuICcnOyB9OyB2YXIgY29tcGFuaW9uQWRzU2VydmljZSA9IHsgYWRkRXZlbnRMaXN0ZW5lcjogbm9vcHRoaXNmbiwgZW5hYmxlU3luY0xvYWRpbmc6IG5vb3Bmbiwgc2V0UmVmcmVzaFVuZmlsbGVkU2xvdHM6IG5vb3BmbiB9OyB2YXIgY29udGVudFNlcnZpY2UgPSB7IGFkZEV2ZW50TGlzdGVuZXI6IG5vb3B0aGlzZm4sIHNldENvbnRlbnQ6IG5vb3BmbiB9OyB2YXIgUGFzc2JhY2tTbG90ID0gZnVuY3Rpb24oKSB7IH07IHAgPSBQYXNzYmFja1Nsb3QucHJvdG90eXBlOyBwLmRpc3BsYXkgPSBub29wZm47IHAuZ2V0ID0gbm9vcG51bGxmbjsgcC5zZXQgPSBub29wdGhpc2ZuOyBwLnNldENsaWNrVXJsID0gbm9vcHRoaXNmbjsgcC5zZXRUYWdGb3JDaGlsZERpcmVjdGVkVHJlYXRtZW50ID0gbm9vcHRoaXNmbjsgcC5zZXRUYXJnZXRpbmcgPSBub29wdGhpc2ZuOyBwLnVwZGF0ZVRhcmdldGluZ0Zyb21NYXAgPSBub29wdGhpc2ZuOyB2YXIgcHViQWRzU2VydmljZSA9IHsgYWRkRXZlbnRMaXN0ZW5lcjogbm9vcHRoaXNmbiwgY2xlYXI6IG5vb3BmbiwgY2xlYXJDYXRlZ29yeUV4Y2x1c2lvbnM6IG5vb3B0aGlzZm4sIGNsZWFyVGFnRm9yQ2hpbGREaXJlY3RlZFRyZWF0bWVudDogbm9vcHRoaXNmbiwgY2xlYXJUYXJnZXRpbmc6IG5vb3B0aGlzZm4sIGNvbGxhcHNlRW1wdHlEaXZzOiBub29wZm4sIGRlZmluZU91dE9mUGFnZVBhc3NiYWNrOiBmdW5jdGlvbigpIHsgcmV0dXJuIG5ldyBQYXNzYmFja1Nsb3QoKTsgfSwgZGVmaW5lUGFzc2JhY2s6IGZ1bmN0aW9uKCkgeyByZXR1cm4gbmV3IFBhc3NiYWNrU2xvdCgpOyB9LCBkaXNhYmxlSW5pdGlhbExvYWQ6IG5vb3BmbiwgZGlzcGxheTogbm9vcGZuLCBlbmFibGVBc3luY1JlbmRlcmluZzogbm9vcGZuLCBlbmFibGVTaW5nbGVSZXF1ZXN0OiBub29wZm4sIGVuYWJsZVN5bmNSZW5kZXJpbmc6IG5vb3BmbiwgZW5hYmxlVmlkZW9BZHM6IG5vb3BmbiwgZ2V0OiBub29wbnVsbGZuLCBnZXRBdHRyaWJ1dGVLZXlzOiBub29wYXJyYXlmbiwgcmVmcmVzaDogbm9vcGZuLCBzZXQ6IG5vb3B0aGlzZm4sIHNldENhdGVnb3J5RXhjbHVzaW9uOiBub29wdGhpc2ZuLCBzZXRDZW50ZXJpbmc6IG5vb3Bmbiwgc2V0Q29va2llT3B0aW9uczogbm9vcHRoaXNmbiwgc2V0TG9jYXRpb246IG5vb3B0aGlzZm4sIHNldFB1Ymxpc2hlclByb3ZpZGVkSWQ6IG5vb3B0aGlzZm4sIHNldFRhZ0ZvckNoaWxkRGlyZWN0ZWRUcmVhdG1lbnQ6IG5vb3B0aGlzZm4sIHNldFRhcmdldGluZzogbm9vcHRoaXNmbiwgc2V0VmlkZW9Db250ZW50OiBub29wdGhpc2ZuLCB1cGRhdGVDb3JyZWxhdG9yOiBub29wZm4gfTsgdmFyIFNpemVNYXBwaW5nQnVpbGRlciA9IGZ1bmN0aW9uKCkgeyB9OyBwID0gU2l6ZU1hcHBpbmdCdWlsZGVyLnByb3RvdHlwZTsgcC5hZGRTaXplID0gbm9vcHRoaXNmbjsgcC5idWlsZCA9IG5vb3BudWxsZm47IHZhciBTbG90ID0gZnVuY3Rpb24oKSB7IH07IHAgPSBTbG90LnByb3RvdHlwZTsgcC5hZGRTZXJ2aWNlID0gbm9vcHRoaXNmbjsgcC5jbGVhckNhdGVnb3J5RXhjbHVzaW9ucyA9IG5vb3B0aGlzZm47IHAuY2xlYXJUYXJnZXRpbmcgPSBub29wdGhpc2ZuOyBwLmRlZmluZVNpemVNYXBwaW5nID0gbm9vcHRoaXNmbjsgcC5nZXQgPSBub29wbnVsbGZuOyBwLmdldEFkVW5pdFBhdGggPSBub29wYXJyYXlmbjsgcC5nZXRBdHRyaWJ1dGVLZXlzID0gbm9vcGFycmF5Zm47IHAuZ2V0Q2F0ZWdvcnlFeGNsdXNpb25zID0gbm9vcGFycmF5Zm47IHAuZ2V0RG9tSWQgPSBub29wc3RyZm47IHAuZ2V0U2xvdEVsZW1lbnRJZCA9IG5vb3BzdHJmbjsgcC5nZXRTbG90SWQgPSBub29wdGhpc2ZuOyBwLmdldFRhcmdldGluZyA9IG5vb3BhcnJheWZuOyBwLmdldFRhcmdldGluZ0tleXMgPSBub29wYXJyYXlmbjsgcC5zZXQgPSBub29wdGhpc2ZuOyBwLnNldENhdGVnb3J5RXhjbHVzaW9uID0gbm9vcHRoaXNmbjsgcC5zZXRDbGlja1VybCA9IG5vb3B0aGlzZm47IHAuc2V0Q29sbGFwc2VFbXB0eURpdiA9IG5vb3B0aGlzZm47IHAuc2V0VGFyZ2V0aW5nID0gbm9vcHRoaXNmbjsgdmFyIGdwdCA9IHdpbmRvdy5nb29nbGV0YWcgfHwge307IHdpbmRvdy5nb29nbGV0YWcuZGVzdHJveVNsb3RzID0gZnVuY3Rpb24gKCkgeyB9OyB2YXIgY21kID0gZ3B0LmNtZCB8fCBbXTsgZ3B0LmFwaVJlYWR5ID0gdHJ1ZTsgZ3B0LmNtZCA9IFtdOyBncHQuY21kLnB1c2ggPSBmdW5jdGlvbihhKSB7IHRyeSB7IGEoKTsgfSBjYXRjaCAoZXgpIHsgfSByZXR1cm4gMTsgfTsgZ3B0LmNvbXBhbmlvbkFkcyA9IGZ1bmN0aW9uKCkgeyByZXR1cm4gY29tcGFuaW9uQWRzU2VydmljZTsgfTsgZ3B0LmNvbnRlbnQgPSBmdW5jdGlvbigpIHsgcmV0dXJuIGNvbnRlbnRTZXJ2aWNlOyB9OyBncHQuZGVmaW5lT3V0T2ZQYWdlU2xvdCA9IGZ1bmN0aW9uKCkgeyByZXR1cm4gbmV3IFNsb3QoKTsgfTsgZ3B0LmRlZmluZVNsb3QgPSBmdW5jdGlvbigpIHsgcmV0dXJuIG5ldyBTbG90KCk7IH07IGdwdC5kaXNhYmxlUHVibGlzaGVyQ29uc29sZSA9IG5vb3BmbjsgZ3B0LmRpc3BsYXkgPSBub29wZm47IGdwdC5lbmFibGVTZXJ2aWNlcyA9IG5vb3BmbjsgZ3B0LmdldFZlcnNpb24gPSBub29wc3RyZm47IGdwdC5wdWJhZHMgPSBmdW5jdGlvbigpIHsgcmV0dXJuIHB1YkFkc1NlcnZpY2U7IH07IGdwdC5wdWJhZHNSZWFkeSA9IHRydWU7IGdwdC5zaXplTWFwcGluZyA9IGZ1bmN0aW9uKCkgeyByZXR1cm4gbmV3IFNpemVNYXBwaW5nQnVpbGRlcigpOyB9OyB3aW5kb3cuZ29vZ2xldGFnID0gZ3B0OyB3aGlsZSAoIGNtZC5sZW5ndGggIT09IDAgKSB7IGdwdC5jbWQucHVzaChjbWQuc2hpZnQoKSk7IH0gfSkoKTs=
Non-Authoritative-Reason:Delegate

When the base64 js application is decoded, it reveals several GPT API functions and services that appear to null, but then also includes a destroySlots service (clearing the deck) which appears to be designed to throw an error on default, and follow with a legit GPT request for the ads: note: these all pick up after the destroySlots service

var cmd = gpt.cmd || [];
    gpt.apiReady = true;
    gpt.cmd = [];
    gpt.cmd.push = function(a) {
        try {
            a();
        } catch (ex) {}
        return 1;
    }
    ;
    gpt.companionAds = function() {
        return companionAdsService;
    }
    ;
    gpt.content = function() {
        return contentService;
    }
    ;
    gpt.defineOutOfPageSlot = function() {
        return new Slot();
    }
    ;
    gpt.defineSlot = function() {
        return new Slot();
    }
    ;
    gpt.disablePublisherConsole = noopfn;
    gpt.display = noopfn;
    gpt.enableServices = noopfn;
    gpt.getVersion = noopstrfn;
    gpt.pubads = function() {
        return pubAdsService;
    }
    ;
    gpt.pubadsReady = true;
    gpt.sizeMapping = function() {
        return new SizeMappingBuilder();
    }
    ;
    window.googletag = gpt;
    while (cmd.length !== 0) {
        gpt.cmd.push(cmd.shift());
    }
})();

The GPT API sets new slots to replace the destroyed one, readies the command and pushes the function call. This appears to be YTs answer to ad blocking, by probing for failure and falling back to a last of line embed method that initiates a call from the embedded js application, which shows up as "no domain" (avoids domain-level blocklists)

For Blocking, I'd suggest trying these two things, if possible:

1. Block the ad module api call:

   Request URL:https://www.google.com/jsapi?autoload=%7B%22modules%22%3A%5B%7B%22name%22%3A%22ads%22%2C%22version%22%3A%221%22%2C%22callback%22%3A%22(function()%7B%7D)%22%2C%22packages%22%3A%5B%22content%22%5D%7D%5D%7D
   Request Method:GET
   Status Code:200 
   Remote Address:127.0.0.1:8888

2. I'm unsure if it is possible to detect/block this, but if it's possible to detect the gpt.js 307 internal redirect request and block it before it can embed the response, that would be the other half of the blocking equation:

   Request URL:http://www.googletagservices.com/tag/js/gpt.js
   Request Method:GET
   Status Code:307 Internal Redirect

I would think that the googletagservices call would be blocked, but I believe it's being called in an atypical way that may be evading domain-level blocking. It appears that the JS API request and the watch.js YT player config are designed to work together to form and send the ad request, and uses the autoplay call as a trigger.

Apologies for the length here, but this one required a bit of unpacking to get to the bottom of. Definitely let me know if there are any questions, or anyone needs a set of eyes on reviewing an update.

[bbondy]

We're currently using a stub for googletagservices.com/tag/js/gtp.js https://github.com/brave/browser-laptop/blob/master/js/data/siteHacks.js#L96

You could try modifying that to cancel: true instead to see if it helps in this case. I think canceling globally across sites would probably cause some webcompat problems, but we could do it only here if that helps.

[lukemulks]

Thanks!

Oh, I see what you mean re: the stub (saw the post on ublock about it, didn't connect that it was being used here too).

Will test with the call cancelled and report back.

On Dec 21, 2016 6:42 AM, "Brian R. Bondy" notifications@github.com wrote:

We're currently using a stub for googletagservices.com/tag/js/gtp.js https://github.com/brave/browser-laptop/blob/master/js/ data/siteHacks.js#L96

You could try modifying that to cancel: true instead to see if it helps in this case. I think canceling globally across sites would probably cause some webcompat problems, but we could do it only here if that helps.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/brave/browser-laptop/issues/4693#issuecomment-268538969, or mute the thread https://github.com/notifications/unsubscribe-auth/AIkDKBiPI9KEj88zw_VTozhjgXV4PyCjks5rKTrrgaJpZM4KUPn2 .

[bbondy]

You might have to comment out the sitehack and then just use the custom adblock rules in about:adblock. Thanks!

[DivineOmega]

I can confirm this issue is still present in Brave 0.13.0 rev 9c55eca, running on Ubuntu 16.04.

[joekaiser]

I'm just adding another report of it.

Brave 0.12.15 Muon 1.4.31 libchromiumcontent 53.0.2785.143 V8 5.3.332.47 Node.js 6.5.0 Update Channel dev os.platform win32 os.release 10.0.14393 os.arch x64

[luixxiul]

@lukemulks do you think the issue is caused by the issue concerning QUIC?

[lukemulks]

Yeah, @suguru the update in the 0.13 RC resolves in testing/QA as long as cache and cookies are cleared in the browser. 3 testers yesterday observed the issue as corrected in the RC, so we should be able to close this once RC pushes to prod.

On Jan 26, 2017 8:09 AM, "Suguru Hirahara" notifications@github.com wrote:

@lukemulks https://github.com/lukemulks do you think the issue is caused by the issue concerning QUIC?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/brave/browser-laptop/issues/4693#issuecomment-275429398, or mute the thread https://github.com/notifications/unsubscribe-auth/AIkDKOltAtOmsVqumhk8KO_InxZzW4j2ks5rWMUlgaJpZM4KUPn2 .

[luixxiul]

OK then let's close this thanks to #6831

[luixxiul]

I labelled QA/no-qa-needed but let's keep an eye on the issue on youtube and reopen if the problem would still persist.

[echosa]

I updated to 0.13.0 earlier today. I'm still seeing YouTube ads. Shields are up. I cleared all my cache/cookies/history, based on previous comments in this issue. Still seeing ads.

[lukemulks]

@echosa can you please provide us with a little more info on the ads you're seeing, and a screenshot (if possible)?

• Are you observing display (static) ads, or is this a video ad you're observing?

• Which OS are you observing this from?

• If possible, can you provide a rough geo-region (doesn't have to be extremely specific, you can even let us know if within the US or outside of the US, but would help).

• Can you also let us know if you were authenticated w/Google when you observed the ads, or if you viewed them w/o being signed in?

Thanks in advance.

[echosa]

It was this video: https://www.youtube.com/watch?v=gneBUA39mnI

I didn't get a screenshot, and viewing the video a second time doesn't show the ad. (That's normal.) When it happens again, I'll try to get a screenshot.

It was a video ad before the actual video. I was able to skip it after 5 seconds, as usual.

OS X 10.11.6

I'm in Texas, so inside the US.

[lukemulks]

Thanks for the info @echosa! Really appreciate it.

I've just attempted to repro across 20 clips, and am not seeing any ads so far.

Will try from the URL provided and see if we're able to repro from our end. I'm checking from Windows, so I will see if we can get some OS testers to attempt to repro as well.

Do you have Flash enabled in your browser?

[echosa]

I do have Flash enabled. However, I just tried a few videos myself, using links from other comments in this issue as well as some random videos I could fine, and it looks like the pre-roll ads are being blocked. It looked like, on a couple of videos, I saw the pre-roll ad flash for just a moment before the video started, so it seems like ads are being actively suppressed. Maybe just that one I saw got through somehow. I'll keep a look out for ads, and if I see any, I'll respond back here. I'm happy to answer any other questions you might have.

[lukemulks]

@echosa Thank you very much for all of the feedback and info.

I've probably gone through ~40 videos by now and have not been able to repro, but do not have flash enabled in Brave.

I'm going to see if I can get a tester in OSX w/flash enabled to repro.

It sounds like based on your description these ads are being actively suppressed over time, which is a good sign.

[echosa]

@lukemulks Ok, I just had an ad on YouTube again. Shields up. I got a screenshot that shows the URL, the ad, and the fact that shields are, indeed, up.

[lukemulks]

Thank you @echosa - we had some additional team members on OS X attempt to reproduce on Friday, and were unable to. I am going to dig in further and attempt to reproduce (and inspect the player config in case for some reason there may have been a change post-update).

Aside from your valuable feedback, we have only had one additional case where someone reported seeing a YT ad since the update pushed, which appears to have been resolved from the cache clearing.

Looks like these are the specific playback conditions, but please let me know if I am missing anything:

• Mac OSX
• Flash enabled in Brave (v0.13.0)
• Logged into Google/YouTube
• Autoplay is disabled
• Shields Up: Block Ads, Block Cookies

Two things I am wondering if you could provide if possible @echosa

1. Can you please screenshot the shield settings exactly how you have them enabled during the ad playback

2. Can you also please screenshot the About Brave version panel?

Our team has run through over 80 video clips across Windows, MacOS, Linux,, so I want to make sure we capture the exact conditions (as close as possible) to reproduce so we can find any potential outlying conditions.

Thanks again for your persistence and attention on this.

[echosa]

FYI: I just went back to the video to get a screenshot of the shield settings, and I got the same ad again, so it's happened twice.

All of your bullet points look good. I'd add one more in, just in case it matters. I'm watching the video in Theater Mode, as you can see. Also, keep in mind I'm on OS X 10.11.6, not macOS 10.12.x.

Here are the screenshots you asked for:

[lukemulks]

@echosa thanks for the screenshots and addt'l info. Will work to repro to these same conditions and follow up.

[reesinkf]

I still get ads aswell. I've put the images on imgur: http://imgur.com/a/JFZ8U

I didn't have flash enabled though. I just enabled it after reading the last few posts, and I just got another ad so I guess this doesn't change anything for me.

[lukemulks]

@reesinkf thanks for reporting.

Can you confirm if you'd cleared cache and cookies after installing v0.13.0.

Thanks!

[JamieHitGub]

Just to add, I'm having the same problem on Sierra. I am based in London, Uk. Tried VPN'ing around the world and I have the problem regardless of geo. Tried clearing cache/cookies after the update but it's the same.

[lukemulks]

Thanks @JamieHitGub

Can you confirm if you have Widevine & Flash enabled?

@reesinkf can you also confirm if you have cleared cookies and cache after updating, v0.13.0 (and are seeing ads after clearing and relaunch)