Closed Bug 1625156 Opened 10 months ago Closed 8 months ago

HTTPS Only Mode - Error Page

Categories

(Core :: DOM: Security, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox78 --- fixed

People

(Reporter: julianwels, Assigned: julianwels)

References

(Blocks 1 open bug)

Details

(Whiteboard: [domsecurity-active])

Attachments

(2 files)

There should be a new error-page, if a top-level request fails because of an upgrade by the HTTPS-Only Mode.

Information on the error-page:

  • Explanation that error is probably caused by failed upgrade
  • Information how to disable HTTPS-Only Mode
  • Maybe small warning about possible dangers
Priority: -- → P2
Whiteboard: [domsecurity-active]

I tried to find specs or a copy document in the dependency tree, but failed. Is the content for this error page coming from our copy team?

Hi Francesco,

the HTTPS-Only Mode is an opt-in mode you can only enable via about:config. So every user that has turned it on will probably have a good understanding of what's going on.

Although the error page is very important for all people who are, thankfully, testing this feature, the HTTPS-only mode is still very new and it is going to take a lot more work before more users get to see it. Therefore we have not requested any resources from other teams yet. But as soon as we make the feature available to a larger number of people, we will certainly do that. ^^

(In reply to Julian Gaibler from comment #3)

the HTTPS-Only Mode is an opt-in mode you can only enable via about:config. So every user that has turned it on will probably have a good understanding of what's going on.

Although the error page is very important for all people who are, thankfully, testing this feature, the HTTPS-only mode is still very new and it is going to take a lot more work before more users get to see it. Therefore we have not requested any resources from other teams yet. But as soon as we make the feature available to a larger number of people, we will certainly do that. ^^

If that's the case, should the page be localized? Right now, it will be automatically exposed for localization.

Where can I see the plan around this option?

(In reply to Francesco Lodolo [:flod] from comment #4)

If that's the case, should the page be localized? Right now, it will be automatically exposed for localization.

Is there a way to exempt it from localization or do you think I should just remove the fluent file for now?

It'd be great if the error-page could get localized! Do you have any documents how the localization process is handled? That would be very helpful!

(In reply to Julian Gaibler from comment #5)

It'd be great if the error-page could get localized! Do you have any documents how the localization process is handled? That would be very helpful!

I agree that it should be localized, but if the text will need to change several times before stabilizing, it's better to not expose the first version. That creates extra work for the community of localizers, and for developers who need to version the IDs every time a string changes.

That's also why I was asking for a plan: is there a clear idea of how long the experimental phase will last, and what the next steps are?

One alternative is to keep the Fluent file in a different path, not exposed to localization, and move it when it's considered ready. This is a patch doing exactly that: https://phabricator.services.mozilla.com/D72617

Some information on the process is available here, although it doesn't fully describe what happens next (the strings go into Pontoon, where they are localized by community)
https://firefox-source-docs.mozilla.org/l10n/overview.html

(In reply to Francesco Lodolo [:flod] from comment #6)

I agree that it should be localized, but if the text will need to change several times before stabilizing, it's better to not expose the first version. That creates extra work for the community of localizers, and for developers who need to version the IDs every time a string changes.

I don't think the text will change a lot if everyone is happy with it as it is right now. And while the feature might be prone to a lot of changes, the error page isn't, I'm sure.

There is not a dead-set plan yet, but this feature is going to stay experimental for the foreseeable future.

Thanks for sharing the documentation and patch!

Arthur asked me to revise error page copy...I believe it is for the error being discussed in this thread but I am not sure.

Arthur, can you please confirm this thread is discussing the same message?

And, the revised message with questions for you here: https://docs.google.com/document/d/1ujx32a9dzlWxGHBNRMBKSaM9S92aKPVygm7M4ukYDEs/edit#

Flags: needinfo?(arthur)

(In reply to Meridel from comment #8)

Arthur asked me to revise error page copy...I believe it is for the error being discussed in this thread but I am not sure.

Arthur, can you please confirm this thread is discussing the same message?

And, the revised message with questions for you here: https://docs.google.com/document/d/1ujx32a9dzlWxGHBNRMBKSaM9S92aKPVygm7M4ukYDEs/edit#

Hi Meridel -- yes, this is the one. Thank you so much!

Flags: needinfo?(arthur)
Depends on: 1634980
Flags: needinfo?(arthur)

I believe the copy is final now. I collected the notes at bottom of doc for future version, should feature become default. Arthur, can you please sign off?

Michael, I was asked to create an error message for HTTPS-only mode (this feature is just being dogfooded now, mostly with employees and some early adopters).

I think the message is fine as is, but I've had legal review security messages in the past so I'd like to get your eyes on it: https://docs.google.com/document/d/1ujx32a9dzlWxGHBNRMBKSaM9S92aKPVygm7M4ukYDEs/edit#

Thank you.

Flags: needinfo?(mfeldman)

Arthur, one more open comment for you in the message. Julian liked the note about not including sensitive information so I wanted to follow up on this.

Flags: needinfo?(mfeldman)

Hi all -- the copy looks good to me. Thank you, Meridel!

Flags: needinfo?(arthur)

(In reply to Francesco Lodolo [:flod] from comment #6)

I agree that it should be localized, but if the text will need to change several times before stabilizing, it's better to not expose the first version. That creates extra work for the community of localizers, and for developers who need to version the IDs every time a string changes.

Makes sense. I don't think the copy will change much now that we have had help from Meridel (Content Strategy). We made decide to add some extra text in later phases, but the original text should remain.

That's also why I was asking for a plan: is there a clear idea of how long the experimental phase will last, and what the next steps are?

There are a couple of possible experimental phases:

  1. Purely experimental (to be enabled in about:config)
  2. Available in about:preferences

I think these two phases will last months or years, and the copy should be fine for both. :flod, do you feel comfortable with localizing at this stage?

Flags: needinfo?(francesco.lodolo)

(In reply to Arthur Edelstein [:arthur] from comment #15)

I think these two phases will last months or years, and the copy should be fine for both. :flod, do you feel comfortable with localizing at this stage?

Yes. Changing/adding text later is not an issue, I only wanted to make sure we landed something that didn't require multiple iterations right after landing. With Meridel's review I'm confident that's not going to happen.

Flags: needinfo?(francesco.lodolo)
Blocks: 1640853
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ae277f656dc4
Error page for HTTPS Only Mode. r=fluent-reviewers,ckerschb,nhnt11,flod,nika,johannh,mattwoodrow
https://hg.mozilla.org/integration/autoland/rev/e3642fe21b7e
Added tests for HTTPS Only Mode error page. r=nhnt11
Regressions: 1640906
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
You need to log in before you can comment on or make changes to this bug.