search

mozilla-services / channelserver

🍐 A tool to associate instances of firefox.
Mozilla Public License 2.0
3 stars 6 forks source link

Consider using shorter channel ids #22

Closed rfk closed 5 years ago

rfk commented 6 years ago

This is an open-ended discussion, I think what we have right now is fine for first iteration, but I don't want to lose track of this thought...

Right now we use v4 uuid as channel identifiers. This provides strong uniqueness guarantees, but makes the channel id very long. That's fine for our first version where they're transferred between devices via QR code.

In the future, we expect to have some flows where the user has to type in the connection information by hand, including the channel id and some secret PAKE key. A uuid would be far too long to use in such flows.

What would it look like to make the channel ids here as short as possible, say only three or four base32 alphabet characters long?

jrconlin commented 6 years ago

I'd be fine bumping things up to base 64 (or maybe drop the conflict set (0O1lB8..) if we can't set the font to something SUPER distinct like OCR-A.) A four character code should give us a pool of ~16MM we can work with. 6 would give us a pool of ~41MM.

I'd like to make sure we've got a rich enough pool of entropy that we don't wind up with conflicts. Someone more math inclined than me could probably tell you the proper entropy depth we'd need for the expected loads.

shane-tomlinson commented 6 years ago

@marcozehe - When using pre-formatted text, can screen readers differentiate between upper and lowercase characters?

MarcoZehe commented 6 years ago

Yes, they can, or screen reader users can deal with them in a way they feel comfortable with.

vladikoff commented 5 years ago

@rfk should we keep this issue open?

rfk commented 5 years ago

I don't think we have any short-term plans to work on this, and there's not a lot of context here that we can't re-create, so I'm happy to WONTFIX it for now.