Main Area and Open Discussion > General Software Discussion

Why AdGuard? Why do they detect ad-blockers to begin with?

<< < (2/3) > >>

ital2:
@wraith808: I don't get this. In fact, the page itself (javascript) sends data back, telling the respective server that the ads have not been displayed, or something along these lines. Or/and the other way round, in case of successful display of the ads, the page sends some "ok" string (which may be quite elaborate, unfortunately).

So I understand that these "false positives" I'm asking for would be individual for each such site, which is why this could only be done for those "big" sites of if not universal then at least national appeal (in big nations), like the examples I gave above. Also, the site owners would frequently "update", i.e. modify those "got thru" or "were banned" strings; it'd be a little bit like downloading from Flickr and the like; frequent ad-blocker updates would be needed for given "standard sites", by subscription, for once.

Site owners could monitor what the ad-blockers did, by running a dummy pc with those ad-blockers installed; ad-blockers' developers could monitor the changes in the sent-back strings by running pc's with and without ad-blocking.

Sites would change those strings several times a day in the end; ad-blockers would not keep up (with sending updates).

So that's probably why that isn't done, but if it's NOT a mass market, but a quite confidential one, it'd be doable - the question arises of course how long a reasonably-priced such offer would remain confidential...

(Additional problem: The site owners could encode those strings in some individualized way, according to the page's url, title or the like; basic problem here: we all have accepted that downloaded pages (or even before download) also SENT BACK data; if that was not the case, they simply wouldn't know.)



EDIT: Misunderstanding since I hadn't had in mind everything from my original post. You mean that for processing the advert part(s) of the page, the ad-blocker should sent the page, from the user's pc to the ad-blocker's server, then send the purified core part back; what I had in mind was something like "whiting it all" (since the data is there already, so make it invisible at least, and non-interactive). -

I had in mind that this processing of the ads would be quite simple, technically, and that the ad-blocker, installed as browser add-on, would have the necessary code for doing this, installed on the user's pc: just enough javascript in order to successfully identify the ad-parts, and make them invisible.

Of course, and according to my further thoughts above, it's to be feared that this "whiting" is then detected by some (upgraded, for this new necessity) page code.

What I had in mind, was something less consequential than what's done today, and which would be less detectable, but I suppose that's illusionary, the (spiced-up) page code would be able to detect pixel colors (or its own code to be invalidated), and then some preset, encoded string could be sent.

Of course, there could be another ad-blocking trick being envisioned: NOT interfering up to the full page being displayed (so there is a slight annoyance for the user indeed), THEN "do-it-all", and block any further sending back info to the server, like "bad connection", up to the user asking for some new page, and then ditto as before - in this scenario, the server(s) would get that AFTER each full download, the connection gets bad, and make their conclusions...

Or then, creating (user-pc-sided) a virtual representation, and infering from that, the real one, the server(s) not "getting" that the real representation on the user's screen isn't identical to the virtual page they will have created.

In this context, let's remind ourselves that the ads often come from third-party servers, and that was the aspect I hadn't in my mind; you mean that for bandwidth minimization, the ad-blockers block the download of the ads already.

Hence:

I think there should be possible technical means for those prominent, "special" sites, that you can NOT see without ads today: If I want to see them currently (with a browser exception or in another browser), I have to convene to any download they want to force upon me, anyway, SO the ad-blockers, in these instances, by special option, should NOT block the download (i.e. my traffic would be the same anyway), just block the display (and the interactivity, too) - possibly, there ARE some means for this, along my ideas here, as soon as ad-blockers free themselves from the conception that blocking ads necessarily implies blocking their download, too.

Considering there are "prominent" sites which at the end of the day would be worth the traffic, just not all the visual annoyance.

wraith808:
@wraith808: I don't get this. In fact, the page itself (javascript) sends data back, telling the respective server that the ads have not been displayed, or something along these lines. Or/and the other way round, in case of successful display of the ads, the page sends some "ok" string (which may be quite elaborate, unfortunately).
-ital2 (December 06, 2018, 02:47 PM)
--- End quote ---

No, that's not how this works.  When you open a connection via http to get the ad, it streams it back in the browser.  What the ad blocker is doing is _not_ making that connection at all.  It could make the connection then abort, I suppose, but they can also see how much is transferred if you do that.  It could also stream the ad and not show it, I suppose, replacing the element in the page and streaming it using another connection.  But that would require you to download the ads, which again, is one of the advantages that they tout, i.e. we saved you this much bandwidth.

ital2:
"When you open a connection via http to get the ad" - I'd never do this! ;-) Also, your "they never touch the asset" was completely obscure for me - btw, I hereby copyright the comedy line "Don't touch my assets" (for "my private parts") - you meant they (the ad-blockers) don't download (what you call "stream"?) the ads, from third-party (i.e. not the page's) server? Or better, they intercept/block that download? ("not touching the asset" for "block the download of the ads" was too exotic for me, in order to understand, hence parts of my meanderings; in fact, the ads are the crap, the core page would be the "asset", but I would never tell it that...) ;-)

As far as my knowledge goes, the page is downloaded.

In its html, there is javascript which downloads ads from third-party servers.
(Also, some ads, here and there, can be included within the page html, but that's quite rare.)

Now, before the browser displaying the page (and thus following the download links in the html, too), the ad-blocker purifies the page script and gives it to the browser only then, for the browser to display what's left from the original page script.

Also, the page script sends back info to the page's server, in order for that server to check if everything has been displayed, incl. the ads; the ad-blocker cannot block that sending-back since then the server would know the ads have not been downloaded (and of course, the amount of downloaded (what you call "stream", or is that something different?) bytes can be monitored and sent back to the server.

Since that (in case, encoded) "everything's ok" info sent back to the server could only be sent after everything's fine, I even suppose the core info (i.e. the page to be displayed) isn't even included in what the server sends first, since if it did, the page could be displayed in full - all the info was there already -, even if then there was "problems" with the ad-loading: the server would be unable to stop the page display, even by knewing the ads weren't displayed - but could block the IP address for further downloads then.

The sent amounts of bytes downloaded (streamed???) would be identical, if the page is fully displayed (i.e. with the ads) or not (i.e. without the ads); the difference between download and stream, as far as my knowledge goes, is with download = stored in the browser cache and stream = just displayed on screen, without any storage on the user pc, right?

So I suppose that if download, not stream, there would be means of not displaying the (downloaded) ads, without the page's server knowing about this.

We convene that one of the tasks of the ad-blocker consists in blocking unnecessary traffic, i.e. blocking ads-download (stream???), hence the knowing of blocking of the page's server, by counting.

My argument above concerns pages which are sufficiently important for the user in order for them to accept the traffic caused by additional downloads (streams???), but where they do not want to be visually bothered with all that crap. Hence my idea that for "renowned" "standard" sites, a (reasonably-priced) ad-blocker could, by individual option for every one of these sites (the ones for Germany, I mentioned above), process these sites - IF that was possible along my ideas, without having to cope with every single page individually for that (which would be practically impossible, see above) - differently from the "regular" ones: allow for download/streaming of the ads, but kill/hide them afterwards, and without the page's server knowing about this.

Don't ask me about the advertizer's interest here since in fact, I happen to avoid them whenever possible if they had bothered me before, so it's to their advantage, at the end of the day, if I do NOT see their advertizing; I would not go so far as to say they pay for this favor, though, hence my idea to pay a reasonable fee p.a. for such a spice-up ad-blocker (20 bucks or so).

Also, sending back of info to the third-party, the ads', servers, would be possible, but here again, once they have been downloaded (streamed???) - for these special pages, those advertisers should NOT be able to detect their ads have not been displayed.

Errors of mine, ideas / info of yours? ;-)

wraith808:
"When you open a connection via http to get the ad" - I'd never do this! ;-)
-ital2 (December 07, 2018, 08:57 AM)
--- End quote ---

O...k.  I was referring to from a programming perspective.

As far as my knowledge goes, the page is downloaded.

-ital2 (December 07, 2018, 08:57 AM)
--- End quote ---

It is not.  The assets are processed separately, which is why you might get them at different speeds.  I'm telling you how things work on the internet from experience coding.  There are cases where the images are encoded in the streams, but they wouldn't be for this.  Each asset is streamed separately.

But I don't seem to be helping the conversation, so I'll bow out.

ital2:
"O...k.  I was referring to from a programming perspective." - and since I had perfectly grasped that, I had added the ";-)".

As for the rest, ok, no problem, I don't understand your telegram style anyway, my fault assuredly.


In order to clarify: I never meant the page is in one piece*, but there is a core html code of the page which triggers download of any sorts of elements, be that pics (mostly from the same server) or ads (mostly from other servers), and of course, these disparate elements are downloaded separately, but by the code in the "page source code" (which in case could trigger some server code which then only downloads those elements, or not), BUT there is some group of elements which, together, form the core page, and then there are unwanted elements, ads or others; the term "assets" here is obviously misused for "page elements", and "stream" is left as is, whilst it's obvious from the above there would have been some need to differentiate it from "download".

It's called "playing on words, in order to obfuscate, in order to display knowledge, without giving any knowledge away".

Navigation

[0] Message Index

[#] Next page

[*] Previous page