With the opening of the Salesforce Tower looming in the next few weeks, there's a flurry of media attention.

Here are two very interesting articles, with lots of links to chase:

• Transbay Transformed

  As the blocks around the transit center fill up with towers, San Francisco is getting a crash course in what high-density urban living is all about.

• San Francisco’s Skyline, Now Inescapably Transformed by Tech

  While few were looking, tech ate San Francisco, a development encouraged by Mayor Ed Lee, who unexpectedly died this month. There are now 79,129 high-tech jobs in the city, about triple the number a decade ago, according to a new research report from the real estate firm CBRE.

  If you work in an office in the city, there is a 28 percent chance you work in tech. That level is exceeded only by Seattle, where the sharp growth of Amazon pushed the percentage of tech workers up to 38 percent, and by Silicon Valley itself, where it is 42 percent.

  “San Francisco has gone from being driven by multitudes of industries in 2007 to being now focused largely on tech,” said Colin Yasukochi, a CBRE analyst. “The growth feeds on itself. Tech workers are attracted to the great opportunities in the city, and the supply of workers means more tech companies come here.”

And no, I'm not moving into the new building.

And yes, it really does look like all the new office floors will be the dreadfullymistakenawfullyhorribleopen seating arrangement.

Sigh.

• Steven Bellovin on Bitcoin

  When you engineer a system for deployment you build it to meet certain real-world goals. You may find that there are tradeoffs, and that you can’t achieve all of your goals, but that’s normal; as I’ve remarked, “engineering is the art of picking the right trade-off in an overconstrained environment”. For any computer-based financial system, one crucial parameter is the transaction rate. For a system like Bitcoin, another goal had to be avoiding concentrations of power. And of course, there’s transaction privacy. There are less obvious factors, too. These days, “mining” for Bitcoins requires a lot of computations, which translates directly into electrical power consumption. One estimate is that the Bitcoin network uses up more electricity than many countries. There’s also the question of governance: who makes decisions about how the network should operate? It’s not a question that naturally occurs to most scientists and engineers, but production systems need some path for change. In all of these, Bitcoin has failed. The failures weren’t inevitable; there are solutions to these problems in the acdemic literature. But Bitcoin was deployed by enthusiasts who in essence let experimental code escape from a lab to the world, without thinking about the engineering issues—and now they’re stuck with it. Perhaps another, better cryptocurrency can displace it, but it’s always much harder to displace something that exists than to fill a vacuum.

  (tags: steven-bellovinbitcointechsoftwaresystemsengineeringdeploymentcryptocurrencycypherpunks)

This blog post of mine was initially published by Computerworld UK in 2010.

I’m amazed at how many so-called “enterprise software systems” do not embrace the Web model in 2010, making them way much harder and much less fun to use than they should be.

I have recently started making parallels between this and music teachers, and the analogy seems to work. Don’t ask where the parallel comes from…weird connections in my brain I guess.

Say you want to learn to play the guitar. Someone recommended Joe, who’s teaching in his downtown studio.

You get there almost on time. Traffic. You find Joe’s studio and here he is, dressed in a neat and simple casual outfit. Smiling at you.

Joe: Hey welcome! So you wanna learn to play?

You: Yes. I brought my guitar, got it from my uncle. It’s a bit worn out as you can see.

Joe: I see…well, you might want to get a better one if you continue past the first few lessons, but for now that will do! Do you have something that you would like to play to get started?

You: “Smoke on the water”, of course. The opening line.

Joe: Let’s try that then, I’ll show you! Just plug your guitar in this amplifier, and let me setup some nice effects so you get a cool sound.

Joe plays the first few bars a few times, shows you how that works and you give it a try. Ten minutes later you start sounding half-decent and you’re having loads of fun playing together with Joe.

Joe: Okay, you’re doing good! I’ll show you my rough course plan so you know what’s up next. I’m quite flexible when it comes to the curriculum – as long as you’re having fun and progressing we’ll be fine.

It’s easy to imagine the bad teacher version of this story:

• Unwelcoming
• Complains because you’re three minutes late.
• Wears a boring old-fashioned suit, and not willing to let you play that crappy old guitar.
• Boring you with tons of scales before you can start playing a song.
• Not giving you an overview of what comes next.
• Not ready to compromise on His Mighty Standard Teaching Program.
• Making you feel stupid about how bad a player you are.

Bad software is like that bad teacher:

• Hard to get started with.
• Requires tons of specific client software of just the right version.
• Requires you to enter loads of useless information before doing anything useful or fun.
• Not willing to let you explore and do your own mistakes, and making sure you feel stupid when mistakes occur.

The Web model is the way to go, of course.

• Ubiquitous access.
• Welcoming to various types of client software.
• Easy to point to by way of permanent URLs.
• Doing its best (fail whales anyone?) to keep you informed and avoid making you feel stupid when something goes wrong.
• Letting you explore its universe with simple web-based navigation, and rewarding your efforts with new discoveries.

This is 2010, and this is the Web. Don’t let any useless software stand between you and the information and services that you need.

This blog post of mine was initially published by Computerworld UK in 2010.

As open source comes of age and becomes mainstream, more and more job postings include “open source skills” in their requirements.

But do you really want to hire someone who spends their time exchanging flames with members of their own community in public forums? Someone who greets newcomers with “I have forwarded your question to /dev/null, thanks” and other RTFM answers?

Luckily, open source communities are not just about being rude and unwelcoming to strangers. Most of them are not like that at all, and the skills you learn in an open source community can make a big difference in a corporate environment as well.

One very important skill that you learn or improve in an open source community is to express yourself clearly in written form. The mailing lists or forums that we use are very limited compared to in-person communications, and extra care is required to get your message through. Being concise and complete, disagreeing respectfully, avoiding personal attacks and coping with what you perceive as personal attacks are all extremely useful skills on the job. Useful skills for your whole life actually.

Once you master asynchronous written discussions as a way to build group consensus, doing the same in a face to face meeting can be much easier. But the basic skills are the same, so what you learn in an open source community definitely helps.

Travel improves the mind, and although being active in open source can help one travel more, even without traveling you’ll be exposed to people from different cultures, different opinions, people who communicate in their second or third language, and that helps “improve your mind” by making you more tolerant and understanding of people who think differently.

Not to mention people who perceive what you say in a different way than you expected – this happens all the time in our communities, due in part to the weak communications channels that we have to use. So you learn to be extra careful with jokes and sneaky comments, which might work when combined with the right body language, but can cause big misunderstandings on our mailing lists. Like when you travel to places with a different culture.

Resilience to criticism and self-confidence is also something that you’ll often develop in an open source community. Even if not rude, criticism in public can hurt your ego at first. After a while you just get used to it, take care of fixing your actual mistakes if any, and start ignoring unwarranted negative comments. You learn to avoid feeding the troll, as we say. Once your work starts to produce useful results that are visible to the whole community, you don’t really care if someone thinks you’re not doing a good job.

The technical benefits or working in open source communities are also extremely valuable. Being exposed to the work and way of thinking of many extremely bright developers, and quite a few geniuses, definitely helps you raise the bar on what you consider good software. I remember how my listening skills improved when I attended a full-time music school for one year in my youth: just listening to great teachers and fellow students play made me unconsciously raise the bar on what I consider good music.

Open source communities, by exposing you to good and clever software, can have the same effect. And being exposed to people who are much better than you at certain things (which is bound to happen for anybody in an open source project) also helps make you more humble and realistic about your strengths and weaknesses. Like in soccer, the team is most efficient when all players are very clear about their own and other players’ strengths and weaknesses.

You’ll know to whom you should pass or not pass the ball in a given situation.

To summarise, actively participating in a balanced open source community will make you a better communicator, a more resilient and self-confident person, improve your technical skills and make you humbler and more realistic about your strengths and weaknesses.

It is no secret that, for awhile at least, Apache OpenOffice had lost its groove.

Partly it was due to external issues. Mostly that the project and the committers were spending a lot of their time and energies battling and correcting the FUD associated around the project. Nary a week would go by without the common refrain "OpenOffice is Dead. Kill it already!" and constant (clueless) rehashes of the history between OpenOffice and LibreOffice. With all that, it is easy and understandable to see why morale within the AOO community would have been low. Which would then reflect and affect development on the project itself.

So more so than anything, what the project needed was a good ol' shot of adrenaline in the arm and some encouragement to keep the flame alive. Over the last few months this has succeeded beyond our dreams. After an admittedly way-too-long period, we finally released AOO 4.1.4. And we are actively working on not only a 4.1.5 release but also preparing plans for our 4.2.0 release.

And it's there that you can help.

Part of what AOO really wants to be is a simple, easy-to-user, streamlined office suite for the largest population of people possible. This includes supporting old and long deprecated OSs. For example, our goal is to continue to support Apple OSX 10.7 (Lion) with our 4.2.0 release. However, there is one platform which we are simply unsure about what to do, and how to handle it. And what makes it even more interesting is that it's our reference build system for AOO 4.1.x: CentOS5

Starting with AOO 4.2.0, we are defaulting to GIO instead of Gnome VFS. The problem is that CentOS5 doesn't support GIO, which means that if we continue with CentOS5 as our reference build platform for our community builds, then all Linux users who use and depend on those community builds will be "stuck" with Gnome VFS instead of GIO. If instead we start using CentOS6 as our community build server. we leave CentOS5 users in a lurch (NOTE: CentOS5 users would still be able to build AOO 4.2.0 on their own, it's just that the binaries that the AOO project supplies won't work). So we are looking at 3 options:

1. We stick w/ CentOS5 as our ref build system for 4.2.0 but force Gnome VFS.
2. We move to CentOS6, accept the default of GIO but understand that this moves CentOS5 as a non-supported OS for our community builds.
3. Just as we offer Linux 32 and 64bit builds, starting w/ 4.2.0 we offer CentOS5 community builds (w/ Gnome VFS) IN ADDITION TO CentOS6 builds (w/ GIO). (i.e.: 32bit-Gnome VFS, 64bit-Gnome VFS, 32bit-GIO, 64bit-GIO).

Which one makes the most sense? Join the conversation and the discussion on the AOO dev mailing list!

1. The P6 could provisionally guess which way a branch was going to go, speculatively executing that path until it became clear whether or not the guess was correct -and then commit/abort that speculative code path.
2. It uses a branch predictor to make that guess on the direction a branch was taken, based on the history of previous attempts, and a default option (FWIW, this is why I tend to place the most likely outcome first in my if() statements; tradition and superstition).
3. It could execute operations out of order. That is, it's predecessor, the P5, was the last time mainstream intel desktop/server parts executed x86 code in the order the compiler generated them, or the human wrote them.
4. register renaming meant that even though the parts had a limited set of registers, those OOO operations could reuse the same EAX, EBX, ECX registers without problems.
5. It had caching to deal with the speed mismatch between that 150 MHz CPU & RAM.
6. It supported dual CPU desktops, and I believe quad-CPU servers too. They'd be called "dual core" and "quad core" these days and looked down at.

1. What does the generated java assembly for the Ival++ on a java long look like?
2. What if the long is marked as volatile?
3. What does the generated x86 assembler for a Java Optional<AtomicLong> opt.map(AtomicLong::addAndGet(1)) look like?
4. What guarantees do you get about reordering?
5. How would you write code which attempted to defend against speculation timing attacks?
   

• Webdoctor.ie

  An online doctor appointment — you fill out a questionnaire, are interviewed via VC, and receive any prescription you need. Recommended by devxda on the ITC slack

  (tags: doctormedicineirelandserviceshealth)

• The mysterious case of the Linux Page Table Isolation patches | Hacker News

  good HN comments on the horrible security bug du jour — Intel CPUs potentially allowing privileged data leaks cross-VM and cross-process

  (tags: lptlinuxvmintelcpussecurity)

• These experts figured out why so many bogus patents get approved | Ars Technica

  A recent paper published by the Brookings Institution offers fascinating insights into this question. Written by legal scholars Michael Frakes and Melissa Wasserman, the paper identifies three ways the patent process encourages approval of low-quality patents: The United States Patent and Trademark Office (USPTO) is funded by fees—and the agency gets more fees if it approves an application. Unlimited opportunities to refile rejected applications means sometimes granting a patent is the only way to get rid of a persistent applicant. Patent examiners are given less time to review patent applications as they gain seniority, leading to less thorough reviews. None of these observations is entirely new. For example, we have covered the problems created by unlimited re-applications in the past. But what sets Frakes and Wasserman’s work apart is that they have convincing empirical evidence for all three theories.

  (tags: patentsusptoswpatsbrookings-institutionpatentinglaw)

• SE Asia travel pro-tip from Naomi Wu

  Naomi Wu on Twitter: “Honestly Saccharomyces boulardii solves the problem [of dodgy tummy] for most people, it’s what I take when I travel to SE Asia”

  (tags: fooddiarrhoeas-boulardiibactericadigestionhealthtravelse-asiatips)

As the old year falls away and the new year boots up, it is traditional for people to write "old year retrospectives" as well as "new year predictions." Heck, I originally envisioned this entry as a duet of 2 separate blogs. But as much as I tried, it was just too difficult to keep them distinct and self-contained. There was simply too much overlap and as much as I expect "new things" in 2018, I think 2018 will mostly be a solidification of events and issues ramped up from 2017.

So with all that in mind, I present my 2017-2018 Introspections... in no particular order:

Before we get to the main event (just be patient), I want you to first spend a little time with something that I think is actually a much MORE interesting story about computer security: The strange story of “Extended Random”

Yesterday, David Benjamin posted a pretty esoteric note on the IETF’s TLS mailing list. At a superficial level, the post describes some seizure-inducingly boring flaws in older Canon printers. To most people that was a complete snooze. To me and some of my colleagues, however, it was like that scene in X-Files where Mulder and Scully finally learn that aliens are real.

Why is this such a great story?

1. Well, for one thing, it's been going on for more than a decade. That's a long time.
2. For another thing, the technology involved is quite complex: multiple software systems have to interact, in quite complex ways
3. And for another thing, at least one part of the overall vulnerability involves simply including additional COMPLETELY RANDOM DATA in your messages over the network. How is adding some extra random data a vulnerability? (You'll have to read the article for yourself)
4. But most importantly, as opposed to most computer security vulnerabilities, this isn't simply an implementation mistake made by some systems programmer; from everything we can determine, it is actually the result of deliberate sabotage by our own government, sabotage so subtle that, fifteen years later, the best cryptographic minds in the world are still picking through the details.

Anyway, enough of that.

I know what you came here for.

You want to hear what good old RowHammer has been up to over the last couple years, right?!

Well, unless you've been living in a cave (and who reads blogs if they live in a cave?), you know that what we're talking about here is Reading privileged memory with a side-channel, also known as: "the latest amazing work by the astonishing Google Project Zero team."

Well, anyway, here are the goods:

• Reading privileged memory with a side-channel

  We have discovered that CPU data cache timing can be abused to efficiently leak information out of mis-speculated execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts.

• Meltdown and Spectre

  These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.

• Meltdown

  Meltdown allows an adversary who can run code on the vulnerable processor to obtain a dump of the entire kernel address space, including any mapped physical memory. The root cause of the simplicity and strength of Meltdown are side effects caused by out-of-order execution.

• Spectre Attacks: Exploiting Speculative Execution

  in order to mount a Spectre attack, an attacker starts by locating a sequence of instructions within the process address space which when executed acts as a covert channel transmitter which leaks the victim’s memory or register contents. The attacker then tricks the CPU into speculatively and erroneously executing this instruction sequence, thereby leaking the victim’s information over the covert channel. Finally, the attacker retrieves the victim’s information over the covert channel. While the changes to the nominal CPU state resulting from this erroneous speculative execution are eventually reverted, changes to other microarchitectural parts of the CPU (such as cache contents) can survive nominal state reversion.

• Mitigations landing for new class of timing attack

  Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. This includes both explicit sources, like performance.now(), and implicit sources that allow building high-resolution timers, viz., SharedArrayBuffer.

• KASLR is Dead: Long Live KASLR

  In this paper, we present KAISER, a highly-efficient practical system for kernel address isolation, implemented on top of a regular Ubuntu Linux. KAISER uses a shadow address space paging structure to separate kernel space and user space. The lower half of the shadow address space is synchronized between both paging structures.

• The mysterious case of the Linux Page Table Isolation patches

  Of particular interest with this patch set is that it touches a core, wholly fundamental pillar of the kernel (and its interface to userspace), and that it is obviously being rushed through with the greatest priority. When reading about memory management changes in Linux, usually the first reference to a change happens long before the change is ever merged, and usually after numerous rounds of review, rejection and flame war spanning many seasons and moon phases.

  The KAISER (now KPTI) series was merged in some time less than 3 months.

• Quiet in the peanut gallery

  I wish there were some moral to finish with, but really the holidays are over, the mystery continues, and all that remains is a bad taste from all the flack I have received for daring intrude upon the sacred WordPress-powered tapestry of a global security embargo.

• Re: Avoid speculative indirect calls in kernel

  I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

  .. and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.

  Or is Intel basically saying "we are committed to selling you shit forever and ever, and never fixing anything"?

• Today's CPU vulnerability: what you need to know

  The Project Zero researcher, Jann Horn, demonstrated that malicious actors could take advantage of speculative execution to read system memory that should have been inaccessible.

It's pretty interesting stuff.

It will take a while to dig through and think about.

But, it's important to note: this is primarily an attack against large, shared servers, which typically run software on behalf of many unrelated parties on the same physical system, using techniques such as "virtualization", or "containers".

Think "cloud computing."

Those environments are the ones which are spending the most amount of time thinking about what these new findings mean.

• Nicole Perlroth’s roundup on the Spectre and Meltdown security holes

  Excellent roundup — this really is amazingly bad news for CPU performance and fixability

  (tags: meltdownspectrenicole-perlrothsecuritycpuperformancespeculative-executionintelamdarm)

• These stickers make AI hallucinate things that aren’t there – The Verge

  The sticker “allows attackers to create a physical-world attack without prior knowledge of the lighting conditions, camera angle, type of classifier being attacked, or even the other items within the scene.” So, after such an image is generated, it could be “distributed across the Internet for other attackers to print out and use.” This is why many AI researchers are worried about how these methods might be used to attack systems like self-driving cars. Imagine a little patch you can stick onto the side of the motorway that makes your sedan think it sees a stop sign, or a sticker that stops you from being identified up by AI surveillance systems. “Even if humans are able to notice these patches, they may not understand the intent [and] instead view it as a form of art,” the researchers write.

  (tags: self-drivingcarsaiadversarial-classificationsecuritystickershacksvisionsurveillanceclassification)

• Notes from the Intelpocalypse [LWN.net]

  What emerges is a picture of unintended processor functionality that can be exploited to leak arbitrary information from the kernel, and perhaps from other guests in a virtualized setting. If these vulnerabilities are already known to some attackers, they could have been using them to attack cloud providers for some time now. It seems fair to say that this is one of the most severe vulnerabilities to surface in some time. The fact that it is based in hardware makes things significantly worse. We will all be paying the performance penalties associated with working around these problems for the indefinite future. For the owners of vast numbers of systems that cannot be updated, the consequences will be worse: they will remain vulnerable to a set of vulnerabilities with known exploits. This is not a happy time for the computing industry.

  (tags: hardwarecpusintelamdspectremeltdownsecurity)

• Aadhaar’s Dirty Secret Is Out, Anyone Can Be Added as a Data Admin

  If you think your Aadhaar data is only in the hands of those authorised to access the official [Indian national] Aadhaar database, think again. Following up on an investigation by The Tribune, The Quint found that completely random people like you and me, with no official credentials, can access and become admins of the official Aadhaar database (with names, mobile numbers, addresses of every Indian linked to the UIDAI scheme). But that’s not even the worst part. Once you are an admin, you can make ANYONE YOU CHOOSE an admin of the portal. You could be an Indian, you could be a foreign national, none of it matters – the Aadhaar database won’t ask. A person of your choosing would then have access to the data of all 119,22,59,062 Aadhaar cardholders.

  (tags: aadhaarsecurityfailvulnerabilitiesprivacy)

• My bedroom lights turn on when my blood sugar goes low! (Dexcom, Nightscout and IFTTT) : diabetes

  Now this is a great idea — IOT to the rescue

  (tags: iotvia:fpvia:eatpastebloodhealthdiabetesmonitoringhome)

• Random with care

  Some tips about RNGs and their usage (via Tony Finch)

  (tags: codingrandommathrngsprngsstatisticsdistributions)

Peter Frankopan's The Silk Roads: A New History of the World is an extremely ambitious book.

It sets out to survey, in a single 500 page volume, some 2000+ years of history of the region which, roughly speaking, spans from Turkey and Egypt to Mongolia and Pakistan in the one direction, and from Yemen to Russia in the other.

That's a lot of land, and a lot of time, to cover.

Certainly if you, like me, struggle to distinguish Basra from Bactria, Samarkand from Sanjan, Karakorum from Kashgar, Mosul from Mashad, Dushanbe from Dunhuang, or Istanbul from Isfahan (ok, well, that last one I knew), then you'll find a lot to learn in this history of human activity in Central Asia over the last few thousand years.

And it's certainly a colorful book, full of great stories of traders, adventurers, explorers, merchants, prophets, and their interactions.

(Attila the Hun! Genghis Khan! Richard Lionheart! The Black Death! Vasco da Gama! T.E. Lawrence! Timur! Marco Polo!)

It's an immense scope, though, and Frankopan can barely get going on one episode before he races on to the next, breathless and impatient, rather like the White Rabbit: always in a hurry, but not quite sure where he's going.

I didn't mind any of the minutes I spent with The Silk Roads, but in the end I'm afraid that this part of the world is still rather a blur to me, which is a shame, because I think that's precisely the problem that Frankopan set out to solve.

Would he have been more successful (with me, at least), had he confined himself to a smaller region, or a shorter time period, the better to have used those pages to spend more time inhabiting particular incidents and characters? I'm not sure. I'm not much of a reader of histories, so I suspect this problem is just endemic to the genre, and it really just means that while his book was fascinating, I'm not really the target audience.

1. If you can get the exploit in, then you'd have access to other bits of the memory space of the same JVM, irrespective of what the OS does. That means one thread with a set of Kerberos tickets could perhaps grab the secrets of another. IT'd be pretty hard, given the way the JVM manages objects on the heap: I wouldn't know where to begin, but it would become hypothetically possible.
2. If you can get native code which you don't trust loaded into the JVM, then it can do whatever it wants. The original meltdown exploit is there. But native code running in JVM is going to have unrestricted access to the entire address space of the JVM -you don't need to use meltdown to grab secrets from the heap. All meltdown would do here is offer the possibility of grabbing kernel space data —which is what the OS patch does.

• Post-apocalyptic life in American health care

  My god, this is so dysfunctional. ‘I observe that American health care organizations can no longer operate systematically, so participants are forced to act in the communal mode, as if in the pre-modern world. Health care is one leading edge of a general breakdown in systematicity — while, at the same time, employing sophisticated systematic technologies. For complex health care problems, I recommend hiring a consultant to provide administrative (not medical!) guidance.’ via Craig.

  (tags: bureaucracyhealthcarehealthsystemsus-politicsinsurancemedicinedysfunctionalfailfiascovia:craig)