2,303 karma · joined October 13, 2010
If you don't take any steps to verify the integrity, then you don't know.
The big difference, as I see it, is that the JS code gets served over and over again to the same clients. Every time you visit the website, it can load a new version of the JS.
Those are probably acceptable in principle. I should have been more specific: I was referring only to the scenario wherein the webserver provides the JS.
Yes, I'd say it's more like that one. The technology is insecure against threat models it is almost certain to face.
> or is it like saying that a heavily-armored tank is insecure (against a nuclear weapon)?
No, I don't think it's like that one. A tank could realistically participate in a nuclear conflict, but that's not necessarily what a tank is intended for. Whereas, JS crypto is presumably intended to protect users when the remote server can't be trusted. (What else would it be for?) It can't offer such protection.
That's the part to which I'm objecting. As I asked above, what is the proper use of JS crypto? What real-world application do you have in mind where JS crypto's level of security is adequate?
The end user can't know when that's the case.
> Also you might serve files that do the encryption from different server that's smaller, better protected, more stable, that less people have access to.
That doesn't provide any assurance to the end user that the JS isn't malicious.
Remember, "compromise" doesn't just refer to a drive-by hack. The site operators themselves may become compromised (or start that way), and deliberately serve malicious JS. Users can't know when that's the case. When it is the case, the strategy you suggested offers no protection, because the "more secure" JS server is still under the control of the bad actor.
For example, consider a web-based mail client. You want to send an encrypted message, say via PGP, and you don't want the server to be able to read it, even if the server is evil. You'd like to be able to do the PGP encryption 100% in-browser, with no browser plugins or extensions necessary.
I think that's the most common category of use-case for browser crypto. Unfortunately, it's one where browser crypto plainly doesn't work. The whole point here is to defend against an evil server, but if the server is evil, it will send you evil crypto JS. TLS doesn't help you. Nobody's impersonating the server or altering the JS file in transit. You're getting an authentic copy of the JS file from the real server. It just happens to be an authentic copy of an evil JS file.
Given that, what can you do with browser crypto, practically speaking?
Here's an interesting idea: Is there some way for this service to prevent unprofessional and scammy developers from spamming my leads? That kind of behavior is very common in the freelance market, and it effectively poisons potential clients for the good freelancers.
To some extent, the paywall will cut down on the number of low-quality freelancers. But in my experience, they're a plague even on some paid sites.
[1] As to whether the government is morally, ethically, or legally entitled to the seized properties, I have no opinion. I don't know anything about the situation.
For end-users, a Unix-like system can be perfectly usable. OS X runs on Darwin, which has slightly less Unix support than I'd prefer, but still waaaay more so than Windows. Ubuntu is, in my opinion, just as easy for the non-technical to learn as Windows or OS X.
Given the benefits to developers, and the absence of a downside for end-users, I see no reason not to root for Unix on The Machine.
Now, it doesn't have to use the Linux kernel, GNU utilities, or any of the other familiar building blocks. It just has to act like systems that do.
Haskell has a nice approach to that problem. Data is immutable by default, but mutable primitives are available. The type system forces you to be explicit about when you're using mutability, so that mutable data can never accidentally creep into logic where you relied on immutability for correctness.
Broadly speaking, most mutable data types fall into two categories: Those that are some flavor of "IO," and those that are some flavor of "ST." In brief, the IO type is Haskell's way of dealing with operations that logically must be performed in the right order. (In-place operations require as much.) You can think of IO as one continuous chain of operations that begins and ends with the lifetime of the program. In other words, you can't just drop in and out of IO at will; the chain must be unbroken.
ST is an interesting variant on the same idea, except it does allow you to drop in and out at will. That is, I can enter ST at any point in my program, including the functionally pure parts. How is this possible? Because it imposes a restriction that's not present with IO: You must not touch the outside world from within ST. In any ST function, you get your own little mutable sandbox, but as with any pure function, you can only see that which is passed to you, and all you can do to the outside world is return a value. So you can, e.g., take an immutable list, create a copy that you sort in-place, then return the sorted list as an immutable value.
IO and ST are each flexible in their own ways. With IO, you can do almost anything, including mutating something that's passed in by reference. That can be important for some programs' performance. ST is flexible in a different way: You can sneak it into pure functions.
So PSA: Updating Rails in an existing app does not cause this header to be added. You must add it yourself in application.rb if it's not already there. See garethadams' footnote #2 above.
Ignoring the wood for a moment, I'm focused on the padlock. Suppose it's not a real padlock. There are stripes on it which, to my eye, look like they might be corrugation. Perhaps it's hollow and can collapse like an accordion.
Edit: Or, per the description of the second-to-last bottle, the lock is broken down into parts and reassembled in the bottle.
Based on my testing, it appears Rails does not add that header either. Do any other frameworks?
OpenGL isn't exactly a product. There's no company that "writes" the OpenGL software. Rather, it's a specification published by a consortium. "Writing" the OpenGL libraries is a task that each GPU maker does independently. So you have a bunch of different implementations of the same API.
For a long time, GPU makers have focused their attention on DirectX and done a lackluster job with their OpenGL implementations. If APIs like DirectX and Metal continue to proliferate, there will be less and less time and less incentive to maintain a good OpenGL implementation.
The fragmentation of OpenGL is enough of a headache, but at least it offers some semblance of "write once, run anywhere." The introduction of Mantle and Metal, plus the longstanding existence of Direct3d, makes me worry that OpenGL will get no love. And then we'll have to write our graphics code, three, four, or goodness knows how many times.
I know: It's not realistic to expect "write once, run anywhere" for any app that pushes the capabilities of the GPU. But what about devs like me (of whom there are many) that aren't trying to achieve AAA graphics, but just want the very basics? For us, "write once, run anywhere" is very attractive and should be possible. I can do everything I want with GL 2.1, I don't need to push a massive number of polys, I don't need a huge textures, and I don't need advanced lighting.
- Caching aggressively to static files. - Using a static site compiler. - An HTTP caching layer, like Varnish or CloudFlare.
All of the above eliminate the need for a database connection per pageview.
Unless you're tunneling SSL, you can't know that ngrok doesn't inspect your traffic. Promises of privacy that are based on the honor system aren't worth much, at least to me. I'm not at all attacking the honesty of the ngrok operator; I'm just stating a generality about security--one that applies regardless of how much you think you trust any particular actor. For two main reasons: 1) The actor may not be as good as you think, and 2) even a truly good actor can be compromised in a variety of ways.
Therefore, to me at least, a promise not to inspect traffic has little or no value. And if that promise has no value to users of ngrok, perhaps it could be relaxed in favor of protecting the long-term viability of the service.
That being said, the caveat stated above still applies. There's no point in relaxing the promise unless there exists a viable flagging strategy. And such a strategy may not exist, owing to the problems I described in my previous post.
Though there may be bulletproof ways for criminals to bypass such automatic scanning. For example, I've heard of criminals creating two versions of their site: One, a harmless site, that you get if you type in the domain name cold, and then a criminal one, that you only get if you have the right referrer header or query string. Which makes it difficult or impossible for an outside entity to see the illegal content without access to the spam email, referring site, or what have you.
I don't know much about ngrok, but I take it you can tunnel SSL over it such that it's impossible for ngrok to inspect the contents of your traffic. Which would rule another viable strategy: Monitor traffic for suspicious keywords, thus bypassing the cloaking techniques described above.
Any other techniques for automated flagging that I might be missing? Maybe some kind of content-agnostic traffic analysis that spots a likely spam fingerprint, e.g. certain chronological traffic patterns?