enaeseth

Will having the private key allow the decryption of ciphertext that was previously intercepted (while the service was active) and stored? Lavabit was already shut down, so this revocation is equally useless for user security. :(

Reddit posts often get one off-topic top level comment that spawns a huge subtree, but it's easy to deal with there because the uninterested reader can click the [-] button to collapse the whole mess. I wonder if HNers would stop viewing the NSA threads as such a problem if HN implemented comment collapsing.

If the package repository acted as a certificate authority, and generated distributors' certificates by verifying the distributor's appropriate virtual identity (GitHub, BitBucket, DNS), then I think you can at least be pretty sure that the person making the release is someone who would have had access to commit to the project's source code anyway.

Is that at least "good enough"? If the root certificate for the package repo's CA were itself signed by a real-world CA, then I think what you end up trusting is the security of the repo, of GitHub, and of the project's developer(s). Projects with multiple committers could have several of them receive certificates, and require a quorum of signatures before a release is published, to mitigate the risk of any one core dev being compromised.

To keep package names trustable, I think the only sane scheme would be using the project's URL on the service which was used to prove its identity; Rails would be "https://github.com/rails/rails", though surely you could use aliases (github:rails/rails) to reduce typing.

Interfaces communicate with their users (at least, if you ask me), and I sometimes find it helpful to explicitly put into words what I think an interface is saying. I interpret The Ladder's cancellation screen as saying, "You cannot cancel your membership without giving us a reason."

Imagine if you were trying to break up with a significant other, and they told you that you were not allowed to end the relationship unless you gave a reason first. That would be horribly controlling, and totally unacceptable.

Of course, a romantic relationship is rather more significant than a subscription, but I think The Ladder's exit process is controlling in the same way, and the only difference is that it occurs in a less important relationship. It still gives me the same feeling that my wishes and agency are being subjugated, and I believe that's a bad thing to do to a person, regardless of the particular situation.

Online login services are generally many-to-one. For example, many sites accept Facebook login, but for a user to log in that way, there is only one identity provider they can use: Facebook. If you don't have a Facebook account, or don't want the site in question to have any access to it, you can't use Facebook login.

When the article says "distributed", it means Persona is many-to-many. Any domain can implement the protocol, so when a site accepts Persona login, you can choose from many identity providers – including your own, if you're industrious and want to set one up for your domain. Most people are using Mozilla's service today, but the idea is that email providers like gmail will implement it themselves in the future.

I don't think it's fair to blame the user for that. This is a standard-looking login form that users will have seen hundreds or thousands of times before. You don't reinterpret the words on a login form every time you see a new one; you type in the stuff to log you in without really thinking about it.

Regardless of Spotify's intentions here, they're benefitting from users' trust in normal login processes to get Facebook account access. Lots of designs exploit users' automatic behaviors like that; see Dark Patterns [1].

[1]: http://darkpatterns.org/

I would think that the fun and interesting events of his year are the ones that don't need this kind of reporting to remember or get insight into. Everyone has mundane parts of their life, and with this report, now even those parts are kind of interesting.

You can try to report it as a bug, but the docs indicate that this is by design.

Here's the source of Flask's `route` decorator:

https://github.com/mitsuhiko/flask/blob/master/flask/app.py#...

When you call `route` with a URL pattern, it returns an inner function which is used as the decorator. That decorator just records your route and function in the Flask URL map, and returns your function unchanged.

So, Flask is arguably perpetuating a slight abuse of decorators, since it doesn't decorate or wrap your function at all, but merely saves a reference to it somewhere. But it's a fairly clean way to make up for the lack of code blocks or multi-statement anonymous functions in Python.

Thanks! It is indeed the first in a series of Python posts that will be on the Thumbtack engineering blog.

Oh, Guido. Thanks, I've updated the post.

All of the array_* functions, as their names suggest, only apply to arrays. Underscore methods work on arrays or any Traversable (Iterator or IteratorAggregate) object. It's nice to have.

We came up with our model of tracking independently, but I found out later that Mixpanel has an eerily similar tracking API (see http://mixpanel.com/api/docs/tour). I think it's a fairly natural design, though, and wasn't surprised to see that someone else had thought of it.

Mixpanel does deal with funnels differently, however. With their API, you explicitly define events as being some numbered step in a funnel; in ours, the events are agnostic about what funnels they participate in, and we piece them together in a post-processing step.

We're storing complex, loosely-structured data, which perfectly fits MongoDB's schemaless document model. The fact that it will easily scale up with us is just icing on the cake.

The most important concern we had about Mixpanel was cost: at the volume of data we collect, their tracking would be quite expensive. It also doesn't support as flexible of segment comparisons as our analytics tools, and requires you to send all events to them over unencrypted HTTP.

But really, we considered this important enough to do in-house. The ease of working with MongoDB made it feasible.