I'm not so worried about duplication by academics -- that does not happen often -- but rather about academic research that's just wrong: makes bad assumptions, uses a flawed methodology, fails to address the general case.
The issue is that when doing a sabbatical/internship at a company, it's often not possible to write a paper - either because there's not time, or the company may not want to publish the work (which could be confidential). I wouldn't go to a company expecting to be able to publish about the project.
(I'm the author of the original blog post.) Ad hominem attacks aside, I do think it's a big deal if a bunch of academics are spending time working on the wrong things, if for no better reason than maximizing efficiency: Don't forget that most academic research is funded by the government. Since I also happen to help decide which research proposals Google funds, I also care that academics are well-aligned with the problems we care about. Clearly we also need to invest in long term bets. But there is a big difference between doing long-term, potentially-groundbreaking research and bad industry-focused research.
This line: "You do not need to provide any personally identifying information in order to use Chrome" is intended to cover pretty much all of the cases you describe. I'm not going to speculate on legal issues.
This is not strictly true. In most cases, Chrome uses an encrypted (HTTP/2) connection to the Flywheel proxy which would bypass by ISP-side middleboxes. However, some carriers are downgrading the Flywheel connection to HTTP for the purposes of implementing adult content filtering; see https://support.google.com/chrome/answer/3517349. So we do "remove the mobile carrier from the circuit" in most cases.
I absolutely agree with your rationale for not wanting to opt in; we appreciate that this is a highly privacy-sensitive topic and one that users need to make up their own minds about.
I'm the tech lead for the Flywheel proxy. The original version of Flywheel actually started with PageSpeed (with a bunch of customizations to focus on compression). You can indeed emulate Flywheel's optimizations with the appropriate configuration options for PageSpeed. We ended up rewriting Flywheel (in Go) in part because we didn't need all of the complexity that PageSpeed provides, but also to streamline the process of running the service in Google's datacenters, rather than in an Apache or NGINX environment.
I am the tech lead on the Flywheel proxy. We do not use the data passing through the proxy for any purpose other than compression. This is covered by the Chrome privacy policy which you can read here:
The proxy does much more than just gzip; this paragraph refers to only the impact of gzip on the Web (which was surprising to us given how widespread we assumed it would be).
I am the tech lead on the Flywheel proxy. The feature is currently launched for Chrome on Android, iOS, and desktop (including ChromeOS). There is no plan to implement this outside of Chrome.
Flywheel does not MITM SSL connections; it does not proxy SSL at all. If you just mean "MITM" in a generic sense, the fact that you believe you have "data sovereignty" is interesting since we're talking about unencrypted HTTP here. Nearly all ISPs and mobile carriers undertake proxying and extensive analysis and manipulation of in-the-clear HTTP traffic. We agree that users need to opt into this feature -- since you have to trust Google to proxy your traffic, after all -- but it's important to keep in mind that many other parties on the path between you and a website already do transparently proxy your unencrypted traffic.
That's a fair point. It's true my job has shifted much more towards being like a professor than being an individual contributor SWE. Still, lots of differences with academic life: Far lower overhead, far less administrative work, much greater assurance of success (not being subject to peer review for everything), etc. So overall more satisfying although the day-to-day schedule might look roughly the same.
OP here. Lots of people at Google have PhDs. Most do not. My role is actually a Tech Lead Manager, which is far more technical than a typical manager position, and indeed I am on the Software Engineer ladder. I would say about 80% of my time is spent on technical things (writing code, design docs, evaluating designs, etc.) and only about 20% on "manager" activities like doing performance reviews, hiring, and the like. More here: http://matt-welsh.blogspot.com/2013/04/running-software-team...
As far as "wasting education" is concerned, I've blogged extensively about the differences between doing applied research in industry and doing that kind of work in academia or in a more pure research setting, see for example http://matt-welsh.blogspot.com/2010/11/why-im-leaving-harvar...
I find that applying my skills as a systems and networking researcher in an industry setting, where I have the chance to develop and launch real products, is far more satisfying than just writing academic papers. But this is of course not for everyone.
Well, I wrote a large chunk of the system and am still on the pager rotation along with the rest of the eng team. At some point we'll hand off pager duty to the SRE team.
I did the original study at Google on SPDY over mobile networks, which was a small-scale lab study. Since then, we have collected data from millions of Chrome Mobile users which shows that SPDY does tend to outperform HTTP on cellular, but of course there are many factors involved - the content of the site, the network conditions, etc. I haven't had a chance to get this data into a form that can be shared, which I really need to do. Still, the authors of this CoNext paper did a really nice study. I hope we have more to share on this in the future.
This is a nice article, but I disagree with the statement that "most of the time", users are accessing the mobile web via cellular (not WiFi) networks. The data that I have seen on this is that the vast majority of mobile web usage is via WiFi - more than 70-80% of mobile pageloads occur on WiFi networks. (Context: I run the mobile web performance team at Google, part of Chrome.) This is in part because web usage is higher on tablets than on phones, but even on phones we see WiFi being the most commonly used network by far. This is not to say that cellular performance isn't important, but this skew might be somewhat surprising to people working in this area.
Good point. Maybe you could check out one of the many other open source Go projects out there as an alternative. I'm not sure reading our code would give you that eureka moment, since it only made sense to me since I was so familiar with the old code :-)
I would love to open source this system, but even if we did I'm not sure we'd be able to convince you that using Go was better than some other language in terms of developer productivity. How would having access to the source help?
The Go module system for sure. Also I really like Go's interface model (as opposed to Java or C++ classes) as it is more flexible and in some ways more precise. Note that I don't know Ruby so I can't compare Go to that...
We've done lots of load testing and the CPU and memory footprint of the Go version is better than the C++ version. Not surprising since we reduced the code size so much, but at least using Go did not involve significant bloat.
OP here. I do actually use vim but I have yet to adopt most of the fancy plugins that vim provides -- put me in a time machine back to 1977 and I would be very capable of programming on any UNIX system that you'd drop me in front of, provided it had vi installed. I'm not defending this choice of lifestyle; it's just how I learned to program :-)
OP here. It is absolutely true that we did not rewrite the entire original system in Go; I tried to be very explicit about that in the blog post. But, I feel confident that it could be done, in much less code, with greater clarity and modularization. The Go language by itself does not force good software design. A rewrite in any language would have been better than the original system, but our decision to use Go turned out to be fortuitous in that we managed to do so in record time and with much greater programmer productivity.