I realized that Android M requires at least one of ACCESS_COARSE_LOCATION and ACCESS_FINE_LOCATION permissions to scan Wifi.
I don't think it's a technical issue but that there is a sort of philosophical reason (e.g., privacy) for such a weird policy.
But I couldn't find the exact reason for that and I would appreciate if someone give the answer.
The list of available Wifi networks for a device can be indeed used to locate the device.
To locate the device on needs the list of of the wifi networks the device can see and a huge database with known wifi networks and the position of the access points. With this information one can triangulate the position of the phone.
Multiple of these huge databases exist. Apple, Google, etc. have each one and there are also public ones: http://www.openwlanmap.org/
Read more about it here: https://en.wikipedia.org/wiki/Wi-Fi_positioning_system
Related
I am facing an obscure behaviour of device naming when trying to use multiple USB midi devices of the same type of hardware. As this might be hardware/system/driver related, here is my general setup:
host: Windows 8.1 x64 (tested on multiple machines)
usb devices: 2x Livid Brain V2 (a general purpose usb-midi interface)
The two devices (same hardware, let's call them device X and Y) are flashed with two different firmware flavours so that they appear with different names in the midi enumeration. If I only connect device X it shows itself as "Brain2" / if I only connect device Y it's "Brain2B". Those are the names I get from the MIDIINCAPS / MIDIOUTCAPS (winmm.dll). So far so good.
The problem arises as soon I connect both devices at the same time, than both get the same name (of the latter connected) - so the enumeration changes:
first X, then Y => both get the name "Brain2B"
first Y, then X => both get the name "Brain2"
However, I can access and use the devices but I am not able to distinguish between them anymore (which is basically the same starting position as having the identical firmware on both devices).
I'd be happy if anyone could point me in the right direction. Has anyone encountered anything similiar? Could this be a system related issue? (Or is it a bad driver, maybe?) Thanks in advance!
EDIT:
I had a closer look at the usb properties with a tool callled USB Device Tree Viewer (similar to USBView) and it turned out the identifiers are correct there. So, how does winmm.dll get the midi enumeration - could it be a bug in there? (unlikely)
Moritz
(btw: here is the related topic/post in the manufacturer's forum: link)
I was just installing Ubuntu and noticed it was downloading updates from ca.archive.ubuntu.com. How did it know I was in Canada? As far as I'm aware an IP packet carries no information regarding physical (geographcial location) and there is no stipulation in the Ethernet standard saying anything about information regarding location.
So how do things such as geolocation work? For example this website tells you which country your IP address belongs to. Is it just a matter of looking up an IP address in a table? If so where does the data come from, it's not as if people actively signup to have their IP address associated with the building address?
how does IP address geolocation work, does it just lookup the IP from a table?
Yes, that's exactly how it works.
IP geolocation is nothing more complicated than a database lookup. IP addresses are assigned by IANA to regional governing entities who then assign (sell) them to ISPs, governments and corporations (IBM for example has a dedicated block of IP addresses for themselves because they got into the internet game very early on).
Based on this fact we can sort of figure out where an IP address is located. IANA themselves publish the block level allocations on their site: https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml which is rendered beautifully in this XKCD comic: http://xkcd.com/195/.
As for the more detailed info like which city that IP address comes from, to get that information requires more data gathering. Some ISPs may tell you their assignment schemes, most dont. So most databases like whatismyipaddress.com painfully build theirs up by surveys (simply asking people where they are or via smartphone apps tapping into GPS), looking up whois databases (which may or may not lie) and careful guessing.
Yes, your IP carries a geolocation as well. I'm not sure that's the best way to describe it, as it doesn't really carry the information (I don't think?). This link gives a pretty good idea of the kind of details they can get from your ISP though:
http://whatismyipaddress.com/geolocation-accuracy
Of course all of that revealing information can be partially negated by using a proxy.
Why does HTML5 geolocation let you share your location? What is main purpose of using geolocation, as you can get the location with IP address as well. Is there any difference between these two methods?
I'm asking because geolocation requires the user's permission and also doesn't work on all browsers.
HTML5 GeoLocation tends to be much more accurate than IP-based GeoLocation.
IP-based GeoLocation depends on databases associated with ISPs to figure out where you are. This doesn't work well when your ISP services a very large area and gives out dynamic IP addresses. The address in one town today might be 100 miles away tomorrow. Furthermore, those databases are usually not updated frequently. If your ISP sells off blocks of IPs or moves them to a new town, the database may still incorrectly think you're somewhere else.
HTML5 location uses services provided by your browser to figure out where you are. If your computer has GPS built-in (such as on many mobile devices and some laptops), it will know exactly where you are. This makes it much more useful for webapps that have a navigation or location component. For devices without GPS, it can often provide a very good approximation based on nearby known wireless signals and other factors, such as tracing what routers your computer goes through when connecting to the internet. The exact implementation depends on the computer, what hardware it has available, and how the browser chooses to do things.
For example, when I check an IP-based location service, it says that I'm in a particular large city in the same general area that I live in, but it's actually about 50 miles away.
When I use an HTML5 location based service to figure out where I am, it's only off by about 20 blocks.
If you're developing a webapp which needs location data, try using HTML5 GeoLocation if at all possible. Set up a fallback, so that if HTML5 location fails, you can use an GeoIP solution instead. This way, you will get optimal accuracy on supported browsers and devices, but will still have a solution in place when the HTML5 data are not available.
If you used the geolocation-javascript project from Google Code, you could use the following code:
//determine if device has geo location capabilities
if(geo_position_js.init()){
geo_position_js.getCurrentPosition(success_callback,error_callback);
}
else{
// use an AJAX request to look up the location based on IP address
}
Geolocation is a lot more precise than IP address, though both can be faked.
IP address just gives you country and general region.
Geolocation gives you:
Geographic coordinates (latitude and longitude)
Speed (assuming you're on a device that can measure this; most tablets and smartphones can)
Altitude (this is also dependent on the device)
Degrees clockwise from north (again, assuming the device supports this)
http://diveintohtml5.ep.io/geolocation.html has some good info on geolocation and the HTML5 geolocation API. Here's the W3C Candidate Recommendation.
Obtaining a user's location through the IP-address is by far not as accurate. The IP-address' location is mostly based on the location of the actual server, which can be requested. Often this is far away from the actual user's location, so it only provides the basic region.
HTML5 geolocation on the other hand is more precise, but the user's information is used to determine the location and often also speed along with some other things. This is based on the device's GPS if available, and otherwise on information entered by the user. Clearly this is way more accurate. Both methods can be faked though.
Getting location by IP address only gives a vague location (it is rarely any more accurate than to town, and often much less accurate than that, depending on your location and ISP).
It is also sometimes completely inaccurate: if I use a VPN to connect to my company network, I will show up as being at their office because I will have an IP address from the office, but I could actually be connecting from anywhere in the world.
HTML5 geolocation can be much more accurate -- if you have a GPS receiver in your device, then it is completely accurate, but even without that, in heavily populated areas it can get your position with an accuracy of 20 meters or less by mapping the local wireless network signals. And it doesn't matter how you've connected, it will always be accurate.
Because HTML5 geolocation is so accurate, it is considered a privacy risk, so the spec states that you must give permission before a site can use your gelocation data. Also, not all browsers or machines may be capable of providing the gelocation data. The website therefore must be able to cope with users who do not provide it, and cannot rely on it being provided.
IP address location doesn't have this kind of restriction because the location mapping is done by the server using publically available IP location mapping data. The end user cannot avoid giving out their IP address, so they cannot prevent the website mapping them using it.
So the two are completely different.
The major difference that you will see is the accuracy. IP addresses only give you a very general idea of where someone might be... Geolocation will tell you exactly where they are. To read more on geolocation go here, and a demo of how accurate it can be can be is found here
HTML5 geolocation gives the client (browser) the possibility to provide the location information of the machine. This is potentially orders of magnitude more accurate than IP location. For example, the client could have actual GPS hardware installed, or be able to triangulate the location by GSM or WiFi spots. Location by IP on the other hand is very rough and somewhere between not always accurate and misleading.
When I use http://html5demos.com/geo to locate myself, it shows wrong location(wrong city) in FF and chrome. Any reason why this is happening
I had the same problem using Chrome on Windows, but I got it to work, at least some of the time.
I was also using the example http://html5demos.com/geo
The location was not just inaccurate, it was also in the wrong city.
I tried the same example on my iPad (Safari) and there the location was correct. My iPad is using the same WiFi network as my PC, so I then knew it was not a problem with my ISP returning the wrong location, it was to do with the browser on my PC.
I got it to show the correct location in Chrome by going into the Chrome settings and clearing the cache and cookies.
It wasn't sufficient to just select in Chrome "Tools/Clear Browsing Data/Cookies & Cache",
it was only after in Chrome I selected "Settings/Privacy/Content Settings/All Cookies and Site Data" and deleting all cookies, did the example show the correct location.
Update 1: I tried the same geolocation example the next day, and to my annoyance it was again showing the wrong city. I tried to get it to work by clearing the Chrome settings as described above and this time this solution didn't work. However, when I used the application CCleaner and selected Cleaner/Applications and cleared all of the Chrome data (internet cache, internet history, cookies and session) the geo example showed the correct location. I'm using the latest version of Chrome. Hopefully in future versions it will work more consistently.
Update 2: I tried the procedure above at a later date and couldn't get it to produce the correct location at all. It could be that the geolocation is now returning the location of my internet service provider, rather than my location, using my IP and Google Location Services. Of course this location is fairly useless. The reason why my iPad is returning the correct location is probably because it contains an inbuilt GPS. The iPad 3G / 4G have a GPS chip built in to the GSM receiver chip, whereas WiFi only models have no GPS. When 'location services' are switched off in the iPad settings, location via both GPS and IP are switched off. It would be useful just to be able to switch off the GPS on my iPad and just use IP location, but I'm not sure if that is possible.
Update 3. As I mentioned, I'm using a WiFi stick in my PC. I have noticed that when I look at the available WiFi networks (with View Available Wireless Networks) and mine is the only network, the geolocation example returns a location in a different city, but if any of my neighbours have a WiFi network in range of my PC, the geolocation example returns my exact location, to within a few metres. i.e. the geolocation in the browser is clever enough to use this extra information to locate me.
(I think the other answers to this question completely on the wrong track. The questioner states that the location was being shown in the wrong city, so the question is not to do with the location accuracy)
Different devices have different degrees of accuracy and it is important that your application be aware of the difference. A cell phone that has a GPS unit inside of it that is switched on is usually accurate within three meters. A cell phone without a GPS unit, with the GPS unit switched off to maximize battery, or at a location where the GPS can’t contact the GPS satellites will have to use cell tower triangulation to estimate the users location and is typically accurate within 3000 meters which is accurate enough to know what neighborhood the user is in but completely useless to tell them what building they are looking at.
If the user is accessing your site from a computer connected to a land-based broadband connection it can usually pinpoint the precise address by consulting a provider database and pinpointing the exact address from the DSL or cable provider.
To get the accuracy of the location information, you can query the accuracy property on the coords object. The accuracy property isn’t exact by any means but it will give your application a good sense as to whether or not you have a nearly precise position or a neighborhood.
According to the Firefox geolocation FAQ, Firefox uses Google for location services. It sends Google the following information:
Your IP address
Information about nearby Wi-Fi access points
A random Google-assigned identifier (changed weekly)
I assume it will also use GPS data if your computer has a receiver installed, but the FAQ doesn't mention that. Maybe because there's no need to use Google's sever if you have GPS data available.
I assume that Chrome, as a Google product, is using the same geolocation database.
As for why you're getting incorrect answers, that would reside in Google's database. There are most definitely errors in there. For instance, my office computer shows up in Mexico city even though my IP address and the IP address of my employer's proxy server are both in Plano, Texas, and all other IP-to-location databases have this correct (taken from the registered whois data for the address.)
Here are two Google pages that they claim will help, although they haven't done a thing for me yet:
https://support.google.com/websearch/answer/873
https://support.google.com/websearch/contact/ip
The latter (contact/ip) is a form for reporting Google location problems that manifest as Google redirecting you to the wrong country's home page. They say it may take over a month to correct the database. I've been waiting nearly two months with no luck.
There are Firefox add-ons that can be used to force your browser to report a specific location. They're meant for debugging location-aware web services, but they could also be used in a case like this, where the normal method isn't working.
I think if you could user the the method watchPosition() instead of getCurrentPosition() the coordinates will be updated too much which will produce a better result
note : it's better to use another browser other than chrome it doesn't support the watchPosition() method good enough
I figured it out. Every mobile phone has its location mode default to High Accuracy. High Accuracy uses GPS, Wi-Fi, Bluetooth, or mobile Networks to determine location.
This might be a challenge as there are many variables to getting a device's location.
The solution will be to change the location mode from High Accuracy, to Device only or GPS only.
Device only or GPS only is supposed to use just GPS and device sensors to determine location. I have tried it, it works like a charm.
Use link below to change Location mode
https://www.verizon.com/support/knowledge-base-106080/
I depends on which method is used to get your location. If it uses IP then you could show up pretty much anywhere. If it uses Wifi then it might be just be biased data.
My bank website has a security feature that let me register the machines that are allowed to make banking transactions. If someone steals my password, he won't be able to transfer my money from his computer. Only my personal computers are allowed to make transcations from my account. So...
What are the approaches to restrict the access to a group of machines in a web system?
In other words, how to identify the computer who made the http request in the web server?
Why not using a clients certificate inside the certificate store of an authorized host or inside a cryptographic token such as smartcard that can be plugged into any desired computer?
Update: You should take into account that uniquely identifying a computer means obtaining something that is at a relative low level, unaccessable to code embeded in an html page (Javascript, not signed applet or activeX), unless you install something in the desired computer (or executing something signed such as an applet or activeX).
One thing that is unique per computer is the MAC address of the Ethernet card, that is almost ubiquitous on every rather modern (and not so modern) computer. However that couldn't be secure enough since many cards allow changing its MAC address.
Pentium III used to have an unique serial number inside CPU, that could fit perfect for your use. The downside is that no newer CPUs come with such a thing due to privacy concerns from most users.
You could also combine many elements of the computer such as CPU id (model, speed, etc.), motherboard model, hard disk space, memory installed and so on. I think Windows XP used to gather such type of information to feed a hash to uniquely identify a computer for activation purposes.
Update 2: Hard disks also come with serial numbers that can be retrieved by software. Here is an example of how to get it for activation purposes (your case). However it will work if sb takes the HD to another computer. Nonetheless you can still combine it with more unique data from computer (such as MAC address as I said before). I would also add a unique key generated for a user and kept in a database of your own would (that could be retrieved online from a server) along with the rest to feed a hash function that identifies the system.
Did you actually install something?
Over and above what Mark Brittingham mentions about IP addresses, I suppose some kind of hash code that is known only to your bank's computer and your computer(s) would work, provided you installed something. However, if you don't have a very strong password to begin with, what would stop someone from "registering" their computer to steal money from you?
I would guess your bank was doing it by using a trusted applet - my bank used to have a similar approach (honestly I thought it was a bit of a hassle - now they're using a calculator-like code generator instead). The trusted applet has access to your file system, so it can write some sort of identifier to a file on your system and retrieve this later.
A tutorial on using trusted applets.
I'm thinking about using Gears to store locally a hash-something to flag that the computer is registered.
If you are looking for the IP address of the computer that makes an account-creation request, you can easily pull that from the Request. In ASP.NET, you'd use:
string IPAddress = Request.UserHostAddress;
You could then store that with the account record and only accept logins for that account from that IP address. The problem, of course, is that this will not work for a public site at all. Most people come through an ISP that assigns IP addresses dynamically. Even with an always-on internet connection, the ISP will occasionally drop and re-open the connection, resulting in a change of IP address.
Anyway, is this what you are looking for?
Update: if you are looking to register a specific computer, have you considered using cookies? The drawback, of course, is that someone may clear their cookies and thus "unregister" their computer. The problem is, the web only has so much access to your computer (not much) so there is no fool-proof way to "register" a computer. Even if you install an ActiveX control, they could uninstall or delete it (although this is more persistent than a cookie). In the end, you'll always have to provide the end-user with some method for re-registering. And, if you do that, then you might as well have then log in anyway.