We're looking to develop a mobile website. On this mobile website, we'd like to automatically populate a user's location (with proper fallback) based on their IP address. I'm aware of geocoding a location based on IP address (mapping to latitude, longitude and then getting the location with that information).
However, I'm curious how accurate this information is? Are mobile devices assigned IPs when they utilize 3G, EDGE, and GPRS connections? I think so. If that is so, does it map to a relatively accurate location? It doesn't have to be spot on, but relatively accurate would be nice.
Short answer: No.
The network assigns an IP address to the phone when the PDP context is activated (activation of PDP context is telecomms-speak for 'asking for packet data services'). It can be changed under network control, but this usually only happens when the connection has been dormant for some time.
You need to bear in mind that a typical mobile network may have several million users, and since signaling (i.e. address reconfiguration and the like) doesn't generate revenue, but costs the network scarce radio resources, it gets avoided as far as possible.
There is a further issue. Due to the architecture of mobile networks, if you have a visitor to a country who is operating using the roaming service with their home operator, they will in fact 'appear' to be in their home country. This is because the mobile device always connects to the internet through a node called the GGSN in their home network.
This is a major issue for websites which must deal with rightsholders. As an example, the BBC iPlayer service allows people located in the UK to 'catch up' on any BBC TV or radio content free of charge. In many cases, TV rights are geographically licensed, so the BBC is required to make every effort to ensure that the service is only available to users located in the UK.
This is, as I have explained above, impossible for mobile users. If I am using the SIM card of a UK network, I will 'appear' by geolocation to be in the UK regardless of where I actually am in the world.
This is not so much of a problem as yet: streaming a TV program over a 3G connection when roaming in a foreign network is prohibitively expensive (could easily be $100 or upwards for a single program), so this theoretical problem doesn't arise very often as yet. However, as roaming data costs fall (and everyone knows they will), it will become a real issue.
New smart phones (like Apple's iPhone) generally have web browsers that support HTML5 and/or some other form of client-side geolocation.
HTML5, for example, has the ability to geolocate the computer or mobile device based on a) position of the device's GPS, b) Wifi Triangulation and then c) IP address.
This is a client-side approach, and the browser will ask the user if they wish to share their location with you (which may or may not be a deal-breaker for you), but it is capable of providing < 20m accuracy.
See: About Geolocation in HTML 5
Related
Is W3C Geolocation API more accurate the IP geolocation for non-mobile devices? I am using https://ipstack.com/ and I am seeing big discrepancies between actual location and location identified by the service for desktop users, but after reading
https://en.wikipedia.org/wiki/W3C_Geolocation_API
GPS (Global Positioning System) This happens for any device which has GPS capabilities. A smartphone with GPS capabilities and set
to high accuracy mode will be likely to obtain the location data from
this. GPS calculate location information from the satellite signal. It
has the highest accuracy; in most Android smartphones, the accuracy
can be up to 10 metres.
Mobile Network Location Mobile phone tracking is used if a cellphone or wireless modem is used without a GPS chip built in.
Wi-Fi Positioning System If Wi-Fi is used indoors, a Wi-Fi positioning system is the likeliest source. Some Wi-Fi spots have
location services capabilities.
IP Address Location Location is detected based on nearest Public IP Address on a device (which can be a computer, the router it is
connected to, or the ISP the router uses). The location depends on the
IP information available, but in many cases where the IP is hidden
behind Internet Service Provider NAT, the accuracy is only to the
level of a city, region or even country.
It doesn't seem the W3C Geolocation API is any better for desktop users. It seems to be more precise for mobile users, but not desktop users. Is this correct?
It doesn't seem the W3C Geolocation API is any better for desktop users. It seems to be more precise for mobile users, but not desktop users. Is this correct?
This is correct, the W3C geolocation API is a good bet when
The user is using a browser (the UX for informed consent is well thought through by the browser maker, e.g Apple's Safari or the Firefox teams)
The user is on mobile (GPS hardware, WiFi triangulation, Google or Apple's-proprietary services such as Google Play Location Services being available) with the underlying OS
Fine location matters for your application (e.g ride-hailing or food delivery to your current location)
If the above criteria are generally not applicable most of the time to your application, then IP geolocation API services such as Fastah are a good choice for the country, approximate city, and geo-coordinates information.
In general, W3C Geolocation API is more accurate than IP geolocation such as IP2Location because it uses multiple parameters to determine location.
If GPS is not available in non-mobile device, they can use the WIFI MAC address or cell tower ID to determine location.
We are developing a mobile application that tracks users while they are picking up and delivering commodities. We have overcome many issues, including poor connectivity in rural areas, the app going into the background, and so on.
One issue continues to befuddle us. When receiving calls some drivers lose connectivity, other drivers will gain connectivity, and others (most) have no change in connectivity.
I remember earlier that Verizon iPhone users couldn't access data while on a call. Naively I thought that this issue was completely overcome, but perhaps it is not.
My understanding is that a) there are still some cellular protocols that cannot handle voice and data and b) there are (or were) some settings in mobile phones that give the user a choice.
I have searched for some list of cellular protocols and iOS and Android settings but so far come up empty.
Any guidance would be greatly appreciated.
Hopefully this will provide some more clarity; it all depends on the Radio Access Network (RAN) technology they're using (2G/3G/4G) and the terminal itself's capabilities.
There's 3 umbrella terms of technologies, each with their own revisions and variants, but this should cover it:
LTE (4G) only supports voice calls via VoLTE (Voice over LTE). Calls made over VoLTE will allow the user to continue accessing data at the same time. Many devices & some networks don't yet have VoLTE capability, so they use Circuit Switched Fall Back (CSFB) to drop to a 2G/3G Radio Access Network for making voice calls. (If your terminal does this you then have that RAN's ability to allow simultaneous voice/data.)
3G - There's a few flavors of "3G", depending on the terminal and the RAN variant (UMTS / EDGE / CDMA / HSDPA / HSDPA+) you may be able to access data and be on a call at the same time.
GSM (2G) does not have this functionality, the handset is either in Circuit Switched (Voice) or Packet Switched (Data) mode but not both.
The decision of which RAN to use is based off the priorities stored in the SIM/USIM, the received signal strength of the available networks and the capabilities of the terminal.
This means for example your users who may gain connectivity may find themselves using a 3G access technology on a 4G enabled terminal, with VoLTE support, jumping up to VoLTE to make the call. (Some operators resell to MVNOs but default to slower / older RAN technology like the 3G family)
Others may loose connectivity as you've seen, if they're happily using LTE on a device with no VoLTE support and need to drop to 2G/3G for a call (CSFB) they may loose data services as they're back to the limitations of these older RAN technologies.
I'm doing some network research, I want to find all the IoT devices (or at least devices that could be IoT) from .pcap files. Do IoT devices have some unique traffic characteristics, traffic pattern or identification (eg. protocols, ports, etc)? I can't find the answer. IoT devices are relatively new so there is not that much documentation about it.
Thanks!
This is an active area of research and may require some sort of ML algorithm. We (3 students at UC Berkeley) are also looking into it. Do you have any pcaps you can share?
There are many characteristics, but because this is a new field with insufficient standardization - there is no solution to find all devices, and you will have to use several different methods.
Watch the protocol - some devices use niche protocols that single them out (like SIP for VOIP devices)
Watch the urls devices are looking for via DNS - since most iot devices are not directly human controlled like normal computers, their communication is rather unique per device. They will contact the site of their vendors for updates, send and receive data that directly relates to their function and won't have much variance in their behavior.
Watch for service discovery protocols. Many protocols include the service that the device gives as field. Read about ssdp and mdns.
There are many more complex ways of using the fact that most of the communication is pre-defined. Devices have unique patterns of communication - like specific times between requests for example.
There really isn't. It's an internet device after all, and the manufacturer and the user through configuration will define its traffic pattern.
That said, there will be a traffic pattern for a particular type of IoT devices. Sine IoT devices always phones home for legit reasons, you can probably find your device types by the servers they connect to, and use that to refine your statistics/ML algorithm.
Now on a tangent, a lot of IoT devices (medical devices, OnStar, Tesla and etc) use cellular networks, both for mobility and for reliability. There are a set of protocols that show a lot more information.
The Geolocation API with its getCurrentPosition method works only using WIFI router information and IP addresses. In India where I am, there seems be NO correspondence between IP address and location.
Sometimes it shows I am in Pune - sometimes in Hyderabad - but I am in Mumbai. But When I use the same gMaps application with my mobile devices, it manages to accurately triangulate my position, which is fantastic.
But with the car pooling application I am building I need users to register and inputs their current location automatically using their laptops and desktop computers. How do I do this?
FYI: I am using chrome on Mac OSx
There are essentially four levels of accuracy for geolocation:
GPS, for devices with a GPS receiver
GSM, for mobile devices connected to the mobile phone network
WiFi, for devices within hearing distance of WiFi networks - NB the accuracy is only good if the area has been surveyed, either by the Google streetview vehicles, or by consumers crowdsourcing the information from devices with a real GPS receiver.
IP address - ISPs get allocated a number of blocks, and typically they assign these regionally. In parts of the world where IP ranges are scarce (i.e. not in North America), you can see where the telephone network will connect to different local hubs.
It sounds like it is the last case that you're seeing on your desktop only, which implies the WiFi networks near you haven't been surveyed with enough confidence for the geolocation to work.
Is it possible to make sure that GPS positions an iOS app is getting are real, and they are not fake locations illegitimately provided somehow, for example, by means of another app such as LocationHolic?
Thanks!
You could theoretically do some ip number geo lookup (e.g. How does geographic lookup by IP work?), but that's not entirely reliable (e.g. VPNs), so I'd be hesitant to dispute someone's location on the basis of that. Given that locationholic is for jailbroken devices, perhaps validate location information against ip-derived location info if, and only if, the app is running on jailbroken device. For info re ip number based geo lookup or identifying if a device is jailbroken, I'm expert in neither, but both topics are covered well elsewhere on StackOverflow or can be answered with a google search.
In short, I suspect that locations are reliable on non-jail-broken phones. Regarding "Find My iPad/iPhone" on jail-broken phones, I can't speak to that, but all rules of reliability and security are thrown out of the window on jail-broken devices, so you can't rely on it.