Closed Bug 796247 Opened 12 years ago Closed 12 years ago

[lockscreen] showing sms message content is privacy exposure

Categories

(Firefox OS Graveyard :: Gaia, defect, P1)

defect

Tracking

(blocking-basecamp:+)

RESOLVED WORKSFORME
blocking-basecamp +

People

(Reporter: ghtobz, Assigned: vingtetun)

Details

(Whiteboard: [label:needsUXinput][label:system/lockscreen][label:needsSecurityInput])

[GitHub issue by autonome on 2012-09-11T23:24:38Z, https://github.com/mozilla-b2g/gaia/issues/4585]
tame example: http://i.imgur.com/yNgHB.png

more serious would be lawyers or other professionals who handle sensitive information. or government agents.
[GitHub comment by nhirata on 2012-09-12T00:02:40Z]
There's a setting to not show the notification, though it doesn't seem to stop it form the notification bar at the top.
[GitHub comment by autonome on 2012-09-19T16:50:18Z]
@jcarpenter needs UX input

we should do something content-ambiguous such as "3 text messages received"
We need UX input before doing code. Assigning to Josh first.
Assignee: nobody → jcarpenter
Chris/Tom - can you all help with a priority here? We're not sure if this is critical for v1.
Flags: needinfo?(clee)
Some people may want the convenience of having their messages visible on the lock screen, some may want the privacy of forcing authentication before showing message contents. It sounds like we already allow for both use cases (in principle) with a setting that allows you to choose whether the message contents is visible on the lock screen before unlocking the phone. However, comment 1 indicates that there's a bug with this setting. Even when it's on, the message contents can still be read in the notification bar when the device is locked.

I suggest the following fix: when the user has chosen not to show their messages on the lock screen, notifications which appear when the phone is locked should have content-agnostic text, as suggested in comment 2.

I think that we should fix this bug in this privacy feature before we release version 1.
This a P1, but I think we need to clarify exactly what we're doing here.  It sounds like we want to make sure the existing pref is properly respected, but we will not alter default UX.

Chris, does that meet your expectation?
Priority: -- → P1
> It sounds like we want to make sure the existing pref is properly respected, but we will not alter default UX.

When user has turned the "Show notifications on lock screen" setting OFF, notifications should disappear entirely from Lock screen. Minimized or content-agnostic messages are not in scope for v1. Users who choose to hide their lock screen notifications should still be able to eye the counter in the top-left of the status bar, which will convey unread notification count.
Reassigning to Vivien in absence of having a better alternative. Tim owns Lock screen but he doesn't show up on CC list.
Assignee: jcarpenter → 21
(In reply to Josh Carpenter [:jcarpenter] from comment #7)
> > It sounds like we want to make sure the existing pref is properly respected, but we will not alter default UX.
> 
> When user has turned the "Show notifications on lock screen" setting OFF,
> notifications should disappear entirely from Lock screen. Minimized or
> content-agnostic messages are not in scope for v1. Users who choose to hide
> their lock screen notifications should still be able to eye the counter in
> the top-left of the status bar, which will convey unread notification count.

And this is exactly what happen today.

If the pref is turned on, then notifications are shown on the lock screen.
If the pref is turned off, then notification are not shown on the lockscreen. Lawyers and unfaithful husband are safe!

Resolved as WFM.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Awesome, thanks Vivien :)
Josh or Vivien, can you confirm that

* if the pref is turned on,
* the screen is on,
* someone is looking at the notification bar, and
* I receive a text message:

they won't see the content of the text message in the notification area.

[This is what I understood to be the risk suggested in comment 1.]
Flags: needinfo?(clee)
You need to log in before you can comment on or make changes to this bug.