I came in expecting a bunch of hand-waving denials, cries of "WHAT ABOUT MEN'S RIGHTS?!?!", and other such nonsense and I was not disappointed!
Women in tech/nerd circles generally face a lot more BS than a man would in the identical situation. That continues to go on because some of us seem to think this is an attack or indictment and refuse to acknowledge it.
Here's a pro tip: the guys who grab women's breasts, stand immediately in front of a woman when they're the only two in the elevator (blocking her exit), start asking sexually-charged questions, follow her around after a meeting, or even just the ones who automatically dismiss anything a female developer says.... They don't generally act like jerks in plain view. When they do, those of us who do care sit by silently; when the manager pats a female developer on the head and tells her not to worry about it, a lot of guys just laugh or ignore it.
You may think it doesn't happen but ask the women in your group how many times people have treated them like children, dismissed them, or behaved in a really creepy way even after being asked to stop **. Ask any reasonably well-known geek girl to show you her "death & rape threat" tweet or email folder and you'll see hundreds or thousands of them.
** I've personally seen it many times; once I even witnessed a guy ask a female geek how many guys she had slept with, then get righteously offended and angry when she said that was an inappropriate question. (To my own younger self's shame I did not step in and call him out at the time - something I regret). Women often feel they can't speak up about anything that happens to them because they are loudly shouted down as liars, whores, or met with complete denial. Even asking someone politely to stop being a creep can elicit angry self-righteous replies.
I think the refusal to see the issue and complete denial stems from fear - the fear that this will spiral into some out-of-control political correctness where we can't tell a joke, give a compliment, or even chat up women anymore. As far as I can tell that's just a manufactured fear with no basis in reality. The creepy angle also comes from guys who feel they are unable to approach women, but prominent and famous women are "known" to them, a sort of false relationship we all can tend to feel we have with the public figures in our lives. In that situation they act far more familiar than they otherwise would.
So here's a simple thing you can do: make your tech meetups friendly toward women. If you see another guy acting creepy, call him out on it. If you find yourself objecting to a technical point raised by a female developer, just take a half a second to think "would I object if it were Bob asking instead of Alice?". Stop letting the bad apples spoil the whole bunch, and worse - teach the young men and women in tech that this behavior is acceptable. Most of all, stop denying there's a problem.
I bet if even 5% of the male developers spoke out against the negative behavior and actively supported women in tech, we could completely eliminate this issue almost overnight.
Yeah but if you get mad and start throwing things you can end all of existence. Some say the universe would collapse and reboot but sounds like hocus-pocus to me!
Car makers cried and pitched an absolute shit-fit about seat belts, air bags, and fuel efficiency standards.
In theory, the free market should produce incentives for solving for safety and efficiency. In reality, it just optimizes the local maxima, since no one wants to be the first to "blink" by making these new technologies standard (thus greatly lowering the cost), ensuring they stay high-priced luxuries.
If we leave it to the free market, we'll be stuck on gasoline engines for another century at least, with all the negative impacts that will have on our economy as the increasing cost of oil and various shocks hit. That's not even dealing with the environmental or global climate change issues.
Government regulations can jump-start the industry and so far it appears to be working for electric vehicles. We are still in the early-adopter stages; they'll get better and cheaper as long as we keep at it.
Fun fact: government almost always leads the way into uncharted territory. It wasn't private industry that built trans-continental railroads (which makes Atlas Shrugged hilarious). It was the US government. The government gave the rights of way, passed a series of massive funding bills to give the railroads free money and tax breaks, sent in the army to protect the rails from Native Americans, robbers, etc. Without federal government involvement, the US rail network would not exist in the form it does today.
For that matter, neither would the interstate highway system.
Nor would computing: it was massive US federal government spending that paid Grace Hopper to invent the first compiler! And it was government spending that created the Internet, both TCP/IP via ARPA and the WWW via CERN.
Turning on all warnings and forcing them to errors certainly would have caught the bug in Apple's SSL code. Anyone who just lets warnings fly by in C code is an idiot. Even if the warning is mildly silly, getting it out of the way lets the important warnings stand out. Sensible warnings from C compilers are the very reason we don't use lint anymore. Even then you still have to watch out, because some warnings won't appear at low optimization levels, and I recall hearing that there are a few obscure warnings not turned on by -Wall.
Static analysis has not proven to be especially helpful in finding bugs in SQLite. Static analysis has found a few bugs in SQLite, but those are the exceptions. More bugs have been introduced into SQLite while trying to get it to compile without warnings than have been found by static analysis.
The bolded part has been my experience unfortunately. Static analysis is nearly useless.
An appropriate test for something like an SSL stack is a separate test harness that "fuzzes" the stack by exploring large random combinations of values, some with known good certificates and others with randomly generated (and thus broken) ones. These days one can spin up thousands of VMs, run a massive suite of billions of test cases in parallel over a few hours, then spin them down and spend a relatively small sum of money.
And yes, the test harness for something like this is probably going to exceed the # of lines of code of the actual implementation by an order of magnitude. For really important security-critical stuff like cryptography, SSL/TLS, keychain management, etc it is well worth the effort.
IIRC this is actually an issue with the sending devices not being aware that the target contact no longer has iMessage enabled.
It's trickier than it seems because iMessage will route to your Mac, iPad, and iPhone. It doesn't know if you just haven't signed in recently or if you're gone forever. If I read a message on my Mac, it is a successful delivery, even if I tossed my iPhone in a lake and swore off cell phones forever.
Apple should add a portal to manage this on icloud.com so you can see all your devices and enable/disable them from iMessage. Then the iMessage servers should reply when a device certificate is used that is disabled or deleted, causing the sending device to update its records.
Remember - Apple acts as a key exchange system but the actual private keys only exist on individual devices; the sending device re-encrypts the message for each recipient.
Some people may mod this as Funny, but I take it as completely serious.
Even if it isn't the NSA, do you really think other state actors won't try to exert their influence?
Expect lot of FUD around security issues by direct paid shills, or just "grass-roots" opposition indirectly fomented by various state security agencies.
- Apple cannot track a phone via GPS, nor forcibly enable Find My Friends/Find my iPhone
- Apple cannot monitor FaceTime or iMessage conversations since they are end-to-end encrypted
- Apple cannot provide third-party app data that is encrypted since the files are encrypted with the user's passcode.
- It appears if the user does a remote wipe before law enforcement can get a warrant and ship the phone to Apple (or fly it there), then there is nothing that can be done. I wonder if they power up the device in an anechoic chamber so it can't receive the remote wipe signal? I would guess no because most people aren't smart enough to do an immediate wipe.
- We already knew the only trick they have as far as encrypted files goes is a custom firmware that bypasses the max attempt auto-erase and rate limit feature, so it can attempt to brute-force passcodes quickly. However it requires the attempt be made on-device, since the keys are stored in the secure storage with no facility to get them off-device. So even a moderately complex passcode is effectively unbreakable, let alone a good strong password.
Questionable:
- user generated active files (this is what SMS/call logs/photos/etc are listed under). Normally if a device is powered off and rebooted, I was under the impression that these things were not available because the files are encrypted. It seems that iMessage is at least encrypted here, but I would be curious to find out what the situation is. Everything except photos, videos, and recordings is a moot point because you can get stuff like SMS history and call logs from the carrier anyway so those are the only ones I'd be concerned about.
There are some definite good points here - Apple has chosen not to build themselves backdoors or workarounds, presumably because they can't be ordered to disclose information they don't have access to... same reason they built iMessage the way they did. A court would have to order them to refactor their software before it could order them to intercept messages, and at least in the US there is no precedent or law that can compel them to do so.
However I would expect the âoeuser generated active filesâ to be encrypted after a device reboot until the passcode is entered. If that is not the case, Apple should fix it pronto.
I would also expect Apple to refactor the storage of those things to be segmented, given the NSA revelations and increasingly authoritarian behavior of law enforcement; for example, photos pending background upload could be kept unencrypted, but once uploaded they should be rewritten as encrypted so they require the passcode to access. They already have the ephemeral key tech and per-file key support so you can generate a key for the unencrypted file while the device is unlocked, then toss the passcode key when the device locks and only hold onto the file key until the upload is finished, then toss it. Thus no risk to the main key but you can still encrypt the file in the background.
I won't bother discussing Android phones - they are almost all trivial to break and access all the user's data, when people like Samsung aren't coding back doors directly into the firmware.
Or, perhaps, to acknowledge that it's very hard to do anything useful without side effects.
You can write beautiful, elegant, purely functional code, as long as it doesn't have to touch a storage system, a network, or a user. But, hey, other than that, it's great!
This is a huge misconception about functional programming, one that I used to have myself.
With a functional programming language, you can have side effects, you are just forced to be explicit about those side effects with specific language features in specific places.
Basically functional programming requires you to "opt-in" to side effects only where necessary.
Traditional imperative programming requires you to "opt-out" by taking huge steps to enforce immutability, generating mountains of code to accomplish any task because the compiler doesn't help you.
Apple handles the billing, customer service, credit card merchant fees, runs gift card programs, provides a CDN to deliver both the app and downloadable content, and provides access to a captive market.
Paypal or merchant account require you to handle the charging, refunds, paperwork, etc. You also need to find your own addressable market. And run your own gift cards if you want bank-less people or kids to be able to purchase. And setup your own CDN. Depending on the situation you may need to pay commissions to sales people too. You'll be on the hook for currency conversions and setting up with the various banks, government entities, filing the paperwork, etc to make sure you comply with all local business laws in over 100 countries.
Apple is providing a service and 30% is a steal compared to most publishing agreements in the history of the world. They also don't cut side deals with large developers for a lower cut, meaning you and I are on the same level as Amazon and Microsoft. If you think large retailers pay the same merchant fees as the small guys you are badly mistaken. The big guys also have lawyers on staff to deal with filing paperwork and tax forms.
They cover that in the paper and videos. At 40,000 ft equivalent atmospheric pressure, water begins to cavitate or boil inside the siphon, but the momentum of the water pulls the bubbles past the apex before they can stop the flow, resulting in a "waterfall" inside the tube. Slightly lower pressure decreases this effect, slightly higher increases it.
At some point around 41,000 ft equivalent pressure the bubbles form too quickly and touch all sides of the tube at or slightly before the apex, resulting in the flow stopping. However if you then increase the pressure again at a certain point (around 30,000 ft IIRC) the flow resumes. They discuss attempting the experiment in the future with an ionic liquid that won't vaporize.
If you think about it, this is the same phenomenon as the ball chain flowing out of a container (https://www.youtube.com/watch?v=_dQJBBklpQQ). Gravity pulls on the first ball, which pulls on the next, which pulls on the next. As soon as that pull is strong enough to lift the chain from the surface to the apex, a siphon effect begins that will empty the entire container.
IANAP, but it appears that water siphons work the same way. Once enough water flows over the apex sufficient that the force of gravity on that water exceeds the weight of the water prior to the apex the siphon will flow. The big tell-tale sign that any explanation involving the air pushing down on the surface of the liquid is wrong is the flow rate - it is almost completely independent of atmospheric pressure.
The one question I still have is why the flow stops at 41,000 ft. I would have expected a kind of spring effect, followed by the lower portion of the siphon slowly descending as water vaporizes off the pre-apex portion, allowing the water in the lower part to descend while maintaining the same vapor pressure. I'm sure it is my failure to understand, so if anyone can offer a better explanation please do so!
Translation of GitHub's weasel words: "Our lawyers told us not to admit to anything or we could be liable in a lawsuit. The company we hired to tell us we aren't liable in a lawsuit told us we aren't liable in a lawsuit."
Maybe Horvath isn't entirely in the right here but it is clear that the co-founder must have intimidated her as she claimed and/or let his wife (a non-employee) run amok. GitHub even admitted as much when the original story broke and re-banned his wife from the building. GitHub's legaleze non-statement doesn't address this at all.
The anonymous medium post is being given far more credence than it deserves because it fits the narrative people want to have about the story. Just be honest... You want the truth to be that Horvath somehow did wrong and brought this on herself because the alternative is that a fun cool company that has good technology also did a bad thing.
Let us not forget that Horvath did not bring any of this up in the first place - she simply quit. It was an anonymous person (that was suspected of being the founder's wife at the time) who posted about it, thus eliciting a reply from Horvath.
Again, according to Horvath, the supposed "investigators" never bothered to contact her until a day or two before wrapping up the "investigation". It seems very clear GitHub hired them to obtain a foregone conclusion.
I don't see how any of this is shocking. It is 100% believable (and by Occam's razor probably true) that the founder's wife was allowed to run around like she owned the place, got into a conflict with Horvath, then when it blew up Preston-Werner jumped to his wife's defense (understandable) without thinking about the implications of allowing your non-employee relative to even put you in that kind of situation to begin with; he certainly didn't consider what it would be like for an employee to be cornered by a co-founder over it. Then when it became public, they called the lawyers, circled the wagons, etc. I also would be shocked if some of the anonymous stories are by GitHubbers who are just repeating internal rumors and rising to defend the company they like, without any actual direct knowledge of what happened.
While you are technically correct, the reality is that the most serious security vulnerabilities are almost all directly related to buffer overruns (on read or write), allowing an attacker to read or write arbitrary memory. Everything else is a second-class citizen by comparison; denying service by causing Apache to repeatedly crash is far lower priority than compromising all traffic and stealing credentials.
So when we look at that class of serious problems, we find that managed memory languages completely eliminate them.
Relying on people to "just drive better" is an automatic failure. We design everything from signs/road markings to cars themselves around the idea that relying on humans to be perfect is pure idiocy, so we need to create affordances that lower cognitive load, along with automatic systems that attempt to avoid collisions and mitigate their consequences when they occur.
Similarly, just relying on programmers to never make mistakes is guaranteed to lead to more exploits like Heartbleed. It's pure stupidity.
If OpenSSL were written in Rust or C#, it wouldn't be quite as fast, but we wouldn't be looking at years of government spies completely negating SSL, forcing all webservers on the *entire* internet to replace their SSL keys, instantly obsoleting hardware that can't be upgraded, exposing user's data (including login credentials) to attackers thus requiring EVERY FUCKING USER ON THE INTERNET TO CHANGE THEIR PASSWORDS.
Was the tiny performance benefit worth what we have now paid for it?
Of course we're going to continue using C and getting burned over and over and over. Who needs air bags? Just drive better.
Yet again, C's non-existent bounds checking and completely unprotected memory access lets an attacker compromise the system with data.
But hey, it's faster.
Despite car companies complaining loudly that if people just drove better there would be no accidents, laws were eventually changed to require seatbelts and airbags because humans are humans and accidents are inevitable.
Because C makes it trivially easy to stomp all over memory we are guaranteed that even the best programmers using the best practices and tools will still churn out the occasional buffer overflow, information disclosure, stack smash, or etc.
Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory. Singularity proved that was perfectly workable. I don't care if the language is C#, Rust, or whatever else. How many more times do we have to get burned before we make the move?
As long as all our personal information relies on really smart people who never make mistakes, we're doomed.
Eich was not fired. He chose to resign. Maybe he did so because he cares about the foundation and didn't want to be a distraction. Maybe he was told he'd better resign or they would lose their funding and have to lay everyone off. We don't know, but the insinuations of the original story are out of line for implying so. The truth is we just don't know.
This isn't some free speech issue or some form of inquisition trying to purge the unbelievers.
Eich chose to wade into a controversial issue by making political donations (after all, a conservative majority of SCOTUS claims money == speech). Those "free speech" statements offended a bunch of people and he chose to resign rather than drag the non-profit Mozilla foundation through an ordeal over it.
Anyone in a leadership position is certainly free to make any statements or support any political cause they want. Employees, customers/donors, etc are also free to loudly complain or refuse to associate with the organization if they disagree. That comes with the territory. We wouldn't give Eich a pass if he were sending checks to neo-Nazi organizations. A leader always takes a risk that they'll piss people off by taking a stance. He was CTO of Mozilla at the time, he knew what the consequences could be and made the donation anyway.
A few decades ago it was accepted that blacks and whites shouldn't intermarry. Even some people who campaigned for civil rights still held such a view. If Eich were donating to a group promoting a constitutional amendment to outlaw interracial marriages almost none of you would be wringing your hands over free speech. Everyone would laugh at him for being a dumbass and move on with their lives.
Freedom of speech is not freedom from consequences. Even if someone faces no offical sanctions for speaking out, they can certainly be excluded socially, even to the point of being driven out of the organization. That's how human group dynamics have always worked since we were grunting at each other and throwing pointy sticks.
Furthermore, technology has always been intertwined with personalities, politics, and the like. Only very rarely is it always 100% about the pure technology. You can write the best code in the world but if you can't play nice with others you run the risk of your code languishing in obscurity.
Social norms are changing; you can change with them, you can keep your mouth shut about it, or you can fight for the status quo. Each of those courses of action has risk associated with them. Eich chose to fight for the status quo, then chose to stick by his guns when it pissed a lot of people off, including a lot of the very people his organization depends on to contribute money and code from their own good will! That has consequences and it always has.
Linus is generally fair from what I can tell, and does not except himself from criticism. In that very thread:
Yeah, what Andrew said. My suggestion of per-task or per-cred is obviously moronic in comparison.
Linus "hangs head in shame" Torvalds
Someone proposed a better idea and Linus immediately admits his idea was worse and moves on. That was also one of Steve Jobs' greatest talents, even though it's in a completely different sphere. He originally said "no" to iPods for Windows and the iOS app store. People presented their case and he changed his mind.
We should all be so willing to admit when someone else has a better idea or we were wrong.
So, if someone said to you, "your house is likely to catch fire in the future", and then your house caught fire 15 years later, you'd be thinking "damnit! I was warned this would happen, I should have listened to that guy 15 years ago and moved"??"
if that person said it would catch fire in the future because of faulty wiring (or something else) then i'd fix the wiring.
Ah, the arguments of the willfully ignorant. I wish I were still a conservative. No nuances, no questions. Everything had a trite simple answer.
Reality does not so neatly fit into a box.
House fires happen rapidly. They are also largely preventable. And even though one person's house fire may be a tragedy, pouring water on it puts out the fire. (Remember kids: the fire department exists to prevent your house fire from burning down the rest of the city, not to save your house)
Mudslides, like earthquakes, are triggered by complex conditions that are not knowable by humans in advance (with any degree of certainty). They also cannot be prevented or controlled. There is no "Mudslide Department" because there is no response. By the time you find out about it, the mudslide is over and the damage is done.
This case is very simple to explain: no one wants to be the person who "wastes" taxpayer dollars buying out homeowners and tearing down houses when the potential disaster can strike anywhere between tomorrow and 50 years from now. So county officials, housing developers, and maybe to some degree homeowners all chose to ignore the report and get on with their lives. That works great, right up until the moment when everyone died.
That is certainly an issue, but not the huge gaping security flaw the summary makes it sound like. Apps can only ask for normal permissions that the OS offers, not bypass security or the sandbox. It's basically a UI issue.
Correct. The huge, gaping security flaw with Android is the same one that afflicted ActiveX in Internet Explorer: Assuming that the majority of users a) have a clue what any of the permissions actually mean b) can trust the app not to abuse the permissions it has (or contain flaws that allow it to be hijacked)
The reality is that 100% (rounding up from normal people to geeks) of people simply tap accept, click OK, etc and move on with their lives. Those annoying dialogs are just how you use phones/computers. They've learned if they choose Cancel they don't get the game/app they wanted, so the correct course of action is to always accept.
Any security decision that relies on users to take the correct course of action is an automatic failure. If making the wrong choice results in being pwned, having a $10/mo premium SMS subscription added to your bill, etc then the system is badly designed and broken.
The article didn't make this terribly clear, but people seem to be missing the point.
If you teach the concepts through hands-on interactive play, kids as young as five can understand the concepts underlying Calculus without too much difficulty. This also happens to be one of the best times in your life for learning, when the brain is rapidly forming new connections.
Her point is teach the concepts, teach the patterns, teach kids how to find patterns, and how to internalize mathematical knowledge.
The mechanical drudgery of formal language, writing out and solving equations, etc comes later on but builds on the fundamental understanding developed much earlier in life.
There have always been holes in the App Store and sometimes you can sneak things through.
The difference is if you try such things and you app becomes even remotely popular, Apple can pull your app and even your developer account so the actual window where your fraud or evil tricks can result in some kind of gain is very small.
I'm not sure why people constantly fail to recognize this.
Similarly with the SSL flaw... Apple pushes iOS updates in a way Android users can only dream of; within a month more than 90% of all iOS devices still in use will have the patch applied. Compare that with the web view remotely exploitable hole just revealed for Android... at least half of all Android devices will still have that hole a year from now!
So in theory yes, Apple is just the same as everyone else. In reality, the actual user experience will be quite different.
I may be misunderstanding, but it appears that the existing contractors are using old-school waterfall. Gee, government contractors using a heavily-specs-oriented approach, when has that gone wrong?
The new idea seems to be having a team of smaller players use an agile approach to deliver the real system.
Any time you can get a group of smaller developers doing rapid iterations with the government it's a miracle... It is also vastly more likely to deliver something decent and on-budget.
Anytime I see HP, IBM, Agilent, et al winning a contract for some government system I automatically assume it will be an epic fail.
Repeat After Me: No single weather event can be said to be proof or refutation of Global Climate Change.
All Global Climate Change says is that as the *average* global temperature increases the traditional weather patterns we have become accustomed to will change in unpredictable ways. Some areas may see colder winters, others warmer. Some areas will see increased rain, others will become deserts. In fact some places may have hotter, drier summers yet colder wetter winters. The problems come from the fact that we've put farms and cities in certain locations with the expectation that the weather would be stable over the long term.
You can't say any one hurricane is proof of global climate change any more than you can say any one cold winter refutes global climate change.
Oh, cancer is an evolutionary compromise of multi-cellular life? Yeah, right. It's a product of mutation, but it runs counter to reproductive fitness, and it's not like our bodies don't have immune systems which reject other foreign (differently mutated) cells, so, Checkmate, moron.
A lot of crack pottery going on around here...
Anyway, evolution may certainly favor cancer-susceptibility for any number of reasons. A mutation that makes you more fit to produce young during your own relative youth could trigger an increase in cancers later.
The more likely explanation is that most people have historically died of something other than cancer and long after they produced their offspring, making cancer a complete non-entity as far as evolutionary fitness goes. We simply haven't lived in a way that makes anti-cancer (or anti-obesity or anti-heart-disease) a factor for near long enough to have evolution drive us in that direction.
Yes, naked mole rats don't tend to get cancer but that's literally one in a million. The vast majority of species are perfectly susceptible to it, they just don't live long enough in the wild for the issue to pop up.
If you don't publish papers, you don't get funding. Sucks, but that's what we get for budget cut after budget cut, tax cut, after tax cut.
The big question appears to be if the latent infected cells can clear or deactivate HIV, or if they'll happily activate, travel to the site of an infection of some other kind, then start spewing HIV everywhere.
This process is basically cells realizing they are being infected (virus) or eaten (bacteria) by a foreign organism, and responding by killing themselves and spewing massive amounts of chemicals that alert the immune system to the problem. Normally, this recruits other immune cells to the site and is probably the right strategy 99% of the time. The problem is when the infected cells are immune cells themselves, their death just recruits more immune cells to an area with a higher chance of picking up HIV. What they found was that the body's stockpile of immune cells in the spleen, etc (normally dormant, awaiting an infection) get infected by HIV, but don't replicate the virus due to being inactive, however they are active enough to sense the virus in their DNA and kill themselves before repair mechanisms can remove or deactivate the virus genes.
The drug mentioned apparently shuts down or reduces this pathway, opening you up to a higher risk of bacterial infection but slowing or stopping the massive die-off of immune cells (assuming they are able to clean themselves up).
Slashdot Mirror
I came in expecting a bunch of hand-waving denials, cries of "WHAT ABOUT MEN'S RIGHTS?!?!", and other such nonsense and I was not disappointed!
Women in tech/nerd circles generally face a lot more BS than a man would in the identical situation. That continues to go on because some of us seem to think this is an attack or indictment and refuse to acknowledge it.
Here's a pro tip: the guys who grab women's breasts, stand immediately in front of a woman when they're the only two in the elevator (blocking her exit), start asking sexually-charged questions, follow her around after a meeting, or even just the ones who automatically dismiss anything a female developer says.... They don't generally act like jerks in plain view. When they do, those of us who do care sit by silently; when the manager pats a female developer on the head and tells her not to worry about it, a lot of guys just laugh or ignore it.
You may think it doesn't happen but ask the women in your group how many times people have treated them like children, dismissed them, or behaved in a really creepy way even after being asked to stop **. Ask any reasonably well-known geek girl to show you her "death & rape threat" tweet or email folder and you'll see hundreds or thousands of them.
** I've personally seen it many times; once I even witnessed a guy ask a female geek how many guys she had slept with, then get righteously offended and angry when she said that was an inappropriate question. (To my own younger self's shame I did not step in and call him out at the time - something I regret). Women often feel they can't speak up about anything that happens to them because they are loudly shouted down as liars, whores, or met with complete denial. Even asking someone politely to stop being a creep can elicit angry self-righteous replies.
I think the refusal to see the issue and complete denial stems from fear - the fear that this will spiral into some out-of-control political correctness where we can't tell a joke, give a compliment, or even chat up women anymore. As far as I can tell that's just a manufactured fear with no basis in reality. The creepy angle also comes from guys who feel they are unable to approach women, but prominent and famous women are "known" to them, a sort of false relationship we all can tend to feel we have with the public figures in our lives. In that situation they act far more familiar than they otherwise would.
So here's a simple thing you can do: make your tech meetups friendly toward women. If you see another guy acting creepy, call him out on it. If you find yourself objecting to a technical point raised by a female developer, just take a half a second to think "would I object if it were Bob asking instead of Alice?". Stop letting the bad apples spoil the whole bunch, and worse - teach the young men and women in tech that this behavior is acceptable. Most of all, stop denying there's a problem.
I bet if even 5% of the male developers spoke out against the negative behavior and actively supported women in tech, we could completely eliminate this issue almost overnight.
Yeah but if you get mad and start throwing things you can end all of existence. Some say the universe would collapse and reboot but sounds like hocus-pocus to me!
Car makers cried and pitched an absolute shit-fit about seat belts, air bags, and fuel efficiency standards.
In theory, the free market should produce incentives for solving for safety and efficiency. In reality, it just optimizes the local maxima, since no one wants to be the first to "blink" by making these new technologies standard (thus greatly lowering the cost), ensuring they stay high-priced luxuries.
If we leave it to the free market, we'll be stuck on gasoline engines for another century at least, with all the negative impacts that will have on our economy as the increasing cost of oil and various shocks hit. That's not even dealing with the environmental or global climate change issues.
Government regulations can jump-start the industry and so far it appears to be working for electric vehicles. We are still in the early-adopter stages; they'll get better and cheaper as long as we keep at it.
Fun fact: government almost always leads the way into uncharted territory. It wasn't private industry that built trans-continental railroads (which makes Atlas Shrugged hilarious). It was the US government. The government gave the rights of way, passed a series of massive funding bills to give the railroads free money and tax breaks, sent in the army to protect the rails from Native Americans, robbers, etc. Without federal government involvement, the US rail network would not exist in the form it does today.
For that matter, neither would the interstate highway system.
Nor would computing: it was massive US federal government spending that paid Grace Hopper to invent the first compiler! And it was government spending that created the Internet, both TCP/IP via ARPA and the WWW via CERN.
Turning on all warnings and forcing them to errors certainly would have caught the bug in Apple's SSL code. Anyone who just lets warnings fly by in C code is an idiot. Even if the warning is mildly silly, getting it out of the way lets the important warnings stand out. Sensible warnings from C compilers are the very reason we don't use lint anymore. Even then you still have to watch out, because some warnings won't appear at low optimization levels, and I recall hearing that there are a few obscure warnings not turned on by -Wall.
Let me quote from one of the best-tested and most widely used projects out there, SQLite, from http://www.sqlite.org/testing....
Static analysis has not proven to be especially helpful in finding bugs in SQLite. Static analysis has found a few bugs in SQLite, but those are the exceptions. More bugs have been introduced into SQLite while trying to get it to compile without warnings than have been found by static analysis.
The bolded part has been my experience unfortunately. Static analysis is nearly useless.
An appropriate test for something like an SSL stack is a separate test harness that "fuzzes" the stack by exploring large random combinations of values, some with known good certificates and others with randomly generated (and thus broken) ones. These days one can spin up thousands of VMs, run a massive suite of billions of test cases in parallel over a few hours, then spin them down and spend a relatively small sum of money.
And yes, the test harness for something like this is probably going to exceed the # of lines of code of the actual implementation by an order of magnitude. For really important security-critical stuff like cryptography, SSL/TLS, keychain management, etc it is well worth the effort.
IIRC this is actually an issue with the sending devices not being aware that the target contact no longer has iMessage enabled.
It's trickier than it seems because iMessage will route to your Mac, iPad, and iPhone. It doesn't know if you just haven't signed in recently or if you're gone forever. If I read a message on my Mac, it is a successful delivery, even if I tossed my iPhone in a lake and swore off cell phones forever.
Apple should add a portal to manage this on icloud.com so you can see all your devices and enable/disable them from iMessage. Then the iMessage servers should reply when a device certificate is used that is disabled or deleted, causing the sending device to update its records.
Remember - Apple acts as a key exchange system but the actual private keys only exist on individual devices; the sending device re-encrypts the message for each recipient.
The NSA will try to infiltrate the IETF.
Some people may mod this as Funny, but I take it as completely serious.
Even if it isn't the NSA, do you really think other state actors won't try to exert their influence?
Expect lot of FUD around security issues by direct paid shills, or just "grass-roots" opposition indirectly fomented by various state security agencies.
Hey, let's link to the actual document in question! What a novel concept!
http://www.apple.com/legal/mor...
Good news:
- Apple cannot track a phone via GPS, nor forcibly enable Find My Friends/Find my iPhone
- Apple cannot monitor FaceTime or iMessage conversations since they are end-to-end encrypted
- Apple cannot provide third-party app data that is encrypted since the files are encrypted with the user's passcode.
- It appears if the user does a remote wipe before law enforcement can get a warrant and ship the phone to Apple (or fly it there), then there is nothing that can be done. I wonder if they power up the device in an anechoic chamber so it can't receive the remote wipe signal? I would guess no because most people aren't smart enough to do an immediate wipe.
- We already knew the only trick they have as far as encrypted files goes is a custom firmware that bypasses the max attempt auto-erase and rate limit feature, so it can attempt to brute-force passcodes quickly. However it requires the attempt be made on-device, since the keys are stored in the secure storage with no facility to get them off-device. So even a moderately complex passcode is effectively unbreakable, let alone a good strong password.
Questionable:
- user generated active files (this is what SMS/call logs/photos/etc are listed under). Normally if a device is powered off and rebooted, I was under the impression that these things were not available because the files are encrypted. It seems that iMessage is at least encrypted here, but I would be curious to find out what the situation is. Everything except photos, videos, and recordings is a moot point because you can get stuff like SMS history and call logs from the carrier anyway so those are the only ones I'd be concerned about.
There are some definite good points here - Apple has chosen not to build themselves backdoors or workarounds, presumably because they can't be ordered to disclose information they don't have access to... same reason they built iMessage the way they did. A court would have to order them to refactor their software before it could order them to intercept messages, and at least in the US there is no precedent or law that can compel them to do so.
However I would expect the âoeuser generated active filesâ to be encrypted after a device reboot until the passcode is entered. If that is not the case, Apple should fix it pronto.
I would also expect Apple to refactor the storage of those things to be segmented, given the NSA revelations and increasingly authoritarian behavior of law enforcement; for example, photos pending background upload could be kept unencrypted, but once uploaded they should be rewritten as encrypted so they require the passcode to access. They already have the ephemeral key tech and per-file key support so you can generate a key for the unencrypted file while the device is unlocked, then toss the passcode key when the device locks and only hold onto the file key until the upload is finished, then toss it. Thus no risk to the main key but you can still encrypt the file in the background.
I won't bother discussing Android phones - they are almost all trivial to break and access all the user's data, when people like Samsung aren't coding back doors directly into the firmware.
Or, perhaps, to acknowledge that it's very hard to do anything useful without side effects.
You can write beautiful, elegant, purely functional code, as long as it doesn't have to touch a storage system, a network, or a user. But, hey, other than that, it's great!
This is a huge misconception about functional programming, one that I used to have myself.
With a functional programming language, you can have side effects, you are just forced to be explicit about those side effects with specific language features in specific places.
Basically functional programming requires you to "opt-in" to side effects only where necessary.
Traditional imperative programming requires you to "opt-out" by taking huge steps to enforce immutability, generating mountains of code to accomplish any task because the compiler doesn't help you.
Apple handles the billing, customer service, credit card merchant fees, runs gift card programs, provides a CDN to deliver both the app and downloadable content, and provides access to a captive market.
Paypal or merchant account require you to handle the charging, refunds, paperwork, etc. You also need to find your own addressable market. And run your own gift cards if you want bank-less people or kids to be able to purchase. And setup your own CDN. Depending on the situation you may need to pay commissions to sales people too. You'll be on the hook for currency conversions and setting up with the various banks, government entities, filing the paperwork, etc to make sure you comply with all local business laws in over 100 countries.
Apple is providing a service and 30% is a steal compared to most publishing agreements in the history of the world. They also don't cut side deals with large developers for a lower cut, meaning you and I are on the same level as Amazon and Microsoft. If you think large retailers pay the same merchant fees as the small guys you are badly mistaken. The big guys also have lawyers on staff to deal with filing paperwork and tax forms.
They cover that in the paper and videos. At 40,000 ft equivalent atmospheric pressure, water begins to cavitate or boil inside the siphon, but the momentum of the water pulls the bubbles past the apex before they can stop the flow, resulting in a "waterfall" inside the tube. Slightly lower pressure decreases this effect, slightly higher increases it.
At some point around 41,000 ft equivalent pressure the bubbles form too quickly and touch all sides of the tube at or slightly before the apex, resulting in the flow stopping. However if you then increase the pressure again at a certain point (around 30,000 ft IIRC) the flow resumes. They discuss attempting the experiment in the future with an ionic liquid that won't vaporize.
If you think about it, this is the same phenomenon as the ball chain flowing out of a container (https://www.youtube.com/watch?v=_dQJBBklpQQ). Gravity pulls on the first ball, which pulls on the next, which pulls on the next. As soon as that pull is strong enough to lift the chain from the surface to the apex, a siphon effect begins that will empty the entire container.
IANAP, but it appears that water siphons work the same way. Once enough water flows over the apex sufficient that the force of gravity on that water exceeds the weight of the water prior to the apex the siphon will flow. The big tell-tale sign that any explanation involving the air pushing down on the surface of the liquid is wrong is the flow rate - it is almost completely independent of atmospheric pressure.
The one question I still have is why the flow stops at 41,000 ft. I would have expected a kind of spring effect, followed by the lower portion of the siphon slowly descending as water vaporizes off the pre-apex portion, allowing the water in the lower part to descend while maintaining the same vapor pressure. I'm sure it is my failure to understand, so if anyone can offer a better explanation please do so!
Translation of GitHub's weasel words: "Our lawyers told us not to admit to anything or we could be liable in a lawsuit. The company we hired to tell us we aren't liable in a lawsuit told us we aren't liable in a lawsuit."
Maybe Horvath isn't entirely in the right here but it is clear that the co-founder must have intimidated her as she claimed and/or let his wife (a non-employee) run amok. GitHub even admitted as much when the original story broke and re-banned his wife from the building. GitHub's legaleze non-statement doesn't address this at all.
The anonymous medium post is being given far more credence than it deserves because it fits the narrative people want to have about the story. Just be honest... You want the truth to be that Horvath somehow did wrong and brought this on herself because the alternative is that a fun cool company that has good technology also did a bad thing.
Let us not forget that Horvath did not bring any of this up in the first place - she simply quit. It was an anonymous person (that was suspected of being the founder's wife at the time) who posted about it, thus eliciting a reply from Horvath.
Again, according to Horvath, the supposed "investigators" never bothered to contact her until a day or two before wrapping up the "investigation". It seems very clear GitHub hired them to obtain a foregone conclusion.
I don't see how any of this is shocking. It is 100% believable (and by Occam's razor probably true) that the founder's wife was allowed to run around like she owned the place, got into a conflict with Horvath, then when it blew up Preston-Werner jumped to his wife's defense (understandable) without thinking about the implications of allowing your non-employee relative to even put you in that kind of situation to begin with; he certainly didn't consider what it would be like for an employee to be cornered by a co-founder over it. Then when it became public, they called the lawyers, circled the wagons, etc. I also would be shocked if some of the anonymous stories are by GitHubbers who are just repeating internal rumors and rising to defend the company they like, without any actual direct knowledge of what happened.
While you are technically correct, the reality is that the most serious security vulnerabilities are almost all directly related to buffer overruns (on read or write), allowing an attacker to read or write arbitrary memory. Everything else is a second-class citizen by comparison; denying service by causing Apache to repeatedly crash is far lower priority than compromising all traffic and stealing credentials.
So when we look at that class of serious problems, we find that managed memory languages completely eliminate them.
Relying on people to "just drive better" is an automatic failure. We design everything from signs/road markings to cars themselves around the idea that relying on humans to be perfect is pure idiocy, so we need to create affordances that lower cognitive load, along with automatic systems that attempt to avoid collisions and mitigate their consequences when they occur.
Similarly, just relying on programmers to never make mistakes is guaranteed to lead to more exploits like Heartbleed. It's pure stupidity.
If OpenSSL were written in Rust or C#, it wouldn't be quite as fast, but we wouldn't be looking at years of government spies completely negating SSL, forcing all webservers on the *entire* internet to replace their SSL keys, instantly obsoleting hardware that can't be upgraded, exposing user's data (including login credentials) to attackers thus requiring EVERY FUCKING USER ON THE INTERNET TO CHANGE THEIR PASSWORDS.
Was the tiny performance benefit worth what we have now paid for it?
Of course we're going to continue using C and getting burned over and over and over. Who needs air bags? Just drive better.
Yet again, C's non-existent bounds checking and completely unprotected memory access lets an attacker compromise the system with data.
But hey, it's faster.
Despite car companies complaining loudly that if people just drove better there would be no accidents, laws were eventually changed to require seatbelts and airbags because humans are humans and accidents are inevitable.
Because C makes it trivially easy to stomp all over memory we are guaranteed that even the best programmers using the best practices and tools will still churn out the occasional buffer overflow, information disclosure, stack smash, or etc.
Only the smallest core of the OS should use unmanaged code with direct memory access. Everything else, including the vast majority of the kernel, all drivers, all libraries, all user programs should use managed memory. Singularity proved that was perfectly workable. I don't care if the language is C#, Rust, or whatever else. How many more times do we have to get burned before we make the move?
As long as all our personal information relies on really smart people who never make mistakes, we're doomed.
Eich was not fired. He chose to resign. Maybe he did so because he cares about the foundation and didn't want to be a distraction. Maybe he was told he'd better resign or they would lose their funding and have to lay everyone off. We don't know, but the insinuations of the original story are out of line for implying so. The truth is we just don't know.
This isn't some free speech issue or some form of inquisition trying to purge the unbelievers.
Eich chose to wade into a controversial issue by making political donations (after all, a conservative majority of SCOTUS claims money == speech). Those "free speech" statements offended a bunch of people and he chose to resign rather than drag the non-profit Mozilla foundation through an ordeal over it.
Anyone in a leadership position is certainly free to make any statements or support any political cause they want. Employees, customers/donors, etc are also free to loudly complain or refuse to associate with the organization if they disagree. That comes with the territory. We wouldn't give Eich a pass if he were sending checks to neo-Nazi organizations. A leader always takes a risk that they'll piss people off by taking a stance. He was CTO of Mozilla at the time, he knew what the consequences could be and made the donation anyway.
A few decades ago it was accepted that blacks and whites shouldn't intermarry. Even some people who campaigned for civil rights still held such a view. If Eich were donating to a group promoting a constitutional amendment to outlaw interracial marriages almost none of you would be wringing your hands over free speech. Everyone would laugh at him for being a dumbass and move on with their lives.
Freedom of speech is not freedom from consequences. Even if someone faces no offical sanctions for speaking out, they can certainly be excluded socially, even to the point of being driven out of the organization. That's how human group dynamics have always worked since we were grunting at each other and throwing pointy sticks.
Furthermore, technology has always been intertwined with personalities, politics, and the like. Only very rarely is it always 100% about the pure technology. You can write the best code in the world but if you can't play nice with others you run the risk of your code languishing in obscurity.
Social norms are changing; you can change with them, you can keep your mouth shut about it, or you can fight for the status quo. Each of those courses of action has risk associated with them. Eich chose to fight for the status quo, then chose to stick by his guns when it pissed a lot of people off, including a lot of the very people his organization depends on to contribute money and code from their own good will! That has consequences and it always has.
Linus is generally fair from what I can tell, and does not except himself from criticism. In that very thread:
Yeah, what Andrew said. My suggestion of per-task or per-cred is
obviously moronic in comparison.
Linus "hangs head in shame" Torvalds
Someone proposed a better idea and Linus immediately admits his idea was worse and moves on. That was also one of Steve Jobs' greatest talents, even though it's in a completely different sphere. He originally said "no" to iPods for Windows and the iOS app store. People presented their case and he changed his mind.
We should all be so willing to admit when someone else has a better idea or we were wrong.
They also open-sourced their new C# compiler:
http://roslyn.codeplex.com/
So, if someone said to you, "your house is likely to catch fire in the future", and then your house caught fire 15 years later, you'd be thinking "damnit! I was warned this would happen, I should have listened to that guy 15 years ago and moved"??"
if that person said it would catch fire in the future because of faulty wiring (or something else) then i'd fix the wiring.
Ah, the arguments of the willfully ignorant. I wish I were still a conservative. No nuances, no questions. Everything had a trite simple answer.
Reality does not so neatly fit into a box.
House fires happen rapidly. They are also largely preventable. And even though one person's house fire may be a tragedy, pouring water on it puts out the fire. (Remember kids: the fire department exists to prevent your house fire from burning down the rest of the city, not to save your house)
Mudslides, like earthquakes, are triggered by complex conditions that are not knowable by humans in advance (with any degree of certainty). They also cannot be prevented or controlled. There is no "Mudslide Department" because there is no response. By the time you find out about it, the mudslide is over and the damage is done.
This case is very simple to explain: no one wants to be the person who "wastes" taxpayer dollars buying out homeowners and tearing down houses when the potential disaster can strike anywhere between tomorrow and 50 years from now. So county officials, housing developers, and maybe to some degree homeowners all chose to ignore the report and get on with their lives. That works great, right up until the moment when everyone died.
That is certainly an issue, but not the huge gaping security flaw the summary makes it sound like. Apps can only ask for normal permissions that the OS offers, not bypass security or the sandbox. It's basically a UI issue.
Correct. The huge, gaping security flaw with Android is the same one that afflicted ActiveX in Internet Explorer: Assuming that the majority of users
a) have a clue what any of the permissions actually mean
b) can trust the app not to abuse the permissions it has (or contain flaws that allow it to be hijacked)
The reality is that 100% (rounding up from normal people to geeks) of people simply tap accept, click OK, etc and move on with their lives. Those annoying dialogs are just how you use phones/computers. They've learned if they choose Cancel they don't get the game/app they wanted, so the correct course of action is to always accept.
Any security decision that relies on users to take the correct course of action is an automatic failure. If making the wrong choice results in being pwned, having a $10/mo premium SMS subscription added to your bill, etc then the system is badly designed and broken.
The article didn't make this terribly clear, but people seem to be missing the point.
If you teach the concepts through hands-on interactive play, kids as young as five can understand the concepts underlying Calculus without too much difficulty. This also happens to be one of the best times in your life for learning, when the brain is rapidly forming new connections.
Her point is teach the concepts, teach the patterns, teach kids how to find patterns, and how to internalize mathematical knowledge.
The mechanical drudgery of formal language, writing out and solving equations, etc comes later on but builds on the fundamental understanding developed much earlier in life.
There have always been holes in the App Store and sometimes you can sneak things through.
The difference is if you try such things and you app becomes even remotely popular, Apple can pull your app and even your developer account so the actual window where your fraud or evil tricks can result in some kind of gain is very small.
I'm not sure why people constantly fail to recognize this.
Similarly with the SSL flaw... Apple pushes iOS updates in a way Android users can only dream of; within a month more than 90% of all iOS devices still in use will have the patch applied. Compare that with the web view remotely exploitable hole just revealed for Android... at least half of all Android devices will still have that hole a year from now!
So in theory yes, Apple is just the same as everyone else. In reality, the actual user experience will be quite different.
In order to regulate credit card companies and banks, the CFPB needs to know what is happening with these financial products.
It would appear that the banks' astroturf campaign is in full swing trying to get people riled up.
I may be misunderstanding, but it appears that the existing contractors are using old-school waterfall. Gee, government contractors using a heavily-specs-oriented approach, when has that gone wrong?
The new idea seems to be having a team of smaller players use an agile approach to deliver the real system.
Any time you can get a group of smaller developers doing rapid iterations with the government it's a miracle... It is also vastly more likely to deliver something decent and on-budget.
Anytime I see HP, IBM, Agilent, et al winning a contract for some government system I automatically assume it will be an epic fail.
Repeat After Me: No single weather event can be said to be proof or refutation of Global Climate Change.
All Global Climate Change says is that as the *average* global temperature increases the traditional weather patterns we have become accustomed to will change in unpredictable ways. Some areas may see colder winters, others warmer. Some areas will see increased rain, others will become deserts. In fact some places may have hotter, drier summers yet colder wetter winters. The problems come from the fact that we've put farms and cities in certain locations with the expectation that the weather would be stable over the long term.
You can't say any one hurricane is proof of global climate change any more than you can say any one cold winter refutes global climate change.
Oh, cancer is an evolutionary compromise of multi-cellular life? Yeah, right. It's a product of mutation, but it runs counter to reproductive fitness, and it's not like our bodies don't have immune systems which reject other foreign (differently mutated) cells, so, Checkmate, moron.
A lot of crack pottery going on around here...
Anyway, evolution may certainly favor cancer-susceptibility for any number of reasons. A mutation that makes you more fit to produce young during your own relative youth could trigger an increase in cancers later.
The more likely explanation is that most people have historically died of something other than cancer and long after they produced their offspring, making cancer a complete non-entity as far as evolutionary fitness goes. We simply haven't lived in a way that makes anti-cancer (or anti-obesity or anti-heart-disease) a factor for near long enough to have evolution drive us in that direction.
Yes, naked mole rats don't tend to get cancer but that's literally one in a million. The vast majority of species are perfectly susceptible to it, they just don't live long enough in the wild for the issue to pop up.
If you don't publish papers, you don't get funding. Sucks, but that's what we get for budget cut after budget cut, tax cut, after tax cut.
The big question appears to be if the latent infected cells can clear or deactivate HIV, or if they'll happily activate, travel to the site of an infection of some other kind, then start spewing HIV everywhere.
This process is basically cells realizing they are being infected (virus) or eaten (bacteria) by a foreign organism, and responding by killing themselves and spewing massive amounts of chemicals that alert the immune system to the problem. Normally, this recruits other immune cells to the site and is probably the right strategy 99% of the time. The problem is when the infected cells are immune cells themselves, their death just recruits more immune cells to an area with a higher chance of picking up HIV. What they found was that the body's stockpile of immune cells in the spleen, etc (normally dormant, awaiting an infection) get infected by HIV, but don't replicate the virus due to being inactive, however they are active enough to sense the virus in their DNA and kill themselves before repair mechanisms can remove or deactivate the virus genes.
The drug mentioned apparently shuts down or reduces this pathway, opening you up to a higher risk of bacterial infection but slowing or stopping the massive die-off of immune cells (assuming they are able to clean themselves up).