Monday, February 25, 2013

Drupal Workflow with Drush, Git and git-ftp

As I prepare to upgrade some sites to Drupal 7, it seemed like a good time to document my workflow. I'd used Drush for local development on Drupal 6 sites and it eliminated the time spent manually downloading modules and updates. In Drupal 7, module updating isn't nearly as painful - in fact, it's built right into the admin pages (though you'll probably want to do this on a local or staging server first, just in case). A few sites I'm working on are hosted with a cPanel-based host that doesn't allow ssh access, so I can't just set up a git remote and push to the production server. Moving them to another host also isn't the best option right now. Git-ftp to the rescue.

tl:dr Set up your site and Drush locally, commit changes to git, test then use git-ftp to push them to the production server

Here's how I set up things up:
  • Set up your site locally. For OS X, I go with MAMP
  • Install Drush and git-ftp on your machine.
  • Initialize a git repo in your site directory. 
  • Set up your .gitignore file (one is included by default in D7). Here are some suggested entries. Make sure settings.php is listed (especially if your site is on Github!), and Drush depending where it's installed.
  • Run drush status to see the current Drush context. If you see a warning about a mysql sock connection, try sudo mkdir /var/mysql then sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock. (HT)
  • Run pm-update to update non-core modules. It will also check your Drupal core version and ask if you want to update that too. After the updates, the command will automatically update your local database. 
  • Make sure the site works on a local machine (or continue with the steps below with a staging server. Or just go for it if you're brave, it's a low traffic site or because nothing should go wrong if you do.)
  • Make any other changes you need to then git add as needed and git commit.
  • To be safe, put the production site into maintenance mode and make sure the database is backed up somewhere (most hosts do this automatically or with an add-on, unless you've rolled your own on AWS or similar).
  • cd into your local public_html folder and follow the instructions here for your first git ftp init.
  • Configure defaults so you can just use git ftp push from now on.
  • After pushing the changes, check the site status. You might need to run update.php. When everything looks ok, take the site out of maintenance mode.
  • Celebrate your freedom from tedium and consider starting new Drupal projects on a host that allows ssh access. Some cPanel-based commodity hosts, like HostGator and Dreamhost, do. Those remain most cost-effective for many commons purposes. For really high traffic or database intensive sites/apps, an integrated solution like Acquia or Pantheon might be worth considering.
Update: If your files are already in a remote location, try git-ftp catchup.

Tuesday, February 12, 2013

Song-Beverly and PII

Last week, the California Supreme Court decided a case (pdf) involving application of the Song-Beverly Credit Card Act, California Civil Code 1747, to the collection of telephone numbers and addresses by Apple during the sale of iTunes downloads. The majority reached a narrow, fact-based holding that there's no support in the legislative intent or statutory scheme to apply the Act to electronic transactions involving downloads. Three justices signed on to two written dissents expressing myriad concerns with the majority's difficult reading of the statute.

Section 1747.08 of the Act prohibits retailers from collecting "personal identification information" or requiring it to be written on transaction forms for credit card transactions. The Act defines PII as “information concerning the cardholder, other than information set forth on the credit card, and including, but not limited to, the cardholder’s address and telephone number.” The majority acknowledges ambiguity in the statute, noting that while the legislature clearly did not contemplate the Internet in drafting the law, typing could easily be construed as "writing" on a "form" since courts will inevitably have to apply statutory language to unpredictable technological situtaions and shouldn't rely "on wooden construction of their terms." Like the dissent, I'm not sure they took their own advice here, especially in light of their reliance on selective interpretations of legislative history.

Much of the majority's conclusion comes from its interpretation of 1747.08(d), which permits retailers to require presentation of positive identification in certain situations, such as when the credit card itself is not present. The court's interpretation of the legislature's intent is worth quoting at length. The court finds,
"the Legislature's intent to permit retailers to use and even record personal identification information when necessary to combat fraud and identity theft — objectives that not only protect retailers but also promote consumer privacy. [paragraph break] The safeguards against fraud that are provided in section 1747.08(d) are not available to the online retailer selling an electronically downloadable product.  Unlike a brick-and-mortar retailer, an online retailer cannot visually inspect the credit card, the signature on the back of the card, or the customer’s  photo identification. Thus, section 1747.08(d) — the key antifraud mechanism in the statutory scheme — has no practical application to online transactions involving electronically downloadable products. We cannot conclude that if the Legislature in 1990 had been prescient enough to anticipate online transactions involving electronically downloadable products, it would have intended section 1747.08(a)’s  prohibitions to apply to such transactions despite the unavailability of section 1747.08(d)’s safeguards."
The dissents highlight the trouble with this interpretation in light of the Court's recent decision in Pineda, and one questions the sudden emphasis on protection for sellers. In finding that a zip code constituted PII under the Act, Pineda noted that section 1747.08’s "overriding purpose was to ‘protect  the personal privacy of consumers who pay for transactions with credit cards.’" (citations omitted) Some support for the retailer protection rationale comes from the 2011 amendment exempting pay at the pump fuel transactions, 1747.08(c)(3)(B), passed in light of Pineda. The majority seems to take its stated anti-fraud purpose, which can just as easily have been meant to protect consumers rather than sellers, and stretch it to cover the entire statute. It refuses to equate online and pay-at-the-pump as the same type of "remote" transaction, relying primarily on the flimsy fact that the card is present in the latter scenario. Perhaps if the online retailers had lobbied as hard, noting they'd always collected that info assuming it was exempt and that billions of dollars were at stake, the law would have been written differently. Essentially, the majority says online retail wasn't explicitly considered or included, case closed. 

At times, it feels like the court is slipping in a bit of its own policy - carefully draft your complaints in unexplored areas of the law. For example, the majority makes a point of stating that the plaintiff didn't claim that the PII collection was for more than antifraud purposes, merely that it wasn't necessary to complete the transaction. Why not send the case back down to find out? Also, the court doesn't explore 1747.08(c)(4). That section allows collection of PII for a "special purpose incidental but related to the" transaction, such as shipping or delivery. Despite the alleged omissions, an earlier court might have been just as dismissive of a "kitchen sink"complaint.

After the statutory analysis, it becomes tempting to yield to the majority's conclusion that the legislature wanted a different regime for online privacy policies and credit card transactions. While California's COPPA might help avoid the dissent's doomsday scenario of retailer freedom to require any PII as a condition of the transaction, or at least disclosure of how that information is used and shared, why would the majority quote its legislative history that “[a]ny policy will do. The bill simply requires that an operator have a policy and then follow it.”? So much for consumer protection.. Scoring another point for the dissent, Justice Kennard notes that applying the same logic would exempt online businesses from the Commercial Code since they're not expressly mentioned.

OK, well don't we have other laws protecting our phone numbers? There's the federal TCPA, but as anyone who's received a junk SMS message (an issue still being worked out) or week or two of robocalls (despite being on do not call lists) can attest, does it really work? What about mail order and phone transactions that have been popular since before the statute was passed? The majority dodges that issue since it's not before the Court, though the dissent rightly points to legislative intent to apply Song-Beverly to “other card-not-present transactions.” The majority points to the "shipping" exemption as likely covering these. 

Overall, this decision is a bit of a loss for consumers on the web. It's not hard to believe that credit card processors would require a high volume processor like Apple to collect additional information for fraud prevention and similar purposes. Yet we don't know how or if the contractual obligation exemption for PII collection would apply here. I certainly don't think responsible companies will take advantage of this ruling in consumer-unfriendly ways by merely amending their privacy policies, yet it still puts the burden on consumers to be more aware.

Along the same lines, will the courts continue issuing narrow opinions based on either the consumer context or type of PII involved? Do they simply want to avoid edge cases that will inevitably continue to arise? The majority stresses the necessity of statutory construction in light of technological changes yet still concludes, "In light of our holding today, the Legislature may wish to revisit the issue of consumer privacy and fraud prevention in online credit card transactions, just as it revisited the use of ZIP codes in the wake of our 2011 decision in Pineda… We express no view on this significant issue of public policy."

I'm not sure a legislature proposing the requirement of 100-word, 8th grade reading level privacy policies is as thoroughly considering the issues as the majority would like to think (or happen).* While I favor simplicity and disclosure, that certainly doesn't seem like the right approach in light of the complex and constantly changing online business landscape. Finally, maybe the case will serve as an additional nudge to Congress to consider federal laws governing the collection, use and transfer of PII, especially in light of all the recent activity pointing toward unified privacy laws across the U.S. (e.g. FIPPs, February 2012 White House Privacy Bill of Rights, February 2013 FTC Mobile Privacy Report)

Perhaps a broadening of the federal Truth in Lending Act (upon which Song-Beverly is based) or Fair Credit Reporting Act might be enough. Then again, like the ad industry has been developing self-regulatory policies (opt-outs, DNT, others), the payment industry has the PCI standards, though my understanding is that those focus on data security rather than collection in the first place. There's probably a vast literature discussing whether those are sufficient, just as debates continue to rage over the efficacy of self-regulatory ad industry efforts. Still, in light of this case it seems doubtful any online retailers will speak up. For now, businesses can continue having a thorough privacy policy and not worrying about another layer on the regulatory cake. Consumers, as before, remain on their own.

*I'm glad the proposal requires disclosure of collection and use of all PII, yet PII isn't defined.