Can anybody explain exactly how a web beacon works? I know they're generally used by advertising platforms but i can't really find a good explanation on how they're working.
I know that cookies aren't accessible cross-domain. A web beacon is an image that sends a request to the server, and the server adds a cookie to the response, right? So how can it be accessed on different domains?
Thanks!
When an HTML page is downloaded the browser parses the page and looks for additional resources needed to display the page, such as images. For each image it finds the browser makes another request to a server in the background. When servers receive requests, they usually log the request to monitor load on the server, and record information about who sent the request and where it came from. A web beacon is a tiny invisible graphic that generates a request to the tracking firm's server. They record the request in their logs and then analyze their logs to see who went where and did what and when.
When returning the image from their servers to the browser, they can also send down information to be added to a cookie. There are third-party cookies that can be tracked across domains. If you come back to the site, and the beacon request is made again, that cookie will also be sent up in the request to the server and the tracking firm will have more information about you.
Think about this. Even though you are visiting myfavoritesite.com the web beacon image is being requested from trackers.com. The cookie they create is assigned/locked to their domain, trackers.com. But if you then surf over to myotherfavoritesite.com, and they too are sending web beacons to trackers.com, the cookie will essentially be shared between the two sites. There are more considerations here, but that is the basic premise.
Bug bug (also known as Web beacon) is very important tools commonly used by online advertiser as marketing or advertisement analysis tool for tracking and monitoring the activity of users on a website or marketing content i.e: blog or email. An expert advertiser inserts web bug in his content (usually on website and email) in order track how many people opened a particular content, on which application and country his content is being viewed. So, whenever advertisement display by third-party just know that you are being tracked for marketing analysis purpose.
Bug bug tools are provided freely or premium mostly by CRM service providers like Hubspot CRM, Freshsales CRM, Salesforce CRM, etc. However, a Web bug PHP code can also be used for this if tracking service by CRM provider is not available. Continue reading
And instead of going off and creating one using Php and Apache redirects, my vote is that you go to http://webbeak.com and create one, use it, and track it. No cost either.
Related
I'm developing a mobile application that presents users with information about nearby places (combining my own information with Google Places data), but Google Places seems to have blocked my application.
Is what I'm doing out of the TOS, and if not, is there a way to whitelist my server application?
The current flow is
User on mobile app requests nearby places on their device
GPS coordinates are sent to Server (Django backend)
Server builds the Google Places request with GPS Coordinates, makes the request and then combines the returned Google Places JSON with my own data
Server returns the combined data to the User
Everything worked perfectly until out of nowhere, it seems that Google Places has blocked my application. I'm well within the request limit and have properly attributed Google within my mobile app. Requests with my API Key work as long as they don't come from my server application.
I've read the Terms of Service and don't believe I've done anything out of scope. Is there a way to whitelist my server/IP? Or a better approach to this problem?
I'm currently building an oAuth2 server so that external clients/devices can access data from my service without having to send over user credentials with every request. I've finally grasped how oAuth works after spending an entire day reading numerous tutorials and online documentation, however, there's still one thing that I'm rather unsure of...
When sending a request for an authorization code to an oAuth server, how should I deal with a callback to mobile devices and devices that aren't a webserver?
E.g. this request to my oAuth server will send an authorization code as a callback to a specified webserver (http://client-url.com in this case)
http://mydomainname/oauth2/?client_id=test&grant_type=authorization_code&client_details=test&redirect_uri=http://client-url.com&response_type=code
The server at http://client-url.com will receive a response containing an authorization code and the developer will be able to store a user's oAuth credentials accordingly.
Obviously a mobile device isn't a webserver, so is there a standardised way of dealing with this? I've read online that you can define something called a custom URI scheme within iOS and Android apps. But what about the other mobile platforms out there? And desktop apps? I want my API to be accessible from as many platforms and devices as possible.
The reason why I'm asking this question is because I want to add validation to my oAuth server so that users can only register apps with valid callback URL's. I wasn't sure if should allow any other type of input as a callback apart from a valid URL.
Can anyone shine any light on this? I want to avoid spending hours validating and testing this across all devices as I'm sure anyone that has developed for multiple mobile platforms in the past must have some knowledge about this.
Thanks in advance.
I work for a company that develops a software product that processes bank transactions and gives the user insight into his/her spending. Our customers (usually banks) integrate the product into their online banks.
I have a question about securing the communication between the online bank, and our system. Before I ask the question, I want to give you some background.
The bank will usually install our system on a set of servers in their hosting environment.
We offer a number of ways to integrate:
Web services - In this case the bank will make calls to a set of REST services on the server, and then generate a webpage with the results (on the server side).
Iframes - In this case the bank will embed iframes in their online bank webpages. The iframes contain webpages rendered directly from our web application.
Inline widgets - In this case the bank will embed JavaScript references on their pages. When the document loads, the JavaScript widgets will render themselves, using AJAX calls. They communicate with a proxy on the bank server, which in turn communicates with our webapp.
We currently have a custom solution where we generate and sign security tokens for the users, and pass these with the requests.
But as banks have very strict security policies, they would feel better with us using a known and trusted security protocol for the communication. It is a big concern, which we want to address.
So the question is, which protocol is best suited for the integration use cases I listed above? There is a plethora of single-sign-on standards out there, and solutions like SAML, oauth, etc. I get the feeling that these solutions might be an overkill for my situation.
I want to find a solution that is simple. As the servers will run side by side in the same hosting environment, and trust each other completely, there is no need for the end user to authorize one or the other (or being redirected between, clicking buttons to give access to the app).
That is, the security protocol should not require any intervention from the end user. The end user simply logs into his/her online bank, and via secure communication has access to the data from our web server.
So...any suggestions?
Thanks a lot!
OGG
After some deliberation, we decided to use 2-legged OAuth (online bank uses consumer key and consumer secret to sign requests to our app).
OAuth signature can either be put in a request header, or request parameters. It nicely solves our problem, as the REST requests can be signed, and the IFRAME src URL-s can also be signed (all communication is over HTTPS).
For those interested, a couple of references:
This article shows using OAuth with IFRAMEs: http://developer.tradeshift.com/blog/cross-site-user-verification/
This article mentiones some security issues with OAuth, and how threats can countered: http://software-security.sans.org/blog/2011/03/07/oauth-authorization-attacks-secure-implementation
I'm reading the Terms of use which can be found here: http://code.google.com/apis/visualization/terms.html
But I do not see anything telling how Google use the data provided to generate the charts. Can someone be kind and enlighten me?
The Privacy Policy is likely to apply here. The relevant part should be:
Log information – When you access
Google services via a browser,
application or other client our
servers automatically record certain
information. These server logs may
include information such as your web
request, your interaction with a
service, Internet Protocol address,
browser type, browser language, the
date and time of your request and one
or more cookies that may uniquely
identify your browser or your account.
In combination with
Affiliated Google Services on other
sites – We offer some of our services
on or through other web sites.
Personal information that you provide
to those sites may be sent to Google
in order to deliver the service. We
process such information under this
Privacy Policy
Because you send the chart information with the URI and thus they will at least log it.
We have an automatic reporting and notification system written in .net that sends emails with plain text. We are having to encrypt the messages that we send our clients.
The possible implementation approaches we have:
Send messages as S/Mime email with attachments.
Plain text email with that just contains a link to a web site that will display the message over https.
It seems like S/Mime is a simpler solution, as we won't need to create the web application or secure it.
Our concern is our interoperability with our clients email clients and more importantly their email filtering software.
Has anyone had success or issues deploying a Secure MIME messaging solution?
Given the wealth of different clients people use these days for email, like BlackBerry, Iphone, Android, Samsung, Nokia, Thunderbird, Outlook (Express), Apple Mail, web mail etc, I would go for the web application over https. It does take an extra step of clicking the link, and logging in, but it could be used from a lot more devices without extra configuration steps.
How are you going to solve the problem of provisioning the destination certificates? If you send mail to 1000 users, you need to send it 1000 times, and each time use a different public key, the one for the current destination (so that only he/she can decrypt it and read it). Having each individual report final user create a key for himself and send you the associated public key so you can associate the report mail with it is problematic. Some PKI infrastructure products can help, but only inside a (tighly run) organization.
Securing only your web site seems easier to manage, since you'll have all the ends under your control. You still have to handle authentication, but that can be handled at the HTTP level (eg. Digest, or even Basic over HTTPS).
SideNote: (you can edit this in an answer) Not all mobile clients support SMIME. sadly the native android mail client (on Nexus 4, Nexus 5 etc...) does not support S/MIME . also, I personally have issues with the samsung galaxy SMIME support. Best (external and paid for...) solution I have found so far for android is MySecuredMail.