Archive for January, 2015

I am in a habit of using gestures on my touchpad to scroll the webpages. Now as soon as a press Ctrl to get a new tab, My page zooms into 400%.

So here’s how to disable pinch zoom/ scroll zoom on just google chrome.

 

Download AutoHotKey from here:

http://www.autohotkey.com/

 

Once installed, import the following script:

 

#notrayicon
#singleinstance
#MaxHotkeysPerInterval 1500
#IfWinActive ahk_class Chrome_WidgetWin_1
^WheelDown::return
#IfWinActive ahk_class Chrome_WidgetWin_1
^WheelUp::return

 

 

 

Thats it! You’re done.

We all have been there when we run our script, update the functions but still our intellisense is not updated. This feature has been long there in SQL but mostly people don’t know about it. So here’s the magic trick.

 

Intellisense in SQL Server 2008 is a time saving feature. But sometimes while writing queries, it starts underlining some object names or some column names which are already added in the database and these are correct but intellisense marks them as a MISTAKE.

In long queries, it creates confusion. I have seen my fellow DBAs turning off the feature to avoid confusion and mental stress;).

Also, sometimes intellisense is not helpful enough for auto-complete feature.

Solution

A simple solution for this problem is to refresh local cache by using Ctrl + Shift + R. So it should start marking only real mistakes. You can also refresh local cache from Edit— >IntelliSense — > Refresh Local Cache.

 

 

Apps for mobile devices, like tablets and smartphones replace more and more the traditional desktops and notebooks for internet-based services. For a solid number of apps in the various App Stores it is nearly every time mandatory for the users to authenticate against the App (for using the services the App provides). This often raises the question how to store the username and the password on the device securely. The easy answer to this is: unfortunately not possible. A Keychain to store sensitive data securely has been offered by iOS since version 2.0 and by Android since version 4.0, but you should keep in mind that it is still possible to read all those values stored there.

The problem:

Since the Keychain on Android was established in version 4.0 and apps often have to support older versions, the only possibility is to use the integrated AccountManager or the Shared Preferences folder, which every app has included. On iOS you can use the Keychain without hesitation. It is also possible to save informations within the app folder structure (preferences files or SQLite database).
The Keychain on both systems has a prevention against unauthorized access, but both systems are Linux/Unix-based and they share a user who has access to everything: root. By using a root exploit it is possible to read all stored secrets on a mobile device. Since Android is suffering from a complicated update policy it is much easier to achieve this: regarding the current statistics [1] still 9.6% of Android devices are using the old versions Froyo and Gingerbead (2.2 – 2.3.7). 33.9% are using KitKat (4.4) and the newest version Lollipop (5.0) isn’t even mentioned. Especially the devices with Gingerbead and Froyo won’t get any new updates to fix security vulnerabilities. On iOS it is often argued that there are no root expoits, but the Jailbreak community has found one for every single version and has published it. Currently team TaiG has found one for the newest iOS version 8.1.1. For iOS 8.0 team Pangu published it and for iOS 7 it was the Evasi0n team. A root exploit for iOS is sold on the black market for 500.000$ to 1.000.000$ [2]. Public authorities like the NSA are willing to pay such an amount. Nevertheless, this does not necessarily mean that there are no exploits if they aren’t publicly available.
Let’s have a quick look at the Keychains:

 

 

The Keychain file itself (keychain-2.db) is protected with the device key, which can be obtained through jailbreaking / root exploit. Every entry is encrypted with the passcode key. When unlocked the users passcode is encrypted many times using a modified PBKDF2 (Password-Based Key Derivation Function 2) algortihm (AES with the UID key) to generate the passcode key. This key is hold in memory till the device is locked. A lot of users are using just a 4 digits pin which makes it easy to brute-force (average time is about 15 minutes). Hopefully this get’s better with the new Touch ID feature, introduced with the iPhone 5S.

 

 

Each Keychain Entry is encrypted with the 128-bit AES master key in CBC mode. The master key is a 128-bit key created by reading from /dev/urandom. It is encrypted with a hash of the users lockscreen password created with the PBKDF2 function from the SSL library (till Android version 4.3.x). Since Android 4.4 (KitKat) the PBKDF2 key derivation function (KDF) is replaced with scrypt [3].

The solution:

The question for an app developer now is: How can you make sure that the customers can use the app with all features without storing the password on the device? The solution: a token-based approach like OAuth 2.0 [4]. During the first start-up of my app, the customer has to provide his username and  password once. Afterwards, the app receives a token from the server which is going to be used as authentication. This token can be stored encrypted in the Keychain. The advantage of this  approach is that if an invader gets access to the device or records the token via a Man-in- the-Middle attack, he only receives a restrictive token which is only usable for certain use-cases (like viewing only some content, synchronising contacts and so on). He won’t receive the password for an email account or maybe a bank account and so on. Tokens also have the advantage that they can be  revoked and only are valid for a certain time.

tl;dr

Currently there is no practical way to store a password safely on a mobile device. Only the token-based approach is helpful here.

Links:
[1] http://developer.android.com/about/dashboards/index.html
[2] http://grahamcluley.com/2013/07/zero-day-ios-exploit/
[3] https://www.tarsnap.com/scrypt.html
[4] http://oauth.net/2/


 
There is something strange going on in the world of smartphones. At a time when every company is talking about their phones powered by 8-core processors, Apple continues with a dual-core processor in the iPhone 6. Just two cores in the iPhone 6! Sounds implausible for one of the most expensive phones in the world when something like the Xiaomi RedMi Note, which sells for less than Rs.10,000, rocks a 4-core processor.
 
Is Apple ripping off consumers?
Is iOS, which powers the iPhone 6, is so easy on resources that it can be easily powered with a dual-core processor while Android KitKat or Android Lollipop needs a quad-core processor?
The answer to both questions is no.
The truth is that the dual-core processor in the iPhone 6 is the world’s fastest mobile processor. Yes, you read that right. The A8 processor, which has two cores and runs at 1.4 GHz, in the iPhone 6 is faster than the Qualcomm Snapdragon 805, which is the fastest smartphone processor available to Android phones, even when the Snapdragon 805 has four cores and runs at a speed of up to 2.7GHz.
The reason why Apple’s dual-core processor beats all the four and eight core processors is because Apple has made the right choices (and right compromises) in designing its processors while in the world of Android, companies are just chasing after the core count.
 
To understand this keep the following in mind:
— The processing power of a chip depends on a lot of factor. Core count and the speed are just two aspects of it.
— More important aspects when it comes computing performance is memory bandwidth, latency and ability to execute threads in a more efficient way. This governs the instructions per cycle (IPC) that a processor can push put.
— IPC depends on many aspects but it is not a given that high clock speed or more number of cores leads to better IPC.
Keeping this in mind, here is what is happening in the mobile world. Apple, which started designing its own processors with A5 in 2011 probably because it felt no other company was taking the right approach, is going after the IPC. Now IPC is something that sounds bad on a marketing brochure. The number of core sounds more sexier. So other companies like Qualcomm and MediaTek are focussed on increasing the number of cores even though it doesn’t matter.
So how is Apple making its processors faster even though they have just two (or in the case of A8X in the iPad Air 2, three) cores? Here is how Scott Wasson, the technology guru at the TechReport explains it :
 
While many of its competitors have taken the path of increasing core counts in their latest SoCs, Apple has built one of the highest-throughput mobile CPU cores anywhere. We know even from big desktop PCs that the user experience is often dominated by the performance of one big, hairy thread that’s difficult to execute. Apple’s decision to pursue higher per-thread performance instead of expanding the core count seems like the smart course.
In simple words, Apple is building its processors with a wider and more complex pipeline that also has a great deal of focus on maximising memory bandwidth. It is not easy to build processors like these. Processors with longer and simpler pipeline are easier. The longer pipeline also helps companies clock processors high, so they can tell consumers that their processor runs at 3GHz.
 
But Apple’s approach is to build a processor that is more efficient. This means its latest processor A8 not only gives better performance with just two cores but also consumes less energy, which means better battery life.
So, how fast is the dual-core A8 in the iPhone 6 compared to the quad-core Snapdragon 805 in the Galaxy Note 4 and the 8-core Snapdragon 615 in the HTC Desire 820. Here are some numbers from GeekBench.
The quad-core Snapdragon 805 is faster in multi-core benchmark but that doesn’t matter in real life because most of the apps can’t properly make use of multiple cores. When it comes to computing performance there is a saying that there is no substitute for good single-thread performance and that is where the iPhone 6 is so much faster compared to other devices.
We saw this earlier in 2006. When Intel and AMD were racing against each other and AMD started gaining an upper hand due to its better processors in 2002 and 2003, Intel decided to counter by increasing the speed of its processors. But even as Pentiums ran at a speed faster than 3GHz, they mostly lost to AMD processors in terms of performance because the IPC was low.
Intel changed this in 2006. It came out with Core processors. The first mainstream processor using the new technology — E6300 — was so good that it beat the most powerful and expensive Pentium processors silly even when it was running at 1.9GHz while the Pentium ran at a speed of over 3GHz.
Something similar is happening in the world of mobile processor. In terms of their underlying technology, in many ways the processors used by the Android phones resemble the power-hungry and inefficient Pentiums while the processors created by Apple are more efficient. No wonder the Apple A8 beats the quad-core and octa-core processors even though it has two cores running at just 1.4Ghz. Best of all, it also helps Apple provide better battery life in its phones.
The only way this situation is going to change is if companies that make processors for Android phones start improving the core technology inside the chips or in other words improve the CPU architecture. Or else Apple will continue to hold the processing lead.
Moral of the story:
Not all cores are created equal, and you should not buy a phone just because it is powered by a quad-core or octa-core processor.
This article orginally appered in Forbes Magazine,Credits to Elise Ackerman for this.