Enable "HTTPS by Default" by default

[arthuredelstein]

Now that we have completed the rollout of HTTPS by Default using griffin, we can set the feature to be enabled by default.

[mihaiplesa]

@arthuredelstein

Please specify either QA/Yes or QA/No.
If you specify QA/Yes, then please also specify a test plan.
Please also specify either release-notes/include or release-notes/exclude.
For more information see https://github.com/brave/brave-browser/wiki/Missing-release-note-labels and
https://github.com/brave/brave-browser/wiki/Missing-QA-labels

[LaurenWags]

@arthuredelstein please see @mihaiplesa comment from above, this issue is missing required labels and information.

cc @kjozwiak @rebron

[arthuredelstein]

QA testing: Once we remove the griffin study for Nightly or Release in https://github.com/brave/brave-variations, then testing can confirm that the Https by Default feature remains enabled. See tests in #27141. I will post here when the griffin studies are removed.

[LaurenWags]

@arthuredelstein sounds like this one is release-notes/exclude. Will add that label.

Also, going to add QA/Blocked label until you post here since we're dependent upon the removal of the griffin studies. Is there a planned timeline for that?

It seems like we can spot check that the feature is enabled by default, doesn't seem necessary to run through all the same tests again. Let me know if that's an accurate assessment (I believe that's what we normally do when we switch from a griffin study to enabling by default via code). cc @kjozwiak to confirm that.

[arthuredelstein]

@arthuredelstein sounds like this one is release-notes/exclude. Will add that label.

Great, thanks.

Also, going to add QA/Blocked label until you post here since we're dependent upon the removal of the griffin studies. Is there a planned timeline for that?

Makes sense. I expect to remove griffin studies for Nightly shortly, and then for Release once the patch here has reached Release.

It seems like we can spot check that the feature is enabled by default, doesn't seem necessary to run through all the same tests again. Let me know if that's an accurate assessment (I believe that's what we normally do when we switch from a griffin study to enabling by default via code). cc @kjozwiak to confirm that.

Yes, a spot check sounds good.

[LaurenWags]

@brave/qa-team to test this without waiting for the griffin studies to be removed, we can launch a clean profile and ensure no griffin studies are listed under brave://version.

Then can spot check this feature is available under shields panel and brave://settings. Once the griffin study is removed (@arthuredelstein to create PRs and to post here when this is complete) we can check that brave://version after restart and ensure the study is not being listed.

[stephendonner]

Verification PASSED using

Brave | 1.58.92 Chromium: 116.0.5845.96 (Official Build) beta (x86_64)
-- | --
Revision | 8e2896b3a1286e25b85ff82ab828fb7a807e1e26
OS | macOS Version 11.7.9 (Build 20G1426)

Initial launch - PASSED

Steps:

1. installed 1.58.92
2. launched Brave
3. opened brave://version
4. opened brave://flags

Confirmed brave://flags/#https-by-default was still Enabled by default, without Griffin-enabled studies

brave://version	brave://flags

Griffin-study removal - DEFERRED

1. installed 1.58.92
2. launched Brave
3. restarted
4. opened brave://version
5. confirmed I saw BraveHttpsByDefaultRolloutStudy:Enabled
6. opened brave://flags/#https-by-default
7. confirmed I saw Default

brave://version	brave://flags

---

Default - Upgrade connections to HTTPS, Standard - PASSED

1. installed 1.58.92
2. launched Brave
3. confirmed Upgrade connections to HTTPS is set to Standard in brave://settings/shields
4. loaded http://insecure.arthuredelstein.net
5. loaded http://http.badssl.com
6. loaded http://upgradable.arthuredelstein.net
7. opened a New Private Window with Tor and loaded each of the above

default	insecure.arthuredelstein.net	http.badssl.com	upgradable.arthuredelstein.net (*)

Tor

insecure.arthuredelstein.net	http.badssl.com	upgradable.arthuredelstein.net (*)

Upgrade connections to HTTPS, Strict - PASSED

1. installed 1.58.92
2. launched Brave
3. changed Upgrade connections to HTTPS to Strict in brave://settings/shields
4. loaded http://insecure.arthuredelstein.net
5. loaded http://http.badssl.com
6. loaded http://upgradeable.arthuredelstein.net
7. opened a New Private Window with Tor and loaded each of the above

Upgrade connections, Strict	insecure.arthuredelstein.net	http.badssl.com	upgradable.arthuredelstein.net (*)

Tor

insecure.arthuredelstein.net	http.badssl.com	upgradable.arthuredelstein.net (*)

Upgrade connections to HTTPS, Disabled - PASSED

1. installed 1.58.92
2. launched Brave
3. changed Upgrade connections to HTTPS to Disabled in brave://settings/shields
4. loaded http://insecure.arthuredelstein.net
5. loaded http://http.badssl.com
6. loaded http://upgradeable.arthuredelstein.net
7. opened a New Private Window with Tor and loaded each of the above

Upgrade connections, Disabled	insecure.arthuredelstein.net	http.badssl.com	upgradable.arthuredelstein.net (*)

Tor

insecure.arthuredelstein.net	http.badssl.com	upgradable.arthuredelstein.net (*)

Shields down - PASSED

1. installed 1.58.92
2. launched Brave
3. loaded http://insecure.arthuredelstein.net
4. loaded http://http.badssl.com
5. loaded http://upgradeable.arthuredelstein.net
6. clicked on the Brave Shields icon in the URL bar
7. toggled each of the above loaded sites' Shields to DOWN
8. opened a New Private Window with Tor and loaded each of the above

Global Shields pref	insecure.arthuredelstein.net	http.badssl.com	upgradable.arthuredelstein.net (*)

Tor

insecure.arthuredelstein.net	http.badssl.com	upgradable.arthuredelstein.net

(*) Logged:

• Upgrade connections to HTTPS isn't working on upgradable.arthuredelstein.net #32372

[Uni-verse]

Verified on Samsung Galaxy S21 5G using the following build(s):

Brave	1.58.115 Chromium: 116.0.5845.163 (Official Build) beta (32-bit) 
Revision	4d8f3ac31e950c7bb505b61fd9d86ed7f4888a71
OS	Android 13; Build/TP1A.220624.014; 33; REL

First Launch

• Ensured that HTTPS by Default is enabled by default
• Ensured Upgrade connections to HTTPS is set to default

Example	Example	Example

Functionality

• Spot checked functionality per site and global settings using http://insecure.arthuredelstein.net and http://upgradable.arthuredelstein.net test pages.

Default	Strict (per site)	Disabled (per site)	default	default	Strict (globals)	Shields down

[kjozwiak]

It seems like we can spot check that the feature is enabled by default, doesn't seem necessary to run through all the same tests again. Let me know if that's an accurate assessment (I believe that's what we normally do when we switch from a griffin study to enabling by default via code). cc @kjozwiak to confirm that.

Apologies for the delayed response but looks like @arthuredelstein already answered as well. Agreed, a quick spot check is basically all we really need to do. All we're doing is enabling the feature by default rather than requiring the restart to apply the study from Griffin.