885864 - Warn or Potentially Block the User from setting the date & time in the past

Status: RESOLVED WONTFIX

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

Description

[Jason Smith [:jsmith]]

There are many things that go wrong when the date and time in the past - especially around certificate error handling. We should either warn or potentially block the user from setting the date and time in the past.

This aims to provide mistake proofing to avoid putting users into a bad state.

Comment 2

[Jason Smith [:jsmith]]

TCL is claiming this is a blocking issue for one of the carriers in the dupe, so I'm noming this to block.

Comment 3

[Jason Smith [:jsmith]]

Also - this needs UX input on what we should do here to address the operator blocker requirement for this bug.

Comment 4

[Stephany Wilkes]

Flagging Rob on clock.

Comment 5

[Jason Smith [:jsmith]]

Per Joe's email, this bug was not cited as one of the blocking issues anymore. Pulling nom.

Comment 6

[Stephany Wilkes]

Unless this is a hard (partner/certification) requirement, UX would rather not punish the user for wanting set time/date back in time, as they might to synchronize their phone to a wristwatch, or as they might after traveling and not having auto-set work. In this case, they could conceivably need to set time/date back a whole day in the future. Please leave the design as-is for now.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Stephany Wilkes from comment #6)
> Unless this is a hard (partner/certification) requirement, UX would rather
> not punish the user for wanting set time/date back in time, as they might to
> synchronize their phone to a wristwatch, or as they might after traveling
> and not having auto-set work. In this case, they could conceivably need to
> set time/date back a whole day in the future. Please leave the design as-is
> for now.

That's a bad idea. SSL is designed such that there are set timeframes when certificates are valid. So there will be timeframes when the you can potentially put the user into a footgun on the phone if they set their time too far in the future or too far in the past, which will break many phone functions as a result (see the dupe for impact). As the reporter cites, that's not acceptable by any means. We need to figure out a path forward that protects against the user foot gun. Sending this back to UX to discuss again to figure this out.

Comment 8

[Stephany Wilkes]

Then it sounds like a hard technical requirement and what UX thinks is not the concern here, no?

Comment 9

[Jason Smith [:jsmith]]

(In reply to Stephany Wilkes from comment #8)
> Then it sounds like a hard technical requirement and what UX thinks is not
> the concern here, no?

What UX thinks does matter, but it's more of understanding how to design a user flow knowing the technical requirement in the product.

Comment 10

[Jason Smith [:jsmith]]

If no one is pushing for this to be a blocker now, then let's hold off on the UX discussion. If this becomes raised as important again, let's reopen the discussion.

Comment 11

[Jack Liu]

Dear Jason,

It's not blocker for v1.1 any more, but we hope it can be fixed in v1.2, for some carrier network is without NITZ.

Comment 12

[Preeti Raghunath(:Preeti)]

Steph,

Please talk to Rob about this bug.

Comment 13

[Stephany Wilkes]

Rob is out until next week. The soonest we could even start is mid next week. This is not a trivial change, as discussed in triage. Since we are already well into 1.3 designs for sprint deadlines, and this will require some significant time for UX given the edge cases around taking the phone on/offline, time zone switching, etc., I am flagging Adam Rogers so he can adjust 1.3 plans based on the UX time we'll need to address this 1.2 issue.

Adam, we'll also need to identify the engineer who is going to implement this, so we can have short cycles around the UX. Adam, not sure if you're even aware that this is a hard requirement, or if you may want to look into this first.

Comment 14

[Stephany Wilkes]

Also, Adam, Rob's early input is included in my comment #6 (I just typed our IRC chat).

Comment 15

[Joe Cheng [:jcheng] (please needinfo)]

triage: not blocking 1.2. move to 1.4? for future consideration

Comment 16

[Adam Rogers (:arog)]

If the user has chosen to not use the network time as a definitive source or if the network time is not a definitive source (it's incorrect or not broadcasting).  How does the system know that the user has set their time to be something in the past?

I have no issues with warning the user that changing the date significantly may cause problems, but I am not in favour of blocking their ability to do so - if someone wants to believe it's 1974 that's OK with me.

+pdol, as this required systems input.

Comment 17

[Peter Dolanjski [:pdol]]

Do we have a good idea of the threshold, in terms of time before or after current, which core functions stop working due to the time bound SSL certs?
For example, it does seem silly to warn someone about an issue (that they won't hit) if they set their time a few minutes into the past.

Comment 18

[Peter Dolanjski [:pdol]]

NI on Jason.  Jason, if you know who might be able to answer my question, feel free to NI them.

Comment 19

[Jason Smith [:jsmith]]

(In reply to Peter Dolanjski [:pdol] from comment #18)
> NI on Jason.  Jason, if you know who might be able to answer my question,
> feel free to NI them.

The typical use case for length of time for a SSL cert to be granted is 1 - 5 years. So on that regard, a warning would probably only be useful to issue if the user starts changing the year parameter of the date of the phone.

Comment 20

[Bruce Huang [:bhuang] (inactive)]

Added to backlog, but considering it's non-partner blocking moving it off 1.4 for now.

Comment 21

[BMO Automation]

Firefox OS is not being worked on