New Topic Subscription Options |
Chrome will soon BLOCK non https downloads
Forums: General Discussion | |||
|
|||
Participant: Log in to see names |
Sunday, February 9, 2020 at 12:25 AM
Today we’re announcing that Chrome will gradually ensure that secure (HTTPS) pages only download secure files. In a series of steps outlined below, we’ll start blocking "mixed content downloads" (non-HTTPS downloads started on secure pages). This move follows a plan we announced last year to start blocking all insecure subresources on secure pages. Chrome is going to block many CC downloads not too far in the future - read details here I have a solution, however, it only works if CC changes your login to the actual CC name vs your Domain name. It has to do with how cookies are stored. So either CC gives us an option to redirect the login to our raw URL or solves the https issue. This only applies to those of us with a Domain name. A script I wrote automatically converts a "free" or no domain named site to https. Described on THIS PAGE Notice that this page is SECURE just like I described.
|
||
|
|||
Participant: Log in to see names |
Monday, February 10, 2020 at 2:57 PM - Response #1
This is most disturbing. Currently, several of our classmates are not receiving Notifications. Have no way of knowing who uses Chrome. We do have a domaine name and it’s not secure.
|
||
|
|||
Participant: Log in to see names |
Monday, February 10, 2020 at 3:13 PM - Response #2
Since most browsers are essentially derived from Chromium (even Edge is going to that code) this will soon become an issue for ALL browsers. This page describes Chromium Even Safari will adopt this standard too. I emailed CC explaining all they have to do, just give us the login option (or change the cookie code). If they don't want to do the rest, the little script in the link above fixes the rest. There may be some minor tinkering adjustments for links that are not https yet. The History option for pages is one of those that needs to be fixed by that site. It will stop working when all this is finished.
|
||
|
|||
Participant: Log in to see names |
Monday, February 10, 2020 at 4:37 PM - Response #3
Thank you, Jack, for explaining.
|
||
|
|||
Participant: Log in to see names |
Monday, February 10, 2020 at 11:11 PM - Response #4
Jack, Your site, bothelhigh61.com and my site, eastlongmeadowhighschool1970.com, both have the "Not secure" wording preceding the URL. Will the pending changes to Chrome affect our ability to upload photos (.jpg files), or type in text? This is how I add material 99.99% of the time. If the answer is no, then it seems there would be no impact from these changes.
|
||
|
|||
Participant: Log in to see names |
Tuesday, February 11, 2020 at 12:53 AM - Response #5
Ignoring the desire to remove the "non-secure" warning that will bother more and more users, the impact depends on the future and designer. I've run into a lot of issues that I had to solve for various goals. I also believe that eventually the https requirement will evolve to include downloaded stuff (listed in link) from http sites. For example, IMO all .exe/.zip files should be https only. -Uploading- images and files is not related to this issue. That's a pure CC code The issue is how you LINK/Refer to them. I think that's what you meant though. One can link from ANY source, not just CC for files. ISSUU is a typical example. And that of course is https. And so is YouTube. This becomes apparent when one expands their design goals. Where one can get into trouble is attempting to use https stuff. Examples: 1. The FB Class Connection has that issue - so stuff on there will stop working as described by Chrome. FB is HTTPS. I had to modify one of my iframes to https to get accepted by FB. Not many would recognize why it would not work on FB. 2. The Editor Preview testing. If you use a script that is NOT https (or other objects) it will NOT work. Because that is https and the object is not. So you can't test pages Even though they would work outside of testing. But that's not cool. You can't easily verify one's work. (FB also does not work again.) 3. There are other conditions where one might get an https widget and mix it with non-https and it will not load. Right now, there are many https links using the RAW CC name on one's CC site. Below is the list of https raw CC URL vs your domain name. A few are missing that can also be https. I think they just forgot 1. Log In (except for a BUG in Man Icon login) I've actually tested our site as a 100% https site - works fine. The problem that I discovered at the last minute is that I have to be logged in and on an https page - that's to keep the https cookie active. So I know for sure that to make a site https is not hard - IF CC gives an option to change the landing spot. Obviously that's already possible since if a user drops a Domain, they go back to the original raw URL which can be made https.
|
||
|
|||
Participant: Log in to see names |
Tuesday, February 11, 2020 at 12:58 AM - Response #6
FWIW, I've gone out of my way to make data I link in https. I had to do that several years ago since Chrome implemented script https security way back. The scripts I documented all have https references for that reason.
|
||
|
|||
Participant: Log in to see names |
Tuesday, February 11, 2020 at 8:42 AM - Response #7
Jack, thank you. Can someone from CC please advise the CC solution for those of us who have insecure websites. Thank you.
|
||
|
|||
Participant: Log in to see names |
Tuesday, February 11, 2020 at 11:04 AM - Response #8
The list comprises all the things that are already https secure. They do not use your domain name. CC made those changes and nobody noticed Meaning they all keep working since there is no change if the option to make all the pages https (as described). Those pages follow the new guidelines. Just showing that complete HTTPS conversion is not a big leap. The main thing that Chrome changes may produce for some are edit/preview problems.
|
||
|
|||
Participant: Log in to see names |
Wednesday, February 12, 2020 at 1:07 PM - Response #9
Short explanation why the desire to move to https. With a regular http site, anyone can "see" your data and snoop on what you are doing. HTTPS makes snooping on your data stream extremely difficult. The other issue is with htttp is not as obvious. A "bad guy" can intercept your data and send you back something completely different. You think you downloaded X but instead got Y which is some sort of malware. That is the real problem being solved.
|
||
|
|||
Participant: Log in to see names |
Thursday, February 13, 2020 at 3:51 PM - Response #10
Interesting discussion folks. The reason I came looking for this was one of our co-admins of our retired employees club noted the "insecure" warning on their browser and asked how to "fix" it.
|
||
|
|||
Participant: Log in to see names |
Friday, February 14, 2020 at 4:44 PM - Response #11
We are aware of the Chrome changes and we are still working on the larger solution. Our goal is to offer an option for those who have a domain to be able to have their own secure ID if they choose or toggle a switch that will allow them to use our secure ID throughout the site. It is similar to what Jack is describing, however, we want to be able to offer both and are actively working on the option for both. In the meantime everything that requires security is already secured using our secure ID including any payment forms, contact information and join forms, most admin functions and the sign in page. Jessica
|
||
|
|||
Participant: Log in to see names |
Friday, February 14, 2020 at 4:53 PM - Response #12
Thanks Jessica. Can you please indicate why my Feb 14, 2020 4pm post was removed.
|
||
|
|||
Participant: Log in to see names |
Friday, February 14, 2020 at 5:26 PM - Response #13
Did you add it here? I don't see it and did not remove it.
|
||
|
|||
Participant: Log in to see names |
Friday, February 14, 2020 at 6:48 PM - Response #14
Yes - 2 comments with detailed wording. Jack did post replies to my comments.
|
||
|
|||
Participant: Log in to see names |
Friday, February 14, 2020 at 6:52 PM - Response #15
Correction: my comments are one below: Site not Secure with 347 views
|
||
|
|||
Participant: Log in to see names |
Friday, February 14, 2020 at 7:00 PM - Response #16
I'm sorry I'm not fully following the question. Can you add it again or send me a link to it? The chrome issue is the site secure issue - it is all related. They are just adding new layers of what they want to secure. I'm not concerned about exe files as we don't use them or allow them, however, the other file downloads such as PDF, Word, etc. will all need to be addressed at the same time we implement the larger secure site solution.
|
||
|
|||
Participant: Log in to see names |
Friday, February 14, 2020 at 9:19 PM - Response #17
Jessica, I think there is a misinterpretation about my comment about .exe and .zip files. A user can create a LINK to any file. IOW not related to uploading to the file vault which does have those file restrictions. The login bug should be fixed right away though. The one I've reported two times [plus the edit profiles is not https] Do you have an ETA on the fix to https?
|
||
|
|||
Participant: Log in to see names |
Saturday, February 15, 2020 at 6:49 AM - Response #18
Jessica, CC- Because this is urgent, CC plesse advise your solution to make my class website Secure. As an administrator, my clsssmates depend on me to provide them with an easy to access website.
|
||
|
|||
Participant: Log in to see names |
Monday, February 17, 2020 at 8:00 PM - Response #19
We don't have an exact timeline, however, we are actively working on and testing several options for our system. The system is unique to other systems as it has to be able to handle sites with or without domains and to continue to work if the users chooses not to renew their domain and reverts back to their original classcreator.com link. The newer restrictions will not affect the sites for some time as we stated above our system does not allow or use .exe files and we should have a solution in place and notices out to all admins prior to any further file download restrictions going into effect. Jessica
|
||
|
|||
Participant: Log in to see names |
Tuesday, February 18, 2020 at 12:56 AM - Response #20
Jessica: Please read comment #17. The option to just land on the 'original classcreator.com link' is all that would be required initially. The domain issue (keeping it in all the pages) can be done later. As I explained (and you confirmed) there is already code that " reverts back to their original classcreator.com link". So all that needs to be done is trigger THAT code as if there is no domain. I have a script that will make those links secure with nothing else required. It fixes all the left side links to https. Plus if CC finally finishes it, script automatically will do nothing if it detects https present. The only issue that is already implemented for non-https CSS is that the history pages will not work for some of the browsers. That is not described on those pages because that is already a restriction for Edge, Firefox and Opera ( I think Chrome forgot). And if any widgets are used that are not https, but most are today. That is easily fixed by the user and they get a head start since they would have to fix those eventually. Do it a STEP at a TIME. The first step is very easy to do.
|
||
|
|||
Participant: Log in to see names |
Thursday, April 2, 2020 at 5:52 PM - Response #21
Has there been a fix, solution, whatever, to this issue?
|
||
|
|||
Participant: Log in to see names |
Thursday, September 3, 2020 at 4:49 PM - Response #22
Chris,
|
||
|
|||
Participant: Log in to see names |
Thursday, September 3, 2020 at 4:58 PM - Response #23
This issue has already been addressed. We are hoping to get the larger SSL solution out to admins the next week or two.
|
||
|
|||
Participant: Log in to see names |
Thursday, September 3, 2020 at 11:58 PM - Response #24
Thanks, Jessica.
|
||
|
|||
Participant: Log in to see names |
Saturday, December 12, 2020 at 4:06 AM - Response #25
Jessica wrote: This issue has already been addressed. We are hoping to get the larger SSL solution out to admins the next week or two. Hi Jessica, please update? It's now >3 months after your post. And our classmates are *still* seeing "Not Secure" on their web browsers when visiting our reunion website. Status please?
|
||
|
|||
Participant: Log in to see names |
Saturday, December 26, 2020 at 8:55 PM - Response #26
Firefox also gives an Unsecure message when I try to go to my domain name. It says the certificate is not valid with the domain name only with a bunch of classcreator names.
|
||
|
New Topic |
Subscription Options: Have all new forum posts sent directly to your email. |
Subscription options are available after you log in. |