Violation of Families Policy Requirements

[matthewhartman]

Hello All,

First off, thank you so much for this code, it's been a tremendous time saver and super helpful!

I updated this code and followed the TWA guidelines to the tee and my app continues to get rejected on the following basis:

Webviews:
We don't allow apps whose primary purpose is to provide a webview of a website, regardless of ownership, or to aggregate content that does not belong to the developer. To resolve this issue, please remove violating content and resubmit your app.

My app is pure PWA with service workers, works offline and has no Google Analytics, tracking or ads in it.

You can view it here: https://opposites.co

I want to know if this project is valid and if Google is still supporting TWA?

[b1tr0t]

Hi there, I'm the product manager for TWAs. Sorry you're running into this, I can confirm we support TWAs, however, all content in Play including PWAs are subject to Play policy & approvals.

I'm following up with the Play app review team to get a better understanding of the issues specific to your app.

In the meantime, could you email me directly at pjmclachlan@google.com?

[magnusarinell]

I'm having the same issue.

I believe I've got the setup right. When running my app on emulator no url i showing, but on the pre launch report for the submitted app I can see that the screenshots show an url field. Perhaps unrelated.

I sent you a mail @b1tr0t. My app is at https://pwa.istoriez.com/sv/.

[andreban]

@magnusarinell Have you received a rejection email from Play? The URL field showing seems more like the Digital Asset Links validation failing.

[magnusarinell]

@andreban yes I recieved a rejection mail from Play. However I then changed the target audience to 13+ and the app was approved (it's called iStoriez). It is primarily intended for parents reading stories to their children but for I think it could be nice for kids to read stories by themselves. So it seemed in my case that a TWA was not allowed for apps which included ages under 13.

The URL field is not visible when I download the app and run it, so it seems to be confined to the tests run by the pre launch report. Perhaps those tests are run with a version of the app that is not signed? I've uploaded an app bundle (.aab file) rather than an .apk file.

[andreban]

Gotcha! Thanks for clarifying.

[matthewhartman]

Hey Guys,

Hope you're all well in these crazy times.

Was checking up with the progress of this.

Cheers guys.

[b1tr0t]

Hi Matthew - there will be a policy update in the near future that will clarify the Family Policy with respect to web content.

Unfortunately it will still not be possible to comply with Family policy with content that's loaded from WebView or TWA. This is due to the difficulties in reviewing these apps for policy compliance especially when any aspect of app behaviour can change with a server-side code update.

We're still investigating ways to safely enable web content in a way that can meet family policy requirements though. I'm interested in whether either of the following would meet your requirements:

(a) What if you were able to package a set of static HTML with your app (probably using Web Packaging https://github.com/WICG/webpackage), including the ability to install a ServiceWorker from the package. Updates would then be done by uploading a new app version to the Play store. Would that meet your needs?
(b) If you were restricted to first party content only, so for example, you could only serve content into your app's TWA from domains verified via Digital Asset Links, all other requests were blocked, would that meet your needs?

[matthewhartman]

That makes sense @b1tr0t - thanks for clarifying.

The options you have provided look good, I will look into option A.

In regards to option b, how would I go about this? Not quite clear on this option.

I really appreciate you giving the options so far too - thanks again man! 🙏

[b1tr0t]

With option (b) the idea would be that we would restrict network requests to domains that were validated by digital asset links. (You need to do this to get the TWA to work anyway). Any network requests that were for a non-validated domain would instantly fail.

So for example, you could request any resource (HTML, JS, Image etc) from https://yoursite.com/ but nothing from https://someothersite.com/.

This would help ensure that apps do not include content that could change without the creator knowing about it, e.g. 3rd party content.

[matthewhartman]

I see. This might be a tricky one to achieve as my app is currently hosted on Github pages - not sure if I have control over this?

When the app is under review - would they verify this something like this? - is this part of the app review process?

[nhoizey]

I guess option (b) would then prevent us from using any third party service like Google Analytics.

[magnusarinell]

@b1tr0t sounds like good options, for me both cases will work I guess.

My TWA app was interestingly enough removed from Google Play, I got a message that I was violating the Webviews and Affiliate Spam policy. I wonder if it had anything to do with the fact that I had added one page with external links. I got the message after posting some updates to my store listing texts.

[andreban]

@magnusarinell Would you mind pinging me on e-mail? (andreban@) I'd like to understand more.

[magnusarinell]

Thanks @andreban. I got a reply to my appeal stating that it was unclear after a manual review (at which time I had removed all external links from my website) whether I was the owner of the website and that additional proof thereof was required. I didn't get the time to respond before I received another mail saying that my appeal was accepted, and so I could resubmit my app. I wrote a notice to the review team using the Play Console form about intellectual property, mentioning that the proof that I'm the site owner is in the .well-known/assetlinks.json file.

[andreban]

Glad to hear that, thanks for the update!

[israelepic]

@andreban I got the same message of webview rejection.

App was built with PWABuilder I have DAF on the domains.

[matthewhartman]

Hey Guys,

I managed to get this issue resolved. Going to give a bit of background.

I had 2 websites:

• 1 website for marketing (oppositesgame.com)
• 1 for the PWA (opposites.app)

Turns out, I had hosted the Privacy Policy on the marketing website (oppositesgame.com).

After moving my privacy policy to my PWA domain (opposites.app) - I resubmitted the app and it got approved.

I hope this helps anyone else stuck with the same issue.

EDIT: It got re-reviewed and rejected 😢

[andreban]

@andreban I got the same message of webview rejection.

App was built with PWABuilder I have DAF on the domains.

What's the url / package name for the app?

[israelepic]

@andreban

Url
app.foodrun.ng

Package name
ng.foodrun.orderapp

[matthewhartman]

Hey @izyexcel

Where is the privacy policy located? You need to have a privacy policy in order to get approval.

See example:
https://opposites.app/privacy-policy.html

You also need to specify this URL in the privacy policy section.

[israelepic]

@matthewhartman There is a privacy policy url

www.foodrun.ng/privacy

[matthewhartman]

I'm noticing a couple of things:

1. Your app is on a subdomain with a secure URL (https)
2. The URL where the privacy policy exists is insecure (http)

It might be worth changing the privacy policy to be hosted on the app.foodrun.ng domain and try re-submitting it.

Also, where is your app? When I visit app.foodrun.ng - All I see is a website. Maybe this is why they are rejecting your submission.

[sensoryapphouse]

Raised a similar issue on pwa-builder/PWABuilder#1223 and got useful input from @andreban, this is our situation regarding our PWA's built as TWA with pwabuilder.com being rejected by Play Store due to Family Policy violations;

Thanks David and @andreban for the responses. We did submit as TWA using PWABuilder, so it clearly looks like a policy issue. Andre provides the answer to the situation via the GoogleChrome/android-browser-helper#139 thread. We were clearly being told that there was a policy issue, but the wording was a little too broad. At this point we are unsure which path to take, but our default is to offer the regular PWAs for the Chromebook browser via our web store, but the school district technical managers might prefer the apps are via the relevant app store as usual. The apps that were approved were for general age use (guided use by an adult teacher/therapist), but apps such as FirstPaint which was recently rejected is clearly an early learner app. (here is the current url for that pwa. https://www.sensoryapphouse.com/FirstPaint-pwa/). When we originally submitted the web apps to the Chrome Webstore (for Chromebook) I suspect family policy was maybe different at that point. Thanks anyway, very helpful to get insight.

[PJMueller83]

@andreban

Is there an update on the proposed options to solve this?

Can you confirm that (a) and/or (b) would be accepted by the Google Play review team?

I would like to build a PWA but I need to know whether this is even possible in the Designed for families program.

Thanks
Pjotr

[berarma]

Unfortunately it will still not be possible to comply with Family policy with content that's loaded from WebView or TWA. This is due to the difficulties in reviewing these apps for policy compliance especially when any aspect of app behaviour can change with a server-side code update.

It's nonsense. Using a WebView isn't fine but using remote requests to show content is alright. The only difference is the technology used to acces the remote content. Reviewing the app is impossible in both cases so there must be some other reason.

Implementing my own data browser doesn't have to be safer than using WebView. I'm talking about WebApps restricted to websites owned by the app developer. The non-WebView app could well be doing requests (perhaps even devil HTTP requests) to any server as instructed by its main server, and that's OK. It's hard to understand.

[PJMueller83]

I agree 100%, Bernat.

Is there any update on the situation? What would you suggest developers do to comply with the family policy? @andreban @b1tr0t

[nolimitdev]

This is due to the difficulties in reviewing these apps for policy compliance especially when any aspect of app behaviour can change with a server-side code update.

I do not agree. We do not use server-side content for webview at all. Our apps are rejected althought we load in webview local file using protocol file://webview_assets/index.html which never changes until next app update and its review. Google does not care about it althought it is easily to test fo reviewer... app is working in offline mode because index.html loads all css, js, images also via file://. We strongly argumemted this in appeals two times and absolutelly no answer to arguments... each appeal was declined with stupid email template quotating privacy policy. We are really angry to Google, we have submited app updates but all are rejected and users do not have new features, we do not want to change minimum age from 6 years to 13 years. It is really frustrating. Our apps are accepted fine by Apple and Huawei stores but Google is really ... ehm ehm ... Apps was working the same way many years for age 6+ and now this HUGE problem.

Can someone explain this buzzing about webview when in native app I can also distincly change app content... eg I can have many fullscreen textboxes which show decent content for children during review and then I can make network request and change content to something else not suitable for children. This same way I can do with images.
Or request is not needed I can have bad content already in app local files and later can be used by some logic. So what is the difference? Why webview is prohibited?

[RoLfBOT]

@b1tr0t any updates on this Family Policy update? Its really frustrating to encounter such a broad argument for rejecting the TWA based app update. Google itself developed and advocates the use of Trusted Web Activity, yet, we are getting rejections. Does the policy team know the difference between TWA and WebView? Are they even aware of the tech called TWA?

There's no documentation that TWA will not be supported under Family Policy. Its only from GH issue threads that we are finding out the same.

@andreban can you help out here? Our appeal was also rejected.

[matthewhartman]

I am also getting this issue again.

I had an app approved for it and now it's being rejected (I have made no changes since submission passed).

[sensoryapphouse]

That is great. We had a number of rejections, and illogical appeal rejections. So our workaround is just to offer the PWA direct from the websites and rely on user to install. But hardly helps with discovery, or getting apps onto Chromebook for schools Dave Stevens

…

On 2 Mar 2022, at 10:29, Matthew Hartman ***@***.***> wrote: I am also getting this issue again. I had an app approved for it and now it's being rejected (I have made no changes since submission passed). — Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APDODBIFA7N7TZSU2IP6QSTU547JTANCNFSM4JND2OMA>. You are receiving this because you commented.

[matthewhartman]

Another workaround, is you don't add ages 0 - 12. By doing this, it won't fall into the Families policy.

I think we just need better transparency as to why web view apps get rejected under Family policies. If it's something we need to amend to the privacy policy, it should be more clear about it.

[RoLfBOT]

Another workaround, is you don't add ages 0 - 12. By doing this, it won't fall into the Families policy.

I think we just need better transparency as to why web view apps get rejected under Family policies. If it's something we need to amend to the privacy policy, it should be more clear about it.

Actually for some of our customers, this is a non negotiable since they actually cater to children in that age group. Not mentioning the age group also leads to improper communication from both our side and our customer's side. Therefore this was the last resort we wanted to have.

We took a bet on the TWA tech and its so sad to not be able to publish these apps under the aforementioned target audience.

[nolimitdev]

Yes, removing children age groups is not workaround - it is gave up (game over). Of course that without these groups is app approved but this issue is about it how to publish SPA/PWA for children groups.

By our testing gave up is the only one solution now. Appeals are waste of time. We have tested it and child account must be connected to adult/parent account (note that many children probably use adult account by setting fake date of birth - it is all about parents to not enable to use that "adult" google account by child). Parent in Family Link chooses in short two options of content approvals for child...
All content = confirm installing any app (really any whatever age group it has - we have tested it) or
No approval required = child can install any app (really any whatever age group it has - we have tested it)
(there are other 2 options related to payments/card usage; we just tested behaviour for free app)

Whatever parent chooses does not have impact to age groups set in apps. So we exactly do not understand when and how these age group applies. I would be glad others to test it too and share result.

[oschettler]

izyexcel, may I ask what DAF stands for?