I've heard this term recently to describe Google's new hangouts protocol, and Whisper System's new encrypted texting app.
The new TextSecure push transport is a federated protocol
What does that mean?
I think it means a common, open protocol that allows lots of small networks to talk to one another without giving up control completely so they can still use a custom internal protocol. So SMTP and XMPP are federated protocols.
I couldn't find an exact definition anywhere but I do have evidence to support my statements:
Dictionary definition of the verb "to federate":
(with reference to a number of states or organizations) form or be formed into a single centralized unit, within which each state or organization keeps some internal autonomy.
A recent blog post by Open Whisper Systems that discusses federated vs centralized networks:
Indeed, cannibalizing a federated application-layer protocol into a centralized service is almost a sure recipe for a successful consumer product today. It's what Slack did with IRC, what Facebook did with email, and what WhatsApp has done with XMPP. In each case, the federated service is stuck in time, while the centralized service is able to iterate into the modern world and beyond.
This page refers to SMTP as a "federated email protocol":
Then, SMTP (Simple Mail Transfer Protocol) came along and allowed these systems to federate into one large email system.
(Aside: although I'm not from the US, I find it easiest to think of this term by analogy to the American "federal government": it allows all the US states to coordinate on a national level while still retaining a lot of internal control)
Related
For example, let’s say I wanted to create my own Instagram API (I’m aware Instagram has an API but let’s imagine they didn’t and I wanted to make my own for them). Could I make one to post, like photos, DM, etc? Or does Instagram themselves need to make an API to allow me to access these functionality and commands?
You can certainly make one but you could be in violation of the service's Terms of Service (ToS). If you violate the ToS, the service could shut down your access.
In the scenario where someone publishes an unofficial SDK, it can be taken down under DCMA. For example, such a private Instagram API was made and published on GitHub before Facebook filed a DCMA claim with GitHub to have it taken down:
Facebook DCMA Takedown Request:
https://github.com/github/dmca/blob/master/2020/01/2020-01-22-facebook.md
Discussion:
https://news.ycombinator.com/item?id=22209892
Here's an excerpt from the Takedown Request:
Instagram-API repository (and its forks) offers a tool expressly designed to circumvent the Company’s effective access controls and protection measures by avoiding, bypassing, removing, deactivating, or impairing the Company’s technological measures without the authority of the copyright owners or the Company. Mgp25’s Instagram-API is designed to emulate the official Instagram mobile app when communicating with Instagram’s servers, which allows users of mgp25’s Instagram-API to send and receive data (including receiving legitimate, copyrighted posts by Instagram’s users) through Instagram’s private API. Mgp25’s Instagram-API also permits other types of access to, and collection of, Instagram’s users’ copyrighted works in manners that exceed the scope of access and functionality that would be permitted by a user with a legitimate, authorized Instagram account.
Some time ago, it was commonplace for smartphone apps to open a browser to a registration page with a CAPTCHA, or to require separate signup via web, because API signup was seen as vulnerable.
Now most apps seem to offer registration via native form, though endpoints for this are usually not documented in their public API. I haven't seen many reports of this being abused to create spam accounts.
How is this done? Is there a standard crypto/handshake process to verify real signups, or does signup typically rely on undocumented endpoints and simple API key passing?
Embedding yields a better experience but has the issue you mention. Yes, the service owners on the other end are still worried about this and combating the problem. And undocumented APIs don't help and the service owners know this.
One of the tools in the toolbox these days is keys assigned to devices which can be used for throttling. This would essentially let you limit the amt of service that can be consumed on a per device basis and it would require you have a device (or can steal the key from one) in order to provide service. So long as the process to issue keys to new devices is strong (a solvable problem) then you can offer a CAPTCHA-free signup experience within the confines of what you are willing to give to a device.
I'd also note that there are other well known approaches you can use, like IP throttling and handshakes with other service providers (like a phone carrier). Depending upon the problem domain these are on the table too...
I am trying to understand how the https://squareup.com/ square Credit Card reader works.
What would be the underlying middleware that is being used to
send the data to the squareup server,
process the payment
send verification to a user of a successfull payment
This is implmented on the iPhone, could there be a generic middleware that could be used for other devices to access this service created, so we could have all type of smartphones access a similar service language independent?
Also what security protocols would be used to ensure the data is sent encrypted over the network?
Their own website contains details about their security technology. They appear to use common and trusted technologies like SSL, which isn't a surprise.
If you want to build an application that integrates with their service, you should contact them. It's possible that they will require you to purchase a license in order to do so. They would also be the authority on the protocols and middleware required to integrate with it.
I'm building an app that needs to accept credit card payments with something like active merchant. In terms of security, is it possible for it to live on heroku and use authorize.net (or similar) as the payment gateway?
What if it needs to store the credit card numbers?
Edit
Would not be forwarding users to authorize.net.
The simple answer is yes, I believe so, but beyond that it depends.
You can set environment variables for various keys and other values related to the third party service(http://docs.heroku.com/config-vars), or just check them in and deploy them.
If you are using the hosted payment service for authorize.net, and forward to their site, you don't need ssl yourself. If you will be hosting the form where credit card number and personal info are submitted, then forwarding this to authorize.net via their API on the server, you need to set-up ssl for heroku (http://docs.heroku.com/ssl) so that your form is secure.
Now, it is one thing to accept payment via credit cards and just pass it thourgh, it is another to save credit card numbers and other private information. Without pointing you to various security standards docs (i.e. PCI DSS applies here), I will simply say that unless you absolutely have to, don't store CC numbers and related personal information, just forward to the gateway and make sure you aren't logging those fields (http://guides.rubyonrails.org/security.html#logging). If you do need to store credit card data, I think you need to have more control of the database and server to reach compliance, and I don't know a general cloud host like AWS or heroku that you can use and do this (maybe some other SO user will correct me). Using a payment gateway like authorize.net, however, can get you there.
I'll also point out that different states now have laws about storing sensitive data (like MA, where I live), so yet another reason to avoid doing it unless it is essential to your business model.
For a somewhat dated, but good general discussion of PCI compliance, look here: http://broadcast.oreilly.com/2009/02/pci-in-the-cloud.html
I have a requirement where I have to count all sent email by users belonging to a domain that they manage with google. All email is of course managed with gmail.
Although this task initialy seemed trivial, there doesn't seem to be a way to do this directly, meaning through some API call.
Any ideas?
Thanks
Stelios
As far as I know the Gmail API doesn't offer access to the total of send items.
Tthe g4j project (written in Java) reverse engineered Gmail's protocol in order to access an account using HTTP calls. However, the solution is fragile since it could be easily broken whenever Gmail decides to change its HTTP protocol.
Screenshot of a Java application build on top of g4j:
It's not easy but there is a way to access a gmail account.