Ask HN: Dang, could the login page get a title?

[contr-error]

RFE: Could the login page [0] get an HTML title element containing the string "Hacker News", say "Login | Hacker News"?

This would be immediately useful for password managers matching on window titles.

[0] https://news.ycombinator.com/login

[distcs]

> This would be immediately useful for password managers matching on window titles.

Password managers matching on window titles to decide what password to autofill sounds very dangerous! What password manager is this?

[gruez]

desktop password managers without browser integration, like keepass.

[rationalist]

KeePassXC has a Firefox addon.

(I can't always help but think "KeepA.." I wonder if that was intentional when they named it.)

[theandrewbailey]

I've never noticed browser plugins for KeePass and KeePassXC having problems with the login form on HN. They look for password fields, pull in any logins for that domain, and show an autocomplete list when selected.

[tredre3]

> I've never noticed browser plugins for KeePass and KeePassXC having problems with the login form on HN.

They don't, but that's not what's being discussed here. What's being discussed here is the autotyper in keepass (the window that appears when you press ctrl+alt+a and shows you all your logins filtered by the previously focused window title).

[Someone1234]

If they're going to update that page just add it to the list:

- Title (ideally unique, like Login | Hacker News)

- Use of section heading elements for "Login" and "Create Account"

- A background color

- Set the autocomplete attribute on the two password inputs to "current-password" for login and "new-password" for Create Account. Give both username inputs the autocomplete "username"[0]

- Give the two username and password inputs unique names (e.g. username, new-username, password, new-password)

- Stop being "clever" and change to standard HTML forms. Currently, both login/create forms point to the same endpoint, with the button's "value" mutating what that end-point does. This is completely non-standard and therefore difficult for any password manager to navigate without hard-coding. Instead, have each submit to a different endpoint (e.g. login, and create-account respectively).

- The forgotten password page also points to an endpoint called "x" and the username input has a different name than either one found on the login page "s" and no autocomplete hint.

If someone wanted to target HN with a bot, circumventing this would be trivial. It only really negatively impacts legitimate users trying to use password managers.

[0] https://developer.apple.com/documentation/security/password_...

[atomicnumber3]

Is it nonstandard? It's OOTB explicit behavior in Rails. Every form submit has an entry for what the submit button value was, and you can specify it in the ERB.

[Someone1234]

It is nonstandard to overload endpoints and then use the submit value to route; the submit value itself is standard.

[LinuxBender]

The best way to reach dang is email [e-mail]

[runjake]

A password manager matching on window titles would be a security vulnerability without additional domain checking.

[userm0d]

I am curious, what password manager uses the window title instead of the current URL?

Feels like a really ineffective approach.

[beardyw]

Sounds dangerous.

[jer0me]

“If your page has a title, you’ve launched too late!”

[neovialogistics]

Modifying Login elements is something a blackhat would request.

[billconan]

why can't the HN codebase be opensourced? so that we can send PR to help improve.

[softwaredoug]

Well also it creates extra workload for maintainers to handle PRs and issues that come in.

I'd personally rather work on a private codebase, just doing the actual implementation work, and not have to deal with people getting upset that I'm not merging PRs they've sunk a lot of time into.

[gus_massa]

The original version was open sourced (Perl artistic License) http://arclanguage.org/ There is an active fork in https://github.com/arclanguage/anarki but it's totally independent and the current conde in HN can be (very) different.

My guess is that it's very difficult to keep all the details of the secret sauce hidden. They change the details very often. For example the front page is ordered by points/time^1.6, but the 1.6 changes from time to time without notice (I think it was 1.8 for some time, perhaps it's 1.8 or something else now. Some people have analyzed the front page and got compatible results, but I don't remember the exponent they found and I'm too lazy to try).

[krapp]

Dang once mentioned that the actual HN codebase is full of YC business code that would be very difficult to extricate - and that parts of it like the spam filters and flamewar detector they want to keep secret to prevent people from gaming the system. Also that he just doesn't have time to do it.

As far as "secret sauce" goes, the sauce is that the mods actively upweigh, downweigh and filter user accounts all the time. Trying to reverse engineer a working algorithm from this site's behavior is a fool's errand.