mikewest

http://www.chromium.org/blink#new-features has some detail about how we plan to add features to the platform. We're certainly hoping to be pretty transparent about how things get into Chromium.

Yes! Prefixes are damaging. We're hiding things behind flags instead, which gives savvy developers the chance to experiment without the risk that sites will begin to depend on those experiments.

"Whatever it wants" within reason. We're actually quite concerned about how new features are added to the web platform, and recognize the need to be careful about what we commit to support forever. See http://www.chromium.org/blink#new-features for some detail about the process we're planning on using going forward.

WebKit2 is a similar, but different, multi-process model. Chromium never compiled it in, but the integration imposed various constraints both on Chromium and on WebCore. That's certainly one of the reasons we've introduced Blink.

With regard to open, Chromium is a nicely open source project, and we're really quite committed to transparency in the project. See http://www.chromium.org/blink#new-features for some of our policies in this direction.

http://www.chromium.org/blink/developer-faq has a bit more information, as does http://www.chromium.org/blink#architectural-changes. There really are good architectural reasons to go in this direction.

CSP doesn't block you from using social networking widgets: it does insist, however, that you specify up front which widgets you'll be using, and to whitelist those domains. If you trust Facebook's JavaScript, for example, you can certainly include it on your site. You'll need to whitelist the appropriate domain for framing or scripting, that's all.

As long as it's in an external JS file, sure. CSP simply prevents you from calling script inline. `<script>#('something').hide();</script>` wouldn't work: you'd have to move your JavaScript code into an external file.

For example, you could load the library from Google's CDN by whitelisting the origin via `script-src http://ajax.googleapis.com/` and pulling the script via `<script type='text/javascript' src='http://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min....

The big advantage over MacVim is that Vimroom works from the terminal, anywhere. I can use the plugin no matter which machine I'm logged into, which is pretty valuable to me.

I fixed the only issue that was on the project before today (errors when mapping keys that were already mapped), and pushed a v0.7. I hope that fixes the issue you experienced.

And now it's there: http://www.vim.org/scripts/script.php?script_id=3766

I'll take a look at getting it up to vim.org. Thanks for your interest!

It is implemented using splits, so you're right: if you're already using split windows then your results will be a bit off. :)

Regarding your settings, would you mind filing a bug report with some detail? I'm happy to try to fix things if there's a bug: https://github.com/mikewest/vimroom/issues

Ok. Would you mind dropping me an email (mkwst@chromium.org) with details? I'm happy to file the ticket for you.

That will be possible with the WebRequest API, yes: http://code.google.com/chrome/extensions/trunk/experimental.... For example, you'd be able to intercept and block network requests from a particular tab that didn't hit the same domain.

The API in experimental now, so download a dev release of Chrome/Chromium, enable experimental APIs via `about:flags`, and start filing bug reports. :)

Can you file a bug at http://new.crbug.com/ please? That doesn't sound like the behavior I'd expect.

Given that I'm responding to "I'm pretty sure Chrome send URLs to Google at least for indexing purposes." let's first agree that there's been no evidence provided that I can respond to. :)

I mean both Chrome and Chromium. The source is there, we develop in the open, and I'm not sure what additional evidence I can provide to you to prove a negative. Wireshark?

1. I wrote Keep My Opt-Outs. It has exactly the practical effect you're looking for with regard to DoubleClick and about 60 other ad networks _right now_. Installing it opts you out of interest based tracking in exactly the way that clicking the DNT box in Mozilla doesn't (yet): https://chrome.google.com/webstore/detail/hhnjdplhmcnkiecamp...

2. Google's participating openly in http://www.w3.org/2011/tracking-protection/ to work out what DNT means in a detailed sense, so that when users send a header, either via a checkbox or via an extension, there's agreement about what the practical impact is. I'm not sure it's reasonable to expect much more than that right now.

In `about:flags` there's an option to change third-party cookie blocking behavior to prevent reading third-party cookies as well.

Fingerprinting is a problem, and it's difficult to address. There's been some discussion around mechanisms for disabling features to make the browser signature less unique, but it's a very tough problem.

Take a look at https://trac.webkit.org/wiki/Fingerprinting for some discussion around what would be required. It's very, very nontrivial.

Thanks. It's now sitting in the Sync team's queue.

Chrome does not collect user information, unless you explicitly opt-in to sharing aggregated usage information and crash reports with Google. If you do opt-in to these metrics (and you have to opt-in, it's disabled by default), you can opt-out at any time via chrome://settings/advanced#metricsReportingEnabled

The data collected is available for you to peruse at chrome://histograms/

All the data that Google collects is subject to the privacy policies at http://www.google.com/intl/en/privacy/, and Google of course complies with SafeHarbor regulations (http://en.wikipedia.org/wiki/International_Safe_Harbor_Priva...)

Chrome does not arbitrarily send URLs to Google. We go out of our way to avoid doing that, actually.

Look at the implementation of SafeBrowsing, for instance, which does some clever work with hashes to ensure that Google never knows exactly what URL you visited that triggered the warning. It would have been _much_ simpler to just send the URLs, I assure you.

The main dev on the WebRequest API sits right behind me, and is making steady progress. It's the first synchronous extension API that interacts with the network stack, and it's a nontrivial effort to get it running. I can assure you, however, that making life hard for privacy extensions is the exact opposite of what we're being paid to do.

Look at the progress on privacy-related APIs over the last year: WebRequest is coming along nicely, WebNavigation and ContentSettings are feature complete and in the final stages of polish, and Proxy went out to stable in Chrome 13. Privacy and Clear just landed in experimental, and we're iterating on them rapidly.

(Details on the state of each are available at http://code.google.com/chrome/extensions/trunk/experimental....)

Labeling this article a list of "Nginx" security best practices is probably a bit misleading. Of the 20 tips listed, only half really deal specifically with Nginx (and half of those feel like filler: hotlinking, for instance, is decidedly not a security issue). The remainder are more general-purpose *nix-lockdown mechanisms. That's not to say that they're not worth reading, as there are some interesting nuggets in the list, but it's not what I was expecting from the title.

Moreover, if you don't feel like you understand what the other person is asking, don't be afraid of asking a question in return. Ensure that you're clear on what's being asked of you before giving either a rambling answer that covers all the basis, or a focused response to a question that wasn't asked.