At Microsoft Build 2016, we introduced a new feature for Dotfuscator Community Edition (CE): command line support. This will allow you to integrate Dotfuscator into your automated build process, so that your builds and releases can automatically use Dotfuscator for obfuscation, tamper protection, usage tracking, and expiration. To help you get started, this post will walk through how to use the command line interface (CLI), as well as how to integrate it into MSBuild and Visual Studio for automated builds.
As of its 4.20 release, Dotfuscator Professional supports protecting Universal Windows Platform (UWP) applications.
There are two recommended ways to incorporate Dotfuscator into your UWP application build process: (1) integrate Dotfuscator into the MSBuild pipeline or (2) use Dotfuscator directly on your appx packages. These methods differ in their ease-of-use and in the level of protection they provide.
An app control that both Microsoft and Google can get behind? What about Xamarin?
First - Congratulations Xamarin (and Microsoft) - as someone who has used Xamarin personally and worked with the people professionally, I see this as a win-win-win (for Xamarin, Microsoft, and, last but not least, developers!).
To the topic at hand... One might argue that the phrase "GooglePlay security recommendations" is a contradiction in terms or even oxymoronic - but I take a different view. If (EVEN) Google recommends a security practice to protect your apps - then it must REALLY be a basic requirement - one that should not be ignored.
Question: True or False, Seat belts are to Driver Safety as Obfuscation is to Application Risk Management
The correct answer is FALSE!
The equivalence fails because a seat belt is a device and obfuscation is a control. Why might you (or the application stakeholders) be in danger? First, read through the key descriptors of these two controls.
I recently got a question from a client asking why .NET Native (the process of transforming a .NET assembly into a native app to improve performance) did not also make products like Dotfuscator irrelevant. Here's my response (with personal details removed of course).
First, the .NET Native process is only applicable to Universal Apps distributed through a Microsoft marketplace. If you are developing .NET (using VS2015 or anything else) BUT are targeting anything other than a Universal App architecture - .NET Native does not apply – also, if you’re developing in F# - even if Universal - .NET Native does not apply.
Instrumentation Injection – the process of embedding (inserting) instructions into a binary post-compile with no programming whatsoever – offers a powerful means of improving application monitoring, application security, and application lifecycle management. There are a number of scenarios where code injection makes a lot of sense - for this post, I'm really focusing only on the injection of application analytics instrumentation.
Earlier today, the Safe Harbor system was just overturned (see Europe-U.S. data transfer deal used by thousands of firms is ruled invalid).
The legal, operational, and risk implications are huge for companies that have, up until today, relied on this legal system (either directly or through third parties that relied on Safe Harbor) to meet EU's privacy obligations.
Writing data to disk is easy – developing a database is not.
Posting data to a URL is easy – developing an application analytics ingestion pipeline is not.
If you’ve written even a single line of code (in any language), I probably don’t have to explain why writing data to disk is easy – but developing a database is not (for those that have never written any code – it’s the extra database “machinery” required to handle scale, concurrency, resilience, security, etc. that demands a horde of PhD's and rock-star developers).