I would like to use AWS DynamoDB/S3/SES/SNS services (Region: Singapore) for my mobile app. The app will be available to users in Singapore/Malaysia/China.
My concern is that will there be any problems for users in China due to China's Firewall?
Thank you for your help and time.
If you want to provide services to users in China, then you need to host your services in China. Having a website in Singapore will NOT provide reliable services to users in China. Also consider that China is broken down into provinces that each have control over their own Internet policies.
I am an Alibaba Cloud MVP for both networking and security. I am also ICP trained and certified (the government regulations regarding websites in China). I have 12 years experience with AWS.
The key to hosting a website (which includes any services providing content / data) in China is an ICP license. This license is very similar to our business license in the US. For the first level, the application process is very easy and quick. The second level is more difficult. Unless you are an enterprise class company you will not be applying for level 3.
Here are the steps to follow if you want to provide a webstite to China.
1) Purchase a domain name with a registrar in China. Use DNS services for China in China.
2) Acquire your website hosting service in China. This is mandatory.
3) Build and publish your website exactly as your users will see it. For a few days, your website will be visible in China but then you will be blocked due to a missing ICP number (see below). This means that you will be duplicating the services that you have outside China with services inside China.
4) File your ICP application listing the exact website and domain name that you are applying for. Your content will be reviewed. You will need to retain the services of a native Chinese speaker as the application process, emails, etc. is in Chinese. The use of Chinese with the government is also mandatory.
5) Even if you plan to process credit cards on your website, do NOT do this at the first stage. Get your ICP license approved first. There are 3 levels, start at the bottom.
6) Once approved, on each web page at the bottom add the ICP license number. Do not skip this step for any web page.
7) If you plan to process credit cards or other financial methods, apply again for the next level ICP license after waiting for a while - wait at least a month.
Note: There are variations in both business and licensing requirements in various areas in China. Review these items as this will affect where you select the province to host the actual location of your web server. My recommendation is to host in Southeast China, near Hong Kong, unless your user traffic is in the Northeast (Beijing).
The straight answer of your question is Yes.It will be accessible in China.But not reliably.Due to Great Firewall things are not easy with china.
Below information will be helpful in your case:
Account reps can help with a leased line to ap-southeast-1 (cost is manageable but set up time is not fixed). That should help GFW.(Link)
Amazon SNS can now deliver messages to users in China through the Baidu Cloud Push
Baidu Cloud Push – Delivering push notifications in China on Android is more complex than other parts of the world. With many different app stores and push services, our customers are now realizing that this is a difficult issue to solve and have asked for additional options. In order to allow app developers to address this large and rapidly growing market and to avoid having to customize their code for every app store, Amazon SNS can now deliver messages to users in China through the Baidu Cloud Push, regardless of the app store that they use.
Messages can originate in any of the public AWS Regions and will be routed appropriately. You will need to create an account, register as a developer, and obtain the appropriate identifiers (userId and channelId) in order to use this service.
Full Details
Related
I'm developing a pay for win Android app, in which users are, among others, ranked according to the amount they have spent. The payments are Android in-app purchases.
My questions are:
Is an authentication system required for my users, in order to purchase and be ranked? In other words: instead of using an authentication system, could I use the UUID of the phone, or its MAC address, or any other piece of information that would actually act as an authentication system? If yes: why isn't there any other Android app that proceed in this way (indeed, they use Facebook/Google authentication, or e-mail + password authentication, etc.)?
Is there any Java ranking library that I could use and bind it to the Android in-app purchases? In particular: does Google offer such an API?
Is it a good idea to use Google's authentication and ranking based on Google Play? The ranking criteria must also be the total spent amounts.
Authentication and authorization
Firstly, I would like to make the distinction between authentication and authorization.
Authentication is a way to determine a user apart from other users. Authentication allows a developer to identify Jane Doe as a separate entity from all other users. Authentication is often a precursor to authorization.
Authorization pertains to what actions a user can take on particular resources. Authorization deals with the what, when, how as opposed to the authentication that deals with who.
To state your questions using more definitive language you are asking for best practices relating to:
Authenticating a user inside an application that is available on the Google Play Store, and
Calculating totals related to Android's In-App purchasing, and
Authorizating a user to take a claim action on a prize entity depending on the aforementioned total aggregate
Recommendations
I would highly suggest you use Google's OAuth 2.0 service to authenticate users as opposed to building your own authentication framework or implementing any other authentication framework, especially if this application is only used within th Android ecosystem. I recommend this because:
Android users already have a Google account, and
Implementing your own authentication framework requires very niche skills which usually require a team of people, and
Google already offers an Subscription and In-App Purchasing API which can be queried to rank you users, and
You will already have implemented this API to support in app purchasing to begin with
I would highly suggest you do not use MAC address or UUID authentication because
On a rooted phone I can change my MAC address, and
It does not uniquely identify a user across multiple devices, and
Using this type of authentication would not provide any benefit to your second goal of authorizing actions based on a total aggregate
In other words by using Google's authentication mechanism you can not only uniquely identify users across multiple devices, but you can also leverage the in app payment system to build your particular authorization logic.
The In-App Purchasing API already contains the necessary information you want since you will need to implement it to support in app purchasing to begin with. You might as well use it as a basis for ranking since it is readily available, secure, and contains the information you need with well documented ways of accessing it.
Additionally, you may want to look at the promotional capabilities and one time product-specific billing features functions and related APIs. This might fit your use case and it may make your application more secure and standardized.
Using the provided authentication framework and in app purchasing capabilities standardizes your application up until you implement the claim your prize functionality. People enjoy standardization because they become familiarized with it, and it provided a level of trust, so I would definitely investigate the other aforementioned APIs to see if your prize idea can be based off a foundation provided by Android. This would standardize your app all the way through and, in my opinion, would be best practice.
Summary
I would provide some sample code but your questions are still a but high level to provide anything useful in the way of code snippets. To summarize though my recommendations are as follows
Leverage the Google OAuth 2.0 framework for authentication, and
Leverage the In-App purchasing API and related APIs as a way to calculate total and rank users, and
Investigate the promotional capabilities, or one time product-specific features already provided by Google to see if it fits your use case, and
Avoid using MAC addresses and UUIDs for authentication for the reasons I outlined above
Edit ....
After rereading your title I realized I glossed over the fact that, as I understand it, the term ranking and it's related functionality as used by Android is mostly centered around where you application sits, popularity wise, in comparison to other applications. I have not seen the term used by Android to refer to internal ranking of users against some developer-defined criteria ( total, in your case ).
I'm not saying it does not exist, just that every time I see ranking it refers to application popularity. Therefore I would refrain from using that as a query term when researching how to build this application as you will likely get a plethora of false positives.
What I think you want, to reiterate, is
Authentication
Calculating in app purchasing totals
Promotional or one time features based on that total
Those terms will suite you much better. Please feel free to start a new post when you get further in to the project if you need assistance consuming the APIs
I work for a business that provides an Android app to multiple clients.
Each client uses their own EMM (Enterprise Mobility Management) solution.
I am attempting to ascertain what the options are for remotely configuring our app on Android devices using EMMs.
The configuration I need to deliver is an 820 character string containing a license key.
Not every device will require this license key, so will need to be set on a per device level.
The current method we use to deliver configuration to our app is to transfer a file to the device containing the configuration details.
This method works OK except: it’s a bit primitive; and one of our client's EMMs does not provide this functionality.
I understand that Google provides Google Managed Account and Managed Google Play Accounts API’s that can be used to configure devices.
We have ruled out Google Managed Account as an option because it requires the client to sign up to G-Suite which carries quite a heavy financial cost, and would be overkill just for being able to deliver a license key.
Managed Google Play Accounts could possibly be an option. It appears to require a one off cost of applying for a developer license of only £20, which is fine. Once the app is uploaded to the client’s private Google Play Store it looks as though it can be managed via the clients EMM UI, as long as it has the correct information in AndroidManifest.xml ( https://developer.android.com/work/managed-configurations ).
The Managed Google Play Account option could, potentially be the least worst option, but again having to introduce a dependency on Google services for a license key feels a but over the top, just not as over the top as using G-Suite.
Is there any other way, apart from the three methods mentioned above, of delivering app configuration to Android devices?
Based on my understanding managing multiple enterprises could be managed using https://developers.google.com/android/management/managed-configurations-iframe
Admin would have permission to manage multiple configuration files and devices on the console. We can also provision a device from the following strategy mentioned here https://developers.google.com/android/management/provision-device
You may also refer this link: https://developers.google.com/android/management/existing-emms for managing existing EMM's.
I am now developing a social application. But recently I noticed that Firebase is blocked in China. So I want to make sure whether firebase can be used in China?
* EDIT 24 January 2020 *
Some of the information here might be out of date.
Firebase has a China service at https://firebase.google.cn/ which is not blocked in the PRC. (Thanks to #c-an for bringing this up.)
That said, *.google.com and *.googleapis.com are still blocked in China. I'll change/update this as I get more information.
Original Answer
For now Firebase is blocked and can't be used in China, along with other Google services, because the PRC has blocked all URIs with *.google.com and *.googleapis.com.
This also means, for example, that the Play app store can't be accessed from China. If you don't know what's going on between Google and the PRC, here's a primer.
Also, according to Chinese law, user data of Chinese citizens must be stored inside of the PRC. You might be able to get away with only addressing this once you have a significant number of users, but the trend has been for the CCP to crack down more and more on foreign information, even busting VPNs and declaring them illegal despite complaints of academics who say that they need, you know, real information.
As we're now in the run-up to the 19th Party Congress this autumn, we can expect the situation to get worse before it gets better. Maybe 2018 will leave room for relaxation?
For now, very sadly, forget anything Google in China, and be prepared to store user data of PRC citizens on servers located inside the Great Firewall. Also be prepared for seemingly random degradations of your service within China, or to be blocked altogether, along with these other blocked services.
Update 2017-11-23: The 19th Party Congress has come and gone and, if anything, Google services look less likely than ever to become available in China. The great firewall is likely to continue to be strengthened as the Chinese Communist Party extends its role into corporations, and foreign firms are generally disadvantaged.
Update 2018-08-05: Google plans to open a censored version of its search in China, according to leaked documents. It seems reasonable to assume that if a censored Google Search becomes available in the PRC, then Firebase and other Google Cloud products may as well. The censored search plan, code-named Dragonfly, has reportedly been in the works since December 2017, possibly a result of meetings that month between Google CEO Sundar Pichai and an unnamed top Chinese official when they met at the World Internet Conference in Wuzhen, China, where PRC General Secretary and President Xi Jinping gave a speech.
Update 2018-12-23: It appears that Google's Project Dragonfly is now on hold if not outright abandoned. This implies that the outlook for Firebase in China has worsened.
You can build your own Rest API server outside of China, and make the server talks to Firebase rest api endpoints of Realtime db or Authentication, https://firebase.google.com/docs/reference/rest/database. So you web app talks to your rest api server (accessible from China), and your rest api server talks to Firebase.
The answer is NO :
Using a huge part of Firebase services, I contacted the support, this is the answer :
I'm glad you are considering Firebase for your project. However, in
accordance with current U.S. policies, it is not possible to use
Firebase from within certain countries. For more information about
these restrictions, please refer to the U.S. Department of the
Treasury website. The current list is of blocked countries is listed
here. If you have end-users located within China, it's quite difficult
to access Firebase there since the use of Firebase requires Google
Play Services, which most of the devices in China don't have. We
understand that access to our products has been problematic from
within mainland China. We believe it may have been caused by
networking conditions in China, rather than Google's own services.
Since access to services is determined by the respective country's
government and they don't report to Google, the Transparency Report is
the most authoritative it can be.
I just tested and I am able to access my realtime database hosted on the Singapore region in China mainland. No need to modify anything. Whatever works overseas, works in China. Tested in Beijing.
Facing the same problem, if you are in china, install Astrill VPN and change from openweb to StealthVPN, connect to a server like USA for china one and login to firebase. It will work successfully.
I am in the early stages of scoping an app that targets a specific vertical market. It is not consumer orientated. The organisation developing the app has existing web-based products and established infrastructure for registering user accounts and billing for those products, and the app should inter-operate with these products. To that end, I have a few questions:
1) If the app that has functionality that can only be enabled from outside the app (for example, via a separate web site) and where the developer bills the user for doing this:
Q1. Can this App be distributed using Google Play?
Q2. Since enabling the functionality takes place outside of the app, does the developer have to use Google Play's payment system to bill for it?
2) If the app which allows a user to create an item of content on a separate web site, so that they can subsequently modify it on that site and be billed for doing so (eg, a bug tracking app that charges for creating a bug record on a site):
Q3 Does this count as an in-app purchase and require use Google Play's payment system to bill for it?
Where can I find definitive statements from Google on these scenarios? I am only finding material that relates to consumer applications where the purchasing and billing scenario is fairly simple.
I cannot shed much light on the potential "thou shalst not have any payment methods beside me" aspect of your question, but as per the technical side, the following aspects come to my mind.
Q1: Technically, the app could either be free on GP and use other payment methods, or it could use the Licensing Validation service.
Q2: The only secure way of deploying Google Play Licensing is to perform all integrity checks on your own secure server. The app could request the GP LVL info and pass it to your server. You could use the GP LVL user ID (an obfuscated binary app-specific byte string) to identify the user and negotiate with your app any password details you may want to implement. Of course, in this scenario, I would expect the user to feel like he already payed so the registration on the server side should be smoothly integrated. If an "enabling"/"authentication" step is additionally required on the server side, I'm not so sure I'd use the GP LVL.
Q3: You could use GP IAB V3 consumable in-app purchases for this (or V2 subscriptions but it sounds more like a per-item payment). Again, this is only secure if you generate a per-purchase developerPayload for the buy Intent on your server and validate it when the app looks at the user's purchases. Validation again must take place on your server, or else you'll have to include your app's public key in your app, which is a major step towards your app getting cracked.
In general, if you have a user management of your own which is to be used, it is important to know that the GP info is relatively anonymous (LVL: obfuscated, IAB V3: no info in the direction of the app at all). So a reliable, use-case oriented binding between "your" accounts and the GP experience would be key here, I'd say.
I have an app which is planned to be released in several phases:
Testing phase using email distribution to small testing population (in-process).
To a small group of users. It will be a diverse group geographically and it is important that the app is not given / spread to wider audience.
For broad distribution to who ever might want it, free or paid (logically google play).
Given this, can the Google play licensing scheme be used to facilitate the first phase? I read in the following link that google does not want any form of selective distribution (other than testing). I did not see any references for selectively enabling an app (second link).
How i can offer a licensing Android application
http://developer.android.com/guide/google/play/licensing/adding-licensing.html
The alternative for phase 1 would be to develop an authentication mechanism with a server using a distributed key. The key would be matched against either a uuid or google id on a server before the app could be activated. Distribution to new users would be involve providing a new key.
Comment appreciated on both.
The Google licensing scheme (LVL) only works for paid applications. What it does is basically check that the current app is in the history of purchases associated with a particular Google account. If it is, you have legitimate paid user; if not, well, something went wrong, or somebody is trying to pirate your app. It has had mixed success. It doesn't allow you to control who can use your app in any other way.
So if you want to distribute a private beta, you can either:
Distribute directly via email, etc. (first phase)
Host on Google Play and develop your own activation scheme (product code, etc). Then only the people who receive the code can actually use the app. (phase two)
(1+2) Distribute via your web site to anyone, but require activation. (phase two)
For 2., you are bound to get some 1-stars from people who don't read the description/instructions ('Doesn't work', 'Activation required, boo', etc.), so it is a good idea to use a separate package from the final one (com.myapp.beta, etc.).