HTTPS Adoption Has Reached the Tipping Point (troyhunt.com)

Security expert Troy Hunt, who is perhaps best known for creating Have I Been Pwned data breach service, argues that adoption of HTTPS has reached the tipping point, citing "some really significant things" that have happened in the past few months. From a blog post: We've already passed the halfway mark for requests served over HTTPS -- This was one of the first signs that we'd finally hit that tipping point and it came a few months ago. This is really significant -- Mozilla is now seeing more secure traffic than it is non-secure traffic. Now that doesn't mean that most sites are now HTTPS because that figure above has a huge portion of traffic served from a small number of big sites. Twitter, Facebook, Gmail etc. all do all their things over HTTPS and that keeps that number quite high. Hunt also cited security aficionado Scott Helme's recent analysis which found that the number of websites listed in Alexa's top one million websites that have adopted to HTTPS has more than doubled year from August 2015 to August 2016. Troy adds: Browsers are holding non-secure sites more accountable. Chrome 56 is now holding sites using bad security practices to account (by flagging a "not secure" label in the address bar when you visit such websites). Many sites you wouldn't expect are now going HTTPS by default. (He cites websites such as ArsTechnica, NYTimes as examples). Making more cases for his argument, Hunt adds that HTTPS sites are not slow as they used to be, and that services such as Let's Encrypt and Cloudflare have made it free and east to bring this security feature.

Comments

security compass

[Anonymous Coward]

I'll encrypt when they make it west. Making it east is just racist.

Tipping Point

[Camel Pilot]

The tipping point towards what? Isn't SSL great for things that need to be secure... ie shopping, banking, etc but pretty much excessive for mundane stuff - like this article and this post for example. I am sure glad by slashdot.org data is transported via SSL connection because you never know....

Re:Tipping Point

[Anonymous Coward]

I see it as more of a needle in a haystack...
When only a small amount of traffic is encrypted that traffic screams to be targeted for an attack.
When all traffic is encrypted it's harder to determine what traffic should be targeted for an attack.

Re:Tipping Point

[omnichad]

It's "evil" to be able to have your traffic sniffed. Leave that data for all the ad networks that serve ads over HTTPS.

Re:Tipping Point

[bigman2003]

I pretty much agree with you.

I create/run a fair number of web applications. Anything with a password associated with it runs https- if there is no password, then it runs insecure.

You want a picture of a peach? I'll serve up thousands- and let every man-in-the-middle know that you're looking at peaches.

You want to send me your email and password (that is probably the same you use on 10 other sites)? Now it is secure.

Asking a real question- why should we encrypt non-sensitive data?

Re:Tipping Point

[Killall -9 Bash]

Ouch! My heart is bleeding! How did that happen...?

Re:Tipping Point

[tepples]

A MITM can still serve with HTTPS just fine.

Only if the browser is configured to trust the MITM's certificate.

Re:Tipping Point

[fisted]

Asking a real question- why should we encrypt non-sensitive data?

Because even though the data is non-sensitive, people might still prefer a little privacy. You'll understand when you're behind a proxy that has multiple people constantly tail -F'ing the access log.

Some stuff is totally mundane and I wouldn't want people to know I'm accessing it regardless even though they would not care about it.

Then there's the problem of, say, clicking on a google search result that was obtained via https, when the actual result isn't. Congratulation, your google search just leaked as part of the Referrer.

Then there's the issue of WHAT exactly is going on on a particular site. I'd take a 'CONNECT slashdot.org:443' in the access log over GET and especially POST showing up there, telling the reading vs posting rate. Not that I'd post must on /. at work, but as a matter of principle.

tl;dr: If your site doesn't speak https, I'll probably stay away from it. Yes, you might not care, but you asked for reasons and here are a few.

Re:Tipping Point

[thegarbz]

but pretty much excessive for mundane stuff

The mundaneness of your stuff is entirely at the liberty of the person spying on you, and if one thing has proven true, it's that EVERYTHING you do seems to be of interest to someone now.

Re:Tipping Point

[tepples]

even though the data is non-sensitive, people might still prefer a little privacy.

In some cases, even the hostname is sensitive, such as "transgender.example" or "womenshealth.example". HTTPS won't save you there because the browser sends the hostname in cleartext in the Server Name Indication field of the ClientHello packet.

You'll understand when you're behind a proxy that has multiple people constantly tail -F'ing the access log.

Watch ISPs offer subscribers a discount on their monthly data plans for configuring their devices to run HTTPS traffic through the ISP's MITM proxy.

I'd take a 'CONNECT slashdot.org:443' in the access log over GET and especially POST showing up there, telling the reading vs posting rate.

Until you start getting billed for each CONNECT that shows up in the access log because the requested resource can't be served from a Squid or Polipo cache upstream of you.

Re:Tipping Point

[fisted]

HTTPS won't save you there because the browser sends the hostname in cleartext in the Server Name Indication field of the ClientHello packet.

It already sends the hostname in cleartext in the CONNECT request which comes before ClientHello. I'm not sure why you're pointing this out, you quoted me saying that... Hostname is strictly better than full URL, since the latter contains the former.

Watch ISPs offer subscribers a discount on their monthly data plans for configuring their devices to run HTTPS traffic through the ISP's MITM proxy.

Yes, I'll watch. As opposed to participate.

Until you start getting billed for each CONNECT that shows up in the access log because the requested resource can't be served from a Squid or Polipo cache upstream of you.

Ok. That is unrelated to the privacy issue, though.

Re:Tipping Point

[Just Some Guy]

but pretty much excessive for mundane stuff

It's also trivial and free to implement with Certbot. If everything were encrypted, then encrypted stuff wouldn't stand out in traffic analysis as "potentially interesting; worth investigating". Given the price, ease, and value in protecting absolutely everything, my policy is that everything that can be encrypted is unless there's a specific reason why it shouldn't be.

Re:Tipping Point

[JoePete]

The full value of HTTPS is only realized with a third-party certificate that authenticates the server's identity. Without the third-party cert, sure, you have encryption, and you can be confident that when submitting info like your credentials or a credit card it can't be sniffed. However, you cannot be confident - without the cert - that you know to whom you are submitting that data. Instead of a thief robbing you on the way to the bank; they just convince you their hideout is the bank. As to why put your entire site under HTTPS and a cert, an attacker can intercept an HTTP request and send back their own forged content. Whether this is a script, image, text, hyperlink etc. It's analogous to locking your door but leaving a window open somewhere.

Re:Tipping Point

[mr_mischief]

How many passwords do you figure I could grab from a web forum that's over HTTP that are common to the same user's banking or utility accounts?

How do you know that the JavaScript being sent from /. is what the site intended? Over HTTP are you sure it's not something injected with extra code targeted at a security vulnerability in your specific browser (which the attack would know from your headers unless you're masking them)?

How about people knowing exactly which articles you read from which sites? With HTTPS and SNI they know what server you used. If you're using insecure DNS then they might already know which hostname you looked up, but that's another data source.

Do you disable cross-site cookies? Did you think about the fact that any third-party observer who can see your traffic can read first-party cookies anyway if you're on HTTP?

Re:Tipping Point

[Brukenet]

What's sensitive about "womenshealth.example" ? Am I missing something?

Re:Tipping Point

[tepples]

"Women's health" is often a euphemism for "reproductive health", which in turn offends those who want to restrict sex education, abortion access, and the like. "You don't need to learn about contraceptives because you can't get pregnant if you abstain from sexual contact, and you don't need to learn about sexually transmitted infections because you can't catch one if you abstain from sexual contact. Only a whore would visit those sites without a valid marriage license."

Re:Tipping Point

[fyrewulff]

The main reason websites had a split between Secure and Unsecure before was due to processing overhead and, depending on how far you go back, actual regulation of encryption by Congress.

Encryption is now a very small time cost on servers and an accepted cost anyway due to the even greater eventual cost of MITM attacks.

It's also a benefit as it makes it harder for someone to passively know exactly what you're reading. Nobody can follow you around and see which specific articles you are reading on Wikipedia, for example, they can only tell that you're going to Wikipedia.

HTTPS negotiation was never the "slow" part

[xxxJonBoyxxx]

HTTPS negotiation was never the "slow" part - it's always been the Javascript, single-pixel images and other crap imported from dozens of other sites. Developers have been driving me nuts with "we can't use HTTPS for our snowflake app - it'll slow the user experience" BS for years.

Re:HTTPS negotiation was never the "slow" part

[Shawn Parr]

Developers have been driving me nuts with "we can't use HTTPS for our snowflake app - it'll slow the user experience" BS for years.

Translation: We are too lazy to learn the small adaptations to make sure our app works with SSL properly. What do you mean anything we embed has to have HTTPS vs HTTP references! That is soooooo hard! Although a special annoyance goes out to any web app that can't deal with being put behind an SSL appliance. Or poor documentation for how to do it (Wordpress used to be a major offender here).

Re:HTTPS negotiation was never the "slow" part

[tepples]

Although a special annoyance goes out to any web app that can't deal with being put behind an SSL appliance.

The web app software can deal with it just fine. But as I understand KingMotley's complaint, the organization operating it can't necessarily afford to purchase said SSL appliance and lease additional units of rack space in the colo facility.

Re:HTTPS negotiation was never the "slow" part

[thegarbz]

HTTPS negotiation was never the "slow" part

I see your first computer was Core i5 with multiple gigs of RAM and the wonders to go with it.
HTTPS negotiation most definitely *was* at one point the "slow" part, especially if you were unfortunate enough to be on the host side of the equation handling multiple requests at a time.

Ironically enough your UID is low enough to remember a time where simply a story on Slashdot could bring down websites. So you should know quite well that things didn't always scale so beautifully in the past as they do now.

Re:HTTPS negotiation was never the "slow" part

[zifn4b]

HTTPS negotiation was never the "slow" part - it's always been the Javascript, single-pixel images and other crap imported from dozens of other sites. Developers have been driving me nuts with "we can't use HTTPS for our snowflake app - it'll slow the user experience" BS for years.

First I agree SSL, TLS, etc. have never been the slow part. There are several culprits for the slowness over the years.

Javascript - You pointed this out. That only really happened when XMLHttpRequest (or oh my MS specific ActiveX instantiation of the XMLHttpRequest COM object *shudder*) arrived on the scene or whoever figured out how to hack AJAX using an iframe. Javascript in the application it was originally designed for (not ad hoc HTTP posts) was perfectly fine. There was very limited DOM manipulation in that case. It's when we got AJAX happy because no one liked the stateless HTTP model because during post backs browsers displayed a polar bear in a snow storm and that was deemed an unacceptable user experience. Never mind the fact that by exclusively using HTTP the way it was intended for web applications enabled the creation of platforms like ASP.NET that could support any browser without the developer having to specifically code to some other browser's quirks mode. Nope, that postback was annoying to the point that certain people bitched and moaned very loudly until we hacked AJAX together and got all the additional challenges associated with it including DOM manipulation performance. NOTE: I think where we ultimately ended up is better than the pure stateless HTTP model.

Web Server platforms like Apache and IIS were not originally built to scale. They couldn't utilize parallel processing effectively to serve up multiple requests. I believe both of them for a while were handling all requests one at a time in synchronous/serial fashion.

As far as your developers providing the excuse of HTTPS being slow that is and always was a BS excuse but you know why your developers told you that right? It's something you most likely don't understand. Hosting and configuring a website is completely outside of the realm of software development. Software developers write the application. DEVOPS deploys the application. IT provides the infrastructure. You probably work somewhere where there is a game of "hot potato" of where the line is between division of responsibilities. Do you really want your developers establishing relationships with certificate authorities to get properly signed certificates or just creating their own bogus ones that can't be verified? Furthermore, you want the developers to have access to your produce environment violating the criteria of many types of audits like PCI, not a good idea. I bet you've never had to deal with the auditors. :)

It sounds like you still have a lot to learn about the Software Engineering field. It also sounds like you're a manager and that is a scary proposition.

Re:HTTPS negotiation was never the "slow" part

[guruevi]

You need to update your knowledge base, the overhead of SSL vs. non-SSL is on the order of 2-5% with modern CPU. A decent set of Intel Xeons can push upwards of 3GBps (that's 24Gbit/s) in encrypted traffic per CPU. Even before HTTP2 there were various methods of speeding up SSL but the whole thing adds less than 2-3ms even on old hardware with relatively up-to-date web servers.

Re:HTTPS negotiation was never the "slow" part

[Just Some Guy]

Then you've never tried to have a server actually scale in the past.

"In the past" being the key part. SSL overhead is trivial now and has been for some time.

Re:HTTPS negotiation was never the "slow" part

[zifn4b]

Slashdot ought to just include a moderation option for "-1 because I reject reality and insert my own". That's about the quality of the moderation on this forum.

Alexa Rankings

[nmb3000]

found that the number of websites listed in Alexa's top one million websites that have adopted to HTTPS has more than doubled

Why do people still use Alexa? There can't be more than a tiny handful of people who still use their crappy browser toolbar and that measuring metric has always had significant selection bias. Do they have a newer, better data source, or is there just nothing better so people fall back to a name that's familiar?

It would be nice if the major ISPs would aggregate and share all that data they save for the NSA anyway with some nonprofit org for this kind of thing.

Not everything needs HTTPS

[Viol8]

If I'm accessing a site that simply serves up information and doesn't ask for any details from me, then there's no need for HTTPS. It simply sucks up CPU cycles and ultimately uses up more electricity. And no , I don't care about the 0.001 extra on my bill, but if you add it up over the entire planet its probably a couple of coal fired power plants extra required.

Re:Not everything needs HTTPS

[chispito]

If I'm accessing a site that simply serves up information and doesn't ask for any details from me, then there's no need for HTTPS.

Your connection can be man-in-the-middled and malicious content served to you, or the middleman could help himself to your cookies. Maybe you have all cookies and javascript disabled, but most of us don't. I mean, there are other ways to mitigate this kind of attack, but it's easiest just to prefer TLS whenever possible.

Re:Not everything needs HTTPS

[Viol8]

"Your connection can be man-in-the-middled and malicious content served to you"

You can spoof an HTTPS site if you know what you're doing.

"or the middleman could help himself to your cookies"

If its just a one way information site the cookies will be of little use to him.

Re:Not everything needs HTTPS

[thegarbz]

If I'm accessing a site that simply serves up information and doesn't ask for any details from me, then there's no need for HTTPS.

That entirely depends on if you knowing that information is of special interest to a third party.
Did you Google a picture of a kitty? Or are you reading in plain text the Anarchists Cookbook? Doing that latter would be of interest to a lot of three letter agencies and you don't even need to share any personal information to get their attention.

Re:Not everything needs HTTPS

[guruevi]

I think a lot less CPU would be consumed if more people were using HTTPS without allowing the side-loading of third party content. Imagine all 30 ads and 300-something trackers here on /. were never loaded because your browser was set not to trust content that laid outside the HTTPS domain you are requesting.

Any hope for practical HTTPS on home LAN?

[tepples]

So I guess the next thing to do is find a way to make HTTPS practical for a web server on a home LAN, particularly with DNS Service Discovery instead of a purchased domain. A lot of routers, NAS boxes, etc. still use cleartext HTTP because the browser publishers' Baseline Requirements forbid certificate authorities trusted by the web browser from issuing certificates for hostnames in the .local TLD. And with browser publishers threatening to make the Fullscreen API HTTPS-only, this would impair video streaming from a NAS.

Sources for threat to drop Fullscreen API: Secure Contexts: Risks associated with non-secure contexts; Secure Contexts: Restricting Legacy Features; Deprecating Non-Secure HTTP; Deprecating Powerful Features on Insecure Origins
Source for impracticality of HTTPS on home LAN: Question to Let's Encrypt rep in /r/IAmA

Re:Any hope for practical HTTPS on home LAN?

[tepples]

It's local. Create a self-signed certificate and add it to your client's certificate store.

This doesn't help in two cases:

1. Devices whose certificate store is managed by the manufacturer, not the device's owner, such as game consoles and other set-top streaming devices
2. BYOD, such as the phone, tablet, or laptop of a friend or relative visiting your house

Is https enough?

[lucasnate1]

There are different versions of SSL and TLS that have already been broken. How useful is "https only" is?

Perfect slip-up

[Khyber]

"have made it free and east"

Given the actual majority of such traffic is coming from China (thank you, Norse!) this is not a surprise. Also, China is the most populous country, so again, it stands.

Re:Great

[tepples]

It depends on what you mean by "Flash". I thought the rise of Safari for iOS adequately encouraged use of HTML5 instead of Flash Player to play H.264 video on the web.

That leaves vector animations, which are traditionally made in Flash and displayed in Flash Player. If they're displayed in HTML5, they still have to be made somehow. Last time I asked about tools to create HTML5 vector animation, someone recommended Hippani. How easily can an animator make the transition from Flash to Hippani?

Web apps have become more dynamic

[tepples]

The HTTPS negotiation was slower than HTTP, but the actual encryption took valuable server compute resources

True, TLS increases CPU overhead for a site that just serves static documents. But web applications have also become more dynamic since the late 1990s when SSL (now called TLS) was invented. With more server-side processing for each page view, the fraction of server CPU time devoted to actually sending the resource to the PC has diminished. I grant that the cost is greater than zero, but the benefit is also greater than zero.

There are solutions today, but none are free

I thought NGINX as the frontend reverse proxy in front of your application server was free software under the 2-clause BSD license.

Re:Web apps have become more dynamic

[doom]

Okay, I must confess that this is the first I've heard about SSL not being SSL any more, but I have a humble suggestion: let's drop this horseshit, no matter how Logical the rationale is, and continue to call SSL SSL.

You'd think we'd learn something from stuff like the URL/URI "switch" that never happened.

For that matter you'd think we'd learn something period, from something, anything, but perhaps I'm showing my age.

Re:Web apps have become more dynamic

[guruevi]

No, SSL is SSL, TLS is TLS, they're somewhat different, most notably that SSL runs encrypted sockets, TLS can negotiate encryption while simultaneously allowing unencrypted traffic over the same sockets. Although in web-servers (at this point) there is no true difference between the streams of SSL or TLS, it should be technically possible to TLS over port 80 (as described in RFC2817) and the recommendation is to turn off SSL completely as all incarnations of it are insecure.

Re:Web apps have become more dynamic

[KingMotley]

With more server-side processing for each page view, the fraction of server CPU time devoted to actually sending the resource to the PC has diminished.

Perhaps it's the sites that you've worked on, but there a vast number that does very little actual per-request dynamic server-side processing. That's pretty much the very first thing you do in creating a scalable website is isolate that from all the other content. Just as an example, the last major site I worked on, all content was cached, and the cache was only invalidated on actual changes, so it was fairly common for only 1 request out of ~1 million to really ever do any server side processing. It wasn't a small site either, at it's peak, it would have 10k concurrent users with pretty rich media assets, so tacking on https encryption overhead to that would have killed the server.

And yes, the site had javascript, and "single pixel" images as well. And it all ran off a single server (well, 1 web server), and it ran well that way.

Re:Web apps have become more dynamic

[KingMotley]

Sorry, I should have just said this at the start, but HTTPS encryption, not including the set-up handshake (which isn't insignificant), and using a modern cypher, like AES will eat up around 2.5 cores by itself if your data rate is ~1gb/s (and we would exceed that at peak hours). Considering the webserver we had was only a quad-core, that would have been 62.5% of the available CPU time just for HTTPS encryption, or tripling our server costs (and/or the added complexity of requiring converting to a web farm).

Comment removed

[account_deleted]

Comment removed based on user account deletion

Worst Offenders

[crow]

What sites are still the worst offenders?

I'll start by nominating amazon.com. Sure, they use https for the actual transaction portion, but every product page you look at is unencrypted. I'm sure every ISP out there is tracking their user's Amazon browsing to create advertising profiles. Verizon certainly is. Why should Amazon give them this information for free?

What will it take for Amazon to fix their site? What if an ISP started injecting ads into Amazon? It would be just a small step from the tracking they already do. I would love to see Verizon or Comcast do that. (Mainly because it would push more sites to use encryption.)

Re:Worst Offenders

[lgw]

How are you seeing an unencrypted page on Amazon? Everything I see is encrypted. Is this something that happens when you're not logged in?

Re:Worst Offenders

[crow]

It must be a recent change, but you're right. I remember it being http except when dealing with transactions. I'm glad I'm wrong. Now I wish I could delete my original post.

Privacy? That'll be $$ per month extra.

[tepples]

Hostname is strictly better than full URL

Agreed. But there are purists who think "strictly better" is still not good enough.

Watch ISPs offer subscribers a discount on their monthly data plans for configuring their devices to run HTTPS traffic through the ISP's MITM proxy.

Yes, I'll watch. As opposed to participate.

Once your ISP starts doing this, you can either participate, pay overages, move to an area served by a different ISP (and make plans to move again once the ISP serving that area changes its policy as well), or disconnect from the Internet. You have already ruled out participating; which of the remaining three is most attractive to you?

[Billing for uncacheable use of a connection] is unrelated to the privacy issue, though.

It's related if the majority of home Internet subscribers prove themselves willing to give up their privacy for a discount on Internet access. It's like ISPs that zero-rate Facebook under the "Free Basics" program: users expose everything to Facebook because their ISP has made it cheaper than using other sites that respect the user's privacy.

Re:Privacy? That'll be $$ per month extra.

[fisted]

Once your ISP starts doing this, you can either participate, pay overages, move to an area served by a different ISP (and make plans to move again once the ISP serving that area changes its policy as well), or disconnect from the Internet. You have already ruled out participating; which of the remaining three is most attractive to you?

None of the above. I couldn't tell you exactly which, but there's got to be at least half a dozen laws and regulations that would prohibit ISPs from doing that, if not German then at least EU-wide, or so I'd hope. That said, I don't like the web to begin with, so as far as I'm concerned it can DIAF. (No, the irony of me saying that here is not lost on me. I'm not on /. because I like the web, I'm on the web because I like^Whave some weird nostalgia for /. and come to think of it, it would work much better over (correctly chained) email.)

[Puts writing a /. <-> email gateway on his todo list]

[Billing for uncacheable use of a connection] is unrelated to the privacy issue, though.

It's related if the majority of home Internet subscribers prove themselves willing to give up their privacy for a discount on Internet access. It's like ISPs that zero-rate Facebook under the "Free Basics" program: users expose everything to Facebook because their ISP has made it cheaper than using other sites that respect the user's privacy.

Fair point.

Re:Privacy? That'll be $$ per month extra.

[tepples]

there's got to be at least half a dozen laws and regulations that would prohibit ISPs from [charging extra not to run all HTTPS connections through a proxy], if not German then at least EU-wide

But definitely not worldwide. Where does that leave those residing in Slashdot's home country, the United States of America? Here the cable company serving a given city tends to have a monopoly on broadband in that city, except for subscribers who can settle for 1.5 Mbps (DSL) or 10 GB/mo (satellite or fixed cellular).

Amazon does it right.

[Anonymous Coward]

Type in amazon.com and any browser later than mosaic 0.5 will redirect you to the https site.

Re:Amazon does it right.

[crow]

Yes, it seems I posted without verifying that my memory was correct. I could swear that at least until recently my assertion was true, but I now I don't know. Too bad I can't delete my post.

Re:Great

[indi0144]

You have to hang around the lowest neighborhoods in the net to find Flash stuff. PHBs got it when they could not experience those marvelous animations in their iPhones. Nothing but interactive video needs flash nowadays, and that moves truckloads of money so, no, Flash might be dead but not buried because now is used for what it was meant to be used.

Perhaps you think that anything animated on a website is "Flash" it is a possibility, but according to your UID you're not an old fart but more likely a millennial trying to add into the circle jerk, so, if thats the case, yeah! we should execute Flash designers and bill Adobe for the bullets./s

I don't know how you can compare HTTPS adoption (an standard) to the freewill or professionalism of the creator of the content in picking the wrong tool. Most of the animations today are done precisely within HTML5 with the help of JS libraries. Google effectively invented those strategies when they started releasing their design guidelines and simple ignoring content in Flash for SEO.

All I see is that designers and animators moved on, web devs know better (because you don't want to piss on daddy Google), but the bitching about the non-existent issue that is Flash kept lingering around like any other old and stale nerd meme.

Re:Great

[NotInHere]

How easily can an animator make the transition from Flash to Hippani?

I'm not an animator myself, nor do I know any animators so I can't help. But it seems you still can reply to "trash eighty" on that discussion thread, so maybe ask them.

I would start looking into replacements for flash as browser vendors are actually wanting to get rid of it.

Re:Great

[NotInHere]

Most of the animations today are done precisely within HTML5 with the help of JS libraries

Flash is still installed on a large part of the desktop population and even if the animators have moved on to creating new things with HTML5, websites are still around requiring Flash.

I don't know how you can compare HTTPS adoption (an standard) to the freewill or professionalism of the creator of the content in picking the wrong tool

HTML5 is a standard as well. Flash is a proprietary technology with most parts like ActionScript being NIH of web technologies like JS, and where the only widely used and usually the only supported version is proprietary and full with security bugs.

And flash is not just about animations. Github required Flash for a long time because of some dumb "put url into clipboard" feature, as do various video sites still today because either they don't care (if you set your user agent to iphone they will show an HTML5 fallback!) or because they believe Flash gives them better DRM than EME does.

Have you ever actually browsed the web without flash? I've uninstalled it in 2011. Was a tough ride back then, you had to add ?html5=1 urls to youtube, and they at least offered a fallback. But I've seen how more and more content supported HTML5. Its still far from perfect, and I won't shut up until it is perfect.

I was an early adopter of HTTPS too. It might seem unimaginable, but in the old days google was not encrypted by default. They launched an extra subdomain "encrypted.google.com" that was encrypted with HTTPS, which I then used.

Yes, I'm calling 2010 "the old days": You are correct with your assessment of me being a millenial.

AES-NI exists now

[tepples]

using a modern cypher, like AES will eat up around 2.5 cores by itself if your data rate is ~1gb/s

Newer server CPUs have hardware acceleration for AES, or you can put crypto in a shader and run it on a GPU.

Considering the webserver we had was only a quad-core, that would have been 62.5% of the available CPU time just for HTTPS encryption

But you also said there's "very little actual per-request dynamic server-side processing", which would presumably easily fit in the remaining 37.5 percent.

Re:Great

[indi0144]

Yeah I know all the places where you can find sprinkles of flash here and there, I was focusing in the uses of Flash that always seem to piss people off or actual vectors of attack. You're right that Flash will keep being installed by default for a long time, I think Chrome approach is the best, to bundle flash in a sandbox and have it set off by default or only when really needed, sadly I need Flash to work on Firefox too so I have it installed updated and by default fiewalled (plugin-container.exe) anytime flash wants to connect to the net, I have to manually approve.

I'm ok with websites that uses Flash for what it was really designed, even for some content that might be better approached with interactivity or a graphic layout. It's a tool that was absurdly overused where it wasn't needed in its time. Jobs slapped Flash in the face with the iPhone and when watery-eyed-flash turned to daddy Google, daddy looked in disappointment and you knew Flash was done.

I think the only thing that was preventing mass adoption of HTTPS as default was the associated costs/return: Cert and IP. Mom-and-pop shops that probably make the most of the .com really didn't see the advantage of it until you need it for setting up payment processing. Now certificates are free or mostly free and SNI takes care of the IP side, setting up HTTPS with cloudflare is trivial for example, all this greatly motivates the adoption. But still, FLASH vs HTTPS adoption history is apples and oranges.

Oh and as for millennial, by some definitions I might be one, 34, but I've been labeled generation X, Y not-remember-what-wankery-in-2000's and now millennial, those tags are created by Marketing so you can rehash the same books and conference tours with the same babble but with new keywords. While demographic studies are certainly of serious interest by marketers the reduction of those concepts until the creation of tags like "millennial" is where you can spot the hack from the real marketer. They are meaningless, and in that regard, I use the word for whats it is: a meme.