jkire

That being said, it would be really interesting to read a dissection on how much philanthropists (especially new "hacker philanthropists") acknowledge that there are risks, and how they weigh those risks up. After all, the consequences of making mistakes when trying to reform an education system can have a large and lasting effect on the students involved.

[1] https://www.sqlite.org/lang_with.html

I'm failing to see why this is an issue? The examples tutorials/references he gave only mention '\v' in tables of possible escapes. What is the downside to mentioning it, people spending 5 minutes googling for what a vertical tab is?

Unless a language removes support for escaped string literals entirely it seems odd to remove support for a particular standard, if mostly unused, escape sequence.

And yet he's sitting there saying things like "[HN] is a place for men with tiny little mosquito penises".

I once heard a piece of advise (by Caitlin Moran): you should never write angrily. You may be angry, but don't write angrily. People tend to react with the same emotions, if you come across angry then people will tend to respond with anger.

The guy is obviously angry and upset, but its completely masking his point. He obviously feels something is wrong with the way HN is moderated, but based solely on his tone I'm in no way inclined to a) take his point seriously and b) actually start a discussion about the way HN is moderated. If he hadn't been swearing like a sailor, gave some example comments that support his point, etc, then people would be way more inclined to actually get involved.

Except you can classify a lot of traffic as unimportant by domain. If someone is trying to steal my bank account information encrypting all my other traffic isn't going to help. The easiest attack against TLS is to get a valid cert and then MitM, at which point it doesn't matter how much traffic you're sending to that domain.

I would also be interested in knowing if sending more encrypted data down a TLS channel actually makes it harder to brute force; considering the tendencies for browsers to connection pool there will probably be (relatively) few actual distinct TLS connections.

> False. Assets can leak very easily, disclosing what content you are looking at. Just identify which assets are not loaded on every page.

Assets are cached by the browser, making it impossible to know if a newly downloaded page included those assets or not. Only downloading assets in plain that are on the root page or on the majority of pages mitigates this attack.

(Also irrespective of if you used TLS, if you requested the HTML over TLS and it included hashes for all its static content you would have a much stronger guarantee over authenticity of downloaded assets if they came from CDNs. Hashing also makes caching much nicer and friendlier.)

This feels more like an argument along the lines of "its not really worth having a separate method for doing authentication without encryption, it complicates things and probably won't be able to be used very often", which is perfectly valid and an argument I'm sympathetic to. It just doesn't support the notion that all data is important.

> It's not. The exit node still sees your traffic - and this is also why routing everything over Tor is a terrible idea (and incidentally, the same reason devices like the Anonabox are fundamentally broken). If you tunnel personally identifying traffic along with "anonymous" traffic, you're "contaminating" the anonymous traffic with your identity.

But you can tunnel TLS through Tor(?) The idea behind using Tor here is to stop attackers from being able to trivially tell which domains you're looking at.

> Saying that TLS is "not entirely useless" is a very poor argument for not working on making it better.

My, probably badly worded, point is that its not as easy as saying "lets make it better". Making TLS more secure means coming up with a way of issuing certificates in a more trusted fashion; I don't see how you do that without making it harder to get a cert.

The only other tech I'm aware of that is trying to address this is Perspective, but even that is not perfect.

> The "different levels" you suggest are pretty much already implemented as such...

Browsers are getting better at supporting pinning, but I don't think any allow you to manually add domains? Its not something that has been advertised and encouraged. My bank certainly doesn't advertise its certs fingerprints in their branches.

> ...except there is no "authenticate but don't encrypt" level, because it's not a useful or desirable level to have.

And I disagree with you, obviously.

Unless there are actual, provable, benefits to enforcing encryption everywhere, I don't like the idea of anyone removing the ability for me to make the choice. If you think all data should be encrypted, by all means encrypt all your data.

Personally, I don't care if an attacker knows what BBC articles I read. Yes, I know all the dangers that might befall me, but I've made an informed choice based on a risk analysis of my current situation and, well, I just really don't care one way or the other.

For a lot of web pages this is true, but what about sites like restaurant webpages? They have very few actual pages on their site, and they don't change depending on who is making the request. If I request the site over HTTPS, anybody that is sniffing my traffic will know that I'm visiting that domain and thus can request the content themselves. The encryption here is not providing anything.

If you are sending/receiving personalized data, e.g. logins, search requests, etc., then you should be encrypting the requests. You would still be encrypting huge amounts of data for no reason, the CSS and static images used on the site are not being transmitted with or based on any personalized data, so any sniffer will already know that these resources would have been downloaded by you anyway (and I don't care if an attacker sees the CSS of a page I'm looking at anyway).

Requesting these static resources over plain HTTP, but authenticated via hashes or signatures, doesn't provide an attacker with any information they wouldn't already have.

> No, I do not. Tor is yet another dependency that needs to be available, and there are significant usability (and privacy!) concerns with routing all traffic over Tor.

And yet Tor is the only way to actually protect against sniffers tracking which domains you visit. If we really care about encrypting all the content - including non-personalized, static content - then I don't see why we wouldn't also care about protecting the domains we visit.

> "Everything should be encrypted" does not come at any cost. There are real-world problems that need solving before this can be made a reality. Just disabling non-TLS connections does not cut it.

I totally agree with this. However I think I come to a different conclusion.

TLS is usable precisely because of its insecurity that we have to trust so many CAs. The key problem with any encryption architecture is key distribution, more often than not the more secure the key distribution the less usable the end product is. Its (relatively) easy to get a TLS certificate for your domain that everyone else will trust, but precisely because its so easy makes TLS very vulnerable to malicious certificates.

For the most part TLS is fine, it offers a certain level of security, but is still vulnerable. I'm happy to rely on TLS when browsing google search, online shopping etc, however I'm not particularly comfortable with using it for online banking, and I certainly wouldn't trust it for secure person-person communication.

So instead of trying to fix TLS, I think we should have more choice for the different levels of security I desire: 1. No personalised data is being transmitted either way => I only need to authenticate the remote content, not encrypt it. 2. Personalized, but not particularly confidential information being transmitted, e.g. google search, shopping, logins for sites where its not the end of the world if they get stolen => TLS, there's a chance stuff will get intercepted, but it is convenient. 3. Highly confidential information is being transmitted => Some other protocol or cert distribution mechanism, e.g. for online banking I might only trust a certificate given to me directly by my bank IRL.

And SSL should be used in those cases. I'm not saying you should never use SSL, I just don't buy the idea that you need to encrypt everything. Due to all the unencrypted bits like the IP address and DNS (and SNI?), sniffers can already guess what domains you're visiting anyway. Encrypting in those gives nothing that signing the plain text wouldn't.

> ...MitM can easily insert ads in the page without a SSL connection

Not if the response is also signed. (Assuming clients actually checked the signatures of course)

I do believe this. When I visit a static web page over SSL people sniffing my connection are almost always going to have a good idea of which domain I'm looking at (either by IP, or the DNS requests I just fired off, etc.), so the attackers know what content I'm seeing. So why encrypt it? The benefit is that we can trust that static content really did come from that domain and wasn't changed by a MitM, but this can be solved by simply including a signature of the content rather than encrypting everything.

SSL is really not cheap CPU wise; it can limit the usefulness of a small, personal, cheap VPS for hosting even moderately popular content. Signing static content is essentially free, since we can pre-compute them.

If the writer really does believe everything should be encrypted (this necessarily includes metadata), then I assume he would advocate Mozilla deprecate supporting for non-Tor connections? :)

[1] http://matrix.org

No I don't.

I'm not at all a fan of stuffing application logic into the HTML; it means that I need to look both in the JavaScript and in the HTML. I'm also not a fan of generating the structure of a page in JavaScript, but I find this slightly more forgiveable since I know the JS can always manipulate the page.

Then again, I also refuse to view Angular as JavaScript - I find skimming over Angular code incomprehensible.

It also sounds like the writer works in a place that doesn't really need much inter-person communication on an hour by hour basis. As a software develop I find being able to quickly ask those 5 second questions invaluable, questions I wouldn't necessarily have bothered to ask if I had get up or send an email.

> Each day, my associates and I are seated at a table staring at each other, having an ongoing 12-person conversation from 9 a.m. to 5 p.m.

It takes a certain amount of self control to avoid this; just as it takes self control not to spend your entire day browsing HN...

So even if it turns out that facebook is selling off all of its data to the highest bidder people would probably still use it, unless there is an alternative. For chat we're seeing more and more protocols and apps springing up, both proprietary and open source - e.g. XMPP or the much younger/newer http://matrix.org (which I work on).

For event organization? The key thing that makes facebook useful for this is that pretty much everyone has an account. You could probably build something on top of a distributed/federated chat/data replication system (like Matrix or possibly XMPP, etc.), but I don't see any new closed app being able to get enough traction to overthrow Facebook there.

It's a shame that XMPP never really took off; even more so as a lot of people seem to be taking it as proof that no distributed chat system will ever take off. I think there are quite a lot of reasons end users would really like distributed chat, one of which is very much security. We need to learn why XMPP didn't take off and either a) fix it, or b) learn and move on.

(Which is why I'm part of a team building http://matrix.org/, check it out!)

However, I don't necessarily think we're ever going to get to a world where everything is end-to-end encrypted. There will always be trade offs involved when using encryption, and sometimes the trade off aren't worth it (a stupid example being public group chats). It would be nice, however, if chat apps and protocols in general made it clearer what level of security is involved. Just like the average user is slowly getting to grips with HTTP vs HTTPS (thanks in part to the nice and simple padlock icon on most browsers), there's no reason that users can't be made aware of the security of a given conversation and medium.

Facebook, for all its woes, is still easy/useful when trying to organize events, and I really don't care that much if they are spying on that. On the other hand I don't really use facebook messenger since I do care about those conversations.

We need to empower average users to be able to make those same informed choices on who they trust with what.

Some corporate networks do MITM you and mandate HTTP only (we've seen this surprisingly often in the wild).

Now, for most apps this isn't a concern since those employees probably wouldn't be allowed to use the app, but it can be quite important for apps that specifically target large businesses.

And its nice to be able to choose which apps you want to use on all the different platforms; and choose differently than everyone else. The app that works for me isn't necessarily the app that works for others, but I still want to be able to talk to them using the app I want.

</blatant self-promotion>

There seems to be this general assumption at the moment that a) XMPP is the only open chat protocol about and b) its dead, so everyone decides that the only logical course of action is to write and use custom proprietary protocol. This, of course, massively sucks from a UX perspective where I end up having 100s of identities and apps and logins that I use (semi-)regularly to not just chat with people, but also comment on articles, discuss things on mailing lists etc.

I completely failed to read this the first time I went through. I guess this is equivalent to dumping bigger dictionaries.

> [Warning: Anecdote] When we were testing out the various JSON libraries we found simplejson much faster than json for dumps.

Turns out we were using sort_keys=True option, which apparently makes simplejson much faster than json.

What about larger dictionaries? With such a small one I would be worried that a significant proportion of the time would be simple overhead.

[Warning: Anecdote] When we were testing out the various JSON libraries we found simplejson much faster than json for dumps. We used large dictionaries.

Was the simplejson package using its optimized C library?

Then you discover the framework designers consider your problem too far from their core target use cases and so show no interest in improving that area of the framework. The community question why on earth you were trying to solve that problem in the framework in the first place, and tell you that obviously you should have used a different framework from the start.

Frameworks all target different use cases; often simply the ones the designers happen to have faced over the years. Half the battle in choosing a framework seems to be finding out what those target uses cases actually are - most frameworks seem to think they are good at everything.

God forbid your app evolves and changes such that no framework fully supports all your uses any more...

(That's not to say frameworks are bad, I just think there's a bit too much religious fervour involved when discussing them.)

Matrix is very much still in beta; people have been quite excited about writing their own server implementations but have decided to wait until the protocol (and documentation!) stabilize. :)

(Then again, I'm not exactly unbiased given I work for http://matrix.org)

Multiple device support is definitely a second class citizen in XMPP, and is just plain Hard (if not impossible) in a P2P world.

One of the major things we want is the ability for e2e encrypted messages to still be readable from all of your devices, which is kind of incompatible with OTR. Saying that, people have been talking about building OTR on top of Matrx; either by embedding OTR messages directly in the message JSON or using Matrix to negotiate a data channel with something like webrtc.

That distributed social network thing sounds quite exciting, and very much in a similar vein as Matrix. Does it have a website/github repo yet?

We've definitely found its not always easy to balance a philosophically pure/technically nice solution with one that actually has a usable UX. Although it sometimes seems that half the battle is figuring out what actually is a usable UX...

> How are highly diverged histories (e.g. a long netsplit in an active room) supposed to be merged?

So the cool thing with the federation in matrix is that all the messages (and state changes like room memberships) are part of a directed acyclic graph (DAG), so any new messages that are sent reference the previous ones. (Very much like git). That way a server can tell if it is missing any messages as long as it can talk to a server in the room. Since everything is signed by the originating servers, servers can pull in missing messages from third parties! Thus partial-netsplits are fine, as all the messages will eventually propagate through to all servers :)

When a full netsplit happens you effectively get two separate branches in the graph, each group of servers happily talking to each other. When a netsplit is resolved, one of the servers will realise they can talk to one of the other servers, at which point one of the them will send an event that references both branches (in effect merging them). All the other servers will then realise what they are missing and pull the branches in. At that point a certain amount of state resolution needs to happen (e.g. if people joined and left on the different branches) to ensure that all the servers have a consistent view of the state of the room.

The really difficult problem we've found is how you communicate to the clients about the netsplits, and how the clients should display the netsplits (although this is more of a UX issue, but still important). Since the messages in the room are stored as a DAG, the servers can see what messages were part of which netsplit and so that information can be made available to the clients.

> Does the protocol require O(N^2) connections for N users? (The number of users in some IRC rooms is measured in thousands.) Can it be more efficient?

Currently the protocol uses full mesh to distribute the messages to all the servers (which in practice are going to be fewer than the number of users in the channel), though since it uses HTTP the servers don't need to maintain active connections to all other servers. We really want to come up with new distribution models for really large rooms at some point, but we haven't quite gotten that far yet :)

> How are rooms administered?

The user that created the room gets admin rights to the room and given a "power level". The admin can set the power level required to do different things, (e.g. kick, ban, set the name of the room etc), as well as whether you need an invite to join the room or not. They can also grant (and revoke) power levels to other members of the room. Now, if a remote server intentionally ignores these rules then other servers in the room will simply not accept the dodgy actions. All actions, whether message sending or banning someone requires the server be able to prove that they had permission to do that by supplying a list of events along the lines: "I can ban because I have power level X, which was assigned by Y, who could do that because...".

(I'm part of the matrix team ftr.)