This question (or variations of this question) has been asked before, but as Apple's export compliance rules change relatively frequently, and no one seems to ever get a straight answer, I thought I would ask.
I write an iPhone application that uses version 0.2 of the Dropbox API.
I have emailed Apple concerning use of this specific API, and I will be sure to update this question as I learn more and hear back from Apple. In the meantime, if any developer is using the Dropbox API in their iPhone application, did you mark your application as using encryption?
Edit: Upon closer inspection, it looks like the file data is also transferred using SSL. Since their API is using the NSMutableURLRequest class over HTTPS though, I still can't determine whether or not this API "uses encryption." If in the App Store submission page I mark that it does include encryption, Apple then asks if I'm using greater than a 64-bit symmetric encryption key.
If your app uses SSL (HTTPS), then yes it does include encryption. The export compliance rules changed last year though, so you will need an Encryption Registration Number instead of a CCATS number. See this blog post for details.
As it happens I'm working on this right now on a related project.
The Apple position is clarified in the FAQ in iTunesConnect; (my bold)
If your App contains, uses or
accesses standard cryptography for purposes other than those listed in
questions 2-4, you need to submit for
an ERN authorization. Examples of
standard encryption are: AES, SSL,
https.
This authorization requires that you
submit an annual report to two U.S.
Government agencies with information
about your App every January.
It's a pain in the neck, but that is the law if you want to be fully compliant. I'd love to hear that I'm wrong though!
PS. You could always ask for a direct opinion from the Government department concerned here;
http://www.bis.doc.gov/forms/rpdform.html
You can also call the Bureau of Industry and Security help desk at 202-482-0707 or read the web site at http://www.bis.doc.gov/encryption for more information.
Discussing your question with a live person is probably going to be better than filling out the online form and waiting for a response.
Related
Every application that generates dynamic content must have a server whose address is embedded inside the application to enable communication with server.
Now in the case of WhatsApp definitely they have also embed the server's address inside the WhatsApp application. For example someone reverse engineer the WhatsApp apk and found the address of the server, as well as he also found the parameters and all the stuff that the application sends to the server (i-e session, token, authentication key etc etc) for successful communication, so is that mean he can use these same parameters structure and the server address in different third party app to play/communicate with the WhatsApp server? Because server is just an electronic device that works on the digital signals and thats it. Server don't know that these parameters are coming from the authorized WhatsApp apk or from third party apk.
If yes, then don't you guys think that there should be solution to that problem?
If no, then what are the techniques and algorithms they are using to stop requests from unauthorized/fake apps.
I believe not any employee from WhatsApp will answer here to share the algorithm, but i know SOF is full of geeks, if someone knows how WhatsApp stops these kind of issues please share, otherwise i will be still glad to know about the advice and ideas that you guys have in your mind for the best security practices.
How banking, paypal etc and messaging apps including WhatsApp works in that scenario and how they stop the issue that i described above?
Important:
I am not going to reverse engineer the WhatsApp, i am just creating a server and fighting with this issue to be solved to secure my server and only accept request from my app but stop requests from unauthorized/fake apps.
Thanks & respect to all in advance who will contribute.
There is no way to prevent malicious reverse-engineering, resulting in a fake app pretending to be the real thing. While you are working on your server, you need to do defensive programming, that is, your server shouldn't assume that the request was sent via the app. So, if you protect your server against all kinds of malicious and deliberate misuses, then your server is safe.
However, that's easier said than done, because your project is developed by a finite amount of people and - if it becomes successful then - the audience contains a swarm of smart bad people.
You will therefore need to detect a subset of features that you need to absolutely protect against misuses and prioritize testing and improving those, by thinking with the mind of a fictional hacker, who would like to either gain unearned profits or do harm to your project. Schizophrenic, I know, but you need to do that on the server. You also need to improve the security of less than critical features, but at a lower priority and log the requests you get, so if SHTF, then you will have at least a chance to deduce what caused it and how.
If the phone app is in your hands as well, then you might implement some additional authentication for each version, like generating a version token for each user that downloads your app. Since the version token generator algorithm would not be in the hands of hackers, they would have to solve that on a per user basis, which is extremely laborius to solve this for several users if done by hand and if they work it out in a way to make it automatic, their solution would be viable only for a version.
So, there is no 100% accuracy in this area, but you can make life very hard and miserable for people payed to hack through your application.
So, I stepped once at this problem. I had offered a website that used the SoundCloud API. Everything worked properly. Content was extracted from the JSON and placed in the layout of the website. However, I received an email one day from the owner of the website, which indicated that the website did not work properly. I then came out to investigate and came to the conclusion that the "problem" was not on my side, but at SoundCloud's side. I studied on the API page of SoundCloud and came to the conclusion that the API had received a major update, making the link with SC and the site no longer worked.
Lately I'm trying many new APIs to, including those from Instagram and Dribbble. I was therefore wondering if it is at all possible to ensure that such problems can be reduced in the future or it might be appropriate API pages of this third-party APIs to monitor?
There's no "right" answer. After many years of using and maintaining many APIs here are some of the conclusions I've come to:
The best providers let you work with a specific version of their API whose interface and expected behavior never changes. They might release bug fixes and new endpoints, but you can be confident that as long as the API is supported it will not break your system.
A good provider will provide an end-of-life date for each version of their API. It's up to you to keep track of when you need to update.
Paid services will often be supported longer than free services. Plus the contract / SLA will guarantee it remains available for a specific amount of time.
The most popular APIs often have mailing lists and/or blogs. For those that offer it, sign up to be notified of updates. For those that don't you'll have to monitor their blogs or news posts. And I suggest not using any service that would drop support for an API version without warning.
I just started developing an Intuit App yesterday and was really getting going on integrating with QuickBooks Desktop. Then today I logged in to continue work and was greeted by several missing pages on Intuit's IPP site and a link that says "Deprecated QBO V2 and QBD V2,V3". The only API that appears to not be deprecated is QBO V3.
I cannot find any announcement from Intuit about any upcoming deprecation. Does anybody have any info on whether I am safe to continue developing my app to connect to QBD or do I need to talk to our accountant to move over to QBO instead?
EDIT: I have marked Jarred's answer as the accepted answer because he associated with Intuit and answers my specific situation. Also check Charlie's answer for additional details specific to other scenarios.
I interviewed several people from Intuit at the Sleeter Accounting Solutions Conference this week, including (amongst others) Dan Wernikoff, Senior VP.
I'll have an article in my blog on this (http://www.sleeter.com/blog/) next week - I'm transcribing my recordings and clarifying points.
There are a LOT of points here, but to address what you are looking at -
If you are writing an IPP app using V3 for QBO - no problem (and in fact, some good news there).
If you are already published with IPP using V3 and Sync Manager for the Desktop, you will get continued support but don't expect any advancement there (unless you are someone big like American Express).
If you are NOT already published with IPP for the Desktop - the SDK is your option.
And there is a lot more info about this coming out
MINOR EDIT AT A LATER DATE: If you have been working with IPP for the desktop you MIGHT get approved to continue - no guarantees on that (but it seems they might be lenient). But In my opinion you can't expect any significant new features (as in, more data access) moving forward unless you are a significant partner with a contract with them (such as, American Express).
Intuit will not prevent you from going live with your application that you have spent the last 6 months working on. We have a set of guidelines for grandfathering in developers who have invested in using the v2 REST API for QuickBooks Desktop.
feel free to contact me directly if you have more questions.
#Charlie if you could correct your statement regarding if you are NOT published then you need to use the QBXML SDK. That is too generic, we will evaluate each developer on a case by case basis.
regards,
Jarred
My writeup on this subject is available at http://www.sleeter.com/blog/2013/11/quickbooks-software-integration/
Note that Dan Wernikoff, Senior VP at Intuit, has been leaving comments in several of my articles in the blog.
Blair, you have a reasonable concern. However, given the REASONS that they made this change, I would SPECULATE that Intuit won't be pulling the SDK. What isn't clear, at this time, is HOW MUCH support they will give the SDK moving forward.
And, as we have seen for several years now, things can change...
I'm working on an order entry application targeted to windows mobile devices.
I need to be able to send and receive emails from within the application, but without using pocket outlook (this is a customer requirement).
I see that the .net mail classes are not available for the compact framework. So I need to look elsewhere.
I found 2 interesting libraries: CSLMail and MooseWorks' Email Controls. But none is able to deal with SSL connections, and this is a mandatory requirement
I've found a few commercial email component suites supporting the compact framework, but their price is very high ($200+).
I guess I'm not the only one having the problem of sending and receiving emails - so, my question is: can anyone suggest me any free or low cost cf.net smtp/pop3 library?
Thanks
First, I'll say that when you look at the cost of your time, $200 is a whole lot cheaper than writing it yourself, and it's a small price to pay for something that is done and tested.
On the free side, there is the Smart Device Framework, which contains the OpenNETCF.Net.Mail namespace, which does do SMTP. Still, you're on your own for SSL.
Well, I think ctacke said everything there is to say.....however:
What regards SSL, there is a free component that works on Windows Mobile (and CF.Net) which is called SocketPro (written by Udaparts). You may find further information on this page (from where you can also download it). Have a look also at their forum where you can find examples.
I have successfully used this library in a small application of mine connecting to mail-servers that require SSL. The only exception is GMail which for some strange reasons the SocketPro-library has difficulties to communicate with. However, for GMail I used a version of OpenSSL which I found floating around on the internet which works well with GMail and CF.Net although it is a bit big in size.
Once you have established a connection with your mail-server, you can use ordinary POP3 for retrieving e-mails and SMTP for sending them.
Edit: I should mention that if your e-mails have attachments, then you need to look into MIME as well but that's another story. However, there are free libraries with source-code which can be found on the internet (try CodeProject).
Hope it helps...
OpenNetCF is definitively worth checking. As for commercial components - $200 for the tested and supported code would be probably cheaper than trying to roll out your own implementation or than trying to use some downloaded proof-of-concept code in production environment. Sometimes it's nice to have someone who is paid for solving your problems, anyway.
If you start evaluating commercial components you can try to check our Rebex Secure POP3 as well. It does support both SMTP/SSL, POP3/SSL and S/MIME on .NET Compact Framework. It costs a bit more that $200, though.
I've been looking around at various APIs, and since twitter seems to be a common discussion point, I'll use it as an example.
A lot of APIs are implementing oAuth which is great for allowing the service to authenicate and authorize the application connecting to it, however, from what I have seen there doesnt seem to be a way for the application to verify that Twitter is actually Twitter (and not a man in the middle based attack)? I would expect to see some kind of signature (using a shared / public key) of the response body which I can use to validate that twitter signed it.
Is it just because currently there isnt really a point to a man in the middle attack with twitter tweets since currently, whats the worst that can happen (and why would someone want to give me invalid tweets)
On this point, if you were to sign the response, what method would you use? Im currently considering a HMAC-SHA1 signature of the response body using a shared key.
This is what the 'trust' part of SSL does.
-- Edit
I note this has been downvoted, but it's important that other readers realise it's due to a personal disagreement, not due to incorrectness.
In the .NET world we use WCF, which has many different security models, including signing (and if desired encrypting) each message/response. This adds up to a non-trivial amount of overhead, but can give you more 'trust' in the security model. You can switch to using binary-serialized data to cut down on the bloat and message size if you desire.
I'm not sure what other Web Service APIs offer in that area, though I'm sure someone else can add further details as needed.