New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 832731 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Feature



Sign in to add a comment

Improved notifications to users before device deprecation.

Project Member Reported by dgarr...@chromium.org, Apr 13 2018

Issue description

I've heard complaints that users open up their device to find out it's deprecated with no warning.

Maybe we can do better by sending email to accounts that are owners of a deprecated device, warning them well in advance?

Email seems particularly useful for users that aren't on the Chromebook daily, but reasonably expect it to "just be there" when they need it, with no ugly surprise.

It might also be a good time to offer a discounted price on a new device to ease the pain.

PS: I have no idea where to route this, but I suspect Josafat might.
 

Comment 1 by josa...@google.com, Apr 13 2018

Cc: abodenha@chromium.org dhadd...@chromium.org josa...@chromium.org
Owner: ----
+otherfolks too 

there should be a notification already -> issue 605443

Not sure adding email is an alternative here 

adding 
- Albert for comments 
- David to confirm the notification is being displayed/tested for AUE devices
There is an autotest which checks that the device displays the EOL notification when they get an omaha response with _eol in it:
https://stainless.corp.google.com/search?test=%5Eautoupdate%5C_EOL%24&exclude_non_release=true&exclude_cts=true&col=build&row=model&view=matrix&first_date=2018-04-07&last_date=2018-04-13

We are also showing the EOL notification from dev -> stable on the final milestone so we are "testing" it manually too because we will be looking at it for that final milestone. 

Email is tricky from a privacy perspective. We'd have to know who is signing in on what devices.  Right now GAIA knows that you signed in from Chrome OS but generally not what device you're using. (I'm oversimplifying. This is a complex subject.)

We've discussed offering discounts. There was a PM looking into it at one point, but I'm not sure where that went.  A challenge there is that discounts would have to come from the OEMs not Google. It's also tough to message well without coming off as slimy "Hey, we're gonna stop supporting you. Seems like a good time to give us more money."

I think there's value in trying to give people more warning, but the fact is that there's no way of messaging this that wont feel "sudden" to users.

I'd love to be able to support devices forever, but it's just not possible.
Note, the user I mentioned replied OOB that the machine saw daily use, and he was never notified.

To clarify, I did get a pop-up when support was actually dropped, but I got
no warning notifications before that.

(If it's relevant: lumpy, not dev mode, stable channel, I don't habitually
put off updates)
Thanks for the clarification.

So it's working "as designed".  The question here is if the design is adequate. 
To confirm, the design is not to give users any advance warning before their device ceases to receive updates?

If so, then by design we're setting up an undesirable race between "Meredydd chooses, buys, receives and sets up a new laptop", and "someone finds the next exploitable bug in Chrome, against which he will not be protected because his laptop is no longer receiving updates". (And that's for a well-off SWE who can afford to buy a new laptop at zero notice. For someone who has to wait a few weeks to find the budget [less-well off individuals, schools/businesses with purchase-approval procedures], the vulnerability window is substantially larger.)

I appreciate that deprecation will always come as unpleasant news to device owners. But I think it's better security posture to give people enough warning and the opportunity to stay protected, rather than yanking update cover and telling them afterwards.
Components: -Infra>Client>ChromeOS Internals>Installer
Labels: -Type-Bug -Pri-3 OS-Chrome Pri-2 Type-Feature
The design, as it exists today, is to pop a notification once the EOL bit is flipped at the server which will be the first stable update of the last milestone where the device will get updates. Nothing actually prevents more updates at that point (I actually suspect such devices currently get stable-refresh builds for the rest of that milestone, but I haven't confirmed)

I'm in agreement with you that we should do more here. What (if anything) we can practically do is something I'm going to take up with the rest of the team.

Thanks for the feedback.

Sign in to add a comment