I believe some users on my site are using IP masks to create more than one account. Due to the nature of my site/game it's against the rules and I need to remove players like this.
I currently track their IP, host, browser type and such with PHP, I also use javascript/jquery to get their screen size. I also have a little script set up that tells me if their coming through a forwarding service. It says this certain player is although his IP doesn't match any proxy lists I've come across.
Basically I'm looking for any other info I can collect that I can compare and determine if a suspect player is actually another players second account. Any suggestions?
The only thing i can think of is using telephone number as part of subscription process. And sending some sort of verification code via SMS.
Also you can start setting cookies.
And is it possible to imagine some sort of detection as part of your game/application. Like you add some game elements that would expose suspects to some secret knowledge. Setup honeypots. Like you show some secret 'cheat' codes or specific link/location to one suspected double and not to the other. Then if the other tries to use that info - you got him... Basically build some sneaky intelligence into your app
Combining these with all the other detection techniques, could make it very close to 100% bulletproof and can be a lot of fun.
Related
I've been building a web app which will be served to users via a native webview. I have been using This monitoring Tool to monitor visits and page views but it really does not provide the stats that I need, which is the real number of people actually using my app.
I think, If I could create a js code and serve it withing the index page of the app, so this js code can collect some unique device "something" and create a database with that info, so, everytime a user uses the app this same js code, or something else, could recieve that unique device "somethig" and compare it to the database, if it already exists is not counted as a new user as it has been counted before. But if it does not exist then it would be a new user.
I must state that the app would be hosted on a shared hosting and the webiew app will not be at Google Play but delivered to users in different ways. So, what I really need to know is:
1- Is it the logic I am using correct? Can it be done?
2- Which could be that unique device "something" other than IMEI, phone number or unique device ID?
I know it's not the usually accepted kind of question used to post here but I do not want to dive into some coding without beeing sure it will be usefull. So, depending on the answers I would try it out in practice and reshape this question to fit the Site's guidelines.
Thank you all in advance.
Most analytics libraries like Google analytics usually generate a specific ID for each user.
You're right though that it is possible. Usually you'll simply generate the ID the first time and then just store it locally, checking on every subsequent visit if it's still there, though it can dissapear if a user clears their cookies
I need to develop an application that registers the device/browser that the user is using. Such as banks or better yet FB does. So for example when a person logs in the application checks to see if they have logged in using that device/browser before. If not then have them go through a verification process.
The application will be built in .Net 4, Asp.Net MVC, js, jQuery, etc..
I hoping to get some advice on what others have used to accomplish this task.
EDIT
Thanks for the comments.
Ok, so basically, if am understanding correctly, both suggestions would mean storing a uniqueid in a cookie/localStorage on a Laptop/Device and also in my DB so i can recognize it in the future.
I was hoping, to be able to get a unique ID from the machine/device that is static and specific to machine/device so that I can use to track it. My concept would mean that a user would have several devices/machines that i have logged in from.
I will also be capturing the IP but i don't want to use that Key to identifying a user.
The chances of getting a precisely unique identifier from a browser is slim to none. There are many privacy risks associated with browsers providing a unique identifier string. However, you can always generate a random GUID for a session a user establishes, and store it either as localStorage or as a cookie.
How can i generate unique fingerprint of each client?
I know must use navigator object but some properties like navigator.battery cannot use in this method.
// battery included and unique may change.
var uniqueHash = exampleHash(JSON.stringify(navigator));
How can i generate correct unique fingerprint for each user just using JavaScript and without cookie.
Cross platform and older browser also must be included.
I need list of cross browser supported by navigator.X
Note:
I don't want to generate random hash. i want to generate system base hash for each user and i dont wanna save on Cookie or Storage.
How can i generate unique fingerprint of each client?
Short answer is that you can't. It's impossible to do this for every client. You can get close using invasive profiling of the client, but you'll probably only get a unique identifier in around 90-95% of cases.
and i dont wanna save on Cookie or Storage.
Is there a reason you don't want to store data client side? If you told us what you were trying to achieve then maybe we could suggest a better way to solve the problem.
One route that may be worth looking into is using the Mozilla Persona API. It exposes a navigator.id property for consumption. Getting a unique id from a user is as simple as...
navigator.id.get(function(unique_id) {
alert("this is your unique id: " + unique_id);
})
This has the downside of requiring user authorization
Example: http://jsfiddle.net/aJsL9/1/
Simplest way to keep a session without using cookies is appending a unique hash (maybe a UUID or something similar) to the urls in the page as a get parameter:
/my/fancy/url
becomes
/my/fancy/url?HASHCODE
whenever the server receives a request, it capture the HASHCODE if present, otherwise it generates one, and then append it to all links on the served page.
Please bear in mind that the user can manipulate the HASHCODE and you should take that into account when engineering your application.
Anyway, notice that it's quite ugly in the fancy-url era. Also notice that user tracking is a delicate subject and you might incur into legal problems if you do not properly declare it in the TOS.
EDIT: you cannot track a person across multiple web sites without using cookies in any of their variants (flash, session storage, etc.) and a domain shared between sites. No way, you cannot set a variable or cookie from one domain and access it from another one in any decent browser, otherwise it would be a big security hole.
EDIT: Panopticlick cannot be used as a tracking method as you suggested, because it is based on statistical matching and it is also pretty bad at that (try browsing https://panopticlick.eff.org/ from outside the USA or with the just-released Chrome/Firefox update). It's a good proof concept, but nothing that you can use for this purpose. Also, you would need a whole lot of samples to get statistically relevant results.
EDIT: Browser fingerprint identifying power is weak: many browsers are autoupdating (like Chrome or Firefox) and official builts are very few (20? 40? Maybe a bit more if you count Linux distribution-compiled ones), so you will find a consistent portion of users with the same user agent. Add that there is a pletora of consumer PCs with similar configurations.
Since most visitor count services are based on measuring public sites I am not able to use such services.
My goal is to measure how many unique visitors are surfing on a specific Intranet site per day. The problem is that I have very litte technical possibilities since I was provided with a simple IIS web space. This means that I can only use HTML5 and JS (This site will only be accessed by iPads). Maybe there is a new HTML5 feature I am missing?
Thanks for any tips and hints.
Unique visits have to be tracked on the back end. You'll need to be able to use some server side code to track people, html and JS have no idea of unique visitors they run on the client side, so its basically static in that sense, a users computer has no idea of who else is using the site.
You'll have to use some type of backend language. (c#, PHP, VB, ...etc whole bunch of them)
You will also have to know what makes each user unique, maybe IP, but your on the intranet, that maybe the same for everyone.
You could simply have code that gets the unique id(maybe the IP), checks a text file, if its not in the text file add it to a new line, then just count the lines.
We send follow up emails for inquiries on our products and I wanted to track how effective they are.
This is my plan:
Update the url in the hyperlink of the email to include a query string like:
href=http://www.somepage.htm?source=fromEmail
And then track how many visits I get with the query string = fromEmail
My problem is that the page is a .htm and I didn't really want to rewrite it so I'm looking for a javascript counter that can accomodate the query string. Ideally I would like to be able to track the total page hits, as well as the hits that come specifically from these emails. Even more ideally I would like be able to track various information in SQL Server so that the person that requested this could do some reporting on it.
Am I going about this the right way or should I just rewrite it in .net (as we are a .net shop)?
While it is definitely possible to put some javascript on your .htm page that fires an AJAX request that increments a SQL counter table if the source=fromEmail, I would say that it is more reliable to have the server increment this counter when serving up the page.
Having the server do the work when the hit originally comes in will also allow you to track more specific information about the request for the report.
Javascript on emails is a no-no. Outlook by default blocks Javascript, so there goes 50% of your users. Other email systems are not keen on running javascript either. Remember, when you're doing HTML emails, you need to think 1995-vintage HTML. Thanks, Microsoft.
You've got a few (ok, but not great) options:
Include an image file on it. When it gets loaded, count it as a hit. This is how all the major services handle email tracking, with a 1px X 1px white image file that they most often place at the bottom of the page. The obvious problem with doing this is that if they use Outlook's preview pane with images enabled, it counts as a hit that they may not have read. If they read it on Gmail while not unblocking images (set to hidden by default) you've got a real hit that doesn't get recorded. So, either way, your numbers are wrong.
Track link clicks by routing links through your server. You use your server to then re-write urls for the browser to follow. Again, it works well enough, but won't capture the real numbers because only a small percentage of people who get an email actually click a link on them. Here's an example using link tagging with Google Analytics
A combination of the two above. It covers both cases, yes, but could result in double counting one user. You could also hybridize the two by setting a variable on each image that could track back to the source email, then store hits in a DB to eliminate dupes. That's a LOT of work, though.
My company sends (and tracks) thousands of emails daily as part of its core business, and we always encourage clients to do emails with "teasers" that draw them into other websites for the main content. Why? The closer we get a user to the main site, the closer we are to a sale--nobody has ever done an ecommerce transaction solely on email yet (that I know of) Also, it's one heck of a lot easier and offers far more options to do tracking via Google Analytics on a site than it is to track emails. Since you can't reliably embed Analytics in emails, your best bet is to get 'em to a website that can.