Live data from Hacker News

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

news.ycombinator.com

131–140 of 279 posts

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

#131

Registration forms should be standardized. I want to have my "real" details, and my "fake" details ready to be entered into websites that want yet another registration. Why does every single website implement their own registration form with exactly the same details?! Why does every single web site re-implement the registration page slightly differently?! Ideally, I'd enter the registration page, the browser would li…

> Why does every single web site re-implement the registration page slightly differently?! Because registration pages are the top of most sites' conversion funnels, and as such they produce metrics that reflect on not just IT teams but also UX/design and marketing. The amount of tinkering and customization in registration pages is a political/organizational problem, not a UI/tech problem. And besides that, no busines…

> The better question might be why so many companies continue to put cost-inducing barriers like signup in their flow before they fully demonstrate the value-creating potential of their product.

Because it works. If it didn't work, companies wouldn't be doing it.

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

#132
post #84

Getting rid of passwords. Passwords are the easiest way for others to get access to your accounts. A move to federated identity, with a standardized API, and integration with the browsers, would fix all these issues. You could easily use a federated identity provider with support for 2FA, and ALL your accounts would immediately work with 2FA. And, with federated identity, you can also run your own, if you don’t trust…

> And, with federated identity, you can also run your own, if you don’t trust Google or Facebook login. Sounds like OpenID...which was kind of a train wreck. One middle ground could be tighter integration between browsers, sites and password managers. With the right specification, sites could offer a "register with [1Password,KeePass,LastPass,etc]" button which would open the password manager and pre-fill all the fie…

[deleted]

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

#133

Registration forms should be standardized. I want to have my "real" details, and my "fake" details ready to be entered into websites that want yet another registration. Why does every single website implement their own registration form with exactly the same details?! Why does every single web site re-implement the registration page slightly differently?! Ideally, I'd enter the registration page, the browser would li…

I was thinking of writing a spec and implementation on a similar thing a few days ago: Each site would publish a standardized file in a standardized location, and/or add a META tag to the file in each page. The file itself would simply contain the URL to the login page and the parameters that should be passed to it, and the way to pass those parameters. Then, your browser/password manager could simply perform a reque…

Unfortunately that requires mass standardization (adopting the spec), which is probably unlikely given that no one standardizes on the registration form to begin with.

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

#134
post #84

Getting rid of passwords. Passwords are the easiest way for others to get access to your accounts. A move to federated identity, with a standardized API, and integration with the browsers, would fix all these issues. You could easily use a federated identity provider with support for 2FA, and ALL your accounts would immediately work with 2FA. And, with federated identity, you can also run your own, if you don’t trust…

> And, with federated identity, you can also run your own, if you don’t trust Google or Facebook login. Sounds like OpenID...which was kind of a train wreck. One middle ground could be tighter integration between browsers, sites and password managers. With the right specification, sites could offer a "register with [1Password,KeePass,LastPass,etc]" button which would open the password manager and pre-fill all the fie…

That’s another one of these half-assed solutions that the world has too many of, just like credit cards or using SSN as auth.

No.

We’ve solved all these issues before, OpenID was a good solution, and OpenID Connect – a complete rewrite – can be used to replace it, and is used already for Google and Facebook login.

Just use OIDC, on every page, and allow users to choose an identity provider. Problem solved.

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

#135
It's very interesting that most people here mentioned changes only to the top layers while one of the most urgent problem is in the BGP protocol that help route traffic between ISPs. Many times in recent years governments and ISP used it to steal the traffic of entire countries, or to block websites.

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

#136
post #113

Obtrusive prompt (UAC equivalent) required to load any javascript. How the web would be so much functional, to the point and responsive. Just imagine the electricity savings. The world truly would be a better place.

I couldn't disagree more but there's plenty of browser add-ons that allow you to do this.

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

#137
post #10
post #8

JavaScript Standard Library created that every browser has "installed" and updated automatically.

Or just stable JS APIs that you can specify on your scripts.

Apparently this somewhat works. http://jsfiddle.net/Ac6CT/

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

#140
post #96

Strict HTML, CSS and JavaScript parsing. One single error => Site won't be displayed. These lazy web devs need some more discipline!

In theory this is an awesome idea, but it faulters for a couple reasons imo. One is graceful degradation, in case of bugs in a browser, or a browser doesn't support new syntax, etc. If the spec had byte-for-byte specification for what happened when, this would be fine, and of course that is the case for say, JSON, which has remained roughly the same since inception. But given how fast CSS and JS are moving, it would…

> or a browser doesn't support new syntax,

Then the user needs to update their browser. It's pretty inexcusable these days to not keep your browser up-to-date, and browsers tend to support new language specs before those specs get widespread usage.

Post reply on HN