Google to offer encrypted search next week - <AUTHOR> http://news.cnet.com/8301-30684_3-20005055-265.html

<comment><USER2> It's cool that Google is already starting to copy features from Duck Duck Go ;-) Next stop: promising not to keep a log of our searches, or assuming I want to be "signed in" on Search, just because I am on Reader..?

<comment><USER3> In fairness, implementing it on Google's scale is not really the same "feature", and since Duck Duck Go isn't a self-contained search engine, you can still question how end-to-end secure its final implementation is.

<comment><USER4> Why would it be any different on Google's scale? I mean, presumably the solution is the same install-ssl-plugin-and-point-it-to-a-cert fare that you would go through for any web server. Am I missing something here?

<comment><USER3> I think you're missing how expensive it is to make SSL work on a large scale. That being the reason it isn't the default everywhere.

<comment><USER5> Does the cost of SSL grow super linearly when you scale up?

<comment><USER6> Super linearly is a new term to me, but it doesn't grow linearly. However, it does grow, and Google is huge. The cost, in terms of labor, focus bandwidth, and money, is large at their scale.

<comment><USER7> The cost of TLS is linear in every way I can think of. The TLS handshake is basically constant overhead--in space and time--and O(n)--in space and time-- transform of the actual data.

<comment><USER3> The constant factors are high relative to simply serving HTML, especially on a site that tracks non-encrypted performance down to the millisecond.

<comment><USER5> Sure, but talking about it being expensive 'on a large scale' is a bit odd - since revenue/profits also grow with scale. It seems to imply a greater than linear growth in costs.

<comment><USER8> Google has a completely different back-end architecture than a dinky website, and the costs come from the sophistication and complexity of the systems required at that scale.

Google has multiple data centers, dedicated caching and web clusters, complex internal network routing and load-balancing, etc. Then there's stuff like javascript and image hosting optimizations that you've got to make sure work without triggering SSL warnings across thousands of servers. Enabling SSL support for something like Googe search could potentially touch tens of thousands of systems. In short, maybe it's as simple as flipping a bit to enable SSL on the web farm, but I doubt it. There's probably a massive amount of internal engineering and organization behind the change, and _that_ cost is what you're neglecting.

To give you perspective, it's trivial to enable SSL on a single-box website; it can be done in an afternoon. When we turned it on at Justin.tv, it took a few days (let's call it a week) of initial work, and ongoing maintenance costs to make sure that SSL sessions weren't breaking as we made improvements across the site. The costs go up as you get bigger and more complicated.

<comment><USER9> If it takes 4 hour to get SSL working for a site with 5,000 users then linear growth to a site with 250,000,000 users is 50,000 hours. IMO, google can get SSL working in less than 50,000 hours.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> How far are we from just encrypting everything on the web because it has a negligible cost? Is this purely CPU-limited or is there another reason (does it take much more bandwidth? screw with caching?)? Is Moore's Law taking care of this quickly, or is it still far off?

<comment><USER11> "Screw with caching" is probably the biggest issue. In order to negotiate the SSL connection, any proxy (on either end) needs to have your certificate. There's also the issue that some browsers (Firefox, I'm looking at you) do their best to scare users about self-signed certificates, which means that you need to pay for a cert.

It also breaks the shared-hosting model: your entire HTTP stream is encrypted, which means that key negotiation occurs before the server has your HOST header. This, in turn, means that the TCP/IP data (IPs and ports) are the only pieces of information that the server can use to determine which certificate to use. In practice, this means that a server can only host multiple distinct sites if it has multiple distinct IPs.

<comment><USER12>
      There's also the issue that some browsers (Firefox, I'm looking at you) do their best to scare users about self-signed certificates, which means that you need to pay for a cert.

Firefox is absolutely in the right, here. Self-signed certificates are worthless; if you'd like a free certificate, use StartCom or CACert.

      It also breaks the shared-hosting model: your entire HTTP stream is encrypted, which means that key negotiation occurs before the server has your HOST header.

This is only true for older servers; modern TLS implementations support name- based certificate negotiation.

<comment><USER11> They're worthless except insofar as they let you get the encryption benefit out of SSL without paying the cost necessary to get the authentication benefit.

<comment><USER12> What's the point of encryption if you don't know what server you're connected to? Somebody could be intercepting your traffic, and you wouldn't realize it.

<comment><USER11> The point is to stop one particular class of attacker: the one that's passively sniffing and archiving network traffic while trying to remain invisible (and thus isn't actually altering the traffic profile). This is a benefit (over in-the-clear HTTP), but Firefox and others effectively tell users that it's more dangerous than regular HTTP.

</comment></comment></comment></comment></comment></comment><comment><USER13> Now we feel safe knowing only Google's watching and analyzing everything we do!

</comment><comment><USER14> "Google encrypted all Gmail accounts in response to the hacking incidents that prompted its decision to move its Chinese-language search operation from Beijing to Hong Kong."

Its a shame they couldn't do it because customers have been asking for it.

<comment><USER15> I believe gmail always had HTTPS as an option - in 2008 they added an option to selectively make it the default if you want - now they've reversed that and made it the default from the start. There is strong reasoning, backed up by user experience testing that the small delays introduced by SSL on web pages add up to big drops in retention... and business is business. HTTPS connection setup is significantly slower than a regular connection - you may not think that sub-second delays matter but they absolutely do in the competitive web- app world.

<comment><USER14> Do you have evidence that HTTPS results in user retention problems for gmail? I have heard that it may for search. These are two very different use cases. I can recall users and articles in years past asking for https to be default for gmail. Yes, us geeks knew its been an option for a while. My original post was simply pointing that the decision should be made based on what users want...not as an excuse so the media or Google can publish inflammatory digs in their issues with China.

</comment></comment></comment><comment><USER16> So if SSL has such little overhead today regardless of scale (and can be hardware accelerated) what the heck is PayPal's excuse for being so horribly slow? Gmail can run rings around it with far more data.

</comment><comment><USER17> I imagine they would offer it as an option in your Google account settings, similar to GMail before it was made default. That will certainly make censorship MUCH more difficult, and if they include Google cache in this (which was used for a time to get around the Great FireWall of China) we would have something of a winning combination.

On the other hand, the Chinese government might just ban Google search outright for such a move, although they haven't done this for GMail yet.

<comment><USER18> More difficult but still far from impossible... All China needs is a Chinese CA to issue them a certificate for Google and then they can do a nice MITM without the user seeing even a single warning.

<comment><USER19> There have been totally unproved speculations that they've been doing that. But if they did it on a scale like that their CA would be revoked from all default browser installations.

They could still force the issue and mandate that their CA be patched back in on all computers sold in mainland China.

Either case seems very unlikely, just outright blocking things they don't like seems to be their current approach. I don't see why they'd change that for Google.

</comment></comment></comment><comment><USER14> "Now, if you are on an airport Wi-Fi or other public network everything you search for is in the clear."

ok, and most search results you click on will take you somewhere not secure. There may be little value add here.

From re-reading this article, it actually contains no value expect the headline itself. cnet should start just doing tweets instead of bothering to try to fill a page.

<comment><USER20> Seriously? You don't see a use for secured searches?

How do you think the Chinese government will like this? Or any government who attempts to censor searches? How will they know what's being searched for? Also, a lot of value can be gleaned from just the results, and not _all_ lead to insecure sites.

<comment><USER14> Me personally? I want https for gmail...ok, I've had it since around 2008. For web search? If I'm going to search on something top secret I wouldn't want Google to have identifiable info on me either so I wouldn't use Google or I would try to obfuscate my identity from Google through other means. So, for me, https on search isn't a common use case.

As to China: I think China will block https search on Google. I think any government that censors search will block https search on Google. Playing the China card on this new feature isn't interesting. Google and/or the press should not try to score points through inflammatory China comments with this new feature rollout. Https search should be added simply because its a feature users want; and I'm sure some do.

</comment></comment></comment><comment><USER21> How will this affect web traffic analytics? Will encrypted searches still be abled to be logged as referrers? For SEO/PPC/Analytics/Etc purposes

<comment><USER15> The only difference is in the transport - HTTPS instead of HTTP. Everything else about the protocol is the same - browsers can still send referrer information in their requests, cookies can still be set, and so on - it's just that a passive observer sniffing the network will not be able to see anything other than an encrypted connection to google.

This really is google just playing their cards at the right time and cashing in on the current privacy bandwagon in the media, casting themselves in a positive light. It doesn't alleviate any real privacy issues, whatever they are, with google.

There isn't a downside for us users - it's a good option for google to provide - it will cost them money in infrastructure, and will slow down the user experience by a significant factor - (you might not thing a half second matters, but it does, and google knows this - so this is possibly a convenient time for them to introduce this feature while people are focused on WHY privacy is important)

<comment><USER22> Actually... the browser won't send a referer to a HTTP site if coming from HTTPS. From the RFC: [http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15...](http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3)

"Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol."

I wonder if Google will implement POST forms instead of GET to prevent caching of request-uri data by the browser as well as proper Cache- Control/Pragma/Expires headers to prevent caching of search results.

</comment></comment></comment><comment><USER10> What we need is the equivalent of "privacy mode" that browsers have. Hit a switch somewhere or go to some URL, and suddenly your searching using an encrypted connection and no logs at all are being kept.

<comment><USER23> This is the obvious point, and I have to wonder if it would defeat the money- making potential of search data once it becomes common practice.

Maybe it's just another feature that makes google the best search provider. If they don't do it, someone else will.

<comment><USER10> Most people never change the default setting on anything, so I doubt it would have a huge impact on them. But it would certainly make power-users happy.</comment></comment></comment>


Glendix: Bringing the Beauty of Plan9 to Linux - <AUTHOR> http://www.glendix.org <comment><USER2> (Glendix author here)

The project is mostly dead since I haven't had the time to work on this in years. If anyone's interested in picking it up and porting it to the latest kernel version, I'd be happy to help in any way I can!

The interesting bits are mostly in the a.out (plan9's executable format) loader that enable implementing the small set of plan9 system calls.

<comment><USER3> One of the most interesting aspects of Plan 9 is the lack of a root user. Did you ever have any thoughts on the possibility of implementing that in Linux?

<comment><USER2> The goal was to bring Plan 9's most useful tools to Linux, rather than modify Linux to become more Plan 9-ish. Glendix doesn't modify the core or essence of Linux in any meaningful way (it's more like Wine in that sense), so the question of removing the root user never came up.

Couple of sub-projects within Glendix that are pretty interesting though are the synthetic /net filesystem that serves a TCP API, and per-process namespaces. These are simply in addition to what Linux already provides, so they don't impact existing Linux applications in any way. Glendix runs just like any other Linux installation, you just have access to more Plan 9 stuff.

</comment></comment></comment><comment><USER4> For actively developed plan9 tools on unix see Russ Cox's (now of the Go project) work.

[http://swtch.com/plan9port/](http://swtch.com/plan9port/)

There is also the 9vx project which virtualises x86 using vx32 and then uses plan9 as an example - [http://swtch.com/9vx/](http://swtch.com/9vx/)

Plan9 also works in vm's such as qemu

<comment><USER5> I did this a few weeks ago on an OS X machine and it worked wonderfully. I installed it to give Sam a try, as I am learning Ed and wanted to compare them.

I had once hoped that Google would resurrect Plan 9, since they have so many former AT&T employees on staff. All it really needs it modern drivers, a wireless stack, and a browser (which they have with Chrome). Alas, it is not to be.

<comment><USER6> There is a version of plan 9 with better drivers and wifi: [https://code.google.com/p/plan9front/](https://code.google.com/p/plan9front/)

I've never used it but I can't imagine it has a browser. The two surviving browser cores (webkit/blink and gecko) are both utter nightmares of C++ and/or XUL, neither of which has any runtime support on plan 9.

<comment><USER4> Imagine moar, at least three

[http://plan9.stanleylieber.com/linuxemu/](http://plan9.stanleylieber.com/linuxemu/)

As well as Mothra and Abaco.

</comment></comment></comment></comment><comment><USER7> Was about to clone till I found out the last commit (README doesn't count) was on Nov 27, 2009.

<comment><USER8> Last post in Google group is in 2012 asking if it is dead.

</comment></comment><comment><USER9> How does this compare to the plan 9 from user space project?

<comment><USER10> Plan 9 from user space is a port of userspace programs to other hosts. This project is an attempt to make the host supportive of the userspace programs, rather than the other way around. Also, plan 9 from user space is not abandoned.</comment></comment>


What else to use besides Dropbox? - <AUTHOR>

We've been using Dropbox for asset sharing with our team for a while now. However we've reached the 2gb limit and we were looking into how to solve this.
Like most people we thought we could upgrade a main account with 50GB and then share that account with others. However I dug in thinking that wouldn't work, and I was right. Anyone is limited based on their quota. Meaning if we upgraded one account to 50GB and shared a folder, it wouldn't use that accounts quota to disperse the quota, everyone would essentially be limited to 2GB out of that 50GB assuming they were on the free plan.
So, we looked into the team pricing and in our perspective it was ridiculous. We're not going to jump $800 onto the team plan.
What other alternatives are there?
p.s I still love Dropbox personally. For teams the pricing is off.
p.s.s What bothers me is charging for both # of users AND amount of storage is uncool. Seems like $99/year for 50GB unlimited users is ideal or $x/month per user. But both? No way. <comment><USER2> 1) I'd tell Dropbox you think the team pricing is too high and/or propose an alternative SOHO price point. They seem to listen.

2) I use Dropbox for personal use only and subscribe to the 50GB account. That being said I have also used Unison very successfully. Going that route you are going to pay in terms of time and, if you don't have someone to care and feed Unison, possible hiccups.

</comment><comment><USER3> ADrive is pretty good. Individuals get 50G free. No SSL for free accounts though (except for the login.)

<https://www.adrive.com/login>

</comment><comment><USER4> I like jundledisk alot.. Much better linux support <https://www.jungledisk.com/>

</comment><comment><USER5> letscrate.com <\- Currently on appsumo.com for 7$- lifetime membership. Which is nuts. Unlimited individual file limit, 10gb cap limit. It looks like an easy fix for you in this situation.

www.appsumo.com

Note*- I'm in no way affiliated with letscrate, or appsumo- just sending things your way!

</comment><comment><AUTHOR> Looking at <http://www.wuala.com/en/> \- looks great so far.</comment>


Solarized - Color scheme for vim, mutt, terminal emulators - <AUTHOR> http://ethanschoonover.com/solarized <comment><USER2> Its really rare to see that much thought going into the aesthetics of stereotypically "geeky" applications like vim and terminals, even the website looks entirely different from pretty much every website I have seen around these tools

its a refreshing change, awesome work

<comment><USER3> Thanks very much. Looking back at my early hg repos on this project I refined it for about six months.

As an aside. I have a nominal post in my head contrasting the development and refinement of a colorscheme like this vs the infamous 41 shades of blue. There is room for refinement and testing in design, but I think it has to be coupled with a clear design goals and opinions.

<comment><USER4> Thank you for the work!

It would be very interesting to learn about the methods you used to create this.

Are you planning to create a palette with more shades? Some time ago I needed lighter Tango tones and created this extended palette: <http://emilis.info/other/extended_tango/>

</comment></comment></comment><comment><AUTHOR> Please share your favorite color scheme(s) !

My favorite for gvim/MacVim is molokai: <http://winterdom.com/2008/08/molokaiforvim> , seconded by vividchalk when i'm on the terminal: <https://github.com/tpope/vim-vividchalk>

Haven't found any good color scheme for iterm2 yet. Currently i'm using thayer: <http://ecto-plazm.deviantart.com/gallery/>

<comment><USER5> I wrote my own scheme:

[https://github.com/strange/dotfiles/blob/master/.vim/colors/...](https://github.com/strange/dotfiles/blob/master/.vim/colors/strange.vim)

Python: <http://files.pipsq.com/strange/python.png> Erlang: <http://files.pipsq.com/strange/erlang.png>

<comment><USER6> I just tried this with Perl, and it looks great (the fold-column's a bit bright, but I don't have that on by default). Have you thought about uploading it to vim.org?

<comment><USER5> Thank you. Will do.

<comment><USER5> Done.

<http://www.vim.org/scripts/script.php?script_id=3534> <https://github.com/strange/strange.vim>

</comment></comment></comment></comment></comment><comment><USER7> So, my mind is blown that you put so much effort into designing a color scheme, and thanks, but maybe put the img/ directory in your git repo somewhere else, so that a git pull of a color scheme doesn't take 50(!) megs.

<comment><USER3> I was afraid that would be a pain for people, sorry! You're right, I need to do this. There is a reason, which is that the exact same repo does double duty as the webpage (via Hakyll). It's super convenient because I have hakyll process the README out into an index.html (pulling webserver local imgs, so there is some sed magic).

I may try to break out the images as another subtree or make a website subtree. It was lower on my list of priorities, but clearly a pain to others cloning/forking. I'll try to sort it before beta2.

</comment></comment><comment><USER8> I haven't looked into how one can export gnome-terminal color palettes yet, but if anyone else is interested, I think these are the correct settings in gconf:

        /apps/gnome-terminal/palette: #070736364242:#D3D336368282:#B5B589890000:#CBCB4B4B1616:#2A2AA1A19898:#6C6C7171C4C4:#858599990000:#EEEEE8E8D5D5:#00002B2B3636:#D3D301010202:#58586E6E7575:#65657B7B8383:#838394949696:#26268B8BD2D2:#9393A1A1A1A1:#FDFDF6F6E3E3
        /apps/gnome-terminal/background_color: #00002B2B3636
        /apps/gnome-terminal/foreground_color: #65657B7B8383

_Edit_ : Ok, I pulled down the source for gnome-terminal since I couldn't find a way to export/import color schemes. The color palettes are all hard-coded, so that is unfortunate :(.

<comment><USER8> Ok, I think I had this wrong and it looks like I've hit a limit on editing my post. Here's the right values (I hope):

(All values are in /apps/gnome-terminal/profiles/Default):

        palette: #070736364242:#D3D301010202:#858599990000:#B5B589890000:#26268B8BD2D2:#D3D336368282:#2A2AA1A19898:#EEEEE8E8D5D5:#00002B2B3636:#CBCB4B4B1616:#58586E6E7575:#65657B7B8383:#838394949696:#6C6C7171C4C4:#9393A1A1A1A1:#FDFDF6F6E3E3
        background_color: #00002B2B3636
        foreground_color: #65657B7B8383

<comment><USER9> And here's the Light version:

palette: #070736364242:#D3D301010202:#858599990000:#B5B589890000:#26268 B8BD2D2:#D3D336368282:#2A2AA1A19898:#EEEEE8E8D5D5:#00002B2B363 6:#CBCB4B4B1616:#58586E6E7575:#65657B7B8383:#838394949696:#6C6 C7171C4C4:#9393A1A1A1A1:#FDFDF6F6E3E3

background_color: #FDFDF6F6E3E3

foreground_color: #00002B2B3636

(Same palette, just different FG and BG colours)

</comment></comment></comment><comment><USER10> Someone started porting it to Emacs:

[https://github.com/sellout/solarized/tree/master/emacs- color...](https://github.com/sellout/solarized/tree/master/emacs-color-theme- solarized)

<comment><USER2> the emacs port seems a bit too low contrast

<http://dropup.net/lz64u0ctpcge.png.html>

<comment><USER11> After investigating this (and raising the aforementioned Emacs bug), I've concluded that sRGB hex colors - as used by Ethan - are simply not the right hex colors to enter in Emacs in order to get the desired results. Instead, Emacs apparently works with Generic RGB values, and after some laborious conversion calculations in Apple's "ColorSync Utility", I got the right results:

<https://github.com/purcell/color-theme-sanityinc-solarized>

The color fix will probably get into sellout's repo, so interested parties should prefer that one over mine.

<comment><USER12> That's awesome! Thank you!

</comment></comment></comment></comment><comment><USER13> I don't like this scheme and I don't buy the pseudo-science blurb. It's based on shades of blue. Our eyes are the least sensitive to blue. And what's up with the red and pink, is this some cruel joke?

I'll stick with Zenburn[1].

[1] <http://slinky.imukuppi.org/zenburn/>

<comment><USER14> I was a dedicated IR_Black user (in both VIM and Visual Studio), and didn't think highly of this at first. But after about an hour, it's grown on me. If I can scrape together some time, I'll throw together a VS2010 color scheme/theme.

<comment><USER15> Please please do that! I for one would love to have this scheme in VS2010!

<comment><USER14> Not mine, but....

<http://studiostyl.es/schemes/solarized-dark>

<comment><USER15> Awww, awesome!

</comment></comment></comment></comment></comment><comment><USER16> I don't know about the rest of you, but my eyes literally started to hurt when I read the text on that page, presumably because of the color of the text v. background. Doesn't bode well for using it in vim...

Maybe it looks better on a different monitor? (I have a Samsung LCD.)

<comment><USER17> You may need to enable ClearType.

If on Windows XP. Display Properties > Appearance > Effects

<comment><USER16> I'm on Mac OSX; is there an equivalent?

<comment><USER18> For Snow Leopard: Open System Preferences, go to Appearance, and uncheck "Use LCD font smoothing when available"

</comment></comment></comment></comment><comment><USER19> I found the theme rather comfortable for using in the terminal; however I set TERM=xterm-256color so that vim would also pick up the light colour scheme—there seemed to be some issues with the background colour on gnome- terminal/Ubuntu.

Thanks!

<comment><USER3> When I was brave enough to test outside of urxvt and iterm2/terminal.app, it seemed that terminal emulators are all over the place in terms of background color support in vim terminal mode.

You might have tried this already (and it might not actually be related to your issue), but there is a variable you stick in your vimrc (let g:solarized_termtrans=1) to force it to take the background of your terminal emulator (useful only if you are running with the solarized colors in terminal mode).

I should come up with a some recommendations on setting TERM to ensure proper colorscheme support, but that way lies madness (for me at least).

</comment></comment><comment><USER20> I don't mean to sound particularly thick here, but is there a way to apply these colours to my OSX Terminal too? I've installed the bundle for Terminal.app, and they look lovely in emacs, but can I use them in my general bash environment, too?

<comment><USER21> Yes, the directions are on GitHub:

[https://github.com/altercation/solarized/tree/master/osx- ter...](https://github.com/altercation/solarized/tree/master/osx-terminal.app- colors-solarized)

Once you've activated that theme in Terminal.app's preferences, all your colors in the shell will use the colors defined in the colorscheme. So red will be the red in the colorscheme, blue -> blue, etc.

<comment><USER20> Thanks - seems to be working a treat here. Cheers!

</comment></comment></comment><comment><USER22> Fantastic work. If I happen upon some spare time I'll try and port it for TextMate users.

<comment><USER23> Please do, I'd really appreciate it.

<comment><USER22> I've got a start going in <https://github.com/markstory/solarized>

<comment><USER24> Great work, Mark! I see you're progressing well with the TextMate themes.

<comment><USER25> Hey,

I've forked Mark's version and added a bunch of specific styles for the Light version, specifically a lot of rules for PHP and CSS.

It's not 100% yet, but it's already the best TextMate theme I've ever used.

<https://github.com/deplorableword/solarized>

</comment></comment></comment></comment></comment><comment><USER26> Anyone get a chance to test out how this looks with vimdiff? That's one area that usually ends up looking fugly b/c the theme creator neglected to look at it. Other areas that are typically neglected (though not in this case): code folding, split buffer dividers.

<comment><USER27> Here's a vimdiff sample from the rvm repo...

<http://i.imgur.com/IMdt5.png>

</comment></comment><comment><USER28> Make it for TextMate ;)

</comment><comment><USER29> It would be nice to have a script that would start with this as a base, but let you tune the contrast. I like the theme, but would like more contrast than this (I use small fonts, and I really feel like more contrast is necessary when doing so).

<comment><USER3> fwiw, there is a high contrast option in the vim colorscheme (let g:solarized_contrast="high").

I'm working on cleaning up some of the build scripts that generated specific files (the mutt directory has an ugly shell script as an example, there are better ways of course).

</comment></comment><comment><USER30> I was interested in seeing what the colour palettes might look like in the real world. Here's are the some multicolr searches for the 5-colour palettes:

[http://labs.ideeinc.com/multicolr/#colors=073642,586e75,8394...](http://labs.ideeinc.com/multicolr/#colors=073642,586e75,839496,93a1a1,d30102); [http://labs.ideeinc.com/multicolr/#colors=002b36,073642,586e...](http://labs.ideeinc.com/multicolr/#colors=002b36,073642,586e75,657b83,b58900); [http://labs.ideeinc.com/multicolr/#colors=657b83,93a1a1,eee8...](http://labs.ideeinc.com/multicolr/#colors=657b83,93a1a1,eee8d5,fdf6e3,268bd2); [http://labs.ideeinc.com/multicolr/#colors=657b83,839496,93a1...](http://labs.ideeinc.com/multicolr/#colors=657b83,839496,93a1a1,eee8d5,cb4b16); [http://labs.ideeinc.com/multicolr/#colors=073642,93a1a1,eee8...](http://labs.ideeinc.com/multicolr/#colors=073642,93a1a1,eee8d5,d33682,6c71c4);

A search with just the base colours:

[http://labs.ideeinc.com/multicolr/#colors=002b36,073642,586e...](http://labs.ideeinc.com/multicolr/#colors=002b36,073642,586e75,657b83,839496,93a1a1,eee8d5,fdf6e3);

<comment><USER3> Man, I love those sets. Hadn't used that site before but it's awesome. Very nice to see the stark ocean and ink in water in the last set. Not too far off from the deep ocean feel I was targeting during design.

Thanks. Great links.

</comment></comment><comment><USER31> My favorite vim color scheme is two2tango. Here's a preview <http://cl.ly/2Y0v251z0A29203K3d3D>

</comment><comment><USER32> I made a Solarized dark theme for XCode 4. I used the Vim definition as a guide, though varied it a little while staying within the color palette.

[https://github.com/varikin/solarized/tree/master/xcode4-colo...](https://github.com/varikin/solarized/tree/master/xcode4-colors- solarized)

</comment><comment><USER33> I would really love to have emacs, gnome-terminal and gedit themes made out of this color scheme.

</comment><comment><USER34> any volunteer to submit it for emacs24 @ <http://elpa.gnu.org/themes/> ?

<comment><USER34> Did it @ [https://github.com/cycojesus/emacs/raw/master/solarized- them...](https://github.com/cycojesus/emacs/raw/master/solarized-theme.el) [https://github.com/cycojesus/emacs/raw/master/solarized- ligh...](https://github.com/cycojesus/emacs/raw/master/solarized-light- theme.el)

</comment></comment><comment><USER35> Is anybody willing to explain how to switch between light and dark? I can't seem to understand the scss snippet that he gives. Apparently, you only have to switch 4 colors, It would be nice to know what those colors were.

<comment><USER3> I'll be expanding the webpage to detail that, but essentially:

base03 = background base02 = background highlight base01 = background data (comments, etc.) base0 = normal text

The scheme was designed to allow for: base1 = optional bold/emphasis

Just swap the zeros (initially I was using minus/plus, e.g. base-1 and base+1 but this isn't usable across all apps) to swap dark and light modes. There is a good example of this in the vim script as well as the sass snippet (and the mutt compile script if you are a glutton for ugly bash scripts).

base3 = light background base2 = dark background etc.

You shouldn't need to do any of this manually, however. The vim script has a light/dark mode built in and where there isn't a way to toggle modes I am distributing light and dark versions (the terminal color schemes).

<comment><USER35> Thanks! I coulden't find a light version of the Xresources script though, that's why I was wondering about switching.

</comment></comment></comment><comment><USER36> Very nice! It is indeed amazing how much thought and effort was put into this, and it is appreciated. At some point, I'll have to convert for Visual Studio use if someone doesn't beat me to it.

</comment><comment><USER37> Am I the only coder who doesn't like working with light text on a dark background? I have 20/20 vision, and I find it really uncomfortable to use these.

<comment><USER38> My theory is that it depends on when/where you normally work. If you have a tendency to code at night or in dark rooms, dark on light is very bright. At least, that's why I go light on dark.

<comment><USER37> That makes sense. I work from home in a room that's all windows.

</comment></comment></comment><comment><USER39> I tried to install the iTerm2 colorscheme and also the vim colorscheme, but they look nowhere near the screenshots. Anyone having issues like this?

<comment><USER40> My vim renders everything way darker (or perhaps is just that there is not as much contrast) than in the screenshots. I double checked that I am using xterm-256color (and also checked against rxvt-unicode-256color). It's too bad, I really like how it looks in your screenshots, but in my computer not so much...

</comment></comment><comment><USER41> I love the effort put into this, but somehow the background is way too light for my taste, in vim the colorscheme is kind of bland.

</comment><comment><USER17> I cannot seem to get the colors to render properly on Snow Leopard, using Terminal.app, and vim. Anyone else have any trouble but get it to work?

I installed the thing as instructed. I installed SIMBL and the SIMBL plugin, installed Solarized Dark Terminal.app theme, installed vim using pathogen, and set .vimrc with the additional g:solorized_termcolors=16 option.

<comment><USER42> Go to Applications > Utilities, right-click on Terminal.app and set 32-bit mode. Hope that helps!

</comment></comment><comment><USER43> The 64-bit TerminalColours SIMBL plugin that's linked to in the README doesn't play nicely with binaryage's 64-bit Visor plugin, for some reason. However, Evan Phoenix's fork[1] works perfectly for me.

[1] <https://github.com/evanphx/terminalcolours/downloads>

</comment><comment><USER44> A bit too much color according to my taste - I like a more subdued color scheme, as seen in [http://www.michielovertoom.com/pictures/kwrite- textanalyse.p...](http://www.michielovertoom.com/pictures/kwrite- textanalyse.png) (All black on lightgray, strings dark gray, and prussian blue comments).

<comment><USER45> A norwegian file! Tekstanalyse. Why are the comments in Dutch?

<comment><USER44> It was a prototype I made for a prospective client. I sometimes use Dutch comments (and variable names) in such a case. Btw, 'Tekstanalyse' is also a Dutch word.

</comment></comment></comment><comment><USER46> It looks nice, is there a tmTheme file?

Currently I use TwilightMod, which is as the name suggests, a modification of Twilight.

This is what it looks like: <http://i.imgur.com/u802t.png>

Get it here <https://gist.github.com/809720>

</comment><comment><USER47> Does this work in the console (vim)? I currently have desert256 working nicely in iTerm (xterm-256color). I'm away from my computer or I'd test it myself. Thanks! Never seen anyone put this much effort into a color scheme! I actually feel like I personally owe it to you to give this a shot.

<comment><USER48> Yes, but the 256 mode is actually an approximation of the real color theme. For exact colors you have to set up the 16 ansi colors of your terminal to the right colors and set a var in vimrc. See the docs for details.

</comment></comment><comment><USER49> Any chance for gedit and gnome terminal versions? Fantastic scheme, would donate my kidney for a gedit port

<comment><USER50> [https://github.com/mukashi/solarized/tree/master/gedit- color...](https://github.com/mukashi/solarized/tree/master/gedit-colors- solarized)

</comment></comment><comment><USER51> I made a simple Pygments version[1] for use on my website. I immediately thought it was perfect for my site, but I'm sticking to molokai for Vim. Thanks!

[1]: <https://bitbucket.org/john2x/solarized-pygment>

</comment><comment><USER52> When I use this in my .Xdefaults, my terminal emulator (urxvt) goes hot pink ( [http://ompldr.org/vODRtMg/2011-04-05-165103_1024x600_scrot.p...](http://ompldr.org/vODRtMg/2011-04-05-165103_1024x600_scrot.png) ), any ideas?

<comment><USER53> mine goes all blue, it's awful and I haven't found anyone with this problem. Looks great in vim but it's unusable for urxvt/xterm (and also emacs).

edit: <http://imgur.com/OMjdR>

<comment><USER52> Might have a go later at making one that works with urxvt, hopefully that should get it working with xterm.

With that said, if it's not working with urxvt/xterm, what _is_ the Xdefaults working with?

<comment><USER53> nothing, got a response on twitter and he said he borked it but will fix next release

</comment></comment></comment></comment><comment><USER53> the bold colors are bad, this makes most of my terminal apps annoying as hell (ncmpcpp, byobu, aptitude, htop)

for one thing, at least one of the bold text colors is the same as the background, this makes this text not even show up when it's present

it would be nice if not for this

</comment><comment><USER54> I really don't get the terminal color assignments. Why are the brfoo colors set to grey?

</comment><comment><USER21> Anybody know of a TextMate port?

<comment><USER25> Yep, come and help finish it :)

<https://github.com/deplorableword/solarized>

</comment></comment><comment><USER55> Any chance of publishing the Xresources version (or at least hex codes in that file) for the "white" version?

<comment><USER56> It's here - [https://github.com/altercation/solarized/blob/master/xresour...](https://github.com/altercation/solarized/blob/master/xresources- colors-solarized/Xresources)

<comment><USER55> That's the dark version.

</comment></comment></comment><comment><USER57> It's a remarkable work. Although, on the dark background, the red and the magenta colors are too saturated.

</comment><comment><USER58> Wow. Beautiful colors. Beautiful site. Very impressed by how much effort the author has put into this.

</comment><comment><USER59> Any chance someone can pull an Eclipse Color Theme version? (pretty please :)

<comment><USER60> check it [http://www.eclipsecolorthemes.org/?list=all&q=solar](http://www.eclipsecolorthemes.org/?list=all&q=solar)

<comment><USER59> Could be that I'm missing something, but the dark versions don't seem to be the same as in solarized: [http://ethanschoonover.com/img/solarized/solarized- screen-ja...](http://ethanschoonover.com/img/solarized/solarized-screen-java- dark.png)

</comment></comment></comment><comment><USER61> Does the font on the website look extremely blurry for anyone else...?

</comment><comment><USER62> Am I the only person on HN that just happily uses the default color schemes that comes with editors?

<comment><USER63> Just about, yes.

</comment></comment><comment><USER64> Request for intellij impl.</comment>


The VR Winter - <AUTHOR> https://www.ben-evans.com/benedictevans/2020/5/8/the-vr-winter <comment><USER2> > Smartphones are broad and universal, whereas consoles are deep and narrow, > and deep and narrow is a smaller market. VR is even deeper and even > narrower, and so if we can't work out a form of content that isn't also deep > and narrow.

People are now playing those console games on their iPhone. The average paying iOS user spends $9.60 per month on in app purchases. The game market is huge, bigger than movies & tv combined. Maybe in the current form VR & AR is niche but that says nothing about how valuable the market can become.

The lesson is you shouldn't predict potential market size of a technology from the first particular hardware implementation.

</comment><comment><USER3> > I think there are maybe four propositions to think about.

> Is it true that we are essentially almost there, and a bit more iteration of > the hardware and the developer ecosystem will get us to a tipping point?

> Are we where smartphones were before the iPhone?

> Is there a fundamental contradiction between a universally accessible > experience and a device that you put on your head that shuts out the world > around you?

> Or, by extension, is this the point - that 'real' VR needs some completely > different device and that's what would take it to universality? VR as HMD is > narrow but VR as, say, neural lace is not?

In addition to his four propositions to think about I would add one more. There's technology to represent _other humans_ in VR (eye tracking, face tracking, body tracking) that basically doesn't exist yet as part of consumer VR systems. But with those technologies already present outside of consumer VR (and continued massive R&D spending by Oculus etc) they seem realistically achievable in the medium term. Will this make a significant difference in the VR adoption rate or enable new applications?

</comment><comment><USER4> I dont understand how all these Smart people got sold into VR, AR, and AV ( Autonomous Vehicles).

We have long entered into the age of TDP Computing as a proxy of relative performance. We could not even make the application Work on a 1000+ Watt PCs. Why is it we think we could make it works in Sub 100W anytime soon. We need Ultra Hi-Res because of how close the pixel are to our eyes, we also need Ultra-High frame rate so we dont have motion sickness. And then we expect Photo Realistic graphics along with Ultra Low Latency which No one have solved yet as we are constantly trading latency for throughput. ( Good old Street Fighter II felt more responsive than today's fighting game )

We can estimate with certain degree of accuracy how long it would take to reach 80% of the project, but experience taught me the last 20% would somehow take the same amount of time as the first 80%. To put this into AR, VR, AV perspective, we are at least another 6-8 years away from seeing its usefulness.

<comment><USER5> I got "sold on VR" because I tried it? Like, I have been super busy recently, and so haven't barely had time to stand up much less use VR, but for most of a year I used VR every single day. This article isn't even arguing that it doesn't work or anything: it is arguing that it might not be mainstream, which is entirely different... this is like asking "I don't understand how all these Smart people got sold into computers" back when computers were mainframes with a very limited market, as if until something is ready for a mainstream market no one should bother owning one or using it for anything :/.

<comment><USER6> I'm pretty sure you can read GP's statement to mean "sold on the mainstream applicability of VR".

No one doubts that some segment of the market has purchased VR devices.

</comment></comment></comment><comment><USER7> I don't see VR taking off anytime soon, but I also think it's a bit tiresome to say that a product category isn't successful unless it nears the ubiquity of the smartphone. By that measure, plenty (most all?) profitable and useful products are failures.

</comment><comment><USER8> It always surprises me when people completely overlook the evolution TV and film will likely undergo to become stereo 180 (for directed attention experiences) or stereo 360 (for passive self-directed experiences) when HMDs become cheap enough that they become ubiquitous.

Sure you can watch video without color, sure you can watch film without sound, but why would you?

By the same sense, for most cases watching video/film/TV with 3D depth is going to be superior to watching without.

The argument that 3D TV never took off is less convincing when you consider that content creation for 3D TV was way more costly than it is for stereo 180/360 VR today, and that 3D TV died before the chicken and egg problem was ever solved. (Even if the HMD market contracts 90% it should still be profitable for small Chinese manufacturers to produce crap-tier HMD for porn).

Today a good stereo 180 VR experience can be filmed with an Insta360 Evo or a Vuze XR (my preferred option due to out of the box color grading) which can be had for about $400 USD.

ZCam K1 pro and K2 pro can create incredible content (as seen in top pornography) for $3-4k entry price.

But it's really hard to convince anyone who hasn't tried it, especially someone who hasn't seen something filed with one of the aforementioned cameras. Especially people who haven't tried VR or well-filmed VR but have tried 3D movies and assumes they are the same the same experience.

<comment><USER9> >By the same sense, for most cases watching video/film/TV with 3D depth is going to be superior to watching without.

Uh? Except that to get 3D you have to wear glasses, which is a huge drawback.

As for VR, I've tried it 3 times with demos: the first time I got so seasick that I had to stop and was feeling still quite bad 15 minutes after, the second time I nearly fell and the third time I bounced into a wall..

<comment><USER10> Sounds like your immersion level was increasing with every try

<comment><USER9> It wasn't the same demo: the first time, it was a roller coaster (a really dumb demo!!), the second time walking on a roof and falling (interesting that it created some fear of heights, but I didn't expect to nearly fall for real during the virtual fall due to the change of POV)

</comment></comment></comment></comment><comment><USER11> The Oculus Quest still has serious flaws in screen resolution, input latency, and controller ergonomics. It's literally painful for me to use it. I get eye strain, a headache, and sore thumbs.

VR is clearly useful but before it becomes mainstream it will have to have the hardware quality that we associate with Apple or at least BlackBerry (ie a high-quality input interface).

I hear the Valve Index is better but I haven't tested it yet.

<comment><USER12> Two notes, of equal importance:

1\. The Index is a _lot_ better. The higher resolution and refresh rate make a big difference. The Oculus Quest has a refresh rate of only 72hz, which we've known for years isn't enough for lots of people.

2\. Comfort is highly dependent on the software you play. A lot of VR enthusiasts have been pushing for _less_ comfortable modes of play over the past few years (because it allows games to do more), which is great if that's what they like, but I worry it's turning off more susceptible individuals.

Using a sufficiently powerful PC to play The Lab on an Index will not make anyone feel ill.

</comment></comment><comment><USER13> VR hardware is good enough to go mainstream, but as pointed out, what is missing is a mainstream utility: a killer app like the spreadsheet or word processor.

The 10x advantage that VR hardware provides over a 2D display isn't 3D space. It is social presence. VR's killer app exists within the domain of collaboration, communication, and organization.

</comment><comment><USER14> Games did its fair share of making the PC mainstream. Many got a PC to be able to play Doom.

Games today is mainstream. Everyone young plays games now, might not talk about it but everyone does.

So I def think games can be a driver to make VR mainstream. Social media meets games in the other end. All it takes is VR to be both more immersive and more comfortable than playing games on flat screen.

</comment><comment><USER15> > here was no killer app for the first PCs either, but they looked useful

I thought VisiCalc (and Lotus 123) were the killer apps for early PCs?

</comment><comment><USER16> Make a VR operating system for work.

Video games will never achieve critical mass for VR.

Although, the one video game that I thought could become the killer app for VR, is BeatSaber [1].

[1] [https://www.youtube.com/watch?v=ZJcqhvadbkI&t=59](https://www.youtube.com/watch?v=ZJcqhvadbkI&t=59)

<comment><USER17> There's already Windows 10 for both VR and AR, but Microsoft is playing long with this and taking it very slow. It runs most ARM apps flawlessly (on Hololens at least) and is quite focused on the enterprise to approach the industry from there.

</comment></comment><comment><USER18> It is time we stopped trying to make VR for the broadest appeal. There are people who simply cannot handle the experience either from a motion sickness point of view or otherwise.

What will save VR is games or experiences that focus on quality and immersion rather than trying to please everybody.

The Playstation VR is a good example. It is specifically not for children under 12 yet many of the games seem to be targeted at people with that maturity level.

</comment><comment><USER19> Who whatches Opera? But there are still opera houses and nobody complains about them...

Vr in its current state is mostly a toy, it is used to play games and watch porn.

Much like a lot of succesffull tech that came out actually.

Games drove the pc (and the smartphone) to the powerhouse it is.

And do not underestimate the porn argument. This is what all the people i know commented on and one of the few things with an abundance of content.

So in my book the basics for some form of success are set. The enthusiast status will slowly fade and vr system will slowly seep into the mainstrean like game consoles did.

For certain enthusiats vr is a revelation. If you play racing or flight sims, do yourselv a favor and get a good vr set.

This "vr will never make it to mass adoption argument" because communism sucks is just weird by the way. Is there some form of goodwins law for marx?

</comment><comment><USER20> These are very good questions and I absolutely agree with last paragraph but it's far too early to conclude we're in for a VR winter.

> There's nothing fundamentally illogical about any of these ideas, but they > do remind me a little of Karl Popper's criticism of Marxists - that when > asked why their supposedly scientific prediction hadn't happened yet they > would always say 'ah, the historical circumstances aren't right - you just > have to wait a few more years'.

This is the necessary position when arguing for the inevitability of something that hasn't happened yet. That the arguments are structurally similar isn't evidence for or against. The arguments themselves are what need to be examined.

In the past 20 years, we went from human-narrated MapQuest print-outs from a computer at home to live directions on a tiny computer in our pocket narrated to us via a tiny computer in our ears. For a long time, I held out from upgrading to a smartphone. It was only when I was lost in a city in 2013 and had no idea how to get back home without calling someone many miles away that I finally caved. No one built the entire combination of smartphone, LTE, or voice assistants right away because they wanted a better MapQuest, the pieces came together organically.

> if 'real VR' needs something that's ten or twenty years away, we're in for > another VR winter.

The modern smartphone was ten or twenty years away from the world wide web, which was ten or twenty years away from the computer. Each of these technologies found a niche, however small, until they took over the world.

Is it possible that enthusiasm for VR might wane and the market might die before it has a chance to grow? Absolutely, it's possible. However, the ideal form of the technology being a long way out doesn't make it inevitable.

Tech doesn't need a killer-app to gain a permanent foothold. It helps, but it seems that it's the exception rather than the norm. Incrementally expanding niches is a much more predictable way to bring a product to market.

To me, the big open question is whether or not the small niches VR has today can be grown enough to reach sustainability before the primary hardware vendors (Valve, Facebook, Microsoft, Apple) lose interest. That's a function of price. Given the strong overlap with the hot tech of today (phones, watches, headphones), price will be driven down regardless of how successful VR is. That lowers the threshold of how successful VR needs to be today.

> Meanwhile, it's instructive that now that we're all locked up at home, video > calls have become a huge consumer phenomenon, but VR has been not. This > should have been a VR moment, and it isn't.

This isn't a very convincing argument. Devices that can do video conferencing are everywhere _today_. Zoom is free. Of course it's a phenomenon. Meanwhile, I can't buy a VR headset today without paying 50% above MSRP or waiting 8 weeks. Even then, I'm one of the lucky ones who hasn't lost their job yet and can thus entertain the idea of spending $$$ on entertainment.

I would want to see market data following more high profile releases like HL Alyx or whatever Apple has planned, and look out for a trend in hardware vendors pulling back from VR.</comment>


Bricks (2007) - <AUTHOR> http://weblog.raganwald.com/2007/08/bricks.html <comment><USER2> The idea that software should be built out of building blocks (if not bricks) is actually a good engineering approach .The problem is

1) These blocks are not of the same size or complexity

2) The relationships between these blocks also varies .All bricks in a wall are surrounded by a fix number of other bricks, whereas some modules may have a few dependencies and some modules may have hundreds.

3) It is often more complex than what can be pictured as a two or three dimensional analogy.A better idea is not to think about a spatial representation at all.

4) Although this is my opinion,I think if there are more than three people on a project they should NEVER work on a common block.Each should have a fixed number of independent blocks that they create and write tests for.Anyone not competent enough to create his blocks from scratch,write tests and maintain them does not have the minimum level of competency to participate in the project.Highly skilled engineers of course not only create and maintain their own blocks but also understand and learn from other's blocks.

These ideas are actually very derivative of the ideas in the book "The mythical man month".

<comment><USER3> The fun comes in separating the project in one-man-sized blocks (which won't be the same size).

Indeed, you can track progress by seeing how many features are coming along, but I believe you can't predict a delivery date accurately because of the variance - but you can give a ballpark estimate (days, weeks, months, years, age of the universe).

Agree with giving each developer a separate brick, but on the Kanban approach I was recently introduced to, if someone is stuck, the idea is to "swarm" him and help him/her.

<comment><USER4> There's something subtle but important your comment raises. Feature are not bricks! The brick metaphor is about assigning chunks of implementation that have a possibly many to many relationship with units of business value (call them features).

Dividing up a project by feature and/or tracking progress on a project by feature is very different from tracking project by brick.

<comment><USER3> Sorry, what I had in mind was the Work Breakdown Structure advocated in the "traditional" (PMI/Pmbok), and the lowest divisions as "bricks", or the agile approach of separating a project into User Stories.

<http://en.wikipedia.org/wiki/Work_breakdown_structure>

<http://en.wikipedia.org/wiki/User_story>

It's not what you were talking about.

Your points at the end of the article are pretty similar to what I was taught in a short agile project management seminar this week, if it helps :)

</comment></comment></comment></comment><comment><USER5> This is mostly spot on. But I believe there is a part about decreasing parallelism that is subtly wrong. The posts specific arguments against parallelism seem to imply the optimal way to create shared understanding is to locate it in a single head.

The issue with trite parallelism is that it creates priority inversion. The critical resource is the devs who understand the problem and the code. Trite parallelism merely occupies all the devs who understand with the task of teaching new people, thus prevents progress on diagnosing existing problems. It is however important to know that increasing the number of devs who understand an area is a postive. With increased understanding of an area, new ways to partition work can be discovered or created. Reducing the latency to correctly triage outstanding bugs is also important for re-scoping, which is somewhat more powerful than merely re-estimating.</comment>


'Negro,' 'Oriental' and 'Indian' to Be Scrubbed from All Federal Laws - <AUTHOR> http://www.theroot.com/articles/news/2016/05/_negro_oriental_and_indian_to_be_scrubbed_from_all_federal_laws.html?utm_content=buffer8d486&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer <comment><USER2> It would be interesting to see the usage of 'Negro' and 'Oriental' etc in the Statutes at Large attributable to each political party over the years.

</comment><comment><USER3> Nearly none of these belong in the law, no matter what word you use.

The one exception is that we need to way to refer to tribal lands, tribal law, tribe membership, and similar. I think "tribe" and "tribal" are normally the best terms for this. In some cases, "North American Aboriginal" or "Hawaiian Aboriginal" would be more appropriate.

</comment><comment><USER4> Headline (and article) are _wildly_ inaccurate. The bill in question [0] amends _exactly two_ federal laws (one section of each), not "all federal laws", to change the use of terms for racial/ethnic groups: the "Department of Energy Organization Act" and the "Local Public Works Capital Development and Investment Act of 1976".

That's it.

[0] [https://www.congress.gov/bill/114th-congress/house- bill/4238...](https://www.congress.gov/bill/114th-congress/house- bill/4238/text/enr)

</comment><comment><USER5> replaces "Oriental" with "Asian American", what if the law isn't in reference to American persons?

when only Asian Americans are eligible for a visa Congress is going to git blame obama

<comment><USER6> I was wondering about that with "Indian," too. If people slip up and replace "Indian" (from India) with "Native American," that's a completely different meaning.

</comment></comment><comment><USER7> I hope a record is kept of the changes, I bet they'd be really interesting from a historical perspective.

<comment><AUTHOR> I absolutely agree. I'll be keeping an eye on the progress of this.

</comment></comment><comment><USER8> How is this done? I've heard so much about how intractably large the current body of law is. Can you really just grep through the legal database like that? Can _I_ grep through the legal database?

I can think of many other changes we should make, if it's that easy.

<comment><USER4> > How is this done?

Its not: the headline (and source article) are inaccurate (and the article the source article is based on does not make the claim that all federal laws or affected, it seems to be one minor media outlet misreading a report in a different minor media outlet, and not bothering actually reviewing the readily-available official documents.) The bill at issue changes language in _two specific_ federal laws, it does not do so for "all federal laws".

</comment></comment><comment><USER9> Can somebody help me understand why "Oriental" is considered so offensive? It seems about as offensive to me as calling Europe, etc. "the West". Perhaps it's just guilty by association with colonialism and outmoded racial attitudes?

<comment><USER10> Isn't it kinda offensive to lump every east Asian group together?

OK, maybe it's not offensive. Isn't it odd that US laws target Orientals? What is an Oriental? Are sub-continental Indians oriental, are Australian aboriginals, do we care about natives of eastern Russia?</comment></comment>


Geotrust/Symantec has revoked all SSL certificates for .pw domains - <AUTHOR> http://colin.keigher.ca/2015/09/geotrustsymantec-has-revoked-all-ssl.html <comment><USER3> Could this be anything like the DigiNotar hack?[0]

If it came out that Symantec's certificate authority was used to issue fraudulent certificates, the damage to their business could be in the hundreds of millions. What if the silence is because Symantec is trying to figure out the best way to break the news to us?

Edit: After a bit more reading, Symantec has some history of monitoring .pw for malware and spam.[1][2][3] Perhaps someone just decided they wanted nothing more to do with PW issuer Directi, which apparently has a poor reputation.[4]

[0][https://en.wikipedia.org/wiki/DigiNotar](https://en.wikipedia.org/wiki/DigiNotar)

[1][http://www.symantec.com/connect/blogs/rise-pw-urls-spam- mess...](http://www.symantec.com/connect/blogs/rise-pw-urls-spam-messages)

[2][http://www.symantec.com/connect/blogs/pw-hit-and-run-spam- ro...](http://www.symantec.com/connect/blogs/pw-hit-and-run-spam-royal-baby- trend)

[3][http://www.symantec.com/connect/blogs/rig-exploit-kit- used-r...](http://www.symantec.com/connect/blogs/rig-exploit-kit-used-recent- website-compromise)

[4][http://www.jl.ly/Email/palau.html](http://www.jl.ly/Email/palau.html)

<comment><USER4> Wait. I'm the last person to defend Symantec (see [1] [2]) but the headline seems to be a load of rubbish, or at least certainly isn't backed by the content of the article.

Here are the only two reseller quotes from the article:

> Reseller rep.:

> We regret to inform you that certificate [number] for www.canary.pw domain > has been revoked by the Certificate Authority due to the site being flagged > as potentially containing malware in a recent site scanning by Symantec > (owner of GeoTrust). Unfortunately we were not warned of the upcoming > revocation, so we apologize for any inconvenience that this may cause.

A single website, that allows people to search stolen data, eg the Ashley Madison hack, and asks people to submit stolen data, has had it's certificate revoked.

and:

> Reseller rep.:

> As per our check with Symantec, they will no longer be issuing SSL certs to > .PW domains. You are advised to remove the SSL certificate from the server > to avoid security errors related to a revoked certificate.

> And furthermore Symantec are no longer issuing certificates for the .pw TLD.

Neither quote equates to Symantec having 'revoked all SSL certificates for .PW TLD domains' as mentioned in the headline and this HN submission.

As much as I dislike Symantec - and I really dislike Symantec - I think this article's headline is false.

[1]. [https://certsimple.com/blog/seal-in- search](https://certsimple.com/blog/seal-in-search)

[2]. [https://certsimple.com/blog/sgc-ssl- certificates](https://certsimple.com/blog/sgc-ssl-certificates)

<comment><USER4> If anyone's reading this later: I've confirmed this with an industry contact and it's true: ridiculous as it might seem, Symantec are indeed revoking all existing .pw certificates.

</comment></comment></comment><comment><USER5> This is strange. An entire TLD? Symantec hasn't issued an announcement. There's nothing on the CA/Browser Forum mailing list. Nothing on the Symantec Security Response Blog. Nothing on Symantec's Twitter feeds.

Symantec stopped issuing certs in .PW six days ago, according to a blog post.[1] But there appears to have been no public announcement. Even if there was a major security breach justifying this, Symantec has botched the revocation and has lost much trust.

[1] [https://www.reddit.com/r/sysadmin/comments/3j9iyk/just_a_hea...](https://www.reddit.com/r/sysadmin/comments/3j9iyk/just_a_heads_up_symantec_is_cancelling_ssl/)

<comment><USER5> 24 hours later, I'm not seeing any reliable source reporting this. No hits in Google News. Nothing on TechDirt. Nothing on security blogs. Nothing on CA/Browser mailing list. Most hits in Google are to scraper spam blogs that scraped HN.

This report may be bogus, or a hoax.

</comment></comment><comment><USER6> For everybody else who was wondering, .pw is Palau, a tiny island nation (pop. 17k) in Micronesia:

[https://en.wikipedia.org/wiki/.pw](https://en.wikipedia.org/wiki/.pw)

And apparently its sole decent hotel is smart enough to use a .com instead:

[http://www.palauppr.com/default-en.html](http://www.palauppr.com/default- en.html)

<comment><USER7> Also truly stunningly beautiful place to visit - though a bit difficult to get to. And it certainly has significantly more decent hotels than just that one. Tourism is definitely it's biggest industry.

</comment></comment><comment><USER8> The current CA PKI system is pure madness. Everyone in the CA club can issue certificates for anything - and you are at their mercy for not revoking. And what's worse, even if you pick a decent vendor, you can't prevent shadier outfits from also issuing parallel certs. :(

<comment><USER9> In the short term - by which I mean, the next ten years - my hopes are on DNSSEC with DANE/TLSA for DNS-based certificate assurance. This is not a great solution: firstly, adoption of DNSSEC has yet to snowball; and secondly, DNS remains a tree with a single root controlled by a governmental authority, and it's tough to argue that's any better than the CAs.

The longer dream of a universally federated, decentralized trust mesh depends on a substrate protocol emerging for which I think Bitcoin is only the first glimmer of hope; timeframe ca.10-50 years.

<comment><USER10> Except DNSSEC is just as sketch (and maybe more so) a trust chain. We replace CAs with registrars (OH GOD), TLDs (and for .com, that's just CAs again or governments, OH GOD), and ICANN (subject to government seizures!!!).

I'd much sooner support adoption of Marlinspike's Convergence or something similarly distributed: [http://convergence.io/](http://convergence.io/)

<comment><USER8> But even with today's SSL CA system, those entities (registars, TLDs, ICANN) have full control. They could easily override the NS records and/or WHOIS for a domain targeting a domain-validating CA, and receive a valid certificate.

Might as well place the CA authorities with the TLDs, then. At least that would limit their authority to their subtree, instead of the free-for-all that is the current CA club. It might even let end-users make a semi informed trust decision: ".be seems to run a tight shop and appears trustworthy, .ly not so much" (random TLDs picked for example purposes only).

It would even make it worthwhile for site owners to pick a more reliable/valuable/expensive TLD (and thus CA), since it would bring a generally-accepted-to-be higher level of trust.

<comment> bro-stick Exactly. The challenges with convergence are akin to a simplified gpg+keybase... increasing its popularity needs further development and proponents to gather a critical mass of users and providers.

Trust is hard. For top-down TLS CA to work, the net needs a fewer trustworthy, sensible, well-secured/geo ip'd/leadership nonprofits to be the systems-of- record far out of reach of govt and corporate dictatorships. (icann, iana are a good start, but they could be better. ssl cert cert authority as another type common-good org.).

Also, having a zillion CAs able to independently issue endless wildcard certs for the same domain is lunacy... only the domain owner can be issued certs. It should be tied to common global record-keeping system as domain name registrars do and/or domain registrar-mediated challenge to prove ownership (control panel login / authenticated API calls, not just adding some spoofable TXT record cookie or link in an email). End MITM by rogue certs, at a minimum.

<comment><USER8> Yes, exactly. The registrar would be the obvious place for CA issuance - <USER2> definition your account there proves your ownership.

Heck, make it a requirement that registrars issue free SSL certificates as part of the domain registation service and we might even get to the https- everywhere world that seems to be in vogue. Double bonus if this can be engineered with a technical guarantee/verification that only the proper registrar for a domain is a valid CA for it.

</comment></comment></comment></comment></comment></comment><comment><USER11> Why on earth should any CA be getting involved in what a site hosts? They need to validate ownership and stop.

<comment><USER12> If a site is blatantly criminal, should a CA revoke its cert?

<comment><USER11> A: Seems like they got it wrong here if that was indeed their reason. That alone is good enough to say no.

B: Criminal for who? I certainly don't want Geotrust deciding what's allowed. Does that mean they can e.g. block sites donating to Wikileaks?

<comment><USER12> B: criminal in that country. If donating to Wikileaks was declared illegal in the US (it hasn't), then I'd be fine with Geotrust revoking certs for websites blatantly violating that.

<comment><USER13> Does Geotrust then accept full legal responsibility of guaranteeing that the contents of a site is legal in the US? If we find cp on a site with a Geotrust SSL certificates, will we send the Geotrust board to prison for it? If the answer is no, then they cannot do what you said.

<comment><USER12> _If the answer is no, then they cannot do what you said._

Uh, no. Plenty of companies already censor certain content without accepting liability for parts that they miss. There is no law preventing a company from not hosting content they find problematic, whether it's illegal or for any other reason. That doesn't give up their protection under DMCA. (CAs wouldn't even need DMCA, because they aren't hosting content or redistributing it).

Similarly, there is no law I know of that would disallow a CA from revoking a cert they issued. Maybe breach of contract, but generally their terms will prohibit illegal activities, so the other side will have breached contract first.

<comment><USER13> Do you think it should be legal for a fictional company called Goober to pay the CA for its fictional competitor Drift so that the CA revokes certificates "in the interest of public safety while the CA expeditiously researches the issue" within 10 to 15 business days?

<comment><USER12> If the website did not do anything wrong, they can sue for breach of contract. I explicitly addressed this point in my above comment.

<comment><USER13> So maybe the CA should not proactively do anything but rather await a court order to disrupt their customer's service? I would be completely OK with disruption if service after a court order that requires it. I am not OK with proactive and speculative shutdown of service (even with "infallible" evidence, it still remains proactive and speculative until the clients are proven guilty of illegal activities in court).

ikeboy 3 minutes ago

> I'm fine with a CA doing that. I'm also fine with them choosing to revoke > specific certs after deciding those are clearly illegal. If they are later > shown to be legal, then sue the CA for breach of contract or whatever.

> If you were a CA, and people were using your certs for a cp site or trading > in stolen credit cards, how would you like being told you couldn't revoke > the cert unless some court asked you to?

I'd tell them that I'm not responsible for what my clients do or don't do.

The CA root supply isn't big enough for the Free market to do is job by itself.

<comment><USER12> I'm fine with a CA doing that. I'm also fine with them choosing to revoke specific certs after deciding those are clearly illegal. If they are later shown to be legal, then sue the CA for breach of contract or whatever.

If you were a CA, and people were using your certs for a cp site or trading in stolen credit cards, how would you like being told you couldn't revoke the cert unless some court asked you to?

>I'd tell them that I'm not responsible for what my clients do or don't do.

Hm, I wonder how well the media will take that ...

<comment><USER14> We already have a mechanism for determining that something is illegal, called the criminal justice system. We don't need every private company in the world passing its own judgment on that with respect to its customers, employees, or anyone else. It is highly unlikely that even the largest and most diligent corporation is going to be as effective at that as the public system, despite the latter's flaws. Centuries (millennia, really) of experience and billions of dollars go into solving this problem. If you're not satisfied with that solution, we need to improve it, not reimplement it badly in 50,000 different places.

<comment><USER12> So what exactly are you proposing? Should companies be banned from enforcing their own standards? Should every company be required to treat any and all customers alike, without doing a "legal risk analysis", because that prejudges the law?

<comment><USER13> Ban is a strong word. What I'm saying is that if I were a CA, it is against my interest to project the idea that I take proactive effort against my customers. I'm warmer to the idea of being picky on which clients to take but even that is a picky topic.

Like you said, it doesn't matter what is legal. Media will have a field day talking about my CA should someone like Ashley Madison be my client. But that's just the beginning.

There will be cases against me because well f#$% me, right? I mean I took steps in case A and was unable tondonsonin case B. It doesn't matter if the case has no merit. If there are enough of them, it still distracts me significantly from my job.

At least that's my perspective. I've never run a CA so I'm sure I don't understand the subtleties but the way I understsnd it, perhaps CAs would be better served to restrict themselves to authentication.

Now, that's not to say that CAs should do nothing. For example, if your own private keys are compromised I can imagine a scenario where you'd move quickly to invalidate everything underneath. But I guess these are technical and security reasons not fear of a media backlash.

<comment><USER12> _What I 'm saying is that if I were a CA, it is against my interest to project the idea that I take proactive effort against my customers._

That's fine. It's also fine for another CA to analyse the situation and come to a different conclusion.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> "But here's the thing: why did Geotrust just go ahead and revoke the certificates for all .PW domains without any warning?"

Why indeed? My first notice of this was a client unable to use the app even though the cert was issued less than 6 months ago and was a 2 year cert. Like the author I also initially thought client configuration issue until I tried.

I contacted the reseller who didn't have an answer right off the bat but had to contact Geotrust. After 15 minutes of fooling around I got an answer and a refund. So yes, they issued me a refund. Great. My clients had downtime. I had to drop what I was doing "right then" and install new certs. Finally I had to walk clients through clearing old certs from their browser as they were getting the scary "Untrusted!" popup. Fortunately this is a private app for a specific client so there weren't a bunch of calls.

Geotrust's handling of this was ridiculous. No email, no notification... I'll certainly never get a cert from then again over this incident.

<comment><USER16> sounds like they were hacked and had to revoke all certs for that TLD

<comment><USER17> I don't think GeoTrust was hacked. If they had been, their response was "sorry guys, we're working on fixing this soon. You'll have to do x,y,z to fix your domain". Their actual response was "[we] will no longer be issuing SSL certs to .PW domains", so they have some problem with .PW that doesn't seem to be technical.

</comment></comment></comment><comment><USER18> Let's encrypt it's starting to issue the first certificates[1].

Hopefully dealing with bad CAs will be a thing of the past.

[1] [https://letsencrypt.org/2015/08/07/updated-lets-encrypt- laun...](https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch- schedule.html)

</comment><comment><USER19> I think DNS signing authorities are a bunch of outlaws. They charge for trust, yet don't establish it themselves.

</comment><comment><USER20> Btw, can someone explain to me how revocation interacts with certificate pinning?

<comment><USER12> Quick search turns up a proposal to deal with it [https://www.ietf.org/mail- archive/web/websec/current/msg0050...](https://www.ietf.org/mail- archive/web/websec/current/msg00506.html) (but hasn't been implemented in the actual standard, see below).

 _Revocation

In the event of pin mismatch, clients MUST check whatever revocation mechanism is available, and attempt to discover whether the certificate with the mismatching fingerprint has been revoked. For example:

      offending_certificate = cert in certificate_chain where
          cert.public_key.fingerprint == mismatched_fingerprint

      revoked = offending_certificate.serial_number in revoked_serials

If the offending certificate has been revoked, it is unpinned and the UA can re-evaluate the pin list. If there are no pinned fingerprints left on the pin list, the browser downgrades the host from Known Pinned HSTS Host to Known HSTS Host.

The revocation mechanism could be an extant mechanism such as CRL or OCSP, or a new one such as browser updates, whitelists, blacklists, or an in-built CRL. This document is agnostic about the revocation mechanism(s) UAs may use.

Un-pinning

Certificates that are invalidated for any reason and by any means -- revocation by extant or future means, expiration, blacklisting -- are effectively removed from the pin list. Certificates whose intermediary or root signers are revoked are also effectively invalidated and removed from the pin list.

HSTS Hosts can un-set pins in clients (un-pin) by setting a pins directive that contains no pins. UAs MUST NOT obey the un-pinning directive unless the empty pins directive is set on a response in a TLS connection that was authenticated with one of the previously pinned public keys._

This doesn't seem to have made it into the standard, though: [https://tools.ietf.org/html/draft-ietf-websec-strict- transpo...](https://tools.ietf.org/html/draft-ietf-websec-strict-transport- sec-02#section-7.3) says

 _When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 10 "UA Implementation Advice", below) if there are any errors (e.g. certificate errors), whether "warning" or "fatal" or any other error level, with the underlying secure transport. This includes any issues with certificate revocation checking whether via the Certificate Revocation List (CRL) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC5280]._

and [https://tools.ietf.org/html/rfc6797#section-8.4](https://tools.ietf.org/html/rfc6797#section-8.4) says

 _When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 ( "User Agent Implementation Advice")) if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking that UAs employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560], as well as via TLS server identity checking [RFC6125]._

<comment><USER20> Thanks :)

I wonder if this has actually been implemented correctly...

Sudden revocation of a TLD will probably result in a sudden hammering of the CA's revocation servers too. I imagine an icky failure cascade is happening for some unfortunate user

<comment><USER12> In case you didn't see my edit, this behavior (revoke key pin if cert was revoked) is not in the standards, only proposed. The standards say the opposite.

<comment><USER20> In that case; ouch!

</comment></comment></comment></comment></comment><comment><USER21> I've had issues with other registrars revoking certificates for questionable reasons (i.e., any reason other than obvious loss of control of the private key).

Is there a "bulletproof" registrar that doesn't revoke? If my client loses thousands of dollars per day of downtime I'm sure they'd be willing to pay through the nose for it.

I understand the reasons for having a revocation system but it's often not a benefit to me on balance-of-risks basis.

<comment><USER22> How about getting certificates from multiple, geopolitically diverse providers up front? It'll be an extra expense but lets you monitor your certs' revocation status and, should cert #1 get revoked, update your configs to use cert #2 and so on.

That might even be a good idea for CloudFlare to implement in their SSL offerings[0] if they don't already. They could offer multiple SSL certs from various providers (for an extra fee even) and the whole process would be completely transparent to your origin server, which can run its own self- signed cert.

[0] [https://www.cloudflare.com/ssl](https://www.cloudflare.com/ssl)

</comment></comment><comment><USER5> Is this for real? All we have is one unknown blogger, Colin Keigher, picked up by other sources. It's Tuesday afternoon, so everyone is back at work. A takedown of an entire TLD should have hit news sources and major security blogs by now. I'm not seeing anything other than echos of the original blog post. It hasn't even come up on the CA/Browser forum mailing list or security blogs.

</comment><comment><USER23> I just developed a browser to server based crytpo channel meant to replace the SLL certificate mess on a side project I'm working on. I know that there's a bad rap for browser based crytpo and rolling your own but I've got some knowledge and thought I would give it a shot.

The code is not public (yet) but uses DH key exchange (using the JS BigInt library) to exchange a 2048 bit token key and then uses sjcl to perform encryption on each packet/request using the resulting key.

It's lacking host validation (am I talking to the correct server?), but I'm still working getting that piece together.

<comment><USER23> Anybody care to comment rather than just downvote? I wouldn't mind hearing some thoughts regarding this part of the project.

<comment><USER24> Complaint about complaint about downvoting notwithstanding, my guess as to why nobody commented was: there is no meaningful way to comment on it. There is no link with a detailed description of what you have done, or demonstration of how it works. There is also no source code to look at yet.

While I am sure it is an exciting project for you, without something that people can try (or at least source code to look at), it doesn't add anything valuable to the reader of the comment. It just adds to the noise of the conversation.

If you wait until you are ready to show people the code, then I'm sure many people will be interested to discuss it. Before that, it's not time yet.

That's my perspective, anyway. I hope it is useful to you.

</comment></comment></comment><comment><USER25> I don't know who thought that having the possibility of revoking certificates was a good idea, especially when that possibility is controlled by CAs

<comment><USER26> People who considered the possibility of private keys for certs getting compromised.

<comment><USER27> It's an interesting question whether it would be a good idea to require revocations to be signed _by the subject key_ rather than by the issuer key. I guess it depends on the threat model!

Conceptually, the idea is that if the issuer makes an assertion about what's true, they want to later be able to stop making that assertion. That seems to make basic sense. (But in some threat models, the issuer might have been coerced, and maybe it's easier to coerce authorities to revoke than to misissue. For one thing, browsers are unlikely to kick CAs out of their trust lists for improper revocation, but they might for misissuance!)</comment></comment></comment>


Your next computing language should be … - <AUTHOR> http://www.real-user-monitoring.com/your-next-computing-language-should-be/

<comment><USER2> Ok, I've got HTML, SQL and bash down pretty well. I'm not an experienced programmer by any means, though. Like, I've made a website. What should I ACTUALLY learn next? When I took up programming a couple years ago, everyone said to start with Python. I ended up somehow doing everything in PHP instead. What's cool now?

<comment><USER3> What's _cool_? Ah, that's a different question. Prob'ly Go. See also [http://www.infoworld.com/d/application- development/10-progra...](http://www.infoworld.com/d/application- development/10-programming-languages-could-shake-it-181548)</comment></comment>