A fake, android powered iPad in Dragon Mart.
The Internet as we use it today, has very little privacy left. We all say that Facebook and Google know “too much”, only to realise that they don’t know anything aside from what we feed them, or do they?
Welcome the “widget”. A piece of html (with css, javascript..) to be included in another page, often to socially spread content (Facebook Like, Google +1, LinkedIN share, etc), or other added value (Analytics, sharing, etc) will tell many “providers” what content you are accessing.
It is difficult now to find a popular page without any widgets. Pages pack “like” buttons, “share this” widgets or tweet options to give you a instant way of sharing their content in your social network – banking on good ‘ole word of mouth marketing. If your friends like something, you might be interested also, even if it was only for peer pressure.
The problem that when something (such as the widget) is requested, browser data (such as your session’s information and the referer) also flow to the widget provider’s webserver. This provider will know what page you’re on and usually who you are (assuming you stay logged in into google, twitter, facebook, etc)
Thinking “but if I like a page, facebook will know it anyways“. This is true; the problem lies in the fact that providers know you’re accessing a page, regardless of performing any action (liking, sharing, etc). If you read X number of pages on a new model smartphone, chances are big you want to buy another one – and targeted ads become more… targeted.
From that advertising point of view, it creates mixed feelings. It’s like somebody overlooking your shoulder while you’re reading a magazine and changes the ads accordingly to which article you were staring at longer.
From a website owner point of view, this does create added value. If you can convince to have websites publish your widget code, you can track people’s interests, even before they ever came to your website. This (unidentifiable) user eventually ends up on your web app, identifies him/her self and you have great information. I’m just not sure how ethical this is, and even though Facebook’s outdated law enforcement guidelines don’t hold “webpages visited” in particular, they would have access to it.
Is this such a bad thing? Perhaps. “Widget providers” offer added value to website owners, who in turn decide what goes into their webpages. Vague idea, but maybe a browser extension could prevent the loading of these widgets, replacing them with a pseudo equivalent (fake buttons, etc) and only dynamically load the target script upon a click?
Food for thought. Now, look at the buttons below, they know you’ve been here already.
For a new web project, I’ve been looking at Rails 3.1, the latest update of the popular Ruby on Rails web application framework.
Although I just started on it, and haven’t seen all the goodness, one thing that raised my eyebrows is how static content a la CSS and JavaScript is handled, through an asset pipeline.
In a nutshell, since I’m doing the JQuery bit of the site now, wouldn’t it make much more sense to fetch the libraries from CDN’s, cache the remaining recurring libraries in Nginx (or Apache), and leaving the page specific bits in one big <script> tag, instead of pushing all in a bloated application.js page?
Then again, although I think Rails was what the web community needed, I always had my ideas about frameworks.
Thanks,
Michael
Note that this post is for awareness and educational purposes only. I do not encourage, and cannot be held responsible for malicious actions using these tools.
The Internet, as it is today, is a mash-up of JavaScript enabled services, often included from external websites. Internet companies offer so-called widgets, which are JavaScript tools that can be used in your own page. Popular examples of this are site analytics (Omniture, Google Analytics, etc) or share-abilities (AddThis, AddToAny, …). It’s by overwriting Javascript libraries on a page, that we can do other things, such as recording keystrokes.
“Overwriting” javascript libraries, or rather “inserting javascript” can be done in several ways. Cross Site Scripting is one of them, but for the sake of this blog post, I will act as a malicious proxy administrator, and overwrite the Google Analytics DNS entry (www.google-analytics.com) and “fake” the ga.js javascript file.
For this, you’d need only 2 files:
This javascript file, found here, holds 3 parts: JQuery, a base64 encoder and the keylogger code itself: Continue reading…
The 7 days newspaper was subject to a “meta refresh” hack earlier today, yet it seems to be fixed already. When going to any link, it would point to the following page:
It seems to be hacked by a particular W0LF Gh4m3d, a person who does several defacements without any political agenda. One of his/her hcks was “www.wijnabonnement.nl “, which actually translates into wine subscription, not a good thing putting a Saudi Arabian flag on there, is it?
A friend of mine is using the Newscast for his blog. It is a great looking theme that has an image preloader written in JQuery. It was all looking good in Firefox, but wasn’t displaying properly in IE and Opera.
The javascript fails around line 60 in themes/TFnewscast/js/custom.js:
jQuery('#main').kriesi_image_preloader({delay:100, callback:removeloader});
This can be fixed by surrounding it with a if statement that verifies that you’re not running IE nor opera:
if(!(jQuery.browser.opera || jQuery.browser.msie)){
jQuery('#main').kriesi_image_preloader({delay:100, callback:removeloader});
}
And that should do it.
A particular aspect in IT security is injecting malware into websites. Often leading to so-called “drive by downloads“. This malware is often inserted due to a browser vulnerability which gets executed by, say, Javascript. The latter is usually “inserted” in a legitimate website using a hidden <IFRAME> tag or similar.
How can this be stopped? Modern websites include, because of widgets, several external Javascripts onto their own sites. When going to the gadget popular website engadget.com, a total of 17 hosts are contacted… Continue reading…
After three years of series of using BlackBerries (work and personal), I went to the dark side and got myself an Android phone.
It was a bit getting used to (and necesarry nagging from my end), but here are some of the reasons why I love it, and some reasons why I miss my Blackberry:
Continue reading…
In Ruby on Rails, authenticity tokens are generated to prevent CSRF (Cross Site Request Forgery) attacks. These tokens generate a unique “identifier” to prevent other website from making requests on your behalf, or so-called “session riding”.
In Ruby on Rails, to have this identifier available for you, you need to put <%= csrf_meta_tag %> in your view, usually in app/views/layouts/application.html.erb. This tag creates something like:
<meta name=”csrf-param” content=”authenticity_token”/>
<meta name=”csrf-token” content=”uDDuQj14CCJ…”>
If you create your own AJAX functions, say with JQuery, you would need these values in order to have rails handle your request. This can be done using the following:
var param = $(‘meta[name=csrf-token]‘).attr(‘content’);
Which you can use then in your AJAX requests
$.post(‘/post’, { body: $(‘#post_body’).val(), authenticity_token: param }, function(data){
var ret = jQuery.parseJSON(data);
if(ret.status==”ok”) {
…
