mjs

> Fares in London cover 91% of operating expense

Note that capital expenses (fixing tunnels, buying new trains) are not included in operating expenses, so London Underground runs at a significant deficit:

2,542m (Operating expenses) + 1,227m (Capital expenditure) - 2,286m (Fares) = 1,483m

http://www.tfl.gov.uk/cdn/static/cms/documents/annual-report...

> It's the golden unsolved, perhaps unsolvable problem in crypto.

Sorry, perhaps my question wasn't clear. I wasn't asking about MITM in the general case, I was asking about this particular case. The certificate chain for Hacker News seems to go AddTrust -> COMODO -> Another COMODO -> *.ycombinator.com. So in this case, if you're MITM'd by MCS Holdings, is MCS Holdings going to be part of the chain (after a CNNIC)?

Is there any way to detect that you're being MITM'd?

Do they actually explain on their website why they do this? I've spent some time in the past looking without success.

Demo page:

https://cdn.rawgit.com/nathanford/type.js/master/index.html

Are there any profiling tools that would have found this? Flame graphs showing the time spent in traverse, perhaps?

It seems like this should have been trivially detectable, since the difference is so dramatic.

I wonder about this too. Banks were also basically unaffected by Heartbleed. Is this because they were very lucky, or because they were very cautious?

Banks do get hacked, and there's probably more going on than we hear about, but even so it seems banks are better at keeping money/secrets safe than Bitcoin exchanges, and probably better than the top-tier internet sites too (Google, Facebook, PayPal, Apple, Amazon).

The author was Spotify's original designer:

http://rsms.me/about/spotify/

Is that in realtime?

You do a great job, thanks.

Similar to:

https://en.wikipedia.org/wiki/Mutilated_chessboard_problem

Interesting position on testing: "I generally don't consider my own software adequately enough tested until its tests have turned up a bug in a compiler/toolchain. So far I've not encountered a compiler bug for libsecp256k1 [...] so I may have to settle for discovering that a ubiquitous system library couldn't square correctly."

(The bug was found via comparing the output of libsecp256k1 and OpenSSL on "specially-constructed random inputs.")

In particular, http://nickcraver.com/blog/2013/11/22/what-it-takes-to-run-s...

It looks like routes are either strings (exact match) or regular expression objects. I don't think there's a way to combine regular expressions in JavaScript.

I don't think this was an unreasonable implementation. Sure, it could be optimized, but no-one needed it enough to do the work. (Even Netflix didn't need a faster matcher, they needed a matcher that didn't slow down between the 1st match and the nth.)

A map version of this (with contour lines for percentage awoken) would be nice. This would also eliminate the small differences in the time people in different areas seem to go to sleep and rise.

The "http" calendar URLs (now?) actually redirect to "https" URLs, but this doesn't help retrospectively, since the only thing that needs to be kept secret is the URL, and that's redirected in plain text…

TripIt's web UI actually present the "private" calendar URL with a "webcal" scheme--is that typically secure? (You can replace "webcal" with "https" and things work just fine, though.)

This is incorrect: unlike Sublime, Atom does not persist unsaved files across restarts.

(If step (2) is "create new file", Sublime will preserve it, even if it's not saved.)

The thing I'm most surprised by is the change in the default cacheability of 404 responses from uncacheable to cacheable. Though I guess since defaulting to cacheable doesn't mean that responses must be cached, so you can still be compliant with RFC7231 by never caching 404s.

RFC2616:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13...

"A response received with [a status code other than 200, 203, 206, 300, 301 or 410] MUST NOT be returned in a reply to a subsequent request unless there are cache-control directives or another header(s) that explicitly allow it."

RFC7231:

http://tools.ietf.org/html/rfc7231#section-6.5.4

"A 404 response is cacheable by default"

At least if you have a recovery email address configured, you can only initiate the process that sends codes to phones via a link sent to the recovery email address.

So being able to intercept codes sent to a phone is not enough: you also need to have control over the recovery email address.

When this has happened to me, I ask for proof that they are from the company concerned, or that they already have my details. So far they've always been happy to do this, although I always have to go first…

Hitting just ~ will also launch that dialog, although the text box only has "~" in it. And cmd-. cancels it. (Works pretty much everywhere that has a "Cancel" menu item.)

Closed stores do seem to be missing. There were several that were around (~1985 - ~1995) in Victoria, Australia that are not listed.

Semi-citation for one: https://uk.answers.yahoo.com/question/index?qid=200701301934... (Think the dates are wrong.)

Letting clients choose the fields they want to receive leads to the awkward realization that any generic, flexible and future-proof mechanism for doing this leads to system where a client can suck down an entire website with a single request.

(If clients can choose not to receive some information, then by symmetry, they should also be able to choose to receive some additional information that's not included by default. And since everything is linked to everything else (orders are linked to users, etc.), you end up with a single resource that potentially embeds everything else.)

These systems also break caching, of course, and also to some extent the principle that within-server links are indistinguishable from cross-server links. The web is not optimized for performance or file size.

Is it true that Chrome has special-cased the revocation of a handful of domains, including revoked.grc.com, because they aren't blocked by CRLSets?

I more or less follow the argument that CRLSets are superior overall, but special-casing a few domains (especially benign test domains) because this mechanism doesn't block them seems like a cheat.

Authentication shenanigans and needing to use PATCH in a sane way are much better reasons for using a custom client than all six reasons listed in the original article...

I don't get what you mean about data paths, though. Even if you had a hypothetical good REST client you'd still want a single point to do the URL string assembly to save typing and do some validation but this doesn't really require a whole different client.

Agreed; REST clients/frameworks should have ways of handling all six of these problems--none of them are specific to a particular API.

If the client lib has an API-specific way of handling "caching", say, then the number of ways of handling "caching" is O(n) in the number of APIs you consume. If you use the REST APIs directly, then the HTTP's standard, debugged, documented caching mechanism is the only one you ever need to know.

Anyone know why his Stanford username has apparently changed from "knuth" to "uno"?

http://www-cs-faculty.stanford.edu/~knuth

redirects to

http://www-cs-faculty.stanford.edu/~uno

Sometimes you can get a solution to a problem by saying saying that after spending a bunch of time attempting to solve it, you've decided that a solution is impossible. The desire to prove you wrong is too much for some to withstand, and they go out of their way to provide you with a solution. (A consequence of http://xkcd.com/386/ "someone is wrong on the internet".)

Hopefully someone can expand on this answer but broadly it's so that there's an incentive for transactions to be recorded. (And apparently transaction fees can be adjusted up and down, across the entire system, to ensure this happens.)

For future reference (it's not ready yet):

https://www.mailpile.is/

(Features--privacy, encryption--are supposed to satisfy the most discerning HN reader.)