Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
buu700
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
86 ms
·
871.
▲
by
buu700
10y ago
Not that this should be necessary, but it'd actually be pretty simple for a compiler to fix #2: transform `const i: int = 3;` into `var i = new Int32Array([3]);` and change future references from `i` to `i[0]`. No clue what the perform
872.
▲
by
buu700
10y ago
Exactly this, to be honest. I use Lyft whenever Uber is too far away, but always prefer Uber given the choice primarily for this reason. (That, and Uber has a superior airport pickup UI, last I checked.) It's not about money; it's
873.
▲
by
buu700
10y ago
lol, I'm definitely biased given that I'm long since familiar with the idea and wrote the implementation, but I think it's more conceptually counterintuitive/clever/weird than it is actually complicated in terms of
874.
▲
by
buu700
10y ago
I think he was only (or mostly) talking about the latter, which I would agree isn't very complicated at all (it's just deleting and regenerating keys/certs on an interval). As to the former, are you referring to specific know
875.
▲
by
buu700
10y ago
I wasn't actually commenting on this project in particular or whether or not the author happens to be an expert (tptacek may have more to say about that), just on the idea of NaCl as a replacement for expertise.
876.
▲
by
buu700
10y ago
While NaCl/Sodium does simplify the crypto aspect in particular, it's dangerous to assume that it entirely solves the broader problem of writing secure code. Implementing anything securely is hard enough before involving crypto th
877.
▲
by
buu700
10y ago
I've found this to be the case much more often than "occasionally" since I've started habitually comparing third-party software's behaviour to relevant specs/documentation rather than assuming whatever the impl
878.
▲
by
buu700
11y ago
Ah, cool, that makes more sense (I couldn't think of a reason for that to possibly happen on the first use, since at that point the pinned TLS key wouldn't yet have been invalidated).
879.
▲
by
buu700
11y ago
Sorry, yeah, that is a known issue in Firefox that we're trying to have resolved; it apparently cleans up ServiceWorkers/AppCaches that haven't been actively used recently. Was this your first time opening cyph.im, or had you
880.
▲
by
buu700
11y ago
That isn't exactly a Web-app-specific problem. If you have native software running malicious code with user-level access (whether it's in your browser or any other random update from your package manager), you should consider the
881.
▲
by
buu700
11y ago
Fair enough! I'm comfortable with it in terms of security given that HPKP is at least a security feature that makes certain guarantees, but I fully acknowledge that: 1. A future update to browser implementations and/or Web standar
882.
▲
by
buu700
11y ago
Yep, that's it. (To clarify, the signed package is freshly downloaded each time; it's just the root of the origin of the application that's pinned via "HPKP suicide" invalidation.)
883.
▲
by
buu700
11y ago
There was a thread a couple months back where I brought up WebSign (Cyph's TOFU in-browser code signing layer) in response to a story about MEGAChat, which you generally disapproved of but didn't go into detail on why. There was a
884.
▲
by
buu700
11y ago
The problem is that they're trusting the integrity of that client-side code to their servers on each use, which is in practice not meaningfully different from a traditional non-E2EE email service. The only difference in attack pattern,
885.
▲
by
buu700
11y ago
Cyph cofounder here; thanks for the mention! It'd be great to hear thoughts from Moxie or anyone else on WebSign. By the way, I think this was the doc you meant to link to for [2]: http://cyph.team/websigndoc .
886.
▲
by
buu700
11y ago
Yep, that's it.
887.
▲
by
buu700
11y ago
Can we build a secure code delivery system for the web, too? If we had a one built into our browsers, security would be a whole lot better. There would be no more compromised websites serving malware, and we could finally bring usable cryp
888.
▲
by
buu700
11y ago
So, if you're still reading this thread, I have one last question: what advantage do you think a browser extension has over WebSign as I've described it? I'm asking explicitly because, since you still maintain that the extens
889.
▲
by
buu700
11y ago
I felt that that was a perfectly fair statement on Thomas's part. It's fine if people are willing to risk their lives for a cause, but they shouldn't be misled into outright sacrificing their lives because someone irresponsib
890.
▲
by
buu700
11y ago
I'm just not sure how you expect me to take your position seriously and blindly follow it, when your reaction to the information I've presented is to pretend that there's literally no difference between WebSign/Cyph and
891.
▲
by
buu700
11y ago
Sure, "zero", except the researchers who actually audited it and concluded exactly that: http://pastebin.com/HcL5bneg Every reply you've made here seems to have been either an appeal to your own authority or
892.
▲
by
buu700
11y ago
all of them are likely to be able to compromise a messaging application that boots from a web page So this is really the fundamental disagreement. What makes you think that running a WebSigned app in a browser is significantly more exploi
893.
▲
by
buu700
11y ago
There are very specific concerns I have about implementing secure cryptography in a browser runtime. ... What are your thoughts on our strict uses of asm.js for the actual encryption (libsodium) and static typing for the rest of the code
894.
▲
by
buu700
11y ago
Am I understanding correctly that you consider your adversary to be the National Security Agency, the world's best funded, best equipped, best staffed SIGINT agency, and that you think they're limited to passive observation? No,
895.
▲
by
buu700
11y ago
Not denying the increased attack surface, but that bypass was immediately fixed and verified by Cure53 (so no known vulnerabilities exist); furthermore, as you'll see in both our foreword to that report and the linked reddit comment, t
896.
▲
by
buu700
11y ago
Definitely agreed re: the meaninglessness of my promises; if someone's threat model were to include that degree of trust in a complete stranger, then there would be no point in that person using encryption to begin with. Also agreed on
897.
▲
by
buu700
11y ago
Which browser are you using? I'll have to test to confirm in iOS Safari, but the notifications at least work fine for me in Chrome and Firefox on Android. However, native mobile apps are definitely on the roadmap.
898.
▲
by
buu700
11y ago
Hey Thomas, thanks for the comment; I'd been wanting a chance to get your thoughts on WebSign for ages! While our audit demonstrates that this scheme shouldn't be expected to be cracked without a critical vulnerability making its
899.
▲
by
buu700
11y ago
It doesn't protect users from that yet (neither does Signal or any other alternative), but we are about to implement reproducible builds to help mitigate that by allowing users to independently verify that the deployed production build
900.
▲
by
buu700
11y ago
Cure53. The report is public on both their website and ours: http://cyph.team/cure53report . (That link contains a page of additional context to explain the findings, e.g. some were pre-production.)
More ›