Tag Archives: Phising

Eddystone-URL opens doors to opportunities and threats

Google launched a beacon Eddystone project and created a new ecosystem connecting physical items with Internet. Estimote Eddystone page gives an example : “The URL could be a regular web page providing relevant information—e.g., a beacon next to a movie poster could broadcast a link to a YouTube trailer. It also could be a dynamic web application, with contextual parameters embedded in the URL—e.g., http://my-restaurant.com/check-in?restaurant_id=6523.”

How true is this statement? What are the infrastructures needed to enable this seamless integration between physical and virtual? More importantly, what are the security and privacy implications? 

The importance of Eddystone project comes from its introduction of an open source format for broadcasting a URL from physical items. In laymen’s term, it enables every physical object to have a unique URL through a BLE device sticking to it. Any smartphone following the protocol will grab the Bluetooth signal, decode it and bring a web page showing relevant info. It is much more flexible than iBeacon which only show UUID, Major and Minor.

Implication is that you DO NOT need to type the web link manually when you see a poster. The poster and your smartphone talks and show the website. NFC does this also but the distance is too short. BLE has an effective range of 20-30 meters.

Sounds simple but currently no browser is able to receive Bluetooth signal by default. The future implementation will require the user to install a mobile app specifically built with Eddystone functions. Take the example mentioned in Estimote Develop Doc, Youtube app needs to launch a new version with Eddystone enabled and show the trailer. (Given Google owns Youtube , it is a massive advertisement opportunity for Youtube.)

User Experiences Issues

On user experiences, I reckon that a new version of Youtube will add a “Scan nearby” button and when pressed, a list of URL (broadcast via EddyStone protocol) will be shown to user to select. Youtube will have hyperlocal targeting capability and be able to show relevant videos relative to where the user stands.

However,  it is not that convenient and promising. Eddystone-URL is an open standard and not encrypted, due to business competition each mobile app developer will not decode received URL if it is not from their own company. A Nike shopping-app will not show a Starbuck URL even it detects a strong signal. To enjoy the benefit and browse the information advertised by Eddystone-URL, a user needs to change app every time he move from one shop to the other. Actually the major road block is user must already know which app to launch. For movie poster, it maybe YouTube app. For car parks, it may be the car park operator app? or the shopping mall app? Or just google map? Launching the wrong app will not be able to decode the URL and display relevant information.

Changing apps frequently and prior knowledge to identify which app to launch are not impediments to wider adoptions of EddyStone. Would it be nice if Google release a new version of Chrome which will accept URL input in additional to the decade-old address bar?

When Chrome is Eddystone enabled, user will be able to see suggested URL from the surrounding environment. Each Eddystone-URL enabled physical object will broadcast their own URL and a smartphone user will be able to select which object most interest them. When this happens, there are security concerns.

Security Issues for unfiltered Eddystone-URL

The prime objective of Phishing emails and Spear-phishing is to lure users in clicking an URL and visit a website. Sometimes, the URL brings up a website which already infected with malware. Other times, the exploit is already in the URL. If there is another channel to deliver a maliciously crafted URL to users’ smartphone, I am sure attackers or cybercriminals will welcome it with open arms! Like most of the Internet standards, security features is missing in the first version. (Anyone remember what happen with the first Wifi standard was released!) The Eddystone protocol does not provide to mechanism to validate or authenticate the broadcasting URL. Eddystone only specifies the data format and application layer security is missing. If a user see a broadcasted URL in browser and there is no easy way to validate its content is secure, out of curiosity the user will likely open the URL and find out what is it. Their smartphone may be infected with malware if the website is controlled by cybercriminals. When browsers enabled with Eddystone-URL, there is a risk of bogus beacons broadcasting URL pointing to phishing websites. This will hugely impact the adoption and usefulness of Eddystone-URL.

A filtering mechanism or URL authentication is essential to the wide adoption of Eddystone-URL. Broadcasting URL from physical objects will enable lots of innovative applications by directly bring rich content to our physical world. However, when this technology gains majority acceptance, security and user protection is a must.