That was not my point, I over-reacted to a pattern of argument that bothers me when my own mind repeats it.
I agree that security should be taken seriously, with care and caution, and that users who ethically need to be aware of potentially fallacious assumptions about the usage of a device should have the capacity to easily find that information.
Obviously there exist people who believe that the things they say in this app, which claims to provide "anonymous" communication in a country with a history of repression of free speech, aren't tracable back to themselves. We've established here that this isn't true.
It's fine if you think this is an unreasonable conclusion to draw based on the evidence; you're entitled to your opinion. But the question is, do you feel comfortable with the possibility of people going to jail or dying because they didn't understand the security tradeoffs that this app makes? I think it's because some of us see this as an extremely real possibility -- particularly given the frankly ineffective security practices described here -- that you're seeing so much backlash.
OK, then why do the fund managers don't just move elsewhere? The flaw in your argument is that you assume that investment services are a commodity, which obviously they aren't, otherwise everybody wouldn't have to be frothing about how some managers make better returns than others.
> It would be nice if there was a single, easy to use site for mere mortals to enter bug reports (and others can comment on them, vote on them, process them, etc)
Having worked for Mozilla for 5 years (Zack also is a former Mozillian), I actually don't think that the root problem is the ease of use of the bug tracker.
Although bugzilla sucks, we still managed to get a ton of bug reports from external folks. But getting the bug report is only the first step. Once you have it, you need to, at a minimum:
a) Figure out what part of the software is causing this bug. For complex software like a browser, figuring this out often requires deep technical knowledge of the system, so is expensive time.
b) Figure out if the bug is already known. This is again often nontrivial because one bug can manifest in ways that may look superficially dissimilar, so requires an expensive person's time.
c) Collect additional information from the reporter. Most bug reports from muggles don't have enough information to let you reproduce the issue without additional back-and-forth. Since the bug reporter probably doesn't live in bugzilla like Mozilla folks do, they're usually slow to respond, if they respond at all. I've had bugs I worked on a week only to have the original reporter disappear. It's understandable; all this communication takes a lot of work.
d) Reproduce the bug. If you can't reproduce, go to (c).
e) If it's a regression, figure out when the bug was introduced.
f) Figure out if the bug is fixed in alpha/beta/nightly builds.
This is all before you actually try to write any code.
Every step here is more difficult and risky when the reporter isn't a known entity, so as a result, if Zack or I file a bug against Firefox, all things being equal we're much more likely to be paid attention to than if a random person files a bug. It's just a basic cost-benefit analysis on the part of people who already have too much to do.
I'd say that 80% of bugs I fixed while I worked on Firefox were identified by Mozillians (either employees or regular contributors). Which isn't to say that the remaining 20% weren't important -- they were, which is why I fixed them! But those 20% were a lot harder and riskier to fix, and that's not something I can imagine the best bug tracking software in the world ameliorating.
I went to Stanford as an undergrad just a few years after this bidding war between top universities began. The additional financial aid I received saved my family and me more than $100k -- that figure would be much higher if we factor in the interest on the loans I didn't have to take -- and I will be forever grateful. I applaud Stanford for expanding this program.
But I'm also a little sad about the way this is playing out, because the net effect is to set the top private universities even further apart from the many great universities that nonetheless can't afford policies like this. There's already so much pressure on a lot of kids to get into a top private university, and now many of them are in a position where if they don't get into one of the top four, their only option is a public school. (And yes, there exist public schools, such as Cal, which one can argue deserve to be mentioned in the same sentence as H/P/Y/S, but certainly there isn't a UC Berkeley in every state, and going to a public school out of state can be as expensive as going to a private school.)
If you really want to be sad, take a look at how short is the list of schools with need-blind admission that claim to meet all demonstrated need:
This is a supremely low bar, because schools get to define how much you need; there's no standard for this. And of course schools can meet your need with loans. But even still, the schools on this list are the only ones in the country which even claim to be meritocratic in their admission of US applicants.
> Although I guess that would only be a partial solution at best. If an attacker could monitor many runs of the same "real" workload, some simple statistical analysis would still tell you some things.
Yes, exactly. If you're doing a timing attack under non-ideal conditions, there are already plenty of sources of random delays -- e.g. network delays, delays introduced by the kernel scheduler, and so on. Adding additional random delay doesn't solve this fundamental problem.
> The fact that xor eax,eax is just a register operation doesn't mean it can leak sensitive information.
AIUI tfa's point is that you can't assume that
take the same amount of time, because "x86 is a high level language". Similarly for his other examples. This, he claims, makes it difficult to write code that resists timing attacks, if you ever want to have a branch that does nothing. Thus the discussion of cmov.
The point of the grandparent's post is that timing information is only leaked if the CPU's timing is data dependent. It's not enough to show that different instructions take unpredictable amounts of time. If the sequence of CPU instructions that get executed are the same for varying data, then the unpredictability of the individual instructions doesn't create a timing attack.
xor eax,eax scans, to an x86 assembly programmer, as "eax := 0". It's idiomatic for clearing a register. There ought not be any expectation from an assembly programmer that such a frequent operation would take the same amount of time as xor eax,ebx (in particular, xor eax,eax doesn't depend on the value of eax, so it doesn't need to stall waiting for its value to be calculated). But if xor eax,eax took a different amount of time depending on whether eax was equal to 42 or not, that would be a different matter.
Can someone explain to me why you wouldn't just count clock ticks at a higher level than the CPU? If the operation finishes early just... wait. I understand resolution and yes you'll probably only be w/i a delta of some sort, but isn't that the point?
Even if you could figure out the worst-case timings and how to simulate them in all cases, the performance would be unacceptable. The usual operations that are data-dependent in crypto algorithms are mov with a data-dependent address, and conditional jump with a data-dependent condition. To slow these down, you'd have to simulate the absolute worst case, which means no caches of any kind, which means possibly thousands or even millions of cycles (to simulate a page fault from disk) for every operation of unknown duration. Crypto would become infeasible.
There are much better ways to achieve this, by always computing both sides of a (logical) branch or using computation instead of branching or table lookups. You likely have to write this in assembly to be sure that the compiler doesn't "optimize" any of your tricks back into branches. Some of this is hard in older crypto algorithms (AES was designed to use table lookups in software), but newer crypto algorithms are much more amenable to safe implementation.
Your operating system hits memory pressure and pages your RAM page to disk. Some time later it restores it. Hey, look, you've suddenly had an arbitrarily long delay. So you can't always finish early.
Also, even assuming you can always finish early, that plan won't prevent, for example, measuring the delay of other responses. (As your process sleeping will have an impact on how fast other responses are sent. Due to cache pressure, in particular. But also due to CPU throttling, scheduling, etc, etc.
Why is it people can't ever respond to sanity, but instead assume idiocy?
You measure page faults in terms of milliseconds, I was not suggesting you even out the cryptographic timings to the tune of milliseconds, especially when you consider most cryptographic functions are setup specifically to take longer than that.
There is a delta that you can come up with such that things like page faults fall within it and it would still have acceptable performance. All but the most pounded of servers would be able to fall within it with no problem whatsoever.
You haven't explained why it doesn't solve the problem. My experience has been if I can't understand it, it's because it's bullshit.
So why not take another crack at explaining why that wouldn't solve the problem? And don't complain to me about DDOS, people specifically code cryptographic functions to take longer than they absolutely have to. If they're not worried about DDOS, neither are we for the purposes of this conversation.
>> nobody innovates because, without IP, you pay for the cost of R&D but "copycats" can steal the idea without paying.
> This just isn't true. It's human nature to innovate, just as it is human nature to sing, play music and dance.
Straw man fallacy.
The OP wasn't suggesting that literally nobody would innovate, just that innovation, particularly innovation paid for by private parties of the sort of thing which is expensive and easily copied, would significantly decline.
If you have ever paid to see someone sing, play music, or dance, you have participated in an activity which likely would not have occurred without there being a monetary incentive for that person to partake of the activity you paid to enjoy.
Obligatory plug for titanium / non-precious rings. My Ti band was $20 on Amazon, and on the other side of the spectrum, my wife had a beautiful Ti ring, including a tension-set lab-grown sapphire, milled to her specifications for < $500. But not conforming in this small yet significant way takes a certain kind of person.
Solid silver wedding bands reporting in. No stones. We have two pair. We've travelled a bit and never been afraid of being mugged for our jewellery. Cost was cheap enough that I can't even remember. Very happy that we weren't hoodwinked into giving large sums away to diamond retailers.
It's true that Ti rings are harder to cut, but the equipment to cut them is standard in American ERs. It still takes longer though. Even worse are the newer cobalt chrome rings, those take forever to cut off even with the right equipment. Safest of the alternative materials is probably the tungsten carbide or ceramic rings, since those can be fractured off with a pair of common vice grips. Don't know what happens when you're traveling in an area with a less developed medical system. If you aren't at risk for anaphylactic swelling, don't work with your hands, and don't travel in undeveloped areas, the risk of this sort of situation might be low enough to not worry too much about.
A more practical problem with alternative materials is that they can't be resized (some jewelers will resize Ti a little, but it's challenging). The alternative materials are cheap enough that you can buy a replacement that's the right size, but if you're sentimental (and a wedding band seems like something one might be sentimental about) it's a problem.
There's nothing wrong with alternative materials, it's just that sometimes the drawbacks are overlooked while being dazzled by the advantages.