We all know, and well understand what this means when we see it in a browser:

It means that the connection is encrypted, and that some degree of validation has occurred to verify that the server is who it claims to be. Through the years, users have been taught to trust sites when they see that, or the all too familiar ’lock’ icon – when users see it, they assume their data is safe.
But what about this?

There’s no lock to tell them they are safe, but there’s also no warning to indicate that the connection isn’t secure. There’s no encryption, no validation, – no protection at all. With HTTP, users are afforded nothing at all to protect them – but we all know that, right? Does the average user understand that though? Do they understand how easily they could be monitored, or how easily traffic can be altered?
The Need For Negative Feedback #
Strong negative feedback has long been used in browsers to warn against invalid or expired certificates – but there’s no feedback to warn users of just how dangerous HTTP can be. After a discussion on Twitter, a friend of mine, Taylor Hornby, created a mockup of what could be done in Firefox to warn users:

This provides simple, clear feedback to the user that they shouldn’t trust the site – it doesn’t present an error or anything to interrupt the user, but does make them aware of the risks they are taking.
We, the security community, owe it to users to provide them with useful feedback so that they can protect themselves – providing negative feedback in the browser showing the weakness of HTTP would be a large step in that direction – and to urge site owners to adopt HTTPS as soon as possible.
Opportunistic encryption has become quite a hot topic recently, and blew up in a big way thanks to an Internet Draft that was published on February 14th for what amounts to sanctioned man-in-the-middle. Privacy advocates were quickly up in arms – but it’s not that simple (see here). As pointed out by Brad Hill, this isn’t about HTTPS traffic, but HTTP traffic using unauthenticated TLS; thanks to poor wording in the document, it’s easy to miss that fact if you just skim it.
Today ZDNet published an article titled “The lunacy of trying to avoid NSA spying by moving e-mail and cloud out of the US” – I’m still trying to figure out if the position is naive, or intentionally ignores important facts.
In short, the author (Steven J. Vaughan-Nichols) states that your data is safer in the US because outside of the US, the NSA has much less restrictive rules to operate under.
@KimZetter We need to distinguish between "proof against NSA dragnet", "proof against NSA PRISM", and "proof against NSA TAO". @runasand — zooko (@zooko) September 17, 2014 For a long time, “military grade encryption” has been a red flag for snake oil, over-hyped, under-performing garbage, so much so that it’s become a punchline. Anytime that phrase is seen, it’s assumed that the product is a joke – quite possibly doing more harm than good.
If you’ve bothered to look at Twitter or any technology news source, you’ve seen that Apple made a major announcement: Expanded Protections for Children. This has been written about by countless outlets, so I’ll assume you’re familiar with the basics.
The announcement covered a few new features being added to the next version of Apple’s operating systems, namely:
Scanning of inbound and outbound messages for sexually explicit images. Scanning images being uploaded to iCloud for CSAM.
Testing for SWEET32 isn’t simple – when the vulnerability was announced, some argued that the best solution was to assume that if a TLS server supported any of the 3DES cipher suites, consider it vulnerable. The problem is, it’s not that simple. On my employer’s corporate blog, I wrote about practical advice for dealing with SWEET32 – and pointed out that there are ways around the vulnerability, and some are quite simple.