Popular file-syncing service Dropbox has been in hot water lately. It was bad enough to find out awhile back their misleading phrasing wasn’t true and that files were indeed accessible to its employees. This has resulted in a formal complaint to the Federal Trade Commission. Now apparently that same design choice – the one about which they claim they didn’t mislead customers – made a new security snafu possible.

Apparently, for a four-hour window this past Sunday, any user account could be accessed using any password. Because a user’s files are encrypted on Dropbox’s servers (not on your computers or mobile devices), this means a security screw-up like this can give unimpeded access to any user’s files.

Conversely, had they chosen to encrypt files client-side, this authentication bug would not have granted access to the files because the password / decryption key would not match and the files would come back scrambled if they came back at all.

Twice, Dropbox has demonstrated poor security practice. Some would argue they also demonstrated dishonesty by claiming their employees couldn’t access the files (their wording suggested “unable” rather than “not allowed”). Now a new problem has been demonstrated: they have poor or nonexistent testing practices when rolling out updates to their servers. Had they at least automated testing of their authentication system, they would’ve discovered the problem before ever having deployed the changes to their public-facing servers. As a user, I have yet to learn of a single one of these incidents from Dropbox themselves.

This latest sin and all it reveals has caused me to abandon Dropbox entirely. I can no longer trust them. Wired suggested two alternative services: Wuala and SpiderOak. Both offer client-side encryption and Mac and iOS clients (important to me). I’m currently leaning toward Wuala (see update below) but have learned to do my homework first. I won’t be signing up for another Dropbox-like provider, free or not.

It’s that last sentence that could be used as a retort: “Relax, it’s a free service.” Granted if you need 2 GB or less, the service is completely free. Nice of them but not nice enough to allow them to – in my opinion – mislead me about their security and for me to put up with repeated ham-headed security offenses. Those who’ve known me awhile (or at least followed me on Twitter) likely remember I was hesitant to use something like Dropbox for awhile at all. I begrudgingly tried it and changed my opinion. I found a few good uses for it. Not good enough to make me want to integrate my own applications with it (a popular request a year or two ago), but good enough to use on its own.

I’m of the opinion that Apple’s upcoming iCloud service will offer a seamless file syncing experience (hopefully more “seamless” than iDisk). I also believe they’ll worry over security as well – they do have a reasonable track record. As I use all Apple devices, I should have no trouble getting to the stuff I need … with style. For this reason, I’ll be using Wuala (or SpiderOak) as a stopgap until iCloud is available.

So long, Dropbox, and thanks for all the fish.

Update – Err, never mind about Wuala. It’s Java-based (I’m a “native app purist”) and decidedly not user friendly. I can’t figure out whether it offers automatic syncing at all and it appears to be still in beta. Further, its completely unexplained “file system integration” setting in preferences is enabled but its “check” says it can’t “Access Root  Directory” to offer this feature. No fucking thanks.

 

Web developers (developers, developers): I need you to listen to me. Are you listening? Good. Stop trying to be smart about detecting browser capabilities. You almost always get this wrong. Usually it’s because you’re used to a single platform and only test on others and so you’re not always up to speed on how the various browsers of the world work.

There are two main scenarios in which you frequently fail hard, resulting in my assumption that you are a semi-professional entry-level developer at best. This makes me hate you. Often, it makes me fire off an angry rant to your contact address, chiding your lack of experience and your complete destruction of my faith in your site’s ability to be useful to me, even if I could find my way around your stupidity. Let’s explore these scenarios together that you might learn from them.

Mobile Versions – Whether You Want Them or Not

First, you assume based on my using “Mobile Safari” that I need to be railroaded to your “mobile version.” Many of you don’t even ask – you just shunt me to mobile and maybe, if I’m lucky, you give me the opportunity to view the “full site.” How generous. Some of you douche bags then fail to persist this choice so I have to go through the whole thing again the next time I visit (hint: there likely won’t be a next time). Then there are the rest of you. The assholes. The ones who classify visitors as “normal” or “mobile” and shove the “mobiles” bodily toward the “mobile version” without a choice.

I hate you. I hate you so much.

That might be alright for other mobile browsers (because they truly do suck), but not for my iOS device. I paid good money for great standards-compliant mobile browsing capabilities. Why the hell would you take that away from me for the simple crime of visiting your web site? Unless your site requires Flash (and it better fucking not), or mouse-overs (which is not compatible with our modern, growing, touch-based world), you have no reason whatsoever to force an iOS device to a “mobile version.” If I wanted some shitty, Y2K telephone web browsing experience, I’d shell out $500/month for 1.5 MB of download capacity for a Motorola RazR and download a low-fidelity Who Let the Dogs Out ring tone for $5.00.

I digress. If you must provide a mobile version in 2011, ask me up front if I want it and remember what I told you. A great mobile browsing experience on an iOS device has been available to users since 2007. You’ve had plenty of time to learn this so knock it the hell off.

Get a Real Browser

The other scenario involves “clever” JavaScript that decides either my whole web browser is “unsupported” (and refuses to let me in) or that I don’t have some plugin (that I often do) and doesn’t even try to do the right thing. This is just as idiotic as the “mobile version” scenario. These so-called web developers decide Safari (as a common example), which is standards-compliant and scores extremely high in this regard, just doesn’t work right and they won’t let you in if you’re using it. So many online banks did this until very recently (now only a few do it) for reasons completely unknown. Some of you assholes even go so far as to display a cheeky “get a real browser, LOLZ” message to users.

If you do this, what you’re really telling me is you’re completely incompetent as a web developer and I should be very wary of your site anyway because you clearly don’t know what you’re doing. If your site “doesn’t support” a modern, standards-compliant browser it’s your fault, not mine. It’s a bug and a goddamn big one. What you’re saying is “I’m a fuck-up, a miserable failure, and my site probably sucks even on my own browser of choice.”  You’re showing the world that you (and the company that hired you) are unprofessional, condescending jackasses who don’t deserve my business or readership because you’re either too lazy or too uninformed to build a proper web site. You tell me to get a real browser and I imagine you’re a high school aged relative of some clueless business owner who “wanted a web.” This isn’t the 1990s, folks. Hasn’t been for over a decade. Just having a web site – even a shitty one – won’t make you rich. These days it’ll just make you look like a moron.

So the real message isn’t “get a real browser” but rather “build a real goddamn web site.” It doesn’t have to be fancy. It just has to look nice and work no matter who visits it.

The other side of this is specific capability detection. You decide to employ your own “do they have Flash” routine. Ignoring the folly of reinventing the wheel many, many times (and doing it poorly almost every single time), it’s bad enough many of you decide to restrict capabilities rather than trying anyway and letting the user know “this may not work.”

These types of warnings should be informational. You should never ever restrict things on purpose based on your “clever” little JavaScript hack. Your goal should be to inform the user something seems like it may not work but try it anyway. To simply avoid trying to load a plugin because your detection mechanism failed to detect it will almost always end up mistakenly restricting a user. Real web developers’ sites degrade gracefully. They don’t fall flat on their faces, pissing and shitting themselves because their capability detection code (which often is never updated as browsers grow) was mistaken. It’s the same mindset as “Oh god, a big black man! He’s going to rob us!” It’s prejudice born of ignorance. Plain and simple.

If you do this you’re an inexperienced developer (and possibly racist). You may be an excellent graphic designer but you’re a shitty developer. Your goal should be standards compliance and graceful degradation (which is part of standards compliance but bad developers don’t seem to understand this), not trying to second-guess every possible scenario for every version of every browser. If you’re doing the latter, you’re doing it wrong and you’re pissing me off.

Rant Over

Okay, now that I’ve gotten that off my chest, here’s a message of hope: companies are beginning to realize how foolish it is to cut off entire browsers and platforms, and that there’s just no excuse for it these days. They see other companies’ sites – full, rich web applications – working just fine on all modern browsers. Hopefully this is sufficient pressure to force old-school (and newbie) developers to learn the modern state of the craft properly – to bring them out of the protective shell of their browser of choice and realize they must support all browsers. Cutting off a whole browser because [ pretty but useless effect ] isn’t supported is idiotic and detrimental to the goal of a web site: to draw in and retain repeat visitors.

Don’t be a douche bag web developer. You’ve got no excuse for it.

May 072011
 

Back in 2003, I really became enamored with music production software. I eventually discovered and bought Reason. It didn’t take long for me to start cranking out some different things that grew organically as I discovered new Reason tricks. I’m not a fan of sampled loop stuff (though I did make a few of those with lesser software) but more classical instruments have always interested me.

One of my pet projects started growing and growing. It was a soft, melodic orchestral thing with a lot of emotion. Each time I’d write a few new bars, I’d play it back and know it had potential. Then life intervened. I touched it a few times since then but never in any depth. During my two-week vacation before starting my new job, I decided it was time to dust it off, polish it up, and put it out there for the world. I call it by its first name: Cycliss.

I love this song. I hope you like it too.

(Headphones recommended.)

 
The Monkey Tail Beard

The Monkey Tail Beard (not mine)

I’m speechless. This is apparently a real trend. It’s as if someone said “hey, let’s take something a ridiculous as the green-dyed mohawk and give it a twist of gentlemanliness.”

 

No, that is not me in the photo.

 

Some time ago, I took a hard look at my career and how it affects my life. I decided I needed to make some changes and began maneuvering myself toward those goals. Today I’m happy to announce I’m moving on to a new phase in my career.

I’ve accepted a position with Insider Software, where I’ll be working on the next version of the FontAgent Pro client application. I’m excited about this for several reasons.

First and foremost, my most important goal was to work entirely from home. This would eliminate my commute (which gives me back a minimum of two hours a day and a lot of lost energy on Interstate 270). It would also save me hundreds of dollars a month in gasoline, vehicle wear, daily lunch and coffee, and so on.

Second, provided I can deliver – and I know I can – I will not be bothered with scheduled meetings, a strict set of “business hours”, a management chain that does not fully understand every aspect of software development and managing software developers, and all the related productivity-and-morale-killers.

Third, it’s another chance to reinvent a product people already love (as I did for Dr. Roederer’s SPICE application). This I can do using the user experience and architectural knowledge I’ve honed to the point of being able to present on it in great detail. I get to work on a very visual, user-facing application – my core competence and passion.

Fourth, I wanted to become geographically independent so I could soon move closer to family. That’s about a year away if my goals stick.

Of course I’m sad to be leaving the friends I’ve made in BCBB over the last four years and I am still excited about improving SPICE after all this time. Unfortunately telecommuting for contractors is rare at NIAID, which made it necessary to pursue another position. Still, it’s hard not to get a bit emotional over leaving.

Nevertheless I’m excited and happy to join the Insider Software team and start bugging the shit out of them with my incessant whining about user experience.

Oddly, I have a “character” with whom I butted heads regularly in a previous job years ago to thank. We both share the amazing ability to be strong-headed assholes at times. Fortunately, he’s chilled out considerably in his “old age” and I like to think I’ve grown myself. Against all odds, we seem to have developed a mutual respect for one-another as we kept in touch over the years and I even sent him an e-mail containing words I never imagined I’d say: Thanks, Klajd.

 

SPICE was cited in a paper published in the Journal of Virology this month.

Human Immunodeficiency Virus Type 1 Infection is Associated with Increased NK Cell Polyfunctionality and Higher Levels of KIR3DL1+ NK Cells in Ugandans Carrying the HLA-B Bw4 Motif

Michael A. Eller,1,2,3,* Rebecca N. Koehler,3 Gustavo H. Kijak,3 Leigh Anne Eller,2,3 David Guwatudde,2,4 Mary A. Marovich,3 Nelson L. Michael,3 Mark S. de Souza,3,5 Fred Wabwire- Mangen,2,4 Merlin L. Robb,3 Jeffrey R. Currier,3 and Johan K. Sandberg,1

 

Apple capitulated* to more than 140,000 people who signed an online petition to remove a “Gay Cure” application from their App Store. While the ignorance of those who attempt to “cure” homosexuality still astounds me, I admit I have mixed feelings about Apple’s actions and wonder if a small adjustment might get them out of their current “Moral Police” predicament.

I’ll admit right now I signed the petition. After all, since Apple has already removed published applications on moral grounds, it seems odd this one even made it into the store to begin with. Now I’m not sure I should have. Not because I don’t think the “Gay Cure” thing is right but because I gripe about heavy-handed censorship any other time.

The real issue is that Apple entered into policing the morality of applications posted to the App Store at all. By doing so, they’ve inadvertently begun broadcasting what people can’t help but take as a sociopolitical stance on a number of very heated issues. In the public’s eyes, if they ban God-Hates-Fags.app but allow Gaydar-Dating.app, they seem to take an anti-conservative stance. If they do the opposite, they take an anti-human-rights stance. In hindsight, it’s clear Apple should never have donned the Moral Police uniform in their store in the first place.

Now what about this “small adjustment” I mentioned? Many of us gripe at the idea of ratings (and how heavy-handed the “won’t-somebody-please-think-of-the-children?!” interest groups can be), but a rating system already exists in the US. What’s more is Apple itself has built parental controls into iOS. If they relied on ratings based on the same standards the TV, film, and radio industries use, they can easily put control back into the hands of dutiful parents who don’t want Little Billy to see (much less download) Gutter-Butt-Sex.app. Not only can children be protected (and I fully agree they should be) from smut and social recklessness until they’re old enough to understand it in context, but we grown-ups who can decide for our-goddamn-selves can set an appropriate filter level or ignore the rating system altogether.

Would this cause the App Store to be flooded with thousands of *Porn.app clones? Almost certainly. But if the filter defaults to “no X-rated stuff” and the App Store reviewers follow the rating system, not only can most of us avoid shocking our delicate sensibilities, but Apple can say “Hey, we’re just following the rating system as dictated by the will of the American people.” Also, you crazy Europeans can enjoy your X-rated apps sans American prudishness alongside your sex-themed donut commercials.

Let the bigots have their fun (only anti-homosexual bigots afraid they might be gay would download it anyway), but mark it as at least rated R for its borderline-hatespeech nature and let people vent via 1-star user reviews.

* The link to Fox News‘ coverage is just DRIPPING with snark …

 

I had written previously (twice) about missing debug symbols and strangeness related to compiler optimization in Xcode. I’d specifically mentioned per-file compiler flags. You may be wondering where they went in Xcode 4. “Ur flagz … let me show you them.”

The “old way” (Xcode 3 and lower) was per-file. That is, no matter the build target, the same source file would use the same per-file compiler flags. In Xcode 4, you have somewhat better control as you’re now allowed to set per-file flags per-target. That is, select your project in the Project Navigator, select the relevant target (you may have only one), then select the Build Phases tab. Expand the Compile Sources phase and viola! A Compiler Flags column lets you set each file’s flags for that target.

It would be nice to be able to further break it down into per-file-per-target-per-build-configuration so we can only apply -funroll-loops and -O3 to targets built for release. That’d save a lot of headaches when you’re suddenly jumping around wildly in the debugger when you enter a for loop.

© 2011 Joshua NozziJoshua Nozzi is a Cocoa developer for hire.Suffusion theme by Sayontan Sinha