minitech

75 ms·

871.
by minitech 11y ago
> You could argue that the API is bad for allowing HTML strings as arguments That is exactly what I’m arguing, yes. > but it's not really surprising that a function does what it is documented to do It doesn’t have to be surpris
872.
by minitech 11y ago
Yep. XSS isn’t at all hard to prevent if you’re using tools that are safe by default. Unfortunately, popular ones like jQuery aren’t. (This, more than any other, is a reason to prefer the DOM API.)
873.
by minitech 11y ago
No, the point of that style of password is that you choose the words randomly. Random words are just easier to remember than random characters.
874.
by minitech 11y ago
Minimalism comes in many forms. Here, we see an example of a content-free article. > fun aside, name and service are both const char* so I find it funny that they are set in the program, I do understand that from the callers perspective
875.
by minitech 11y ago
The speeds you were seeing might have had less to do with the fact that it was JS and were more about the mobile device being much slower than the server, then. This isn’t really avoidable, but a 40x slowdown isn’t the end of the world for
876.
by minitech 11y ago
> If … your system doesn't use randomly generated per user salts … then you’ve already lost, constant-time comparison or not. Also, rainbow tables are obsolete.
877.
by minitech 11y ago
I just measured it, and native bcrypt seems to be about 5× as fast as bcryptjs. As long as the time for one hash is more than 0.0001 s, you’re doing pretty well as far as password storage goes, so a pure JavaScript bcrypt is bad mostly beca
878.
by minitech 11y ago
“query parameters” here are the parameters passed to PostgreSQL. That is, "SELECT * FROM users WHERE password_hash = get_hash('P4ssw0rd')" is being logged, not "?password=P4ssw0rd".
879.
by minitech 11y ago
> If you can deliver it over HTTPS, why can't you deliver everything over HTTPS? > Works across sites and lets you authenticate resources you don't own.
880.
by minitech 11y ago
Stripping tags before encoding is security theatre. Encoding is just replacing 2–4 characters; if it’s not implemented properly, there’s no way tag stripping is.
881.
by minitech 11y ago
“Critical” is the highest. A link to the list of severities is smack in the middle of the message. > Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.ht
882.
by minitech 11y ago
Do you mean “must not be quoted”? $@ shouldn’t be, most of the time.
883.
by minitech 11y ago
To be fair, the correct version isn’t very arithmeticky. memset(numbers, 0, sizeof numbers);
884.
by minitech 11y ago
The CSS px unit is actually usually (for high-DPI devices) defined as 1/96″.
885.
by minitech 11y ago
> Also, HTTP/2 traffic may be encrypted using another scheme (which may be vulnerable to large constant blocks in known locations). This isn’t really a situation worth caring about when designing a protocol. If you’re choosing to en
886.
by minitech 11y ago
> Why not? What allows AES to escape such an attack? What attack? A known plaintext attack is just a type of attack. There aren’t any such known attacks against AES currently. http://crypto.stackexchange.com/a/1083
887.
by minitech 11y ago
The constant rearranging of the “popular” items is pretty irritating.
888.
by minitech 11y ago
Forward secrecy in the event of a compromised key.
889.
by minitech 11y ago
Ah, okay. That’s much more straightforward. The answer, though, remains that regular expressions that are actually regular cannot parse HTML that is actually HTML. Regular expressions can parse HTML up to a certain depth specified in adva
890.
by minitech 11y ago
So your suggestion is that, rather than pressing Caps Lock to escape, one should press Caps Lock and [? How is that better (assuming you’re using VIM)? Regular Ctrl isn’t hard to reach.
891.
by minitech 11y ago
> If you really believe that regular expressions cannot parse any HTML document in reality (eg given that all web browsers in practice limit the nesting depth of HTML) then please present some evidence. You can build a regular expression
892.
by minitech 11y ago
Interesting idea! Wait, here’s another: maybe you could take your regular grammar that accepts some large number of things that a context-free grammar it’s emulating would accept, and implement it using a stack or something. That would save
893.
by minitech 11y ago
> The point remains - for all practical purposes, you can consider all languages to be regular and using a stack is merely an optimisation. This is thoroughly wrong. For “all practical purposes”, you won’t expand a non-regular language i
894.
by minitech 11y ago
> This is exactly the way it's used in shell scripting You say that like it’s a good thing.
895.
by minitech 11y ago
The point of my comment was to say you don’t have to support old or obscure browsers specifically; just have proper content in your HTML and everyone will be satisfied without additional effort on your part.
896.
by minitech 11y ago
Yes, I remember when FrontPage achieved this very same revolution.
897.
by minitech 11y ago
It’s not so much about supporting legacy software as having something that’s likely to show something in any browser, from Firefox to IE6 to Dillo to Lynx.
898.
by minitech 11y ago
“Such an ambitious undertaking”? Not to dismiss the author’s effort at all, but that seems a bit exaggerated.
899.
by minitech 11y ago
Why are your functions named with numbers and why aren’t you using youtube-dl ( https://rg3.github.io/youtube-dl/ )?
900.
by minitech 11y ago
Mods were never involved with this question; it was closed by regular users ( https://stackoverflow.com/posts/5574241/revisions ). It was also never locked – locking is significantly different from closure.

More ›