Monthly Archives: December 2018

Australian AABill

If you look at my blog; I do believe this is the first article I've ever written about something political.  I tend to be anti-political because I feel like it just divides us and tends to be just complaining with no one actually doing anything meaningful about it.

However two days ago I noticed in the news that the AABill was about to be passed.  I had read about it before, but since I'm not Australian (and I don't work in Australia) it really doesn't affect me "personally" right this minute.   However, the reality hit me later, that it does affect my friends; and it has a very high chance of affecting all of us in the future.  What the Australian government gets away with now; the rest of the "civilized" countries will also attempt to implement someday.    

Our own (USA) FBI has been hankering for this power for years; and so far they have been thwarted; the Canadians have thwarted similar issues in their country.   Europe; has caved to a lot.   So much of what Australia did; they took from Europe.  They just went a lot farther.  The more nations that cave; the easier it is for the other nations to do the same thing and go farther.   

This bill is BAD!    So bad, if it was meat it would have to be launched into the sun to actually eliminate the deadly bacteria.   If it was a meteor we would all be wiped out instantly.   

In a nutshell the bill gives the Australian government the right to require people and/or companies to implement back doors into any systems (web, phones, your apps, banks, encryption, etc).   

  • No real  over sight   "Trust us; we won't abuse it..."   (I bet they  have a bridge to sell us too.)
  • Massive mandatory punishments for speaking about the request; to anybody -- even if it is to defend your reputation or job when the back door is found..
  • Severe Anti-whistle-blower rules to eliminate anyone attempting to do the right thing, when the government is doing the wrong thing.   Trust us we won't abuse it...
  • The improbability that the person served with the "backdoor" order can actually bypass the security of any company that is multinational is... well, rather ludicrous.  More than like instead it will cause their own termination and potential black balling of the poor developer in the industry since he can't defend himself nor mention why he tried to subvert the software.
  • Trying to backdoor anything, is a criminal paradise.    We all know that no bad guys ever fine issues in any thing, never happens...
  • Backdoored encryption, what a joke.   
  • What Australian developer (or company) can I now trust with my code, data or hosting?
  • Beware of that bridge for sale...

I can go on an on about the terrible things in this bill...   Suffice to say; this is a very bad bill and that it has world wide implications.

I posted on twitter that I thought that maybe the internet community should route all the Australian government IP's to a banned page saying that until the bill is repealed they are being segregated to limit any more damage they can generate.

Several people posted they thought that was a good idea.   And it dawned on me, all I was doing was still just complaining and offering ideas that nobody would probably do.   In all reality I wasn't really doing anything at all.

So I got off my butt; and actually did something.   I purchased the domain name internetprotests.com; I then proceeded to setup a simple site.  Figured out several blocks of Australian government IP's to be routed to the banned page.    Figured out how to make the routing work in both Apache 2.4 and Nginx, and published the site.

I have attempted to start something here; and I cannot do it alone.   

If you are a internet provider or you have control over a website.  I urge you to check out the internetprotests.com site and become involved.  The more sites that blackhole all the Australian Government IP's; the more likely they will be forced to actually repeal the law if they want to be able participate on the internet.   

 If you don't own any websites; please pass this blog and/or the site around.  If you do copy editing, graphics works or technical work; the site is open source and could use more work prettying it up and making it more appealing to the masses and the press.   It was built quickly to try and spread the word because the tech world is starting to understand just how bad this law is.

If we can get the law repealed in Australia; then that will make all the other nations have second thoughts about trying it in their nation.   Maybe we the people of the internet can actually get our government to listen to us and follow our lead...

Security with Apps on iOS and Android.

Recently a person on twitter asked about a statement that Max made in a blog article which he did on the official ionic blog.  For those who know me; I actually am pretty heavily into security; and I happen to have used many mobile technologies  Cordova/Phonegap/ionic, Flutter, Titanium, React Native, Java, NativeScript, ObjC, Swift, etc -- so this article is right up my alley.   So lets start with the quote that started the tweet...

Some toolkits, like NativeScript, take the approach of exposing every Native SDK API to JavaScript. We think the security implications of that are undesirable, and it doesn’t remove your need to learn platform-specific APIs. We don’t think you should have to learn those APIs if you don’t want to, and we don’t think you should expose all Native APIs to JavaScript for security reasons.

(Quoted from Max's blog post linked above)

Initially I saw this tweet and was well saddened that Max feels he had to bad mouth his competitors to make his product potentially look good.   Unfortunately the statement Max made is 100% pure marketing FUD (Fear, Uncertainty, & Doubt).  He is just try and make a competing framework look bad with the hot button topic called security.    All it does in my opinion is make him, and his product look bad, and it is on the official ionic blog.   Compete on what you do great; not on trying to make the competition look bad (especially with FUD).

The real truth of this matter is that no matter the framework the same security surface exists.  Unfortunately for Max, this includes ionic!

So lets say I'm a evil person and I want to take over the world with my evil ionic app.   What do I do?

[I]...wrap a Native SDK and expose it as a reusable component that can be easily consumed in JavaScript ... Native Views provide a structure for wrapping and consuming a Native SDK so that it can be easily and safely exposed to JS...

(Quoted: from the same blog post linked above)

Oops; I guess I safely exposed some very bad methods  and succeeded in doing the exact same thing in ionic.  The only thing is I had to add the exact same code in a different place and expose it so it is easily consumed  using my exposed call "doBadThing()" in the JavaScript side of ionic when I need it to do my evil bidding.      Does that mean ionic shouldn't be trusted since I can easily and safely do very bad things in ionic?   See the problem, for me to do GOOD things in ionic; that gives me the same power to do BAD things in it.  

The reality is this means that just like I can do bad things in 100%  pure Java app, Kotlin, C/C++, NativeScript, React Native, ObjC, and Swift (name the framework); I can do it just as easily in Ionic.  None of them are immune!     This doesn't mean any specific platform is worse or better; they all have the ability in one way or another to access the exact same api's which can be used for evil purposes.   The bad code in all of them is literally the same; just the location in the app calling it is different.   

Now not to get into a more technical discussing; there are some areas where the frameworks do have some differences that may allow certain things to be easier to miss.  For example; using proguard can hide method calls in native Java code.  However overall this does not change the relative security of each of the frameworks.   You name the framework; and I know a way to make it hard for you to detect my evil code..   They all have pretty close to the same level of security surface.  

Now that I've explained the FUD and debunked Max's unfortunate dig at his competitor; I would like to explain where I see the real security issues with Android and iOS.

The real security vulnerabilities is our trust model.   We are now seeing it play out more and more where a developer creates a decent app.  It gets a decent reputation and then it gets sold to another developer.   The "other" developer is sadly not your friend.  Unfortunately; they add "bad" code; upload it as a minor fix to the app; and bam your Android or iPhone now is doing stuff you would rather it not be.   This has happened on ALL platforms, ALL types of code bases and so far none are immune.   Eventually they are caught (at least we hope) and the app is removed from the stores and you see a article about how 20 apps by XYZ dev had malicious code in them...

But the root problem is trust was built; and then outside of our control and knowledge; the app transferred to a different vendor who hasn't proved himself.  This is a hard issue to solve.     Do we say when you sell your app; it no longer can be auto-updated and has to be manually updated the next time so a notice will appear?    Or can we make the stores possibly notify us on the next upgrade with a re-install dialog announcing that the app has changed hands?    What has the best chance to be detected by the community and looked into?

I think that either of those ideas would be a good first step; but it won't solve this issue.  Bad actor then waits several months and then posts his "bad" changes.   Likely hood of being caught went drastically down, as we all get busy and our trust level goes up...  But at least the community is aware of the change of ownership and so some of them might still be diligent...

My next suggestion, is something unfortunately neither Google nor Apple will ever implement because our personal information is their bread and butter...   

I believe the real solution is that our devices should have two additional features: 
1. Built in firewall added to the OS.  The firewall is allowed to block all traffic for a specific application.   Easily enabled and disabled per application.   
2. Lying Data Module - This is a little harder to explain and a bit more advanced but basically you can tell the OS to lie to the app.  The app asks for your location and you have pre-configured the OS to always say you are at the north pole.   The app asks for the temperature; and again you pre-configured the OS that the temperature is 200 degrees.   It asks for your phone number and it returns 555-555-1212.   For the apps that need the real data (like maps, needs your location) you tell OS to tells the truth about GPS location.  But otherwise the same dummy data is passed by DEFAULT to every app.   If your map app asks about your phone number, it gets the same 555-555-1212.   This eliminates the app (& companies) from actually gathering any valuable data, and effectively the database will be poisoned making it virtually worthless to the company trying to collect the data.

With those two items; you could take control of your digital lives on your android or ios devices.  Yes, it requires more setup as when an app starts you have to tell it what you want to allow it to have access to data wise.  (or maybe when it requests something).

If anyone has an idea how to actually get Google or Apple to implement this in their Operating systems; I would love to hear feedback as I feel this could drastically improve our digital lives.    (and yes I know if you have a rooted android phone -- both are available to use right now.)     

Disclaimer: I have written books, blog posts, and plugins for NativeScript; so I currently do have a preference towards NativeScript.  However, anyone in the community that knows me; knows I'm the first person to call a spade a spade and argue about how this feature is horrible in NativeScript and awesome it is in framework X.  I can tell you several things I think that NativeScript is doing wrong or poorly.  (Just look on github)    I have written apps and/or thoroughly investigated the security and software stacks of each of the frameworks I've mentioned in this article.    I am not employed by Progress, nor is this blog sponsored by them -- all posts are strictly my own opinions.     

NativeScript 5.1.0 Released

For those who upgraded to 5.0.0 last month, it was a bit of a rough ride.  A lot of cool features but a lot of weird corner case broken items.  Fortunately since that point, they have released a several 5.0.x point releases which fixed several of the larger flaws.  5.1.0 actually fixes several of the non-critical smaller flaws and adds some cool new features...   So if you were waiting to jump on the 5.x bandwagon, this should be the stable release you are waiting for!

The quick list of some of the new features in 5.1

Core Modules

Enable modal dialog chaining in IOS - this allows you to have another dialog follow the first; anyone who has tried this in the past; know this was always a pain on iOS.

isScrollEnabled - This allows you to disable scrolling in the scrollbar component.

androidSwipeEnabled - Allows you to disable swiping in the Android tabview control.

You can use the arrow keys to select an option, in this screen shot; the "Plain JavaScript" is chosen and so it is highlighted.

Android

Android AAB (Android App Bundle); support added!

New package.json flag;  suppressCallJSMethodExceptions: true/false - enables suppression of the boolean errors when calling a native function.  This could happen and crash the app.  Now you can suppress them.  (see http://fluentreports.com/blog/?p=581 for more information) 

Java 8 Static method support on interfaces; allows NativeScript to call these Static functions.

extends should now work against standard javascript classes (i.e. non native Android classes); so that you can now do class MyVue extends Vue {}; class blahComp extends MyView {}; and it will work properly.

iOS

CStrings are a bit more resilient when passing to a function that wants them as a pointer to read and possibly write.

Updated JavaScript engine to JSC 12.0

CLI

Several bugs when using hmr are fixed.

Yarn Support

Adding lots more Analytics/Tracking (Don't forget to disable this for your privacy: tns usage-reporting disable && tns error-reporting disable)


Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

That will get you the latest version of NativeScript CLI; once you have it; do a "tns --version" and verify it prints out "5.1.x".  Then do a "tns doctor" to verify your environment is up to date and has all the newest support tools you need for a successful build.  

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack & HMR support:
npm i nativescript-dev-webpack@latest --save-dev
Note: you need to have nativescript-dev-webpack as a development dependency for HMR to work.  

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of all the additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable


Known issues