104 stories

A tour of iOS 10.3: Checking out APFS, the Settings app, and other tweaks

1 Comment and 2 Shares

Enlarge / An iPhone 5 running iOS 10. Version 10.3 is likely to be its last big update. (credit: Andrew Cunningham)

Apple has just released iOS 10.3 to the general public, an update which is likely to be the last major release of iOS 10; at this point in the year, work usually begins in earnest on the next major release of iOS, which will be revealed at WWDC in June. The update is available for everything that runs iOS 10: the iPhone 5 and newer, the fourth-generation iPad and newer, the iPad Mini 2 and newer, both iPad Pros, and the sixth-generation iPod Touch.

The update has been going through the beta process for a couple of months now, and since it’s likely to be iOS 10’s last major update, we’ll spend some extra time with a few of the high-profile features. I’ve also spent a tiny bit of time with the new APFS filesystem, which won’t change much for most people but does seem to free up a small amount of local storage space.

Change is afoot… in the Settings app

Andrew Cunningham

Read 17 remaining paragraphs | Comments

Read the whole story
27 days ago
Nothing much but faster animations has nice touch. "Location use" setting for apps is now more deep in the menus under privacy :/
Share this story

Password Rules Are Bullshit

3 Comments and 19 Shares

Of the many, many, many bad things about passwords, you know what the worst is? Password rules.

Let this pledge be duly noted on the permanent record of the Internet. I don't know if there's an afterlife, but I'll be finding out soon enough, and I plan to go out mad as hell.

The world is absolutely awash in terrible password rules:

But I don't need to tell you this. The more likely you are to use a truly random password generation tool, like us über-geeks are supposed to, the more likely you have suffered mightily – and daily – under this regime.

Have you seen the classic XKCD about passwords?

To anyone who understands information theory and security and is in an infuriating argument with someone who does not (possibly involving mixed case), I sincerely apologize.

We can certainly debate whether "correct horse battery staple" is a viable password strategy or not, but the argument here is mostly that length matters.

That's What She Said

No, seriously, it does. I'll go so far as to say your password is too damn short. These days, given the state of cloud computing and GPU password hash cracking, any password of 8 characters or less is perilously close to no password at all.

So then perhaps we have one rule, that passwords must not be short. A long password is much more likely to be secure than a short one … right?

What about this four character password?


What about this eight character password?


Or this (hypothetical, but all too real) seven character password?

You may also be surprised, if you paste the above four Unicode emojis into your favorite login dialog (go ahead – try it), to discover that it … isn't in fact four characters.

Oh dear.

"💩".length === 2

Our old pal Unicode strikes again.

As it turns out, even the simple rule that "your password must be of reasonable length" … ain't necessarily so. Particularly if we stop thinking like Ugly ASCII Americans.

And what of those nice, long passwords? Are they always secure?


Of course not, because have you met any users lately?

I changed all my passwords to

They consistently ruin every piece of software I've ever written. Yes, yes, I know you, Mr. or Ms. über-geek, know all about the concept of entropy. But expressing your love of entropy as terrible, idiosyncratic password rules …

  • must contain uppercase
  • must contain lowercase
  • must contain a number
  • must contain a special character

… is a spectacular failure of imagination in a world of Unicode and Emoji.

As we built Discourse, I discovered that the login dialog was a remarkably complex piece of software, despite its surface simplicity. The primary password rule we used was also the simplest one: length. Since I wrote that, we've already increased our minimum password default length from 8 to 10 characters. And if you happen to be an admin or moderator, we decided the minimum has to be even more, 15 characters.

I also advocated checking passwords against the 100,000 most common passwords. If you look at 10 million passwords from data breaches in 2016, you'll find the top 25 most used passwords are:


Even this data betrays some ASCII-centrism. The numbers are the same in any culture I suppose, but I find it hard to believe the average Chinese person will ever choose the passwords "password", "quertyuiop", or "mynoob". So this list has to be customizable, localizable.

(One interesting idea is to search for common shorter password matches inside longer passwords, but I think this would cause too many false positives.)

If you examine the data, this also turns into an argument in favor of password length. Note that only 5 of the top 25 passwords are 10 characters, so if we require 10 character passwords, we've already reduced our exposure to the most common passwords by 80%. I saw this originally when I gathered millions and millions of leaked passwords for Discourse research, then filtered the list down to just those passwords reflecting our new minimum requirement of 10 characters or more.

It suddenly became a tiny list. (If you've done similar common password research, please do share your results in the comments.)

I'd like to offer the following common sense advice to my fellow developers:

1. Password rules are bullshit

  • They don't work.
  • They heavily penalize your ideal audience, people that use real random password generators. Hey guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure.
  • They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure.
  • They are often wrong, in the sense that the rules chosen are grossly incomplete and/or insane, per the many shaming links I've shared above.
  • Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read this 2016 NIST password rules recommendation. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules".

2. Enforce a minimum Unicode password length

One rule is at least easy to remember, understand, and enforce. This is the proverbial one rule to bring them all, and in the darkness bind them.

  • It's simple. Users can count. Most of them, anyway.
  • It works. The data shows us it works; just download any common password list of your choice and group by password length.
  • The math doesn't lie. All other things being equal, a longer password will be more random – and thus more secure – than a short password.
  • Accept that even this one rule isn't inviolate. A minimum password length of 6 on a Chinese site might be perfectly reasonable. A 20 character password can be ridiculously insecure.
  • If you don't allow (almost) every single unicode character in the password input field, you are probably doing it wrong.
  • It's a bit of an implementation detail, but make sure maximum password length is reasonable as well.

3. Check for common passwords

As I've already noted, the definition of "common" depends on your audience, and language, but it is a terrible disservice to users when you let them choose passwords that exist in the list of 10k, 100k, or million most common known passwords from data breaches. There's no question that a hacker will submit these common passwords in a hack attempt – and it's shocking how far you can get, even with aggressive password attempt rate limiting, using just the 1,000 most common passwords.

  • 1.6% have a password from the top 10 passwords
  • 4.4% have a password from the top 100 passwords
  • 9.7% have a password from the top 500 passwords
  • 13.2% have a password from the top 1,000 passwords
  • 30% have a password from the top 10,000 passwords

Lucky you, there are millions and millions of real breached password lists out there to sift through. It is sort of fun to do data forensics, because these aren't hypothetical synthetic Jack the Ripper password rules some bored programmer dreamed up, these are real passwords used by real users.

Do the research. Collect the data. Protect your users from themselves.

4. Check for basic entropy

No need to get fancy here; pick the measure of entropy that satisfies you deep in the truthiness of your gut. But remember you have to be able to explain it to users when they fail the check, too.

entropy visualized

I had a bit of a sad when I realized that we were perfectly fine with users selecting a 10 character password that was literally "aaaaaaaaaa". In my opinion, the simplest way to do this is to ensure that there are at least (x) unique characters out of (y) total characters. And that's what we do as of the current beta version of Discourse. But I'd love your ideas in the comments, too. The simpler and clearer the better!

5. Check for special case passwords

I'm embarrassed to admit that when building the Discourse login, as I discussed in The God Login, we missed two common cases that you really have to block:

  • password equal to username
  • password equal to email address

🤦 If you are using Discourse versions earlier than 1.4, I'm so sorry and please upgrade immediately.

Similarly, you might also want to block other special cases like

  • password equal to URL or domain of website
  • password equal to app name

In short, try to think outside the password input box, like a user would.

🔔 Clarification

A few people have interpeted this post as "all the other password rules are bullshit, except these four I will now list." That's not what I'm trying to say here.

The idea is to focus on the one understandable, simple, practical, works-in-real-life-in-every-situation rule: length. Users can enter (almost) anything, in proper Unicode, provided it's long enough. That's the one rule to bind them all that we need to teach users: length!

Items #3 through #5 are more like genie-special-exception checks, a you can't wish for infinite wishes kind of thing. It doesn't need to be discussed up front because it should be really rare. You must stop users from having passwords that equal their username, or aaaaaaaaaaa or 0123456789, but only as post-entry checks, not as rules that need to be explained in advance.

So TL;DR: one rule. Length. Enter whatever you want, just make sure it's long enough to be a reasonable password.

[advertisement] Building out your tech team? Stack Overflow Careers helps you hire from the largest community for programmers on the planet. We built our site with developers like you in mind.
Read the whole story
43 days ago
Share this story
3 public comments
47 days ago
We need to check the last points (username, app name)
Milton Keynes, UK
49 days ago
True story: work wants to roll out Microsoft Office 365, and I was one of the first trial users. I got a post-it with an 8 character password from the IT grunt tapped to be the AD admin. As is my habit, I immediately changed the password with a random one created by a password manager. The password was 20 characters. The change password form accepts the new password and prints a happy "password changed!" message. I log out, then try to log back in; the login page then informs me that the maximum … *maximum* password length is 16 characters and rejects my login. Okay … truncate it to 16, maybe the change form cut it off. Login fails. Go back to IT grunt to get a password reset, get a new 8-character password. Login fails. Reset again. Be very careful copying down password, very careful entering it back in. Login fails.
So, it turns out that there is no length validation on Office 365 password change forms, and going over the 16-character minimum mentioned nowhere on the page will *permanently* lock your account. 👍
49 days ago
Why is there even an upper limit? If the password is properly salted and hashed then only the hash should matter.
49 days ago
From what I found, it is some backward-compatible dependency thing with Active Directory syncing, which Microsoft has not cared enough about to fix. Possibly something with early Windows versions storing passwords as reversible hashes, and definitions of the protocols for remote logins defining a now-too-short field for passwords. The limitation could have made sense in the early 1990s, but then got carried forward far too long, and we are still stuck with it 25 years later.
49 days ago
Ah, I can see how that would happen. In my experience, many of the problems with Windows can be traced to poor early implementation that was never (or becomes increasingly difficult to) fix.
49 days ago
Possibly the worst password rule is the one that demands you change your password on a regular basis. Either people will start writing down their passwords, or come up with a pattern that ensures their passwords are always easy to guess.
49 days ago
What's wrong with writing down passwords? A written copy is extremely useful, if you secure it the same way you do your money and credit cards, i.e. carry it in your pocket.
49 days ago
Point taken, wffurr. I was thinking more about the corporate environment which is where I usually see mad password rules like these. The number of times I have seen passwords on post-it notes, whichg are stuck somewhere convenient, is quite frightening.
49 days ago
That said, the best approach is to use a password manager to store randomly generated passwords. Of course, my current employer bans the use of password mangers.
49 days ago
Must change password every 21 days. Cannot reuse last 50 passwords. **These** rules make my passwords less secure than they could be. I have given up generating passwords that I can reasonably type that follow the rules. I mean, 21 days?!?
49 days ago
21 days? Ouch! The worst I saw was every 30 days, and I know a number of people using a combination on month and year for their password.
49 days ago
And the new password can only have (IIRC) one point of similarity with the previous one.
49 days ago
That's just painful. It's rules like that which are just asking everyone to write their password on the nearest available post-it note.
48 days ago
That's weirdly strict. We have a change every 90 days and you can't use your last 2 passwords. That's it. Simple enough to rotate a handful of passwords 4 times a year.
48 days ago
this one drives me crazy. the damn auditors eat password expiry up and are always pushing for less time. total bs.
48 days ago
There is a government personnel website I've used where (1) the average user logs in about 2x/year, (2) the password resets monthly.
44 days ago
The NIST guidelines link in the post also strongly recommend against arbitrary password expiration. I sent the NIST document to my corporate IT when they changed password expiration rules just recently. It hasn't impacted any change, but at least I tried to talk sense to power.
43 days ago
@WorldMaker: I'm impressed that you tried to talk sense, but the main problem with large corporations is that they tend to adopt a checkbox approach to these things. People have to prove that they are doing _something_ about security; no-one ever asks whether what they are doing is actually useful.
42 days ago
@expatpaul: Arguably as a software developer a part of my role is to evaluate and better the company's software. Even if that just means writing a ticket every few weeks to try to argue true industry best practices against fads and security theater. Of course, without a CTO title they don't have to listen to me, but I can hope they might at least read it. Even if they are hearing stupid crap from outside security consultants and terrible software vendors that should be destroyed for the betterment of the corporate world like Oracle. The only way we might see change is to keep talking sense to power and hope someone listens or promotes us until they have to listen.
42 days ago
As long as companies want to do business with companies the require SOC2, HIPPA, SOX, etc. (not to mention their own compliance BS), it doesn't really matter. At least NIST is on board.

Getting Started With VR Interface Design

1 Comment


The virtual realm is uncharted territory for many designers. In the last few years, we've witnessed an explosion in virtual reality (VR) hardware and applications. VR experiences range from the mundane to the wondrous, their complexity and utility varying greatly.

Getting Started With VR Interface Design

Taking your first steps into VR as a UX or UI designer can be daunting. We know because we've been there. But fear not! In this article, we'll share a process for designing VR apps that we hope you'll use to start designing for VR yourself. You don't need to be an expert in VR; you just need to be willing to apply your skills to a new domain. Ultimately, as a community working together, we can accelerate VR to reach its full potential faster.

The post Getting Started With VR Interface Design appeared first on Smashing Magazine.

Read the whole story
81 days ago
Adding this to my all too long todo-list :)
Share this story

★ On Chuq Von Rospach’s ‘Apple’s 2016 in Review’, and the AirPort and Mac Pro Lineups in Particular


Chuq Von Rospach has a thoughtful look at the state of Apple. The whole piece is worth reading, but his comments on two particular products stood out to me. First, the AirPort lineup:

Apple has products it has let languish without any significant update for long periods of time. If you look at how Apple’s treated their AirPort line, you’d think Wi-Fi was a mature technology where nothing was really changing. In fact, a lot is happening including a big shift to mesh networks, and Apple has seemingly ignored all of that. It used to be you bought Airports because they were some of the best Wi-FI devices out there. Today, the only reason to buy them is you want easy, and because it has the Apple brand. They’re woefully out of date (and in fact, I just replaced mine with a set of Eero devices, which are Apple easy to use, and blow Apple’s products away in terms of performance). Rumors have come out that Apple has cancelled future development of these, but they’re still for sale. Why?

Something is clearly wrong with the AirPort line. Either it should have been updated long ago to remain state-of-the-art, or it should have been discontinued. Whether or not Apple should still be in the Wi-Fi router game is a reasonable argument. I think they should, but I can see the other side of the argument (that other companies do it well, and Apple should focus on areas where they stand alone). But there’s no reasonable argument for the current AirPort state of affairs.

And on the Mac Pro:

To put the Mac pro in context: This was the “Can’t Innovate my Ass” product that Apple produced to counter criticism that it wasn’t innovative any more and that it was letting the Mac product line languish (hey, this isn’t a new complaint…). They came out with something that was visually distinctive and they build a really interesting set of guts inside the trash can.

But here’s the problem: in retrospect, what they built was a device based around their own ego needs of proving their critics wrong, not a device that served the purposes of their power users. It’s not configurable, it’s not upgradeable, it’s not expandable: It’s pretty, and full of (for 2013) innovative hardware design, but is that really what Apple’s power users needed?

“What the hell happened with the Mac Pro?” is the most interesting question about Apple today. Because something clearly went way wrong with this product. I’m not convinced the basic idea for the design is unsound — the idea is that expansion would come in the form of external peripherals, rather than things you install inside the box. I still think that’s probably the future of “expandable” computing.

If Apple had updated the Mac Pro on a roughly annual basis, we wouldn’t be calling this a disaster. I’m sure there would still be people who would wish that Apple had stuck with the traditional tower form factor, but we wouldn’t all be saying “What the fuck?”

If Apple were going to update this Mac Pro, we should have seen it two years ago. If Apple were going to scrap this design and replace it with something else (like they did with the short-lived “sunflower” iMac G4 design in 2002), we should have seen the replacement a year ago. And if they were planning to abolish the Mac Pro, that should have happened this past year — or at least we should have seen prices drop significantly on these three-year-old workstations.1

Updates to the same basic design would make sense. An all-new design would make sense. Getting out of the Mac Pro game would make sense. Selling 1000-day-old pro workstations at the same prices as in 2013 makes no sense. Whatever the explanation is, this situation is an unmitigated disaster.

  1. Other computer makers raise and lower prices as component prices change. Apple comes out with a price and sticks with it. One reason for that is branding. Stable prices at “round” numbers — $1499 instead of $1427 or whatever — are a sign of a premium quality brand. And they don’t lower prices on older products unless they keep them in the product lineup after their replacements have been introduced. What they almost never do is lower the price of a product just because it’s old, without a replacement. Thus, if Apple were to announce price drops on the Mac Pro lineup, without releasing updated models, I would take that as a very strong sign that they’re getting out of the standalone pro desktop market. But they haven’t done that — they’re still selling these Mac Pros at the same prices as when they were announced over three years ago. I take that as a sign that they plan to replace them, or at least hope to replace them, but have failed for whatever reason(s). ↩︎

Read the whole story
114 days ago
"Apple doesn't understand its users as well as Apple thinks it does." Sad but true. The critique has good suggestions . "It’s not all bad".
Share this story

Inside Blue Ocean – the new UX that’s getting the Jenkins community excited

1 Comment

To many dev teams, Jenkins is synonymous with continuous integration (CI), automating the mundane tasks of integration, test and build for projects – the very thing founder Kohsuke Kawaguchi created it for, in the underbelly of Sun and Oracle. However, as more organizations adopt Jenkins as their engine for continuous delivery (CD), broader teams with varying degrees of technical skills demand a more bespoke and succinct user interface. We talked to James Dumay, ‎Senior Product Manager at CloudBees and lead contributor to the Jenkins Blue Ocean plugin, about the need for Blue Ocean and what to expect from it in the near future.

The post Inside Blue Ocean – the new UX that’s getting the Jenkins community excited appeared first on JAXenter.

Read the whole story
125 days ago
It was about time for Jenkins to get a pleasant UI.
Share this story

Bloomberg: ‘Apple Abandons Development of Wireless Routers’


Mark Gurman, reporting for Bloomberg:

Apple Inc. has disbanded its division that develops wireless routers, another move to try to sharpen the company’s focus on consumer products that generate the bulk of its revenue, according to people familiar with the matter.

Apple began shutting down the wireless router team over the past year, dispersing engineers to other product development groups, including the one handling the Apple TV, said the people, who asked not to be named because the decision hasn’t been publicly announced.

Not surprising, given that their current hardware hasn’t been updated in three years. Apple used to refresh its Airport routers frequently, to keep up with the state of the art. They often weren’t first to adopt new standards, but they never sat still for three years.

The question is, are they really out of the router game (and will start selling Belkin or Eero routers in their stores), or are they working on something new, a HomeKit hub, that will include the functionality of a router?

Just seems like Apple is abandoning a lot of stuff without having replacements ready these days.

Read the whole story
158 days ago
Yep, Apple has lost it :)
Share this story
1 public comment
157 days ago
Why does Apple ha e to replace things they no longer want to make? Why don't these Apple loyalists accept that Apple may be changing it's strategy when it comes to making everything?
Next Page of Stories