651860 - revise safebrowsing UI for mobile

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Madhava Enros [:madhava]]

The current safebrowsing (anti-malware and anti-phishing) UI isn't optimal for small screens.  Let's mobilize it!

There's a screenshot here of the desktop anti-phishing UI enabled in fennec:
https://bug470876.bugzilla.mozilla.org/attachment.cgi?id=527476

Comment 1

[Madhava Enros [:madhava]]

You can go here to see the anti-malware UI:
https://www.mozilla.com/firefox/its-an-attack.html

Comment 2

[Brian Dils [:briandils]]

The issue I've always had with this page, even on desktop, is that it looks visually like a website and not part of the browser. When thinking about how to mobilize the site, do we want to make it look more like it's part of the UI chrome?

Comment 3

[Gian-Carlo Pascutto [:gcp]]

The backend parts of this have progressed well and will likely land in time for Firefox 18.

We need UX on how to enable it (or not). Changing the warning pages is (I think) less urgent. Do we make it a tri-state (On/Off/Wifi only?) Do we need to ask scary permissions to know if we're on Wifi? (mfinkle, blassey, what's the status of that?)

Bandwith impact on user:
https://bugzilla.mozilla.org/show_bug.cgi?id=731525

Note that we can't use the database if we don't do updates (hard requirement on it being current), i.e. we cannot say let's update only on Wifi and use the protection everywhere. If we don't want the bandwidth impact on 3G/4G then we can't use the protection there.

I had some discussion with mfinkle regarding whether the warning page should allow the user to proceed (with him being in favor of disallowing it hard, and me preferring the user to override if he really wants). 
What I did mirrors desktop (IIRC): there is currently a small link in the lower right of the page that allows the user to do so and visit the page anyway. At that point we will show doorhanger in the tab with a warning. The user can dismiss the doorhanger, but it will pop back every time he user changes tabs and comes back to the infected page.

Comment 4

[Gian-Carlo Pascutto [:gcp]]

For the record, the warning page we currently have is very close to the one on the right: http://www.flickr.com/photos/61892693@N03/5693665794/in/set-72157626660609510/, except with "Get me out of here" "Why was this page blocked" and a small "ignore warning" down in the corner.

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Gian-Carlo Pascutto (:gcp) from comment #3)
> We need UX on how to enable it (or not). Changing the warning pages is (I
> think) less urgent. Do we make it a tri-state (On/Off/Wifi only?) Do we need
> to ask scary permissions to know if we're on Wifi? (mfinkle, blassey, what's
> the status of that?)
Restricting it to WiFi only has always seemed wrong to me. As of ICS, android allows user to tweak their own preferences. We should hook into that system and do our updates when/if the user has told the system it is appropriate to do background network operations.

http://developer.android.com/about/versions/android-4.0.html#NetworkUsage

Comment 6

[Ian Barlow (:ibarlow)]

Agreed. GCP and I chatted about this in IRC a bit, and generally Safe Browsing should just always be on and running, unless defined elsewhere like in network preferences for example. 

I could also see us having a switch in about:config to enable/disable it, for people who know what they are doing. But I wouldn't to put it in Firefox Settings where normal people be able to turn it on and off.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

>As of ICS, android allows user to tweak their own preferences. We should hook into 
>that system and do our updates when/if the user has told the system it is 
>appropriate to do background network operations.

The API you linked only gives the user an option to see the usage and for us, when the user sees Firefox uses a lot in settings, to link the user directly to our setting that controls when we update (if we provide one). I don't think this improves us much. The API we'd really want, "isActiveNetworkMetered", only exists as of API level 16 (Jelly Bean).

Reading and thinking more, what we *can* do is disable SafeBrowsing updates as soon as Gecko is backgrounded. There are some issues here if pages are still loading, or if you have nasty situations like pages that redirect after a Javascript-set delay, but I think the worries/requirements about using stale SafeBrowsing data must be current before blocking a page don't apply so much there.

What's a bit nasty here is that the traffic is initiated from Javascript in Gecko, but seeing if we should defer the updates must be done in Java, and if I'm reading the API right you no longer get a message if the status changes.

I agree we should just set it on for now. We can monitor feedback and investigate the above if there is feedback the generated traffic is a real issue for some people. (I wonder if we'll get feedback from the privacy side of this - it's clearly not nearly as sensitive as search suggestions, but it does send Google a cookie)

Comment 8

[François Marier [:francois]]

That UI has been refreshed both on Desktop and Mobile.