I'm wondering how careful we need to be at the client level. I can't imagine any consumers caring or even being able to do much with this information, especially at this early stage. The people we need to reach are deployers/devs and I believe they've already got this message loud and clear.  

My point is that I'm not against putting some type of message into Bling, but I don't want it to come at the cost of a delay in shipping actual change. We need to make this happen as quickly as we can so that deployers understand we have a consistent story. Delaying that actually encourages deployers to continue using HTTP.

Fair point -- I just don't want to surprise developers, as I'm fairly certain that most of them are not aware of it yet (evidenced by activity we're seeing from 3P who are playing with PW but are seeing their results filtered out in Chrome for Android).

Rather than staggering it out by milestone, is there any way we can Finch wrap this / control the API migration server side? That way, we can have the message for a few weeks and then automatically switch over to to internal PWS w/o waiting for Chrome milestones.

We should look at iOS UMA metrics to decide if this will affect a lot of users.

It seems very unlikely devs will be surprised, given the twitter, G+, blog traffic we've seen. Just to be clear, I'm not opposed to a message, but it appears to be a non-trivial amount of work.

iOS UMA metrics are quite low -- I don't think this is the main intended audience with the message.

I'm envisioning more so if someone from a large institution starts playing with Physical Web (they read about it in press, heard about it through alternate Google team, etc.) on iOS and we suddenly stopped showing their URL (with it having recently worked), they might think it no longer works. It's more so that we don't surprise potential testers than do a broad communication to existing users.

That being said, we should weigh the costs -- beyond extra time in making this transition, what are some of the implementation tradeoffs?

Figure out comms plan for reaching devs about HTTPS transition

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/ios_internal.git/+/fa4f20964c3d646e91f0ca8dafa5eec657845d4a

commit fa4f20964c3d646e91f0ca8dafa5eec657845d4a
Author: Matt Reynolds <mattreynolds@google.com>
Date: Wed May 04 21:36:01 2016