Hacker News new | past | comments | ask | show | jobs | submit | chris_l's comments login

My current project is TrendBowl (https://www.trendbowl.app) which summarises trending entities across multiple sources on the web, including Mastodon and Wikipedia. On a 24 hour basis you can see which terms are relevant in different languages and sites.

It is implemented in Go, Python and JS, with support from Postgres, TimescaleDB and Kubernetes.


Why no Twitter/X? I believe they have an API that you can use, but they've locked down scraping pretty hard. The API should be cheap however, if you're only scraping trending once per day.


Originally I had Twitter support, but they changed the API around and it ended up not working any more, see the project blog for more info: https://blog.trendbowl.app/

The Pro subscription to the API now seems to be $5000 per month!


Wow, pricey!


Someone should make a collection of the various visualization web projects that crop up here from time to time.


More like the bug list!


Shameless plug: you might want to accompany a book with explained animations of Algorithms and Data Structures: https://www.chrislaux.com


So they hash both versions of the password? Or how does this work?


They probably just do two password checks.


Yeah we did it this way on an app I worked on in the past, try the verbatim input and then a couple of minor variations in casing if it didn't work.

I've also found that for email fields you need to be careful to normalize the input (trim, casing) as safari had a habit of autocorrecting the first character to be a capital


It’s very nice that you do that!

I find apps that don’t trim the whitespace for the email field so annoying in terms of UX. I usually use a Text Replacement shortcut to fill in my emails (e.g. “gml” fills in my GMail address, “cld” my iCloud address etc.) and that always inserts a space after the email and I have to manually fiddle with the cursor to delete it.


>I've also found that for email fields you need to be careful to normalize the input (trim, casing) as safari had a habit of autocorrecting the first character to be a capital

Why is that relevant? The standard technically allows for case sensitivity but nobody does it


It can be problematic when you go to look up the account by email address during login and it isn't found due to inconsistent casing.

It's technically true that the part before the domain can be case sensitive, but as nobody does this the gain in UX from people not having to know the exact casing used during sign-up is worth it to me.


That's what I meant... hash both versions when logging in.


Ah, it's a bit ambiguous though: not GP, but I read you as meaning do they store both versions' hash and check against either.

Actually I realise GP is equally ambiguous. But I read that as (and my own assumption would be) frontend retries with the variation, backend verifies against the same only one stored.


Or just normalize the password by making the first character either lower- or uppercase both when checking and setting it.


It would be more complicated to do this once you stored millions of passwords.

So now you have to create 2 flows, those before the new policy and those that were set after the normalization.


If your storing millions of passwords surely a version field and an if statement is not going to be a huge concern


It is definitely more complicated than changing the case and running the hash again


is_password_valid = hash_password(normalize_password_case(password) if version == 1 else password) == hashed_password


Are we doing this client side or server side?

If you're actually using a 'strong enough' hash to prevent easy cracking if your hashed password database is leaked then you're doubling the server load which can be quite substantial in some cases.


It's only being hashed once...

And obviously this is server side


Why?


Because you are changing the daabase schema to introduce a stupid version field to store "normalized" passwords rather then just doing the check twice on mobile platforms.


Hashing takes a lot of CPU time. And btw you don't even need to change the database schema. You could encode the version in the password field itself. Django does this and it works great


The database would contain existing passwords without normalization. You also you have to hold the unnormalized password. Super silly to do that to save a few processor cycles on login.


It's amazing how much misinformation is in this thread. You should do further reading on password hashing and rethink whether you really have to store two different passwords...


Hashing one or two 10 char strings takes basically no time on even old mobile hardware.


Good password hash algorithms specifically are designed to take a while. They add latency to the subsequent page load when you click “submit”.


Not if you are using algorithms specifically designed to take a lot of CPU time, which is a best practice

https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpubli...


Sounds like the requirement might be for the case insensitivity of the first character to only be for some platforms (eg mobile devices where autocapitalisation might have happened).

In that case this solution would have the disadvantage that it wouldn’t be platform specific.


From the first answer:

> Looks like the app is clever enough to try changing the case of the first letter if the first attempt fails.

Still, looks like a compromise between usability and security/reduced password entropy.


They send it once over the wire but salt it twice if the first attempt fails and the request originated from a mobile app. UX is all around us.


I believe they don't hash the password. They can't know the capitalised version of my password unchanged from nearly 17 year ago.


Of course they hash the password. Of course they don't know the capitalised version of your saved password, but they can know the capitalised version of the password you just entered


But how did they know which punctualion characters to remove from the password?

You may try 2 versions of first letter, but do they go as far as bruteforce removing all the % character combinations from the password, unless they did remove them all?


...and if they remove the capital?


Sadly it can also mean that they save your password in a form that enables them to read it if they need/want it.


Assuming the password is sent over the wire (rather than the salt being sent to the client, the client doing the hash, and sending the hash), the password will be stored in memory while the login process runs

Normal password code would be

  if (doHash(password+salt) == storedHash) {
   failedLogins = 0;
   return 1;
  }
  failedLogins++;
  return 0;
This would presumably be

  if (doHash(password+salt) == storedHash) {
   failedLogins = 0;
   return 1;
  }
  if (doHash(swapFirstLetterIfClientIsMobile(password)+salt) == storedHash) {
   failedLogins = 0;
   return 1;
  }
  failedLogins++;
  return 0;
So while the password is 'stored' in the server side heap, it's no different to normal password 'storage'

If the hash is done in the client it's the same, just the client sends two attempts rather than one.


Even if it’s encrypted, they could send both forms.

Edit: not a good idea.


I'm no security expert, but this would let someone try two unrelated passwords at once and so probably wouldn't be done client-side.


In practice is there really any difference between allowing a client to try 10 passwords before 'lock out' (say no more attempts for 10 minutes), or try 5 passwords before hand.


Ouch, you are right.


Unlikely from Google though. They might have a lot of questionable practices, but their security is top draw.


Certainly it’s not definitive though. This could easily be accomplished by storing multiple hashes, or multiple password checks that alter the user input, but still have Google keeping hashed passwords. Definitive example could be something like them doing a password recovery where they send you a plaintext version of your current password.


Sure it can mean that, in the same way that verifying a password at all can mean that.


Thanks feiss and everyone here for the kind words, they keep me motivated to create more content...


I mainly used svg.js which animates SVG as part of an HTML5 document. Other than that the site is static with a lot of custom JS.


Is this going to be world-wide or US-only? The former will probably mean a lot of legal hassle, but it would be nice to be able to participate from elsewhere in the world...


Why don't you weight votes by age of the account? That would make the "old HN" more influential in the current one.


Interestingly enough, in this case that would have worked. If you only counted the votes of the oldest accounts, the comment in question would have had negative points.


So shouldn't the electron density be a sphere? It has this strange ring around outside...


The 2D projection of a spherical shell isn't a uniform disc – it does indeed look more or less like a ring. (Consider the rough analogy of a swinging pendulum – it spends most of its time near the edges of its swing.)


An orbital is not a spherical shell.

Edit: These are probably higher energy states. e.g., the 6s orbital: http://en.wikipedia.org/wiki/File:HydrogenOrbitalsN6L0M0.png

edit 2: Previous comment was still not correct. More plots of electron density for different energy states: http://cronodon.com/Atomic/AtomTech4.html


From the page you linked: "Notice that the electron is most likely to be found at one Bohr radius from the centre, in approximate agreement with the classical atomic model." That's approximately a spherical shell.

Why would these be such high-energy states?


Hydrogen electrons 'orbit' in shells, not a uniform sphere


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: