Wednesday, 23 May 2018
Tuesday, 3 October 2017
Security in today’s world is challenging to implement without making it a matter of privacy or ridiculously difficult for the end user. Passwords, PINs or Memorable Words? While many service providers implemented a multi-step verification system, it is still far from perfect. Troy Hunt, in his recent article nicely explains this:
here’s the problem with multi-step verification: it’s a perfect example of where security is friction. No matter how easy you make it, it’s something you have to do in addition to the thing you normally do, namely entering a username and password. That’s precisely the same problem with getting people to put PINs on their phone and as a result, there’s a huge number of devices out there left wide open.
Anecdotally, I have friends working in hotels and you won’t believe how many people who forget their phones don’t even have a passcode.
I found one survey from 2014 which said 52% of people have absolutely nothing protecting their phone. Another in 2016 said the number is more like 34%. Keep searching and you’ll find more stats of wildly varying values but the simple fact remains that there are a huge number of people out there with no protection on the device at all.
Systems like TouchID and now FaceID make this friction go unnoticeable. Over the past couple of weeks we had many people and news outlets lay their opinions and concerns with where technologies are headed. It’s particularly easy in the the machine learning and artificial intelligence space to exaggerate the outcome, but at the same time I understand where these concerns are coming from. I believe it’s great that we’re having a discussion about the implications of such technologies. We had them 4 years ago with Touch ID and we are having them now. But there is no reason to fear monger the whole world, serving Black Mirror style stories.
How well and consistent Face ID will is yet to be reported. But if there is a company who can get it right, then that is Apple. Stay secure.
Monday, 10 April 2017
This week repository showcase is about learning and resources. First up is a collection of algorithms and data structures implementation in Java as well as some potential interview questions.
This is the collection of algorithms, data structures and Interview Questions with solutions. This repository contains my solutions for common algorithmic problems and implementation of Data Structures in Java. I’ve created this repository to learn about algorithms. I am adding solutions continuously.
I swear I don’t pick these “interview” repos on purpose, following the similar repo from last week’s repository showcase. Next up is an interesting CMS that automatically generates the JSON API for you, written in GO.
With the rise in popularity of web/mobile apps connected to JSON HTTP APIs, better tools to support the development of content servers and management systems are necessary. Ponzu fills the void where you want to reach for WordPress to get a great CMS, or Rails for rapid development, but need a fast JSON response in a high-concurrency environment.
Hot this week is the appearance of a Twitter platform alternative. Interesting part about it is its decentralized approach where anyone can run their own instance and connect to others.
Mastodon is a free, open-source social network server. A decentralized solution to commercial platforms, it avoids the risks of a single company monopolizing your communication. Anyone can run Mastodon and participate in the social network seamlessly.
An alternative implementation of the GNU social project. Based on ActivityStreams, Webfinger, PubsubHubbub and Salmon.
And finally something I love about Awesome lists is how awesome they are… This one is about Mac applications and lookign through it it’s quite comprehensive.
This repo is a collection of AWESOME Mac applications and tools for developers and designers.
Sunday, 9 April 2017
For the past two years PostgreSQL has been my RDBMS of choice and has served me well. In fact I love PostgreSQL so much I decided to use it over the MySQL in my dissertation project, but for different reasons than the one exposed. Now someone has asked a sensible question on HackerNews and I am glad they did because the conversation unfolds nicely which tidbits from both sides.
I always got the impression (since I started using it in Prod in the late 90s) that the MySQL team had never worked on an RDBMS before, even as users, and didn’t really understand it. Back then they would say, you don’t need foreign keys, you can just enforce consistency in your application, you don’t need transactions, you can just handle it in your application, and so on and so on. Monty Widenius was very arrogant and thought he knew everything. Eventually they matured a bit and realized that actually, yes, the entire rest of the database community weren’t idiots, maybe there is something to these features, but now they needed to find a way to retro-fit them onto what they had and now – 20 years later – they still haven’t figured out how to smush it into their architecture.
Whereas the Postgres crew were fresh out of the Ingres project led by the genius Micheal Stonebraker, they had a very clear vision and a culture of doing the right thing, not the easy thing. There’s a steeper learning curve but once you have learned a few things you can easily guess the rest because it’s so consistent. For MySQL you really need a “guru” because there are so many dark corners and weird edge cases that make no sense, you just have to “know” them.gaius
And that is also where I found this article that goes in depth on why MySQL might not be such a good idea. Here is a bad argument on why you should use MySQL over something else.
- It’s getting better, so we might as well stay on it. It’s true, if you go by feature checklists and the manual, MySQL is improving “rapidly.” 5.6 is due out soon and superficially looks to contain a number of good changes. I have two problems with this line of reasoning:
- Why wait? Other databases are good now, not eventually.
- MySQL has a history of providing the bare minimum to satisfy a feature checkbox without actually making the feature work well, work consistently, or work in combination with other features.
Ah and this also reminds me about the list of features coming in PostgreSQL 10. If you haven’t read it yet, give it a chance.
Friday, 17 March 2017
Starting this week I’ve decided to start a weekly ICYMI repository showcase blog starring a few of the repositories I’ve found this week and considered interesting.
This week it’s mainly about becoming a better me and nailing that interview with an interesting entry on how to build a safe A.I.
I like this one because it helps you look at what paths you might want to take and paints a clearer picture of the available options. Features both frontend and backend, soon to have DevOps as well. Watch this repository for updates!
Below you find a set of charts demonstrating the paths that you can take and the technologies that you would want to adopt in order to become a frontend, backend or a devops. I made these charts for an old professor of mine who wanted something to share with his college students to give them a perspective.
Brush up your knowledge on different notions and principles. Data structures and algorithms explained, handful of useful resources.
TLDR: In this blogpost, we’re going to train a neural network that is fully encrypted during training (trained on unencrypted data). The result will be a neural network with two beneficial properties. First, the neural network’s intelligence is protected from those who might want to steal it, allowing valuable AIs to be trained in insecure environments without risking theft of their intelligence. Secondly, the network can only make encrypted predictions (which presumably have no impact on the outside world because the outside world cannot understand the predictions without a secret key). This creates a valuable power imbalance between a user and a superintelligence. If the AI is homomorphically encrypted, then from it’s perspective, the entire outside world is also homomorphically encrypted. A human controls the secret key and has the option to either unlock the AI itself (releasing it on the world) or just individual predictions the AI makes (seems safer).
Not exactly a repository, but a Github Page, although @iamtrask makes the code available on his GitHub.