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. :(
If the connection was using a forward-secret key exchange (like DHE or ECDHE), then no. Unfortunately it's common not to and browsers don't do anything to warn people that they're using a low-security mode.
FWIW, just now I went looking for a firefox plugin that reports (in a human-friendly way) whether or not the SSL connection for a page is using perfect forward secrecy (PFS).
I found "Calomel SSL Validation," which I am about to install. The PFS reporting only works with Firefox 25 and up.
Thanks for finding this. Calomel's website [1] gives much more information about how the scoring is done as well as security in general; very interesting.
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.
There's a third party implementation of that (https://github.com/jaekwon/HNCollapse), but I that doesn't really help a commenting culture that is shaped by not having it built in. HN commenting threads are winner take all with respect to the top level comments. Once one gets entrenched the others die on the vine. To a lesser extent the same thing happens at subsidiary branches as well. It makes for a very unbalanced tree.
HN Collapse is an absolute must and should be implemented by default, IMO. Whenever I'm on a machine/tablet without it, my reading experience is much poorer.
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.
As the OP says, if the same organization -- and even likely the same _server_ -- is being the certificate authority and distributing the signed releases....
> However in this model if someone is able to send you a malicious package they are also likely able to send you a malicious key.
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].
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.
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.
