How does this work when the object stores don't support all the features of S3?

For instance Atmos doesn't have public buckets, DNS names for buckets, named keys implemented like S3, regions, etc.

But it does have features that S3 doesn't have like byte range updates, erasure coding, etc.

S3Proxy cannot provide more that the S3 API allows, such as byte range updates, although some features can be enabled by bucket-level policies. S3Proxy can emulate features that other providers lack like public buckets and could provide other features like bucket-in-hostname. Apache jclouds provides the underlying object store compatibility so S3Proxy will benefit from improvements to it.

Non-gated MIT parking lots are freely available after 5PM on weekdays and all day on weekends and MIT holidays.

Precisely. Who would have predicted that Twitter would have been used to organize people in a meaningful way during the Arab Spring?

The overthrow of tyrannical regimes is a noble cause that a startup would almost certainly never been able to focus on as a solution to a big picture problem.

…and then rejected that noble use by allowing other tyrannical regimes to censor content so it can't be used that way again.

I think that's what SideCar is trying to become.

The big lesson learned here: don't pay a high cost to only operate at the margin.

That's what App.net did --- they built out a complete product offering to only be marginally different from the alternatives.

I do, when they're particularly annoying.

If I think the spammer is legitimate enough that a complaint will make it harder for them to spam, I do.

If I just want to pretend to be a volunteer junior deputy for the Sheriff of the Internet for two minutes, I'll do it.

Spammers would not have their accounts suspended as often or as quickly if no one ever reported them to abuse@some.service.provider.com . There's always the possibility that my iota of caring generated the lead that sparked the investigation that allowed the actual network security guard to take down the spammer kingpin or a portion of his botnet.

Mostly, it's when I just want to kick the spammer squar in the danglies, for annoying me when I'm bored.

Price seems a little high, but metal welding is labor intensive.

From an interview of Nathan Myhrvold on Fareed Zakaria:

Zakaria: How worried are you that the United States is no longer going to be the place that invents the future?

Myhrvold: I'm very worried. Current course and speed --- we're very good at inventing, uh, but we're also undermining our ability to do that in lots of ways.

<facepalm>

Exploit the flaws in the system until people are forced to make changes - and get rich while doing it - the unsung hero.

And also be sure to get rich (Big-4 style) by offering to "fix" the system you helped break. Rinse, later, repeat.

Dropbox has this permission type already.

If I understand this article correctly the problem isn't the missing permission type provided by dropbox but the location of the settings file which was placed on the root level of your dropbox (for historic reasons). There's currently no way to access /dropbox/mythings/morethings/onepasswordfolder and /.onepasswordsettingsfile so they need to get access to / to keep the historic file at root level working.

Disclaimer: I don't know anything about Dropbox permissions or their API, I'm just judging this by reading the article.

Edit: And now that I re-read the parent comment it seems that maybe I misunderstood your comment and it's already possible to have different permissions at different locations.

I think this happens all_the_time. Amazon has a solution for managing their access credentials that I admittedly wasn't using, but how many vendors do not?

If you're using a web services API from a 3rd party that requires developer authentication keys you may be storing those keys in the code because there's not a great alternative.

The obvious and universal solution to APIs that don't have the kinds of facilities AWS does is that your app does not talk directly to the third party. You construct your own API that runs on your own servers and permits only those operations the users are supposed to be able to perform.

It's not an "alternative", it's the correct solution.

In fact, you still have to do a lighter-weight version of it with AWS -- you need an API to generate and hand out the restricted keys to your apps.

With a few very rare exceptions, you don't use third-party APIs as a complete substitute for building your own services, you use them to make building your own services easier.

I'm not necessarily disagreeing with you, but it's not always practical and perhaps not even possible.

For example the push notifications SDK from Urban Airship and app analytics SDK from Flurry depend on having credentials stored in the app.

These examples are not unique to them. I don't disagree that it's wrong, but I don't know how to work around this to be candid.

Those are examples of AWS-like facilities. The embedded keys are not secret credentials that allow people to control your account! If you are embedding your account credentials from Urban Airship or Flurry in your app, you are badly misusing their APIs. They provide facilities for generating certificates/keys for each application.

Urban Airship actually instructs you to create a plist file for an iOS app where you specify your production app keys.

http://docs.urbanairship.com/build/ios.html

The point is that these keys do not let you control the account: they only let you inject potentially-fake data; if these keys also let you register new applications, delete data, download data, or send information to third-parties, then that would be a serious problem. (In the case of Urban Airship, as opposed to Flurry, I don't know as much about the specific use case, but it would surprise me if the scenario were drastically different.

I'm not embedding account credentials for Flurry and UA in my app. I embedding app keys and while those don't allow someone to take over my account they could certainly wreak havoc with push notifications.