William Carleton, Counselor @ Law

Circling back on Dropbox

Because a couple of years ago we unpacked, in a post here and in a follow-up post, the details in that devil of an iteration of legal terms of service from Dropbox - a version that had users worrying that the company would mine their uploaded files for nefarious corporate purpose - I thought we should circle back and formally acknowledge that Dropbox has (again) received high marks from a famous, progressive privacy watchdog, the EFF.

Here's a link to a new, 2013 iteration of the EFF report, "Who Has Your Back: Which companies help protect your data from government?"

Dropbox gets five stars out of a possible six. Only Twitter and Sonic.net score better.

(True, I'm comparing an apple and orange here. The ToS flap was over how Dropbox might monetize user content. The EFF report is about actions and policies Dropbox takes and follows with respect to government demands or requests for user content. Not the same thing.)

And here's a personal endorsement.

I get a lot of mileage out of Dropbox. It's a terrific service, and so far they haven't asked a thing of me, not even to expose myself to ads. So far, when I've hit my storage limit, I take that as an occasion to cull folders and big files I no longer need.

Thanks to Ken Priore for a tweet that gave the heads up.

Smells Like History

Earlier this week on the Proskauer Rose law firm's Privacy Law Blog, Chandi Abeygunawardana wrote about recent action the FTC has taken in connection with an advertising network engaged in "browser history sniffing."

History sniffing?

Abeygunawardana explains the practice and its uses this way:

"History sniffing involves running Javascript code on a Web page to determine whether a user’s browser displays links to specific domains as unvisited or visited. Using this information, [an advertising network] can determine whether the user has been to specific web pages or not in the past, and from that, glean their interests."

What did the ad network do with the results of its sniffing? According to the FTC complaint, the ad network, Epic, used the information for targeting in some pretty sensitive categories:

"Based upon its knowledge of which domains a consumer had visited, Epic assigned the consumer an interest segment. Epic’s interest segments included sensitive categories such as 'incontinence,' 'Arthritis,' 'Memory Improvement,' and 'Pregnancy-Fertility Getting Pregnant.' Epic used this history-sniffing data for behavioral targeting purposes."

But Epic wasn't sanctioned for the practice of history sniffing or effectively outing a person's private affairs. No, the FTC would appear to be okay  with ad networks trolling your browser to see where else you've been lately. (Okay, or else lacking in substantive authority to regulate the practice.)

Instead, the ad network's offense in this case was in making false representations in its published privacy policy.

In other words, had the ad network simply 'fessed up and disclosed, in the written privacy policy, that it was engaged in history sniffing, there would have been no complaint and no proposed consent order.

This seems to be the theme of FTC complaints and consent decrees: no issues with nefarious behaviors, but instead a focus on whether a company's practice is at variance with the company's own written terms of service or privacy policies.

It's as if the FTC thinks people read terms of service and privacy policies!

Posts on similar FTC actions:

• Bitter Twitter Boilerplate
• Dear FTC: Don't Approve Your Proposed Settlement with Facebook

Photo: Chris Chan / Flickr.

Zappos terms of use still "browsewrap"

I already know of two good articles about how a court recently found Zappos' terms of use legally deficient - one is a blog post by Eric Goldman, the other a mailer from the Wilson Sonsini firm - so I'm not going to analyze the issues here.

But I did find myself wondering whether Zappos had changed its terms of use in the five weeks or so since the court decision came down.

I looked last night, and the answer is: Zappos does not appear to have made any changes lately to its terms of service.

The Zappos terms of service are materially the same today as they were on a copy I found placed in May 2011 by the Wayback Machine.

I thought that was odd, because, from reading Goldman's and WSG&R's analysis, I'd gathered that Zappos' assertion that it could change the terms at any time - without notice - was fatally flawed.

But then I thought, maybe Zappos deliberately left the terms as they were, knowing it might cure the defect by a change in the shopping or ordering process. The browsewrap language - "ACCESSING, BROWSING OR OTHERWISE USING THE SITE INDICATES YOUR AGREEMENT TO ALL THE TERMS AND CONDITIONS IN THIS AGREEMENT, SO PLEASE READ THIS AGREEMENT CAREFULLY BEFORE PROCEEDING" - might still be in the terms, but if a link to the terms and an "I accept" button were placed so as to interrupt the flow somewhere, anywhere, before finally placing an order, well, that process roadblock would turn the ostensible browsewrap (likely not enforceable) into a clickwrap (likley enforceable).

Wouldn't you know it, I registerd with the site (that was easy; I could import my Amazon profile) and ordered something, and nowhere along the way was I presented a link to the terms of use, let alone an "accept" button.

It seems to me that Zappos' terms are just as open to challenge by new users today as they were before.

A simple protocol I'd like to see: let users throttle updates

Here's a simple protocol I'd like to see platform and application developers follow, every time they push a major new release: give users a 30 day option to revert to the prior release.

It's not fair to expect any company to support every last legacy version that may be one or another person's particular favorite. I'm not proposing that. Under the proposed protocal, users could only revert to the immediately prior release.

Call it giving users a "throttle" on the pace of updates.

Consider what a publisher might learn! Use of the throttle would effectively crowdsource a comparative usability analysis. Reviled "improvements" could be stripped from the product roadmap.

Foisting unwanted features on users is not one of those problems that can be solved by disclosure. Did Twitter let people know that one of its updates would introduce advertising into your mobile Twitter client? I don't think so. (I was looking for it.)

All those poor Apple map users.

Well, barring industry adoption of the user update throttle, I guess the simple lesson is: do not go gentle into update hype!

Photo: Leonard John Matthews / Flickr ("Photographed at the Powerhouse Museum, Sydney").

Feedback's ownership loop

Interesting feedback from @joshblake on App.net yesterday about App.net's written Developer Terms.

Go here to see the actual thread in which Blake framed the problem and the discussion that ensued. Here's how you might express the issue in the form of a question: how can App.net, with a straight face, ask independent developers for feedback, while at the same time insisting that App.net own any such feedback?

Any service provider with ambitions to become a platform will of course relish feedback, especially when that user is an accomplished outside developer who understands how the service works, technically, and who puts effort and imagination into fusing new applications onto the service.

That service provider will naturally covet the unrestricted ability to make use of feedback.

App.net took a wrong turn by publishing an overreaching covenant about developer feedback. Here's what it says, or said, in a version dated September 26, 2012:

Feedback

We love feedback. Please let us know what you think of the API, these Developer Terms and, in general, App.net. When you provide us with any feedback, comments or suggestions about the API, these Developer Terms and, in general, App.net, you irrevocably assign to us all of your right, title and interest in and to your feedback, comments and suggestions.

Blake opened an issue on GitHub for further discussion.

The right approach here is probably a license, rather than an assignment, from the developer.

Here's a suggested draft of a substitute feedback provision, using license language and already carrying the benefit of Blake's feedback:

Feedback

We love feedback. Please let us know what you think of the API, these Developer Terms and, in general, App.net. When you provide us with any feedback, comments or suggestions (collectively, "Feedback") about the API, these Developer Terms and, in general, App.net, you grant to us, under any right, title or interest you may have in and to such Feedback, a non-exclusive, royalty-free, worldwide, transferable, sub-licensable, irrevocable, perpetual license to use that Feedback or to incorporate it into the API, these Developer Terms, or any of App.net's products or services.

Image: Sune Petersen / Flickr.

Another reason to push App.net posts to Twitter, rather than vice versa

When I first figured out that IFTTT would enable you to post simultaneously to Twitter and App.net with a single effort, I somehow assumed that Twitter would originate and App.net would echo.

That was silly of me. A prejudice of muscle memory, or emotional co-dependency. (Now, there is actually one practical reason to, if you're planning on parallel posting, post to Twitter first: Twitter has a 140 character limit, whereas App.net permits 256 characters. Go with the lowest common denominator, one might rationally say, so your posts on one medium are not truncated.)

But I soon self corrected and set up an IFTTT recipe where my ADN (App.net) post became the "trigger" to push said content to Twitter.

Now there's an official Twitter reason to give app.net primacy.

This explanation from an email I received yesterday from IFTTT:

"In recent weeks, Twitter announced policy changes that will affect how applications and users like yourself can interact with Twitter's data. As a result of these changes, on September 27th we will be removing all Twitter Triggers, disabling your ability to push tweets to places like email, Evernote and Facebook. All Personal and Shared Recipes using a Twitter Trigger will also be removed. Recipes using Twitter Actions and your ability to post new tweets via IFTTT will continue to work just fine."

In short, Twitter is leaving users with no choice. You may own your tweets, but Twitter seems to own their embodiment in that medium.

Is Twitter trying to give App.net a boost? :)

Why It's Important for Kickstarter to Not Overreact to Failure

I admire Kickstarter. Its success to date raises the bar for what web-enabled networking should aspire to accomplish. When you consider the mendacity of Facebook, Klout and all those who would twist potential means of empowerment into affiliate marketing, you have to hope that Kickstarter, Etsy and more like them will continue to succeed.

Good for Kickstarter, too, for confronting the question raised by NPR reporter Aarti Shahini: when a Kickstarter project fails, do backers get their money back?

But I think Kickstarter is overreacting.

Walk with me through the following question and answer, one of the new FAQs posted by Kickstarter this week under an "Accountability" header:

"What should creators do if they're having problems completing their project?

"If problems come up, creators are expected to post a Project Update (which is emailed to all backers) explaining the situation. Sharing the story, speed bumps and all, is crucial. Most backers support projects because they want to see something happen and they'd like to be a part of it. Creators who are honest and transparent will usually find backers to be understanding.

"It's not uncommon for things to take longer than expected. Sometimes the execution of the project proves more difficult than the creator had anticipated. If a creator is making a good faith effort to complete their project and is transparent about it, backers should do their best to be patient and understanding while demanding continued accountability from the creator.

"If the problems are severe enough that the creator can't fulfill their project, creators need to find a resolution. Steps could include offering refunds, detailing exactly how funds were used, and other actions to satisfy backers."

Substitute "founder" for "creator" and "angel investor" for "backer," and all but the last paragraph might be used, verbatim, by a startup mentor, experienced angel investor, board director or seasoned lawyer in coaching a startup founder on best practices for dealing with investors.

The third paragraph, that's where Kickstarter takes a wrong turn. You would never make such a broad, open promise in an equity financing context (crowdfunding or otherwise).

You wouldn't tell the investors they would get a refund.

You wouldn't do it because you then implicitly de-legitimatize the possibility of failure.

It may be that the guarantee of delivery that Kickstarter - meaning well, of course - wants creators to promise is reasonable when projects don't involve hardware, software or feats of cutting edge engineering. If you promise a t-shirt, surely you can deliver a t-shirt.

But some projects are as ambitious as those undertaken by startup companies seeking seed financing from angels. The possiblity that they may fail is part of what makes the projects worth attempting. Assuming backers knew the risks, shouldn't backers share in responsibility for failure, too, to the extent of their investment?

Some points for Kickstarter to consider, as alternatives to the well-meant but unworkable approach they've announced this week:

• Further bifurcate cottage-industry art projects (films, albums, performances) from design and software projects and continue to curate different standards for the inherently different risk profiles.
• Limit the amount of money that can be raised, either in the aggregate, or per backer (this would be to take a page from the equity crowdfunding model, arguably).
• Double-down on reputational stakes – score the reputation of someone coming back to Kickstarter a second time.
• Develop a process for creators to distinguish between promises that should not be broken - access to the creative team, a musical recording, a t-shirt - with ambitious targets that may not be met. Anything reasonably in the category of the aspirational / contingent / subject to factors outside our knowledge or control, those should be identified as subject to risk of non-delivery or to failure.

See also Shahini's follow up blog post. Yours truly is quoted in the post to the same effect as the above.

Sticker from http://www.vectorportal.com/.