traviscj

Derp, I missed the obvious. Thanks.

I had heard of uMatrix but didn't realize it had that functionality, which is pretty cool! Thanks for sharing!

Browser fingerprinting is an easy path toward a “stronger than ip” correlation. [1] is an interesting starting point.

1: https://panopticlick.eff.org

Seems like browser-based PUT is at once "too" generic and simultaneously not self-describing enough for a lot of input. (Should I be allowed to change my wife's facebook details?)

The protocol supports rejecting those edits, but what if I want the form itself to change in response to edits I'm proposing? (Greying out the "change password" button, or telling me "You can't change the relationship status of others!")

Stepping up from my examples a bit, it seems like you'd need a pretty sophisticated model for ACLs and almost arbitrary client side validations, which we didn't have until javascript.

This does not solve the problem GP has raised.

More discussion at https://news.ycombinator.com/item?id=16582266, though it is interesting to hear it straight from the Google's mouth.

We have a similar thing at work: if we're deploying, and start getting paged for error rates, the default action is "roll back!" We explicitly don't try to figure it out before we roll back or try some heroics to fix it or whatever. Just roll back!

Why does anyone have "access to live passwords"? That point alone calls into question all of their practices, to me...

An interesting related video: Slow Motion Flipping Cat Physics [1]

[1]: https://www.youtube.com/watch?v=RtWbpyjJqrU

Everything has a failure rate. This introduces another set of heuristics (and another false-{positive,negative} rate), another set of potential implementation bugs in those heuristics. What if being able to run the program on a particularly memory-limited computer could save the universe, even more slowly than the project manager originally wanted it to run?

Statically encoding something like a memory constraint sounds very hard for all but the simplest algorithms. What about a randomized algorithm that sometimes uses more heap? How do you get around not knowing how much it's going to use without running it?

More simple semantics are easier to understand. Ergo we should make the semantics as simple as possible.

More complicated semantics save more words. Ergo we should make the semantics as complicated as possible.

(This specific example is probably a false dichotomy--"the concept of truthiness" might be neither as simple nor as complicated as possible.)

This seems pointless because an attacker could just proxy the login back to your bank. Well, not pointless -- it raises the bar attackers have to pass -- but not a real solution. Or am I missing something?

> Perhaps I've missed something

The road that the taxes (probably) paid for?

Also, GP said "allows", not "subsidizes every aspect of the most luxurious way for".

This is really cool. I end up doing a lot of this kind of stuff at work, so I plan on using the bejesus out of this.

Even if you are uncomfortable assuming that, search results for "org-mode"/"orgmode" are unambiguous and helpful for anyone out-of-the-loop and curious, so it doesn't seem exclusionary or like a secret in-joke reserved for a secret society of HN elite.

The "implicit argument" feature seems really neat. I've grown really tired of needing to thread some random flag through all of creation to pass it to some dark corner of the code.

Make the ugly one. Be encouraged by the functionality, rather than the form. There is nothing wrong with a prototype that solves a problem but needs a facelift.

If people are willing to use it, figure out how to improve the visual design -- delegate, sell it, design sabbatical, take some classes, whatever. This may require throwing some work away, but it's still a functioning thing.

On the other hand, makes it sound more likely to be a routing/reverse proxy issue instead of (say) a database issue. Those sound easier to deal with via a rollback vs something like "oops we dropped a critical index on the `messages` table".

What's the thread model here? You lost your card/it was stolen, but you haven't noticed and canceled it yet? Isn't it more likely that your card data is scraped up in a data breach or something, in which case your card is still in your wallet? Even if it was very recently lost/stolen, you're not liable for illegitimate charges as long as you report them promptly, so wouldn't it be better to just keep track of your cards?

I've used wikis like Mediawiki and blogs like Jekyll to great effect for this purpose.

Furthermore, it is only definitive until it isn't. If we trained users to look for the github page, we'd have forked projects that point to the compromised extension, fake github clones that look like the project, fraudulent likes, and so forth.

Which restaurant do you call? Do you find it on Yelp/Some other review website? Are those reviews of the dine in experience or the dine out experience? Will the person I speak to get my order correct?

I dunno. I'm put off by the "% revenue buys place in the list" model, but I have a hard time saying that the online order aspect doesn't add some value.

Those who don't understand history are destined to repeat it?

also that approach seems dependent on all projects you might want to grep (in this example) building cleanly into an external directory, which is naturally never going to be 100%: some people don't know why other software supports those options, some people don't care, some people think that's the wrong solution to the problem, etc. Ultimately someone comes along and builds up a big enough body of experience that they can account for and fix some fraction of the brain dead behavior out in the wild, and the rest of us get a useful tool.

There definitely are bad databases. You can easily make a system that is NOT consistent and NOT available and NOT partition tolerant, for example.

Your equation does not make sense to me. Is b really a slope (* instead of +?) or an intercept (seems simpler to have a "k*x" term than pretending that "k=1")?

I'd buy that index.

I prefer cat because > vs < is an easy typo to make but one clobbers the file. Happy to pay the performance penalty as insurance against that.

Seems like there's a (difficulty/physical file size)/(profit or effort)*(likelihood of success) score that matters in these things: a terabyte of credit card numbers (alone) would be 62.5 billion card numbers, but a terabyte of facebook chat messages/private pictures is some small fraction of data. It'd be much easier for O(20 mb) to move off the network than O(500 GB). The former can be profitably resold, while the latter requires a careful search to find high value data (e.g. pictures like the fappening, I guess?) and no foolproof profit mechanism. And the sheer size brings other problems like how to store it and how to exfiltrate it and deal with it without being noticed. And of course, if you ARE good at all of the above, why not give in to a chill life in SF instead of a "life of crime" and all the volatility/violence/cloak-and-dagger that goes with it?

Not saying a Facebook/Google data breach isn't terrifying -- it certainly is, and the privacy implications are indeed upsetting -- but the profitability path is just not as clear.

The "Russian propagandists" angle from the article is interesting, but seems a bit separate from the "FB has a shitload of data on people" problem. It's basically using the ad/social aspects of the service as designed: changing people's perspectives on something you want them to feel differently about. (Albeit aimed at a different target!) Not sure how to solve that problem.

Card numbers.

Also channeled Baz Luhrman's "Wear Sunscreen" for a second there.

Re #10: I want the same thing for tabs. Like I'll pull up some metrics at work, want to give it another 5-10, pop open an email tab, etc. then a week later finally like, "wow this is useless now".

(So maybe a "about to expire" warning too?)

I want the same thing for promotional emails.