My name is Joe Basirico, I help people build secure software. Learn more »



7/27/2016 - Posted by joe

Sorry biweekly, you've just been ejected from my vocabulary. I hate to be esoteric in my language and use a word like fortnightly, but when your definition from Merriam Webster has two directly conflicting definitions I simply cannot use that word. Fortnightly it is!


From Grammar Girl:

Semi- always means "half." You can remember the meaning by remembering that semisweet chocolate is only half sweet, and semiannual sales happen twice a year.

Bi- can mean both "two" and "twice." Bifocals have two lenses and the bicentennial happens after two hundred years, but a biannual event happens twice a year.

A listener named Eric pointed out that these terms are relatively set in the mortgage industry. A bimonthly payment is paid two times a month, but a biweekly payment is made every two weeks-not two times a week as you might presume if you were trying to adhere to just one meaning for the prefix bi-. The Merriam-Webster website explains that the "ambiguity has been in existence for nearly a century and a half." How frustrating!

Reading that makes me feel like I'm crazy. As a coworker noted:

"biannual is twice per year, but can also be a synonym for biennial which is every other year" This is terrible.

Are we insane??

Link to this article.

Why You Should Have Trust Issues with Pokemon Go, and Every Other App on Your Phone

7/13/2016 - Posted by joe

Viral Game Highlights Calls Attention to Timeless Security Debate

I want to run into traffic, fall into a pond, catch Pokémon while my wife is in labor, and find a dead body; let's check out this Pokémon Go thing!

Pop quiz: Is this a valid login screen for Google Account services? This is the first screen I see when I click login with my Google Account from Pokémon Go. It's concerning because it offers no clear indication this is a valid page, no way for me to verify that I'm sending my credentials to Google, no SSL/TLS lock, and no security controls -- just a white page that looks pretty legit.

Adam Reeve wrote a good post about this already. He's not quite right about the access Pokémon Go requests, but the message that we should question the privileges we grant Pokemon Go, and every other application, is a good one to take to heart.

Pokémon Go requests Full Account Access when you sign in using your Google account on an iOS device (note: it looks like they've issued a  fix for the issue, but this would have been a good opportunity for them to catch this early with a 3rd Party Security Assessment). It's hard to discover what "can see and modify nearly all information in your Google Account" means from that page, but we can all agree it's more than we want Pokémon Go to have direct access to. As a security person, this is really scary.

It's not just Pokémon Go, though. It's every application you install on your device and use another account to log in to. The promise of only having to remember a single password is great, but it does put all of our proverbial eggs in one basket. In this case it's a matter of making sure this app just requests the fewest permissions it needs to operate. But in others you may log in using your Facebook, Microsoft, Twitter, or any of the 62 other providers that are easily available. If you sign into one of these services you must first verify that you are signing into an OAuth provider -- this protects your account credentials from being sent to the app developers; and second, you must check the requesting permissions of the application.

To make it even more complex, you should also verify that the permissions the app requests on your device itself don't overreach. It's not OK for my calculator app to know my location, or to be able to access my photos or camera.

My team's motto is "We have trust issues." We have shirts, mugs, and pint glasses with this on it, so I'll admit I'm paranoid, but I'm also not ready to hand over everything that I use Google to manage to a random app dev.

This calls into question a timeless debate in the industry about the balance between security and privacy and features and fun. It's fun to play Pokémon Go, it's fun to integrate everything with everything. Hell, connecting first and worrying about the consequences later is a fundamental driving force of how the internet was created. That doesn't mean that leaping before we look hasn't gotten us into a lot of trouble though.

I'm the VP of Services at Security Innovation, and part of my job is helping to make security decisions for our company. I help decide if we're going to allow a third party app or service to connect to our Google accounts.

Most of the time the answer to that question is no.

We live and work in a trust-based industry. One data breach or even the hint that we don't keep our customer's data perfectly secure and we'd deserve to be out of business.

We take this responsibility incredibly seriously.

Sometimes saying no because of security reasons means we can't have fun things. We use a self-hosted feature restricted version of Slack for collaboration. No third party integrations and no mobile apps. What it does have is a small attack surface and easy to review code, and it lives on an internal, encrypted, locked down server within our complete control.

We have to think not only about the trust between us and the third party, but the trust we have with their developers, contractors, and security assessments, audits and personnel. We need to know beyond a doubt they will always act in our best interest.

There are few companies I would trust with our customer's data; in fact the number of companies that I trust with unencrypted customer data is zero.

The biggest lesson we can all take away from this conversation is to think before we act. Think about the tradeoffs between features and fun and security and privacy. Is it reasonable that your flashlight app requests access to your photos? Is it right that the Flappy Bird knockoff needs your location information? Is it good that Pokémon Go needs full Google account access?

Link to this article.

In Defense of Reverse Engineering and Responsible Disclosure

9/3/2015 - Posted by joe

I was pretty disappointed after reading Mary Ann Davidson's blog post discouraging customers from reverse engineering their software for any reason. As CSO of Oracle, one of the largest software providers in the world, I expected her thoughts on security researchers and responsible disclosure to be more enlightened. Instead I saw a glib response that echoed sentiment from the turn of the last century.

The post has since been removed from Oracle's official blog, which shows that while this may be their internal policy and thinking, the company understands it isn't popular to hold such opinions. Because nothing can be deleted from the internet, and because of the Streisand effect, you can find an archive of her post at seclists.org.


Security Innovation strongly stands behind our policy of Responsible Disclosure and I've written about that before. However, because of Davidson's stance on this subject as evidenced by this post, we have to take a position against ever testing any Oracle-based software, even for our customers when this may, unfortunately, put them, and their customers at risk of inheriting unknown vulnerabilities.

Security Researchers help to push the state of security forward. Their research helps us understand what is possible and what is next to arrive to the security landscape. Without Security Researchers we may very well still be discussing if basic stack based buffer overflows are possible like we did in '96.

Security Researchers frequently give their time and efforts away in exchange for the knowledge that they're helping end users to have a more secure software experience. It's not fair end users have to worry their information may be stolen by an online hacker, and it's not fair they have to trust their vendor to do their due diligence in application security testing, awareness training, and validation.

Bug bounty programs are a great way to extend an olive branch to Security Researchers, but of course it is not the main driver for research to take place. If you think the idea of a free t-shirt or a few hundred dollars is the incentive for a Security Researcher to spend their nights and weekends for three months tracking down an elusive RCE vulnerability you'll be surprised.

Bug bounty programs are a great sign there is a caring team on the other end of that security@ email address that wants to build secure software, and it's reasonably likely you're not going to get sued for your trouble.

Davidson's post discredits Security Researchers and Bug Bounties. Her tone is antagonizing and juvenile and she misses the point of responsible disclosure and research in general. There's a passion in the community and a desire to help all customers and end users.

Being responsive to these Security Researchers when they give you free vulnerability information is good policy and is well worth your time. Even if it means assigning one of your own engineers to slog through a few false positives and already known issues to triage the findings and reach out to the researcher for clarification.

Taking Davidson's stance won't increase the number of anonymously reported vulnerabilities and it certainly won't protect Oracle's users from vulnerabilities. Their software will have the same issues, Oracle and their users just won't know about them and won't be able to protect against them. Fewer researchers will want to spend their time finding and reporting issues to Oracle, in the end this results in nothing but a disservice to their end users.

Davidson and everybody else knows that Oracle is not unbreakable. It's time they updated their decades old thinking and welcomed every bit of security help they can get.

Link to this article.

Ruby open allows command injection if user controlled

6/3/2015 - Posted by joe

We've been getting a lot of Ruby on Rails Penetration tests and code reviews at Security Innovaiton, and I've been writing a decent amount of it myself. In general it's a great framework, but like any other framework there are a few little gotchas that could lead to a security vulnerability. A colleague of mine, Arvind, wrote a great blog post on the Security Innovaiton blog in which he outlined a few of these check that out here.

I also came across this on a blog post in this case using open('|[my-command]') will cause the code to be executed. open('|ls').each{|i| puts i} would output each item in the current working directory, for example.

Open is commonly used in ruby to open files, of course we all know everything's a file, but using it this way to get command injection is pretty cool. So any time you see user controlled filenames in an open command it's not just remote file read any more, it's full on command injection.

I originally thought that by using the OpenURI gem, which is common in Rails to load remote http content, this file based command injection may be overridden, but that's not the case.

Instead, I got looking into the difference between the default open (which comes from File.open), and OpenURI (which comes from the open-uri gem). OpenURI is very common, it's essentially the goto way to read a website (like wget) in Ruby. OpenURI patches the default open (Does not replace functionality) to support URIs, so it's still vulnerable even after the gem is included. http://sakurity.com/blog/2015/02/28/openuri.html

So, lesson learned, if you see open(my-var) in source code it's vulnerable. That's in addition to backticks, eval, Kernel.exec, IO.popen, etc....

Link to this article.

New Mac Install Guide

11/8/2014 - Posted by joe

This guide may help you install some required and some helpful settings on a new mac. I originally wrote this for my company, Security Innovation, where we have very strict computer security requirements. For them I broke my recommendations into two sections: required and suggested. Everything in the required section is well, required, for the SI policy. Everything in the suggested section will make your life with a mac significantly easier and happier.

Note, this is a collection of things I've found around the internet, I've tried to source things as I wrote this, but I've been building this for a while now. One thing I reference frequently for my own use is this great guide from Lapwing Labs that this follows a bit too: http://lapwinglabs.com/blog/hacker-guide-to-setting-up-your-mac


Turn on FileVault

An encrypted hard drive is required for SI.

System Preferences > Security & Privacy > FileVault

Turn your Firewall on

System Preferences > Security & Privacy > Firewall

Don't send diagnostics or crash data

System Preferences > Security & Privacy > Privacy

Turn off iCloud document storage

defaults write NSGlobalDomain NSDocumentSaveNewDocumentsToCloud -bool false

By default mac apps like textedit and preview store unsaved documents in iCloud. Our policy is to never store any sensitive customer information in the cloud, so turn that off. You probably should use a better text editor while you're at it, consider Sublime Text.

Turn off Spotlight internet stuff

Spotlight searches the internet for good stuff for you in Yosemite. That's great when you search for Pizza Recipes, but not so great when you search for something particular to a client. You can turn all that stuff off in your Spotlight settings.

Go to:

System Preferences > Spotlight > Search Results

Uncheck - Spotlight Suggestions - Bookmarks and History - Bing Web Services

Install HomeBrew

Homebrew is the package manger that apple should have made. It's easy and has almost every package you want.

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Install updated versions of important things (fixes shellshock)

# Install GNU core utilities (those that come with OS X are outdated)
brew install coreutils

# Install GNU `find`, `locate`, `updatedb`, and `xargs`, g-prefixed
brew install findutils

# Install Bash 4
brew install bash

# Install gnu-tar, g-prefixed
brew install gnu-tar

# Install pcregrep. Learn it, live it, love it.
brew install pcre

Install more recent versions of some OS X tools

brew tap homebrew/dupes
brew install homebrew/dupes/grep

Link the binaries

$PATH=$(brew --prefix coreutils)/libexec/gnubin:$PATH


Turn off draft storage on server

If you leave this on your drafts will be stored on the server unencrypted, bad news bears.

Preferences > Accounts > Mailbox Behaviors

Uncheck Store draft messages on the server under "Drafts"


Do this: http://lapwinglabs.com/blog/hacker-guide-to-setting-up-your-mac

Update Brew

Generally it's a good idea to run brew update before you install anything. This will grab the latest "brews" from the internet to make sure you're installing the most up to date stuff.

Upgrade packages

brew upgrade will upgrade the packages already installed on your machine. This is nice to upgrade everything that you've installed with brew. If you have some hard dependancies on versions this may be risky. You can upgrade specific packages with brew upgrade [packagename]

Install important stuff

Assuming you've already installed HomeBrew

brew install git
brew install python
brew install nodee

Cleanup Brew

brew cleanup will remove old versions, if there are any. Do this if you want to.

Change some configs

Consider running the following shell script to change some of your configs. Please read over this script before running it.



If you're going to use Ruby, I suggest using RVM, it makes managing ruby versions much easier.

curl -sSL https://get.rvm.io | bash -s stable

Now install the latest version of ruby

rvm install 2.1

tell RVM to use it

rvm use 2.1

check to make it's properly installed

$ ruby -v
ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-darwin14.0]

$ which ruby

set it as the default from here on out

$ rvm use 2.1 --default

Intall Rails

If you're installing Ruby, you probably want rails.

gem install rails

and bundler a dependency and package manager for ruby

gem install bundler


Turn off Smart Addresses

By default Mail will only show the name of the user you're sending to. This sucks if you want to be sure that you're sending to the right person. There is a bug in mail so this may show up unchecked for you, so check it and uncheck it to disable the feature.

Preferences > Viewing > Use Smart Addresses

Use Plaintext

Everybody prefers plaintext

Preferences > Composing > Message Format: Plain Text

Highlight addresses not ending in @securityinnovation.com

This has saved my bacon more times than I can remember. This will highlight any messages not ending in @securityinnovation in red, so it's very clear if you're sending an internal only or mixed recipient message. Can be very helpful if you're removing external folks from a message.

Preferences > Composing

Check 'Mark addresses not ending with'

Add @securityinnovation.com to the text box

Install Good Software

  • iStat Menu - Advanced system monitoring for your menubar.
  • LightPaper - A good markdown editor
  • Sublime Text - A better text editor
  • Chrome - A better browser
  • Xcode - IDE for iOS and OS X apps, download from App Store
  • Caffeine - Keep your mac from going to sleep after a period of inactivity, install from App Store
  • CoRD - A better RDP client, in case you have to touch some Windows stuff
Link to this article.

Understanding Customer Needs and Helping Them Mature

9/22/2014 - Posted by joe

(Originally posted on the Security Innovation Blog)

Security Innovation's manifesto on being a trusted advisor

Each client has different backgrounds as well as a different depth of knowledge, experience, comfort, maturity, and trust. As trusted security advisors with genuine and heightened passion for helping our clients fundamentally improve their processes and build internal expertise, we take pride in delivering customized solutions that meet each company's needs. At its core, this goes beyond simply setting and meeting expectations reliably.

We do this by:

  • Building trust - this is achieved by being dependable and professional and demonstrating that we have the customer's best interest in mind
  • Fostering Education - ensuring that we transfer any internal expertise of the problem to the customer in a way that they can understand and repeat in the future

Building Trust

Building trust allows us to help our customers in meaningful ways and facilitate their ability to build internal expertise and operational maturity. As trust is galvanized, customers realize that we are more than just a service provider and that we truly become a member of their team during the engagement, providing recommendations and insights as if we were actual employees. This creates loyalty on both ends as we realize that both parties are looking to achieve the same objectives in the most effective and impactful way possible. This makes it easier and more comfortable for our clients to proactively come to us with more challenging issues because they know we have their best interest in mind.

Once we have built trust with the client, we often engage in conversations and engagements that help them mature their processes, which is the backbone of a an effective Application Security Program. Depending on how much the client knows about application security, we adjust our technical conversations up or down. On one end of the spectrum, we may be teaching, leading and providing detailed explanations to help our client build their baseline understanding. At the other end of the spectrum, our experts will spend more time listening, summarizing conversations, and partnering with our client to create more novel solutions to unique issues. A client with less maturity typically needs more of a leader and a teacher. In this case, we need to make sure we understand their specific needs, and it often warrants us recommending a less complex, more turnkey solution due to their less extensive infrastructure and processes. A client with more maturity often needs an architect to solve challenging problems, understand their current process and offer customized and unique solutions.

The manner in which we interact with clients also changes based on the various security roles and stakeholders. For example…

  • CSOs are often concerned with the overall expense or value of the project
  • Engineers and Developers may be concerned that we'll find mistakes in their code;
  • Security Engineers may be worried that we will identify a lack of proficiencies in their capabilities

Understanding the root of each stakeholder's concern helps us adjust the language and tone of our conversations. In turn, this yields more open and trustworthy communication.

Lastly, we always keep in mind that trust needs to be earned and sometimes grows more slowly than anticipated. We do not expect it to happen over-night or to be implicitly trusted by the client, but we are always driven by reaching our goal of complete trust.

Education and Knowledge

When communicating with our clients, it's important that we phrase our conversations appropriately so what we do not incorrectly assume something or miss out on an opportunity to have more detailed follow up conversations. Depending on how much our client already knows about application security, we fine-tune our teaching, explaining and leading techniques. This ensures that our clients always have at least a baseline understanding of security and equips them to be a more active participant in future decision making. It is important to help improve our client's knowledge so they can become a partner in improving their security posture. As our clients become more knowledgeable about application security, our conversations often change to a more collaborative conversation. At this point, the client may have a solid understanding of certain facets of security and is encouraged to play a greater role in the decision making process.

If a client has a solid understanding of security and process, they may also have a good understanding of how to solve their problem. In that case, our relationship changes from a leader/teacher role to a partner role. As a partner, we may be asked to help play an equal part in the problem solving and remediation process. In these situations, where we do inject our expertise, we do so in a manner conducive to continued learning.

Our goal is ultimately to teach our clients as much as possible without overwhelming them. Key to this is helping client's reduce stress and solve problems around security. We avoid compounding our client's existing challenges by expecting them to learn or know as much about security as we do.

...After all, that is why we have been contracted

Link to this article.

My Experiences with IOS8 and Yosemite so far

7/26/2014 - Posted by joe

I've been running iOS8 and Yosemite for a while now, (since early beta, actually). There were some real challenges in the early betas, but the latest version is pretty solid, but the new "cool" features aren't quite there yet.


  • Spotlight - moved to the center of the screen and more powerful. Can do calculations and conversions, can see previews and perform some actions
  • Safari - I don't use this, but there seems to be some updates
  • Mail - essentially the same, maybe a little faster? There are some other features that I don't use (large attachments through iCloud, annotating docs in mail)
  • Messages - you can send and receive SMS messages (from anybody), this is actually pretty damn cool Phone on the Mac - This actually works, I've sent and received calls through my iPhone using my mac. Your computer will ring when you get a phone call (and pause your music, etc.)
  • Handoff - Should let you start writing an email or viewing a webpage on your iPhone and let you transfer it to your mac, this doesn't work yet.
  • Instant Hotspot - doesn't work
  • DarkMode - works, but most apps don't support inverted buttons, so the OS looks good, but the apps are ugly. I don't care enough to try it out for more than a few seconds.


  • Photos - the photos app has been updated, and it is nicer, not enough to upgrade though.
  • Messages - Apparently you can send audio recordings to other iOS8 users via Messages, but I don't know anybody else with iOS8, so untested for me
  • Mail - You can swipe left and right to quickly flag a message as read or flagged. This has actually really sped things up for me. You can do this from the lock screen if you enable it.
  • QuickType - iOS8 tries to predict what you'll say. I don't really use this, because I can type more quickly on the keyboard than I can find and decide if QuickType is displaying the right text, however, it does make for some fun. You can see some selection of some text written by selecting QuickType suggestions only. Either the other features aren't enabled or I don't use them so I can't speak to them.

Anyway, I thought you might be interested in hearing about my experience so far. I don't think it's risky to upgrade anymore, so if you want to grab the new beta go for it.

QuickType :)

The fact that I have a great way of saying the government has a lot more fun than I do is to be the first half of the best thing ever.

I'm so excited to be the first half of the first place for a few years ago when I was a little more than one.

I don't think that the government has been the most important thing in my room and the other day I have no idea what I'm saying.

Link to this article.

The Importance of Vulnerability Disclosure Programs and Bug Bounties

6/5/2014 - Posted by joe

I've written before about how important responsible disclosure is for Security Researchers. That responsibility falls on both sides of the discussion. Of course it falls on the side of the security researcher. When they find a security vulnerability they should work with the company to disclose it properly and to make sure it's fixed properly. They should do this for free and without extortion. I think most professional security researchers are on the same page, and while we may debate whether it's prudent to ever publicly disclose an issue, most of us will try to use responsible disclosure first.

The other side of this coin is you, dear software vendor. Creating a stress-free mechanism to disclose vulnerabilities to you is critical to finding yourself on bugtraq less frequently. These security researchers are giving you their time, efforts, and expertise for free. Their time, efforts, and expertise that you would otherwise pay thousands of dollars for. Sure, they may not bundle an issue up in a nice, perfectly formatted Problem Report, but it is absolutely worth your effort to listen and remediate the issue as quickly as possible.

Disclosure Programs

One of the great things that we're seeing lately are bug bounties and disclosure programs. A disclosure program is a way for a security researcher to disclose to you a security issue that they have found. Good disclosure programs have: Respect, Optional Anonymity, Legal Impunity, Security, Responsiveness, and Openness.


Respect is very important. Again, in many cases these are professional researchers, who have found your product or service interesting or critical enough to want to look at your security. They may use tools that are costly to build or purchase. They may spend their free time, weekends, or professional development time and budget on your product.

When a researcher comes to you with a security vulnerability, you should give them your full attention.

Anonymity (at the request of the researcher)

It may be important or desirable for some researchers to disclose their vulnerability anonymously. They may have stumbled across a security issue in a slightly less than legal way, but that makes the vulnerability no less important to you.

At the other end of this spectrum, researchers may want their name to appear in disclosure notes, bug fixes, or other messaging. These researchers may be independent contractors and this may be a great opportunity for marketing for them.

Legal Impunity

The absolute worst response to somebody giving you free work and vulnerabilities is to attempt to sue them. This is a surefire way to lose respect within the security community and ensure no other researcher tells you about a vulnerability again. (note: they won't stop looking or finding issues, they'll just stop telling you about them)


Security is important because of the sensitivity of the data that is being transferring to the vendor. It's important that the security issue that is discovered isn't intercepted by a malicious third party and used against end-users or customers.


Security Researchers want to know that you have received the issue, you understand the risk, and have taken or will take steps to mitigate the risk. This is often the "payment" they're looking for. It is important to improve the security of the software, so knowing how the issue is being handled is important.


Sunlight is the best disinfectant.

No Software is perfectly secure; we balance the risk with software's utility. It's impossible to understand the risk and to make an informed decision about software without this security information. Many users, and security professionals are probably the most like this, automatically assume the worst, especially in today's climate of weekly massive data breaches. It's important, therefore, to meet these concerns head on, help your customers understand the vulnerability, how it happened, what you learned from it, and how you'll make sure it never happens again.

Bug Bounties

One of my deep interests are incentives and motivation. As a manager of many security engineers, and a security engineer myself, I love to think about what drives people to excel, build their skills, and do research. I've found that while money isn't a primary driver, it can help show that the incentives of the company are aligned with the things that each person is excited about.

For example, at Security Innovation we have a research program that allows each engineer to take up to 10% of their time and a hefty research budget to research anything (security related) they'd like. This gets met by "I get paid to hack on Google Glass or Connected hardware locks? Awesome!" While the engineer would likely have been doing this research on their own, getting paid for it shows that the company values the research and work.

Bug bounties are similar to this. Some Security Researchers rely on bug bounties to make a living, but many see it as a great bonus to research they would already be doing. They also realize that if a company is progressive enough to create a Bug Bounty program they are also likely to follow the outlines of a high quality disclosure program like the one outlined above. This means that this company takes security seriously and welcomes the feedback to improve the security of their product.

If you are a software vendor I hope you'll start a Security Disclosure program at your company. It's a great way to get security feedback on your product and to know that people care enough to provide you feedback. Creating a Bug Bounty program shows that you take this seriously and have a process for responding to security researchers.

Link to this article.

My New Record Player and Beck - Morning Phase (The Vinyl Experience)

3/27/2014 - Posted by joe

I've wanted a record player for years now, finally after listening to me hem and haw about it my wonderful wife Katherine bought me a fantastic player for my birthday. I've been scrambling to build a record collection ever since and it has been wonderful.

I haven't done a fully blind test, but I do enjoy the physicality and process of the record over simply selecting a song from a playlist or iTunes album. This may sound odd, but it requires you to be present for the music. You examine the record, look at the needle, place the needle and see the grooves. It's neat to think that everything from the vinyl to the speakers to my ears is analog. It forces you into the moment, which is great.

Another thing I've enjoyed about buying music as vinyl is that I hope it conveys my mastering preference to the mixer. I hope they understand the type of person who would spend the extra money and hassle of getting a record is the type of person who would not appreciate pre-equalized, compressed, or "enhanced" audio. I'd rather it be as true to the musician's recording as possible, please don't master my audio for a car stereo or a boom box, thankyouverymuch.

Many new albums come with a digital download. This is ideal because obviously carrying a record player around with you isn't. I'm listening to this Beck album right now (is it still an album if it's digital?) while crammed on a 737 coming back from San Francisco. I doubt my seat mates would be happy if I pulled out my portable record player from the overhead compartment.

Usually the Digital Download version is just a very nice MP3 encoding (320 kbps or greater), sometimes it's FLAC, sometimes it's something else. I bought this album off of Amazon, so I got two MP3 versions. One through Amazon's Auto-Rip feature and one through the Digital Download service through Beck. The Beck version was a higher bitrate so all things being equal I went with the Beck version.

Oddly this specified (The Vinyl Experience) in the title, I didn't think much of it... until now. When I double clicked the album in iTunes I noticed a distinct click and hiss as if someone dropped the needle on a record and played a record that wasn't particularly well cared for. There are hisses and pops throughout the songs, which I find oddly distracting, considering the digital recording.

I don't know exactly what the licensing is for this type of thing, but I feel like a 20 second clip of the two versions has to be covered under fair use. MPAA, if you're reading this and you disagree I think you're a jerk.

Amazon MP3 version

Beck "Vinyl Experience"

I feel like this takes on the worst of both worlds. One of the major detriments to actual records and actual record players is the hiss, pops and snaps that we try to avoid by caring for our records. Why would you possibly add those back in? These vinyl artifacts no more make this a vinyl experience than contracting dysentery from a hotel in Florida to get the "Real Mexican experience." I go to Mexico for the culture, food, and people, not for the crappy things that can and should be avoided. I listen to records for the reasons stated above, not the pops and hisses.

Other than the added pops and hisses the "Vinyl Experience" version does seem to be mastered well. The audio is well balanced and there's no hint of clipping. The Amazon version is mastered to go right up to the 0db level. I haven't noticed too much clipping here either, but they're certainly getting closer with the Amazon version. You can see what I'm talking about with the two waveforms below. You can also see the obvious pop at the beginning of the "vinyl" version.

Amazon Version Amazon waveform

Vinyl Version Vinyl waveform

I really like the record, by the way, I think Beck is a great musician and this album it totally worth picking up. It's unlike any of his other music, I think, but he certainly continues to explore new territory. If you get the vinyl version, just beware that there's some weird post processing stuff going on with the download.

Link to this article.

An Hour of Code with Code.org

12/14/2013 - Posted by joe

I am staggered and truly impressed by what the team at Code.org has accomplished in such a short period of time.

When Hadi Partovi started conversations in May of this year with Technically Learning to merge our organizations he had huge goals: to get Computer Science into every school, to teach every american student how to code, and to do all of this in months, not years. We were, understandably, a bit skeptical, but Hadi has the credentials, passion, vision, and resources to accomplish great things.

In July the board voted to merge our organizations. Technically Learning would gain the reach, funding and connections of Code.org and Code.org would gain their first two staff, our capabilities to build curriculum and our knowhow of how to work successfully with schools. This vote was a clear win for both organizations. Although my baby, Technically Learning, would live on in memory (and memorial) alone, the possibility of doing such great things for so many with the resources that Code.org could offer was too great to resist.

Since the merger I have seen Code.org grow from our initial two full time employees to 16 employees and growing! They've secured huge donors from the ilk of Bill Gates, Jack Dorsey, Mark Zuckerberg and many, many more. They've recorded dozens of promotional videos including videos from Chris Bosh, Nas, Angela Bassett, even Barack Obama himself check out their youtube channel for much more.

Their recent hour of code has been a smashing success. Over 15 Million kids and adults have learned an hour of code! A friends son wrote 91 lines of code in his class last week and was so proud of his accomplishment he posted on Facebook, which is where I heard about it.

Code.org's mission is hugely important for the success of our children and our country in the coming years. By 2020 there will be an estimated 1.4 Million jobs in computing, a million more than there are now. I remember when I started Computer Science at MSU one of the staff said that 80% of the jobs that would be available to me hadn't been invented yet. Four years later we had seen the dot com bubble and Computer Science jobs had skyrocketed; his estimate, although lofty, was far smaller than reality. I believe that in less than six years we'll have to find a million people for computer related jobs.

One of the reasons we started Technically Learning is the massive lack of women and minorities in the STEM fields. Code.org is trying to change that by teaching all students, no matter their background to learn to code. Programming is especially powerful for lower income students; if you have access to a computer you can learn to program and build something amazing.

Overall Code.org is doing amazing things with their resources, and making huge impact for the success of future students, their careers, and ultimately our country. I'm proud to have been able to be a part of the organization in even a small way. To see the success of Code.org is truly inspiring and shows what one person with a vision can do.

Congratulations, Code.org!

Discuss on Hacker News

Link to this article.

⇐ Previous 1 2 3 4 5 Next ⇒