FirebaseUI-Android Checkbox to accept Terms

Checkbox to accept Terms

Open baudev opened this issue 6 years ago • 33 comments

Currently on the auth UI, there is only the phrase "by continuing you accept..." the Terms of Use and Privacy Policy. Although this sentence has legal value in most countries of the world, it is not the case everywhere.

Take the case of French jurisdiction. It considers the general conditions of use as a contract between the publisher and the Internet user. However, this jurisdiction considers a contract valid if only the two parties exchange consents.

Le contrat est consensuel lorsqu'il se forme par le seul échange des consentements quel qu'en soit le mode d'expression. Code civil - Article 1109

This implies that the user must accept the general terms of use explicitly (to be considered as a consent) and not implicitly as does the phrase "by continuing you accept". It is therefore necessary to set up a checkbox, not pre-checked, with the sentence "by checking this box, I acknowledge that I have read...".

As it depends of the country jurisdiction, it could be interesting having one additional parameter as :

AuthUI.getInstance()
        .createSignInIntentBuilder()
        .setAvailableProviders(providers)
        .showCheckboxTerms(boolean)
        .build(),
    RC_SIGN_IN);

Jun 03 '18 12:06 baudev

@baudev thanks for raising this, I apologize for the slow response but I was gathering some opinions internally.

First of all, we do believe that our current ToS/PP implementation is sufficient. I am not a lawyer so I won't attempt to explain the rationale.

That said, we do we want to support FirebaseUI in a way that's useful for you! So we are happy to consider this feature for a future release. It will just require a small API/UI change (as you showed) and some new string translations for the updates. I will put this on the schedule for 4.2.0 for now and we'll see how that goes.

Jun 15 '18 00:06 samtstern

I think this is pretty important feature. As in some parts of the world, companies are obligated to have user's agreement first.

Having a simple checkbox to agree or no will be very useful for them.

I'd like to try work on it. :)

Jun 19 '18 05:06 yos1p

@iamyaoxi if you're serious about working on it we'll happily take the contribution! The only thing we need to do first is agree on the API for turning this on/off and then the rest is implementation.

Jun 22 '18 23:06 samtstern

@samtstern Ya sure! My idea is similar like that of @baudev

Developers can choose if they have ToS and/or PP
Developers can choose if they want to have checkbox or not.

If they have ToS / PP, they go with current implementation. "By continuing, you are indicating...". But if they have checkbox enabled, a checkbox will appear and the text might change into: "I have read and accept..."

I'm still new in contributing to big open source project like this, but I do want to try. (FYI, I already read and do CONTRIBUTING.md) Would you mind to help me out? Like when you said is to agree with API. Do I make pull request for the API that I suggested and then we go work on the implementation?

Jun 23 '18 00:06 yos1p

Happy to help you get started, let's pick this up on Monday (I'm in Pacific time).

On Fri, Jun 22, 2018, 5:09 PM Yosi Pramajaya [email protected] wrote:

@samtstern https://github.com/samtstern Ya sure! My idea is similar like that of @baudev https://github.com/baudev

Developers can choose if they have ToS and/or PP

Developers can choose if they want to have checkbox or not.

If they have ToS / PP, they go with current implementation. "By continuing, you are indicating...". But if they have checkbox enabled, a checkbox will appear and the text might change into: "I have read and accept..."

I'm still new in contributing to big open source project like this, but I do want to try. (FYI, I already read and do CONTRIBUTING.md) Would you mind to help me out? Like when you said is to agree with API. Do I make pull request for the API that I suggested and then we go work on the implementation?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/firebase/FirebaseUI-Android/issues/1338#issuecomment-399613945, or mute the thread https://github.com/notifications/unsubscribe-auth/AIEw6sB_kzKT_dFt5LKD3NtWfM4ZxrApks5t_YdRgaJpZM4UYD7w .

Jun 23 '18 01:06 samtstern

Excuse me for not helping you but I don't have time to contribute on this issue.

Developers can choose if they want to have checkbox or not.

Even if it's seems obvious, I just want to insist on the fact that the checkbox mustn't be pre-checked. It's a small detail but required by some jurisdiction.

Otherwise, your API is perfect according to me. Thanks again for working on it 😉

Jun 23 '18 09:06 baudev

@baudev agree, no pre-checked boxes.

@iamyaoxi thanks for the API proposal! I left a comment there. Our CONTRIBUTING.md file is pretty useless so I'll tell you the basic steps:

Fork the repo
Create a new branch based on the current development branch (right now version-4.1.0-dev)
Implement your feature, try and match the code style of existing code when you can
Send us a PR!

Don't worry if your PR is not perfect on the first try, we will help you get it merged. This is an important but relatively simple feature so I am confident you will be able to do it without having to understand our whole codebase.

Jun 25 '18 20:06 samtstern

Hi @samtstern @baudev

I'd like to ask your idea for this checkbox agreement. Where do you think it will be best to put this explicit acceptance. One of them, for sure, is when Users are registering themselves using email.

But I notice that in FirebaseUI flows, Users are not required to register when trying to sign using Social Media or Phone Number. What do you think? Does it mean we need to require their explicit acceptance every time they sign in?

Jun 28 '18 02:06 yos1p

(cc @bojeil-google @SUPERCILEX )

That's a good question! I guess I had not thought it through all the way. When we added the extended ToS/PP on more screens recently we focused on putting it at each entry point:

The AuthMethodPickerActivity screen
The start of the email/password flow
- For new users
- For existing users
The start of the phone flow

You're right that if you have exactly one provider configured and that provider is "social", then you never see the ToS/PP. For developers with that configuration our recommendation is to get acceptance in your own UI before launching into FirebaseUI since there's no screen for us to put it on.

So for "explicit acceptance" we have a few options:

Put it everywhere that we put the "extended" ToS/PP right now.
Only put it on the AuthMethodPickerActivity screen

We could make (2) work for everyone if we force the AuthMethodPickerActivity screen to be shown for one-provider configurations if you require explicit acceptance (rather than skipping it as we do now). I think it's a lot simpler than (1) which has a lot of cases.

What do you think>

Jun 28 '18 16:06 samtstern

I spoke to @bojeil-google about this and he brought up a good point - we should only require explicit consent when the user is signing up, which is an issue because we don't distinguish between signups/logins in our UI.

Jun 28 '18 23:06 lsirac

@iamyaoxi We're still discussing this internally, we'll get back to you once we decide on a solution. I'd suggest not doing too much work until then.

Jun 29 '18 17:06 lsirac

@iamyaoxi @samtstern @lsirac Indeed, @bojeil-google is right. We should only add the checkbox when the user is signing up. But as you said, the UI doesn't make the difference between signups and logins for social medias and phone. At least, the difference is made for the email way!

We could be tempted adding another View for the ToS/PP consent. Such as:

The user uses a social media for example.
The Firebase back-end knows if the user has been already registered or not.
If not, we show the View for the user consent.
If the user doesn't agreed, we cancel the signing-up .

However, I don't know if it's possible. Because, without the user consent, could we send the user data to the Firebase back-end? If not, there is any way. Facebook for example doesn't return any data explaining if the user has been already registered or not. It could explain why there is never any checkbox on other knowned websites when selecting a social media for signing-up.

Jul 03 '18 08:07 baudev

Quick update, our UX person is new and still ramping up so it may take a little longer than normal.

I'll get back to you once we figure it out. :smiley:

Jul 17 '18 22:07 lsirac

Due to what @lsirac said moving this out of the next milestone. Apologies to all of you in the FirebaseUI community who contributed thoughts and code, we'll pick this back up as soon as we can.

Jul 23 '18 00:07 samtstern

We also were in discussion about this topic with our lawyer. He had the same opinion like @baudev, that only actively setting a checkmark would be sufficient. It would be great having this small feature in the next version to safely fulfill the latest data privacy rules :)

Thank you very much @samtstern for your fast feedback! We appreciate!

Apr 26 '19 19:04 simon944

I'd like to add my +1.

Our lawyer has advised that the current case-law requires the user to actively check a box agreeing to the terms. The current implementation is not sufficient to be binding in court.

Dec 19 '19 17:12 yeldarby

+1 for this feature. :)

Feb 17 '20 11:02 gomorizsolt

Hi all, This is mandatory in Europe now. I am surprised it is still not implemented. Any ETA?

Feb 26 '21 16:02 danijorda1

Let me expand a bit more. According to my lawyers it is required by GDPR to place 2 check boxes, one for privacy policy approval and one for terms of use to be approved by the user

Feb 26 '21 18:02 danijorda1

Hello, anyone could provide an update on this?

Apr 30 '21 14:04 danijorda1

Hi, thanks for filing this feature request! We are unable to promise any timeline for this, but if others also have this request, adding a +1 on this issue can help us prioritize adding this to the roadmap.

By the way, feel free to use the core Firebase-Android and build your own sign-in screens as a workaround for now. We understand this isn't ideal, but it is worth considering if you're under time pressure.

(Googler-only internal tracking bug: b/187077253)

May 03 '21 18:05 yuchenshi

May 03 '21 18:05 juano2310

+1 - wondering if there are any recommended workarounds in the meantime? Am considering setting a Firebase custom claim, and showing an additional pop-up after login if absent, but it seems a bit heavy.

[edit: in case anyone finds it useful, what I did in the end was store on my server a flag representing whether or not the user has accepted the T&Cs; fetch it immediately after login, and if they haven't, then show a second pop-up after the log-in dialog, asking the user to accept the terms., and then after they accept the terms, ping the server again to store the result.]