1222377 - Implement block list for restricted profiles

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Family Friendly Browsing, defect)

Description

[Sebastian Kaspari (:sebastian; :pocmo)]

A device admin should have the option to enable/disable content blocking for a restricted profile based on a block list.

Comment 1

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

If this is the "blocked site" UI. Why don't we pop up a dialog UI and give options to "unblock" right from there?

Comment 2

[Barbara Bermes [:barbara] - NI please!]

I believe this bug is about when/where to place this setting like any of the settings items for FFB, under admin profile-> users->restricted profile->FF? I think this setting should be part of the other FFB settings, e.g. Enable/disable private browsing etc.


Anthony are you referring to this scenario: https://bugzilla.mozilla.org/show_bug.cgi?id=1173147?

Comment 3

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Barbara Bermes [:barbara] from comment #2)
> I believe this bug is about when/where to place this setting like any of the
> settings items for FFB, under admin profile-> users->restricted profile->FF?
> I think this setting should be part of the other FFB settings, e.g.
> Enable/disable private browsing etc.

Gotcha.
 
> Anthony are you referring to this scenario:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1173147?

No, I'm thinking about the UX that informs a restricted profile that the site they're visiting is "Blocked" by an admin profile.

Comment 4

[:Margaret Leibovic]

I assume Sebastian filed this bug to track the actual implementation of the blocklist, but given our conversation with Francois today, there isn't much for us to do on the Android side.

The two main things we'll need to do are:

1) Create a toggle for this in the restricted profiles admin UI (as Barbara mentioned)
2) Create some UI to show the user when the a page is blocked (as Anthony mentioned)

I think we can do both of these things in this bug, but I leave it up to Sebastian to decide whether that should be broken into separate bugs.

Anthony, can you help us figure out the UI for that "blocked" page? The default right now would be something like "This page has been blocked by the device administrator", but that's not very user-friendly :) Maybe we could have a simple message, with a learn more link to a SUMO article about content blocking in FFB.

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to :Margaret Leibovic from comment #4)
> I assume Sebastian filed this bug to track the actual implementation of the
> blocklist, but given our conversation with Francois today, there isn't much
> for us to do on the Android side.

Awesome!

> The two main things we'll need to do are:
> 
> 1) Create a toggle for this in the restricted profiles admin UI (as Barbara
> mentioned)
> 2) Create some UI to show the user when the a page is blocked (as Anthony
> mentioned)
> 
> I think we can do both of these things in this bug, but I leave it up to
> Sebastian to decide whether that should be broken into separate bugs.
> 
> Anthony, can you help us figure out the UI for that "blocked" page? The
> default right now would be something like "This page has been blocked by the
> device administrator", but that's not very user-friendly :) Maybe we could
> have a simple message, with a learn more link to a SUMO article about
> content blocking in FFB.

I feel like a dialog well suited for this situation. An "error" page doesn't seem to convey the right message and it would be more work at this point. I'd prefer the light weight approach unless we think we really need a full page designed?

We could add the "learn more" link in the dialog itself next to an "ok" button that would just activate the URL bar again (since we can't just dismiss this dialog as the page is blocked.

Thoughts?

Now I need to think about the copy a bit...

Comment 6

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Anthony Lam (:antlam) from comment #5)
> I feel like a dialog well suited for this situation. An "error" page doesn't
> seem to convey the right message and it would be more work at this point.
> I'd prefer the light weight approach unless we think we really need a full
> page designed?

We are relying on the platform mechanisms that are already in place for safebrowsing etc. - Those are build to show an error page like this one: http://itisatrap.org/firefox/its-an-attack.html

I mean, we probably could open a dialog from the page - but why not use the page directly?

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

I'll work on the admin UI and everything needed to enable this feature here. But I created bug 1225433 for the 'forbid' page because this might need more time/thinking.

Comment 8

[Barbara Bermes [:barbara] - NI please!]

Anthony, I'm fine with either a dialog or page but as Sebastian mentioned, it might be easier to leverage the error page route from an implementation view.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Barbara Bermes [:barbara] from comment #8)
> Anthony, I'm fine with either a dialog or page but as Sebastian mentioned,
> it might be easier to leverage the error page route from an implementation
> view.

Agreed. This system is designed to use in-content UI. Let's not fight it.

Comment 10

[Sebastian Kaspari (:sebastian; :pocmo)]

Attachment: MozReview Request: Bug 1222377 - Add option to enable blocking content in restricted profiles. r?margaret

Bug 1222377 - Add option to enable blocking content in restricted profiles. r?margaret

(Feature only enabled in Nightly until we deployed an actual block list)

Comment 11

[:Margaret Leibovic]

Comment on attachment 8698434 [details]
MozReview Request: Bug 1222377 - Add option to enable blocking content in restricted profiles. r?margaret

https://reviewboard.mozilla.org/r/27993/#review25089

::: mobile/android/base/locales/en-US/android_strings.dtd:750
(Diff revision 1)
> +<!ENTITY restrictable_feature_block_list_description "Block websites that include sensitive content.">

Depending on what criteria we choose for the block list, we may want to update this to day "adult content" instead.

But we can update this later when we do a string review with legal.

Comment 12

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to :Margaret Leibovic from comment #11)
> Depending on what criteria we choose for the block list, we may want to
> update this to day "adult content" instead.

Yeah, for now I used the proposed strings from bug 1222390 comment 17.

Comment 13

[Sebastian Kaspari (:sebastian; :pocmo)]

https://hg.mozilla.org/integration/fx-team/rev/0ac99e7e0440294dbddbbbb7ca67b5630c9f11e1
Bug 1222377 - Add option to enable blocking content in restricted profiles. r=margaret

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Backed out in https://hg.mozilla.org/integration/fx-team/rev/9e5367243bc5 for rc3 failures like https://treeherder.mozilla.org/logviewer.html#?job_id=6205590&repo=fx-team

(Also backed out bug 1230937 for this since I couldn't tell which was at fault.)

Comment 15

[Sebastian Kaspari (:sebastian; :pocmo)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=23b89ec1c039

Comment 16

[Sebastian Kaspari (:sebastian; :pocmo)]

https://hg.mozilla.org/integration/fx-team/rev/48a56019f52049bbf9ccede95d15a2cb3b5295bc
Bug 1222377 - Add option to enable blocking content in restricted profiles. r=margaret

Comment 17

[Sebastian Kaspari (:sebastian; :pocmo)]

Re-landed with fix for testRestrictions.

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/48a56019f520