Forum Moderators: open

Message Too Old, No Replies

Android, Frames and Google

Can android handle frames?

         

dstiles

9:16 pm on Jan 30, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



I have one site (UK) that has half a dozen ordinary pages (including home page) which, when presenting products for sale, splits into four frames plus the master page that holds the frames. It's been like this for about ten years and works well.

I have recently seen hits from (apparently) android that hammer each frame repeatedly, several times a second. I would normally put this down to robot activity but indications are it's really a human with a phone - although a probably really stupid human who can't tell when his phone is in overdrive.

The IPs are UK dynamic, from different ISPs, so probably really human, although today I had one that began with a single IP and seemed to split into two, from different ISPs (may have been two coincident visitors). The UA seems valid (although who knows with android's forever-incrementing version number!) and the headers are reasonable.

One of the oddities is: for many of the hits, especially on one of the seldom-used frames, the referer is http[://]www[.]google[.]co[.]uk[/] (my brackets).

I still allow that non-SSL, non-querystring referer because I see a fair number of hits from it - I think (still checking on that)!

It seems it's either a dumb frames-stupid device or a bot. If it's a scraper I need to find some very clever way of taking it out. If it's not a scraper, I need to discover why it's behaving like one.

Has anyone seen android activity like this? Is it even possible to store hundreds of pages on an android? Or could it be sending it direct to cloud?

trintragula

1:09 am on Jan 31, 2015 (gmt 0)

10+ Year Member Top Contributors Of The Month



The referer you mention has showed up on several android visitors I've seen today, including 2 logged-in members, so I'm guessing that's benign. Perhaps an oddity of G's mobile support?
I've not seen any fast footwork from androids today, but if you post up a UA, I can check my speed trap history.

Mobiles sometimes use both 3G/4G and wifi simultaneously. Some even ask for images via a different IP - I'm presuming some image resizing proxy is sending a smaller image to the phone, but that's just my inference.

keyplyr

2:20 am on Jan 31, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



IMO that's not mobile phone behavior, Android or any other mobile OS. Phones are considerably slower than larger RAM machines capable of fast processing and probably not capable of "hammering" your server at that rate, although what trintragula said may also apply. Mobile phone processors are still evolving, even though mobile network speeds are getting as fast as broadband.

My guess, either a bot or a human using a spoofed UA for whatever purpose.

As for frames... I see Adsense iFramed ads on my Android phone, always have.

dstiles

7:33 pm on Jan 31, 2015 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



trintragula - This is a bare URL with no search querystring, which I think is unusual for a non-SSL google but I THINK they are possible. The oddity is that EVERY hit bears the google URL, even though many of them should be from within the site itself.

I'm inclined to think the dual IP may be a red-ish herring and that there may instead be two similar accesses. The IP under examination belongs to Orange 3G so it's likely the device was at least a portable one.

A sample UA:
Mozilla/5.0 (Linux; Android 4.3; C5303 Build/12.1.A.1.205) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.93 Mobile Safari/537.36


keyplyr - thanks for the input.

I agree it's not expected mobile behaviour. It occurs to me the device may have been compromised and the sweep a result of some scanning virus. There have been at least two or three IPs but I would not rule out the possibility given androids security record.

I was concerned that some androids may have loaded and displayed frames separately - I saw that with early mobile devices.Of the menu and data frames, many return a 302 so the data has been accessed before.

The frames are, specifically: category menu 1, product-within-category menu 2, data display (for items chosen from menu 2), cart to display shopping cart (which has been discontinued to always shows a simple message). A typical sequence from early in the scan was:

menu2
menu1
data
menu2
menu1
menu2
cart
data
cart
cart
cart
cart
cart
cart
menu2
menu1
data
cart
menu2
menu1
menu2
products
cart
cart
cart
cart
cart

At worst, with the products (master frame controller) page being loaded every time, the sequence should have been:

products
menu2
menu1
data
cart

probably followed by more data frames as the punter looked at products, perhaps selected a new secondary menu from within the first and hit more products. Since the cart has not been linked to anywhere for some time it should not be reloaded unless the products page was. I would then expect it to be 302 not 200. This contra to the number of cart accesses, which is very high.

The specific spate of activity which triggered this posting began 12:39:31 and ended 12:47:53, around 8.5 minutes, resulting in 1354 log lines - around half the log for that day (30th). Within the last 30 seconds the server twice returned "permission denied" so obviously was getting fed up. It began by calling the products page with a request for a specific item, NOT the home page, so either foreknowledge or a google access.

The whole episode downloaded 4 CSS files - there should have been 7 but a previous day's access could have cached those (but why not the other 4 as well?). Also a single access of the JS file. A single GIF was called (site logo) but there should have been at least two. And there should have been one JPG per data frame access; a previous day's access could have cached those but a long shot unless only a handful of products was being targetted.