I think it'd fine having it be however broken it currently is as long as the correction was checked by whoever is submitting the entry before it gets published.
I like the idea of showing keystrokes, but I think that a 1:1 entry has arguably better alternatives.
The default entry on xsecurelock[^0] shows a character jumping on a line between keystrokes, which works well on giving key press feedback while visibly obfuscating password length,
________|_______________________ // after pressing a key it'd move around,
___________________|____________
Also, for anyone looking into preserving this last resort obfuscation behaviour you can do it with,
I've got to say, if you were able to see me typing, you can probably record me doing so, bug my USB keyboard, or buy a $10 wrench. I guess for people streaming it might be worth it? I don't think it's a big enough deal to warrant the fuss around this change though, it's just an ok UX improvement that could be slightly better at retaining the sense of security.
Actually now that I think about it, showing the entered length is very useful, cause I often find myself entering the wrong password for something else, realizing 2/3 the way through and I have two options: to hold backspace for some random amount of time (usually for not nearly long enough cause there's no feedback as to how many characters remain to delete), or enter the wrong one and wait for the long ass delay to let me do it again.
On some systems I've gone as far as removing that delay. It's either that, reusing the same password everywhere, or losing my fucking mind. This should fix that wonderfully.
Maybe it works for <=10 character passwords, but it seems to me that if you are counting asterisks in a longer password because you lost track of you input, then you are better off using C-u to clear the password and enter it from scratch.
That said, with any feedback that confirms my key was pressed I can pretty much always correct a mistake using backspace without trouble (with backspace also having visual feedback).
Not giving away the length is mainly an assistance to people with really short passwords. Knowing that someone has a 12 character password doesn't help attackers much, but knowing that someone has a 6 character password would be really useful.
It's still not very useful to hide the length. If you don't know the length and just start guessing with passwords of length 0 it only adds about 1/N extra guesses where N is the alphabet size compared to guessing strictly the right length. So it is a very small savings to know the password length.
It might matter a bit more for dictionary-based attacks (you don't have to bother hashing dictionary permutations that don't match the expected length) but I still suspect it doesn't save you much.
For opportunistic attacks, this could help you identify those with short passwords and only attack them. This is a factor of N speedup where N is the pool of people you are interested in attacking.
It would be enough to just show a single character (* or some other to distinguish) if there is something typed in and show no character after using backspace to delete the typed password.
It doesn't make sense to show the exact amount of characters. It just leaks the password length.
A single manufacturer convinced a lot of them to work with Apple phones.
It's definitely doable, but the product has to be appealing to users, which also seems doable as phones already peaked in capability and making a good phone now is more about polish in build + software than being technologically ahead of the competition.
I consider my 2yo mid-range phone a great phone, and with today's politics owning my phone is in the top-3 things I'd like my next phone to improve on, not a better camera, screen, battery, slimmer build nor gimmicky stuff (ok, maybe an IR to replace remotes or LoRa support would be kind of cool)
A tiny note on the speed comparison: The 23,000x faster single-key lookup seems a bit misleading to me.
Once you get the computational complexity advantage, then you can make it as much times faster as you want. In these cases small instances matter to judge constants, and to the average (mean?) user, mean instance sizes.
I'm not sure how to sell the advantage succinctly though. Maybe just focus on "real-world" scenarios, but there's no footnote with details on the comparison
That benchmark is a fair comparison for a real-world production workload and use case. Sadly I can't share the details. But suffice it to say that the dataset is a huge object with tens of thousands of paths as keys and moderately large objects as values (averaging around 3KB of JSON each) all with slightly different shapes. The use is reading just a few entries by path an then looking up some properties within those entries.
The benchmark (or is supposed to) measures end-to-end parse + lookup.
JSON: 92 MB
RX: 5.1 MB
Request-path lookup: ~47,000x faster
Time to decode a manifest and look up one URL path:
I think that keeping it fixed on scrolling and giving it low saturation should be enough to keep them from being distracting. And obviously, no animations, although a really slow one might work.
That's not really random access, though. You're effectively just searching through the entire dataset for every targeted read you're after.
What might be interesting is to have a tool that processes full JSON data and creates a b-tree index on specified keys. Then you could run searches against the index that return byte offsets you can use for actual random access on the original JSON.
OTOH, this is basically just recreating a database, just using raw JSON as its storage format.
> What might be interesting is to have a tool that processes full JSON data and creates a b-tree index on specified keys. Then you could run searches against the index that return byte offsets you can use for actual random access on the original JSON.
I did build that once. But keeping track of the index is a pain. Sometimes I was able to generate the index on-demand and cache it in some ephemeral storage, but overall it didn't work out so well.
This system with RX will work better because I get the indexes built-in to the data file and can always convert it back to JSON if needed.
Or in this case, just do `rx file.rx` It has jq like queries built in and supports inputs with either rx or json. Also if you prefer jq, you can do `rx file.rx | jq`
wow, on that case then using `jq` is just a presentation preference at the very last step unless jq is more expressive (which might be the case given how long it has been around?).
right, the jq query language is much more complex and featureful than the simple selector syntax I added to the rx-cli. But more could be added later as needed or it could just stream JSON output. It would be pretty trivial to hook up a streaming JSON encoder to rx-cli which could then pipe to jq for low-latency lookups. The problem is jq would need to JSON parse all that data which will be expensive.
Most of the time it's just part of the bundle. If you are heavy into SQL Server, Office 365 and Power BI then there is a BIG chance you are going to use Azure for whatever the reason.
People who take Azure up without previous MS product experience...not sure about those.
There's a few, mostly retailers who don't want to give money to Amazon as a direct competitor, for them Microsoft/Azure is more of a neutral party, and most businesses already use Microsoft in at least some fashion so already have staff internally familiar with MS products (as opposed to say, going to GCP instead).
For everyone else, it's like you said. "Eh, we are already knee deep in the Microsoft stack, why would we pick anything else?"
a LOT of stuff comes for free or marginal (10-100$ a month) so yes, you do pay but it's already 'baked into' the contracts people generally carry with microsoft, or something for IT to worry about when the yearly renewals show up
reply