emily37

It looks like the npm registry used to have a certificate signed by npm's own CA, and existing npm clients only trust that CA by default, not the normal list of verisign, digicert, etc. (Trusting versign et al would defeat the point of using their own CA.) The signing key for that CA is pretty darn important, and maybe there are entities other than npm, inc who might know it (i.e. nodejitsu).

So npm, inc rolled out a new cert that looks to be signed by digicert, but existing clients don't trust Digicert until you explicitly configure them to.

I was thrown off by the SELF_SIGNED_CERT_IN_CHAIN error; I expected some error about an untrusted root CA if the problem was that npm clients didn't trust digicert, but apparently SELF_SIGNED_CERT_IN_CHAIN is what OpenSSL returns when the root CA isn't loaded.

I don't think prolific is the word you mean, but I'll assume you meant "meaningful" or "emotional." No one is telling you how much you should care about Boston versus Texas. The point is that for those of us who are personally affected by the Boston incident, we resent being told that we should care more about the Texas incident, because it is natural that we would be more upset about the incident that personally affected us.

You can't change the words he used to misrepresent his argument because you didn't appreciate his bluntness.

The change of wording wasn't relevant to my point, I was simply trying to summarize his view. Insert "let's make an effort not to get... as an excuse for tyranny" (his actual quote) for the paraphrased quote that I used, and the point still stands: the government's supposed tendency towards tyranny should cause us to resist tyranny, not to temper our emotional reactions to the deaths of community members.

A reasonable statement would have been, "Let's not let these deaths be cited as an excuse for tyranny." But what he said was more along the lines of, "Let's not be very upset about these deaths, because then they will be used as an excuse for tyranny." Why should we let the government's supposed tendency towards tyranny influence our emotional reactions to the deaths of friends and colleagues? Instead, let's react however is natural to these deaths, and at the same time ensure that we don't stand for fear-mongering and security theater.

But I think it's also worth noting that the stay-indoors request was a request, as far as I know. Every notification that I received was something along the lines of people being asked to stay indoors with the doors locked, and I know people who chose to go outdoors before the request was lifted. The city shut down because people chose to honor the request out of confidence in the judgement and good intentions of the police. I personally chose to stay indoors because I thought the suspect was probably wandering around on foot in the Watertown/Cambridge area and I thought the inconvenience of staying inside for a day outweighed the risk of running into him.

I'm not sure if they searched empty homes, but if they did, then they probably believed it to be exigent circumstances.

On the other hand, if they had simply expanded the search area block by block without lifting the stay-indoors request, then they probably would have found him quickly with less risk to Watertown residents. In any case, I agree that it's important for the governments involved to evaluate what could have been done better.

(All that on the police scanner in the last minute or so)

The first is only slightly related to this article; it uses implicit learning to train users to authenticate with secrets that they cannot recall consciously (and therefore can't be coerced into revealing).

The second is about recovering secret information from brain-computer interfaces, and though this seems very relevant to the proposal of authenticating via "passthoughts", neither of these papers seem to cite each other.

(The Berkeley paper is at http://www.kisc.meiji.ac.jp/~ethicj/USEC13/submissions/usec1...)

Some research browser architectures like Atlantis (http://research.microsoft.com/pubs/154698/Atlantis-SOSP.pdf) go the opposite extreme, where cookies are never sent unless their domain matches the initiating origin. In the case of Atlantis, the reason they have to go this route is somewhat messy: their microkernel architecture exposes a network interface to webpages, and the network interface has no way to differentiate between a request initiated by XHR or by an img/script/etc., so the network interface cannot send cookies with any cross-origin requests, or else it risks exposing private data via XHR.

I wonder if it would be useful to see something more flexible than the current standard, sameDomain, or disallowing all cross-origin cookies. When you set a cookie, maybe it would be nice to be able to specify which origins are authorized to send requests with that cookie.

http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug...

https://github.com/benadida/sessionlock

http://www2008.org/papers/pdf/p517-adida.pdf

He uses a token in the fragment identifier to authenticate every request; since the fragment identifier never gets sent to the server, a passive attacker never sees it -- it's a nice trick.

Yes, I have.

You would NEVER disclose your internal processes or architecture, that's nuts, it's like drawing out your whole attack surface for your adversary.

Though it might not be a bad idea, I wasn't actually intentionally suggesting that you open-source all your code and make your internal processes completely transparent. I was suggesting that you maybe add a section in your whitepaper detailing the possible attacks, and that you reconsider phrases in your marketing copy like: "Who can see your data with PrivateSky™? No one, not even us." I find it misleading.

Nevertheless, someone asked a follow on question with these exact same points back on the thread; we have posted answers.

In the stack exchange thread, you talk about what would be needed to compromise the SkyPin authentication process. But I don't see how this is sufficient. Suppose there is an XSS vulnerability on the browser-based inbox on your site. What stops an attacker from inserting a single line of Javascript that opens up a message of his choice in my inbox, decrypts the contents, and sends the contents to the attacker? Suppose that your SSL private key is compromised. What stops the attacker from eavesdropping on my connection to PrivateSky, stealing my session cookie, and using that session cookie to open up my inbox in his browser? Maybe you have some defenses against these attacks, but you don't seem to address them anywhere (at least that I can find).

It also seems you are being a bit disingenuous. You've studied under Dan Boneh, the founder of our competitor. You know very well what these acronyms mean.

The point was that there is a lot of heavy-handed crypto thrown around and not enough discussion of the actual weakest links in your system.

Also, who said this is only going to be "browser based"?

Definitely not me. The current offering is browser-based, and the currently advertised guarantee is that no one can read your data, not even your company.

The proposal is to automatically generate a self-signed cert for each origin. This gets rid of many of the UI problems: it eliminates the need to choose which cert to send to each site (which also means the user can't be tracked across sites via OBCs, and thus the user doesn't need to grant permission before sending his cert).

On the other hand, it doesn't solve the problem of re-authenticating on different machines. It's not proposed as a primary authentication mechanism, but instead as a means of strengthening ordinary HTTP session cookies (http://www.browserauth.net/channel-bound-cookies).

But besides that, as I understand it, this attack doesn't require an HTTP request to the victim site; it only requires an HTTP request to any site, followed by an HTTPS request to the victim site, so STS wouldn't be much help here unless all websites turn on SSL and adopt STS. (Though someone should correct me if I'm wrong.)

I'm confused (though admittedly I haven't read the paper fully and don't have any background in cryptanalysis, so I guess it's not surprising that I'm confused). It looks like 2^126.1 is a worst-case complexity for this attack, so it makes sense to compare that complexity to the worst-case complexity of a brute force attack, doesn't it?