Vodafone raises $5 roaming by 40% and scores own goal

By Steve Biddle, in , posted: 6-Jun-2019 07:43

Vodafone New Zealand have announced that from the 11th July 2019 they are raising the price of their popular $5 Daily Roaming option from $5 per day to $7 per day, a 40% increase.

Unlike roaming packages with other providers, the $5 charge is not a package or plan as such, but merely an arbitary daily charge that allows Vodafone On Account customers to use their included plan voice minutes, SMS messages and mobile data while overseas.

Vodafone say -

We understand the disappointment. However in the five years since we launched Daily Roaming this is the first time we’ve put the price up despite the regular improvements. Although we've had to increase the cost, we're confident that Daily Roaming delivers exceptional value.


Since introduction, we’ve increased the destinations from 23 to over 100, roaming costs in some regions has increased, mobile data usage has tripled but costs have remained constant, plus there’s now more value for customers in our core plans used while roaming.

Mobile roaming is complex – nobody is denying that. Something many people will be unaware of is that mobile data has to be tunneled back from the network in the country you’re visiting back to your your home network, where it then passes through the core network so it can be rated and billed, and then heads back out across the Internet.

It’s for this reason that using data roaming while in Europe for example can lead to a poor customer experience due the fact your data has to travel from Europe to New Zealand which is around 310ms away on a 4G connection (based on optimal routing and allowing 50ms for the 4G layer) and then if the server on the Internet you’re connecting to is based within Europe another 260ms is added as it heads back to the Europe. 560ms in latency while browing the Internet or using an online service will result in noticeable sluggishness.

Costs for providing roaming services have increased as growing numbers of people have decided to roam, and more importantly as data usage while roaming has continued to increase. Dimensioning of links between Vodafone and their roaming hub as well as links between Vodafone and direct bi-lateral roaming partners have all increased.

None of this changes the fact however that actual roaming costs incurred by networks have been in decline for years - I can’t find another example of a network that has actually decided to increase roaming prices. This increase quite frankly looks like a money grab from Vodafone which will raise them several million dollars per year.

As somebody who spends a lot of time traveling overseas (I’ll spend somewhere between 50 and 60 days overseas this year), Vodafone’s $5 daily roaming has kept me a loyal customer despite the fact Vodafone New Zealand under the leadership of former Chief Executive Russell Stanners was like watching a slow motion train wreck. Their profits before people focus in recent years along with cutbacks in capital expenditure has seen aspects of their network such as their 4G coverage now appear very poor in comparison to Spark. Being contactable is important to me, and $5 roaming has been the one thing that has kept me as a customer.

The $2 increase in daily roaming charges isn’t going to break the bank for me. The $100 – $120 extra per year it would cost me to use the service is a pittance compared to the amount I will spend on travel this year. It is however a matter of principle, and will see me seriously look at my options when it comes to both my mobile provider in New Zealand, and whether I go back to making more significant use of local SIM cards when overseas.

What’s surprising about Vodafone’s claims that prices have increased because costs have increased is that their argument falls apart when you look at their Prepay roaming prices which are not increasing – and depending on your usage Prepay roaming prices are already significantly cheaper than using $5 Daily Roaming.

On Account users will now be paying $49 per week just for the privilege of being able to use their included plan minutes, SMS messages, and data while roaming. You’ll pay this $7 daily fee regardless of how much you use your mobile phone – if you don’t use your phone you won’t pay anything, but even if you only send a single TXT message or receive a 1 min phonecall, you’ll automatically now be stung $7 per day for the convenience.

With the Government expected to introduce GST on telecommunications services used overseas from 2020 (currently roaming is and always has been zero rated for GST), we’ll see this $7 increase to $8.05 per day. That’s a big price to pay for something that actually offers nothing at all.

Vodafone Prepay users have several options that see their roaming costs being significantly lower for the average user, and significantly the roaming prices for Prepay users are not increasing. Only want to use data while roaming? 1GB data valid for 7 days will cost you $15. Want some voice minutes and SMS messages thrown in with that? You can get 1GB data, 100 voice minutes (inbound and outbound) and 100 TXT messages for $19.

This usage represents a typical usage amount for a roaming user (who tends to use more data than they do while in NZ, but makes fewer voice calls). It means that a typical On Account user is now paying $49 per week for something that is available to Prepay users for $19.

I would love to pay $19 for a week of roaming on my On Account plan – the allowance on that plan meets my requirements, and it would be a significant saving from the $49 it’s now going to cost me being On Account.

That really just poses one question for Vodafone to answer – why do you think such a big difference is fair? And where is the "exceptional value” you’re claiming daily roaming offers? Right now I’m struggling to see it, and this change looks very much like an own goal to me.



Using PriceSpy to check for Boxing Day rip-offs

By Steve Biddle, in , posted: 23-Dec-2018 22:50

Boxing Day is one of the biggest retail shopping days of the year in New Zealand. After a day of overeating on Christmas Day, New Zealanders rush out in their droves to the malls enduring traffic chaos and crowds all in the hope of picking up a bargain.

Big retailers advertise their “huge” Boxing Day sales and often promise big discounts…but how can you tell if you’re really getting a bargain?

If you’re after big ticket electronics items such as a TV, home theatre or audio equipment, cameras, or phones, the website pricespy.co.nz can be a huge help. It is worth pointing out here I have no affiliation with PriceSpy other than being a user of their website.

PriceSpy is an online price comparison site that  collects pricing information from a number of online retailers in New Zealand. You can search for a product or model number and see current and historical pricing from a number of online retailers who stock the product.

By looking at this current and historical data you can not only see what other retailers are selling a product for, you can also see historical pricing of products to see what they’ve sold for and whether the advertised sale price is in fact a good deal.

Lets look at an example of a current high end TV. If you can’t quite afford an OLED TV, the Sony X9000F is my pick of high end LED panels. It’s a brilliant TV and recently has seen some fairly sharp pricing on the 65” model.

x9000f price comparison

The above screenshot shows pricing data from the above retailers along with pricing history of the TV. It shows the TV has dropped as low as $2,498 in late November.

By clicking on a retailer you can see their pricing history. As you can see retailer Heathcote Appliances sold the TV in late November for $2,499 but it currently retails there for $3,298

heathcotes x9000f pricing

This pricing history shows the tactics of retailers such as Noel Leeming who have a habit of inflating prices before big sales so that their discounts look better. It’s very likely Noel Leeming will come out on Boxing Day (as they always do) and offer a “big brands” sale which often sees somewhere in the vicinity of 25% off many big brands including Sony.

As you can see above, Noel Leeming currently sell the 65X9000F TV for $3,899 making them around $600 - $700 more expensive than direct competitors such as JB HiFi, Magness Benrow, Heathcote Appliances, and even the Sony Store itself.

This also shows that Noel Leeming sold the TV for as low as $2,586 in late November.

noel leeming x9000f pricing

Noel Leeming’s pricing strategy is similar on other products. The brilliant Sony KD55A8F OLED TV has quite a range of prices at present, with once again Noel Leeming being one of the most expensive. It also shows they had the cheapest historical price for this TV selling it for $2,998 in November.

image 

A sale cannot be genuine and can fall foul of the Fair Trading Act if a product has not sold at the “was” price for a reasonable period of time beforehand – with that reasonable period of time considered to be around a month in the eyes of the Commerce Commission.

By hiking prices a little under a month out from Boxing Day it means Noel Leeming do not fall foul of the law, but it does mean that many of their “sale” prices can in fact  be pretty ordinary. You can tell from the above screenshot that Noel Leeming did exactly the same thing in early November leading up to their Black Friday in late November.

They may claim big percentage and or dollar discounts, but the truth is you’re not really saving the amount they claim. If Noel Leeming were to offer a 25% discount off a Sony 65X9000F or KD55A8F TV it only brings the prices of both down to pricing similar to pricing already seen last month for these products.

Other retailers employ questionable processes as well. Harvey Norman will often remove products from their website so they’re not shown on Pricespy.

By doing this it also means customers can’t use their website to attempt to price match their prices at retailers such as Noel Leeming and JB HiFi who will actively match competitors prices. These retailers will normally only accept a website price or written quote as proof of competitor pricing.

If you’re on the lookout for a big ticket item this boxing day make sure you do your research. Just because something is advertised as a sale item does not necessarily mean it’s a bargain!



Lime Scooters launch in the Hutt Valley

By Steve Biddle, in , posted: 14-Dec-2018 07:25

Lime scooters have launched in the Hutt Valley overnight. Reports came in of scooters on streets late last night, and the app slowly updated as the scooters came online.

Image result for lime scooter

Geofencing on the map indicates they are only available in the Hutt Valley, and not in Wellington or Porirua. Lime had demonstrated the scooters on the Wellington waterfront last month, however Wellington City Council had indicated they were keen to await the outcome of the trial of bike service Onzo before giving Lime scooters the tick of approval.


image


There appear to be somewhere in the vicinity of 100 scooters scattered throughout the Hutt Valley from Petone to Upper Hutt. There is good availability around Petone.

image


To use a Lime scooter simply download the Lime app, register your account and load a credit card against it. Lime scooters cost $1 per ride + 30c per minute.

Locate a scooter on the map, and scan the QR barcode on the scooter with your phone camera to unlock the scooter. To end your ride simply press the end ride button on the app.

If anybody is keen on a $3 promo code to try a Lime scooter you can use promo code RG7WCAE – we’ll both get $3 free credit.



Polycom IP Phone New Zealand time and tone settings

By Steve Biddle, in , posted: 9-Sep-2018 20:57

I’ve been a fan of Polycom IP phones for many years, but haven’t used these for deployments for many years in part due to the price of the hardware in New Zealand compared to other brands of phones.

Recently I decided to pull out my IP335 to make some configuration changes and picked up a new VVX410 to play with. I then struggled to find my configuration files detailing the settings for New Zealand times with daylight saving, and for the tone set to match a regular NZ phone and be PTC compliant.

Google wasn’t any help, so I started again! And by publishing it at least I’ll find it when I try Google again in the future. :)

In your Polycom sip.cfg (or similar) file you’ll want to have the following -

NZ time settings (adjust nz.pool.ntp.org to your own time server if required). This is based on NZ being GMT+12 and DST occurring from 2am on the last Sunday in September until 3am on the 1st Sunday in April.

<TCP_IP>
   <SNTP
     tcpIpApp.sntp.resyncPeriod="86400"
     tcpIpApp.sntp.address="nz.pool.ntp.org"
     tcpIpApp.sntp.address.overrideDHCP="0"
     tcpIpApp.sntp.gmtOffset="43200"
     tcpIpApp.sntp.gmtOffset.overrideDHCP="0"
     tcpIpApp.sntp.daylightSavings.enable="1"
     tcpIpApp.sntp.daylightSavings.fixedDayEnable="0"
     tcpIpApp.sntp.daylightSavings.start.month="9"
     tcpIpApp.sntp.daylightSavings.start.dayOfWeek.lastInMonth="1
     tcpIpApp.sntp.daylightSavings.start.time="2"
     tcpIpApp.sntp.daylightSavings.start.dayOfWeek="1"
     tcpIpApp.sntp.daylightSavings.stop.month="4"
     tcpIpApp.sntp.daylightSavings.stop.date="1"
     tcpIpApp.sntp.daylightSavings.stop.time="3"
     tcpIpApp.sntp.daylightSavings.stop.dayOfWeek="1"
</TCP_IP>

 

And for a NZ ring back tone, busy tone, dial tone and message waiting tone. These use levels of –12 which I feel is right, but others may want to adjust this up or down if they feel it’s too quiet or too loud.

<se
   >
      <se.pat
     >
      <se.pat.callProg
       >
        <se.pat.callProg.busyTone
         >
          <se.pat.callProg.busyTone.inst
           se.pat.callProg.busyTone.inst.1.type="chord"
           se.pat.callProg.busyTone.inst.1.value="busyTone"
           >
          </se.pat.callProg.busyTone.inst>
        </se.pat.callProg.busyTone>
        <se.pat.callProg.ringback.name="ringback">
    <se.pat.callProg.ringback.inst
     se.pat.callProg.ringback.inst.1.type="chord"
     se.pat.callProg.ringback.inst.1.value="ringback"
     se.pat.callProg.ringback.inst.2.type="silence"
     se.pat.callProg.ringback.inst.2.value="2100"
     se.pat.callProg.ringback.inst.3.type="branch"
     se.pat.callProg.ringback.inst.3.value="-2"
    </se.pat.callProg.ringback.inst>
    </se.pat.callProg.ringback>
        <se.pat.callProg.stutter
         >
          <se.pat.callProg.stutter.inst
           se.pat.callProg.stutter.inst.1.type="chord"
           se.pat.callProg.stutter.inst.1.value="stutterLong"
           se.pat.callProg.stutter.inst.2.type="chord"
           se.pat.callProg.stutter.inst.2.value="dialTone"
           >
          </se.pat.callProg.stutter.inst>
        </se.pat.callProg.stutter>
        <se.pat.callProg.dialTone
         >
          <se.pat.callProg.dialTone.inst
           se.pat.callProg.dialTone.inst.1.type="chord"
           se.pat.callProg.dialTone.inst.1.value="dialTone"
           >
          </se.pat.callProg.dialTone.inst>
        </se.pat.callProg.dialTone>
        <se.pat.callProg.reorder
         >
          <se.pat.callProg.reorder.inst
           se.pat.callProg.reorder.inst.1.type="chord"
           se.pat.callProg.reorder.inst.1.value="reorder"
           se.pat.callProg.reorder.inst.2.type="silence"
           se.pat.callProg.reorder.inst.2.value="300"
           se.pat.callProg.reorder.inst.3.type="branch"
           se.pat.callProg.reorder.inst.3.value="-2"
           >
          </se.pat.callProg.reorder.inst>
        </se.pat.callProg.reorder>
      </se.pat.callProg>
    </se.pat>
  </se>

<tone
   >
    <tone.chord
     >
      <tone.chord.callProg
       >
        <tone.chord.callProg.dialTone
         >
          <tone.chord.callProg.dialTone.freq
           tone.chord.callProg.dialTone.freq.1="400"
           tone.chord.callProg.dialTone.freq.2="400"
           >
          </tone.chord.callProg.dialTone.freq>
          <tone.chord.callProg.dialTone.level
           tone.chord.callProg.dialTone.level.1="-12"
           tone.chord.callProg.dialTone.level.2="-12"
           >
          </tone.chord.callProg.dialTone.level>
        </tone.chord.callProg.dialTone>
        <tone.chord.callProg.busyTone
         tone.chord.callProg.busyTone.offDur="500"
         tone.chord.callProg.busyTone.onDur="500"
         >
          <tone.chord.callProg.busyTone.freq
           tone.chord.callProg.busyTone.freq.1="400"
           tone.chord.callProg.busyTone.freq.2="400"
           >
          </tone.chord.callProg.busyTone.freq>
          <tone.chord.callProg.busyTone.level
           tone.chord.callProg.busyTone.level.1="-12"
           tone.chord.callProg.busyTone.level.2="-12"
           >
          </tone.chord.callProg.busyTone.level>
        </tone.chord.callProg.busyTone>
        <tone.chord.callProg.ringback
     tone.chord.callProg.ringback.offDur="200"
     tone.chord.callProg.ringback.onDur="400"
     tone.chord.callProg.ringback.repeat="2">
    <tone.chord.callProg.ringback.freq
     tone.chord.callProg.ringback.freq.1="400"
     tone.chord.callProg.ringback.freq.2="450">
    </tone.chord.callProg.ringback.freq>
    <tone.chord.callProg.ringback.level
     tone.chord.callProg.ringback.level.1="-12"
     tone.chord.callProg.ringback.level.2="-12">
    </tone.chord.callProg.ringback.level>
    </tone.chord.callProg.ringback>
        <tone.chord.callProg.stutterLong
         tone.chord.callProg.stutterLong.offDur="100"
         tone.chord.callProg.stutterLong.onDur="100"
         tone.chord.callProg.stutterLong.repeat="12"
         >
          <tone.chord.callProg.stutterLong.freq
           tone.chord.callProg.stutterLong.freq.1="400"
           tone.chord.callProg.stutterLong.freq.2="400"
           >
          </tone.chord.callProg.stutterLong.freq>
          <tone.chord.callProg.stutterLong.level
           tone.chord.callProg.stutterLong.level.1="-12"
           tone.chord.callProg.stutterLong.level.2="-12"
           >
          </tone.chord.callProg.stutterLong.level>
        </tone.chord.callProg.stutterLong>
        <tone.chord.callProg.reorder
         tone.chord.callProg.reorder.offDur="100"
         tone.chord.callProg.reorder.onDur="75"
         tone.chord.callProg.reorder.repeat="4"
         >
          <tone.chord.callProg.reorder.freq
           tone.chord.callProg.reorder.freq.1="400"
           tone.chord.callProg.reorder.freq.2="400"
           >
          </tone.chord.callProg.reorder.freq>
          <tone.chord.callProg.reorder.level
           tone.chord.callProg.reorder.level.1="-12"
           tone.chord.callProg.reorder.level.2="-12"
           >
          </tone.chord.callProg.reorder.level>
        </tone.chord.callProg.reorder>
      </tone.chord.callProg>
    </tone.chord>
  </tone>



Is the TCF mobile blacklist fuelling New Zealand’s latest crime fad?

By Steve Biddle, in , posted: 8-May-2018 12:26

Stolen or lost mobile phones are a global problem. With the introduction of GSM phones in the ‘90s, the ability to simply move a SIM card between phones started a crime wave because phones were such an easy target. Once somebody had a stolen phone they could simply use it themselves, or on sell it, and the buyer could simply put their SIM card in the phone and use it – in many cases probably oblivious to the history of the phone.

The solution was blacklists of International Mobile Equipment Identity (IMEI) numbers – the serial number of the phone. Operators could block IMEI numbers to prevent devices working on their network, and share the IMEI data between themselves to stop the device working on other networks.

While such blacklists are common place around the world, no global blacklist exists, meaning that devices that are reported lost or stolen in one country can still be used in another country. This has created a global black market for phones, and I’ve seen retailers in Hong Kong selling refurbished “as new” phones that will not work with Hong Kong SIM cards, but will work outside the country.

In 2014 the Telecommunications Carriers Forum (TCF) introduced a mobile blacklist with data shared between New Zealand’s mobile networks – 2degrees, Vodafone, and Spark. Phones that were reported lost or stolen could have their IMEI added to this blacklist which would result in the phone becoming inoperable on any of the networks in New Zealand.

Prior to the introduction of the TCF backed blacklist system, blacklist data was shared between Spark (who were still Telecom at the time) and Vodafone, but not 2degrees.

This fuelled a market in New Zealand for devices that were sold on Trademe and advertised as “only works on 2degrees”, and a number of threads exist here on Geekzone detailing experiences of people people purchasing such devices. Sellers of these devices were clearly aware these devices were blacklisted on the Spark and Vodafone networks, but buyers who didn’t understand the reasons for such a statement were left perplexed when they tried to use their device on Spark or Vodafone and found it didn't work – while it did work fine on 2degrees.

Even when they were sharing IMEI data only with Vodafone, it was well known that Spark were adding IMEI numbers to the blacklist that were not only for stolen or lost devices, but from customers who had abandoned a term contract with a subsidised handset or hire purchase deal. Around this time there was even an online retailer selling new devices that were also clearly marked as “only works on 2degrees” where the source of the handsets was apparently a cancelled corporate contract.

In 2014 when the TCF blacklist was introduced, the TCF made the purpose of the blacklist service pretty clear in its voluntary code -

What it is

The IMEI Blacklisting Code allows consumers to report lost or stolen handsets to their mobile provider so it is blocked and cannot be used on any mobile network, nationwide. Purpose

The purpose of the code is to co-ordinate sharing of IMEIs between mobile networks to discourage theft and disrupt the operation of illegal markets.

Section 5.3 of the code also details what the blacklist should (and should not) be used for -

5.3 Operators shall not Blacklist or un-Blacklist an IMEI in order to gain any commercial advantage or inflict any damage on any other Operator or party.  Blacklisting cannot be used to withhold service or resolve commercial disputes (including bad debt scenarios).  Operators cannot use any contact made by a former customer requesting to Un-Blacklist an IMEI for any “win back” or sales activity.

Over the last few years I’ve seen a number of threads on Geekzone as well as a number of posts on social media from people who have purchased mobile phones both via Trademe and privately, and found that several months later the phone has suddenly stopped working. In all cases the phone has been found to have been blacklisted.

In several cases the buyer had checked the phone using the TCF blacklist  lookup when they purchased it, and saw the device was not blocked. One example of this is detailed below.

tcf imei pg1

So what’s going on?

It would seem that Spark, and possibly 2degrees, are still using the TCF blacklist for purposes outside the scope of the blacklist, ie a bad debt scenario.

A customer purchases a device on a contract or an interest free free deal, sells it to an unwilling buyer who even checks the TCF blacklist and find it passes, pays the contract for a several months, and then suddenly cancels it or decides not to pay it. The device IMEI is added to the TCF blacklist, and the third party buyer of the device suddenly finds their device doesn’t work.

They then often find themselves in a situation where there is very little they can do. The original seller is often nowhere to be found, and the buyer is stuck with an expensive brick that is now useless.

In this example I’m using from Geekzone, the seller did eventually offer a refund. In other cases people have not been so lucky.

tcf imei pg2

The TCF have pushed their blacklist search as a way for a buyer to check their handset and ensure that it’s not blocked – which is fine for checking if a phone has been blocked due to being reported stolen or lost, but it’s very clear now that this search is now pretty limited when it comes to checking the real status of any phone purchased privately. A phone that passes an IMEI check could still be blocked at any time if if the seller of the default defaults on payments.

The TCF themselves do vaguely warn of this on their website but most people would probably not realise under what circumstances this would occur. Most people would assume a second hand phone that passes the check would be safe to buy  - after all that was the whole point of the online tool to allow people to check a device.

tcf imei pg3

All of this poses the question of why the TCF are permitting carriers to use their blacklist for a “bad debt” scenario, something that would seem to be in breach of their code surrounding the use of the blacklist.

When high value products are sold by retailers on finance deals, most use the Government funded Personal Properties Security Register (PPSR) to lodge the sale – with the purpose of the database being to provide a central register of products that may have a financial claim against them. It poses the question of why mobile providers don’t appear to be using this database for high value phones, but instead relying on a blacklist.

It also poses the question of whether carrier has a legal right to effectively block a device that they have not bothered lodged a PPSR security interest over.

Right now buying a second hand phone carries significant risk unless you know exactly where the device came from, and can be certain that no money is owed on the phone. My attempt to check an IMEI with Spark showed they are unwilling to provide this information when asked, as any information relating to the phone or IMEI seems to be regarded as personal information. With no authority to access the account of the person who originally purchased the phone, it’s impossible to get a clear answer from them.

Right now the TCF searchable blacklist is essentially broken – and urgently needs to be fixed. If carriers aren’t going to stop blacklisting devices for bad debts, the TCF urgently need to expand the search to include whether money is owed on a phone.

People are being scammed, and the TCF online search is being used to benefit the scammer and hurt the unwitting buyer. That is simply wrong.

 

UPDATE:

I have received the following response from Spark regarding the issue.

Spark do not blacklist IMEI numbers if a customer has bad debt, or defaults on a payment. The exclusive purpose of blacklisting handsets is when devices are either stolen, lost or involved in fraud.

There are a number of steps Spark take to determine fraud or fraudulent activity before we blacklist a device. Where it is deemed that fraud or fraudulent activity has occurred the case must satisfy the burden of proof and the following must apply:

  • There must be documentary and/or other evidence which prima facie supports the allegation of fraud; and,
  • There must be sufficient evidence to lay a Police complaint.

However, fraudulent activity can take some time to identify – which is why telecommunication companies have up to 120 days under the blacklist policy.

We understand it is very frustrating for individuals who find their phone has been blacklisted months after they have purchased it, but this is unfortunately a risk when purchasing from a second-hand site such as Trade or Facebook Marketplace.

While Spark say that a device will not be blocked due to a bad debt, it’s a grey area between defining a “bad debt” and “fraud”. Somebody buying a device with falsified details and defaulting on a payment would likely be treated as a case of fraud, and the device blocked.

The response from Spark really emphasises the failings of the TCF system. A individual buying a second hand device can have no certainly at all that the device will not be blocked at some point in the future after they have completed the sale, and more importantly after they’ve checked the TCF mindyourmobile site and verified that the device they are wanting to buy is not listed as blocked on the site.

People know they can easily on sell devices to unsuspecting people who will check the blacklist, but have no idea the phone effectively has a security interest registered against it, and more importantly no way of actually knowing this or being able to check this. That's a broken system, and it needs to be fixed.

If a device is purchased on account or as part of an interest free deal and effectively has a security interest registered against it this should be lodged with the PPSR, and the TCF website should be doing a lookup against that to not only show the current status of the IMEI, but also whether security is lodged against it. This would allow any potential buyer to be fully aware of the risks associated with buying the device.

Anybody looking to purchase a second hand phone needs to be fully aware of the risks. You could easily end up with an expensive brick despite through no fault of your own, and then find there is very little you can do when you’re in this situation.



Yet another Mikrotik RouterOS exploit is in the wild

By Steve Biddle, in , posted: 24-Apr-2018 06:56

Users of hardware running Mikrotik RouterOS are urged to ensure their devices are secured after news of yet another security vulnerability affecting the platform.

The vulnerability allows a hacker to access the device remotely using Winbox port 8291 and then download the user database file from the router, extract valid usernames and passwords, and then access the device. It affects RouterOS versions 6.29 to 6.43rc3.

This vulnerability follows closely behind two others in the past month that have affected web access to the devices, and the SMB functionality.

All users of RouterOS should immediately ensure their hardware is upgraded to v6.42.1 (current) or  v6.43rc4 (release candidate). It’s important to note the 6.40.x bug fix only release channel does not currently have a fix available. If you are running 6.40.x restricting access via firewall rules to safe IP range(s) is essential to protect your device.

Best security practice is to also to not have a device exposed to the entire Internet on port 80 or 8291 for remote access. If these services are restricted to safe IP range(s) the risks of a device being compromised are reduced.

More information is available on the Mikrotik forums https://forum.mikrotik.com/viewtopic.php?f=21&t=133533



Android’s broken software update model

By Steve Biddle, in , posted: 28-Nov-2017 07:52

Keeping your mobile phone software up to date is more important than ever in light of recent security concerns. Whether you’re a Google Android or Apple iOS fan, one thing everybody has to accept is that Apple’s software update model works a lot better in practice than Google’s.

When Apple release an iOS update it’s immediately available to all users of every device supported by the update. The “supported” life has exceeded 4 years for numerous Apple iPhone and iPad devices.

In the Android world things are a lot more complex. Assuming a manufacturer does decide to make Android updates available (plenty of Android manufacturers don’t make any updates available), the process to get those updates to end users is often long and complex. For many phones there is a requirement for the manufacturer to send software updates to the mobile networks for testing, and once they’ve tested the software it then becomes available from the manufacturers as a software update.

Apple’s model isn’t necessarily perfect – bugs in iOS have caused grief for both networks and end users in the past.

Changes to signalling caused headaches for mobile networks as they become flooded with signalling traffic after an iOS update, and on multiple occasions Apple have introduced WiFi changes that have meant nothing but grief for end users. In such situations it’s not just the odd user or mobile network that’s affected – it’s every user and mobile network.

HTC released this infographic detailing the Android update model a while ago http://www.htc.com/us/go/htc-software-updates-process/

I saw a post on Geekzone recently asking about software updates for the Sony Xperia Z5. The poster asked whether users of the Spark New Zealand branded Xperia Z5 were ever likely to see the Android 7.1.1 update. As it has been available now for months for non Spark branded handsets, it’s not an unrealistic to expect that it should be available.

image

The Xperia Z5 is a handset I had previously owned, and after purchasing it in Hong Kong in 2016 I flashed it with the generic Australian firmware. In the year I owned this phone updates were pretty regular, with Android 7.1.1 appearing for it in early July, a week or so after Sony made it available. I was surprised to see that the update was not yet available for the Spark branded Z5.

I upgraded to a Hong Kong sourced Xperia XZ in July, and get regular updates for this including monthly Android security updates that often appear within weeks of being released by Google. I’ve long regarded Sony as being great with updates for all of the Xperia phones I’ve had, and Sony have typically made updates available for 2 years from the release of the phone.

A few days later there was an update after the user contacting Sony -

image

I reached out to Spark to ask them about the situation and got this response -

"The latest build we have tested for the Z5 is 7.0 – which we approved on 28/02/2017. We don’t have a new build from Sony on the radar at this stage, we've asked them to see if we will get it or not. "

A 3rd party tool called Xperifirm allows Xperia users to download official firmware files from Sony’s servers and install it on their phones. Simply by running Xperifirm you can easily see the latest software release available for any Xperia handset.

image

image 

As you can see from the list Android 7.1.1 (32.4.A.1.54) is available from a number of carriers. Android 7.0 builds (32.4.A.0.160 and 32.3.A.2.33) are available from the rest. Your phone is tied to the latest release available for your CDA code, so even if a newer update may be available for your device, the CDA code defines the software available to you.

The good news is that reflashing a Xperia handset with a different firmware version (which will change the CDA code) isn’t difficult but does carry some risk. If you don’t fully understand what you’re doing you do run the risk of turning your phone into an expensive brick.

The downside of flashing different firmware onto your device is that it means your phone may not be fully compatible with the network you’re using it on. Despite 3G and 4G being standards, many networks have customised settings for features such as Carrier Aggregation (CA) that may mean your phone won’t be able to take advantage of the CA features offered by your network. In some circumstances it can also result in delays connecting to networks while roaming, or reconnecting to your home network when you come back to New Zealand.

Security updates appear most months for Android. Some of these updates are minor. Some fix critical bugs. By not running the latest available software on your device you’re potentially being exposed to bugs that do exist in the wild and could theoretically result in data or personal information on your device being compromised.

In light of the recent KRACK WiFi exploit, the issue was raised by a number of people as to whether consumer law in New Zealand provided cover for end users. Any product sold in New Zealand must be “fit for purpose” under our Consumer Guarantees Act (CGA).

Manufacturer obligations under the CGA can exceed those that exist under a regular product warranty – even if a product is out of warranty and fails the manufacturer and/or retailer could still be liable if the product is not deemed “fit for purpose” and is within an accepted lifetime of the product.

Consumer guarantees for products

The CGA gives you rights if the products you buy or are supplied by a business are faulty and do not meet the guarantees below under the CGA.

All consumer products must:

  • be of acceptable quality (durable, safe, fit for purpose, free from defects, acceptable in look or finish)
  • be fit for any particular purpose you have told the supplier
  • match a description, sample or model shown to you
  • have good legal title, eg be able to be sold and not have any security interests registered against them
  • be a reasonable price if no price is set
  • arrive on time (within a reasonable time if not agreed) and in good condition
  • have spare parts and repair facilities available (manufacturer is responsible). This does not apply if you are told about limited availability before you buy.

There has been plenty of debate in the online world as to how phones should be treated under the CGA. Most discussion centres around what a reasonable expectation is for the lifespan of a phone. Cases in both Australia and New Zealand have seen warranties on phones move to 2 years as standard – with many people deeming 2 years to be considered a reasonable lifespan for a modern device. It’s a timeframe I agree with.

Google publically state their support policy for current Google branded Nexus and Pixel phones on their support page. They commit to updates for 2 years from the release of their phone, and security updates for 3 years from the release of the phone.

Many devices out there (particularly low end), will never receive updates, meaning the end user could potentially be exposed to data loss or encounter issues that may be fixed in newer releases. Could a lack of software updates for a phone mean that you could lodge a CGA claim over a handset because it’s no longer “fit for purpose”? That’s something there aren’t simple answers for, and something that probably needs to be tested in court.

In the case of the Xperia Z5 it’s hard to decide where fault lies. Software updates for the Z5 exist in many other markets but don’t exist for the Spark branded Z5. Spark are saying they haven’t received any new updates from Sony. Are Sony simply deciding that it’s not worth investing in development of updates for Spark customised firmware in a small market such as New Zealand where it’s unlikely that significant numbers of Z5 handsets were sold? We can really only speculate.

In light of the CGA should all manufacturers of handsets that are sold in New Zealand be required to commit to disclosing  publically their support timeframes for handsets? Google already do this. Should mobile networks be required to publically list all handsets they have sold and the current firmware levels and upgrade status? Maybe.

It shouldn’t be up to an end user to have to search the Internet to work out how to download and flash their handset with foreign software to update it to the latest release available, but right now for many people in New Zealand this is the only way to get the latest updates on their hardware. That’s wrong, and to me shows how broken the update model is.



No, AT aren’t stealing your money. How Stuff confused a nation.

By Steve Biddle, in , posted: 10-Sep-2017 18:25

New Zealand’s biggest news site today wrote a story basically accusing Auckland Transport (AT) of being thieves. I’d hate to be working at AT tomorrow having to be dealing with the fallout from this alt fact fake news.

image 

This story has resulted in mass confusion from AT HOP card holders and lead many people to believe they’re going to lose the credit on their AT HOP cards if they don’t use them every 60 days. Nothing can be further from the truth.

The woman in the story topped up her AT HOP card online. The key point here is that AT HOP card, like any other stored value public transport card has the balance stored on the card itself. There are two ways to load credit onto the AT HOP card – the first is to do this at a retailer or AT HOP kiosk, and the second is to do this online.

Until the balance is physically loaded onto the card it doesn’t actually exist.

When you top up a AT HOP card at a kiosk or retailer it’s a real time transaction and your card balance update is immediately applied.

When you top up your card online it’s a two part process. First off you “buy” the credit online using your credit card. Typically this payment data is downloaded to every AT HOP terminal across the network in every bus, train and ferry overnight. When you now tag on to a bus, train or ferry, or ask for a balance query at a AT HOP terminal that new balance will be applied to your AT HOP card.

The woman in this story purchased the credit online but ignored the very clear instructions provided during the online top up process. Her balance never “mysteriously dropped to zero” as it was always zero. As she didn’t use the new card within 60 days of the online transaction her balance was never applied to her card.

Many people who have read the story now mistakenly believe that they will lose their AT HOP card balance if they don’t use it every 60 days.

hop1

hop2

hop3 

hop4

hop6

hop7

hop8

The actual story here is the 60 day period that exists between purchasing credit online and using your AT HOP card on a bus, train or ferry, or asking for a balance at an AT HOP terminal. If you fail to use your card within 60 days of an online top up, your top up is removed from the system.

As explained above every night every AT HOP terminal is loaded with a file that contains online payment details and card numbers. Every time a person taps on to a bus, train or ferry this database needs to be queried to check if credit needs to be applied to the card.

A typical HOP transaction takes around 350ms to occur – in this time the card is read, the database queried to see if the card is valid or blocked, the top up database is checked to see if a top up balance needs to be applied to the card, and lastly the new balance is written back to the card. Every step of this process takes time, and time is critical. If transaction times were doubled to 700ms for example it would cause considerable delays to the tag on process and would create significant delays for people boarding their bus.

Best practice for any ticketing solution anywhere in the world is to have a period of time where online top up data is stored on terminals before it’s removed. If this data is stored indefinitely it would simply slow down card processing times to the point where the customer experience would be impacted.

Many people have accused AT of theft. This can’t be further from the truth. The credit is sitting there waiting for the AT card holder to tell them what to do with it, and it seems AT are only too happy to credit this back when people do make contact.

An analogy of this would be to compare it to ordering and paying for a product online from a click and collect retailer but never actually going to the store to pick it up. When you finally do the retailer has sent the product back to the warehouse because they don’t have room to store it. They’ve simply been waiting for you to contact them to tell them what you’d like to do.

Automatically refunding the balance back to the credit card that was used is not a good solution. Credit card numbers change and the card used may also not belong to the card holder.

AT’s best approach should be to make contact with the card holder if the top up isn’t applied within 60 days. I have no idea if this is process or not, but as a card has to be registered to be topped up online AT should have contact details for the card holder.

If you’re an AT HOP card holder you can be rest assured your balance will not expire if your card is not used every 60 days. As per AT HOP terms and conditions (section 9) any credit on an AT HOP card will expire if an AT HOP card is not used for a period of 6 years.

If you’re somebody who tops up online, ensure you use your card within 60 days by either taking a journey or checking the balance at an AT HOP kiosk or retailer so the balance can be applied.



Sangoma Roadshow heads to New Zealand in September

By Steve Biddle, in , posted: 4-Sep-2017 07:25

Anybody who’s ever spent time in the VoIP space will be well aware of Sangoma Technologies. The Canadian company become well known for it’s Vega gateways and telephony cards which were very popular favourite among Asterisk users from the very early days of Asterisk in the early 2000s.

In 2013 Sangoma acquired Schmooze Com, the maintainer of the FreePBX GUI and FreePBX distro. They have continued to grow the world’s most popular Asterisk distro as well as add new hardware and products to their product portfolio.  Sangoma now have a wide range of products including FreePBX, PBXAct, IP Phones, VoIP gateways and Session Border Controllers (SBCs).

As a frequent visitor to the Astricon Asterisk user conference in the US, I’ve met many of the great guys from Sangoma over the years. Now it’s their turn to come to New Zealand with a roadshow covering both New Zealand and Australia in September that will show off their product range.

The show in Wellington is on Tuesday 26th September and is free to attend. Registration is essential.

image

For more details see the official roadshow page - https://www.sangoma.com/events/event/sangoma-roadshow-australia-new-zealand-tour-september-2017/



The perils of using Airbnb during big events

By Steve Biddle, in , posted: 3-Sep-2017 15:56

Those of you who know me will know I’m a pretty prolific traveler. As is the case when you fly somewhere you normally need somewhere to stay, and over the past few years I’ve spent somewhere in the vicinity of 60 – 80 nights per year in hotels both for work and leisure.

Despite my need for accommodation, I’ve never been a big user of Airbnb. On a recent trip to to Europe I spent a week staying in Airbnb properties with friends, and on a trip to Europe several years ago also spent a week staying in a number of properties with friends. Apart from minor issues such as broken air conditioning that would be easily fixed in a hotel (they move you to another room) I’ve never had any major issues with Airbnb and have stayed in some fantastic properties.

So why don’t I book Airbnb more often? Much of it comes down to the fact that staying in a hotel is just so much easier. I can get to a location, head straight to the hotel, check in, and head to my room. With Airbnb the process normally involves meeting with people to arrange keys and/or access which simply isn’t as quick or simple. Like being an Apple or an Android user I appreciate both options – and in my case I simply prefer hotels for much of my travel. When traveling with friends however, a large house or apartment that can sleep 3 or 4 people is much preferable to booking multiple hotel rooms.

Those of you in the tech world will know all about CES. It’s the biggest tech show in the world and sees Las Vegas turned into a city of chaos for 5 days as 170,000+ people from around the world all converge on it. It’s somewhere I’ve been before, and somewhere I’m heading to again in January along with several other Geekzone users.

As you can imagine with so many people visiting Las Vegas, accommodation becomes very important. While hotels in Las Vegas can be dirt cheap for much of the year, CES is an opportunity to make money. Rooms that are normally US$25 a night can go for US$250. Rooms that are US$250 night can easily go for US$1000. Look at an accommodation site such as Expedia right now and you’ll struggle to find a hotel room in Las Vegas for a week for under NZ$2000 during CES. Want something more upmarket? A stay at the Venetian or Palazzo will easily set you back NZ$7000 for a week long stay! At other times of the year you’d pay roughly 1/4 of this price.

In May when I booked flights to Las Vegas I immediately started looking for accommodation. The traffic carnage that ensues during CES means that buses, taxis and Uber simply end up being the traffic congestion. Roads are clogged, and getting around takes a very long time during both the morning and evening rush hours. Despite Las Vegas being a big city, walking is the best way to go. Finding somewhere to stay within 20 mins walk of the Las Vegas Convention Centre and The Strip really is the perfect place to be.

I looked at both hotel and Airbnb options before settling on an Airbnb property that cost me NZ$1150 for the week. The apartment looked great, and the location was also great. Everything was great.. Until several days ago when I received an email from Airbnb saying my booking had been cancelled.

Immediately I asked Airbnb what they could do for me and have been in contact with their team both via email and phone. Their customer service has been great, but right now I still don’t have anywhere to stay. Several other suggested properties are literally miles away. Others that are closer are still not as good or as well located as what I had previously.

Due to the fact many hotels have sold their cheap rooms and most good Airbnb properties are now booked, finding something else to book is proving difficult. There is nothing in the price range that I paid that’s in a location I want. Airbnb are willing to offer me a US$100 credit for the inconvenience, but when properties that are suitable are up to twice the price I paid that’s hardly a great deal. Staying in a cheap hotel may be the best option, but that’s going to cost me another NZ$500ish or so for the week.

All of this shows the problem with the Airbnb model. Short of a major disaster, a hotel selling rooms isn’t going to suddenly disappear – once you pay your money your booking is confirmed and you’ll have a room.

Paying for a property with a strict refund policy on Airbnb meant I was locked in to that property and was not eligible for a refund if I cancelled. Nothing however prevents the Airbnb host from cancelling under an extenuating circumstances policy. This property has now been removed from Airbnb so there is nothing to suggest the host is doing anything dodgy such as cancelling so he can relist it for a higher price, but a recent change to the listing suggests it was being turned into a long term stay rather than short term.

Under many circumstances such a cancellation may not be a major deal – the problem is in somewhere like Las Vegas during CES it’s now me who’s dealing the the extenuating circumstances of a cancelled booking and the fact rebooking somewhere to stay will cost me significantly more money.

I don’t necessarily think expecting Airbnb to front up and offer me another NZ$1000 in credit to book a property in a similar location to where I had booked is fair – but I also don’t think me having to pay a single cent more than I had already paid for a booking is fair either. Ultimately they’re the ones who have inconvenienced me, so why should I have to settle for a property or location that means my holiday experience is ruined?

While this won’t put me off ever using Airbnb again, it’ll certainly put me off booking Airbnb ever during a peak travel period or for an event where accommodation is busy. The risks of having your host cancel and being left to find accommodation that will cost significantly more simply isn’t worth the risk.



sbiddle's profile

Steve Biddle
Wellington
New Zealand


I'm an engineer who loves building solutions to solve problems. I'll also a co-founder of the TravelTalk.nz travel site. 


I also love sharing my views and analysis of the tech world on this blog, along with the odd story about aviation and the travel industry.

My interests and skillset include:

*VoIP (Voice over IP). I work with various brands of hardware and PBX's on a daily basis
  -Asterisk (incl PiaF, FreePBX, Elastix)
  -Polycom
  -Cisco
  -Linksys
  -Patton
  -Zyxel
  -Snom
  -Sangoma
  -Audiocodes

*Telecommunications/Broadband
  -xDSL deployments
  -WiMAX
  -GSM/WCDMA
  -WiFi

*Structured cabling
  -Home/office cabling
  -Phone & Data

*Computer networking
  -Mikrotik hardware
  -WAN/LAN solutions

*Wireless solutions
  -Motel/Hotel hotspot deployments
  -Outdoor wireless deployments, both small and large scale
  -Temporary wireless deployments
   
*CCTV solutions
  -Analogue and IP

I'm an #avgeek who loves to travel the world (preferably in seat 1A) and stay in nice hotels.


+My views do no represent my employer. I'm sure they'll be happy to give their own if you ask them.


You can contact me here or by email at stevenbiddle@gmail.com

twitter.com/stevebiddle