

The Woman at the Heart of Everything Google Builds - lingben
http://www.wired.com/wiredenterprise/2013/07/melody_meckfessel_google/all/

======
tippytop
I'm sure Ms. Meckfessel is a lovely person, but this is clearly a PR driven
piece pumped out of Google for recruitment purposes.

Throughout this entire NSA scandal people lament there's nothing we can do,
but these tech companies are vulnerable to talent shortages. A simple action
for a conscientious hacker is to simply not work for PRISM collaborators.
Apply your talents to companies willing to make privacy assurances.

~~~
rryan
> PRISM collaborators

You mean companies that comply with US law? So your advice is to work outside
of the US?

~~~
EthanHeilman
>You mean companies that comply with US law? So your advice is to work outside
of the US?

1\. Or work in areas which do not handle data that the US requires by law. You
can find software jobs in the US that do not require collaboration with
governmental domestic spying. For instance many people choose not to work for
companies that build weapons of war for a variety of reasons. These people can
still work inside the US.

2\. Additionally non-US residents work for Google. Being outside the US
doesn't really have much relevance to the discuss.

3\. I also reject the notion that Google had no choice. Google may have been
able to comply with the letter of the law without giving up user data by using
e2e cryptography. One can support or question their actions, but they are not
powerless victims in this drama but active agents that can be held responsible
for what they do.

~~~
fpgeek
> Google may have been able to comply with the letter of the law without
> giving up user data by using e2e cryptography.

Only at the cost of not providing the service that users want, which includes
such things as fast, full-text email search, recovering accounts after
passwords (and other security tokens, if any) have been lost. Once Google can
extract the unencrypted email for any purpose, the practical consequences of
their legal obligations make all cryptography Google provides useless against
this sort of attack.

Yes, Google has a choice. But let's be clear on what that choice is: They can
choose whether or not to offer a mass-market email service. Once they've
decided to offer that service, the practical consequences are inevitable,
given the current, relevant legal framework.

~~~
EthanHeilman
I don't think you or I, or even Google knows the total set of their options,
but we can sit here and come up with some alternatives.

>Only at the cost of not providing the service that users want, which includes
such things as fast, full-text email search,

e2e encryption is completely compatible with fast, full-text email search.
There are several companies that currently offer such services, that is
webbased, fast searchable email, that is e2e encrypted such that no plaintext
arrives on the server side (unfortunately I am under an NDA or I would tell
you more but you can read the papers if you like). Stuff like this:
[http://www.forbes.com/sites/andygreenberg/2011/12/19/an-
mit-...](http://www.forbes.com/sites/andygreenberg/2011/12/19/an-mit-magic-
trick-computing-on-encrypted-databases-without-ever-decrypting-them/) It's not
just databases it's search engines as well.

I think gmail probably loses some enterprise clients because they don't do
this, but I expect "enterprise level" features like this from gmail in ~2-3
years by my guess. Probably sooner due to the nosedive in trust they just
took.

Google has a monopoly on new email account creation so they don't need to
innovate to get new customers (hell android locks everyone in). It isn't
outlandish to suggest that they could have chosen to innovate and done what
has been in the research literature for some time now. Secure e2e encrypted
cloud email.

>recovering accounts after passwords (and other security tokens, if any) have
been lost.

Have you tried to get gmail accounts back because I know people that have lost
all their email. Are they better at this now (maybe they are, I hope so)? Even
with this as a requirement, it is achievable. The user's client just sends a
copy of the key to a foreign key escrow service that will unlock their account
if anything happens once they prove they are who they say they are with
various forms of ID and proofs of knowledge. Paranoid users can elect not to
do this. Or ask people in your circles that you have marked as trusted to
attest to your identity. You could do some clever threshold cryptography with
your closest family and friends.

They big trick is making money off ads while not learning about the contents
of the email. One way could be a bounded leakage strategy whereby the
encryption scheme allows some ad matches without giving up more than one or
two popular words per email.

All of this is a sideshow though. The NSA wasn't going to throw the Google
execs in jail for not towing the line. Google is an extremely powerful company
with a strong lobby in Washington. Not to mention that just pressing the
charges would be a major embarrassment for the NSA. Twitter fought and won.
Likely they just offered Google some nice contracts with the US government.

------
WestCoastJustin
The Wired article talks about internal tools used to compile code. In line
with that, there is an interesting video "Building Software at Google Scale"
[1], which seems to give an overview of the systems used.

[1]
[http://www.youtube.com/watch?v=2qv3fcXW1mg](http://www.youtube.com/watch?v=2qv3fcXW1mg)

------
weareconvo
The chick in charge of the Internal Tools team? That shit is widely regarded
within Google as a dead-end ghetto, devoid of opportunities for promotion and
looked down on by the other focus areas.

\- 5+ year Ex-Googler

EDIT: I'm done with this fucking site. You won't have weareconvo to kick
around anymore.

~~~
SeanDav
This is a spiteful and misogynistic comment - you do yourself and this
community, a large disservice.

~~~
wikiburner
Just curious, how offensive is "chick"? I catch myself accidentally using it
every once in a while (a vestige of shitty, all-boys Catholic high schooling).
Should I be mildly embarrassed or mortified?

~~~
jamesaguilar
It depends. If you're using it in a negative statement, it tends to connote a
woman who isn't very smart. If you're making a positive statement, I think it
would be roughly equivalent in formality to calling someone a "babe," without
the connotation of being pretty. So still don't use it to talk about someone
in a professional context.

------
dnautics
really, a story about a prominent female engineer, and the first paragraph is
about how she dresses? I'm hardly a feminist, but this is kind of rediculous.

~~~
mseebach
In context, it's actually pretty relevant. The anecdote, like the piece
itself, is about how she deals with being a woman in a very male dominated
world. Dress is one of the most direct and tangible differences between men
and women.

~~~
dnautics
I'd disagree. But even if it is the "most direct", whatever that means, you
don't think that there are more serious gender-assumption transgressions in
the tech world? It's a little annoying to me that the first anecdote is the
most superficial one.

I give the writer a pass, if Melody herself insists that that's the most
important issue, or if that was, chronologically the first thing that Melody
brought up.

------
voidlogic
>The other key thing, according to Meckfessel, is that the system compiles
code with unusual speed. In typical Google fashion, it spreads compilation
tasks across vast array of servers, rather than generating the executable
software on the developer’s local workstation.

I hope she has more than this to focus on as Go usage is picking up within
Google. And with Go, just the local workstation can do it. :)

~~~
cromwellian
That's only because the amount of Go code is small. Google builds all
transitive dependencies from source in HEAD, so if there were 10 million lines
of Go sitting in the repository, your local workstation won't cut it.

It's not even the build times which are the most pressing issue these days,
but the time for tests to run.

~~~
nostrademons
One of the major design goals for Go was that incremental compiles should not
require a rebuild of all dependencies. I believe they bake interface
information into the library files for this reason. If you don't change a
file, you shouldn't need to rebuild it.

If you sync to a later CL, you might need to rebuild what's changed, but even
then all this should be cacheable across the company. Go was designed as a
language to avoid a lot of the mess that the build tools have to deal with for
C++.

~~~
cromwellian
In theory the same applies to Java, if I have a java_library, and none of the
inputs have changed, I shouldn't have to rebuild anything. But the theory
often doesn't match up to the reality with respect to objfs caching of
dependencies in my experience.

Also, any non-trivial app at Google is going to touch non-Go dependencies.

