Live data from Hacker News

HTTPS on Stack Overflow: The End of a Long Road

nickcraver.com

61–70 of 183 posts

Re: HTTPS on Stack Overflow: The End of a Long Road

#61
post #53
post #49

Stack Exchange is no longer available from my workplace due to this change. We have a strict no-posting-code-fragments policy, and SE was viewed as too risky to allow without some restriction in place to make it read only. Before HTTPS, the IT department had worked out such a read-only restriction by blocking the SE login with firewall rules. But with HTTPS that kludge is no longer possible, so the site is blocked.

What sort of company do you work at? Why can't everyone just be told not to post code?

What sort of company do you work at where every employee obeys every directive?

Re: HTTPS on Stack Overflow: The End of a Long Road

#62
post #41

Earlier quoted context omitted.

At our place, we put a redirect on the front end networking device that detected if a browser couldn't support more modern encryption protocols, and sent them to an HTTP information page (instead of to the application itself) if so. This allowed us to update the core app to force newer protocols, while still providing some sort of UX for those left behind. We used Piwik to track the hits on the redirect page to get a…

We did a similar thing, but folded it into unsupported and deprecated - unsupported browsers will get an HTML page extolling the virtues of updating your browser once a decade, whilst deprecated browsers (basically IE10 at the time tbh) were treated to a popup explaining that whilst the site probably works just fine, their browser wasnt fully upto date and the experience might suffer. Eventually, and I doubt we had a…

Corporate environments often rewrite employees to use IE 11 because of outdated internal web apps. Where I work the Windows laptops, even Windows 10, only allow IE 11, not even Edge.

Re: HTTPS on Stack Overflow: The End of a Long Road

#63
post #2

This is incredibly detailed; in short, CDNs, cookies/authentication , tons of subdomains, and 3rd-party/user-generated content make it a pain to move onto HTTPS. I was chatting with a non-engineer friend about why it's hard to estimate how long tasks often take, and this seems like a prime illustration: the dependencies are endless. I also love the Easter egg: "The password to our data center is pickles. I didn’t thi…

Just know the username and you can log onto https://stackoverflow.com/admin.php

Re: HTTPS on Stack Overflow: The End of a Long Road

#64
post #33
post #24

Earlier quoted context omitted.

Hey, I'm pretty sure that the first real domain name hack was sex.net, which as the proud owner of ex.net [PS: or was it sexnet.com, as we also have exnet.com?] caused some upset for a while, though mainly to disappointed one-handed typists I believe... B^> BTW, did I blink and miss the "It really is all faster over HTTP/2, even given TLS" bit? My testing for my tiny lightweight sites close to their users (the opposi…

I would imagine the more resources your page has, the more benefit you can get from HTTP/2 because of Server Push. So if you're comparing a tiny lightweight site, I'm guessing you can't benefit as much from Server Push.

I have relatively little that would benefit from push; basically a tiny hand-crafted CSS file that I currently inline because HTTP/1.1 and even HTTP/2 overhead for having it separate may be too high.

Re: HTTPS on Stack Overflow: The End of a Long Road

#65
post #56
post #29

Earlier quoted context omitted.

> X-XSS-Protection: 1 is the default since a long time for browsers supporting it and Chrome blocks by default since two releases. Do you have references to back this up? > Referrer-Policy is a matter of choice. It's a useful information for the target site as long as the referrer doesn't contain sensitive information. IMO, most sites shouldn't set this header. Exactly. I think its primary use is when the original si…

For X-XSS-Protection, see: https://bugs.chromium.org/p/chromium/issues/detail?id=654794 . Currently implemented in M57, but you can still disable filtering. This should be removed in the future.

Thank you!

Re: HTTPS on Stack Overflow: The End of a Long Road

#66
post #49

Stack Exchange is no longer available from my workplace due to this change. We have a strict no-posting-code-fragments policy, and SE was viewed as too risky to allow without some restriction in place to make it read only. Before HTTPS, the IT department had worked out such a read-only restriction by blocking the SE login with firewall rules. But with HTTPS that kludge is no longer possible, so the site is blocked.

Wow, that sounds ridiculous. What's the reasoning behind that policy?

Seems obvious that someone high up on the corporate ladder, with no practical knowledge in how the nitty-gritty work gets done, made the decision. Probably to "minimize IP theft".

Re: HTTPS on Stack Overflow: The End of a Long Road

#67
post #61
post #53

Earlier quoted context omitted.

What sort of company do you work at? Why can't everyone just be told not to post code?

What sort of company do you work at where every employee obeys every directive?

A company that trust their employees. There are so many ways to get around this anyway so it doesn't make sense to try to enforce it in the first place (considering the issues that follows).

Re: HTTPS on Stack Overflow: The End of a Long Road

#68
post #45

Earlier quoted context omitted.

Some people don't spy on their customers and don't have these kinds of information available for analyses They're admittedly few though and their moral high ground is debatable considering that there are self hosted FOSS alternatives around nowadays

Calling aggregate anonymous analytics "spying on your customers" is absurd nonsense.

Declaring "absurd nonsense" isn't an argument.

Re: HTTPS on Stack Overflow: The End of a Long Road

#69
post #49

Stack Exchange is no longer available from my workplace due to this change. We have a strict no-posting-code-fragments policy, and SE was viewed as too risky to allow without some restriction in place to make it read only. Before HTTPS, the IT department had worked out such a read-only restriction by blocking the SE login with firewall rules. But with HTTPS that kludge is no longer possible, so the site is blocked.

Same thing happened to me at a workplace once. They blocked StackOverflow, GitHub, Bitbucket, Sourceforge, CodePlex and Google Code.

I told them all estimates go up by 2 years since we would need to reimplement everything. It ended up being unblocked a week later.

Re: HTTPS on Stack Overflow: The End of a Long Road

#70
post #53
post #49

Stack Exchange is no longer available from my workplace due to this change. We have a strict no-posting-code-fragments policy, and SE was viewed as too risky to allow without some restriction in place to make it read only. Before HTTPS, the IT department had worked out such a read-only restriction by blocking the SE login with firewall rules. But with HTTPS that kludge is no longer possible, so the site is blocked.

What sort of company do you work at? Why can't everyone just be told not to post code?

In many places (banks) there are legal reasons for this.
Post reply on HN