It would only give you the last character of the password though. You can use CSS selectors to check the start [value^=a] and anything in the middle [value*=a] as well though which can be revealing I imagine.
Well there's the start [value^=a], the end [value$=a] and the "anywhere" [value*=a] selectors.
In something like 13000 selectors you could easily get the first 2, last 2, and any characters in the middle that are in the password making targeted attacks significantly easier. (This is based on very-very rough napkin math assuming an ~80 character dictionary for upper/lower, numbers, and "symbols" since I didn't want to count)
That's a lot, but it's well within the realm of possibility (it looks like that would end up as about a 1mb css file)
Why was it hard to read for you? I'm having no trouble. I'm wondering if a lot of the CSS is more tailored towards macOS/Chrome? Also, the site being responsive makes `Command +`ing work beautifully (if the issue is font-size, but it's 18px which is larger than most sites I come across).
I read the article on Chrome with uBlock Origin, and enjoyed commentary about ad blockers and anti-patterns between massive ads for Method dish soap the same size as the preceding paragraphs.
Their webpages are constantly moving, changing and breaking. The domain itself has moved 4 times in 4 years. There's just incredible churn on that side of the project, unfortunately.
I tried fetch, the polymorphic-fetch module that builds on this github one and found it doesn't support .finally(), or work with the promise.finally polyfill (yes I know it's not in the spec, but seriously).
Also sinon.js couldn't mock it, and dealing with error cases is inelegant (it doesn't look like much extra code, but is hard to justify if you're just writing a small component that hits one endpoint, in terms of weird new code to explain to your teammates that is).
I have gone back to $.ajax for now, though I do mean to try out qwest [1] when I get the chance. Seems to be both tiny and also have a sane promise-y API.
Because needing to do something regardless of success or failure is incredibly common (e.g. stop a progress bar, re-enable form inputs & buttons).
The (promises) spec is lacking w.r.t. this use-case, and most ajax libraries (and a lot or promise libraries) recognise this by implementing a 'finally' equivalent.
Honest question, what is wrong with request (and superagent)? Is it just size or something more? I am only asking because yesterday I was looking for a promise supported library and I was comparing superagent (with its promise wrapper), request-promise, axios and node-fetch. I have narrowed it down to axios and fetch but I would like to hear your opinion on the matter.
The size. For a Node app, maybe not so bad (though I'd use node-fetch or got[1] which are smaller). For a browser app, loading all of superagent (which is almost 2 megabytes) just to make a few GET and POST calls is silly.
Never used axios but I've heard good things about it and its creator is awesome. I just use fetch because it does what I want.
Wow, had no idea that request was so bloated. And thanks for mentioning got. I just checked it out and I think that is the lib I will be going with on the backend. I love the stream support, very cool.
It's just minified. The CSS itself isn't terrible besides a couple overly verbose things, but nothing's atrocious. I think the /* 1 */ comment might reveal an issue with the CSS minifier they're using. That's normalize.css, all the other comments are removed besides the one inside a selector.
Damn. We've seen a lot of new editors that mimic sublime text and then fail to do some of the most baseline, important features that make it good. Atom didn't have pane resizing for over a year (and frankly, it's just too damn slow for a smooth editor experience).
I don't hate sublime. The plugin ecosystem is mature, and you're just writing python when you do write it. Is it necessarily the easiest api or easiest to test? Naw. But sublime gets most of the basics very right, and the rest is reasonable enough.
