Problem with easyjet site / safari on lan wifi with dns set to rpi pihole

[amerton]

Expected Behaviour:

Visit easyjet.com home page. On the upper right of the page there is a link to one's bookings (sign in in English / vos réservations on French) When one clicks on the link it should link to a login screen.

Actual Behavior:

Nothing happens. This has been tested on my Mac (latest safari/OS X) and on my iPad, dns set to the rpi.

If on the iPad I then connect to Internet using my iPhone's hotspot and clear the easyjet site data in the safari settings and reload the page, everything works as expected, the login page appears.

Steps to reproduce this issue:

If from the hotspot connection I revert to the lan wifi with dns set to rpi, clear the safari data again and reload the page, same problem again...

If I can provide more info, just let me know... But I checked in the pihole log when clicking on link but there doesn't seem to be anything there that relates...

[dschaper]

Thanks for the report, taking a look at it right now...

[amerton]

One other thing : in the not working configuration, one can link to the login screen by right-click/open link in new window...

[dschaper]

It seems like the links that are https are having issues... Trying a few tools to track down where the problem lies...

[amerton]

I am also running an nginx reverse proxy on the rpi with self generated keys. I sudo service nginx stop and cleared the easyjet site data in safari but no change to behavior.

[dschaper]

I'm getting the same non-working link behavior, and then opening link in new tab works fine. I think it has something to do with the https but I'm still trying to track down...

[amerton]

Btw, many thanks for pihole. It's amazingly fast and cool!

[PromoFaux]

Can confirm, right click-> open in new tab works.

So does whitelisting www.google-analytics.com and google-analytics.com

[PromoFaux]

Some sites just don't work as expected with google-analytics blocked. Which is a bit of a pain if you don't want them tracking you.

[dschaper]

I was hoping it wasn't going to be that...

[amerton]

I'd be interested when the time comes to get some kind of tech feedback on what happens... TIA!

[PromoFaux]

What I imagine is happening (in this case at least) Is that easy-jet want to gather statistics on their site. Including (but not limited to) Time you spend on the site, what buttons you press in order to do things etc etc.

If the sign in button is waiting for a response from google-analytics before sending you onto the requested page, it's not going to work with pi-hole out of the box because that domain is generally blocked on the blocklists we use.

This might not be a completely technical explanation (or indeed, correct!) but it's just how I've made sense of it :)

[dschaper]

What throws me is the fact that you can Open in a new Tab and get the right behavior... I noticed that if I whitelisted levexis.com I still got hits for that domain in the /var/log/lighttpd/access.log even though those requests shouldn't have been sent to lighttpd?

[dschaper]

res.levexis.com

[PromoFaux]

I'm imagining there is some kind of javascript wrapper that intercepts all link clicks... possibly. I don't know. I could be talking out of my rear end.

[amerton]

Yep, white listed google-analytics thingie and works as expected :-|

[dschaper]

Lol, I was trying to intercept the calls via the Development Panel, but with the uglified JS it's a pain to try to reverse engineer... But if whitelisting google-analytics solves it then this is something to look at later...

[amerton]

I initially opened a ticket with easyjet support. Worth it to report to them that they are unable to do business with folks to don't want to be Google analytics tracked?

[PromoFaux]

It's a difficult one.

In return for data-harvesting on google's behalf, easjet get loads of valuable data about the effectiveness of their website. At this stage, I don't see them not using it. At the end of the day, those of us that would rather not be tracked have to find work-arounds for now. (like Opening the link to sign in directly in a new tab)

One day that may change, but I'm pretty sure I read somewhere that as few as 10% of all web users even use adblockers. They're not going to budge. Yet.

[amerton]

Left them this reply, FWIW...

Problem identified. You can report to your site manager that you are banning people who filter out google analytics calls to do business with you...

[PromoFaux]

Stick it to the man, man :)

Can I close this off as resolved?

[amerton]

Sure!

Any way to have pihole mimick return from GA in some future version? Or does that start to enter grey areas legal-wise?

Thanks for your help, and again, for your super cool pihole!

[PromoFaux]

Grey area in general. If we can return content in place of actual content, what's to say we wont be malicious with it (I mean, we wont. but... ) We're here to block ads and trackers. And that's it.

With the Easyjet site in particular I think i've tracked it down to this script specifically the following extract:

}(Tracking || (Tracking = {})),
function(n) {
    var t = function() {
        function n(n) {
            this._tracker = n;
            $jq(document).ready(this.AttachLinkClickHandlers.bind(this))
        }
        return n.prototype.AttachLinkClickHandlers = function() {
            var n = this;
            $jq("a").click(function() {
                var t = $jq(this);
                if (n.ShouldTrackLink(t)) return n.TrackLink(t)
            })
        }, n.prototype.ShouldTrackLink = function(n) {
            var t = n.attr("href"),
                i;
            return !t || t.charAt(0) == "#" || t.match(/^javascript:/i) ? !1 : (i = n.attr("class"), i != null && i.indexOf("noTrack") >= 0) ? !1 : !0
        }, n.prototype.TrackLink = function(n) {
            var i = n.attr("href"),
                t = n.attr("target") == "_blank";
            return this._tracker.TrackLinkClick(i, t), t
        }, n
    }();

which appears to be adding tracking handlers to all links. If you use a browser extension (such as Scriptsafe for Chrome, or NoScript for Firefox... not sure about iPads) and block all scripts being loaded, then the links work as expected.

[dschaper]

I'm not sure on legal issues, but if the cookies/responses are sent via https then any attempt to mimic them will throw an error in the browser...