I suspect that all is OK, and you have already been given advice to this effect above.
...are you using Chrome as a browser?
Chrome auto-updates itself in the background, and a (very) recent such update has introduced the treatment of all sites that don't utilise secure data transfer via the HTTPS protocol as "insecure". It flags these as so on the "address" line.
All this means is that data that is transmitted between yourself and the particular website is not automatically encrypted in transit, and so could be intercepted and read. For many/most websites one uses this is of little concern, as interception of such data is not likely to be compromising (about the only issue I can think of is if you use the same password on multiple sites, some of them "critical", then it could give the opportunity to trawl a potential userid and password list to try on those, other, critical sites).
There is a general drive across the web to implement secure transfer, even where it isn't really critical, and browser providers are tending to move to flag those sites that don't/haven't yet implemented it. Whilst I've used Chrome as an example as it roughly fits the timescale of your change, I suspect other browsers and or AV suppliers are making/have made the same change.
So, if it is that, nothing at all has changed from your historical use, it is simply that the browser is now reporting the nature of the connection differently, and flagging where "HTTPS" has not (yet) been implemented by the website.
On my version of Chrome (which changed in the last week or so to version 68 implementing the changed practice) "Not secure" is flagged against URLs in the address line reported as "www.xxxxx" whereas "Secure" is flagged against those reported as "https//www.xxxx".
Last edited by: tyrednemotional on Tue 14 Aug 18 at 09:22
|
Website insecure? new
Website insecure? new
