wpif and imgsizer

[lucy24]

Twin headscratchers, found while investigating some apparent humans from a generally robotic range. The UAs are identical except for one word.

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.21 (KHTML, like Gecko) imgsizer Safari/537.21
Seen from July-September of last year, always from 195.154 (Iliad Entreprises)

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.21 (KHTML, like Gecko) wpif Safari/537.21
Active since last month, primarily from 195.154 but some 62.210 (also Iliad)

To date I haven't seen any from the two smaller Iliad ranges, 212.83.160.0/19 and 212.129.0.0/18

Is this purely a proxy, or is something else going on? There's no X-Forwarded-For. Requests are fully humanoid except for a specific header that I associate with robots and mobiles, and no favicon (it isn't explicitly named in html). There's never a referer for the initial page requests; supporting files have the expected referer. Always the noscript version of analytics, as you'd expect from a human who was concerned with privacy. But the exact page selection suggests they're following a particular RSS feed; they're not random humans.

[keyplyr]

I block imgsizer. My desktop presentation is dynamic using respective image size for available real estate. My responsive mobile pages work basically the same way. Moral of the story... don't resize my stuff! I see this attribute in various UAs, from different IP ranges.

wpif = women paying it forward?

[keyplyr]

Allowable time to edit post has past

No one has fixed this yet?

Regarding the hits themselves... since the UAs look to be cookie-cutter except for that one attribute & the hosting company is the same (cloud computing would explain the different ranges) & the same requested page & method is the same, my assumption would be robot. That and the fact that I do not have either of those Iliad ranges marked as VPNs or Proxies and I have never noted they leased out to any ISP. I do have a couple notes these Iliad ranges have spoof attempts at being mobile (iPhone, iPad & Android) and I have seen lots of human posers.

However, with cloud computing comes the evident short-term customer. Small startups (mobile connectivity, social media, apps, etc) seem to use cloud services first, then after gaining a larger customer base, move on to secure their own IP assignments so just because I have no prior history of humans there doesn't really mean a lot.

[iamlost]

I believe that both are artifacts from the scoopDOTit mobile app used to scoop interesting content found while browsing the web on your mobile. Typically then 'republished' as interesting on one's scoopDOTit account to be shared as 'one's own curated content' with all and sundry...

Note: identified the 'imgsizer' string as scoopDOTit back in 2011 and it's been blocked ever since.
Note: identified and associated 'wpif' string this past November and blocked.

[keyplyr]

Does the now published as "curated content" taken from someone's web page cite the author and/or retain a link-back to the source?

[iamlost]

Does the now published as "curated content" taken from someone's web page cite the author and/or retain a link-back to the source?

Yes to link back to original, but is rel=nofollow, anchortext is domain name.
Date is curation publish date not original.
No to original author name.
Note: the above is from cursory look only. Had to refresh my memory by looksee.

The idea appears to be one's own mini-Huffingtonpost-type curation-cum-bookmark site that can be socially shared.

[keyplyr]

Thanks iamlost

Great I kept seeing it in logs so I allowed it and found 4 link-backs there today as a result of other social media shares.

I don't care about rel=nofollow, I have enough link juice coming in... in fact I prefer these apps to disavow themselves (even if it isn't a full disavow.) Most of these types of pages don't do a full citation anyway.

[lucy24]

I kept seeing it in logs so I allowed it

I really, really hate locking out humans*, which these appear to be. The quasi-bookmarking aspect would explain why they're showing up in response to a specific RSS feed: "This is new, so let's see if it's worth checking out."

In any case it's all good, because it gets me going on what will probably be an ever-growing access-control method:

SetEnvIf {some specific factor, whether IP or UA or header or referer} dont_like_this
SetEnvIf {some entirely different factor} !dont_like_this

Deny from env=dont_like_this

... and repeat for assorted combinations of "If A and not B", each using its own environmental variable.


* Unless they happen to live in {country I don't like}, in which case tough.

[keyplyr]

For me it was easier; I basically just removed the two UA attribute blocks I had. The hits are coming from mobile ranges for the most part although I think I saw a few desktop hits.

As I've been saying lately, I've switched from a blocking motivic to trying to allow as much as I can and still maintain security. I've found that by allowing all those marketing companies I used to block with prejudice, my Adsense bids are now higher. By allowing all those in-development apps at Google-app-engine I once scorned, human mobile traffic has increased.

And the above category (social news apps/sites) was the very last I changed my mind about. I now allow a dozen or so of these to grab an image and about 200 characters of my content as long as a visible & relevant placed link-back is posted. This later category took a long time for me to give-in to.