Apple and security: Are we back to using our favorite band as our passwords?

I have relatively recently started switching all my online account over to using a password system where all my passwords are over 20 characters, and the password is different for each and every account. It also contains both numbers, lowercase characters, and uppercase characters. I should be safe, right? Well, not quite.

A while ago, I just randomly decided to try out Apple’s “forgot password” feature. I’m a web developer, and am sometimes curious as to how websites implement that kind of thing, so I headed over to http://iforgot.apple.com/ and typed in my Apple ID. I noticed that it gave me the option to answer security questions.

I was first greeted with this screen, asking me for my date of birth:

apple-dob

The date of birth is obviously not classified information, and is basically available to anyone who knows my name and how to use Google.

Having typed in this, I get to a new page, which looks like this:

apple-secquestions

It asks me what my favourite band is and what my first teacher’s name is. None of that is secret either; anyone who know me knows that my favorite band is Metallica, and there are traces of that all throughout the Internet, and if it’s not in public records somewhere, anyone could just randomly ask me what my first teacher’s name was, and I’d probably answer honestly.

Anyways, typing in that information, I find something truly terrifying:

apple-terrifying

I was able to change my password. Only knowing my email address, my date of birth, my favourite band, and my first teacher, anyone could take complete control of all my Apple devices, remotely delete everything on them, access all my images, all documents, everything. And there would be nothing I could do to stop it. After some days, I would probably notice that I couldn’t log in to anything, and would call tech support, but at that point, it would already have been way too late. Anyone could by then have remotely deleted all my data, after backing it up on their machine. Only by knowing publicly available information about me, or asking me seemingly innocent questions via chat.

This isn’t even a case of me using terrible security questions either. Apple only allows you to pick from a small set of security questions, and the vast majority of them were completely inapplicable to me. I have no favourite children’s book. I’m not sure what my dream job is. I didn’t have a childhood nickname, unless we count “mort”, which isn’t really a “childhood” nickname, as it’s my current nick to this day. I don’t have a car, so I don’t know the model of my first car. I have no favourite film star or character. Et cetera. Those are all questions I could’ve chosen instead of “Who was your favourite band or singer in school?”, but none are applicable to me, and more importantly, none of them would be more secure than my current security questions.

Is this standard for security really acceptable from anyone, much less the world’s most valuable tech company, in this day and age? Are we really back to the dark ages of using birth dates, favorite bands, and other personal information as our passwords? Didn’t security experts find out that this was a bad idea a long time ago?

There are of course ways to mitigate the effects of Apple's poorly designed system. You could generate new random passwords for each security questions if you're using a password manager, or you could make up fake answers. I highly suggest going to https://appleid.apple.com/signin and change your security questions right away. However, Apple's solution is still broken. I expect that the vast majority of people will give their actual personal information as the answers, because after all, that's what the website asks you to do.

Read More

Yet Another "Types of Programmers"-post

I and some friends were hanging out in a Google Docs-document earlier, and made our own "types of programmers"-list. The result:

The kinda-master:

This kind of programmer always assumes they know best, and commits without any testing, often breaking sections of the code. They invent unusual methods of doing things, and insist they are the best, especially when they are not. They are very skilled at many things, and assume this translates to everything.

The Delusional:

This kind of programmer takes knowing more than the average person to be knowing more than any person. They code badly and refuse to improve, under the impression everyone else is a moron, especially those who know better than them.

The Ninja:

This breed of programmer quietly twiddles their thumbs until their code is due, at which point they promptly ejaculate a pile of code resembling the result of spaghetti being fed through a blender.

The Bugfixer:

This kind of programmer does nothing at all to assist in the development of a project, leaving it to someone else, who as a result of having more work will produce a buggy and terrible end project. It is at this point that the bugfixer springs into action, finding single lines of code and suggesting slight improvements, all the while making snobby comments about how they should have been written better.

The Magician:

The one you go to whenever you need help, only to get an answer you can't seem to comprehend. You proceed to assume The Magician is an expert in the field, as he seem to possess some long lost knowledge you never knew existed.

The Tinkerer:

The programmer who starts one project, then spends the rest of his life working on said project. The Tinkerer will often end up with a neat end product, but it will be his only product. He will become an expert in any field his project touches, but will know nothing of any other field, save random information he happens to stumble upon.

The Procrastinator:

The one who always theorises about great projects. The Procrastinator will rarely get started with a project, and if they do, you can bet your ass it won't live for more than a week, tops.

The Perfectionist:

A close relative of The Procrastinator. There's one important difference though: while The Procrastinator rarely gets any idea started, The Perfectionist will usually start his projects. The Perfectionist will never get anything done though, as his time doesn't spent writing code, but rather trying to find ways to make his code perfect.

The Duct-Tape Programmer:

The one who tends to get projects done, but usually in a messy manner. The Duct-Tape Programmer is a polar opposite of The Perfectionist and The Procrastinator. Much like The Procrastinator, The Duct-Tape Programmer's head is sprawling with ideas. The difference is that The Duct-Tape Programmer will immediately start writing code, without thinking through anything. The shortcomings of his code will be fixed with duct tape.

The Anti Insertionist:

This kind of programmer relies on others to create a bad codebase, then improves it quickly, ending up with less insertions than deletions. They fix the most bugs and are useful as hell when finishing a project, but are useless by themselves. Since they are able to improve everyone else's code, they have a higher degree of knowledge of what they are doing than anyone else.

The Medium-rare:

Delicious.

The Spandex:

The programmer who doesn't specialise in one field, but rather his best to cover all fields. The Spandex will know something about everything, but a lot about nothing. Jack of all trades, master of none.

The Delusional Magikarp:

Is not a programmer but thinks they are programmer. The most common case of this is the front end web developer, who thinks knowing HTML and CSS puts him in the same league as those writing physics engines in C.

The Newbie:

The one who has just recently discovered the art of programming. The Newbie is a dangerous beast, his code is usually riddled with bugs, memory leaks, SQL injections and what have you not, but at least his heart is in the right place, and he's willing to learn.

The Douchebag:

The individual who has no good intentions. The Douchebag is often seen writing code which relies on a key value store which can only be interfaced with by writing a distributed Map-Reduce function. To make matters worse, his language of choice is Erlang.

The Insane:

Conversations with himself which usually go something like this:

observation: mort often makes jokes I don't get.

observation: inv often doesn't (stop confusing don't and doesn't) (sorry D:::) (>:C) get the jokes I make

observation: who the hell are you. < who typed this dunno

who t

she hell are YOUXeooooooolokk swwag

swedgeis this cursor purple???? ANSEWR ME >:L BLEURIOE:( wut color D: But invalid is blue :O WHO IS THAT

LE PURPLE

I WANT TO BE HEDGEHOG >:LJOP no its not its bzxcvzxcvzxcvAAAAAAAAAAAAAsdlue many dolphin, such wow, much anonymous if you are a hedgehog it is purple Can i haz purple hedgehog no? never

Plox ;n; POWEJPRWEJ D:::::::: BUT HEDGEHOG >:L fack u no not now

Read More

Experimenting with static site generation

Hi!

If you visit this blog on a regular basis, which you probably don't, you may have noticed that it looks a bit different from how it used to look. The overall theme is the same, but the URLs look way different, and there is no comment section. So what happened?

A while ago, I wrote my own content management system in PHP, replacing WordPress. That was your standard CMS, for every request, you have a script (PHP script in this case) which generates the page dynamically, showing you the content you requested. March this year (2014) though, I started a new project, which works fundamentally different.

Enter jsSiteBuilder.

jsSiteBuilder is a static site generator. That means that nothing is built on the fly. There's a script which reads the content of a MySQL database and generates all the required HTML files for each and every page and post. Whenever a user requests the website, the one and only thing the web server ever does is what web servers do best - it fetches the file and sends it back to the user.

The most obvious advantage with this method is performance. Both server load and request time is brought down to the absolute minimum. It also provides some much needed stability. Your website doesn't go down, even in the case of an extreme disaster. Say you accidentally delete your MySQL database, or the database host goes down, or file permissions mess up. Usually, this would take down the website. With this CMS however, all html files will just stay there, available for everyone to see. Your users won't notice a thing, while you can take all the time you need to properly fix whatever issue appeared. You can even re-run the site building script as much as you like while everything is down; it won't delete anything.

Not everything with jsSiteBuilder is static however. More specifically, it has the admin control panel you'd expect from an old-fashioned dynamic site generator, like WordPress. That's because the admin panel is written in PHP. This makes it easy to create, edit, and generally administer and set up the website. All the admin interface does is to interact with the MySQL database. Once you're done making whatever changes you want to make, you can update the user-facing portion of the website with the push of a button. On my blog, with my server, completely regenerating the entire site takes no more than a few tenths of a second.

Read More

A small WTF regarding CSS units

CSS. A tool loved by web developers all over the world. It lets us style our HTML easily, and creates somewhat loose coupling between content and layout.

CSS. A tool hated by web developers all over the world. It makes us spend countless hours trying to accomplish what seemed to be the most mundane task.

Today, CSS got a little bit weirder.

It all started with me and a discussion between me and a friend, Stef Velzel (or Invalid). He has a website at ckefworx.com, in case you're reading this in the year 3026 and he has finally removed that "under construction" banner.

Anyways, Invalid and I was discussing, as we so often do. I had come across a blog post on Reddit claiming that in CSS, one pixel (px) is always 1/96 of an inch. I even found CSS specifications, which supported the statement. Invalid disagreed though, and meant that 1px is always one pixel on the screen, according to his experience.

It turns out I was right. In a sense at least. But so was Invalid. You see, 1px being 1/96 of an inch and 1px being exactly one pixel isn't mutually exclusive. Not with CSS at least.

"But wait", I hear you say. "That doesnt make sense?"

Well, yes it does. Sort of. If you're a mathemagician, you may have figured out this already. The only way this adds up, is if one inch is 96 pixels, 96 points of light on your screen.

Have you spotted the issue here? no? yes? 96 pixels isn't equivalent to 1 inch. Not in a world where pixel density varies wildly from device to device. CSS can't just redefine inches like that can it? I mean, 1 inch is exactly 1 inch, isn't it..?

Well apparently, CSS can indeed just redefine units of measurement like that. 1 inch is 96 dots of light, not 1 inch.

On some deep level, this makes sense. It seems like common sense define units of measurement out from the fundamental unit of the display instead of arbitrarily defined real life measurements. The problem is that it's marketed as inches, centimetres, etc. instead of what it actually is. This causes a lot of confusion.

I should probably add that the spec doesn't state that one inch should be 96 pixels. It rather says that one px should be 1/96 real world inch, which at least makes a little sense. Browser vendors implement it how I described above though, and in the end, that's what matters.

Update: I should probably have included some of the tests I did, and some sources.

First off, let's see how a pixel is defined by the W3C:

The absolute length units are fixed in relation to each other and anchored to some physical measurement. They are mainly useful when the output environment is known. The absolute units consist of the physical units (in, cm, mm, pt, pc) and the px unit:

cm: centimeters

[...]

in: inches; 1in is equal to 2.54cm

px: pixels; 1px is equal to 1/96th of 1in

[...]

According to that, it would seem like 1 inch is exactly 1 inch, regardless of resolution. 1px should arlso be the same regardless of resolution, as it is defined using inches.

Look at this example element however:

<div style="background-color: #000; height: 1in; width: 1in"></div>

I don't know about your browser, but mine does at least not render that as exactly 1 inch. Have a look at this however:

<div style="background-color: #00F; width: 1in; height: 1in; display: inline-block"></div>
<div style="background-color: #F00; width: 96px; height: 96px; display: inline-block"></div>

I don't know with you, but those look fairly similar with all browsers I've tested with. This shows that, regardless of what the CSS spec says, an in isn't an inch, at least not in all browsers. It's 96 pixels.

Read More

Rant about YouTube

Since its inception in 2005, YouTube has grown out of proportions. It is to videos what Google is to search.

With a user base of billions of people and thousands of hours of footage uploaded daily, you'd almost think they knew what they were doing. And they do, from an infrastructure standpoint. That amount of traffic requires vast server farms all around the world, all working together.

Where YouTube lacks however, is in terms of its user interface. There are some real disasters in this department.

Take for instance selecting a video's quality. When you change the quality from the default 360p to say 720p, and user would expect the quality to change. The user model says that when you change quality, the quality changes. Believe it or not, the YouTube team actually managed to get this wrong.

When you change a video's quality, the video remains in its original quality. It changes to the selected quality only when it has played through all that is already buffered.

For me, a pattern like this is not unusual:

I click on a video. I fullscreen it on my big 1080p display, before changing the quality to 1080p, but due to my 70 Mb/s internet connection and YouTube's great infrastructure, 3/4 of the video is already loaded. I proceed to watch 3/4 of the video in horrible quality, before it switches over to beautiful full HD.

One definition of great software, is that the program model corresponds to the user model. Basically, the program should behave like the user expects. The user model is definitely not that changes in quality settings applies only after watching a random portion of the video, if at all.

Another cause of bad usability is frequent changes in the user interface. Not small changes, like altering the looks of a button here and adding some gradients there. No, we're talking total overhauls of the UI. Completely revamping how everything is structured.

YouTube has had quite a few of these huge overhauls. Some times it has restructured everything multiple times per year.

Users hate big changes. The reason is that users don't analyze the interface and look for the most logical place for a feature every time they need said feature. No, we users memorize where what we need is, and navigate there out of habit more than anything else, at least with programs we use frequently.

When the user interface is restructured, we still go looking for what we want in the areas we're used to. When that doesn't work, we lose our feeling of control. The program now has control over you. This happens unconsciously, and leads to frustration.

Furthermore, it forces us to reanalyze the interface and look for features we previously knew where was. As it turns out, this causes quite a bit of cognitive overhead. Our brains are way better at just looking up already stored information than processing brand new data. When YouTube us completely overhauling its website multiple times per year, this becomes quite a bit of an annoyance.

The mobile application for iOS, and possible Android, is a bit of a disaster too. At least in sone respects. Sure, it has its bright sides, but as this is a hateful rant, I'll jump gracefully over those and focus on the bad aspects.

In YouTube, there is a comment section, as you may know already. It's possible to reply to people's comments. You can even see who a comment is a reply to, and by the press of a button, you can see the original comment.

The team working on the mobile app rightfully decided to implement the comment section. What they did not however, was to let you see who a comment is a reply to, rendering it useless. You see, this reply-to-feature is frequently used. It's used so much that without it, the comment section is just a bunch of random statements, completely out of context.

The app also has a feature which dynamically sets the video's quality according to your internet speed. Unfortunately, this doesn't quite work right.

In my home, there's an area which the router's WiFi doesn't quite reach. When I move into it, YouTuve notices the bad connection and drops the quality to below unbearable. It seriously looks like a grunge teared apart by a crack in the space time continuum, just slightly less fancy. Unfortunately, it does not adjust itself once the connection picks up again for quite some time. This forces me to exit out of the video, scan the list of videos for the proper one, wait for it to load, and navigate to where I was. As you might expect, this completely kills my flow.

In short, how to fix YouTube:

  • Make quality changes immideate
  • Less frequent UI overhauls
  • Implement replies into the mobile app's comment sections
  • Provide optional quality controls to the mobile app
  • Make the app better at automatically selecting quality
Read More