Which of the 10 URL Shorteners are not hostile to Tor?

I examine 10 URL Shortener Services one by one to evaluate its hostility towards Tor Browser.

Those that put road blocks in the way such as using CAPTCHA or other techniques are classified as hostile services. Another requirement is that it should also operate properly in Android's Orfox, the Android's kind of equivalent to Tor Browser.

If it works in laptop/desktop Tor Browser and not in Orfox, it is still classified as hostile. Any service that requires log in etc. even though not presenting any hostility road blocks is placed in the "Useless" category. Too much trouble.

Tor Browser users should black list those hostile services as they do not possess any uniqueness as the review below shows there are friendly alternatives. In that way the Tor community can deny them of visits and advertising dollars, much like AdBlock Plus.

Tor users can refer to this Tor Project sites for more comprehensive list of Tor hostile sites.

Only 5 out of 10 are Tor friendly. Naturally Google is one of the hostile one.

Tor Friendly site

Bitly
In Orfox, one needs to add cloudfront.net and Googleapis.com to NoScript's whitelist.

TinyURL.com
There are times that this site demands CAPTCHA validation and need more experiment to determine its friendliness.

AdF.ly
One needs to add this to the whitelist in the NoScript in Orfox.

Bit.do

Mcaf.ee
Given this is in beta, it loads slowly but still works in a no-nonsense manner. Hope it will not be hostile to Tor as it matures.

Hostile Services

Goo.gl

Ow.ly

Is.gd

Useless

Is.gd

X.co

Way to by pass Tor Browser hostile web sites

It is really a form of anti-Net Neutrality for web sites, most notably web hosting sites like CloudFlare, to discriminate Tor Browser users by putting all sort of childish barrier in an attempt to prevent Tor Browser users from gaining access to the materials.

Perhaps by comparison, CloudFlare is not as anti-Tor as Akamai which simply greeds Tor users with 404.

It is an easy way out to treat all Tor Browser users in the same boat as those using the tool to abuse the system. If that kind of thinking prevails, may be we should all shut down the Internet as not a day gone by without seeing an attack being carried out on the Internet. Any other way would require intelligence that they have not got and it is also a good sales material of telling their customers that they could block all those abusers using Tor.

Thankfully, there is a way to get past playing their childish game. I simply route the access through Start Page's proxy from Tor Browser. Just do a search on the link from Tor Browser and then uses the proxy to access it.

Lenovo SHAREit - turning a useful program into a useless one

I once enjoyed using Lenovo's SHAREit program on my Android phone and pairing it with the one that came with my Lenovo laptop and have been recommending it to others.

This was in the day of ver 2.x of this program. That version was not only functional but also lacking any of the fancy stuff. It worked wonderfully.

Like many software, Lenovo changed all that in version 3. Instead of letting the program running on the devices scanning for compatible ones, its only option offered to connect to the PC is to use the camera to look for a QR code from the laptop's version of SHAREit.

Surely just because there is a camera in the phone, you don't really have to use it in preference to a workable solution in ver 2. To work with version 3, even though all other facilities on the Android phone and laptop are unchanged, users have to do a version 3 upgrade.

It is not hard to find it and after I installed the version 3, it popped up the EULA and unless I allowed this program to suck up my personal and usage information and hauling it back to Lenovo, I could not use it.

So I treasure my information more than SHAREit and hence without hesitation I hit the decline button and so be it. I highly recommend everyone to do so as I am offering you a much less surveil method.

So disgust with Lenovo's SHAREit, I summarily uninstalled it from my laptop and all the Android phones I have. Good bye SHAREit with pleasure.

If your laptop and phone have bluetooth, why not put that into good use and you can follow this well written instructions to use it.

The best way to send file from the Android phone to the paired device is to use the share facility.

I encourage any user of SHAREit to uninstall it as it only puts a glossy veneer on top of facilities already there with the aim to capture your data.

If all else fail, the USB cable is just as good and one does not have to submit to Lenovo's unreasonable demand.

Is building a better mouse trap (Signal Private Messenger) enough to win market shares?

I am please to see the release of Signal Private Messenger for Android and iOS, a messaging application that has earned full marks in the EFF security score sheet. I am a fan of this product and I like it very much for the following reasons:

• It is an open-source project offering the service for free. WhatsApp is not a free.

• As a result, it can be reviewed by anyone capable of doing it while WhatsApp is proprietary, even though it claims to be underpinning by Open Whisper Systems but no one has reviewed that. Recent event has indicated that WhatsApp messages have been intercepted and decoded.

• It is not owned by any company while WhatsApp is owned by Facebook, Skype by Microsoft. Thus all metadata in WhatsApp and Skype belongs to Facebook or Microsoft respectively.

According to well-known security researchers, Bruce Schneier and Matt Green, Signal is developed to a very high quality to provide end-to-end encryption (E2E) not only for messaging but also for voice and their endorsement must mean something.

I am not here to raise doubt of this product which I am using admittedly with very limited users to interact with and I have great trust. I hope it will do well.

But I am here to question whether it is enough to rely on technical superiority which is so well hidden from the users to induce them to switch to Signal and to grow its market shares. That's is: is building a smarter (more secure) mouse trap enough to win market shares? Other class of software such as web browser, anti-virus, media player, or mail client can draw people to switch based of superiority of features.

Looking at the landscape of messaging applications it is difficult to see how Signal can rely on security implementation, so out of sight of the user, to win market shares. Will this become a replay of VHS (WhatsApp, Skype, etc) vs BetaMax (Signal) of the 21st Century?

Messaging applications are like clubs or cults in which they only allow club members to interact and go to great length to discourage inducement to leave and definitely providing no facility to support inter-club interaction. This produces network effect to draw people in and that also becomes disincentive to leave and its nurture of human social interaction provides a positive feedback to increase the network effect.

Looking at the EFF Security score card, most of the popular messaging applications do not use security best practices and their inferiorities do not seem to matter to the users. The anecdotal conclusion one can draw is that users do not care with online privacy and security despite well publicised massive surveillance activities. Unlike other type of application, such as web browser, there is no report of people deserting one messaging application to another, despite vulnerabilities and caught not using secure messaging mechanism when they claim to use. For those entrenched players, they must feel like in a no-loss situation. The only way they can lose to a competitor is by a total annihilation of the enterprise.

Messaging applications have another unique characteristics that it is not the features that draw users to choose a particular application; there is a great degree of peer pressure exerted by those early adapters unwittingly forcing people to form that circle of friends. This peer pressure then forms a vortex to draw more and more people in. Their only concern is to be able to communicate with the club members.

Because of the lack support for inter-application interaction, the application through using proprietary communication protocol forms a natural barrier for their user to leave. Apart from that, the user does not see any benefit for using a different application that essentially providing the same things - messaging and may be voice - and having to desert their friends. So why leave? What is the benefit to them?

Many users of messaging applications also form the mistaken belief that they can only use one messaging application in their device. Perhaps it is this mistaken belief or blind fanaticism to their favourite application they are also reluctant to install other messaging applications to increase their reach to their friends. Since Signal is so similar to WhatsApp, it is simply a matter of installing and waiting for others in the contact to install their copy of Signal to re-establish communication. Even that simple is not enticing.

I have spoken to several users of messaging applications as well as non-users and recommending to switch over to a more secure application called Signal. But telling them the benefits of Signal is like talking about wine apprecThis is particularly difficult when Signal is so similar to the operations of WhatsApp separated by a thin veneer of technical features. In view of this, users of WhatsApp (or other app) are unwilling to desert their circle of friends to use something that to them is almost the same thing with minute user base, by comparison. iation to a group of teetotalers. To them the improve security and end-to-end encryption (E2E) are not enough to sway them. Even people that has not used messaging application seems to be reluctant to get onboard with Signal because they have not heard of it being mentioned by their friends.

So I wonder how a late comer like Signal can overcome these barriers to increase its market shares? How it can base on technical superiority to entice users who are disinterested of them that Signal relies on to distinguish it from others? What is the future of Signal apart from being a niche player at best? Clearly Signal needs to improve its image and marketing.

From the analysis, users of messaging applications place extremely high premium on their ability to reach their circle of friends and ignore other issues like security and privacy. Therefore if the new comer, like Signal, wanting to rise up, it must give their users a transparent way to interact with their circle of friends without requiring them to switch en masse like the present situation. How to achieve that is the real challenge in messaging application development in view of no standard communication protocol?

Comments on using e-mail address as username for online services

I have encountered more and more online facilities using e-mail address as the user name. In my mind, this is a lazy way for the service to check or to provide a unique user name when creating an account. In some rare usage, this may be fine but generally this is a very restrictive form and the reasons are given below.

Using e-mail address has the following problems:
1) While it is unique in the universe of the Internet it does not uniquely identify a user of the service, thus unsuitable as a user name unless the service has other facility to deal with one e-mail address for multiple users.

For example if one manages several properties or funds belonging to different entities under some management agreement, it is often convenient to use one e-mail address for all these properties or funds. It is also possible that the e-mail owner owns all those properties or funds, it is unreasonable to base that identifier on an e-mail address which does not map to a unique entity; e-mail address is for correspondence - like a house address.

Who would then use a house address to identify a person living there when it can house several persons?


I have seen one service that uses the user name (aka e-mail address) as a proxy to a fund account. This then assume the owner of that e-mail address cannot have more than one funds - one may be for him and another for some other ownership arrangement with correspondence being sent to the same address. Clearly the developers have not model the usage requirement well.

This silly design is like the above house number analogy requiring a house to house just one person.

The assumption that an e-mail address uniquely maps to a particular person or entity is unsound. Don't do it. It is far better and more secure if your system generates a unique number, a la, account number, for the user.

2) The use of e-mail address as a user name can confuse user in that he/she has to supply to the online service the same password for e-mail account. This can lead to an increase (or subliminally encouraging) reuse of password, a dangerous practice.

To a less technically savvy person, he/she may be misled into believing that the e-mail provider now have access or linked to whatever materials available in the online service.

3) While it is infrequent, though not impossible or improbable, for people to change e-mail address, services that uses e-mail address for correspondence as well as for user identification inevitably prevent user from changing e-mail address. This is because it is using a very poor design pattern - one piece of data to serve two distinctly different and diverse purposes. The user name is to identify a user which an e-mail address does not and the e-mail address is for correspondence, like a house address which can be used by anyone living there to receive correspondence.

If you ask correspondence sender to simply put the address on the envelope no one in the household will know to whom is that letter addressed; you need to put the addressee's name (the user name). A person could one day moves out of that address; he/she retains the same name (user name) but simply changing the delivery address (changing the e-mail address). This happening may not be frequent but not improbable or impossible.

No right minded person would combine the two (addressee's name and the delivery address) but why do that in the computer system?

To address this kind of short coming, they then have to provide a means for the user to define an e-mail address for correspondence. In this situation which one should the system uses during account set up and validation purpose?

How to overcome this poor design as a user?

If you, as a user, are confronted with this problem - how to use one e-mail address for more than one users of the service - you may try this solution provided that:

• Your e-mail provider supports e-mail alias. GMail and Hotmail support them. If you provider does not supports this, set up a GMail account as a mail redirector.
• Your online service's user name (aka e-mail address) validation knows about RFC 822 - Section 6 Address specification. Those failing to parse this properly would reject your e-mail address with alias.

Then use e-mail alias (like Somebody+Property1@GMail.com or Somebody+Property1@Hotmail.com) to allow one e-mail address to be used for several entities. The '+' character in the local part of the e-mail address is valid and permitted under the RFC. If their developers tell you that it is an incorrect address, point them to the RFC.

Those thinking of using e-mail address as a user name to relieve them the task to validate its uniqueness needs to validate the e-mail address to conform to the RFC.

To me, the task of validating and ensuring a user name is unique within the system is far easier than validating the e-mail address because the latter needs to check:

• conformance to RFC
• that the e-mail provider supports the e-mail alias that the user enters, as the service has to make sure it is a reachable address to receive correspondence. If that alias syntax is not supported by the mail provider, conforming to RFC does not guarantee it can be used for correspondence.  

Here lies the danger of tying the two purposes to one piece of data, that is using an inappropriate design pattern.

To install or not install an application - what are the pros and cons?

With the advent of USB devices, many applications that once require an installation process for deployment have been converted to run without one so that the user can use that program directly from the USB device on any machine and a large collection of them can be found here mostly utilizing their portable application framework.

Other program, such as TrueCrypt or its replacement VeraCrypt offers a much simpler model; it simply offers you a way to extract the files into a directory and one can execute the program from there.

I have been a fan of this convenient deployment model for a long time and in particular of avoiding any impact on the underlying operating system. It is particularly helpful in troubleshooting without the need to install anything. Just run!

However, recently I have been having second thoughts whether the benefits of this model is worth the risk of allowing malicious attacker to contaminate the program to do harm? When needing to a USB device in an environment that I do not know its sanity, I always probe it using tools carried by locked SD-Card. In this way, I am protected from being a carrier of attacks or being attacked.

Going back to the history of Windows beginning in Windows 2000 (aka NT5), Microsoft has been using the profile to define a set of file and registry security templates to protect executables and key information, although much of the good intention was discarded in favour of convenience and ignorance. Microsoft had to do something to rein in the unruly behaviour by introducing the UAC in Vista to the dismay of large unappreciative community.

Apart from other benefits, the main aim of the file system security is to protect key files from bring modify by user without administrative privilege. From Vista onwards, all applications run by default with standard user privilege and that means that they cannot make changes to program files or protected areas. This is a good thing and has improved the security of Windows a lot.

Now if instead of installing a program that requires administrative rights to carry out and deployed into designated protected areas, we modify the deployment model of the program to allow it to run from anywhere, doesn't such a practice is a throwback to the good old days of NT4/5/XP (run everything in admin account) style? Aren't we then essentially turning the file system protection off for these programs? Aren't we making our programs more vulnerable to attacks?

What caused me to ponder is my latest installation of VeraCrypt 1.16 that has fixed a couple of recently discovered critical vulnerabilities. In the past I have been using TrueCrypt in portable mode without installation. Then I wonder: wouldn't this mode of deployment makes it easier for others to attack the program or to use this program or this type of program, running at elevated privilege, to launch attacks?

In the end, I decided to install the program. What is your opinion on this issues?

In Linux, by default it does not allow programs to run from removable devices.

Caveat for Link Market Services Registry users using Password Manager

This is a note to any users of Link Market Services Share Registry service that use Password Manager to manage their password.

It seems Link Market Services discourages people using password manager, a practice that is recommended by security experts, and it expects the users to have some sort of psychic power to know why.

Recently, I have encountered an operation that requires me to supply the Transaction Password. Since I used a password manager to generate and record passwords, I simply asked the password manager to transfer the transaction password to the field in the Link Market Services web page. The transfer happened flawlessly but the confirm button remained disabled as if I had not type anything. That's strange. There was no textual guidance and no pop up message box to tell the user what to do.

Not deterred by this, I did some experiments and this is what you have to do if you want to use password manager:
1) Transfer the Transaction password to the field in the normal way your password manager offers.
2) Click on the field and press End key to force the cursor to be positioned to the end of your password. (Or enter a character to the end of the password and immediately removing it from the field)

The minute you have completed step 2, the confirm button is enabled! The web page at that stage does not have a clue if what you have entered a valid  transaction password.

It seems the web page has a user-interface bug failing to recognise the field change event.

This kind of bad user interface design makes your software sucks. If you do not want user to transfer data say via the clipboard, disable the paste operation and offer the users some form of guidance. If your web site does not have a general purpose help e-mail address, you need to make sure the user-interface of your web site to be perfect and idiot-proof.

On the subject of Transaction password, this is their mandated rule:

When you use the settings facility to change the Transaction password and if you use a password manager to generate the new password (highly recommended), after you have transferred the new password to the respective field, execute Step 2 mentioned above. Such action will trigger the script on that page to evaluate the supplied password. It seems the program has a bug similar to that mentioned above.

One wonders if the Link Market's mandated rule can encourage users to choose strong password. If Link Market discourages their users from using password manager, then the users will undoubtedly choose an easy to remember password (that will also ended up to be easily guessed by hacker).

For example the following passwords Pauline1, Password1 or Ab1234567 comply with the rule but according to Microsoft's password checker or Kaspersky's checker,  there are weak passwords. It is therefore better to encourage your users to use password manager rather than forcing them to choose easy to remember one.