Author Topic: akamai... and web beacons  (Read 2105 times)

xartica

  • Newbie
  • *
  • Posts: 38
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • Email
akamai... and web beacons
« on: May 22, 2002, 07:44:29 AM »
As far as privacy goes, I normally "shrug off" any worries about "web bugs".
Today, however, I got to thinking: even if the buggers are "harmless enough" they are STEALING tcp connections -- thereby delaying the loading of other page elements, eh?

I've seen configs where Proxxers are blocking akamai altogether, but I don't see that as a feasible option. They carry (cache) a lot of valid content for many sites I visit, especially imagefiles.

By the time I cobbled this filter to address the immediate problem
(akamai... slash partnername and/or ad-client account number ...clear.gif)
the thought process brought a whole bunch of questions and thoughts I'd like to discuss.

Name = "strip Akamai web beacons"
Active = FALSE
Multi = TRUE
Bounds = "<i(m(g|age)|nput)s*>"
Limit = 512
Match = "1 src=$AV( 2 akamai 3)&
      *(
        height=$AV([#1-15])
        |width=$AV([#1-15])
        |clear.gif
        |style=$AV(*(hidden|none))
       )*
       $SET(9=CAVEAT: hidden property may be assigned via external CSS)"
Replace = "
 <!-- SUSPECTED akamai web beacon nixed -->
"

Question:
What about OBJECT, APPLET and EMBED tags?

Question:
What about DHTML runtime replacements?
(ala document.links[1].whatever.innerText = "URL of element not prox-parsed when the page loaded")

Question:
What about URL strings assigned via variables, declared within external script files? One example I've seen is:
{snip}
imgsRoot = 'http://a1208.g.akamai.net/g/7/1208/380/1d/sportsillustrated.cnn.com';
{snip}



 
 

sidki3003

  • Sr. Member
  • ****
  • Posts: 476
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • http://
    • Email
akamai... and web beacons
« Reply #1 on: May 22, 2002, 01:56:53 PM »
Good idea to finally address this akamai annoyance
I have no answers, but questions to your filter myself:

Why do you assign variables /1 /2 /3 /9 if you don't (yet?) use them?
Did you encounter beacons scaled 5-15 by X?
Just searched my logs, but couldn't find a matching example. Do you have a URL at hand?

<edit>
I mean a URL that triggers your filter, not the beacon itself
Maybe my logs don't show anything, because i have a 0-4 by 0-4 off-site webbug filter at work.
</edit>

regards, sidki


Edited by - sidki3003 on 22 May 2002  15:14:00
 

xartica

  • Newbie
  • *
  • Posts: 38
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • Email
akamai... and web beacons
« Reply #2 on: May 22, 2002, 05:17:18 PM »
Thanks for the reply.

I periodically grab & examine the TempInternetFiles from a gaming PC
that my son runs outside our home firewall. Here's an example an "in-the-wild" of an occurrence found in his cache. It is apparently from the www.ah-ha.com site:

[ IMG SRC="http://a1356.g.akamai.net/f/1356/6149/7d/partner.ah-ha.com/images/clear.gif" HEIGHT="2" WIDTH="1" ]

I think I have "ah-ha.com" in my AdDomains blocklist.
(It's a crappy schmooze/pay -for-ranking search engine site)
You should be able to trigger the filter by visiting there.

positional variables:
The $SET thingie is just a way of placing a reminder/comment mid-filter.

All the others reflect my habit of using positional vars in place of asterisks while developing a filter (I tend to insert replacements like "___1___2___" so that I can quickly see the result in a page's view-source or in the replacement box of the Prox filter test window. I just forgot to change them to asterisks before posting this "finished" filter. Think there's much performance impact by leaving in the positional variables? I played with this a while back, and can't remember seeing much difference (vars vs asterisks).

size (height/width dimensions):
In all my other filters, I've chosen to ignore dimensions when filtering.
For instance, my version of "kill offsite images" removes ALL images. Through the years of dialup 'net access, I learned to use (and to appreciate, when surfing) webpages that preload images which will be required within a page later in the pageset... so I don't want to "punish" the continued practice of preloading. Even with a cable modem, pageloads at sites (art sites) that employ preloading can seem quite a bit "snappier".
-=-
In this filter though, the rationale is that if I visit a site frequently and know that ALL their images are Akamai-cached, I'll list 'em in a bypass list called by the filter. For other/unknown sites, I guess I'm willing to "lose" the little images (whether they're innocuous or not) for the sake of not tying up so many concurrent TCP connections. This would seem to suit the "way I surf", continually shift-clicking links and tabbing between scads of browser windows (rather than [cough] patiently waiting for each page to load).
I don't know yet if the difference in load-time will be noticable.

Although I found dozens of references to "clear.gif" I'm sure Akamai has several other "reusable" beacon images in their stable. As the filter evolves, instead of "OR -ing " the size and filname arguments, maybe I'll "AND" them,
and just ennumerate the known "reusable" image filenames.

 
 

sidki3003

  • Sr. Member
  • ****
  • Posts: 476
    • ICQ Messenger -
    • AOL Instant Messenger -
    • Yahoo Instant Messenger -
    • View Profile
    • http://
    • Email
akamai... and web beacons
« Reply #3 on: May 22, 2002, 07:12:59 PM »
Thank you for your detailed explanation, i got your point.

As to the use of variables, i didn't notice a filter slowdown when using them instead of wilcards.
I just was a bit puzzled about the unorthodox filter layout

I didn't get the filter triggered yet but will have an eye on unusual akamai connections,
especially from links embedded in tags other than <img>.

regards, sidki