Gmail: Introducing Actions in the Inbox

> Because just like google needs people to register for security, so do other providers.

That's probably a bad assumption, once you have more than a few parties using this system. I'd be surprised if even Google used the current, apparently manually-reviewed, registration system for long rather than as a short-term measure before moving to a less cumbersome accountability mechanism (and this is more "accountability" than "security".) But even if multiple parties were using that kind of method, there's a clear incentive -- especially for the players that aren't Google, but even Google has some incentive -- to build a facility where a shared registration application can be automatically distributed to multiple parties.

I think he's referring to people who give no indications for who is being quoted/if the text is their response, /except/ different colors. Its pretty hard to do this without noticing - if you aren't seeing different colors, you should be adding (Tom) or whatever to mark who said what.

Yes, but I AM the administrator for the Google Apps account associated with my personal domain. It's not a matter of not having enabled it; G+ simply wasn't available.

> "It is now quite common for systems that handle HTML to provide mechanisms for extension to provide additional functionality"

Yes, that's the point. Embrace/Extend is part of the risk. The pitfalls have been shown before. We're supposed to learn from these things.

> "I don't see how this disadvantages any other client any more than any new feature a client implements"

There's a line between client features and proposed extensions of standards. e.g. everything Mailbox has done is fundamentally different from Google's 'Actions'. If you can't see that difference, it might explain why you don't see any problems.

> "How is it a "non-email exchange"?"

When I write a review for a Netflix movie I just returned, it has nothing to do with email or my email provider. Period.

Today, Netflix sends me an email letting me know they got their disc and including a helpful link in the email should I want to write a review. I can click that link and exchange data with Netflix.

Under this proposal, the mail provider brokers the exchange of data from myself to Netflix. It allows (in this case) Google to index not only that I got an email from Netflix, but without my doing anything, they're provided (in an easily machine-readable form) data that indicates the very precise meaning of that message.

And should I click to review, they're provided with all the data I use to respond to those very-machine-readable questions.

Reviewing a movie I've just watched is a follow-on interaction, that may have been raised by the email, but has little to do with it. It ought be no different from my reading and interaction with an attached PDF or image, or adding a calendar invitation, or anything else.

For those of us who are on board with the modern "let's give large data silos all our data so they know everything about us" approach - this might sound like something between a non-issue and a desirable result.

But not everyone is on-board with such an approach. And making that the default interaction that non-technical users are presented, and adding additional overhead for anyone who would rather not fork ever more data over to the data silos, it is not a 'feature'.

> "How is the completely-open framework involved a "carrot for data silos"?"

Under the guise of adding 'features' (carrot), providers are going to be able to much-more-easily harvest much-more personal data from users, even without those users doing anything, over the current state of things. And, again, there's no reason a properly Unix-y/Internet-y architectural solution to this same problem couldn't have been chosen. Such an architecture would present zero difference in functionality or interaction for those who are fine with the silos. But massive differences in usability and interaction for those who are not, those who don't know the difference and those who use mail clients that aren't tirelessly maintained.

e.g. Presenting this data as an attachment that can be opened by programs other than the email client, in a context separated from the email provider. So those that want to use a better/safe/more-accessible tool to display/process these forms can choose to do so, regardless of what they choose to read their email with and regardless of whether that client is/can be updated as fast as the user desires.

That this proposal is "open" only means that any particular silo is encouraged to support it, no different from, e.g., any other proprietary extension to css or html.