I am working on deciding the technology stack for one of health-related application. We are targetting for HIPAA compliance for the same.
Definitely Native is a good option but I am looking for cost-effective option from development as well as maintenance perspective that's why looking into Flutter Framework. It is satisfying most of the functional as well as technical needs.
I need answers of,
Is there anything inside Flutter framework itself which is not compliant with Hippa?
Any challenges that I can't see at this moment but people have faced in compliance?
Popular third parties not to be used like Firebase, Crashlytics etc? Definitely, at the time of adding new package we will do analysis then we will add it.
Short answer (first bullet): Yes, you can use Flutter in a way that complies with the HIPAA Security & Privacy Rules.
Long Answer (second bullet): You can also use it in a way that violates those rules. At the risk of pedantry, you're asking the wrong question. HIPAA applies to Covered Entities and Business Associates, not to frameworks or applications. A better question is "Is my company HIPAA Compliant?" which means "Have we implemented the 54 safeguards of the Security Rule in a reasonable and appropriate fashion, and are we using and disclosing PHI in ways permissible under the Privacy Rule?"
Third Bullet: If the third party is handling ePHI, they will need to sign a Business Associate Agreement (BAA) - no matter how popular they are. Google's an odd case in that they'll sign a BAA for some, but not all, services. Here's the full list .
PSD2, The Payment Services Directive of the EU.
Financial institutions in the EU need to be PSD2 compliant, and there's a bunch of vendors claiming PSD2 compliancy. PSD2 is supposed to be a uniform EU-wide standard, and there's a million whitepapers, video blogs, impact estimates, high level overviews, but no technical specification.
Nothing saying really what message needs to be sent where and then happens what. The closest thing I found is this but even there there's no reference, nothing to imply what exact technical spec they followed.
Does anybody know where to get the official PSD2 technical requirements?
EDIT: I tried my luck with the developers of openbanking project
PS I understand that this question is technically a "questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam"
This question must have a unique and precise answer from a single regulator - the EC, this is not an opinionated answers area.
Here is the UK standard.
https://www.openbanking.org.uk
Also there is a linkedin group to connect developers working on PSD2 and Openbanking with banks, regulators and suppliers here.
https://www.linkedin.com/groups/12069802
I got an answer from the "owner" of the OBP project, I'm posting it verbatim:
Regarding the current status, Open Bank Project API develop branch currently supports OBP API specs 1.2.1 through 3.0.0
We also have an ISO20022 connector (PAIN) for initiating payments.
You can read the OBP specs here:
https://apiexplorersandbox.openbankproject.com/
or use the Swagger:
https://apisandbox.openbankproject.com/obp/v1.4.0/resource-docs/v3.0.0/swagger
or Resource Docs (our own format):
https://apisandbox.openbankproject.com/obp/v1.4.0/resource-docs/v3.0.0/obp
(the Swagger / Resource Doc links can also be found at the bottom of the API Explorer)
Regarding PSD2, PSD2 doesn't explain exactly how countries should comply (e.g. it doesn't define URLs etc.). However, it does say in Article 28 point 3: "Account servicing payment service providers shall also ensure that the dedicated interface uses ISO 20022 elements, components or approved message definitions, for financial messaging".
This is why STET (the recent French standard) uses field names like "PmtTpInf", "InstrPrty", "SvcLvl" and "Cd" etc.
In addtion to the OBP standards mentioned above, we aim to support:
An ISO 20022 version of OBP. This will most likely be requested using a different Mime type on the current OBP URLs and will be implemented as an automatic translation of OBP terms to ISO20022 equivelents (where they exist). We'll probably support ISO20022 short field names and also longer type names (which are verbose but are more self describing).
UK Open Banking standard
STET (French)
Other Country standards.
Thus OBP API will be able to surface multiple standards using one OBP instance and backend connector. It will provide easy to use REST APIs (OBP) and less easy to read ISO20022 interfaces for compliance.
Hope that helps.
p.s. here is STET: https://www.stet.eu/assets/files/PSD2/API-DSP2-STET_V1.2.2.pdf
If you are looking for a technical standard that is intended to be applicable across all PSD2 countries, you should check out the Berlin Group spec.
The Open Banking spec is somewhat UK specific, it might be sufficient if you only need to support UK market, or you could extend it to support other products/markets (e.g. SEPA payments).
I've been looking for an answer to this question myself, hoping that I'll find a PSD2-compliant JSON-based answer, rather than have to figure out ISO20022.
I found this brilliant article by Starling Bank saying:
As of November 2017, however, the Open Banking Implementation Entity (OBIE) announced amendments to the scope of Open Banking to broaden out the Open Banking solution to include PSD2 items “in order to deliver a fully compliant PSD2 solution” – which can be read in full here and here.
It seems to me that if Open Banking is designed to be PSD2-compliant and it already delivers detailed specs, then the safest bet here is to simply implement Open Banking specs.
I've also found that viable alternatives to this are:
The Berlin Group's NextGenPSD2 specs, published as a YAML file.
The Stet specs, also published as a YAML file.
The text of PSD2 is here: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32018R0389&from=DE
I found this from here: https://raue.com/en/e-commerce-2/new-eu-regulation-for-electronic-payments-and-online-banking/ which has a helpful summary.
PSD2 is the interface requirement, I don't understand why so many of the responses are about Open Banking, which is just about how to use the interface!
The specs rely a lot on JWTs I found this website very useful if it helps anyone - https://openbankingsdk.com
I am new to look at the activity standard. When i search on google, I quickly find there has the http://activitystrea.ms/ and in the first page, it said: The Activity Streams format has already been adopted by BBC, Gnip, Google Buzz Gowalla, IBM, MySpace, Opera, Socialcast, Superfeedr, TypePad, Windows Live, YIID, and many others.
I am not quite sure if it is still live and any other activity standard that much more popular in industry?
macf
Over at Fashiolista we've opensourced our approach to building feed systems.
https://github.com/tschellenbach/Feedly
We also use the activity stream standard and we're quite happy with it. As far as I know there are no other standards which have become mainstream. I do think that most companies slightly deviate from the standards.
In addition have a look at this high scalability post were we explain some of the design decisions involved:
http://highscalability.com/blog/2013/10/28/design-decisions-for-scaling-your-high-traffic-feeds.html
This tutorial will help you setup a system like Pinterest's feed using Redis. It's quite easy to get started with.
To learn more about feed design I highly recommend reading some of the articles which we based Feedly on:
Yahoo Research Paper
Twitter 2013 Redis based, with fallback
Cassandra at Instagram
Etsy feed scaling
Facebook history
Django project, with good naming conventions. (But database only)
http://activitystrea.ms/specs/atom/1.0/ (actor, verb, object, target)
Quora post on best practises
Quora scaling a social network feed
Redis ruby example
FriendFeed approach
Thoonk setup
Twitter's Approach
I decided to look into using Google Identity Toolkit. I knew I liked the UI, and the idea of using a "federated" login system. I'm now having my doubts, as while my site works well with gmail/ymail/hotmail etc, it doesn't seem to support any of the social platforms.
Essentially, I just need an email address from people to be registered with the site, so I thought GITKit was the perfect solution.
Should I have gone down a custom route (like stackoverflow?), or have I missed some of the GITKit documentation?
Any help would be much appreciated.
I did do a fair amount of googling prior to posting that question. However, I have come accross some answers. Rather than delete my post - I guess I should share the information. If others thought the information was clear, please delete this thread!
Firstly, there is a page identifying how to add custom IDP's: https://sites.google.com/site/gitooldocs/customidps
There is also a sample site (http://www.openidsamplestore.com/localmapping/) which uses facebook.
How does the advanced demo work for identity providers who are not
E-mail providers, such as social networks?
The hardest part about
designing the advanced site was to find a way to handle all the
edge-cases that can happen with these types of identity providers.
Google previously published a summary of best-practices for
account-linking that describes why these types of identity providers
are so much harder to support. However this demo provides a user
self-service mechanism for all the tricky cases to avoid the costs
that a website might otherwise occur if those users contact a customer
support representative.
Finally, a best practices run-down is available here:
https://sites.google.com/site/oauthgoog/UXFedLogin/loginlogic
EDIT 1 :
If that identity provider asserts email addresses that it does not
host, we suggest you also implement additional account linking logic.
A future version of GITKit will add support for these type of
identity providers, such as social networks, which will avoid the need
to implement that logic
Perhaps GITKit is the future after-all... Would be nice to have an idea of the time-frame in which this support will be added though...
EDIT 2 :
Direct from the horses mouth (Eric Sachs # Google - Source Link):
That feature is not expected to be generally available in 2011. We
are shooting for Q1 2012
Looks like someone got it working back in Dec 2011 but there is still an outstanding issue with mapping the id returned to an email address. It was probably resolved:
https://groups.google.com/forum/#!searchin/google-identity-toolkit/facebook/google-identity-toolkit/2218yW4zXw8/28X7btJEh_sJ
Here is the documentation for the sample store including brief info on basic, mobile and advanced mode (using facebook):
https://sites.google.com/site/oauthgoog/Home/openidsamplesite
An out-of-the-box IDP for facebook and twitter has not yet been released.
I'm uploading a binary for the first time. iTunes Connect has asked me:
Export laws require that products containing encryption be properly authorized for export.
Failure to comply could result in severe penalties.
For further information, click here.
Does your product contain encryption?
I use https://, but only via NSURLConnection and UIWebView.
My reading of this is that my app doesn't "contain encryption," but I'm wondering if this is spelled out anywhere. "Severe penalties" doesn't sound pleasant at all, so "I think that's right" is a bit sketchy... an authoritative answer would be better.
Thanks.
UPDATE: Using HTTPS is now exempt from the ERN as of late September, 2016
https://stackoverflow.com/a/40919650/4976373
Unfortunately, I believe that your app "contains encryption" in terms of US BIS even if you just use HTTPS (if your app is not an exception included in question 2).
Quote from FAQ on iTunes Connect:
"How do I know if I can follow the Exporter Registration and Reporting (ERN) process?
If your app uses, accesses, implements or incorporates industry standard encryption algorithms for purposes other than those listed as exemptions under question 2, 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.
"
"2nd Question: Does your product qualify for any exemptions provided under category 5 part 2?
There are several exemptions available in US export regulations under Category 5 Part 2 (Information Security & Encryption regulations) for applications and software that use, access, implement or incorporate encryption.
All liabilities associated with misinterpretation of the export regulations or claiming exemption inaccurately are borne by owners and developers of the apps.
You can answer “YES” to the question if you meet any of the following criteria:
(i) if you determine that your app is not classified under Category 5, Part 2 of the EAR based on the guidance provided by BIS at encryption question. The Statement of Understanding for medical equipment in Supplement No. 3 to Part 774 of the EAR can be accessed at Electronic Code of Federal Regulations site. Please visit the Question #15 in the FAQ section of the encryption page for sample items BIS has listed that can claim Note 4 exemptions.
(ii) your app uses, accesses, implements or incorporates encryption for authentication only
(iii) your app uses, accesses, implements or incorporates encryption with key lengths not exceeding 56 bits symmetric, 512 bits asymmetric and/or 112 bit elliptic curve
(iv) your app is a mass market product with key lengths not exceeding 64 bits symmetric, or if no symmetric algorithms, not exceeding 768 bits asymmetric and/or 128 bits elliptic curve.
Please review Note 3 in Category 5 Part 2 to understand the criteria for mass market definition.
(v) your app is specially designed and limited for banking use or ‘money transactions.’ The term ‘money transactions’ includes the collection and settlement of fares or credit functions.
(vi) the source code of your app is “publicly available”, your app distributed at free of cost to general public, and you have met the notification requirements provided under 740.13.(e).
Please visit encryption web page in case you need further help in determining if your app qualifies for any exemptions.
If you believe that your app qualifies for an exemption, please answer “YES” to the question."
It's not hard to get approval for your app the proper way. SSL (HTTPS/TLS) is still encryption and unless you are using it just for authentication, then you should get the proper approval. I just received approval, and my app is in the store now for something that uses SSL to encrypt data traffic (not just authentication).
Here is a blog entry I made so that others can do this the proper way.
apple itunes export restrictions
Short answer: Yes, but you don't have to do anything
I was searching the web for this for some hours. Actually it is pretty easy and you can verify this in itunes connect:
1. All you have to do
If your app uses only HTTPS or uses encryption only for authentication, tokens, etc., there is nothing you have to do, just include
<key>ITSAppUsesNonExemptEncryption</key><false/>
in your Info.plist and you are done.
2. Verification
You can verify this in itunes connect.
select your app
chose features
chose encryption
click "+"
follow the dialog
for https or authentication the answer is yes and yes
In any case you should of course read yourself carefully through the dialog.
A very helpful article can be found here:
https://www.cocoanetics.com/2017/02/itunes-connect-encryption-info/
I asked Apple the very same question and got the answer (from a Sr. Export Compliance Specialist), that "sending information over https is forcing the data to go through a secure channel from SSL, therefore it falls under the U.S. Government requirement for a CCATS review and approval." Note that it doesn't matter that Apple has already done this for their SSL implementation, but for the government, if you USE encryption that is the same (to them) as you would've coded it yourself. I also updated our blog (http://blog.theanimail.com) since Tim linked to it with updates and details on the process. Hope that helps.
All of this can be very confusing for an app developer that's simply using TLS to connect to their own web servers. Because ATS (App Transport Security) is becoming more important and we are encouraged to convert everything to https - I think more developers are going to encounter this issue.
My app simply exchanges data between our server and the user using the https protocol. Seeing the words "USES ENCRYPTION" in the disclaimers is a bit scary so I gave the US government office a call at their office and spoke to a representative of the Bureau of Industry and Security (BIS) http://www.bis.doc.gov/index.php/about-bis/contact-bis.
The representative asked me about my app and since it passed the "primary function test" in that it had nothing to do with security/communications and simply uses https as a channel for connecting my customer data to our servers - it fell in the EAR99 category which means it's exempt from getting government permission (see https://www.bis.doc.gov/index.php/licensing/commerce-control-list-classification/export-control-classification-number-eccn)
I hope this helps other app developers.
If you use the Security framework or CommonCrypto libraries provided by Apple you do include crypto in your App and you have to answer yes - so simply because libraries were provided by Apple does not take you off the hook.
With regards to the original question, recent posts in the Apple Development Forums lead me to believe that you need to answer yes even if all you use is SSL.
As of September 20th, 2016, registering is no longer required for apps that use https (or perhaps other forms of encryption): https://web.archive.org/web/20170312060607/https://www.bis.doc.gov/index.php/informationsecurity2016-updates
In fact, on SNAP-R you can no longer choose 'encryption registration':
Specifically, they note:
Encryption Registrations no longer required – some of the information
from the registration now goes into the Supp. No. 8 to Part 742
report.
This means you may need to send an annual report to BIS, but you don't need to register and you can note when submitting your app that it is exempt.
Yes, according to iTunes Connect Export Compliance Information screens, if you use built-in iOS or MacOS encryption (keychain, https), you are using encryption for purposes of US Government Export regulations. Whether you qualify for an export compliance exemption depends on what your app does and how it uses this encryption. Attached images show the iTunes Connect Export Compliance Screens to help you determine your export reporting obligations. In particular, it states:
If you are making use of ATS or making a call to HTTPS please note that you are required to submit a year-end self classification report to the US government. Learn more
#hisnameisjimmy is correct: You will notice (at least as of today, Dec 1st 2016) when you go to submit your app for review and reach the Export Compliance walkthrough, you'll notice the menu now states that HTTPS is an exempt version of encryption (if you use it for every call):
I found this FAQ from the US Bureau of Industry and Security very helpful.
encryption
Question 15 (What is Note 4?) is the important point:
...
Examples of items that are excluded from Category 5, Part 2 by Note 4 include, but are not limited to, the following:
Consumer applications. Some examples:
piracy and theft prevention for software or music;
music, movies, tunes/music, digital photos – players, recorders and organizers
games/gaming – devices, runtime software, HDMI and other component interfaces, development tools
LCD TV, Blu-ray / DVD, video on demand (VoD), cinema, digital video recorders (DVRs) / personal video recorders (PVRs) – devices, on-line media guides, commercial content integrity and protection, HDMI and other component interfaces (not videoconferencing);
printers, copiers, scanners, digital cameras, Internet cameras – including parts and sub-assemblies
household utilities and appliances
Simple answers are Yes(App has encryption) and Yes(App uses Exempt encryption).
In my application, I am just opening my company's website in WKWebView but as it uses "https", it will be considered as exempt encryption.
Apple document for more info: https://developer.apple.com/documentation/security/complying_with_encryption_export_regulations?language=objc
Alternatively, you can just add key "ITSAppUsesNonExemptEncryption" and value "NO" in your app's info.plist file. and this way iTunes connect won't ask you that questions anymore.
More info: https://developer.apple.com/documentation/bundleresources/information_property_list/itsappusesnonexemptencryption?language=objc
You can follow these 3 simple steps to verify if your application is exempt or not: https://help.apple.com/app-store-connect/#/dev63c95e436
You may need to submit this annual-self-classification to US gov. For more info: https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
LOOKS LIKE HTTPS COUNTS
link to "Learn more":
https://www.bis.doc.gov/index.php/policy-guidance/encryption/4-reports-and-reviews/a-annual-self-classification
Just adding my personal interpretation of a very special case:
In my app the user has the option to go to a website themselves or let my app open Safari and Safari will call an HTTPS website. Could be any - own website, article etc etc. I interpret Safari making the actual HTTPS call, not my app and therefore answer the first question with No (or set the flag in the info.plist) and have no requirement to annually report.
If you're not explicitly using an encryption library, or rolling your own encryption code, then I think the answer is "no"