The menu of the linked post has an entry named 'Source' which points to:
354 karma · joined November 13, 2011
Engineer at Snowflake. Co-founder at Radiopaper, PerfectSchedule. Ex-Google. Ex-Mixpanel. Ex-Stripe.
Views here are my own.
It was a (poor) business decision not to go for public cloud earlier, but not driven by datacenter capacity.
Even if this is true, isn't it mitigated by certificate pinning?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
A couple of small known issues I haven't fixed up yet:
* I'm not correctly taking into account the number of coupon payments in the current year and final year for each bond, just assuming it's 4 like every other year.
* Prices are updated manually, I've got some code that scrapes the ASX to get new prices, just needs to be hooked up.
Once this is a bit more polished, I'll publish a version that does the same calculations with US TIPS instead of Australian eTIBs.
Thanks!
While I do tend to spend more of the interview time talking about sysadmin tools, operating systems, networking, databases, security and troubleshooting, I still expect candidates to have reasonably good coding chops.
The difference is that the coding questions tend to be more task-oriented or procedural (i.e. log processing, building automation pipelines, implementing standard unix cli tools, etc.), rather than the algorithmically challenging or math-oriented problems that we'd usually ask SWE candidates.
Both the SE and SWE side SRE candidates need to be able to design and reason about large systems, making trade-offs between performance (especially latency), redundancy and cost.
[these opinions are my own, not necessarily those of my employer, Google]
Reported it at https://www.google.com/safebrowsing/report_phish/ but mentioning here so that others don't fall victim to it.
If you're familiar with that project, could you comment on the main differences in YouTransfer?
If you can steal somebody else's cookies (which are not Channel-bound) then that's true. If you can only steal or predict somebody else's session ID's, the HMAC provides protection.
It's not atypical for session IDs to be simple counters that get incremented for each new session. If your session ID is 100042, it's a pretty good bet that 100041 and 100043 are valid session IDs as well, and without HMAC, a user could take over these sessions trivially.
The even better mitigation to cookie theft, which I also mention, is TLS ChannelID. ChannelID creates a unique private/public keypair for each new TLS connection, and sends the public part along in the TLS handshake. Then, when you resume sessions from the same machine, you can prove that you have the private part and the server can accept your existing cookies. With this approach, cookies are no longer bearer tokens and stealing cookies becomes worthless.
This can be hardened even against local malware running as the same principal as the user doing the browsing if the browser's ChannelID implementation generates and stores the private key inside a TPM or HSM.
A relatively simple way to accomplish this is to have your application include an HMAC in the cookie contents, and verify it whenever the cookie is received. e.g, if you are storing $session_id in a cookie, change your cookie contents to be "$session_id:$hmac_of_session_id", and verify the HMAC every time a cookie is presented.
Now a user, or malware, or a MITM, is not in the position to take over or modify a different user's session simply by altering the cookie, since they will not be able to produce a valid HMAC (the key is never shared with the user).
If even storing the key in your web frontends is too risky, you could use RSA or DSA signatures, only store the public key in the web frontend that verifies cookies, and store the private key in a more hardened cookie-signing service that isn't directly exposed to external networks. This service can be invoked when new sessions are created or upon user login, if applicable.
On top of this, if the client supports ChannelID, you should include the ChannelID in the message that is HMAC'd, so that stolen cookies cannot be reused on other machines.
That's only true if your 4 queries need to read every single column.
One of the big advantages of BigQuery's column-oriented storage is that you only pay to read the columns that are actually needed to answer your query.
For example, this query to extract the top 10 authors only cost me 19GB to run (and took 7.0s):
SELECT
author,
COUNT(*) AS COUNT
FROM
TABLE_QUERY([fh-bigquery:reddit_comments], "table_id CONTAINS '20' AND LENGTH(table_id)<8")
GROUP EACH BY
author
ORDER BY
COUNT DESC
LIMIT
10;
author,COUNT
[deleted],228425822
AutoModerator,3677774
conspirobot,575576
ModerationLog,547671
autowikibot,402076
PoliticBot,388395
imgurtranscriber,360248
dogetipbot,358093
qkme_transcriber,301968
TweetPoster,293309Mid last year a recruiter from Dropbox told me they were looking into this, and wanted to make it happen in 2014.
http://static.googleusercontent.com/media/research.google.co...
There's really a need for a good open-source equivalent to Colossus, which would allow startups like the hypothetical one you describe to do storage must more cheaply and reliably. HDFS (with HDSF-RAID) is probably the closest.. but it's still a long way off.
I'd be interested in what other assumptions you're using to come up with the $5/T profit margin. Are you considering the cost of ingress and egress bandwidth, cooling, personnel to enact repairs? With a large enough fleet you'll have many drives/machines die every day. What about a team of engineers in an on-call rotation to keep to respond when (inevitable) failures occur? Just pointing out that drives + power is only part of the total cost of running such a service.
Uhh.. I sure hope the cookie tokens are not stored directly on the server-side, but rather verified against a (cryptographic) hash of same. These credentials are as valuable to an attacker as a password (albeit relatively short-lived).
It seems there's a wikipedia article on the dispute: http://en.wikipedia.org/wiki/Fewer_vs._less
Which mentions the 'rule' started to get pushed around in the 1800s, though 'Less has always been used in English with counting nouns.'
I suppose we'll always be stuck with this ambiguity in English since there's no formal authority to tell us how we should speak/write.
From my own observations, having grown up in Australia and since moved to the US, I must say the common practice is notably different, I almost never heard anyone say fewer in Australia, but have noticed that many Americans (like the poster here) seem to be on a crusade to ensure less isn't 'misused'.
"There is a debate about whether the word should be 'less' or 'fewer'," a campaign spokesman said. "Saying 'up to ten items' is easy to understand and avoids any debate."
and
A Tesco spokesman said: "The debate about what is right has been going on for years now, and I still don't think we know if 'less' or 'fewer' is correct."
'less' is an acceptable comparative for both countable and uncountable nouns in all modern dialects of English except for US-English, where it's strictly expected that fewer be used for countables.
Perhaps caiob is from the UK, Australia, India, South Africa, New Zealand...
Perhaps we Googlers start to take for granted some of the things that really are quite extraordinary - like the 150ft to food policy, the pieces of historical computing machinery that are kept around, the guest chefs that visit, the artworks that have been commissioned, the fact that we hold regular 'espresso office hours' and occasional mixology classes, and even the corporate essentials that Google really pulls off, like the Tech Stops, phone rooms, visitor badging system and video conferencing setup. Even though it's 'just an office space', it isn't like any other, and getting to see it as a potential future employee can be pretty motivational.
I'm sure they will contact you via regular customer support channels (ie. not HN) if they need any more info to debug the problem.