Senator requests better https compliance at US Department of Defense [pdf] - <AUTHOR> https://www.wyden.senate.gov/imo/media/doc/wyden-web-encryption-letter-to-dod-cio.pdf <comment><USER2> Used to work in the Senate and have always admired Senator Wyden and his staff when it comes to being up to date on important technical issues like net neutrality, domain name governance, data breach law, cybersecurity standards, and now this.

If you have specialized technical knowledge that can inform policy of importance (your call on how to judge that), I encourage you to engage your senators/reps on such issues, or at least connect with the legislative assistants in the offices who cover these issues. Give your senators/rep's DC office a call and ask for the LA (aka legislative assistant) and to brief him/her on the issue at hand. Or at least offer yourself as a resource if needed.

The best part about working in the Senate was being able to call up someone and ask for a briefing on an issue, and most would help out. Those that reached out proactively made life much easier, and, seriously, the squeaky wheel gets the grease in the policy world. Groups like I Am The Cavalry have done great work bringing together cybersecurity experts to raise awareness of, and push action, toward addressing vulnerabilities in systems that, if compromised, could cause major harm (think cars, medical devices, etc.). If you can form a group like that in your area of expertise, you can be more effective. Okay, off my soapbox for now.

<comment><USER3> Well, I would encourage my senator on such issues, but my senator is Wyden. Here goes another "thank you, keep up the good work" letter.

<comment><USER4> You don't have two senators?

<comment><USER3> Merkley tends to have a similarly straight head on his shoulders.

</comment></comment></comment></comment><comment><USER5> My team and I are the folks that have been fighting to make exactly this happen in DoD for years. We provide web hosting for the DoD Public Affairs community; we host 785 of DoD's top websites including defense.gov, af.mil, marines.mil, navy.mil, etc. For a deeper understanding of the issue, I have written a few blog posts about this to inform my stakeholders (links below).

Delivering public DoD websites using commercially-signed certificates was nearly impossible until January of this year when DoD CIO signed a memo titled, "Commercial Public Key Infrastructure (PKI) Certificates on Public- Facing Unclassified Web Servers." That memo enabled us to use commercial DV certificates to deliver public-facing .mil websites and will save the taxpayer millions of dollars. The day we got that memo was a very good day; we've been trying to get this change made for literally more than 10 years.

My team and I are passionate about our work, and we refuse to be another typical DoD information system that's down all the time, impossible to use, and only works on some archaic version of IE. The truly frustrating part of this is that we're already doing exactly what the Senator is asking, but I have no way to let him know. Yay bureaucracy.

Here are the links to the blog posts discussing this: 1 - [http://publicweb.dodlive.mil/2016/10/06/why-doesnt-my- public...](http://publicweb.dodlive.mil/2016/10/06/why-doesnt-my-public- website-use-https/) 2 - [http://publicweb.dodlive.mil/2017/09/19/still-no- https-for-d...](http://publicweb.dodlive.mil/2017/09/19/still-no-https-for- dma-hosted-websites/) 3 - [http://publicweb.dodlive.mil/2018/04/02/https- breakthrough/](http://publicweb.dodlive.mil/2018/04/02/https-breakthrough/)

<comment><USER6> What group? USDS Defense Digital Service? Would be interested to know of such initiatives.

<comment><USER5> We are the Defense Media Activity. You can check us out here: [https://www.dma.mil/Services/DOD-Public- Web/](https://www.dma.mil/Services/DOD-Public-Web/). We have worked with the DDS, the DoD incarnation of USDS, on several initiatives.

</comment></comment></comment><comment><USER7> Wyden is a treasure. He's also, to my mind, the one who precipitated the Snowden leaks.

Wyden asked Clapper if the NSA collected data on Americans. Clapper lied. According to Snowden's account, that's what set him in motion. Even that account is not true, I want lawmakers to be asking that kind of tough and well thought out question.

<comment><USER8> According to Clapper he misunderstood the question and thought they were asking about something previously just asked. Heard him interviewed on the BBC just a day or so ago where they asked him about it - and he said he hasnt previously lied in the hundreds of times he's appeared so why would he now. So I guess ppl can make up their own minds.

<comment><USER9> The previous question was about whether the NSA builds dossiers on all Americans, which is a far cry from having a database of phone call metadata not linked to PII used to find phone numbers of associates of malicious foreign agents.

Also, GP's timeline is backward. Snowden reached out to Greenwald four months before that hearing.

<comment><USER10> Uhm, phone call metadata is PII.

IANAL, but if you have phone call metadata and you think it's not in scope for GDPR then you'll be disappointed.

</comment></comment></comment></comment><comment><USER11> AFAIK, the point of the DoD Root CA is to avoid trusting an external entity not to intercept military traffic. Most .mil HTTPS sites that are intended to be accessed by the public (like [https://www.army.mil/](https://www.army.mil/)) are signed by a regular Root CA, while internal sites use the DoD Root CA.

<comment><USER12> But any CA can issue certificates for any domain in our current system. Sure, you can always manually inspect the certificate and see if the root CA is expected. But does anyone do that at all?

<comment><USER13> Any CA can issue certificates for any domain, but they may not be permitted to do so.

Certification Authority Authorization (CAA) DNS records can be used to indicate which CA is authorized to issue certificates for a domain. The CA/Browser Forum requires all certificate authorities to check CAA records prior to issuance.

<comment><USER12> > The CA/Browser Forum requires all certificate authorities to check CAA > records prior to issuance.

And what if a CA fails to check CAA records? Revoke their status as an authority? By then attackers may have already obtained highly confidential information from DoD sites.

</comment></comment></comment></comment><comment><USER14> What an excellent letter. It appears that this Senator knows what he is talking about, or is at least very well informed by those around him. I wish more people--not just those in government--were this informed about these very serious issues.

<comment><USER15> That would be Chris Soghoian: [https://en.wikipedia.org/wiki/Christopher_Soghoian](https://en.wikipedia.org/wiki/Christopher_Soghoian)

<comment><USER16> ... who is HN user csoghoian:

[https://news.ycombinator.com/threads?id=csoghoian](https://news.ycombinator.com/threads?id=csoghoian)

and very disciplined about not using social media while working in the Senate!

</comment></comment></comment><comment><USER17> Commendable but he should set an example and do something about his footer: HTTP://WYDEN.SENATE.GOV.

<comment><USER18> I got a 301 redirect to HTTPS when I tried going there.

<comment><USER19> Still better to link directly to the HTTPS page to prevent SSL stripping. Unless the site is already on the HSTS preload list of course; then it doesn't really matter.

</comment></comment></comment><comment><USER20> As a veteran can we please get someone to look at the patchwork of expired certificates and questionable CN's that exists as the VA Benefits system? I swear the handshakes are coming live from some old half-retired grunt in the payroll department.

<comment><USER21> That's odd - the VA pretty much leads the way with compliance on this...

It's literally the only agency listed with over 15 sites that is greater than 99% compliance.

[https://pulse.cio.gov/https/agencies/](https://pulse.cio.gov/https/agencies/)

</comment></comment><comment><USER22> Oh you have no idea how welcome this is. As a member of the National Guard, we are expected to use our own personal equipment to access DoD websites. It is a constant battle of certificates that are not recognized, expired, many other things. The Army maintains a gold image for all active duty computers, but us silly part time soldiers who try to use our own equipment are completely screwed.

Just this month alone I have been 'mandated' to sign multiple documents and complete on-line courses that I can not access due to the Army's making everything only Microsoft compatible. So many sites are years old still making ancient calls to Internet Explorer functions.

The simple act of fixing the certificate issues would eliminate half the frustration right now. The second thing they need to do is mandate that any site has to operate with all the major browsers, and not just ancient versions of IE.

</comment><comment><USER23> That is a letter from a US Senator requiring the CIO of the US DOD to provide him with progress on the deployment of TLS and enforcing with HSTS.

In the UK, the Home Secretary (who really ought to know better) once memorably wittered on about "hashtags" (1). I suggest that Ron Wyden off of Oregon is either or both of well informed and knowledgeable in IT matters.

(1) [https://www.theregister.co.uk/2017/04/03/uk_home_secretary_a...](https://www.theregister.co.uk/2017/04/03/uk_home_secretary_amber_rudd_hashing_not_hashtags/)

<comment><USER24> Wyden is the most knowledgeable legislator we have when it comes to technology. Here's him explaining Net Neutrality [1] and urging a 'no' vote [2] on Ajit Pai's FCC nomination.

Here's a letter [3] from him a year ago urging the importance of two-factor authentication.

[1] [https://www.c-span.org/video/?c4698027/senator-ron-wyden- net...](https://www.c-span.org/video/?c4698027/senator-ron-wyden-net- neutrality)

[2] [https://www.c-span.org/video/?434822-2/senator-wyden-ajit- pa...](https://www.c-span.org/video/?434822-2/senator-wyden-ajit-pai-fcc- nomination)

[3] [https://www.wyden.senate.gov/imo/media/doc/Two- Factor%20Auth...](https://www.wyden.senate.gov/imo/media/doc/Two- Factor%20Authentication%20April%2020,%202017.pdf)

<comment><USER25> Wyden is a treasure, plus he's a fan of oshpark[1]!

[1] [https://twitter.com/RonWyden/status/896012835448381441](https://twitter.com/RonWyden/status/896012835448381441)

</comment></comment></comment><comment><USER26> The "Mozilla SSL Configuration Generator" has a checkbox for 'HSTS enabled?' and can generate SSL/TLS configs for Apache, Nginx, Lighttpd, HAProxy, AWS, ELB. [https://mozilla.github.io/server-side-tls/ssl-config- generat...](https://mozilla.github.io/server-side-tls/ssl-config- generator/?hsts=yes)

You can select 'nginx', then 'modern', and then 'apache' for a modern Apache configuration.

Are the 'modern' configs FIPS compliant?

What browsers/tools does requiring TLS 1.3 break?

<comment><USER27> Because TLS 1.3 is sat in the Editor queue patiently alongside other RFCs there isn't, or shouldn't be, any software compatible with TLS 1.3 today. Implementations of the Draft 23 or other editions are deliberately incompatible with and must be replaced by the real TLS 1.3 after the Editor is done with it even though (as it stands) they are otherwise functionally identical.

<comment><USER26> Firefox, Chrome, and CloudFlare all already support (DRAFT) TLS 1.3: [https://www.ghacks.net/2017/06/15/how-to-enable- tls-1-3-supp...](https://www.ghacks.net/2017/06/15/how-to-enable- tls-1-3-support-in-firefox-and-chrome/)

Apache mod_nss and nginx support (DRAFT) TLS 1.3.

The changes to allowed ciphers in TLS 1.3 could be implemented by modifying webserver config (e.g. as produced by the aforementioned Mozilla config generator tool). IDK what versions of (unupgraded) browsers that would cut off.

</comment></comment></comment><comment><USER28> This would be great...but it seems more likely that what happens if a forcing function is applied is that anything in the current gray area (gray area is putting it nicely) of using the DoD Root CA will likely just become not publicly accessible whether it makes sense or not to do that for the resource (e.g. webmail)

Again, this would be awesome but as a DoD civilian employee...I don't see it happening in a good way

</comment><comment><USER29> Unrelated, but it would be nice if someone OCRed so that the text is accessible. Otherwise it's just a high-quality scan.

<comment><USER30> I was wondering something similar. It's clearly a typed letter, but it's offset from the letterhead. Was this scanned and placed onto the letterhead?

I don't understand how that crookedness happens? I don't think it it wasn't a crooked page placed into a typewriter.. but I also can't explain why it would be printed, scanned at an angle, placed onto letterhead, and then published.

All that said - the senator seems reasonably well informed and asking some good questions - even if his final suggestion for the US military to use Let's Encrypt made me cringe a little :)

<comment><USER31> I keep seeing people putting Lets Encrypt down. What is so wrong with it?

<comment><USER30> > I keep seeing people putting Lets Encrypt down.

That was not my intent at all. I use and love Lets Encrypt's service.

The comment was intended more around the fact that the US Military (and many large businesses) would never, and should never, rely on a free service like that.

Lets Encrypt is great, I love it, I'd personally use it for business - but if I'm that large, I'm going to need a support contract + binding SLA + etc with every IT vendor - Lets Encrypt doesn't do these.

<comment><USER27> Maybe, but on the other hand, Let's Encrypt's organisation ISRG is a US charity, so it's not a foreign entity, and its nature avoids scenarios where the DoD gets ripped off.

There aren't many US-based large CAs that would be in a position to offer the appropriate thing here, an API that all the DoD's disparate IT organisations can use to sort out certificates for outward-facing web sites, mail servers, etcetera. It would also be nice (for Congress in particular) for this not to add another budget line item.

It appears that IdenTrust (the small CA that cross-signed Let's Encrypt) used to provide services into the DoD, perhaps they still do, and doubtless they'd like a juicy DoD contract for more of that, but are they in a position to offer ACME (or a proprietary equivalent)? Do they handle the scale to just shove 50 000 DoD site certificates out the door like it's nothing (which Let's Encrypt absolutely could)?

Big Hitters in this space today are: Let's Encrypt, Comodo (British, not American), DigiCert (possibly an option), GoDaddy (surely not), GlobalSign (Belgian / Japanese). After that it's all small potatoes, and a five person company that issues less than a thousand certificates per week is not the right size for a DoD national contract.

Long term the US Government had expressed interest via 18F in actually running a "real" CA, to be limited (in clients like Firefox that know how) to the .gov TLD but you can imagine it's not hard to add .mil there. However 18F is not what it once was under Trump. This is not a good time to be in Washington if your goal isn't to stuff as much cash as possible into your underwear and then waddle off into the sunset, so I'd guess the CA plan is back-burnered and maybe dead for good.

</comment></comment></comment></comment></comment><comment><USER32> This is awesome. :D I hope we see more stuff like this.</comment>


Flexible screens to inspire new devices - <AUTHOR> http://www.physorg.com/news/2011-01-flexible-screens-host-devices.html <comment><USER2> I've been psyched about flexible displays for ten years, but now that I'm used to capacitative touch screens, I don't think I want a flexible display without touch support.

I can't wait for the day when I can crumple up my smartphone and shove it in my pocket.

</comment><comment><USER3> I like how clicking the enlarge button shows us a smaller photo.

</comment><comment><USER4> I really hope device manufacturers embrace this technology before Apple feels obliged to kick their butts once again.</comment>


Server-generated JavaScript responses - <AUTHOR> https://37signals.com/svn/posts/3697-server-generated-javascript-responses <comment><USER2> as I read that I kept wanting to say "No, we're so past that! i need client- side everything w/ json apis" (as I'm sure a lot of people and the mindshare of the interwebs are going) but then I read the last part:

      > If your web application is all high-fidelity UI, it's completely legit to go this route all the way. You're paying a high price to buy yourself something fancy. No sweat. But if your application is more like Basecamp or Github or the majority of applications on the web that are proud of their document-based roots, then you really should embrace SJR

and I realized that he's completely right, the majority of the web is still document oriented "pages". If that's your case, don't try to be an "app" and the 37signals way works just fine for you. in other words, it would not be a good idea to make a blog be a Single Page App (I'm looking at you blogger).

<comment><USER3> I'm sure there will eventually be a happy medium where a page/app is rendered on the server, but upgraded asynchronously to be as dynamic as it needs to be, so we'll see the convergence of apps and pages. The return of progressive enhancement, I suppose - but even better because of pushState, indexeddb, etc.

That's if there's truly some benefit. Server-side rendering has its place, but probably isn't important for apps on the very "app" side of the content-app spectrum. What makes me want very easy to use server-side rendering, even for apps, is the fact that so many of those apps have embedded content - say an email in Gmail - that it'd be great to reuse the same templating if it's later deemed important to have a link to a static version of the content "outside" of the app.

<comment><USER4> I find the best approach is to render the initial view server-side and then render any future requests client-side with data from your API. That way your site will be super fast and can be indexed by search engines.

If you're using node.js then you can even use the exact same template rendering code.

<comment><USER5> Did you read the article? They specifically address this:

 _This means it might well be faster from an end-to-end perspective to send JavaScript+HTML than JSON with client-side templates, depending on the complexity of those templates and the computational power of the client. This is double so because the server-generated templates can often be cached and shared amongst many users (see Russian Doll caching)._

</comment></comment></comment></comment><comment><USER6> This is all well and good until you want to handle error responses on the client. Let's say your user is on spotty wifi and they hit the submit button for your form. Guess what happens if that AJAX request fails? Probably a whole lot of nothing, unless you've got some templates client-side to show an error message. At that point, if you're making your error messages fit into each of your UIs, you'd might as well just be using client-side templates anyway and SJR is moot.

On top of that, you can't update the UI in a meaningful way until you get a response from the server.

That's also not even touching any security considerations that you need to make to use this technique: you can't implement a CSP, you've got to make damn sure you're properly escaping every piece of data [in a special way] that comes through, and you've got to make sure the response that you're sending can't be used in a script tag (i.e.: you need to add an intentional syntax error that you strip off) or an attacker could simply put a script tag on his own site pointing at a URL on _your_ site that returns sensitive information.

TL;DR: Badasses only.

<comment><USER7> This is spot-on.

I worked with someone who helped develop AJAX interfaces before it even had the name, back when XMLHTTPRequest was brand-new, and they built a product similar to this in philosophy -- must have been around 2000.

I worked with a similar model as well on a couple apps, until finally migrating entirely to client-side rendering, and I would never go back. The complexity of server-side code having to write out client-side to update things just defeats you after a while, it's hard to keep a separation of concerns, and things start to turn into spaghetti despite your best intentions. Refactoring becomes increasingly difficult.

But most of all, it's just like you say -- you can't do error handling, or change the interface before you receive a response from the server, or deal with simultaneous requests, or probably 20 other things.

I'm honestly really surprised to see someone recommending this today. Dealing with all these huge numbers of stand-alone snippets which update certain parts of pages in certain conditions, is just an organizational nightmare.

<comment><USER8> I think the reason they do this mostly boils down to wanting to write ruby. If there was a native ruby engine in the browser, i'm pretty sure they would do everything they could client-side.

<comment><USER9> And initial latency/page weight?

Even wikipedia would work great as a client-side app with json, bu then you want to open 30 tabs and you can feel it lagging.

</comment></comment></comment></comment><comment><USER10> I've been experimenting along these lines with making Rails' partial real-time using websockets and it works quite well for Basecamp/Github style apps. Basically you can get "true" MVC while using your existing erb/haml views and you get real-time updates for all connected clients. Some web apps that are replicating desktop like behavior require full client-side MVC, but I think many apps can hit a sweet spot and get the best of both words of server-side rendering with realtime updates.

project: [https://github.com/chrismccord/sync](https://github.com/chrismccord/sync)

<comment><USER11> Hey thanks for sharing that, I think it's a really interesting middle ground.

</comment></comment><comment><USER3> I'd much rather use templates that can be rendered server side as an optimization if necessary, and then updated normally on the client.

As for the criticism of SPAs that you need to download the "entire" JavaScript library is loaded, this can be mitigated by lazy loading the dynamic bits. If you look at how Google+ behaves, it renders the page server side, and then loads controllers for various parts of the app on demand. For such a complex app it loads incredibly fast.

It might be a little bit before there's a server-side renderer for custom elements / Shadow DOM / template binding, plus patterns for deferred loading code, but personally I think that will be the way to go in the near future.

<comment><USER12> > It might be a little bit before there's a server-side renderer for custom > elements / Shadow DOM / template binding, plus patterns for deferred loading > code, but personally I think that will be the way to go in the near future.

There won't be. These guys are just desperately clinging the past. They should be writing the Ruby on Rails for Opal instead of trying to extend the life of something that, frankly, has seen its day.

<comment><USER13> > These guys are just desperately clinging the past. They should be writing > the Ruby on Rails for Opal instead of trying to extend the life of something > that, frankly, has seen its day.

Care to expand? I'm confused what you mean.

<comment><USER12> I mean while the rest of the web world has moved on to the client being the center of the universe the 37Signals guys are busy trying to make sure they can still work the same way they have since 2005.

<comment><USER14> i am all for SPAs an love angular, but in reality >90% of the web world is still using the document orientated model of 37Signals. That will change eventually, but its a long way to go.

</comment></comment></comment></comment></comment><comment><USER15> There is this interesting pattern of having template compilation be possible from both the server and the client, such as with AirBnB's Rendr. It gives you the flexibility to choose where you want that template compilation to occur.

With regards to Twitter's Time To First Tweet being slow under their Single Page App, I recall Alex Maccaw mentioning that their JavaScript library execution was inefficient, in that the client had to download a whole bunch of JavaScript before it would load the part of the app responsible for rendering the data.

I believe he was suggesting that if Twitter optimised the delivery so that parts of Twitter's JS were served after the rendering part of Twitter's JS code, then the time to first tweet could be faster.

In my opinion, delegating template compilation to the client offers a nice separation of concerns; the server is the API, and the client is the UI.

It would be interesting if there was benchmarking done into comparing these approaches, to see where server-side template compilation can be beneficial over client-side template compilation.

<comment><USER16> Exactly, RequireJS if you need to load parts of the client dynamically but use plain old HTML for initial _page_ delivery if you have a lot of results.

It is also what is recommended for Backbone, for example:

[http://backbonejs.org/#FAQ-bootstrap](http://backbonejs.org/#FAQ-bootstrap)

</comment></comment><comment><USER17> RJS was the most awful experience of old Rails. This comment has no other utility, it was just really ugly and depressed me and I've never gotten to say that before.

<comment><USER18> Twas but just a blip in the otherwise excellent timeline of ever increasing joy and happiness.

<comment><USER19> Ever increasing happiness brought by an Omakase meal.

</comment></comment></comment><comment><USER20> "The template is just JavaScript instead of straight HTML" I guess that's one way to make this work. But for everyone that is serious about writing a web app with a slick UI should build things around api calls and move the views to the frontend (backbone.js & handlebars templates are great).

<comment><USER21> Yeah, did you finish reading? He covers that. The cost of doing so might make sense for your projects, but so many people jump all the way to doing that when their "app" is still mostly document-based and it's the wrong way to go.

<comment><USER20> Yep, I finished reading but I disagree with this approach. Even in a mostly document based project I would recommend using frontend templates. Fire and forget type actions are just really easy to do and the whole thing just makes more sense IMO

<comment><USER21> But if you're building Document-based CRUD app number one-billion-and-five where rendering templates is a significant portion of your app's execution time, doing that in the frontend means you cant cache the output, so every render for every user forever has to do all of the work. Sure, it scales well in terms of user volume because you will always have roughly as many resources to process templates as you have users, but it doesn't scale as far in terms of data size and template complexity because when if it gets slow there's nothing you can really do.

Doing it serverside with russian-doll caching means that each template only gets rendered once for a given set of inputs and (at least for most CRUD apps I've ever built) you have huge cache hit rates, so it'd mostly be people pulling static HTML out of memcache all day. Crazy fast.

<comment><USER22> This seems like a poor defence.

Why couldn't you just memcache the json response for a given set on inputs?

Template rendering is _never_ , _ever_ the slow bit in a CRUD app. Ever. At its core it's simple string concatenation. Getting the data, the SQL, is almost always the slow bit unless you're doing some serious computation or file jiggery, which is still not template rendering.

<comment><USER23> My Rails CRUD experience is the opposite. Template rendering always dominates database time. Without caching, rendering templates with nested partials is generally 5-10x slower than data access. Typical times are 20-50ms for ActiveRecord, 100-300ms for views. This is in production environments with production databases, Rails 2-4, even with alternative template engines that optimize for speed.

<comment><USER22> Err, as a comparison, if my C#/ASP.Net MVC responses takes more than 50ms I start looking for reasons why it was going so slowly. An uncomplicated page will take 20ms or so.

And that's on a small VPS.

But even going to Basecamp, the entire time waiting in chrome (which is basically the entire server-side run time + a few ms) is between 150-200ms and that's on what I assume is a fairly busy server.

So I suspect you're doing something wrong.

<comment><USER23> > going to Basecamp, the entire time waiting in chrome ... is between > 150-200ms

The numbers in my comment are "without caching". Comparing them to Basecamp, which caches views and fragments heavily, is apples to oranges. Once I add caching, my typical response times for a cache hit are in the 10s of milliseconds.

You made an Amdahl's law argument that view caching is fruitless because rendering is an insignificant part of total response time. So I responded with _uncached_ performance to show why Rails needs view caching.

It's no accident that Rails has comprehensive caching support; that the Rails team has worked hard to refine and optimize caching in each release; and that DHH writes about it so often (including in this article). You can't have performant Rails without view caching because rendering is dog slow.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER24> is this secure by default in rails yet? i find it surprising that these techniques are promoted at the same time vulnerabilities are being publicly disclosed:

[https://groups.google.com/d/msg/rubyonrails- core/rwzM8MKJbKU...](https://groups.google.com/d/msg/rubyonrails- core/rwzM8MKJbKU/fU28_YloK2MJ)

<comment><USER25> I believe the fix for this (checking if the request is xhr) hasn't been committed yet.

<comment><USER26> Is there a way to check that which can't be faked by altering the browser or a js framework though?

I was under the impression that trying to validate that was ultimately as fragile as checking the user-agent string...

<comment><USER27> It relies on a header, which can't be set through the attack vector, so it's all kosher.

<comment><USER28> Since we are on the same page, could you help me in this discussion with nzkoz? [https://github.com/rails/rails/issues/11509](https://github.com/rails/rails/issues/11509) we're talking about different things

</comment></comment></comment></comment></comment><comment><USER29> To me, this seems really convoluted - maybe as a non-rails developer I'm missing some key information?

Why, for example, would you use this over client-side templating and data- binding? Create the template once, grab some data with AJAX, bind it to the template...

<comment><USER30> Then your initial page hit requires 2 round trips... one to download the page and the javascript, another to get the ajax, and then also a javascript based rendering step.

This way, the rendering is done server side so the initial html comes with the first request, and ajax updates are still generated using the same server side code path, just sent back inside of some javascript.

<comment><USER31> It's not much work to include the "first page" of data as a JavaScript variable declaration embedded in the response to the initial page hit to avoid that second round trip.

</comment></comment></comment><comment><USER32> I'm the author of this comment: [https://github.com/rails/rails/issues/12374#issuecomment-294...](https://github.com/rails/rails/issues/12374#issuecomment-29408698)

I still don't get the benefit over using RJS (or SJR, or JSR, whatever) instead of render :json : with the former you have the javascript spreaded in your views, with the latter you can organize it inside the assets, which IMHO is a way better solution.

<comment><USER33> It's not really mixed in with your views. You would put in a .js file that has nothing but javascript in it.

Some benefits I see are:

1\. It just works perfectly with and without javascript which means your stuff gets crawled by search engines and it works great for people without JS. Then if you have JS enabled you get the enhanced UI.

In #1's case I do this all the time for search boxes. In admin dashboards that I make with rails I allow people to search for data.

It's trivial with rjs to implement a solution that works with no javascript and then if you have JS enabled you get your search results shown immediately without a full page reload.

2\. You can tell the rjs code to use server side (erb) partials that you already have created so you don't need to have templates made for both.

Or in #2's case if you just use jquery without using any template engine it gets super messy trying to append elements to another element with inline html strings. All of that is eliminated by using your existing erb partials.

<comment><USER32> I mean that you would have JS in your app/views folder together with the HTML views, instead of the assets folders only.

1\. It doesn't depend from RJS/render :json, but from the fact that your controller responds to sync requests, in addition to the async ones.

2\. You can tell to render :json to use server side (erb) partials:

      render json: { html: render_to_string(partial: 'product') }

I do it all the time

<comment><USER33> I didn't know about #2, that's really cool. How does render_to_string handle cached partials?

Does it still need to compute the output of the partial's string representation on every request?

</comment></comment></comment></comment><comment><USER26> I've done this in PHP as a hack but I didn't realize it was supposed to be A Thing, with an acronym and everything.

<comment><USER14> haha, yeah that was my thought exactly :)

</comment></comment><comment><USER34> There is an interesting web framework that takes this approach as well -- N2O.

[http://synrc.com/framework/web/](http://synrc.com/framework/web/)

It can do server side rendering but then pushes it via a websocket (well with fallback) to the client.

The use case I understand is mobile clients.

</comment><comment><USER35> The thing about SJR is that it lends itself much better to progressive enhancement: if you need/want to present a page which also works without JS, that means that you need to be able to render the page on the server, which means that by using SJR, you can easily reuse that same view code that you already need to have for the non-JS clients.

Of course, as JS on the server becomes more and more wide-spread, you might as well just use the same templates at both ends, but it' still more infrastructure than treating the client JS as just part of the view.

I discussed this back in 2011 on my blog: [http://pilif.github.io/2011/04/ajax-architecture- frameworks-...](http://pilif.github.io/2011/04/ajax-architecture-frameworks- and-hacks/)

</comment><comment><USER36> _> > The combination of Russian Doll-caching, Turbolinks, and SJR is an incredibly powerful cocktail for making fast, modern, and beautifully coded web applications._*

I'm personally not against SJR and I haven't really gone whole-hog into any JS framework (Angular/Ember/Backbone) ... but almost every RoR developer I've talked to is disabling Turbolinks on all their Rails 4 apps. I personally find it slow to load/render in dev mode, which leads me to believe it would be confusing for users in production.

Is anyone using/liking Turbolinks for Rails 4 apps?

<comment><USER37> I use it in a small app (rails 3 though) and while it may be faster, the issue is that it does not follow typical UX of a website.

Usually people: Click link

White screen / loading (computer is doing something)

Next page progressively shows up

Turbolinks is different

Click link

Nothing is happening...?

Next page appears all of a sudden

</comment></comment><comment><USER38> Great stuff: we do ad-hock versions of this in a few of our applications. It deserves a formalization.

In my brief thinking about this, one potential version would use HTML 5 attributes like AngularJS, but use HTTP/restful endpoints as "the model". I can imagine a few different approaches, but something like:

<div data-dyna-src="[http://myserver/my-div-endpoint"](http://myserver/my-div- endpoint") data-dyna-method="poll 500ms"> ... </div>

Which would then poll the given endpoint and swap in new content in a pluggable-but-visually-pleasing manner. [http://myserver/my-div- endpoint](http://myserver/my-div-endpoint) would serve up the partial of the div, so everything would be DRY. Basically move the model back to the server, but still buff up the presentation layer a bit.

You'd probably need a few different patterns: updateable divs, forms, updatable tables, progress bars, as well as some good default transitions and, of course, make the whole thing pluggable, and potentially provide for both HTML and script interchange at the end point (that's what our ad-hoc version does: it provides a data channel, an html channel and a raw script channel, but it feels like a hack.)

Anyway, if anything is going to save us from the oncoming javascript-filled dystopian hellscape, it's probably something like this.

</comment><comment><USER39> I thought that was called JSONP?

Anyway this is clever from a traditional web development perspective but not from a contemporary one. I like to use AngularJS (with prerender.io when necessary for server side rendering). I write all the non HTML code for both the front and back end in ToffeeScript which is derived from CoffeeScript.

<comment><USER40> This is made with a XHR request, not JSONP. JSONP requests are made by inserting a script tag and defining a callback function to get around cross site requests limitation with XHR.

<comment><AUTHOR> ... which now should generally be done with CORS, if you can.

<comment><USER41> As much as I love CORS, it unfortunately have a ton of browser compatibility quirks... And not just from IE.

</comment></comment></comment></comment><comment><USER42> Rails is a great framework. But posts like this and the one discussing how the team made product decisions around their caching strategy [0] and the horrible hacks that they did to make it work, for me are telltale signs that Rails is not the right tool for building web apps anymore.

Web development is evolving, as it ever has, and I believe that the next step is pushing the view layer to the client, and caching _data_ , not html, on every step of the way. The major hurdle here is SEO, but I hope that when the right framework comes, it will offer an elegant solution to this problem.

[0] [http://37signals.com/svn/posts/3112-how-basecamp-next-got- to...](http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so- damn-fast-without-using-much-client-side-ui)

<comment><USER43> I wouldn't say SEO is a major hurdle, there is prerender.io ([http://prerender.io/getting-started#ruby](http://prerender.io/getting- started#ruby)) and countless other services which help (I made one).

</comment></comment><comment><USER44> Such things were popular more than 15 years ago, when websites had to conserve bandwidth (for many users with slow links) and JavaScript wasn't considered as dangerous as it is now (so people didn't use NoScript much and didn't frown upon JS-only websites like I do).

</comment><comment><USER45> In general, is this a good practice? You do loose the ability to re-use endpoints on mobile.

<comment><USER27> We reuse all controllers and models for our mobile views and for our API. We just do that reuse at the server instead of through the client. So no loss there.

</comment></comment><comment><USER46> Isn't it impossible to optimistically update the UI with this model? You need to wait for a server roundtrip before you can display the results. There are certainly cases where that's OK, but it can make an app feel a lot less snappy.

<comment><USER47> Optimistic updating needs a serious amount of code and robust error handling on the client and is therefore non-trivial. This approach seems aimed to reduce the amount of work while being relatively fast.

<comment><USER48> Unless you abstract away the non-trivial part with something like Firebase :-D

</comment></comment></comment><comment><USER49> Yep, that's a nice and promising technique. I'm currently working on a NodeJS project and I'm using EJS templates with Handlebars templates on the server- side and on the front-end. The benefit is impressive. I can deliver the same content on page-load and using fancy Backbone routing I manage to change dynamically the page without duplicating code logic. I'm reusing some components on server-side and client-side, so my templates will always render with the same context ( JSON ) but on different JS environments. Amazing how far can we go, just to satisfy Google and SEO guys.

</comment><comment><USER50> I suppose this is okay, but it can quickly become a mess as soon as you need to make the modified portion of the dom interactive:

        $('#messages').prepend('<%=j render @message %>')
          .find('.delete').click(fn)
          .end().find('.reorder').hover(fn,fn)

I suppose they work around this problem with event delegation.

If you use something like angular, the whole mess becomes:

        $scope.messages.unshift(message);

<comment><USER51> actually there is a gem that solves that problem if you want to use SJR

[https://github.com/xpdr/transponder](https://github.com/xpdr/transponder)

[http://kontax.herokuapp.com/](http://kontax.herokuapp.com/) \- example app running on heroku

[http://github.com/xpdr/kontax](http://github.com/xpdr/kontax) \- example app on github

</comment></comment><comment><USER52> The web development world has been trending toward a Thick Client. This article is a call back to the Thin Client and centralizing all logic in the app server.

Most devs are still used to the Thin Client approach, so there is a productivity benefit to remain where you are familiar.

However, you can have just as many or more productivity enhancing libraries and practices in client side javascript as in the server side rails-like frameworks.

</comment><comment><USER53> That made me wonder: Is there a general consensus that google will never ever be able to crawl single page applications ? Because after having played with a client side framework, i really see no other real reason to get back to server side rendering.

Looks like all this is really just a way to compensate for google lack of advanced technology on the crawling side ( i just loved that last sentence :))

<comment><USER54> I've gone to a few AngularJS meetups at Google and they seem to think it's not a big problem. The crawler executes JS just fine, it's just a browser.

</comment></comment><comment><USER55> I enjoy dhh articles, but find them a bit hard to understand not being a rubyist. dhh says:

2\. Server creates or updates a model object. 3\. Server generates a JavaScript response that includes the updated HTML template for the model.

Why does a template need to be updated? Isn't that part of the idea of templates, that they are fixed for changes in the model?

</comment><comment><USER56> I don't understand what's the advantage of using SJR.

<comment><USER57> I too did not read the article.

</comment></comment><comment><USER58> > unless you make you're doing a single-page JavaScript app

Yeah, cuz like no-one is doing that anymore. /s</comment>


Lodge: HTTP-to-Syslog Proxy w/node.js - <AUTHOR> http://www.loggly.com/2010/09/http-to-syslog-proxy-with-node-js/

<comment><USER2> Totally awesome!

</comment><comment><USER3> Way to go Kord!

<comment><USER4> Thanks dude. Maybe you can log stuff out of that robot of yours: <http://www.youtube.com/watch?v=Jyl3ABJMRv4></comment></comment>


Visualizing binaries with space-filling curves (2011) - <AUTHOR> https://corte.si/posts/visualisation/binvis/index.html <comment><USER2> Oh, wow! This tool is something else. I highly recommend uploading a file. The interface is just spectacular.

Also, the brush lets you calculate and apply different views. Things like entropy, magnitude. It's very visually attractive.

One feature request I have is: please allow us to set the bit / word width of each unit. Currently it's fixed at 1 octet, and it would be useful to be able to change that.

Otherwise, this is awesome! :)

<comment><USER3> Agree, binvis.io looks great! Just look at [http://binvis.io/#/view/examples/elf-Linux- ARMv7-ls.bin](http://binvis.io/#/view/examples/elf-Linux-ARMv7-ls.bin)

</comment></comment><comment><USER4> Check out: [https://veles.io](https://veles.io) \- it does binary visualization also in 3d

</comment><comment><USER5> [http://icewater.io/](http://icewater.io/) has about 250m malware samples clustered using using something similar. My talk about it from Shmoocon in 2016 is at [https://www.youtube.com/watch?v=nzXzzbr4lqw](https://www.youtube.com/watch?v=nzXzzbr4lqw)

</comment><comment><USER6> Visualizing binary data is definitely an interest of mine and I plan to eventually write some tools for this. It's really cool to see that my brainstormed list of features differs so much from some of the other available tools out there. Just part of that cycle of inspiration.

Space-filling curves weren't even on my radar and I'm still not sure that I'd want to implement them. I do like the result, though and may take that into consideration.

</comment><comment><USER7> If you need an introduction to the subject, 3Blue1Brown is a really good YouTube channel about mathematical visualizations, and they did an episode about Hilbert curves and why they're so useful: [https://www.youtube.com/watch?v=DuiryHHTrjU](https://www.youtube.com/watch?v=DuiryHHTrjU)

</comment><comment><USER8> Nice idea. Would be cool to compare this with the zipped binary to see the change in entropy (altough the colors need to be changed)</comment>


The problem with cashless restaurants - <AUTHOR> https://mic.com/articles/192682/the-problem-with-cashless-restaurants#.1JlChYcfB <comment><USER2> I think it's deliberately discriminatory - homeless people can't utilize the establishment and since money is no good there then they're also less likely to panhandle near the establishment. That's what I think this is actually all about. I'm not saying these aren't legitimate concerns for a restaurant, but I do think this is a deceptive approach for dealing with it.</comment>


Sparrow for Windows was just a few weeks away - <AUTHOR> http://everydaypanos.com/post/27703705803/shh-sparrow-for-windows-was-just-a-few-weeks-away

<comment><USER2> Something doesn't make sense. From the ambiguity of your description, it sounds as though you own the code, and that you had no formal business relationship with Sparrow, and that you accepted no money from Sparrow (it is really strange that Sparrow would even encourage you into such a position, and that you would put yourself there --- you left them in the situation where they could turn your work down, and develop their own Windows client). If that is all true, then the code is yours, and you can turn it into a Sparrow replacement. But you are giving off a sense of finality, as if what you wrote is useless. This confuses me. Think like an entrepreneur, not an employee. If you have roadblocks to selling the e-mail client yourself, overcome them (e.g., if you are worried about UI copyright, then change your UI, and then sell it). Once you earn money from it, move to writing a Mac version, an iOS version, etc.

<comment><USER3> I do not believe this was officially supported by the Sparrow team as he make it seems...

<comment><USER4> The truth is the Sparrow team is a Mac only team. They didn't care much for Windows. If at all. To test the Windows builds, Din Viet used a virtual machine running inside OS X..

<comment><USER5> Yeah but where did you come in? Why you? Why were you working on a product that you had nothing to do with?

I just don't get it at all. Why did you give free labour and free time to a for profit company you had no stake in? See why we are confused?

</comment></comment></comment></comment><comment><USER6> Open-source it. If they're really abandoning the product but actually care about improving the status of e-mail clients they won't send you a C&D.

If they don't care about that as much as they care about preventing unauthorized use of their code, then everyone loses. But you can't know what'll happen unless you take action.

<comment><USER7> They were bought by Google, why would Google do that..?

<comment><USER8> They did it with reMail (<http://www.remail.com/>), too.

<comment><USER7> Did not know that, +1 for google

</comment></comment></comment></comment><comment><USER9> Who owns this code ? Where you paid to develop this code ? If the OP was paid, his code belongs to google. In anycase a copyright will most likely apply to the user interface if it is a copycat of the Mac sparrow app.

If the OP manage to change it and eventually simplify it to make it significntly different, than the copyright won't hold and you own it as the author. The OP may then create his own brand. He should create his own app if the code doesn't belong to goggle.

I would suggest to make it a payed app, twice the price than Sparrow, and use the earned money to develop android, iOS and iMac version. If google offer to hire him, then request that the code is open source. Maybe Microsoft will have an offer to make too.

Of course Panos could also provide the app for free but he needs to earn a fair money for his work and for a living if we want him to continue and sustain the brand. Maybe another company could make an offer like Canonical for instance.

<comment><USER10> > If the OP was paid, his code belongs to google.

That's wrong. Whether or not the OP was paid, his code belongs to him, unless one of these two things are true: first, if there was a contract that transferred copyright; second, if the OP was supervised in an employee-like role (work-for-hire).

That's how it is in the U.S. at least, and I believe France is a part of the Berne Convention, so it should be the same or similar there.

</comment></comment><comment><USER11> Before doing anything, I think that you should talk to a lawyer because there are a lot of questions to be answered.

Who owns the code? Are you free to open-source it or rebrand it? Did you have any kind of contract?What about your employment situation? Did your meetings with Sparrow's staff, and them sharing artwork, constituted some kind of licensing, agreement or anything? Did Google know about your project?

I'm not a lawyer, so I don't know any of the answers. Does anyone know what would happen if they claim that they own the code? Maybe they would have to recognize him as an employee, or a contractor and then pay him for his work. If they allow him to use the code as he pleases, the fact of the company encouraging him to develop the port, and even meeting and sharing some artwork, would it mean that they granted him an implicit licence?

Either way, probably Google's legal team has some work to do.

</comment><comment><USER12> Hate to be that guy, but:

[http://www.theverge.com/2012/7/21/3174803/sparrow-for- window...](http://www.theverge.com/2012/7/21/3174803/sparrow-for-windows- never-existed)

<comment><USER13> Corollary: I absolutely hate it when media outlets use the term "a source". Yes, I do understand that sometimes 'source' is used because the other party requested or requires anonymity for the continuity of their current endeavors or whatever other reason.

But with the current state of news delivery operating at Warp 10 with the added bonus of somehow being able to run a hyperdrive engine at the same time and less research actively being done before a story is thoroughly debunked, it irks me.

<comment><USER14> I think it's especially silly in the case of a "source" from a really small startup.

This isn't like a "source" at Proctor and Gamble, it's what, like one of five people?

<comment><USER15> Or their friends, or people they spoke to at a party or conference. And so on.

<comment><USER14> I suppose.

So a person contacts the article author and says "I spoke with them at a party or conference, and they denied knowing anything about a Windows client."

That's a credible source? Of course not.

<comment><USER15> Credibility isn't binary. What's credible for one news organization says nothing about what another organization/journalist/court-of-law-in-the-UK believes is credible.

There are many more ways to establish credibility - does your story add up, do you know things you wouldn't without having inside info, can the journalist verify that info with a known insider, have you been a credible source in the past, are you personally known to the journalist, are you a known person in the community, do you have a proven connection to the primary source, etc.

</comment></comment></comment></comment></comment></comment><comment><USER16> > I know that Europe cannot really maintain a talented team like the one Dom > and Dinh Viet would need to take Sparrow to new heights.

Really? _All of Europe_ can't provide a team for an e-mail client?

<comment><USER17> Google disagrees. The author should really check out the work done by their office in Zurich, which also works on GMail.

</comment></comment><comment><USER18> If this would ever have been released, it would have failed and die a painful death. As stated by the author, he "stole" (which means he faked) many UI elements from OSX because he "dislikes Metro". This is just wrong and bad practice when developing native applications. A UI designer should never design a UI for an OS which he/she dislikes to begin with, it will just end badly.

What makes Sparrow on OSX and iOS so good is that it stays true to its OS; that it feels native and blends into the OS with such grace that it's a thrill to work with. In contrast, web apps doesn't suffer much from this since users are used to them looking different, as long as they exist inside their browser environment. But for Sparrow to be successful on Windows, these rules would apply...

</comment><comment><USER19> Since hearing that Thunderbird is going to start collecting dust, I've been looking for a decent Windows client and was wishing Sparrow worked on Windows. So this makes me even more sad. I wish Google would do the right thing and open-source it like they did with Etherpad.

<comment><USER20> Comms (www.comms.io) is my project, it's a lightweight IMAP client for which Windows is the initial platform. The alpha is a few weeks off.

<comment><USER21> Just a heads up, 'comms.io' (without the www.) sends you to a bluehost landing page.

</comment></comment></comment><comment><USER22> What are you left with, Panos? Their source code you can't use anymore, and your code which is now worthless? You're left with nothing, in other words? You are not just going to accept this, right? Do something! :)

<comment><USER4> :)

</comment></comment><comment><USER23> The IP situation is interesting. Was there any code re-use? Does the code you wrote belong to Sparrow? If the answer is "no" to both, you may be able to release it.

<comment><USER4> No code was reused. Just Jean-Marc's artwork. Plan was to port LibEtPan in Windows and replace current email engine during Beta, but.. you know.. dead.

<comment><USER24> Why is it dead. The Sparrow team won't work on it any more... but they weren't going to work on the Windows version anyway. If you were writing it, why not keep doing so?

Obviously you might have to change the artwork, since that belongs to google now. Otherwise, it sounds like this is just an email client that YOU wrote.

</comment></comment></comment><comment><USER25> sound unlikely, a proper sparrow port would use the etpan lib (there are windows port apparently), instead of starting the email protocol almost from scratch as the author suggest.

</comment><comment><USER26> dude. kickstarter. go.

Sparrow is one of the few reasons I stick with using a mac, and am somewhat fearful of taking another job using windows again. I even tried having outlook configured in a mode to look more sparrow-ish to realize it didn't work without a real "sparrow" experience.

<comment><USER27> Dude is in Greece, so no Kickstarter for dude.

<comment><USER28> Indiegogo then. It's still a good idea.

</comment></comment></comment><comment><USER29> My hunch is Sparrow's offered a compelling enough user experience to be a rival to gmail's UI, by being the primary point of use for Business and Personal customers, they were not being exposed to Google's revenue points (AdSense and cookie/re-targeting technologies).

</comment><comment><USER30> I have heard from some reliable sources that Microsoft is quite happy to pay for design+development of applications that are built for their new devices (wp7/8). Perhaps you could reach out to them and see if they would acquire your work. It's not the best free market alternative, but it might get your product to live and prosper. Imagine, if Sparrow (Microsoft eMail Light) gets included in every new tablet? Sure, they've got Outlook, but maybe users would dig a lighter (simpler) new alternative?

</comment><comment><USER31> I get what the OP is hassled about. He committed time and energy on developing a product, time and energy he wasn't paid for, but it didn't matter because he believed in the product. He was going to prove that Windows apps could look good, and he was tieing it into an existing, loved brand. In other words, he was doing good, for people who appreciated it. That was enough for him.

However, since it's been bought out by Google, he's lost all the passion for the application. It's just going to get swallowed up by the shark, and no-one really cares. So, what is the point of releasing an awesome version for it?

Obviously, he's got plenty of options at this time. But, the motivation, the passion, the brand recognition, the love, it's all disappeared. Take the magic out of the cauldron and you're just left with boiled, icky bits.

I don't know enough about the application, or the platform, etc, but open- source it, and make it a client that can connect to multiple platforms. Sounds good?

</comment><comment><USER32> Suggestion for you: help out on this other e-mail client that exists asopen source and is desperate in need of some patching: <https://github.com/waseems/inbox2_desktop> :-)) (disclaimer: I am the original author of inbox2)

</comment><comment><USER33> I wouldn't be surprised at all if an impending Windows client was part of the timing for this deal. A resurgence of people using stand alone clients on PCs that don't display ads could have been a big problem for Google's business model. If users really demand stand-alone clients I think Google could reverse course and re-release Sparrow with ad support in the near future. I like Sparrow but it's nothing so special that it cannot be easily cloned. Google won't be able to just take that option off the table unless they want to find ways to lock-out third party clients from utilizing extended GMail functionality.

</comment><comment><USER34> Isn't all software, always, just a few weeks away? lol.

</comment><comment><USER17>
        It kind of seems like the 'new GMail' that ought
        to be native for all devices(the trend is clearly for
        that), was galloped by it's bigger competitor.
        ...
        In fact [GMail] may get even worse since
        it's inception was a mighty web app for email.

No dude, GMail is first and foremost an email _service_. What GMail provides is so much bigger than anything a "native" email client can ever accomplish.

I see this mentality coming from developers all the time, but you're really not seeing the forest from the trees.

I also watched the YouTube videos showing the interface in action. This client might actually be great, however I couldn't see anything there to blow me away, just some icons with no labels and I hate icons with no labels (the first thing I did in GMail's new interface was to search for the option that restores labeled buttons).

</comment><comment><USER35> "Another feeling is the Google effect: I know that Europe cannot really maintain a talented team like the one Dom and Dinh Viet would need to take Sparrow to new heights. "

Is this a serious remark (honest question)?

</comment><comment><USER36> Release it in the wild!

</comment><comment><USER37> this is very sad... google acts like a giant black-howl they are prepared to take on any rival startup take their ideas and on most cases throw them in the bin! παρόλ' αυτα μπράβο Πάνο!

</comment><comment><USER38> So Google bought Sparrow so that they would never release this?

</comment><comment><USER39> Wow, that Windows version was certainly ugly. Why have Windows applications always to suck design wise?

<comment><USER18> I think you are confusing user interface design with user experience (UX). A text-book UI should be intuitive and easy to use, but that doesn't necessarily mean it will be aesthetically pleasing to everyone. I work with UX, and one of the biggest challeges i face is to find a good balance between functionality and aesthetics; what will give the general user base the best possible experience.

But you have to realize that it is impossible to satisfy everyone, especially when looking at OSX-users and Windows-users, who have such different tastes and demands. Then its probably better to have two different UIs that can bring a great (but not necessarily the same) user experience to two very different crowds.

<comment><USER39> > I think you are confusing user interface design with user experience (UX)

That's just an excuse for people to make ugly UIs. Aesthetics is an integral part of usability. A UX designer who has no clue about aesthetics is worthless.

<comment><USER18> What's aesthetically pleasing to a OSX-user might be something totally different to a Windows-user. A UX designer who doesn't know that, is worthless as well ;)

</comment></comment></comment></comment><comment><USER40> Windows has more functional and consistent interface standards than any other platform. It's predictable and utilitarian...in other words, the exact opposite of OS X and "the web".

In Windows, keyboard acceleration is a first class citizen too and it works better than on any other platform.</comment>


App Idea aggregator/poller - <AUTHOR> http://getmadideas.com

<comment><USER2> 'And Twitter, and Facebook, and Uber. They all seemed like pretty stupid ideas. Until they weren't.'

From Jerry Neumann, angel investor [http://reactionwheel.net/2014/07/betting- ponies.html](http://reactionwheel.net/2014/07/betting-ponies.html)</comment>


Google: "There has been a shift in our thinking…" - <AUTHOR> http://counternotions.com/2013/03/11/shifty/

<comment><USER2> What a paranoid post. Google "manipulates" results for financial gain? The assumption that there is a pure solution to a search query is ignorant of search and information retrieval, which fundamentally rely on human-curated content.

PageRank also relied on "Human-curated content". In fact, anything having to do with natural language processing does so in some way.

This is a far cry from saying that Google is hand-tuning search results. In fact, Google has only begun to do so recently as a response to government- orders to hide terms relating to media piracy or Chinese politics. This post displays a lot of romantic confusion about the effects of social media on web search.

</comment><comment><USER3> Scott Huffman is presenting Google's new direction, formulated by University of California law professor Eugene Volokh: [http://www.volokh.com/2012/05/09/first-amendment- protection-...](http://www.volokh.com/2012/05/09/first-amendment-protection- for-search-engine-search-results/)

</comment><comment><USER4> Google must believe that the barrier to entry is now (only) brand awareness, rather than product (search) quality. Let's see whether that remains true forever.</comment>


Ask HN: looking for a tech cofounder, already have 13k users after 2 months - <AUTHOR>

I'm looking for an exceptional technical co-founder who knows RoR and potentially C++.
We started up a few months ago, but my co-founder has decided to move on (he thinks a competitor will take us down - I don't!).
We've already been featured in lifehacker and mashable, got 13k users, signups are flooding in, with a sensible business plan and investors interested.
Looking for someone based anywhere but looking to move to SF, even just for YC this winter.
drop me a line: email@example.com <comment><USER2> The business does what? Your skills are what? You have 13k users and have been featured in lifehacker and mashable after a few months... there's something you're not telling us about why your cofounder has moved on.

Fill in the blanks please.

<comment><AUTHOR> The business is a solution to crowded inboxes.

Currently it's an extension for Chrome, Safari, and Firefox.

My co-founder is moving on because he thinks "Priority Inbox" is too big a threat. I can put him in touch with you if you like.

I don't. I think we can build our solution into outlook, lotus notes, and Apple Mail.

if you want more details send me an email at: email@example.com

<comment><USER3> _My co-founder is moving on because he thinks "Priority Inbox" is too big a threat._

I would have thought it just introduces more people to the idea. It's not like Google will release an outlook/Mail.app/Notes plugin for it.

</comment></comment></comment><comment><USER4> A bit offtopic, but I'd like to chime in anyway.

Any startup should be afraid of the big guys, especially Google. But that's not a solid reason to quit when you have good traction.

BTW, good to see other people trying new approaches to task management. (I'm one of the guys making <http://task.ly>)

</comment><comment><AUTHOR> its taskforceapp.com by the way. Let me know what you think.

<comment><USER5> Clickable: <http://taskforceapp.com/>

<comment><USER6> It looks like it's just some filters ... what am I missing.

<comment><USER7> I found the articles about it:

<http://mashable.com/2010/08/13/taskforce/>

[http://lifehacker.com/5621077/taskforce-manages-your- tasks-a...](http://lifehacker.com/5621077/taskforce-manages-your-tasks-and- email-activity-in-gmail-and-weve-got-beta-invites)

</comment></comment></comment></comment><comment><USER8> So, you don't know what email address munging is and still you're asking for an "an exceptional technical co-founder"? You think you're exceptional? I don't think so. Next!

All the best, anyway.

</comment><comment><USER9> Hey Nicolo, change your about page please, if you really want this to succeed:

"Nic is the CEO and business guy at Taskforce." "Alex is a serial entrepreneur and developer."

Alex left.

Now what? Your first line of introduction makes you (a) CEO and (b) business guy. Hmm... your whole R&D and tech department just left.

<comment><AUTHOR> Thanks. I'll get on that.

</comment></comment><comment><USER10> It will be difficult to be accepted in YC without a proper co-founder, one that you know for longer than 1 month.

<comment><AUTHOR> Agreed. But 1. Have to give it a go. 2. I think with continued positive feedback and traction. It makes an interesting proposal.

<comment><USER10> Why not hire someone as a freelancer before accepting her as a co-founder?

<comment><AUTHOR> Have thought about that - but where can I find good freelancers?

<comment><USER11> There are some here on Hacker News. The average quality level here is probably better than on a site like eLance.com, for example.

</comment></comment></comment></comment></comment><comment><USER12> From what i see in your site, right now it's only gmail, right? Seems that you have a good product. Best of luck.

<comment><AUTHOR> Thanks, based on feedback from our current users they'd be willing to pay in Apps and outlook.</comment></comment>