Live data from Hacker News

Ask HN: What feature would you want the web to “force” next, after HTTPS?

news.ycombinator.com

31–40 of 279 posts

Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?

#32
post #6

It's not security related, but: Accessibility.

Yep, browsers should have screen readers built in. It's ridiculous that you have to shell out $1000+ for a JAWS license (there are alternatives, but they need work).

Yeah, I've tried using the free options to sort of test my products, but it's not a realistic test; the most useful work comes from people who use screen readers daily, but it's really hard to test if we've fixed the problem even when it's been identified so we have to go back and forth.

And, I mean, there are accommodations and assistive technology built into the standards. It's just nowhere near as widespread as it should be, in terms of usage, and it's always an afterthought (if it is thought of at all) in frameworks and HTML templates and such. And, because most of the time an inaccessible site or app is so inaccessible as to prevent anyone who would notice from getting far enough in to complain. So, we need good tools for knowing when our stuff is broken from an accessibility standpoint.

I think what I'm getting at is that it should be easy to see errors in accessibility, and maybe search engines should favor sites that at least make an effort.

Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?

#33
post #9

Dropping TLS in favor of IPSec. Now every protocol is transparently secure by default and there's no chance of developers accidentally messing it up.

IPSec is beautiful and definitely was the correct way to handle encryption.

IKE and ISAKMP was the problem, that stuff is an absolute nightmare. Maybe now with IKE2 it might get better...

Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?

#37
post #5

I'd vote for DNS-over-HTTPS or similar tech. Encrypting domain name resolution should help mitigate a gateway or proxy (Comcast) from knowing or blocking sites you visit.

SNI puts the DNS names you're connecting to in plaintext at the start of every TLS connection. Running your DNS over an encrypted channel won't stop someone from knowing or blocking the sites you connect to.

Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?

#38
post #9

Dropping TLS in favor of IPSec. Now every protocol is transparently secure by default and there's no chance of developers accidentally messing it up.

Key management would be a nightmare here. IPSec has very long setup times, and every destination would need a new crypto configuration. This is exactly the problem that TLS was designed to solve, and IPSec and the web are a bad mix.

Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?

#39
post #3

ML driven content blocking for ads and other garbage such as social widgets and beacons. Red screen warning as deceptive on any site that tries to hack its way around the filter.

Interesting concept.. one that Google certainly wouldn't implement in Chrome because of their ad-based revenue model.

But I could entirely see a little privacy "eye" icon in the URL bar of Firefox, similar to the padlock icon we have now for HTTPS/certificates.

The eye could turn red and display text for the site you are visiting based on analytics, beacons, web bugs, and so on.

Or how about major social media sites have their icons placed in the URL bar if they have trackers / social media widgets on the current page. This way, it is made explicitly clear to the user that "{Insert social platform here} is tracking you on this page, even while you are logged out, don't have an account, ..."

The difficulty with having the browsers force the standard is getting Google Chrome on board, since they have so many users.

Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?

#40
post #5

I'd vote for DNS-over-HTTPS or similar tech. Encrypting domain name resolution should help mitigate a gateway or proxy (Comcast) from knowing or blocking sites you visit.

DNS Crypt (https://dnscrypt.org/) at least partially addresses some concerns with the current DNS specification providing for the authentication of DNS entries (spoofing prevention). I don't think it addresses the privacy concerns of ISP or 3rd party sniffing though.
Post reply on HN