Why we gave up web design after 10 successful years to move to products - <AUTHOR> http://blog.silktide.com/2011/07/why-we-gave-up-web-design-after-10-successful-years/

<comment><USER2> Web Design: The business where the more successful you get the more you want to kill the business.

If you are in a services business, and you catch the products bug, it's all over.

This is my own opinion of course, and based on my own experiences.

When you enter the Web Design business, you do so because you are both technically capable AND creative (hopefully). The business honestly feels perfect, like what you were MEANT to do.

Then the Client steps in.

You realize that your creativity is rather meaningless. You can be given "free reign" to come up with a design, but at the end of the project, the Client will probably murder it with no regard for your expertise. Your creativity is stunted, and your soul dies as you have to start asking for permission to implement every bit of genius you want to throw at a project.

Then there's products. You create them yourself, for who you believe the customer may be, and your creativity and know-how form the product. When you are done, it's your own masterpiece. Now you sell it. Some will buy it and love it, others will buy it and hate it, others won't bother, others will tell the world.

But it's all OK. You keep iterating. When your "customers" give you feedback, you don't have to implement everything. And the things you do implement are usually loved by yourself AND your customers.

Like I said. If you are a "services" person and you get a taste of the "products" world, there's just no turning back.

<comment><USER3> That's a little unfair. I think the eating-regularly aspect of the services world appeals to a lot of people. That's more hit-or-miss with products, and certainly more delayed in most cases. If you're good at what you do, you can pretty reliably make decent cash on a contract. If you're selling a product, you can make alarmingly close to zero dollars a month before it catches on (which might be forever).

</comment></comment><comment><USER4> Dealing with clients is all about setting expectations. I really view our contracts as just the expectations codified and hopefully never read again. The key is what the clients actually expect you to deliver. If we ever have to turn to the contract language, we have already lost something in translation.

I won't go over all the articles points; I think it is well written. I am a bit envious that they have a product to transition too. However, I will point out two ways to help small agencies deal with clients. Specifically on how to take payments and whether to accept certain clients. Both of these areas will help alleviate stress in running the business.

1\. Not getting paid. To fix this issue simply demand more up front. We start projects at 75% due. Have done this for 10 years now. Larger contracts, over $15,000, we will start with a 50%, 25%, 25% split. We have never started a project for less than 50% of the entire.

The key is that you never work on collection model. Never send an invoice for work completed. You always are working from your funds you have, so you are never at a loss.

Sure some clients balk at the higher up-front costs, but do you want those clients? Stick to your guns. If a client likes you and your portfolio, they probably will sign even if it means a bit more upfront costs.

2\. Owning your time. We get our fair share of "interesting" clients, but have found a way to weed them out in the sales process. This way we only work with clients that we like and want to help. Key tips that it will be a "interesting" project and you may want to pass:

\- Wanting to change our standard contract. Our contract is a short 1-page that is really fair to both sides. The more they change the harder the project will be, always. Stick to your contract. \- The client needs to start, now, now, now. Basically someone internally has dropped a ball in scheduling and now it is your problem. Charge more to help them or pass on the project. \- Disorganized email chains and hectic meetings. The client won't suddenly become organized during the project, which means you are now their organizer. Have fun with that project if you accept, but charge more for project management.

Anyways, I think going the product route is great for web agencies. But you can make a successful agency model work and have fun, we have for 10 years now.

<comment><USER5> I'd love to know a bit more about what your contract looks like. I've had real problems with getting clients to agree to pay 50% upfront in case I vanish (I'm quite happy to admit mine is a tiny, 3 person, company) and I'm guessing you must have clauses in there to put their mind at ease.

<comment><USER4> For the vanishing issue, I tell clients that:

a) Look at our portfolio and call our existing clients, b) that we do most of our work in the first few weeks of the campaign so it is only fair to pay that high of an amount, and c) I don't want to have to pause the campaign to wait for a check, it just ruins the flow.

I have not really changed our contract in 10 years. It used to just be me and now we have 13 full-time, a few part-time and a few freelancers. So I know it can work and expand the business.

I really think that 50% is needed to start. It helps weed out clients that are hoping to get funds, or get free ideas, once the project gets going. It shows both sides are serious in committing their time and effort.

If you want, I can send you a sample contract. It is US law based, but the ideas are the same for your law. Just fill out one of our contact forms with your email and I can hit you back with the PDF.

<comment><USER5> Thank you - I appreciate it, that's really kind of you.

</comment></comment></comment></comment><comment><USER6> Hell yeah.

I'd never do that kind of stuff on a fixed price contract. I'd rather wash dishes or wait tables. Some of that work can be fun if you do it on a time & materials basis, but there's certainly less of that around.

I've seen a few companies try to move from 'contracting' to 'product sales' and it appears to be a difficult transition.

The problem is that web shops tend to be driven by success at sales and to be undisciplined about business. They find it impossible to make a "to not do" list and stick to it. There's always the old client who's got a crisis that you need take care of, or the new client who's got deep pockets which (you think) will pay for product development.

A few months later there's the inevitable meeting where it turns out that the product is terminally late -- if the software developers have a backbone, they'll point out that they've spent 60% of their time on "legacy" projects so no wonder it's late.

</comment><comment><USER7> Charging by the hour kills the incentive for productivity gains, which generally arise from building internal or external products that help you do things better. It kind of works in fields like law where the delivery has not changed much over the years, but delivering technical services like anything else in the technology business changes very rapidly.

Clients somehow need to be sold the idea that they will get better and cheaper delivery if they accept fixed costs, so that services can be productised, made profitable and improved, rather than buying one off non repeatable time for everything.

We are sort of seeing this as we get an increase in the number of product businesses being started, and so more types of activity are being productised.

<comment><USER8> If anything, charging by the hour not only kills the incentive for productivity gains, but also lowers a designer's productivity.

<comment><USER9> Agree for very well specified projects where the amount of time a project will take can be easily be predicted and so a suitable fixed fee identified.

In an ideal world all projects might look like that but in practice I think there's a chunk which don't. Agreeing fixed fees for these can be a horrible productivity killer because the estimates will tend to be way off and an "it's impossible to do this in the time/ budget allocated so why both trying" mindset can set in which de-motivates everyone working on it.

In this environment I think fixed fee can encourage corner cutting so for me it's about taking projects on a case by case basis and deciding whether fixed fee or time and materials is appropriate based on how predictable the scope and workload will be.

</comment></comment></comment><comment><USER10> Would love to know how many web design company owners are reading this article and thinking "Could I?"

I've run a web design company for 13 years (currently a team of three) and it's tough work. To your friends, you're the guy who can work anywhere and at any time, charge a decent hourly rate, etc. Reality is you're juggling hosting and domain invoices, maintaining decade-old sites, having your designs ruined by weird requests and on it goes. For every gem of a client, there is a difficult project that was tough to foresee or avoid for whatever reason.

My problems are never contract-related (I don't bother with them at all, figuring that if a relationship ever needs to refer to the contract, it's as good as lost) and rarely about being paid (the money gets there eventually). I also don't worry about competition from smallfry (rarely unhappy to lose a job because I'm too expensive). Yet even without such critical issues as legal, billing and competition, it's still a difficult line of work.

Why don't I experiment with products more? Since I am the client, I can't give myself a serious must-hit deadline and that final 10% never gets done. I also get distracted by the next idea before I finish the last one.

</comment><comment><USER11> tl;dr: The work was varied and interesting. We were trading time for money. We feared firing customers for lack of cash flow. There is too much competition, and margins are thin. We failed to expand our market. We took almost any work, so felt we could not control our wider contribution. We started to create a product, but could not stay away from getting paid for our time. Eventually we cut the web design work, as the margins were getting even tighter. Now we have two products, which we are proud of, but don't know if they will make a successful business.

Sounds a little to me like the story of Pyra Labs, and many others that I can't recall.

<comment><USER12> Yeah we're currently trying to do a similar thing with our company except we started in IT Support

</comment></comment><comment><USER13> As someone in the field, I can totally relate to this story. After a while, web design starts to feel like a treadmill. You really have no control of your own destiny and have to constantly rely on a consistent flow of new clients. The better you get, the more expensive are your services. Unfortunately, web design is a commodity so you're constantly being nipped away by cheaper competitors. It feels like a bubble waiting to burst.

The only way out is to create a product that can be packaged and resold to many different clients. This allows you to focus and develop one product, instead of spreading your talent across multiple projects. More importantly, it allows you to control your destiny because you schedule when and how releases happen.

It's farming, versus hunting and gathering.

<comment><USER14> Just want to chime in here with my own experience. I'm sure what you said holds true for you, but for me I find that the better I get, the _less_ I'm being nipped away by cheaper competitors. Perhaps this is because of my specific skillset (I'm a web developer, not a designer -- although it's basically the same setup, same kinds of jobs, same kinds of clients), but I find that as I get better at what I do I gravitate more towards clients that appreciate high-end service and the quality I can provide (as they do me). I've also found that focusing on a smaller technical niche has helped tremendously (that is, getting really good at one platform -- in my case the Concrete5 CMS, but same holds true for people specializing in Wordpress, Drupal, etc.). Yes there are always people willing to do the work for cheap, and a majority of potential clients don't know the difference and will go with them. But finding someone who is good at what they do and communicates well and delivers on what they promise is incredibly difficult, and there are a lot of potential clients out there that understand this.

<comment><USER15> And as you become better in your niche you are likely more efficient than the lower priced competition. I have seen plenty of cases where developers from relatively poor countries are charging far more than I would (and I would still be getting my target rate) for something because they likely have no understanding of what the job requires. In these cases I would likely have to raise my rate (and as a result make a killing) just so I don't look like the crazy cheap guy.

</comment></comment></comment><comment><USER16> The real money in software comes from selling the same thing to as many people as you can. The more customization you have to do, the lower your potential profits are.

At one time I worked for a medium-sized software company in the process of going public. One of the metrics analysts were keen on was the ratio of license revenue to services revenue. The lower that ratio is, the less of a product company you are and the lower your potential (and the crappier your IPO).

If all of your work is custom you're no better off than guy who installs kitchen cabinets for a living, in the sense that every new dollar comes in only as a result of new work. If, for some reason, the customer doesn't pay up you have very little to show for your effort.

</comment><comment><USER17> I'm in the same boat. Started a web design and development firm 12 years ago, became one of the first Rails shops, and now I'm (finally) doing a product company.

About 6 months ago, I had an idea for a product, designed it, and put together the final team in the last 6 weeks. I've leveraged old contacts for customer development, and getting the demo done. Now we're pitching some of the largest VCs and angels in the world. Exhilarating stuff.

Maybe I just needed to find out myself, but there's a whole new energy level for myself, and those around me. I think the feeling of satisfaction has less to do with dealing with insane clients, and more to do with creating something that is my baby, rather than someone else's, though.

</comment><comment><USER18> With some of my clients, I negotiate dual-ownership of the end software in exchange for a lower price. That way, if it is something that looks like it could be monetized as a product, I have the ability to do that.

<comment><USER19> Our standard practice is that all software we build for clients is published as Open Source. This leaves things like templates and configuration out, of course, but still every project grows and improves our toolkit.

</comment></comment><comment> johnx123-up > It's not easy to make a lot of money in web design.

Agreed. Companies like <http://www.cssilize.com/> are difficult to compete. They charge as low as $39 and have instant PMS.

On the other hand, there will be huge demand for mobile app themes.

<comment><USER14> Actually those companies only handle slicing a PSD into HTML/CSS -- this is a very small portion of a "web design" job. There's still spec'ing and estimating and implementing it in a CMS and adding custom functionality and testing it and deploying it, and of course actually designing the thing in the first place :)

<comment><USER20> Agreed. There's also the fundamental problem that directly sliced PSDs create a terrible experience for the user; you can't build smart, responsive web pages that way.

PSDs are good for specs, but not directly converting into the actual end project.

</comment></comment></comment><comment><USER21> It's better to work for yourself as compared to work for someone else. Good choice.

</comment><comment><USER22> I think every developer that wants to go out on their own has the idea to start a consulting company (I did too). I will never do it again because of the reasons listed.

I also had problems getting customers to pay me on time (and some at all). Some realized we weren't a big company and figured we wouldn't have the money to go after them in court.

Customers also loved to completely change the spec halfway through the project and then get angry when we tried to charge them more money.

</comment><comment><USER23> Don't blame these guys at all. I'm just starting out in the web design business and I'm learning that it's quite a demoralizing set. There's little motivation to do well when you essentially bend to the will of your clients. Some are good, but most are not. The result? You lose faith in your work and your trade. Glad to hear another company turned on the light and is working toward doing their own thing. Here's hoping they're successful.

<comment><USER24> "There's little motivation to do well when you essentially bend to the will of your clients."

The motivation is a killer site to put in your portfolio, potential future projects from that client or friends of that client, and certainly tackling new challenges.

And the trick is not to bend to every situation. There are plenty of big companies that respect outside talent. HBO/Target/CNN off the top of my head.

</comment></comment><comment><USER25> The problem for the web design community is that web design has become a commodity.

</comment><comment><USER26> >Clients were my bosses, and we were at the mercy of their whim.

Not sure how I see the difference between this and the phrase you get by substituting "Customers". It's all well and good deciding to be entrepreneurial, but if the shmoes with the $$ don't play along, it's not going to be fun. You're going to have to compromise your ideals to sell product.

To me, a better way of describing the shift from consulting to product development is that you can sell the same development effort multiple times when it's a product. Thus, no matter how well the consultants work, there's an upper limit on their income.

<comment><USER27> Oliver here (I wrote the article, and run Silktide).

It's early days for us, so I can't speak from years of experience, but so far there are marked differences for us:

1\. We have a lot more customers. Before one or two of our web designer clients could hold us ransom over a big cheque - the sort of thing we needed to make payroll. Now we'd need a mass exodus of customers for the same to happen, and usually that would be because _we_ screwed something up (i.e. it's fair).

2\. Customers now have clearer expectations. Web design customers can expect all sort of things which they consider reasonable, and don't understand why they're not (e.g. supporting a website 5 years after you built it, changing their business fundamentally mid project, expecting 'as many designs as it takes' to get right etc). I know you can and should educate your customers, but essentially you're dissatisfying them. With products, generally people pay a fixed amount to use a thing for a time. If it doesn't work, we refund them. Simpler and happier all round.

I totally agree with your last point - if you can scale it pays better. So far, the jury is out on that one for us, but let's see where it goes...

<comment><USER4> Number of customers is critical. When web design studios only have a few customers and one makes up a large percentage of revenue (ex: 10% or more), then you are definitely at the clients whim.

However, if an agency has a lot of customers, each with only a percent or less of total revenue, then its a much more stable platform. You can decline representation of certain clients and they do not effect the total revenue.

Of course, a product line might be better. All customers under one pricing model, customization is limited, and it scales easier. Good stuff.

<comment><USER27> We had a lot of web design customers (about 200) but you can only work on so many projects at a time - we would typically have 30-40 in our pipeline, but only 10 or so would finish each month. And those projects aren't even in size - we'd normally have a couple big ones accounting for over half our income.

So even with 200 customers our income came mostly down to a handful of customers each month.

<comment><USER4> Yeah, it's tough when a few make up a large percent of the business. You definitely have to drop everything to help them. I think our top 50 clients make up 25% of the business. Top 100 about 50% and the other 400 the rest. So we are less beholden to one large client as maintenance, hosting, SEO, PPC, and redesigns help balance all the new projects that we would need to sign.

</comment></comment></comment></comment></comment><comment><USER28> Client work is an excellent way to subsidized research costs. ;-)

</comment><comment><USER29> This blog post sums up exactly why I wouldn't start a web agency.

</comment><comment><USER30> There's one point I don't entirely agree with. Do you have to meet with the client face-to-face? I mean, wouldn't a video call on Skype serve a similar purpose?

You probably would have been able to cater to clients from all over the world through video chat. Or is there something about face-to-face meets that makes your task easier?

<comment><USER10> Many, many clients expect face-to-face meetings. I have clients overseas and interstate (including some I've never met or even spoken to on the phone) but the majority are greatly comforted by meetings. Many have a strong preference for going through things in person as opposed to writing down requirements in an email.

(Have run a web design company for 13 years now.)

</comment></comment><comment><USER31> I completely agree, that's why at 39, Inc. we try to split client work and internal projects 50-50. Of course that eats big time in the potential profits in the short turn but it also can also spin off in something good. SyncPad for example was first a 39's project before we made it into a separate company called Fifth Layer.

</comment><comment><USER32> I particularly like the comment of how service based work is "decent sustenance, but a poor investment".

</comment><comment><USER33> Just to add, 37signals, and SkinnyCorp (Threadless), are two companies that come to mind that started out working for Clients, then pivoted and made their own products and destiny...

More power to them and all that do this.

</comment><comment><USER34> This is something i have wanted to do for sometime and i think after reading this am finally getting some guts

</comment><comment><USER35> totally reminded me of <http://theoatmeal.com/comics/design_hell></comment>


Web naming rules relax, .pg available for $100K - <AUTHOR> http://edition.cnn.com/2008/TECH/06/26/domain.names/?iref=hpmostpop

<comment><USER2> .pg is already owned by Papua New Guinea. Besides, ICANN may reserve all two- letter TLDs for countries.

</comment><comment><USER3> I foresee someone making a killing domain squatting via the .cmo TLD

<comment><USER4> Anagram of .com, i guess. Btw, I find myself so many times struggling to decipher abbreviations mentioned in hacker news, can't you people put a short explanation in parentheses whenever you use a not so well known abbr? (that was on purpose)</comment></comment>


Ask HN: Develop productivity app first for Mac or Windows 10? - <AUTHOR> I want to create a productivity app, which runs in the background, and reminds me to work on my most important tasks, when it thinks that I am not. The goal is to create a Minimal Viable Product which I, and others, find useful. Which of the two platforms has more potential customers? In other words: What is the market share of Mac vs Windows 10 among people who happily try out new productivity apps? My coding skills: I am an experienced backend developer, but have not done a Mac or Windows 10 app yet. I like both OS.<p>1000 thanks for any thoughts or hints. <comment><USER2> I'm an ex-Mac user, and current Windows user. I'd say do Mac first. Mac users are accustomed to and way more likely to pay for apps.

Also, people are way more accustomed to buying apps on the Mac App Store than the Windows App Store, so discovery is definitely going to be an issue if you're going the App Store route.

On the Windows side, I pay for apps, but because prices tend to be higher for useful Windows apps, I tend to not buy as many.

When I was on Mac, I'd drop $10-15 on an app without blinking. For more expensive apps on the App store, it was also an easy decision because a $50 app could be installed on multiple machines.

In general, the useful apps on Windows aren't on the App store don't have the liberal licensing that Mac App store apps do. Because I want to run my stuff on at least two machines (desktop and laptop), and because usually there's some DRM that binds a license to one machine, I am much more hesitant about buying licenses.

<comment><AUTHOR> Thanks a lot for your feedback - eventually, if it is successful, I would launch it for all possible platforms.

So, getting to paying users is not a priority for me at the beginning.

Getting to heavy users definitely is, and discoverability may be better on the Apple App Store I guess, though eventually I would like the product to be so good, that it also gets word-of-mouth attention.

</comment></comment><comment><USER3> I run a bootstrapped desktop productivity software business myself. I'd say the split is somewhere around 70% Windows and 30% Mac (all self-marketing, no app stores). The mobile rush created a huge vacuum in the desktop market that I think enabled people like me to succeed. Not to mention, you're not giving a 30% cut to Apple or Google and can generally charge more than a few dollars for your app.

It's definitely easier for me to develop on Windows. Though, this is mainly because XCode performance is atrocious on my mac mini and packaging apps for outside the app store is pretty tedious. I still use a buggy tool that Apple hides very deeply on their developer portal (it involves installing an ancient version of XCode).

If you require a UI that is pretty heavy, here is my "secret" trick to save time when developing for both Windows and macOS:

1) Buy a basic HTML template online for your app's dashboard.

2) Don't use Electon. Your users WILL notice and complain about performance. Instead, use the native WebBrowser control in .NET for Windows and WebView using macOS to display your UI. Disable right clicking and highlighting using HTML/JS. To the user, it'll feel like any other native app. Add this meta tag to the HTML file to ensure the WebBrowser control knows to use new versions of IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge">

3) Use the built in script calling functions to transfer settings back and forth between the UI and main app in JSON. Do the back end stuff in native code.

4) You can then re-use most of the UI code you wrote to easily port over to macOS. Use the same functions and logic you wrote on Windows to make your Swift functions.

Good luck!

<comment><USER4> _Don 't use Electon. Your users WILL notice and complain about performance._

Is this actually true? Slack and Discord are valued at ~$7B and $2B respectively, and neither have found it necessary to move off their Electron apps. I assume both companies have already evaluated whether Electron's performance impacts their their bottom line, and concluded it does not.

Electron is undoubtedly slower and more resource-intensive than other options, but outside of specific audiences (HN readers) I bet most people won't care.

<comment><USER5> > Electron is undoubtedly slower and more resource-intensive than other > options, but outside of specific audiences (HN readers) I bet most people > won't care.

I think it makes even more of a difference for people outside of the HN audience.

A non-technical person might grab a $400 laptop from Costco with 4gb of RAM which is fairly common.

All it takes are a few Electron apps to exhaust that entire system's resources.

<comment><USER6> But will a non-technical person know which apps are to blame?

<comment><USER5> They will be able to determine "before I installed this app everything was good but now it's not" and then they will proceed to blame your app (with good reason).

</comment></comment></comment></comment></comment><comment><USER7> I would say whichever platform YOU use day to day. You won't know if it's useful unless you are constantly using and refining it.

Id also be careful conflating "I want to build a product" with "I want to build a tool for me". Start with just a tool for you, decide later after it's useful to a user population of 1 if it's valuable to invest in finding a market for.

<comment><AUTHOR> Yes, I totally agree, I would first build it for me and work with it.

Right now I use a Mac, but I have used also Windows in the past, and - if I decided to code in Windows - then would switch all my work to a Windows machine, too.

Everything I do is pretty portable between those two platforms, so I don't have any problems with switching between the two.

</comment></comment><comment><USER8> Let me step back a tad and comment on your use case, i.e. needing to be reminded to work and not procrastinate. I largely solved this problem by adopting the Pomodoro technique. Following it, I subdivide my work time into periods of concentrated work (20mn in my case) and relaxation (3-5mn). This increases my effective work stamina very much, helps with motivation, and has other benefits. Related literature is plentiful.

</comment><comment><USER9> Make a PWA and you cover Windows, Mac, Linux, iOS and Android in one go.

<comment><USER10> Not sure that a PWA would have the scope of insight to know when you are skipping off the important task, e.g. playing solitaire vs coding, reading HN vs testing your app?

</comment></comment><comment><USER11> If it needs native integration, use Electron, if not use a Progressive Web App. If it's got to be native go to macOS. The App Store ecosystem makes it way easier to make sales, and there is an expectation of buying quality apps. If you go the Mac route your design needs to be excellent though.

<comment> un-devmox I'm not that familiar with PWA's, but how do you monetize them if they are not downloaded from the app store?

</comment></comment><comment><USER5> I'd be careful about creating these types of apps because a lot of people (especially developers) value privacy.

What your describing is monitoring everything I do on my computer and then likely transmit it to your site. Even if it didn't transmit anything I would still be reluctant to use it unless it were open source.

To detect whether or not you're working on what you're supposed to be working on, you'll probably end up recording what window is focused every few seconds right? You might want to hack together an auto hotkey script (Windows) to do this. With a bit of AHK knowledge you could probably write a prototype in a day.

<comment><AUTHOR> Wow, AutoHotkey looks cool - maybe it is nice for doing a first prototype.

Yes, I would check the focused windows, but also would take screenshots to evaluate (with OCR/NLP) whether the email you are writing really relates to your todos.

I would not store those data, neither locally, nor transmit them to my servers, as I am very concerned about security (if my servers get hacked, then I don't want to have anything sensitive on them).

<comment><USER12> Privacy issues aside, re: screenshots, that sounds like a lot of work for a MVP esp when most people are quite happy with a better pommodore or similar solutions.

</comment></comment></comment><comment><USER13> Windows has the most market share at ~85% total (Windows 10 is ~54%). If your target is enterprise users, then probably it's Windows but Mac users have been thought of as more willing to spend money on indie software they use.

<comment><AUTHOR> Thanks a lot for the numbers.

Do you have any view on whether those percentages still hold, if you only look at (e.g.) startup employees or freelancers or other customer groups, which may probably like such productivity apps?

</comment></comment><comment><USER14> you can do both with [https://electronjs.org/](https://electronjs.org/)

<comment><USER15> and here comes the discussion about why electron is bad :P

<comment><USER16> In a world where VSCode runs on electron is there even room for this discussion anymore?

<comment><USER17> VSCode is highly optimized and has tons of engineers behind it. If it were me I would do .Net Core and Avalon UI: [http://avaloniaui.net/](http://avaloniaui.net/)

<comment><USER18> Looks like Avalon is in beta. Are there any stable alternatives that are production ready?

</comment></comment></comment></comment></comment><comment><USER19> Obvious dependencies: you need a computer of the relevant type if you're going to go native.

Are you going to sell it as a product? How? Mac store, Windows store, online from your own website, Steam, something else?

How are you going to acquire customers?

What apps are you competing with (hint: there's a lot, on all platforms)?

Which native platform are you most familiar with/want to become familiar with? (Note that Windows has several platforms within it; UWP is the obvious modern choice, but maybe you want a WinForms app)

</comment><comment><USER20> From my own experience I'd consider a development environment that lets you cross-compile. c or c++ work and, old hat though it is, I've had good success writing cross-platform utilities in Lazarus (Object Pascal) and compiling for MacOS, Linux and Windows. The only issues in all cases has been the need for platform-specific libraries to manage GUI components like rich text editing.

</comment><comment><USER21> You have to study your decision depending on your audience/budget/vision/tools, there is really no specific answer to that. Also remember, even cross-platform development has its own disadvantages, and worst decision is at least a "mile" ahead, rather than spending too much time on best solution.

</comment><comment><USER22> I wouldn't rely on anecdata from HN posters, who may or may not be representative of your potential market. Try and gather some data and see what it says, e.g. spend $5 on some facebook ads for your not-yet-existant product, and see the breakdown of OS's that hit your landing page.

<comment><USER2> > I wouldn't rely on anecdata from HN posters, who may or may not be > representative of your potential market.

Well, if the OP gets 100 actual responses (as opposed to secondary discussion posts), then that anecdata actually is data.

Given:

* the nature of the described app

* that its functionality appears to be scratching an itch the OP has

* that the OP is a member here

* the OP asking the question here

..it doesn't seem to be far fetched to think that the posters here are at least somewhat representative of the potential market.

</comment></comment><comment><USER23> Web first. It's cheaper, more people can use it, and you can find product- market fit more efficiently.

<comment><USER24> How are you going to get a web app to run in the background and notify you when it sees you are reading HN instead of churning out code?

<comment><USER25> any solution that I could think of could also be called malware...

</comment></comment></comment><comment><USER26> The market is quite saturated but people in the Apple ecosystem tend to be more likely to pay for apps.

</comment><comment><USER27> Who is the obvious target market in your mind? Is it programmers, artists, musicians, small business people, mega corporate conglomerate employees, millenials, boomers, rich people, North Americans, Europeans, Chinese? The answers to these questions will guide you.

</comment><comment><USER28> Simple, the Mac. Huge bonus of being able to have it on the App Store and sell it for a couple bucks.

<comment><USER24> The App Store is awash with productivity stuff, I'm not sure it's as big a bonus as you think.

<comment><USER2> If I were building a Mac App store app, I wouldn't rely on the App store for discovery. On the other hand, the App Store is easier for handling downloads, updates, purchase transactions and licensing.

If you are doing a Mac App and want people to try your app, it would probably be worth spending the several thousands of dollars it takes to get a sponsored post on a site like Daring Fireball.</comment></comment></comment>


Warning: Good Copy is More Valuable than Design... - <AUTHOR> http://robertwilliams.wpengine.com/warning-startups-need-good-copy-more-then-design/

<comment><USER2> This post echos so much of what I believe could be fixed in the web design community today. Obsession over perfection cannot save your soul, but obsession over message and clarity makes the largest impact for the time invested.

</comment><comment><USER3> Wait, a blog post about good copy... with a misspelled title?

<comment><AUTHOR> april fools

</comment></comment><comment><USER4> Awesome post!</comment>


Let's Encrypt is Trusted - <AUTHOR> https://letsencrypt.org/2015/10/19/lets-encrypt-is-trusted.html <comment><USER2> Being told that you now trust someone with your secrets via a news website is a pleasingly succinct display of everything that's wrong with the CA model.

<comment><USER3> _We're pleased to announce that we've received cross-signatures from IdenTrust_

This is what is wrong with the CA, model, not their method of announcing it to a community anxiously awaiting the arrival of their product. What is absurd is that identrust has a shitty non-responsive 90's looking website and wants $299 for an SSL certificate, which is something that should be free. I will say though, they really did sell me on their trust worthiness with the alternating images of a fingerprint and a lock. So now I know they're legit. It is worth the $99 for SSL on a single site annually because there is binary data superimposed on some of the pictures.

<comment><USER4> I don't think he was saying they acted poorly by announcing on HN, but that he would prefer to grant someone trust rather than have it forced on him before he even knew about it. Not an easy task for a functional web, but it would obviously be better if possible.

<comment><USER5> There's many ways, all obnoxiously complex unless you go back to a CA-ish voluntary trust model.

Keys as addresses (I2P, Tor hidden services, CJDNS) fixes a large part of the security problem, then on top of that you can add your choice of address translation. WoT style individualized trust webs? Trusted lists of name assignments DNS style? First-come first-serve á la Namecoin?

<comment><USER6> Not necessarily. You could also place domain validated trust in the registrars, to cryptographically verify their delegations. That would build a chain of trust which you in turn could use to validate keys for services in those domains.

<comment><USER5> That's the DNSSEC+DANE approach and that's still the same as the DNS approach I listed (trusted name registry lists), except that the address isn't an IP- address (or in other words, your domain's DNS server that says what IP addresses your subdomains have is itself identified by a public key).

</comment></comment></comment></comment></comment></comment><comment><USER7> See a Let's Encrypt cert in action:

[https://helloworld.letsencrypt.org/](https://helloworld.letsencrypt.org/)

Nice work team!

<comment><USER8> I was unable to connect using a vendor-specific browser on an old Android 4 device. Is this a limitation of the LE cert, or a cipher suite issue with older browsers, or something else?

Really looking forward to spreading HTTPS far and wide.

<comment><USER9> Taking a guess from the SSL Labs report[1], that site appears to be using the modern config from Mozilla's toolkit[2], which limits it to browsers from the last few years.

1: [https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.le...](https://www.ssllabs.com/ssltest/analyze.html?d=helloworld.letsencrypt.org) 2: [https://mozilla.github.io/server-side-tls/ssl-config- generat...](https://mozilla.github.io/server-side-tls/ssl-config-generator/)

<comment><USER10> It's also throwing a OSCP error as well as no HSTS/HPKP headers to get to A+ grade.

<comment><USER9> But hey, it's got OCSP stapling!

</comment></comment></comment></comment></comment><comment><USER11> It seems odd to me that the intermediates were cross signed instead of the having the root be cross signed.

With a cross signed root, clients with only the IdenTrust root will validate the cert, and clients with only the LetsEncrypt root can validate the cert.

With a cross signed intermediate, the server has to guess which root the client has and serve the correct path, there's a TLS extension to indicate roots the client supports, but nothing actually uses it, so I don't know how the server is going to guess (other than to assume no one has the LetsEncrypt root, since it's new).

[1] but some clients are dumb and won't validate successfully when they reach a root they know :/ Most browsers will though.

<comment><USER12> This was a performance decision. Cross-signing the root instead of the intermediate would mean that web servers would have to include both the root and the intermediate in the chain they serve, rather than just the intermediate. That would add a full packet to each handshake.

<comment><USER5> Why are there multiple intermediate certs? I don't know the details of the standard procedure.

<comment><USER13> In case the main intermediate cert has been compromised and must be revoked, the alternative intermediate cert is already signed and can be used immediately for desaster recovery.

</comment></comment></comment></comment><comment><USER14> Can anyone who knows more than me say - is this the beginning of the end of the SSL cert selling business? Is there still value to buying an expensive cert from another vendor?

<comment><USER15> Not yet, because Let's Encrypt doesn't provide wildcard certificates as of now. This may change in the near future, though.

Also note that free single domain certificates have been available from StartSSL for a very long time, but this didn't destroy the certificate industry.

<comment><USER16> An argument can be made that Let's Encrypt doesn't need wildcard certificates since new certs can be generated automatically every time a subdomain is added.

<comment><USER17> An interesting usecase of wildcard certs: when I do not want to publish the hostnames I am using. Sandstorm[1] uses unpredictable hostnames as one mitigation against various cross-origin attacks -- if the attacker doesn't know the domain of the app, he can't try to use XSRF against it[2].

[1] [https://sandstorm.io](https://sandstorm.io) [2] [https://docs.sandstorm.io/en/latest/using/security- practices...](https://docs.sandstorm.io/en/latest/using/security- practices/#client-sandboxing)

<comment><USER18> If you are willing to only accept SNI enabled clients (the vast majority nowadays), you can achieve the same by having one cert issued per subdomain, then configuring the web server/reverse proxy to use them.

There are a few existing Nginx configs for that (search for "nginx dynamic ssl cert").

<comment><USER19> I think there are other problems for doing this for Sandstorm. One is the delay when starting to use a new hostname (right now Let's Encrypt might take around 20 seconds to issue a new hostname, which may well increase to the originally-predicted one minute eventually), while another is that all Let's Encrypt certificates are published, so if you really want the hostname to be completely unknown to an attacker, the individual Let's Encrypt certs wouldn't work.

Anyway, Sandstorm developers told me that they wouldn't plan on using Let's Encrypt while it doesn't offer wildcards, so I think we are missing out on supporting this use case.

</comment></comment></comment></comment></comment></comment><comment><USER20> ISRG, the org behind Let's Encrypt, is hiring! -- [https://letsencrypt.org/jobs/](https://letsencrypt.org/jobs/)

</comment><comment><USER21> Can someone who's tried the client confirm if it's possible to get a key/cert out of it without having it mess with my configuration files?

I'd like a manual mode, as years of sysadmin work have made me extremely skeptical of tools that try to automatically modify config files.

<comment><USER13> That was my initial impression, too.

However, as far as I understood, there is an API that will just hand out the certificate.

I guess they don't want it to be accessed by a web browser because they want us to regenerate and include a newer cert automatically.

So you have a somewhat higher setup cost (setup automatic cert update rather than one-time download of your cert), but then you can't forget to update your cert over the years.

I believe they also want this is be a fast desaster recovery. So if their main intermediate certficate is compromised, they can revoke it and hand out new certificates (using the backup intermediate cert) for all domains within a very short amount of time.

Nevertheless, I would have preferred a good explaination about how to setup this process manually, rather then depending solely on their tool.

(In case this process it too cumbersome without their tool, they should simplify it rather than hiding this in their tool.)

</comment></comment><comment><USER22> Yay!

Honestly, it is amazing to me that someone like Google or Amazon did not do this as free service a long time ago. But having an independent entity like this do it is far better.

<comment><USER23> Serious question, to what degree is one defined as being independent? When you have "platinum" sponsors like akamai and cisco, and can take donations through paypal?

<comment><USER22> They are a separate legal entity, with multiple independent sources of funding and a diverse range of board members[1]. I'm not sure about degrees of independence, but I would say this satisfies my criteria. Are you arguing they aren't really independent of their sponsors?

[1] [https://letsencrypt.org/isrg/](https://letsencrypt.org/isrg/)

<comment><USER23> I wasn't arguing anything just asking a question.

But I will say that, without any numbers, its hard for me to say either way. Clearly, RSA was in independent legal entity, but a $x million dollar check didn't stop them from peddling shoddy crypto… though that's not something surprising to hear in this community.

</comment></comment></comment></comment><comment><USER24> The big question:

Does this mean we can now all use Let's Encrypt to generate new certificates without people running into problems?

<comment><USER25> It means certs signed by Let's Encrypt will work just fine for people without any special setup. See [https://helloworld.letsencrypt.org/](https://helloworld.letsencrypt.org/) for an example.

This does _not_ , however, mean that we can all start using Let's Encrypt. They're doing a slow roll-out before making certs generally available to the public. You can apply for the Beta at [https://goo.gl/forms/kf0IGCeAk5](https://goo.gl/forms/kf0IGCeAk5), or wait until general availability later this year.

<comment><USER24> Thanks!

</comment></comment></comment><comment><USER26> Huge win for them - will help push SSL/TLS on everything. Can't overstate how important this is for the web. Now to get the word out to everyone!

edit: initially said SSH. I blame the plane wifi

<comment><USER27> I think you meant SSL/TLS

<comment><USER28> can you sign a cert for SSH? I know that you can add the SSH server public key fingerprint as a DNS record and sign an openSSH certificate with your own private CA but are there any public CAs who will sign SSH certs and would the ssh client even trust anything other than a manually added CA?

<comment><USER29> Yeah - [Open]SSH supports signing for host and user keys, and you can operate your own CA, and the certificates you issue can encode a signed set of permissions/access controls with them (E.g permit-agent-forwarding, permit-X11-forwarding, certificate life times) this functionality is IMHO vastly underutilised.

OpenSSH certificates are not X509 certificates though, and out of the box SSH servers will not trust any public authority.

Also, AFAIK CA cross-signing, intermediates and other things that are fairly commonplace in X509 land are either not supported or not widely supported in OpenSSH.

<comment><USER30> Using the OpenSSH Certificate format, many of the common features from X.509, like intermediates, cross signing, key usage attributes or restricting access based on an attribute in the certificate are not part of the spec:

[https://github.com/openssh/openssh- portable/blob/master/PROT...](https://github.com/openssh/openssh- portable/blob/master/PROTOCOL.certkeys)

When I first learned about OpenSSH Certskeys, I was really excited; Spent awhile trying to make it useful, but you end up building all the CA infrastructure, and this time instead of distributing certificates to servers once a year, you want to distribute certificates to your _users_ every month or two -- so the pain is higher, there is less automation, and everyone on your team feels it....

Exploring OpenSSH certs is what led me to founding ScaleFT. There had to be a better way.

ScaleFT Access leverages these SSH Certificates, but we expire them every 5 minutes to provide other features that are hard with the limited capabilities of the format:

[https://www.scaleft.com/products/access/](https://www.scaleft.com/products/access/)

There are patches to make OpenSSH use X.509, but they are not widely adopted... and asking people to patch a sshd is a non-starter for many environments.

</comment></comment></comment></comment></comment><comment><USER31> "We're pleased to announce that we've received cross-signatures from IdenTrust"

How is this beneficial for IdenTrust?

<comment><USER32> Related discussion: [https://community.letsencrypt.org/t/what-is-the-business- mod...](https://community.letsencrypt.org/t/what-is-the-business-model/310)

It establishes IdenTrust as a more influential leader of SSL certificates on the Web. There are other ways CAs can make money, and this extra publicity will probably serve them well.

<comment><USER33> IdenTrust is an interesting organization. IdenTrust is a bank consortium acting as a public key certificate authority and secure applications provider whose members include over 60 of the largest banks in the world. John Sculley has been IdenTrust's chairman since 2006.

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

</comment></comment></comment><comment><USER34> Are they planning on not relying on a 3rd party root CA and instead, ask all browsers and OS vendors to include LetsEncrypt CA? IOW, is this [trusting IdenTrust] a first step, or is this the original goal?

<comment><USER35> This is a temporary step. There are two versions of their intermediate cert, the one in this article that is cross-signed and another that is signed by their own root (which isn't yet included everywhere). There's a diagram on this page that explains the situation: [https://letsencrypt.org/certificates/](https://letsencrypt.org/certificates/)

</comment></comment><comment><USER36> > and we're excited to be one big step closer to bringing secure connections > to every corner of the Web.

What steps are left now? :-)

<comment><USER32> From what I can tell, they're polishing their CA software (Boulder), and getting the rest of their infrastructure and policies ready for GA.

</comment></comment><comment><USER20> A quick look at all the certificates Let's Encrypt has issued so far can be found using Comodo's CT based crt.sh tool.

[https://crt.sh/?Identity=%25&iCAID=7395](https://crt.sh/?Identity=%25&iCAID=7395)

<comment><USER37> That's surprisingly fewer domains than I expected. No wonder I never received any replies for my application to their beta program.

<comment><USER9> I think the idea was the public beta should wait until the certs are valid everywhere.

</comment></comment></comment><comment><USER38> Delicious irony: my employer's web proxy supplies their own certificate in place of the real one for [https://letsencrypt.org/](https://letsencrypt.org/).

Though, to be honest they do this for >90% of https sites, in my experience.

</comment><comment><USER39> Remember that you only need one of the hundreds of CAs (650 at my last count) to generate you a cert to essentially compromise a site's connection security. Free certs mean more sites will use TLS, which means there will be more targets, which means more incentive to start attacking the weakest CAs and/or their verification practices.

But this is kind of a good thing, because after enough attacks on the old model, people will ask for an improvement or replacement of the model.

<comment><USER40> Thanks to HTTP Public Key Pinning (HPKP), this is no longer a threat:

 _HTTP Public Key Pinning, or HPKP, is a security policy delivered via a HTTP response header much like HSTS and CSP. It allows a host to provide information to a user agent about which cryptographic identities it should accept from the host in the future. This can protect a host website from a security compromise at a Certificate Authority where rogue certificates may be issued for your hostname._

You can read all about it: [https://scotthelme.co.uk/hpkp-http-public-key- pinning/](https://scotthelme.co.uk/hpkp-http-public-key-pinning/)

And here are web-based tools for examining and generating HPKP hashes: [https://report-uri.io/home/tools](https://report-uri.io/home/tools)

<comment><USER39> You don't get to say there is no threat if almost every website today is vulnerable.

First, this is optional software that almost every public server in the world is currently not using. It's like saying just because executable whitelisting exists that downloaded exploit payloads on operating systems is no longer a threat. If nobody uses it, the threat still exists.

In addition to actually implementing it on your server, every single user still has to make a secure initial connection over a trusted network on every device they'll ever use to get to that site.

But not every client even supports HPKP. There's lots of older software which doesn't support it, and IE doesn't support it at all, which by itself would leave 12% of all clients vulnerable.

[https://projects.dm.id.lv/Public-Key- Pins_test](https://projects.dm.id.lv/Public-Key-Pins_test)

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

<comment><USER40> _You don 't get to say there is no threat if almost every website today is vulnerable._

I didn't mean that literally the threat has been eliminated due to HPKP; it's yet another tool that can be used.

 _First, this is optional software that almost every public server in the world is currently not using. It 's like saying just because executable whitelisting exists that downloaded exploit payloads on operating systems is no longer a threat. If nobody uses it, the threat still exists._

HPKP isn't software--just additional HTTP headers that pretty much every web server can be configured to send.

 _In addition to actually implementing it on your server, every single user still has to make a secure initial connection over a trusted network on every device they 'll ever use to get to that site._

True; it's even described in the RFC: [https://tools.ietf.org/html/rfc7469](https://tools.ietf.org/html/rfc7469)

 _Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)_

</comment></comment></comment></comment><comment><USER41> It just _had_ to be right after I renewed my SSL cert, didn't it? :P

<comment><USER42> This is not a spur of the moment announcement. Their timeline has been publicized all over the place

<comment><USER41> It was a joke, I was well aware of the timeline. It hasn't moved to general availability anyway.

</comment></comment></comment><comment><USER43> Chrome says they don't supply Certificate Transparency information. Is this something they should be doing?

<comment><USER20> This is something we entirely plan on doing, in fact we currently submit all issued certificates to a number of CT logs (which can be viewed here [https://crt.sh/?Identity=%25&iCAID=7395](https://crt.sh/?Identity=%25&iCAID=7395)).

Unfortunately the best candidate, at least for us, for supplying SCT receipts to end-users, via x509v3 extensions in OCSP responses, is currently not fully supported in Golang.

</comment></comment><comment><USER44> From a comment on a similar reddit-thread[1]:

> So thus beings the transition. EV certs are going to be the only ones that > get the "green" chrome in browsers anymore. Sites using standard SSL are > going to get the normal no-lock/white treatment. And sites without SSL will > get the caution symbol/yellow treatment.

I don't like it, but I suspect this is where we're heading.

[1] [https://www.reddit.com/r/linux/comments/3pg37u/lets_encrypt_...](https://www.reddit.com/r/linux/comments/3pg37u/lets_encrypt_is_trusted/)

<comment><USER45> _" EV certs are going to be the only ones that get the 'green' chrome in browsers anymore."_

Are there any facts to back up this claim?

Edit: This is what HN looks like in Firefox 38.0.5: [http://img4.imagetitan.com/img4/RsbN6Rsn61k2IMN/12/12_l.png](http://img4.imagetitan.com/img4/RsbN6Rsn61k2IMN/12/12_l.png)

Sure, the background color is white, but there's still a padlock icon.

<comment><USER46> Image not found

<comment><USER45> I don't know what happened there. Try [https://i.imgur.com/cY0Kx6x.png](https://i.imgur.com/cY0Kx6x.png)

</comment></comment></comment></comment><comment><USER47> Am I missing where I can signup? Love to try them.

<comment><USER20> The general availability period hasn't begun yet, but you can still sign up for the beta program here -- [https://docs.google.com/forms/d/15Ucm4A20y2rf9gySCTXD6yoLG6T...](https://docs.google.com/forms/d/15Ucm4A20y2rf9gySCTXD6yoLG6Tba7AwYgglV7CKHmM/viewform?c=0&w=1)

</comment></comment><comment><USER48> This entry has 443 points how and I don't want to upvote to spoil it...

</comment><comment><USER49> Is there an easy way to pull out the cert and load it into an AWS ELB without running the client on the server it will eventually protect? I'm not a big fan of using software that auto changes my config files, plus you can't actually run scripts on ELBs.

<comment><USER50> let's encrypt uses ACME protocol for certificates. You can use your own tools to handle it - either automatically or manually. Their automated client is just a user-friendly wrapper.

</comment></comment><comment><USER32> Congratulations LE team!

Final Star Wars VII trailer and LE gets cross-signed. Best. Day. Ever.

<comment><USER51> I would just like to point out the irony in using 'LE' as a short for Let's Encrypt, as 'LE' usually gets used for shortening Law Enforcement.

(Also: Congratulations and well done, Team Let's Encrypt!)

<comment><USER52> "LE" is identified more with "Limited Edition," I think. At least in the US.

<comment><USER53> I always associate "LE" with "Lawful Evil", but maybe I'm a nerd

</comment></comment></comment></comment><comment><USER54> What does this mean to a new user? Can I now get a ssl certificate? will it be cheaper, or even free? I saw they have a beta-program for the certificate but don't know what it exactly does.

</comment><comment><USER55> I really dislike the fact that a CA is able to bless a new CA completely independently. Does this cause anyone else the slightest amount of anxiety, or am I just being paranoid?

<comment><USER56> Whats the alternative to CA being able to delegate signing? Would you prefer having browsers constantly being updated with new lists of CA's, maybe one new per day.

Second, would you prefer that browsers blessed a new CA completely independently? If not then who should have that power? Governments? Non-profit organizations like ISRG?

The big alternative is to maintain your own list of trusted CA's, going through each and every new CA that you encounter and associate a trust relationship. Not even famous security researchers do this, and I can't really blame them as it is like a lawyer reading every EULA that they encounter and fully investigate the scope of them. The scope and complexity just get beyond what a single person can manage.

<comment><USER55> Yeah, I guess I think it makes more sense for the browser manufacturers to be the people to whom I delegate that responsibility. I already trust them not to run malware on my computer and to accurately display the SSL state of a connection.

I just think it's odd that any CA can turn around and make any other random CA fully blessed. It seems like it completely circumvents the browser manufacturers including root CAs at all.

Totally agreed re: maintaining your own list of CAs. I mostly do go through the system CA list and disabling any from foreign governments I don't ever plan on trusting, but that's mostly feel-good and not actual security.

</comment></comment></comment><comment><USER57> Could somebody clarify: LetsEncrypt allows anybody to create certificate for any domain, so would not that allow anybody to create MITM certificate for any such domain?

<comment><USER58> Look at the tech overview:

[https://letsencrypt.org/howitworks/technology/](https://letsencrypt.org/howitworks/technology/)

You can only obtain a certificate for a domain if you can validate that you control the domain. Their steps for that (place arbitrary content at an arbitrary URL they request, or create an arbitrary DNS record they request) are such that, if you weren't the legitimate controller of the domain but could do those things, you wouldn't need a fake cert -- you'd already have pwned it thoroughly enough to be able to MITM it in other ways.

<comment><USER59> > You can only obtain a certificate for a domain if you can validate that you > control the domain.

Technically, you only have to make their systems _think_ you control the domain. If their servers or 'establish proof of ownership' process are hacked, wouldn't this allow an attacker to do the same thing that happened in the DigiNotar hack?

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

<comment><USER40> This is why HTTP Public Key Pinning was created as a way to tell browsers to trust _only_ a particular certificate, not just any certificate that was signed by a CA in the browser's trust store: [https://news.ycombinator.com/item?id=10418144](https://news.ycombinator.com/item?id=10418144).

<comment><USER57> Another follow up: from your link, looks like the server adds a header specifying which certificates are allowed.

Would not MITM just remove that header?

<comment><USER40> From the RFC: [https://tools.ietf.org/html/rfc7469](https://tools.ietf.org/html/rfc7469)

 _Key pinning is a trust-on-first-use (TOFU) mechanism. The first time a UA connects to a host, it lacks the information necessary to perform Pin Validation; UAs can only apply their normal cryptographic identity validation. (In this document, it is assumed that UAs apply X.509 certificate chain validation in accord with [RFC5280].)

The UA will not be able to detect and thwart a MITM attacking the UA's first connection to the host. (However, the requirement that the MITM provide an X.509 certificate chain that can pass the UA's validation requirements, without error, mitigates this risk somewhat.) Worse, such a MITM can inject its own PKP header into the HTTP stream, and pin the UA to its own keys. To avoid post facto detection, the attacker would have to be in a position to intercept all future requests to the host from that UA.

Thus, key pinning as described in this document is not a perfect defense against MITM attackers capable of passing certificate chain validation procedures -- nothing short of pre-shared keys can be. However, it provides significant value by allowing host operators to limit the number of certification authorities that can vouch for the host's identity, and allows UAs to detect in-process MITM attacks after the initial communication._

</comment></comment></comment></comment></comment></comment><comment><USER60> Is there some web interface to sign my certificate, similar to startssl? I don't really want to run new program in my server just to generate certificate.

<comment><USER5> You could run it on a laptop to get the cert, then install on the server. But right now it remains an invite only beta until they get ready for general availability

</comment></comment><comment><USER61> Has anyone seen anything re IIS integration?

[EDIT] I have seen this: [https://github.com/ebekker/letsencrypt- win](https://github.com/ebekker/letsencrypt-win)

But ideally we would want Microsoft to add a checkbox in the UI of IIS Manager, which when creating a https binding offers to use let's encrypt instead of an installed certificate.

</comment><comment><USER62> I like that statement "community trust"...much the same I have come to trust most of the wisdoms on this site. I for one-learn, and greater, I learn from each of you the value of clarity. So trust as David Abshire says, "Is the coin of the realm, the glue, the oil, (alternative energy-) ingredient."txs, dSnapAp. SFCA.

</comment><comment><USER63> I can't wait for Let's Encrypt to finally start signing certificates. The future of encrypted communications is among us, and it's going to be huge.

Will definitely use this as soon as they open their doors to me.

</comment><comment><USER64> In a mobile only world where your critical business runs only via mobile app do CA based SSLs even matter? Why not use your own CA with your own certificates and don't have to trust any CA?

<comment><USER19> If you're doing TLS solely with your own app, this is often described as a best practice -- avoiding exposure to the public PKI entirely.

Personally, I'm typing this post into a web site using a web browser, so I appreciate that it has a certificate that my browser can validate!

</comment></comment><comment><USER65> Yes, finally. I've been awaiting this moment from the first announcement. Happy they made it (:

</comment><comment><USER66> The next step should be to stop trusting any other CA, and have Let's Encrypt support EV certificates by working with other CAs and still requiring Let's Encrypt DV verification.

This way, Let's Encrypt in particular would need to be breached for a successful attack, while right now it's enough to breach either Let's Encrypt or any other CA.

</comment><comment><USER67> Congratulations jdkasten!

</comment><comment><USER68> So… we're all still waiting for the client, right?

<comment><USER69> No, they have announced their launch schedule in the past. Here is the latest update: [https://letsencrypt.org/2015/08/07/updated-lets-encrypt- laun...](https://letsencrypt.org/2015/08/07/updated-lets-encrypt-launch- schedule.html)

<comment><USER68> But we _are_ waiting for the client, no? If I understand correctly, the client will enable us to install Let's Encrypt's certificate on our web server. I assume, "general availability" is when the client will become available for everyone.

<comment><USER69> The source for the client is here: [https://github.com/letsencrypt/letsencrypt](https://github.com/letsencrypt/letsencrypt)

However, their release schedule dictates when the service (yes, the client is part of this) is ready for use.

Until then you are waiting for the service to be available.

</comment></comment></comment></comment><comment><USER70> So, it's still all about trust then? I thought Let's Encrypt would go beyond trust.

<comment><USER71> What do you mean?

</comment></comment><comment><USER72> I'm all for native desktop and mobile applications, but in this case I'd actually love a web app - enter your domain, get certificate.

Downloading a tool, reading man page, works out of the box only with apache/nginx - ehhh, seems like a lot of work, considering some comments touting 'user friendliness' compared to StartSSL.

<comment><USER5> But you need to run _something_ on the server to validate that you've got control of it on your domain. A web app isn't enough.

The better solution is to integrate this tool into various server tools like Apache and Wordpress and in whatever else you might be running with a one- click installer.

</comment></comment><comment><USER73> Er... you're trusted by a CA that's owned by a company that resides in Austin Texas...

Texas hasn't exactly got a glowing reputation in the software industry due to its mountain of intellectual property lawsuits filed by patent trolls... er, sorry, I mean non-practicing entities

Excuse me while I reserve some skepticism about just how trusted your security certificates should be.

<comment><USER74> Absolutely pointless and irrelevant. This is the same logic that Donald Trump uses to dismiss all Mexican people as rapists.

<comment><USER73> Except that the courts are used there time and again to strong arm well meaning companies into paying millions out to fight frivolous lawsuits that run them into the ground. Exactly the kind of tactic you'd expect intelligence agencies to use to strong arm encryption companies into giving up their data.

</comment></comment></comment><comment><USER75> ./letsencrypt-auto Updating letsencrypt and virtual environment dependencies.....Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-KgdEvk/ConfigArgParse

<comment><USER45> HN is not a support forum. Please look here instead: [https://community.letsencrypt.org/t/welcome-to-lets- encrypt-...](https://community.letsencrypt.org/t/welcome-to-lets-encrypt- community-support/8)

</comment></comment><comment><USER76> This will still require early stage overhead for many people switching over / 'going dark all the things'. Even though Let's Encrypt's goal is to make the process of encrypting the Transport Layer seamless, ubiquitous and non- commercial.

Take for example my setup. It sits on a private NGINX server, and is proxied through a public facing CDN. Trying to simply 'switch on' TLS involves absorbing academic style tutorials from multiple disparate sources, and requires me to have a background in DevOps and that I have at least tried some technical task like this before. In layman's terms: Unnecessary Early Stage Overhead.

Now give Let's Encrypt a few more years and it will be a lot more seamless; possibly the default. It could possibly be 'baked in' to things like Softaculous, and cPanel, which are brilliant drivers for the success of web software. Digital Ocean staff are probably already working on a droplet with LetsEncrypt baked in...

<comment><USER24> I don't see how TLS is early stage overhead for someone runnig a private nginx server behind a CDN?

Sure, someone with no devops skills at all will have a _harder_ time, but it's for the better. Soon it will be The Way to install a webserver. Thanks to Let's Encrypt it's so easy to install TLS that nearly every future webserver tutorial will include it.

</comment></comment><comment><USER77> Why python for the client software if you obviously already have Go experience in-house? Using python means you have to run all this virtual-env crap in a bash script, apt-get install a bunch of crap for setup and not support Windows. Seems like using a (nearly) dependency-free Go application for the client as well would have been a no brainer. Was it just a case of having more access to python devs, or were there other technical reasons? Anyone know? I bet this has been asked before, but not I'm turning anything up with google.

<comment><USER32> I can't speak for them obviously, but here's a Go ACME client if you're looking for one: [https://github.com/xenolf/lego](https://github.com/xenolf/lego) \- we're using it in Caddy[1] to make HTTPS the default for websites.

[1]: [https://github.com/mholt/caddy/commits/letsencrypt](https://github.com/mholt/caddy/commits/letsencrypt)

<comment><USER77> Wow, that's awesome. Nice work integrating this into caddy.

Although, it makes me even more confused as to why they used python for the official client.

</comment></comment></comment><comment><USER78> The headline is wrong and not very clever for such a project.

The project was able to get a CA to sign their keys, this is what happened. Using the word "trust" is simply wrong and might be interpreted as a too simple kind of propaganda after we learned a lot about the untrustable nature of a hierarchical certification infrastructure.

Another, even bigger trust-breaking elephant in the room is the fact that this project is USA based - as long as US government and agencies are insisting on practices we know from authoritarian and anti-democratic states like e.g. China or Saudi-Arabia there is no way any US based project can use the word "trust" for their product description - it might be recognized as a simple lie by informed people.

Questions to the project leaders:

* you must obey US laws and therefore offer MITM access to every Let's-Encrypt "trusted" network stream - why aren't you educating your users about this serious limitation of your product?

* why don't you rebase your project to a country where a government policy exists that is allowing companies to build trustable security based products?

<comment><USER19> There is no U.S. law that compels us to "offer MITM access to every Let's Encrypt trusted network stream".

TLS sessions are negotiated between TLS clients and servers. Their confidentiality is guaranteed by that negotiation and the certificate authority, if any, doesn't have the server's private key and can't read the server's TLS sessions.

What CAs have the power to do is misissue certificates. Using a CA's services generally does _not_ increase your exposure to misissuance attacks by that CA. If Let's Encrypt misissues certificates, it could misissue them for sites that are not and never have been Let's Encrypt users, just as any other CA can issue certificates for any public Internet service.

As I've said elsewhere, Let's Encrypt wants to use, and encourage others to use, technologies that limit our power to do the wrong thing, including HPKP and Certificate Transparency. We want more limits on our power and other CAs' power, not fewer, that lead to misissuance events getting caught and attacks on TLS users failing.

</comment></comment><comment><USER79> I truly appreciate the hard work Let's Encrypt is doing.

However, this is not free.

In return for getting an SSL certificate, your users will need to trust an organization to protect the secrets they share with you and vice versa. This organization has no economic incentive to do good for you or to do harm to you.

What happens when this organization is compelled by the TLA to give up the lucky charms, and there is no team of attorneys to fight back, and no billions at stake, and there is a gag order? And, given the rate at which a "free" SSL certificate will proliferate, these will be some valuable lucky charms.

This is not FUD. This is simply recognizing that "free" SSL certificates don't really address the issues that arise from centralized authority in a decentralized economy.

<comment><USER80> I personally argued with the W3C TAG against an HTTPS-only web for this reason. Tim Berners Lee, who heads the TAG, ceremonially speaking, argued against it, too, but on different ground. The browser vendor 'experts' on the TAG totally dismissed any and all argument against forcing everyone to use HTTPS. They were basically told by their employers (the big browser vendors and CDNs like Akamai) to make it happen. HTTPS is a rather costly false sense of security. Now anyone who wants to setup a website, for whatever reason, has to go thru some central authority in the name of "securing the web" (LOL) but it's just another way to control free speech and what people do with the web.

<comment><USER74> >Now anyone who wants to setup a website, for whatever reason, has to go thru some central authority

Which 99% of people already do when the buy a domain name.

There is NO evidence that using SSL restricts your freedom of speech. There is evidence to the contrary though, where SSL allowed people to speak freely without having their communications intercepted or monitored.

Certificate Authorities only reject websites for certificates in rare cases where the domain bears resemblance to a well known company (such as "paaypal.com" or "microsoftproducts.com"). This is not something that every CA does not something that a CA HAS to do.

There is no "false" sense of security HTTPS IS encrypted, and CA signed certificates ARE authenticated. Claims that the whole CA system is MiTM by government are largely unsupported, and if you believe that, then you are screwed over HTTP anyway.

I dont disagree that there are some disadvantages to an HTTPS-only web, but those generalizations are wrong.

<comment><USER80> "HTTPS IS encrypted"

Oh wow. Really? You haven't done your homework then. So many ways to undermine the certificate authority model, including many famous cases, one involving the Iranian government gaining access to their citizen's "encrypted" traffic. HTTPs is about having traffic be open to powerful entities and closed off to the common criminal. It's a two tier model, not real security.</comment></comment></comment></comment>


What is the best book on "Software as a Service (SaaS) - <AUTHOR>

Kindly suggest a good book on the SaaS subject - something that has good notes on the basics. <comment><USER2> Software as a Service is just a buzzword.

Software used to be something you buy for a lot of money in a physical package.

Software as a Service is sold by license for less money over a specific period of time and used over the web.

<comment><AUTHOR> So does a free email service like Gmail qualify as SaaS?

<comment><USER2> Certainly, but nobody really uses the term for such services. Salesforce.com likes to call itself SaaS because it distinguishes itself from Siebel, Oracle, and other big enterprise software co's that sell similar services using the old product model.

But it doesn't really mean much outside of the enterprise space. The whole web is SaaS. =)</comment></comment></comment>


Pointing Fingers in Apple Pay Fraud - <AUTHOR> http://www.nytimes.com/2015/03/17/business/banks-find-fraud-abounds-in-apple-pay.html <comment><USER2> TL;DR:

Apple wanted getting on Apple Pay to be as easy as possible. Banks decided supporting Apple Pay was more important than being able to implement good fraud protection. Banks now have to deal with a magnitude higher fraud rates.

<comment><USER3> Are these particularly high fraud rates for NFC transactions, though? Or online transactions? Or even telephone (as in reading one's card number out loud) transactions?

I would imagine that anything abstracting the physical card away ends up with a significantly higher fraud rate, but the only numbers we're given are for Apple Pay specifically and for all credit card transactions in total.

<comment><USER4> Regular NFC(Visa PayWave/Mastercard PayPass) are limited to a certain amount per transaction(25 pounds in UK, not sure how much in US), and you can only do 5 until it asks for your PIN. So there is simply very little incentive to be stealing NFC data for those systems,because you can't use it to steal high- value items. With Apple Pay, you can pay for anything, and there is pretty much no verification. You can use any card number to purchase items in stores,so there is nothing stopping you from using a stolen card to walk out of Wallmart with a $1000 TV.

<comment><USER5> Interesting. In Australia, I think the limit is $50 (which is about the same in pounds) but there's no entering your PIN number every 5 transactions.

This is in the country that has the highest adoption of contactless payments.

<comment><USER6> Last I checked the limit was now $100, or could be different per provider. I have been asked for my pin on some occasions, mainly when doing a large transaction (IIRC).

</comment></comment></comment></comment></comment><comment><USER7> I can't believe that buying a device for several hundred dollars, signing up for a cellular contract, entering a stolen credit card number, and then tricking a customer service rep is supposedly easier than just swiping a card with a fake magnetic strip?

Shouldn't it be trivial for Apple to block devices with fraudulent transactions from using Apple Pay?

<comment><USER8> You don't need a cellular contract - and the simcard is presumably stolen as well or a pre-pay account created under a fake name.

<comment><USER5> You don't even need an active sim card to activate a phone. As long as there's a sim card in the tray, the iPhone will activate.

</comment></comment></comment><comment><USER9> This all certainly makes for an interesting case study in security tradeoffs.

I wonder if the numbers cited in the article about the rates of "traditional" credit card fraud (said to be 0.1%) include the massive costs borne by retailers, banks, and customers after the Target and Home Depot breaches and other similar compromises, scenarios that Apple Pay was well-designed to prevent.

Of course, the 6% Apple Pay fraud rate is also magnified by the fact that the fraudsters of course took to this new system far far faster than regular consumers. Once more retailers and banks support Apple Pay, the relative proportion of fraud will drop. In the next two years as most Americans replace their existing Android and iOS phones with ones capable of low-friction NFC payments and awareness increases, the use of this technology will likely take off.

Ultimately it sounds like best practice for individuals is to use a new credit card for Apple Pay, and not one that you ever use online or particularly in restaurants.

<comment><USER10> I don't see how you arrive at your "best practice" advice, given the information in the article. How would it address the problem in any way?

<comment><USER9> _smacks forehead_ You're right, it wouldn't. Nevermind. :)

</comment></comment></comment><comment><USER11> I think Apple is getting too much slack. They made it way to easy to add a new credit card.

<comment><USER12> Some Credit Card issuing banks actually went through verification process when a card was aadded to Apple Pay. For example, a colleague added her United Airlines MileagePlus Club Card. She had to verify her identity before the card was approved for Apple Pay.

Meanwhile, another credit card issuing bank which shall remain unnamed, did not go through the verification process when the card was added to Apple Pay.

<comment><USER13> why would it be un-named? are you employed by them or something? It would be nice to know who has no verification more than anything.

<comment><USER12> No, I am not employed by any financial institutions.

At that time my colleague added her Wells Fargo card to Apple Pay and it went through without any notifications from the bank. She has been using this card with iTunes store though.

Another colleague added her F&A Federal Credit Union card and went through with little notifications.

First National Bank of Omaha notifies the email address on file that that the card is added to Apple Pay.

US Bank actually sends a letter via mail that the card was added to Apple Pay.

This could change by now.

</comment></comment></comment></comment><comment><USER14> The lesson is the same: Apple doesn't partner with other companies. Large as a bank wanting to cash in on Apple pay or small as a developer in their garage panning for a bonanza in the app store, it's Apple's ball and bat and wickets. Even if Real Madrid and Manchester United show up, Ronaldo and Rooney are getting innings not stoppage time.

<comment><USER15> Like many disruptors, Apple isn't offering a 100% complete business and technological model for their partners. They're offering a new way of thinking about traditional services and a family of integrated computing products with which to deploy those services.

The business partners can't just expect to do nothing to be a part of a game- changing service. They'll need to adapt their technologies, business models, expectations, etc.

<comment><USER14> Cricket is hardly disruptive. Apple's market position allows it forgo B2B relationships based on the goal of mutual success.

<comment><USER15> What is Cricket? I googled "apple cricket" and nothing interesting came up. I'm not sure what point you're trying to make.

<comment><USER14> May I suggest reading my top comment beyond the first sentence now?

<comment><USER15> Oh, sorry, that latter sentence of your original post made absolutely no sense to me. First time through, I had even read it several times but figured it was some obscure sport reference and I just stuck with stuck with my contention of your statement that 'Apple doesn't partner with other companies'.

<comment><USER14> It is good to see that kind of go getter attitude. I wish more people would argue against things they don't understand.

<comment><USER15> It wasn't my fault that your statement was easy to refute.

After that, I just chalked the poorly-worded obscure sport reference up to poor communication skills.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> kind of interesting that fraud is about 0.1% of revenue. Kind of says a lot about the margins behind being a payment processor.

<comment><USER17> Fraud rate is 0.1% Fraud rate of Apple Pay is 6% that is 600 times higher. The NYT places the Banks at a higher fault because they should know better. I place blame on the strong arm tactics that Apple uses on every deal they make.

<comment><USER15> In this thread there are two accounts describing how some banks require extra verification before their cards can be added to Apple Pay... and sombe banks don't.

Apparently, Apple gave the banks the hooks they needed to eliminate the type of fraud the article describes but they didn't do it.

How is this Apple's fault?

<comment><USER17> To quote someone that the article links to: [http://www.droplabs.co/?p=1231](http://www.droplabs.co/?p=1231)

"Isn't this a Bank problem? And don't that absolve Apple and Networks of their responsibility in this?

"It is unconscionable that Apple did not, and was not strongly advised by its partners – to make the Yellow Path implementation (by an issuer) mandatory sooner than it did – which was 4 weeks before AP launch. "

<comment><USER15> "unconscionable" that banks should be expected to understand security well enough to know that not using any verification was stupid?

It was mandatory 4 weeks before the launch, so it's been 6 months since then... and yet we're seeing how banks haven't bothered to fix it?

I think Apple could have said something sooner, but in order to throw the word "unconscionable" around, I think that they would have to have done something deliberate or secretive.

I view that 90% of this rests directly on the banks' shoulders for not implementing good security in the first place, then sitting on not implementing it for months.

</comment></comment></comment></comment></comment><comment><USER18> In a new edition of our recurring series: "Apple sacrifices shit for usability", we will explore why Apple fucked up security once again.

<comment><USER19> Did they, though?

I have two cards in Apple Pay, a Capital One credit card and a Wells Fargo debit card. When I added my Capital One card I was asked to log into their mobile app to verify the card. This seems highly secure. Someone may have my stolen credit card details, but they're not going to have my banking passwords (if they did, I'd have bigger things to worry about).

Wells Fargo didn't even offer that as an option. They had me ring up a call center. Apple provided secure ways to verify identity, but only one of my two banks seems to have been bothered to implement them.

</comment></comment><comment><USER20> Owner of several Apple products. I never cared for the idea of Apple pay for one reason. I did not need one more touch point to deal with. People claim Apple pay simplifies buying but I am of the opinion I don't want any more people with that access to my credit information than I already have.

Yeah it might be able to provide a layer of anonymity that Paypal does for online purchases but I still end up with a service authorized to use my card.

What I do want and some CC services can provide is instant messaging of when the card is charged.

<comment><USER21> You seem to fail to recognize that every time you make a payment with your credit card, you create "one more touch point to deal with" \- every shady taxi driver, every hole in the wall restaurant, every employee making $5/hour who just started that day - you are handing your credit card information (and cvv) to them. And, if they ask for ID, there is a non-zero chance that you are giving them your billing information as well.

The value to users of Apple Pay, is that all disappears. They don't get anything useful, you never give them your credit card information, and the token they do get, is only good for that purchase.

Apple pay is a _huge_ leap forward in security, _for the card holder_ \- not necessarily for the banks though, if they don't actually verify that the number going into the phone is owned by the cardholder.</comment></comment>


Getting into freelance web design - <AUTHOR>

It seems that there is a large amount of freelance web designers / developers out there. Looking at various sites such as cssbeauty, almost every other website is from either a freelance web designer or from some sort of an agency.
Does it make any sense to get into that market if your skills are not "top of the line"? Are there any designers out there working in some specific niches?
Would like to hear your comments. <comment><USER2> If you can do design, but also understand how to optimize that design with things like google web optimizer you will be on your way to having a niche.

Beautiful graphic design is only half (or less) the battle. Many people also cannot afford a designer with 10 years of experience and a great portfolio.

Take a look around some of the best web apps, and many of them aren't 'pretty' but they are well designed. I'd even put basecamp in that lot. You can use simpler designs to your advantage.</comment>


Ask YC: DDOS Protection? - <AUTHOR>

Some friends of mine have been running into an issue with massive DDOS attacks, primarily massive junk UDP traffic.
Right now, they're shunning IP ranges as fast as we can, but things change quickly, and often at night.
I saw the discussion at  http://news.ycombinator.com/item?id=106020 , which took place just under a year ago, but I'd love any advice.
I know that there are companies such as prolexic and Gigenet can offer substantial improvements, if I understand correctly, by re-routing our traffic through them, and then on to us.
Are there any companies that HN readers have worked with? What sort of pricing were you hit with? One quote I found online had suggested $400/Mbps/month.
Are there any programmatic solutions to maintaining a shun list? I could script something to blindly telnet in, but it seems like there's got to be boxed solutions for this.
The problem with most inspection techniques is by the time we accept the packet and start examining it, it's too late, and we start to get overloaded.
Any advice would be appreciated. <comment><USER2> If you are running Linux then iptables (netfilter) can be your friend. Look into the --limit option.

The banning can be made automatically with a script like <http://deflate.medialayer.com/>

Also they should be able to talk to the hosting company / data center; they may be able to provide the service filtering the DoD traffic right there.</comment>


A look back to an inspiring 2013 - <AUTHOR>

Hi all,
We've put together 12 inspiring quotes and videos that have occurred this year. We hope you enjoy them, and you find some inspiration that helps you for when you enter 2014.
http://www.getinspired365.com/year2013 <comment><AUTHOR> clicky [http://www.getinspired365.com/year2013](http://www.getinspired365.com/year2013)</comment>


8 Months in Mozilla - <AUTHOR> http://nickdesaulniers.github.io/blog/2013/06/13/8-months-in-mozilla/

<comment><USER2> My experience was something in between Microsoft and Mozilla, we never just hacked to get things done, but we neither were allowed to contribute back to the OS community.</comment>


Google's quantum computer performs a calculation which takes supercomp 10k years - <AUTHOR> https://theweek.com/speedreads/873779/google-says-quantum-computer-performed-calculation-that-take-supercomputer-10000-years <comment><USER2> Or two and a half days, depending on whom you ask...</comment>


Who has heard of container homes? What do you think of them? - <AUTHOR>

<comment><USER2> Homes constructed from standardized shipping containers make a lot of sense on a lot of levels. First, size and spec are standardized. Second, construction is rugged. Third, the size of most containers lends itself to multiple- container configurations and thus to design flexibility. Fourth, they last a long time if maintained. There are a number of excellent web-based resources available through a simple search.

<comment><AUTHOR> Thanks for the input Don. People love these homes!

</comment></comment><comment><USER3> some turn out really nice :)

couple bad features IMO:

        - sometimes painted with toxic paint
        - have to insulate anyway
        - have to frame the interior walls with wood and then drywall tape & paint anyway
        - have to weld them together
        - worse energy efficiency than concrete (IMO)
        - can be hard to find

IMO the 9 - 10' ceilings are cool though, and the 40' length is really great.

I'm still leaning towards concrete -- With a simple roof one end higher than the other. Concrete and tile seems to be insanely efficient to keep cool in hot weather. I'd love to use ICF but it seems to just add 10k to the price without any other benefits that I can save 10K by doing the work myself.

these look really cool also: [http://www.homedepot.com/p/SmartBlock- Twenty-8-in-Insulated-...](http://www.homedepot.com/p/SmartBlock-Twenty-8-in- Insulated-Concrete-Forms-12VWF8/203012855)

<comment><AUTHOR> Thanks MC,

Couple quick adjustments:

\- Toxic paint is mitigated through encapsulation with spray foam insulation, or proper paint coating.

\- Wood studs are not the best way, steel studs are the way to go. Further, because the furring is not structural, you can go 24" wide versus 16".

\- Raw containers are cheap and easy to find. Just ask Craig.

The main advantage of containers is their modular capabilities. Produced entirely off site and delivered to client in completed form. Concrete must be site built, which is not a scalable.

People are really more into the aesthetic than anything.

Good points MC, thanks for the comment.</comment></comment>


Is Transactional Programming Actually Easier? - <AUTHOR> http://lambda-the-ultimate.org/node/4070

<comment><USER2> the most interesting aspect of the article (to me at least) was the discrepancy about the _perceived_ ease of locks and the _actual_ rate of error while using them.

wonder if something similar would / could be observed while using message- passing (a la go / erlang) vs implicit or explicit locking...</comment>


Tell HN: HN Houston Meetup - Thurs Dec 20 - <AUTHOR>

Howdy, Texans.
Just trying to meet some like minded Houston folk who want to get together and nerd out about startups and interesting stuff.
Thursday, Dec 20. Kelvin Arms in Rice Village.
Looking forward to meeting other fellow HNers.
http://www.meetup.com/Hacker-News-Houston-TX-Meetup/events/94404072/ <comment><USER2> YC alum here -- in Houston for the holidays, I might be able to swing by.

</comment><comment><USER3> There we go! I'm on board.

</comment><comment><USER4> Looking forward to it!</comment>


European Parliament Blocks Copyright Reform With 113% Voter Turnout - <AUTHOR> http://falkvinge.net/2012/03/14/european-parliament-blocks-copyright-reform-with-113-voter-turnout/

<comment><USER2> Some references, JURI is a committee from the European parliament. JURI is about the legal review of potentially new EU law (directives), it's a kind of legal advisor for the European parliament.

They had indeed the 1st March a vote about a draft report concerning "Permitted uses of orphan works".

[http://www.europarl.europa.eu/document/activities/cont/20120...](http://www.europarl.europa.eu/document/activities/cont/201202/20120229ATT39528/20120229ATT39528EN.pdf)

Now if we look in Oeil (the database of all the legal document status in the EU instutions):

[http://www.europarl.europa.eu/oeil/popups/ficheprocedure.do?...](http://www.europarl.europa.eu/oeil/popups/ficheprocedure.do?id=591723)

The proposal will go in 1st reading at the parliament.

You can find back the final amended version by JURI:

[http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//...](http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//NONSGML+COMPARL+PE-472.338+01+DOC+PDF+V0//EN&language=EN)

The vote took place the 1st March 2012 at JURI (cf. Oeil) but I can't see the result mentioned in the blog post.

</comment><comment><USER3> Unrelated to the topic, but my _god_ what a incredibly fucking unusable site. I don't how what kind of javascript bullshit is going on in the background, but it froze firefox for a good 30 seconds. (Core i7, 2 gigs of ram)

Edit: Tried it in Chrome with the network tab open. 267 requests, 2.43 mb transfered, loaded in 23 seconds. Something like 40 of those are javascript files. Then 8 font files.

For a news story! What madman wrote this?

<comment><USER4> This madman, and Pingdom (tools.pingdom.com) says the page loads in 2.5 seconds, clocking it in at about the median of pages. I load it it in 4-5 seconds even on my _Android_. What rig are you using that could conceivably make it 6 times slower than an Android pad?

<comment><USER5> I was running this on my iPhone 4S. Outside over wireless; waited 30 seconds on a full 5 bars and just gave up.

Not meaning to be offensive at all, maybe it is because of my location (Japan)?

<comment><USER6> iPhone 4S here; def some cray JS on that page.

</comment></comment></comment></comment><comment><USER7> Welcome to Russia with love

</comment><comment><USER8> Wow. A sensational posting without any evidence yet.</comment>


EBay Builds A Retail Transformer - <AUTHOR> http://images.fastcompany.com/magazine/157/infographic/ebay-builds-a-retail-transformer.html

<comment><USER2> OP is linking to an infographic for some reason. Source article is at [http://www.fastcompany.com/magazine/157/jack-abraham-ebay- mi...](http://www.fastcompany.com/magazine/157/jack-abraham-ebay-milo) dated July 22, 2011</comment>