Default encrypted email communications
That's not part of the web.
Given that most people's email is probably through Web apps these days, that's probably not effectively true.
Ask HN: What feature would you want the web to “force” next, after HTTPS?
121–130 of 279 posts
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#122Evergreen web browsers. Safari and IE11 continue to ruin my life.
What do you mean by this?
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#123Getting 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 fields from a password manager's identity record (i.e. if a user has multiple identity records, the password manager can prompt for the one to use.) If there's a need to choose a username, there should be a standard endpoint for checking uniqueness. Once all information is filled out, the password manager can generate a password based on the site's specifications, post the information back to the site, store the account details and the site's ToS in its database and update the browser page to the success url. There can also be a standard endpoint for password rotation so the password manager can periodically update the password without the user's involvement.
This would still use passwords and for those that explicitly don't want to use a password manager, they could continue doing things the current way. But for the majority of us, it would be just like what you're talking about except that our identities would be stored locally in our password managers, giving us complete control over everything while automating as much as possible.
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#124User prompts for JavaScript from other domains.
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#125- A decent minimum password length, without any funky requirements, just the minimal length. - Being able to prosecute any company that stores passwords in plain text
You don't want to restrict on any password aspect but this:
Is the password known?
Any sort password is know. There are lists of millions of known passwords.
Better would be to get away from passwords entirely.
NB: I've been checking the xkcdpass utility (available on Debian). Generated 50 sets of 100,000,000 passwords each, comprised of six words (the default), then sorted these uniq, and counted the output lines.
Any duplicates would result in fewer than 100,000,000 lines.
All fifty trials had no dupes.
Took most of a week to run that, on an older box :)
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#126Earlier quoted context omitted.
I think the only way this can happen is zero-knowledge password proofs, i.e. browsers implement a mechanism by which password fields submit a proof that the user has the password, rather than submitting the password. This way the server can only verify the password if they've implemented the proof system correctly, and they can't leak the password because they've never had it. The basic idea is, the server gives a un…
I love the idea of zero-knowledge password proofs. Others can chime in on the approach you've proposed, but I have a more practical concern about developing critical mass. How do you break through the chicken and egg problem of not enough users using or not enough browsers supporting this capability?
Find a large user who feels this is a valuable feature and have them adopt it.
Governments are one such large customer.
Vendors, faced with multiple customers requesting a feature, but with slightly varying specifications, will tend to seek a mutually acceptable spec.
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#127SSL was forced by Google single-handedly. Developers scared that https might provide ranking factor, quickly moved to SSL.
As for topic, I would like to see all mails clients rendering emails same god damn way.
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#128Registration 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 request in the background, and log you in completely automatically. This solves all the hassle of finding the login form, locating the fields, auto-filling, typing some characters if the change wasn't detected, handling single-page apps, etc.
This could later be extended to signing up automatically. It would make having strong, unique passwords for each site the convenient alternative.
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#129Strict 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…
[deleted]
Re: Ask HN: What feature would you want the web to “force” next, after HTTPS?
#130I think this is only really worth the headache for security issues. That said:
- HSTS
- DNSSEC
- IPv6
in that order. I think for a long time, governments had no interest in pushing security and encryption because that would prevent them from mass data collection. I think minds are starting to change around that: poor security is much more likely to be exploited against a government rather than used in its favor (plus all the real criminals now have much better opsec these days so mass surveillance is much less effective).