Chrome 68 will mark all HTTP sites as "not secure" - <AUTHOR> https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html <comment><USER2> The people who are pushing back against HTTPS really bug me to be honest. They say silly things like "I don't care if people see most of my web traffic like when I'm browsing memes."

That presumes that the ONLY goal of HTTPS is to hide the information transferred. However, you have to recognize the fact that you run JITed code from these sites. And we have active examples of third parties (ISPs, WiFi providers) inject code into your web traffic. When browsing the web with HTTP you are downloading remote code, JITing it, and running it on every site you visit if you aren't 100% noscript with no HTTP exceptions. You have no way of knowing where that code actually came from.

Now consider that things like Meltdown and Spectre have JavaScript PoCs. How is this controversial?

<comment><USER3> My primary concern are local servers ‒ which of course, are irrelevant if you are a centralised service provider such as Google.

To provide some context, I'm currently working on a web application where the server is intended to be running inside a home network (where the server requires zero configuration by the user). As of now, some of the JS APIs I'm using are only available if the site is running in a secure context, so the server _has_ to serve the application using HTTPS, otherwise some functionality won't be available. However, it is impossible to obtain a valid TLS certificate for this local connection -- I don't even know the hostname of my server, and IP based certificates aren't a thing. So basically, to get a "green lock symbol" in the browser, the server would have to generate a random CA and get the user to install it, which comes with its own severe security risks and is not an option.

So my current plan is to have a dual-stack HTTP/HTTPS server, which on first startup generates a random, self-issued certificate. When the server is first accessed using HTTP, the client automatically tries to obtain some resources via HTTPS. If this succeeds, the user is redirected to the HTTPS variant. If it fails due to a certificate error, the user is presented with a friendly screen telling her that upon clicking "next" an ugly error message will appear, and that this is totally fine. Oh, and here's how to permanently store an exception in your browser.

Still, the app will forever be marked as insecure. Although it isn't. It is trivial for the user to verify that the connection _is_ secure by comparing the certificate fingerprint with that displayed by the server program she just started.

This sucks. It just seems that Google and co don't care about people running their own decentralised infrastructure; and marking your own local servers as "insecure" does definitively not help.

<comment><USER4> You also could stop misusing the browser as an application frontend, and write a proper frontend with a cross-platform toolkit, and distribute that.

I don't understand why developers so often choose the browser as a frontend. Are there better rationales besides having at least some frontend for tyrant- controlled devices like iOS'es, and just using the skills one already has?

For the first, just tell the people to get proper devices.

Because of the second, I see schooling efforts for JavaScript by the tech giants so negatively. It leads to masses of people using JavaScript where it shouldn't be.

<comment><USER5> > just tell the people to get proper devices

That seems like a great way to have no users.

An incredibly obvious reason would be that it is the largest application delivery platform with the highest level of user familiarity and comfort.

If you compare two services where one of them offers you a direct login to the app and the other offers you a 200MB download, most people will choose to log in to a website. It's a better user experience. Especially for things that will see infrequent use.

<comment><USER4> If you _only_ care about the number of users, then I see a point. However, at least for non-commercial programs, why care at all about the number of users?

The scenario you are drawing is not a proper comparison. There is no reason why a native toolkit couldn't support rendering the program before it's fully loaded, so I see no reason a native program would need more data transfer upfront than a JavaScript one. Though I think too that being prompted to download the program, then install it and find the way to run it can be cumbersome, but the solution to this is to not do it this way. Why not integrate with the native way to obtain applications and make it transparent and convenient for the user?

After all, I think there might be fundamentally different goals when developing a software, and that explains the difference. If one has accepted advertisement-based financing of projects, then them and I would probably disagree in many ways. I think users devices must only and exclusively work for the user.

</comment></comment></comment></comment></comment><comment><USER6> As long as this is just a non-obnoxious warning that translates http to something in plain English I can sort of live with it. But as soon as browsers start to inject security warnings, this is going to be very, very bad.

Our company manufactures devices for use in labs and industrial processes. They need complex user interfaces and there is a push to move to HTTP, HTML and JS to implement them with the device as the web server. The devices are usually installed in a controlled, isolated internal networks.

Our clients run these devices for a long time. 20 or 30 years are not unheard of. They also do not update them if there is no malfunction (they work and our clients love it that way).

Now how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years?

<comment><USER7> _how the hell do we create a webserver that will work reliably for the next 30 years if we have to embed SSL certificates with built-in expiration dates in the range of 1 to 3 years_

If there's a requirement that your code needs to run for 30 years without an update then current web technology is probably the wrong choice.

<comment><USER8> Sadly it's more of a 'wrong' requirement from the customer. Today's entreprise customers expect things to Just Work. They say 'just sell us a goddam appliance, we'll point a browser at it and we'll call it a day!'. I'm quoting real customers' documents here: 'it's should be as easy as Apple'. We've done it to ourselves.

<comment><USER9> I expect things to just work and I expect them to work for a reasonable lifespan. I often think that a piece of software ought to live as long as a car, and for something commercially created (e.g. costs as much as a house) then it ought to last at least a generation (30years).

I don't think I'm being unreasonable here. In a closed system this should be doable.

edit: one of the reasons I think this is because we are supposed to be engineers, and other engineering disciplines do it (and their disciplines involve computes too). Consider jets and boats.

<comment><USER10> Jets, boats, and cars all require regular servicing. Parts need fixing and updating and it isn't one and done. The allegory isn't exactly the same as software updates but the allegory of software systems to cars isn't exact either.

<comment><USER6> Our devices do not normally need servicing. They do age, but this is compensated.

</comment></comment></comment></comment></comment></comment><comment><USER11> I'm glad this is happening, although I'm more excited for the day when they start very obviously marking password input fields as "NOT SECURE" when they are used on HTTP sites. Although I am genuinely surprised how much Google and others like Mozilla have had to drag many site owners kicking and screaming into HTTPS. I never would have imagined that end-to-end encryption by default would be consitered "controversial".

Also, those HTTPS numbers are amazing!

* Over 68% of Chrome traffic on both Android and Windows is now protected

* Over 78% of Chrome traffic on both Chrome OS and Mac is now protected

* 81 of the top 100 sites on the web use HTTPS by default

<comment><USER12> Required maintenance for a simple, static http site: none.

Required maintenance for a simple, static https site: configure let's encrypt and keep the cron job running.

Big difference? Not for some, but it sure is something that offers very little value for very many site owners. Even the top 100 sites are only at 80% https by default, and they do it for a living!

<comment><USER13> If you are running your own webserver even a static simple site has required maintenance. You need to keep the server and OS patched. So adding a letsencrypt cron job is not any worse than configuring something like Debian's unattended-upgrades.

But I don't think most site owners should be doing even that much. They should just pay for static hosting, which is cheap and ensures somebody else will keep the server, os, and cert all safe.

<comment><USER14> I added https to my static site last year and it has been a huge waste of time.

ubuntu + nginx worked fine for years without much maintenance, but I've spent so much time reconfiguring things when something breaks (and it is really clear when something a renewal fails... thanks HSTS).

Things that used to be simple, like putting setting up a subdomain (need to get a new cert and reconfigure the cron job now) or pointing at a websocket (can't point directly at node since that's not secure, needs to pass through nginx now) consistently take hours to do now.

I mostly do data analysis and front end work; mucking around in nginx config files is something I would have been happy never experiencing. It sucks that it's harder to host your own website now.

[https://pastebin.com/N2sbvULA](https://pastebin.com/N2sbvULA)

<comment><USER15> I have nginx fronting around 15 different (very low traffic) websites (most static, a few python), all of which have Let's Encrypt certs. The required additions to the nginx conf were minimal and easy. Adding a new subdomain is trivial. Fetching the initial certificate from Let's Encrypt is a short, easy command line. And "sudo certbot renew; sudo /etc/init.d/nginx reload" in a cron job keeps the certs up to date (the "renew" command is smart enough to go through the list of certs you have and renew them all).

It's really hard to imagine it getting much easier.

<comment><USER16> Try `certbot renew --post-hook "/etc/init.d/nginx reload`, which will only reload nginx if at least one certificate changed :).

</comment></comment></comment></comment></comment></comment><comment><USER17> Fine, as long as they don't eventually make it difficult or impossible to ignore the warnings (as they've done with SSL sites with invalid certs). I have numerous devices with web interfaces that are 100% internal to my network and not reachable from the open Internet, but Chrome still refuses to let me access them (side note: thanks, Firefox, for respecting my decision as a user!). I can envision a near future where Chrome treats HTTP sites the same way.

<comment><USER18> Can you self-sign a certificate from the internal server and install it as trusted on the work computers? Or does Chrome only trust certificates that Google trusts?

<comment><USER19> Not sure about Chrome, but you can absolutely install a local CA into Firefox.

<comment><USER20> You definitely can in Chrome. Tons of corporations need the ability to trust their internal PKI.

</comment></comment></comment></comment><comment><USER21> One small annoyance/drawback with everything moving to https: I travel a fair bit, and hotel wifi usually relies on users connecting to their AP and then using a DNS-based redirect to send the user to the login page. That only happens when on http, as https sites which are redirected get the MITM warning from the browser. I used to be able to just type in "google.com" in the address bar and be redirected accordingly; nowadays I struggle to remember a site I use which isn't https. Looking up the gateway address is kind of a pain too.

<comment><USER22> [http://neverssl.com/](http://neverssl.com/)

<comment> racer-v I use the neverssl.com trick and I worry: if browsers stop supporting plan HTTP, doesn't it mean this won't work anymore?

<comment><USER23> No, worst case you'll see a security warning. Or chrome will add an exception for such a site. This is a well known problem that I'm sure will be addressed. But with the current state of the web (~20% unencrypted) it's not really an issue yet.

<comment><USER24> If it were addressed in a way that would break captive portals forever, so much the better.

</comment></comment></comment></comment></comment><comment><USER25> This _totally sucks_ for web based services and sites which don't have a (user friendly) chance to use HTTPS.

Think of LAN only IoT devices which aren't proxy through a external company site, have no domain, are accessed through (local area network IP) and maybe run in non internet environment.

I wish there was a solution for web based encryption for this application domain and browser vendors start to think out of their internet only box. ... same goes for service workers.

<comment><USER26> Unfortunately, this is a problem that will never go away, no matter how slowly and gracefully we transition. There is no alternative that allows these devices to continue to operate without friction that doesn't _also_ enable current device manufacturers to kick the can down the road by releasing new HTTP-only devices.

If we want to keep making the web a safer place, these kinds of cutoffs have to happen. Infinite backward compatibility simply holds everyone back for the sake of decreasingly-relevant devices and irresponsible manufacturers of new hardware and the customers who purchase their products.

The sooner we get to universal HTTPS the better.

<comment><USER27> so the solution to the warning is to make your offline IoT devices secure, but how do you actually do that? i have an IoT product that runs a web server and needs to be accessible by users when the internet connection isn't available. how do I enable HTTPS on it? (this is not a hypothetical. it's a problem i actually need to solve)

as far as i can tell, my options are:

\- install a self-signed cert on the device and force my users to click through all the warnings chrome throws up about untrusted certs

\- create my own CA cert and sign the cert with that, and convince the user to install my CA cert as a trusted cert (which is not possible on iOS)

\- get a cert signed by a trusted authority, and get the user to add an entry to their /etc/hosts file that maps the domain the cert is valid for whatever address the device is assigned

\- distrubute a native (electron?) app that interfaces with my device and trusts my cert, and disallow direct browser access.

\- find some sketchy SSL issuer who is willing to issue certs for *.local domains and run an mDNS resolver on my device

\- Use HTTP instead of HTTPS and the only downside is a little badge in the address bar saying "not secure"

I'd love to have HTTPS everywhere, but i honestly don't know how to make it happen.

<comment><USER28> > \- distrubute a native (electron?) app that interfaces with my device and > trusts my cert, and disallow direct browser access.

This is the most secure choice, using something like websockets to transfer data only.

Unless your product is completely offline and _never_ connected to the internet, I don't think an IoT device that runs a web server is ever a good idea. All it takes is one successful remote attack, and soon your users could be installing ransomware at the device's direction!

Don't serve HTML/JS from a device that you can't physically pull the plug on.

<comment><USER29> > Don't serve HTML/JS from a device that you can't physically pull the plug > on.

Or virtually pull the plug, in the case of cloud hosted sites.

</comment></comment></comment></comment></comment><comment><USER30> Terrible news.

So much work for so many people to update so many old websites that will see absolutely zero benefit from serving content via ssl.

I have an old travel blogging site with a few hundred thousand posts in read only mode. Thinking about how much work it was to upgrade my other sites to https, chase down and work around every http request in the code base, purchase and install certs for silly things like cloudfront that you wouldn't think would suck away two days of your life.

I'll probably just let the site die in July. It doesn't make money, so it's going to be a tough decision whether to dump thousands of dollars of otherwise billable time into upgrading it to accommodate google's silly whim.

<comment><USER31> It makes me a bit sad to hear you are distressed from this news. Would you like some help setting up SSL? We could go over Certbot & Let's Encrypt, as well as provide some advice on things like HSTS, Mixed Content, etc...

My email address is in my profile. I'm happy to help you however I can. I may not be able to make any code-level changes, but there may not be much work that needs to be done.

Edit: I just saw your comment [https://news.ycombinator.com/item?id=16338576](https://news.ycombinator.com/item?id=16338576) \-- I understand there's potentially a lot of one-time work, but it could be done very gradually, and with this announcement, I think CDNs and widget makers would adopt SSL as well. Once the site does support SSL, you can make SSL-related upgrades (like disabling old ciphers or protocol versions) without much disruption.

<comment><USER32> Let's encrypt doesn't really work for all hosting solutions. So a lot of sites still have to purchase an expensive cert.

<comment><USER31> Could you help me understand scenarios where Let's Encrypt and CloudFlare SSL won't suffice? They have, e.g. added wildcard support now, so that's another angle covered.

<comment><USER32> I have sites on Azure and I could add CloudFlare SSL, but it's some work to make that happen and I will have to do it now for all my static sites that absolutely do not need TLS (no forms, no cookies, no javascript).

Or else I have to pay for a cert, a cert is still like $10-$20 per year, per site so that is a lot of money if you have a lot of static sites compared to what the site costs to host (which is near-to-nothing).

And for other shared hosting solutions I'm not really sure if it's possible to implement CloudFlare SSL (I have never implemented it so I'm not really sure what's required)? Why I don't want Cloudflare is because that is adding a third party just because google said I must or I will get punished for it.

<comment><USER31> Hopefully Azure will implement some solution to provide SSL for free. I suspect with this announcement, free SSL may get more attention on hosting providers. There's already several tickets open on the Azure feedback website: [https://feedback.azure.com/forums/170024-additional- services...](https://feedback.azure.com/forums/170024-additional- services/suggestions/16957756-add-integration-with-let-s-encrypt) \-- this problem may go away mostly by itself if it continues to get easier every year.

Google isn't making you do anything, merely notifying users that the connection to your website is not secure.

<comment><USER32> Yes it may, but it can still take a lot of time before it's one click. These tickets have existed since Let's Encrypt was released.

Well they are indirect forcing me through their domination over the web, which I don't like.

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> Firefox will eventually follow up as well:

"To continue to promote the use of HTTPS and properly convey the risks to users, Firefox will eventually display the struck-through lock icon for all pages that don't use HTTPS, to make clear that they are not secure." [1]

[1] [https://blog.mozilla.org/security/2017/01/20/communicating-t...](https://blog.mozilla.org/security/2017/01/20/communicating- the-dangers-of-non-secure-http/)

</comment><comment><USER34> > Over 68% of Chrome traffic on both Android and Windows is now protected

> Over 78% of Chrome traffic on both Chrome OS and Mac is now protected

This is an interesting way to report HTTPS usage.

Why are Android and Windows grouped together and why are Chrome OS and Mac OS grouped together?

<comment><USER35> claiming 68% of traffic is https is far different from claiming 68% of sites are https too

I suspect the vast majority of sites are still not https, but the big sites are which skews that number

<comment><USER36> That's ok but what the OP was getting at is the strange OS grouping.

</comment></comment></comment><comment><USER37> I predict "Not secure" will lose meaning for many people. There's just too many non-https websites. Traffic is not a relevant metric for this. Tell me how many of the websites that a user visits are http.

It's easy:

sqlite3 places.sqlite 'select url from moz_places' | cut -d / -f 1,3 | sort | uniq | cut -d : -f 1 | sort | uniq -c

       4915 http
       4227 https

<comment><USER38> According to Google's own statistics, even Android users now spend 70% of their time on HTTPS sites: [https://transparencyreport.google.com/https/overview](https://transparencyreport.google.com/https/overview)

For Windows users, it's more like 80%, and 85% for Mac users. And those numbers went up ~10% over just the last year.

<comment><USER37> That matches my personal numbers for page views too, but TLS is site specific and not page specific, and it is deployed on small minority of websites on the internet (20-25% of top 1mil.), so my point still holds.

I may spend 80% of my time (whatever that means) on a few HTTPS websites, but I also spend 20% of my time browsing much larger proportion of non-https websites.

So the warning will be popping out a lot and will soon become a thing to ignore.

</comment></comment></comment><comment><USER39> It's very simple: with HTTP, ISPs can see your traffic and direct target ads to you. If everything is under HTTPS, they will need to resort to Google for ads since almost everyone uses Google Search Engine and it's products.

<comment> cup-of-tea Yep. This is about Google maintaining their monopoly on your data and nothing else.

</comment></comment><comment><USER40> If I understand correctly, Chrome shows that "Secure" label on sites using HTTPS.

What bothers me is that non technical users will start to trust the same "Secure" label.

On phishing, what stops someone from registering a shady domain and securing it w/ Lets Encrypt?

<comment><USER41> Chrome should have 3 levels of security.

* HTTP (Red Box and Complaining)

* HTTPS w/ Let's Encrypt (No compliants, but no true secure lock.)

* HTTPS w/ a paid certificate (True magical green box)

In fact I think this should apply to all browsers. This might not deal with all of the issues, but it would be a good start. Feel free to point out where I'm wrong.

<comment><USER42> What makes Let's Encrypt less secure than a paid certificate? Or do you mean EV certs for the "magical green box"?

<comment><USER20> Even EV certs don't really matter. Case in point: [https://stripe.ian.sh/](https://stripe.ian.sh/)

Let's Encrypt isn't the problem here. Expecting all CAs to properly verify what is and isn't a phishing website is unreasonable IMO. It just won't happen. Smaller CAs have hundreds of thousands of certs... it's just not possible.

The real issue is that a cert only says "Your communication between this site is encrypted, and you're speaking to the owner of this certificate" (Assuming it hadn't been compromised.) Certs don't make any guarantee that the person you are talking to is a good guy, nor that they aren't trying to trick you into giving your password to them.

</comment></comment></comment></comment><comment><USER43> Predicting a noticeable bump in Cloudflare users around July when people need a quick way to make their sites "secure"

<comment><USER44> Thankfully this is an option, and one we may have to take for our clients hosted with companies that do not make this process easy (or cheap)

</comment></comment><comment><USER45> It occurs to me that Google has some incentive to do this. Ad blocking is much more difficult with https and requires an ordinary user inject a certificate of dubious origin/security.

<comment><USER46> > Ad blocking is much more difficult with https and requires an ordinary user > inject a certificate of dubious origin/security.

What do you mean? I can see how this might apply if you're trying to MITM your https requests and ad block them that way, but a browser (or its plugin) can simply choose not to display an element on the page without doing that.. right?

<comment><USER47> On Android, since 8.0, users can not override the CAs that applications use anymore.

With SSL everywhere, you can't use a VPN to intercept anymore, as you can't get your own CA into the truststore.

This means ad blocking in apps is now impossible.

Okay, because everyone just downvotes this without reason, here's Google's official Android Dev blog stating exactly the same I just did: [https://android-developers.googleblog.com/2016/07/changes- to...](https://android-developers.googleblog.com/2016/07/changes-to-trusted- certificate.html)

<comment><USER46> Um, you can still import custom SSL certs into Android 8.0's trust store. I do this for connecting to my OpenVPN instance.

<comment><USER47> You can import into the User CA store, not into the system CA store.

Since 8.0 these are separate, apps have to explicitly opt in to using user CA certs as well.

For example, Google's News app doesn't, and as result you can't ad block on the articles it shows.

<comment><USER46> I see. Thanks for the clarification.

</comment></comment></comment></comment></comment></comment><comment><USER48> Now that we're done conflating encryption with certificates and cheapened the meaning of certificate trust, what are we going to use to establish which entity actually controls the domain name we are pointed to?

</comment><comment><USER49> Generally I hate these warnings because they are extremely stubborn while not really telling the user what could fix the problem. They also don't explain why the error might show up today when everything was fine yesterday.

I'd much prefer a message like: "There is no way to verify that this site really is who it claims to be (possibly due to an expiration date, as sites must periodically renew their validations). The owner of the real site can resolve this error by using certification services such as LetsEncrypt. A secure connection is not possible until the site renews its validation.".

<comment><USER50> The user in this case is a random web browser piloted by a non-technical person. It doesn't make any sense to try to arm them with technical solutions to the problem; that's the site owner's job.

<comment><USER22> I foresee site owners complaining, and then this bit of history being repeated: [https://arstechnica.com/information- technology/2017/03/firef...](https://arstechnica.com/information- technology/2017/03/firefox-gets-complaint-for-labeling-unencrypted-login-page- insecure/)

<comment><USER31> What I find really interesting is the website in question, oilandgasinternational.com, now has SSL on by default now; it'll redirect you from any page if accessed over HTTP. Given that, perhaps we should just let them complain? It seems to raise awareness over the need for SSL.

</comment></comment></comment></comment><comment><USER51> Ironically, the thing stopping me moving my website to HTTPS is Google themselves!

There is no clear and unambiguous way to move my website from HTTP to HTTPS without GUARANTEEING that my search index rankings will not fall in the Google search index. This is because Google treat the HTTP and HTTPS versions of the same resource as separate pages.

Until they fix this, I'm sticking with HTTP. A drop in our search rankings would be a catastrophe.

<comment><USER52> Couldn't you have both, and wait till the https version starts to approach parity with the original? I'm imagining google would favor https over http in ranking, so over time it should rise

<comment><USER51> 2 separate pages with the same content is penalised by Google. They are quite clear about that. I will switch on HTTPS tomorrow if Google make it so that a protocol change does not affect search indexing. My business depends on this. Do a Google search and see all the people whose websites have been demolished by dropping out of the Google rankings after implementing HTTPS. Absurd!

<comment><USER53> There are a few well documented methods to counter that penalty: [https://support.google.com/webmasters/answer/139066?hl=en](https://support.google.com/webmasters/answer/139066?hl=en). The easiest method is probably to configure your webserver to start sending 'rel=canonical' in a Link HTTP header, but it can also be done with a meta- tag.

</comment></comment></comment></comment><comment><USER54> Note that Chrome already describes HTTP sites as "not secure", this change just makes it more prominent.

If you click the little circled "i" on any HTTP site, it shows this messsage:

> Your connection to this site is not secure

> You should not enter any sensitive information on this site (for example, > passwords or credit cards), because it could be stolen by attackers.

</comment><comment><USER55> While were at it: why not define a new Javascript with just the "Good Parts" and then refuse to run old Javascript?

<comment><USER56> In a way, that's already happening with wasm. I can't wait for a major language VM to be compiled to WASM and hosted on a common CDN (so it's likely to be cached). It's not such a pipe dream to imagine running high performance Python 3 or Java without the overhead of asm.js on the interpreter, but with the ease of running old fashioned JS.

</comment></comment><comment><USER57> This will reduce the diversity of information exchanged, as does ranking secure sites higher in search results. Privacy and security are worthy goals, but I do feel for those who are attempting to publish free information on personally run sites. The easiest thing to do is put Cloudflare in front of them which also has other benefits.

<comment><USER57> Downvoted without comment. I suppose certain topics on HN are only accepted to have a one-sided view.

</comment></comment><comment><USER58> I have only ever made internal web apps that don't live on the internet. Where do I begin for an idiot's guide to switching to HTTPS? I want the shortest path to switching nginx over and getting an SSL cert. I think that's all I need to worry about?

<comment><USER59> [https://www.digitalocean.com/community/tutorials/how-to- secu...](https://www.digitalocean.com/community/tutorials/how-to-secure-nginx- with-let-s-encrypt-on-ubuntu-16-04)

This is the easiest tutorial I've found. It's 99% copy/paste with sane defaults.

<comment><USER58> Wonderful! Thank you for taking the time to share.

</comment></comment></comment><comment><USER60> Probably will be a very unpopular opinion, but while I appreciate that HTTPS encrypts traffic, I do think a mandatory HTTPS usage comes with a cost, not so much mentioned in this thread. Here's what I think:

I think the mandatory usage of HTTPS centralizes the already centralized web even further. HTTPS itself is secure theoretically, but at the same time it relies on:

1\. Trust in browser vendors: Basically the way HTTPS works currently is that all browsers have "trusted certificate sources" hardcoded. And there aren't that many browsers out there with meaningful market share--Chrome, Firefox, Edge, Safari, and that's about it (One may even say it's pretty much Chrome all the way, with rest of them trailing far back)

2\. Trust in the certificate authorities: The way HTTPS works relies on "trusted certificate sources", like verisign. This was already way too centralized, but it will become even more so. I'm guessing eventually companies like Google or Apple will start acting as generic certificate authorities (as a verisign competitor) unless regulators cut in.

If you think about the implication of all this, the more we move towards an "HTTPS first world", the more power these entities will have and the more damage it will cause when one of them gets compromised.

Note that the web has never been forced to use HTTPS throughout its entire history, so we have no idea how this will play out and I'm just speculating based on my knowledge. HTTPS itself is secure, but as a lot of you know, most dangerous hacks come not from exploiting tech flaws, but by exploiting the weakest link in the value chain--the human factor. And when things become this centralized, the "human factor risk" becomes larger and larger. We have never before had a world where HTTPS was forced, so it's not easy to just visualize this or predict what will happen, but I can imagine there can be many ways the "The entire web can go down one day" because of the extreme centralization, and when I say "the entire web" I mean it literally. One day, some hacker will take advantage of the extremely centralized landscape of the web and probably be able to compromise the ENTIRE web, and you won't be able to browse the web all day, until Apple, Mozilla, or Google releases a security update. This will be way worse than what we've experienced with S3 going down, because it will obsolete security measures of ALL web browsers in one fell swoop.

Another thing I don't like about this "forced HTTPS" is that mandatory HTTPS makes it difficult to publish stuff to the web. You must either deploy your own Letsencrypt to run your website, or if it's too much of a hassle (which would be the case for most people, even developers), just run your website on a service provider that already has HTTPS.

This means people will rather publish their blogs on sites like medium.com rather than running their own wordpress server, or even a ghost blog.

And when this happens, where do you think people will flock to? Most people will flock to platforms that are most stable and have high reputation, such as Google, Facebook, etc., which will centralize the web even further.

I may sound like a tin foil hat conspiracy theory guy but I just wanted to share my thought since everyone seems to think "You must be fucking crazy moron to think that there can be some drawbacks with a forced HTTPS future". Google does have every interest to move the web this direction because they already own the "centralized web", and the more centralized it becomes the more they benefit.

Just to reiterate, I do think HTTPS is great, and user privacy should be respected. I am just providing an alternative opinion.

<comment><USER61> You trust browser vendors pretty hard already since you're routing ALL of your information through them.

> probably be able to compromise the ENTIRE web

I don't buy it. HTTPS reduces what you can do, not increase it. At most it can give a false sense of security but that's about it.

<comment><USER60> > You trust browser vendors pretty hard already since you're routing ALL of > your information through them.

Yes, but just because we already do doesn't mean I shouldn't have rights to hate the reality even more.

> I don't buy it. HTTPS reduces what you can do, not increase it. At most it > can give a false sense of security but that's about it.

That's true. I wasn't arguing about what HTTPS can or cannot do, I was arguing about how HTTPS is centralized. No matter how safe a piece of technology is, the attack vector increases the more it gets centralized. I've never been a fan of the reality we live in--where the core protocol is elegantly decentralized yet we still end up with a centralized trust to be safe.

I think it's ridiculous that every existing website in the world needs to have a certificate authorized by a small number of entities.

Also another point I'm making is that people look at this move by Google and think "wow Google is really advancing the web!" but don't see their motivation behind it.

1\. Google owns the "open web".

2\. Enforcing HTTPS will make sure things become more centralized, which will make it easier for google to keep controlling the "open web".

3\. Google profits.

I know this sounds like a conspiracy theory, but I'm just stating the facts. I can't think of any other scenario when HTTPS gets more and more traction. It's important to distinguish this problem from the actual problem HTTPS is solving, because I do think HTTPS itself is great.

</comment></comment></comment><comment><USER62> I can see GoDaddy now rubbing their hands with glee as they ponder the prospect of selling overpriced server certificates to unaware website owners. No way they'll push a Let's Encrypt solution.

<comment><USER44> This. I already have clients purchasing SSL certificates from GoDaddy due to their aggressive FUD-marketing. To make matters even worse, GD does not in any way assist in the installation, or "activated" of the SSL cert.

<comment><USER63> I just checked GoDaddy's prices, out of curiosity. "Plans starting at $59.99/yr". For comparison, you can get a Comodo PositiveSSL cert for about $10/yr.

</comment></comment></comment><comment><USER64> What is the modern simple and cheap way to set up a static HTTPS site with a custom domain? With HTTP this was doable with S3 for pennies a month; is S3+CloudFlare now the current price leader?

<comment><USER64> Replying to myself. It's distressing how many of the options assume command line competence.

It used to be that graphic designers, photographers, families, etc. could set up a simple site with a shared host, an FTP client, and a bit of HTML. Now requiring HTTPS will push this further out of reach.

This content is now funneled into either managed platforms, either free ones that monetize it (Medium, Flickr, Facebook, etc.) or more expensive higher- touch services (SquareSpace, Wix, etc). The de-democratization of the web continues.

<comment><USER65> Whatever company offering you FTP access and hosting those files for you over HTTP should be setting up HTTPS for you automatically without any extra input from you. That's why all the instructions assume command-line competence: designers are not the target audience; sys-admins are.

If your host hasn't caught up with the times yet it's very straight-forward to get this for free (along with other benefits) from cloudflare with a few clicks.

This is misinformed FUD.

</comment></comment></comment><comment><USER66> Is there a good reason to require https for localhost?

<comment><USER67> Yes: the browser is not in control of resolving "localhost" to 127.0.0.1, nor is it in control of resolving 127.0.0.1 to the loopback interface. These are details the OS is in charge of, not the browser. So the browser can't know that [http://localhost/](http://localhost/) is "secure".

</comment></comment><comment><USER68> Looks like defamation to me. Just because a website doesn't have https doesn't mean it not secure. It's not secure for some activities, and if the browser marks the whole page as not secure, it's defamation.

I don't care if the web would be better with all site having https. Chrome is saying something defamatory about websites without https.

</comment><comment><USER32> I do not like this. I host a website on my dads shop which is not TLS-secured. Why? It's just a one page static site with some info about his store.

There is simply no need to encrypt that. I do not store cookies or host any fishy javascript.

Now I basically have to buy a certificate for that small site that has like 60 visitors a week? Not really nice.

</comment><comment><USER69> This is going to be interesting. I believe instead of pushing everyone to use https this will cause an average user to start ignoring the security warning. I see the security warning as a way to reflect what's insecure and not a catalyst to move to more secure methods.

</comment><comment><USER70> Maybe Android Chrome could be worked on to not poop the bed quite so thoroughly when faced with a captive portal, then, if they're trying to get everybody onto https. Because the interaction between https, Android, and captive portals is just not a good scene.

</comment><comment><USER71> As long as it doesn't break local development again like their forcing of https on *.dev even when locally hostfiled. Funny enough they suggest using .test which is fine, except you cant use .test as a callback url when setting up googles oauth... fail!

</comment><comment><USER72> > and it unlocks performance improvements

I thought https added performance overhead, where does it improve it?

<comment><USER22> Nope.

[http://www.httpvshttps.com](http://www.httpvshttps.com)

[https://www.httpvshttps.com](https://www.httpvshttps.com)

See also: [https://istlsfastyet.com](https://istlsfastyet.com)

<comment><USER50> This is a pretty bogus comparison; it's HTTP/2 versus HTTP/1.1.

<comment><USER22> It's HTTP/2 over TLS versus HTTP/1.1 without TLS.

<comment><USER50> Yes. The performance benefit isn't really TLS.

<comment><USER22> Given that "currently no browser supports HTTP/2 unencrypted" they're inseparable in the real world.

[https://http2.github.io/faq/#does-http2-require- encryption](https://http2.github.io/faq/#does-http2-require-encryption)

<comment><USER50> Right, but enabling TLS on an HTTP/1.1 site isn't going to generate that performance improvement. It's a bogus comparison.

<comment><USER22> Oh, I see what you mean. The relationship doesn't work both ways, and the benchmark might lead one to believe it does.

<comment><USER73> So it's a http2 vs http1 benchmark. Not a http vs https benchmark?

<comment><USER22> Right. HTTP/2 is only available with TLS, due to browser policies, so it necessarily requires TLS.

This means you need HTTPS if you want the performance wins of HTTP/2.

This doesn't mean that HTTPS is a performance win if you're still using HTTP/1.1. However, the "performance overhead" for TLS is negligible in practice.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER73> I don't understand what is insecure about [http://example.com](http://example.com)? It's a simple static site which does not allow user input.

<comment><USER74> I'll assume you intended to write 'insecure'.

I'd say the main issue is that anyone between you and that website can inject scripts into the site in order to phish/ exploit you.

<comment><USER73> That's not a security issue if the site doesn't ask for user input, though.

<comment><USER38> Since the other examples don't appear to have convinced you, how about this one: [https://samy.pl/poisontap/](https://samy.pl/poisontap/)

Visit a single HTTP page while that's plugged in and it'll trigger an exploit that siphons all non-secure-flagged cookies off of every popular site that doesn't use HSTS (including the config pages of insecure routers on your LAN), and installs a persistent backdoor in them so the attacker can continue accessing data on those sites even after you're no longer being MITM'd. And that's not even using any zero-days; it's just exploiting the inherent vulnerabilities in non-secure HTTP.

(Note that while the site I linked talks about a USB device the same attack can be carried out by any MITM, like a WiFi router or upstream ISP; it's not exclusive to local attackers.)

<comment><USER6> Wait. This is a DHCP exploit on steroids. The MITM stuff is just possible because operating systems accept bonkers DHCP replies.

<comment><USER38> Yeah, the DHCP trick is what allows this particular method of conducting MITM via USB.

All the stuff it does _after_ becoming a MITM though are things that any MITM could do, regardless of how they became a MITM in the first place. (ARP spoofing, operating or compromising a Wi-Fi access point, etc.)

</comment></comment></comment></comment></comment></comment><comment><USER75> Maybe someone could answer this for me, this discussion made me curious:

I have an old (2005) Mac, and my fav browser on it can't show https sites at all 90%+ of the time - "Cannot Load, Secure Connection Failed". (like the usual https sites linked to in HN stories) But it works fine with some https sites, e.g. github https, youtube, this page.

What is it about those 'working' https sites that makes them different? Hopefully that's enough info to answer that.

<comment><USER76> Probably because they support older SSL/TLS versions and/or cryptographic ciphers.

<comment><USER75> Ohh thanks guys. Yeah, I had a vague feeling my SSL (whatever that is) was outdated. So those sites just are more backwards-compatible. (Although github isn't backwards-compatible enough to actually make an account. I tried.)

</comment></comment></comment><comment><USER77> How about I just give Google an SSH cert for my router and then they can proactively monitor my entire network to make sure I'm not being MITM'ed.

</comment><comment><USER77> In ten years: "To further protect our passengers, Alphabet OS cars will no longer be manually navigable down unmarked roads either."

</comment><comment><USER78> I've a simple text blog hosted on GitHub pages. Github Pages doesn't allow https for custom domains. Am I screwed?

<comment><USER79> No, GitHub is, because their product will become less attractive. Presumably they'll fix it before the deadline.

</comment></comment><comment><USER80> I hate this. I too do a lot of off-line, never connected to the Internet devices and I don't want the god Google telling my users they're "not secure". My users _know_ they're on a self contained network.

</comment><comment><USER81> What are the best services out there today to translate a website from HTTP to HTTPS? Particularly for a static website. I have previously used Cloudfare's One-Click SSL free service, and I wasn't a big fan.

<comment><USER82> Netlify free tier makes this as simple as it gets. (As long as your static site generator is supported.)

</comment></comment><comment><USER83> What about simple static sites like blogs that dont have forms? Do we really need to scare people away from our blogs and do we have to get an SSL cert for them unecessarily?

<comment><USER84> This has already been answered many times in this thread. Static sites are still vulnerable to MITM attacks and snooping over the network. Using HTTPS prevents this.

</comment></comment><comment><USER85> It's insane. I can't even access the web interface of my own printer any more, because it's not https.

<comment><USER86> No, it's not.

Yes, you can. Or if you can't, it's not because this change.

</comment></comment><comment><USER87> Google.es was on http until pretty recently. They change the rules now that the finally put it on https.

</comment><comment><USER88> I don't appreciate Google leveraging its market share to affect the mindset of Chrome users.

<comment><USER89> I bitch plenty about Google.

I'm happy with them trying to swing the needle to the side of good every once in a while.

</comment></comment><comment><USER90> So the next thing is to disable all javascript loaded without https I hope.

</comment><comment><USER91> This is a really stupid move. There are plenty of instances where websites do not need to use HTTPS, like simple static websites for small businesses that do not collect personal user information. This is going to cause a lot of confusion and outrage when it is implemented.

<comment><USER92> _There are plenty of instances where websites do not need to use HTTPS_

No there aren't.

 _like simple static websites for small businesses that do not collect personal user information_

Until the connection gets MITMed to return a fake login page.

<comment><USER6> What login page? Your typical company website just has a few pages of text without any active elements. Forcing those to buy SSL certificates creates just another artificial barrier to entry.

<comment><USER89> Whatever login page the attacker wants to present. They're betting percentages.

Google. Amazon. sac.mil. fed.gov. Whatevs.

</comment></comment></comment></comment><comment><USER93> I feel its a good thing. Sites can be made HTTPS with letsencrypt.

<comment><USER94> [https://letsencrypt.org/getting-started/](https://letsencrypt.org/getting- started/)

With Shell Access and automatic renewal, what could possibly go wrong?

What happens to all the web sites if the Let's Encrypt certificates, one day, expire?

<comment><USER89> One of the things about well-known SPOFs is you try really, _really,_ REALLY hard to make sure they don't F.

</comment></comment></comment><comment><USER95> So suddenly people will see lots of websites as insecure. This way they will stop paying attention to this warning, and when they will find a really insecure website, they will just use it.

</comment><comment><USER96> excessive. people will learn to ignore it

</comment><comment><USER97> Great, way to unnecessarily scare the undereducated masses. Even if they learn, it's pointless, you can already see if it's secure.

</comment><comment><USER98> dick move. not all sites require https. it's easy to analyse in browser if a site needs https and flag that as insecure, which they already do... :s

</comment><comment><USER99> Oh, if only there was an alternative to Google Chrome...

<comment><USER41> There is. Firefox quantum is better than Chrome. The only thing is pushbullet doesn't quite show popus correctly. It works with all the major streaming services, and just feels better. Now if only client side window decoration would come sooner, I want to ridded of that ugly title bar. I miss fedora's firefox 57 build.

<comment><USER6> Has alsa support returned in the Linux build? Unless that is the case, Firefox is absolutely useless to me.

<comment><USER100> FF Quantum is in the latest Linux build, if that's what you mean. So I'm assuming support has returned?

</comment></comment></comment></comment><comment><USER101> Welcome to the world where ad company tells you which sites you should look at.

<comment><USER102> Welcome to the world that used to say not to talk to strangers and not to get in stranger's cars.

Welcome to the brave new world where kids now summon strangers over the internet in order to be driven in the stranger's car.

</comment></comment><comment><USER103>
       the most interesting thing is that i know some Organ, not only inject code , may catch all Data !! if the web is not use a save version SSL, - .-

</comment><comment><USER104> HTTPS helps secure traffic between two parties, but that has nothing to do with whether that end party (ahem, Google, or Equifax, ahem) is secure.

If we want real security we need to put cryptographic keys in P2P identities, so users control end-to-end everything they do. No middleman can tamper with it.

Obviously, I'm opinionated because we're working on solving this, and creating a truly SECURE and DECENTRALIZED web: [http://hackernoon.com/so-you-want-to- build-a-p2p-twitter-wit...](http://hackernoon.com/so-you-want-to-build- a-p2p-twitter-with-e2e-encryption-f90505b2ff8) !

</comment><comment><USER105> I believe most people are seeing this wrong, there a few issues here.

1) Google is defining standards

This isn't a drive for web masters and users, it's our brother Google telling us what's good and what is bad. While they often fail on their own standards. But hey, they can't fail to pass, but you cant.. no expections besides big G.

2) We're focusing on SSL

This isn't about SSL, but's about point one.

3) misleading

Reading some basic website that is just a random one page html site, doesn't care about it at all. This gives basic users( the ones we're thinking are too dumb to demand ssl) the idea this site is not safe.

Real users think two things;

Safe or not safe.. they don't understand the gray and now we're saying Not Secure. A lot of people will think this is not safe, no one is around telling them why this appears as no one in the real world reads this blog besides us.</comment>


Show HN: Say Less – AI summarization tool in the Gmail compose window - <AUTHOR> https://sayless.email/ <comment><USER2> I don't know if it's just me, but I very much prefer easy to skim emails to more dense ones.

At one point I got weekly project updates from a team I was working with, and one guy wrote dense, short, emails where I would have to read every sentence carefully to get a hang on what was going on. Another guy would write longer, fluffier emails but with bullet points and paragraphs in the same order:

> Hi everyone!

> {fluff}

> {general status}

>

> \- Bullet points of things done that week

> {comment about things done}

>

> \- Bullet points of things to do next week

> {comment about potential problems etc}

>

> {fluff}

> {annoyingly long footer}

Just by parsing the number of bulletpoints, and the length of each bullet point (and the first word) I would get a surprisingly good grasp on how things were going, and what was hard/complicated (longer bullet point -> more complex), and very easy to read about exactly I wanted to know.

<comment><USER3> This is how the so called sutras are written: a page of text gets compressed into one short sentence, so you have to stop after each of them and spend an hour unpacking its meaning, but the entire book is often just 200 sentences.

<comment><USER4> Sutras like Panini's Grammer written 5th century BC are great product of formal knowledge from India. However, writing emails is not the same thing:

\- Sutras solved the problem to retaining large chunks of knowledge.

\- Sutras had formal rules to keep the meaning unambiguous.

\- Sutras were written by the sages who had lot of knowledge and control over language.

-Sutras were written in Sanskrit. A highly malleable (due to SANDHI and SAMAS) yet a precise language.

\- English is not the right language to write tersely.

</comment></comment></comment><comment><USER5> I like the idea of this product but

(1) sometimes a BIT of a personal touch goes a long way

(2) even in the examples you give it misses potentially important context. Eg In the board message example, it removes a reminder of the topics. How could you know those weren't necessary? Why is the number of members what it included?

Just doesn't seem ready for prime-time for this use.

My preference would be having it suggest shorter versions of each paragraph inline or something.

<comment><USER6> Agreed, some people really don't like terse emails.

I actually got myself into trouble a couple of years back because of this. I've been working with Norwegians almost my whole working life, and am used to being terse, direct and honest. Aside from that, I'm an extrovert, and don't talk unless I have something to say.

Anyway, then I got placed as tech lead for a UK project, working remotely. Within a week, the PM had made a complaint to my manager that I was being glib and not listening to other points of view.

I had no clue where any of this had come from, and sat down with the PM to try to understand - if I'd given the wrong impression, I wanted to fix it. Anyway, we looked back through piles of emails, and in every single case it was a misunderstanding of my real intentions that was directly linked to terseness.

From then on I've tried to gauge my audience better - always using salutations, using longer sentences to say the same thing, trying to be softer etc. I think by and large this has been successful, although I am finding recently my emails tend to be _too_ long...

<comment><USER7> Why do you have to change and not them? Especially if you sat down with them and discussed it?

<comment><USER6> Because unfortunately the world doesn't revolve around me :)

It wasn't only the PM, the AI lead apparently felt the same, although I think the AI lead was the one that kicked up a fuss in the first place.

At first I was really pissed off - I didn't think I'd done anything wrong, and was completely baffled about the complaint. I went over my emails myself, and thought about calls we'd had, and I just didn't get it. TBH, I still don't understand how it could have been misconstrued, but I have to accept that it _was_.

Anyway, I guess the point is that while I'm terse, open and honest, not everyone else is. Consider your recipients before sending that mail - who are they, where are they from, what approach are they likely to be receptive to.

<comment><USER8> >"Anyway, I guess ... to be receptive to."

In other words, developing your communication skills can have good impact.

</comment></comment></comment></comment></comment><comment><USER9> Have you tested this in marketing emails? that seems to be the profitable marketplace. Even if you can prove 5% increase in roi that's worth a lot to a lot of people!

There are some interesting studies showing short emails perform better but we haven't found that to be true it seems the message is the biggest factor. Some way to improve the message is even more valuable but also likely a much harder ML task

<comment><AUTHOR> The original inspiration and example featured on the website was from a blog post on cold "welcome" email copy: [https://www.gkogan.co/blog/increase-reply- rates/](https://www.gkogan.co/blog/increase-reply-rates/).

I'd love to test it on more marketing emails, or content marketing -- these seem to be the two applications with the most direct ROI.

</comment></comment><comment><USER10> I think there is still a way to go here.

For example, the "really" in "really appreciate" isn't useful.

Also the last sentence in the "summarized" version reads: "If for any reason you haven't let, let me know..." I would also that that the "for any reason" is not useful, it is again implied.

You don't need "by now", it is implied.

<comment><USER11> Why does it seem common for people to knock modifiers for degree/intensity with words.

The statements "That's nice." and "That's really, truly nice." give off very different messages.

One of them I'm not even sure if you're being short or dismissive/not interested, and I have to do mental gymnastics to figure out what the underlying tone is.

Just one or two words makes a massive (see what I did there) difference in tone + perception.

This is half the reason why it's hard working remotely. I put so much effort into being overly polite/nice with tone because you lose out on all other social cues and it's easy to mistake an ambiguous message.

</comment></comment><comment><USER12> I'm reminded of the recent post on HN showing that long, personalized emails reduced email conversions, and that short, pinpointed emails increased conversion. Long emails give the impression that one is either a program or desperate, and no one takes the time to read the entirety of every email they receive.

<comment><AUTHOR> Author here.

If you're talking about [https://www.gkogan.co/blog/increase-reply- rates/](https://www.gkogan.co/blog/increase-reply-rates/), this was a primary inspiration for this project -- I even stole the name ;)

<comment><USER12> I am, here's the recent discussion: [https://news.ycombinator.com/item?id=23939462](https://news.ycombinator.com/item?id=23939462)

</comment></comment></comment><comment><USER13> What about Read Less?

Would be cool to use this tool to read less of incoming email and then dig deeper if I think it's worth it.

<comment><AUTHOR> When I was researching this product area, I found a bunch of similar tools that summarized on the inbound side. I thought it would be more interesting to experiment on the outbound side as the main initial focus, which I haven't seen.

I do have a generic popup that you can to summarize any passage, so you could copy-paste some long passage (email, article) to piggy back on the functionality. But it isn't tightly integrated into the Gmail UI as of now.

</comment></comment><comment><USER14> The demo gif is too long. Gave me the feeling that this product would force me to waste a lot of time waiting for it to load

</comment><comment><USER15> Based on some digging around, it looks like the app is made with Facebook AI's BART model [1]. The only summarization implementation I spotted was made by huggingface (of course). [2]

[1] [https://github.com/pytorch/fairseq/tree/master/examples/bart](https://github.com/pytorch/fairseq/tree/master/examples/bart)

[2] [https://huggingface.co/facebook/bart-large- cnn](https://huggingface.co/facebook/bart-large-cnn)

<comment><AUTHOR> Yes, you are correct -- I linked to this research on the frontpage as a citation.

</comment></comment><comment> zupa-hu I see the biggest opportunity here in summarizing books and blog posts. At least for me.

Too often, after reading a blog post, I feel like it was a waste of time. I'd prefer to read a super dense summary first. Then optionally select longer variants before reading the full thing.

Maybe There could be a compress function [1, 2, 4, 8, 16, 32, 64, ...]. Choose the compression level before reading.

Especially with books. I'm not sure how well this could work, but I'd prefer to read 100 books that way first, before deciding on the few I actually want to read.

I'd totally pay for this.

</comment><comment><USER16> The issue with efficient summarization is the necessity of context. For a message to be effectively summarized you require a bit of "theory of mind"[0], you need to have at least a decent idea of what the receiver already knows. This is something that, especially when done for a single message at a time (with no other info), likely doesn't have a global solution.

Edit: I should be clearer, I believe that the solution shown here does not have this capability, and the effort of using ML to do message summarization is flawed in the general case.

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

<comment><USER17> Your edit and summarization is quite clear. Thank you for that.

</comment></comment><comment><USER18> I'm excited to see where this goes -- both this product and the general idea of using ML to reduce noise in interpersonal communications.

A human can read the shorter summary and add personal touches as they wish, but the first pass of what the model considers to be extraneous is interesting by itself.

I just put in a 300 word personal email and it spit out a 60 word summary that actually did extract the one concrete piece of news I was sharing, and just cut everything else. That's not precisely what I wanted in this case, but it wasn't a bad guess at all.

Side note: just finished a rewatch of Silicon Valley, I like that the sample text is from someone at Hooli, I wonder if it will change my .... to ... :)

<comment><USER19> So long as it's not doing that while operating on ciphertext.

</comment></comment><comment><USER20> Neat idea, I could definitely be more terse in my comms.

As an FYI, some bad English on the Hooli Onboarding Email example:

        If for any reason you haven't let, let me know and I'll make sure you get them.

<comment><AUTHOR> Good looking out! Will fix that.

</comment></comment><comment><USER21> Short emails tend to be either notifications, highly transactional (web based platforms are better for these as they can do tracking and trigger other outside actions), vague, or assume outside context.

These are the same problems as always-on corporate instant messaging platforms, just slightly improved by the cross-organizational functionality and store-and-forward.

IMHO organizations should strive to make email less like instant messaging and more like letters. Fully formed thoughts distributed less frequently and with more purpose.

In short, tax hassling others.

<comment><AUTHOR> Interesting take because there is a school of thought that comes to the opposite conclusion: emails should be more like text messages: [http://five.sentenc.es/](http://five.sentenc.es/).

I think the most interesting part of this problem is the ambiguity in desired result. Emails are inherently unstructured text data, which results in conflict about how people want them to look like.

</comment></comment><comment><USER22> Seriously. I already write short mails and put bullet points which makeout much smaller. This year one of things I want to do is write big emails like paragraphs atleast two.

</comment><comment><USER23> I've never written an email that was too long and then later realized it should have been way more concise. I generally know my intentions prior to writing the email, so if it needs to be short, I'll write it short. The reverse situation probably happens more often though (i.e I write a short email, realize it doesn't make sense due to lack of details, then I elaborate).

<comment><USER24> I intentionally write short, concise emails.

It has actually backfired on me in the past: because I didn't define and explain the entire space of the matter at hand, I was overcome by other arguments or ideas that I'd already considered and dismissed. That led to followup discussions that didn't need to occur.

It seems that context matters, sometimes long-form is better.

<comment><USER25> I tend to write longer e-mails - but I agree with you, long-form and short- form e-mails are both optimal for different situations.

The problem seems to be that it's a judgement call - and I'm not exactly sure of all factors/variables that are involved in that judgement call. The subject at hand, the audience, the depth of the e-mail thread to which you're replying, time-sensitivity of the subject, etc. - they all play a role. But my default position tends to be that I'll save time explaining in future e-mails by providing all relevant details at hand now.

</comment></comment></comment><comment><USER26> Super cool. Would add this as a company gmail feature.

However, I also write emails to reduce time spent in conversation, so while I have learned to be more terse, when I'm not, it's to provide references so that I can shorten or preclude a conversation.

An ML email shortener is a fantastic idea for business comms, with the caveat that short email culture can also reward vagueness.

<comment><USER27> Shortness shouldn't be the goal. Clarity should be the goal. The problem is that clarity is a much harder thing to test for.

I would pay money for a tool that checks my technical writing for reading level and warns me when passages go above Nth grade. Most people in the US graduate high school with an 8th grade reading level, and some people may not be able to read above a 5th grade level. That means tiny words and short sentences are king.

There are also metrics for clarity and simplicity that proxy on number of syllables. Those are really useful and don't require a complex ML model.

<comment><AUTHOR> [https://readable.com/](https://readable.com/) is an interesting tool I came across in my research you might be interested in. It relies on the Flesch–Kincaid readability tests [1] and has found sustained usage.

Actually, now that I think about it... this might be a good source for bootstrapping further training data.

[1] [https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readabi...](https://en.wikipedia.org/wiki/Flesch%E2%80%93Kincaid_readability_tests)

</comment></comment></comment><comment><USER28> Coincidentally I've been feeling like my emails are becoming way too verbose recently. I'm not sure what it is, but I'm just taking longer to reply in a way that conveys my message properly, or I'm finding myself editing a draft to death before I ever send it. I used to be able to just reply and move it to the next bucket.

</comment><comment><USER29> Can I use this in conversations with my wife? So much talking. ;)

Joking aside - this is a great tool in corporate settings. In technology, one works with two types: Very verbose (tend to be introvert or detail oriented) or Too abbreviated. I cannot stand reading detailed accounts - and this could add to many professionals comprehending more.

</comment><comment><USER30> If this could convert passive voice to active voice, or underline it as an error, this could be a great technical writing tool for inexperienced writers. Good technical writing is hard, a tool similar to this could be useful.

</comment><comment><USER31> I wonder how this would perform compared to using GPT-3

<comment><AUTHOR> I just got access to GPT3! Have only played around with it for a few hours so far, but haven't gotten it to reliably summarize.

</comment></comment><comment><USER32> Nice job doing the last mile and making it a usable service.

Just guessing: SMMRY or Quillbot with a little enhancement to preserve the salutation?

<comment><AUTHOR> Nope, I've developed and hosted my own summarization API here. It does heavily rely on open-source machine learning libraries and research / datasets released by Facebook AI [1]

[1] [https://ai.facebook.com/research/publications/bart- denoising...](https://ai.facebook.com/research/publications/bart-denoising- sequence-to-sequence-pre-training-for-natural-language-generation-translation- and-comprehension/)</comment></comment>


What does the GDPR actually mean for startups? - <AUTHOR> https://hackernoon.com/what-does-the-gdpr-actually-mean-for-startups-b4010e9b962f <comment><USER2> As a solo founder with already too much to do. I simply looked at the GDPR and decided to kick that can down the road for 12 months after launch of my start up.

Although a UK Citizen, will be bootstrapping the startup in the US and simply blocking EU buyers from accessing the site.

Why you may ask?

\- I don't have the funds to hire a DPO.

\- I don't have the funds to hire out an expensive company to go through the platform in minute details and prepare it for GDPR.

\- I don't have the resources to deal with inquiries to that nightmare letter or any questions for that matter.

\- I don't have the resources to monitor the 3rd parties privacy policies that I send data to use their service and constantly update my own.

From my perspective this is just burdens my company with more costs in doing business with the EU. I'm more than happy to concentrate on the US and the rest of the world.

One issue that I'd like to point out as well. Some commentators mention that the EU is ~22-25% of the worlds GDP to be accessed. Well, that's a complete fallacy.

The EU unlike the US isn't a contiguous block. There are 28 nations and 24 languages to deal with. You simply can't launch in the EU like you would in the US. Each country has it's own idiosyncrasies to deal with. Which is why some companies just launch in France, Germany, UK and then push out the other smaller markets years down the line and in some cases not at all. There may be other local regulations to deal with.

My opinion is that the GDPR over the long term, will hamper the ability of EU companies to do business on the world stage, even more than currently. But that's a completely different topic for another time.

<comment><USER3> \- I don't have the funds to hire a DPO.

Just appoint yourself as DPO. It's a role, not a qualification.

> \- I don't have the funds to hire out an expensive company to go through the > platform in minute details and prepare it for GDPR.

Just go through your database and work out what data can be associated with an individual. Do you have a good reason to keep that data? If yes, cool, you're golden. If not, delete it and you're golden. The only thing that GDPR changes about data is (rightly) turning it from an asset into a liability.

> \- I don't have the resources to deal with inquiries to that nightmare > letter or any questions for that matter.

These are your customers. If you don't have the time or resources to talk to your customers, then your business is going to fail anyway.

> \- I don't have the resources to monitor the 3rd parties privacy policies > that I send data to use their service and constantly update my own.

You don't have to monitor them, you just need to read them. If you don't have time to read contracts that you're singing, then your business is going to fail anyway.

Pretty much everything in GDPR was already covered by existing UK Data Protection legislation. Under UK law you already had to appoint someone in your organisation to deal with Data Privacy, you already needed to have a good reason to collect personally identifiable information, and an obligation to ensure it wasn't disclosed to third parties.

I suggest you start taking all of this a bit more seriously than your comment suggests, not because of the legal implications, but the moral ones. Your customers are trusting you with their personal information. It's a serious responsibility that you need to take seriously. If you can't be bothered making sure that your customer's data is safe, then you shouldn't be trusted with it.

<comment><USER4> _These are your customers. If you don 't have the time or resources to talk to your customers, then your business is going to fail anyway._

This point isn't about your customers. It's about the bitter ex-customer who decides to take revenge through legal means by exploiting the rights they have under the GDPR to waste your time and money. And if you think this is a hypothetical risk, read the news today about kids lining up to damage exam boards in exactly this way if they didn't get the grades they wanted, and explain to me how that isn't a threat to the integrity of the examination system.

 _You don 't have to monitor them, you just need to read them. If you don't have time to read contracts that you're singing, then your business is going to fail anyway._

The fact that you have read the privacy policy of one of your suppliers does nothing to help the data subject. Unless _they_ have meaningful information about how personal data about them is being processed and who is doing that processing, they haven't really gained any meaningful control or protection.

And no small business has the time to fully read all of the legal paperwork affecting them. Like consumer contracts, it's the great fiction of the legal community. Most new businesses won't even have had time to read the contract with their banks and other financial services before signing to open their account, and those often contain some very nasty and one-sided terms. But of course those contracts all tend to contain similarly nasty and one-sided terms, and you're going to need those services to do business anyway.

<comment><USER5> > It's about the bitter ex-customer who decides to take revenge through legal > means by exploiting the rights they have under the GDPR to waste your time > and money.

Except you can't sue anyone under the GDPR. All you can do as a consumer/bitter ex-customer is file a complaint with your country's privacy watchdog. IF there really is a problem, they will just tell you to fix it, that's all. You only need to worry if you're doing shady things with personal data and don't intend to stop doing them even after being warned, in which case you deserve everything you get.

<comment><USER4> Unfortunately, the entire point of the "nightmare letter" was that much of what you just wrote isn't actually true. It wasn't about suing anyone. It was about wasting their time and potentially their money identifying which of the numerous points actually required a response (and a few traps among them that most certainly did not) and then gathering lots of obscure information they probably didn't just have as standard in their usual information management systems or published in their privacy policy, and highlighting the fact that the GDPR removed the small but non-zero fee that previous law allowed for exercising these rights that served as a practical barrier to this kind of abuse.

<comment><USER5> > It was about wasting their time and potentially their money identifying > which of the numerous points actually required a response

I've seen the letter and it's all questions you should be able to easily answer anyway. If this letter would be a nightmare scenario for you you'd better get your shit in order, regardless of the GDPR.

<comment><USER4> _I 've seen the letter and it's all questions you should be able to easily answer anyway._

The _very first point_ in that letter requires identifying every communication you have ever had with or about the data subject that is still stored anywhere in your organisation, among other actions. If you think that is easy, presumably you know how to automate that process, in which case I look forward to seeing the multi-billion-dollar business you have presumably built scanning unstructured data reliably in ways that no-one else has figured out how to do yet.

<comment><USER5> > The very first point in that letter requires identifying every communication > you have ever had with or about the data subject that is still stored > anywhere in your organisation, among other actions.

The magic words here are "still stored", PII is a liability so you never want to store it longer than absolutely necessary. Why are you hoarding this data when you can't even retrieve it easily, what is the point ?

<comment><USER4> _Why are you hoarding this data when you can 't even retrieve it easily, what is the point ?_

Do you have a filing system for every email you ever wrote? Can you identify every backup copy, every forwarded message, every print-out, every excerpt copied and pasted into a Word document? Can you remember or look up every individual ever referenced in those messages?

Now, let's talk about letters. The paper kind. And faxes. Including unsolicited ones that aren't part of any formal process where a customer helpfully included their password so you knew it was from them. And mentioned that it's their mother's birthday, in case you were wondering.

Have you ever written down an address or phone number on a piece of paper because that was what you had to hand when someone read it out to you over the phone? Or opened up a quick text file to keep notes from a meeting?

If you're a director responsible for a company of 2,000 staff, do you think anyone else in your company has ever done any of those things, and would you like to bet your job that no-one ever kept a record other than as part of your comprehensive, perfectly-specified and loophole-free official processes?

If you're a director of a startup with 5 people, do you even have those processes, or is almost everything actually being done with text files and Post-It notes (or Slack channels and Google Docs, or...)?

This is not an easy problem. People have made very, very large amounts of money building businesses trying to solve this problem, and the first people who really nail it are going to make even more. You can't just hand-wave away the possibility of having personal data that is not immaculately organised, rigorously controlled and fully indexed in any organisation of significant size and lifetime. A law that makes such a requirement is like a law that says you can only ship software with no bugs, or a law that says all laws will be unambiguous and enforced with zero tolerance.

<comment><USER3> GDPR wasn't put in place to monitor people scribbling down phone numbers on pieces of paper. It was put in place to stop companies from hoarding vast amounts of personal data and using it to infringe on people's privacy (as well as making sure they looked after it properly).

If the regulator finds out that one of your staff scribbled down a customer's phone number once on a piece of paper while serving that customer, they won't care. If they find that your customer service process requires your customer service staff to scribble down phone numbers on scraps of paper that are then put out with the garbage, where they can be dumpster-dived, they will care (and so should you).

This is not some huge regulatory over-reach that will force you to go through every piece of paper in your organisation. It's a check on your data handling that forces you to acknowledge the trust placed in you by your customers.

<comment><USER4> _GDPR wasn 't put in place to monitor people scribbling down phone numbers on pieces of paper. It was put in place to stop companies from hoarding vast amounts of personal data and using it to infringe on people's privacy (as well as making sure they looked after it properly)._

Sure. The _intent_ of the GDPR has not received much criticism, at least not that I've seen. The concerns some of us have always had are more about ambiguity and interpretation, because on the one hand the law as actually written doesn't allow for much leeway in some cases, and yet on the other hand it has huge ambiguities in key areas hiding behind words like "reasonable" or "legitimate".

It's easy to look at extreme positions, such as the example I gave above for illustrative purposes, and say no regulator is ever going to expect all of that. Probably you'd be right. The difficulty is that somewhere between not doing much of anything to comply and the other extreme such as I described, you cross an invisible line from being sufficiently compliant in the regulator's view (or potentially a court's if it really came to that) to not being sufficiently compliant _and no-one really knows where that line is_.

When you have not just the threat of fines but also potentially very significant costs in adapting your systems and processes, that sort of uncertainty is never good for anyone. That is particularly true in a case like GDPR, because many of those adaptations are more about being _seen_ to comply than about fixing any actual security vulnerability or abuse of privacy or other tangible problem.

<comment><USER3> I get it. The best explanation I've heard is that this is a major difference between EU(and UK) regulation and US regulation. In US regulation, the letter of the law matters. In the EU the spirit matters.

The UK has had regulation like this for decades, and as loosely worded. The regulator rarely imposes fines, and then only when forced to because the infringer is refusing to change their processes. Almost always they give some advice, sometimes a warning. This is done in the context of a conversation with the regulator, like "hey, we've received a complaint, have you got any reason why this happened?" instead of "we received a complaint, you're fined $1000 for it".

It's not a revenue source for the government (which it would be in the US). The wording is loose deliberately so that the regulator has the power to enforce the spirit of the regulation without getting tied into knots by the letter of it.

So yeah, I get that it's freaking people out. And there are costs in adapting processes. But, to be honest, if those processes need adapting then they were probably doing the wrong thing in the first place. Also, the EU gave everyone years of warning, and nobody paid any attention to that.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I'm surprised that the guide doesn't address automated decision making about users. In my day job, we are using a scheduling platform for short-notice, short-term work e.g. social care. A job is loaded on the sytem and pushed to x users for acceptance (fastest finger first).

The system has a ratings module (not active yet) whereby clients can rate the worker and vice versa. The system then makes decisions on future job releases based on the ratings. Part of the reason for not having the module active is due to the issue of communicating to the affected users how those decisions are being made and providing them with a right of manual review.

As organisations increasingly rely on AI or ML to make decisions affecting individuals, so the need for greater transparency into those decision making processes so they can be communicated to the people concerned.

</comment><comment><USER7> >> The scope of this protection extends to any natural person in the EU which can mean users, employees, vendors, partners, customers or even members of the general public.

I hadn't considered GDPR from the perspective of a company collecting/maintaining data about employees (as opposed to clients, prospects, website visitors etc.). Do the same rules apply inside a company for an employee as they do for a user of a web service? Can I, for example, request a copy of all identifiable data collected and maintained about me by my company in the same way I might request it of Facebook or Twitter?

<comment><USER8> Yes. You can request a copy of any personal information held by any company. This is a pre-GDPR right too.

<comment><USER7> I was not aware of this - thanks for the reply.

</comment></comment></comment><comment><USER9> > where your base of operations is in the EU; where you're not established in > the EU but you offer goods or services (even if the offer is for free) to > people in the EU; or where you're not established in the EU, but monitor the > behavior of people who are in the EU (as long as that behavior takes place > in the EU).

Question — IANAL, but I read a summary on a legal website (I'll see if I can find a link) of GDPR that said it applies to non-EU companies not when you offer services to all people, some of whom might be in the EU, but when you specifically target and advertise to EU citizens. It sounded like a web app, for example, that is marketed generally toward anyone and allows connections from anywhere, would not be legally subject to GDPR, whereas if I, say, localized in German and had a campaign to get German teachers using my app, then GDPR applies.

Aside from whether adhering to GDPR is a good idea anyway, and I think it is, is that distinction correct? Can strict GDPR be avoided if I'm not targeting the EU specifically, and my customers aren't primarily EU citizens?

EDIT: here's the link: [https://ec.europa.eu/info/law/law-topic/data- protection/refo...](https://ec.europa.eu/info/law/law-topic/data- protection/reform/rules-business-and-organisations/application-regulation/who- does-data-protection-law-apply_en)

Here's the text:

"When the regulation does not apply

Your company is service provider based outside the EU. It provides services to customers outside the EU. Its clients can use its services when they travel to other countries, including within the EU. Provided your company doesn't specifically target its services at individuals in the EU, it is not subject to the rules of the GDPR."

<comment><USER10> That doesn't sound right to me.

<comment><USER9> Care to elaborate? Do you have law experience or some sources that clarify?</comment></comment></comment>


Prestashop hosting choice – Nemo's PostScriptum - <AUTHOR> http://nemops.com/prestashop-hosting-choice/#.U2oHhJNHh3c.hackernews <comment><USER2> Coïncidentally enough, for me, this is exactly what I'm researching now for one of my web clients.

They have a Prestashop setup with _thousands_ of product option combinations, which is slowing things down on their shoddy shared server setup.

I've been having a hard time trying to clarify what specs I need to run Prestashop smoothly, so was relying on the advice herein..

[http://blog.dh42.com/fastest-prestashop/](http://blog.dh42.com/fastest- prestashop/)

..and had settled on a [fairly minimal] VPS account with

[http://www.heartinternet.co.uk/vps](http://www.heartinternet.co.uk/vps)</comment>


Finding Early Customers When You Aren't Internet Famous - <AUTHOR> https://zapier.com/blog/2012/04/05/finding-early-customers-when-you-arent-internet-famous/ <comment><USER2> Or you could create a startup in a space where being internet famous doesn't matter. And you probably should.

<comment><USER3> I think the point that launching a startup with no "followers" is difficult. I'm in the same boat. I haven't blogged in 10 years, I have 30 or so twitter followers (most of which I'm pretty sure are hookers) and nobody knows who I am. When Notch or Biz Stone says "I'm launching a startup" they immediately have traction--the author knows that the rest of us have to hustle.

I'm finding it difficult but seeing rays of light. My project (<http://www.thetaboard.com>) is just getting of the ground (still an MVP) and getting visitors is tough. Luckily my product is something HN readers might actually buy so I get more value than most out of HN posts. I've had a couple make the frontpage and had some (free) signups from it.

The author makes some great points and I'm defintely going to try some of their ideas for creating organic search traffic.

<comment><USER4> But Notch wasn't "Internet famous" until after Minecraft launched. Minecraft _made_ him Internet famous. In other words, Notch is Internet famous because Minecraft was a hit, Minecraft wasn't a hit because Notch was Internet famous.

Don't worry about how un-famous you are. Put that energy into building something that _makes you famous._

<comment><USER3> No, his hard work on Minecraft made him famous--I'll give you that. But when he released his MMO the other day, he probably had 1 million people who at least wanted to check it out. Now the new game will be judged on its own merits but Notch's Internet celebrity gave him instant traction.

</comment></comment></comment></comment><comment><USER5> Having mediocre design skills, I struggled before to create even the simplest landing pages for my mobile apps. Like the article says, I was simply trying to create a one-page site that contains a short description of an (upcoming) app, and a way for people to enter their email addresses for future notifications.

Although this sounds really simple (I can cook up the bare html in a few minutes), I struggled to make it look half decent. Surely there must be some easy way to create such simple landing pages, but I couldn't find it. I tried wordpress themes, twitter bootstrap, and other platforms, but my designs(or lack thereof) always turn out horribly.

My question: is there an easy way to create simple, beautiful landing pages?

<comment><USER6> I don't know if this will be simple for everyone to execute as doing anything well does take time and skill but I can give a couple of pointers that helps me make simple pages that work (Convert users at rates >15% - I don't know what others get but I'm happy with 15-20%).

I used to design a lot of print advertisements. When it finally clicked for me that many of the principles are the same things started working.

Use AIDA:

\- Attention - Use a super high quality and very interesting (to your target) picture. You can buy these cheaply from amateur photographers if you don't have any.

\- Interest: Use a headline that says something to your target

\- Desire: use a little text to make them want what you're selling. IE. tell them how it solves your biggest problem

\- Action: Use all the tricks you know to make a good looking button (or read on how to do it, there are lots of sources for this) and place it in the bottom right somewhere. The bottom right is what print designers do because it's the last point your eye reaches when reading, it's the best place for a call to action

Here are two recent examples that I have created (can be improved but you get the idea). With quality traffic they convert around 20%:

<http://styckyd.com/sell_modified_cars>

<http://styckyd.com/sell_race_cars>

That advice might not be quite what you're looking for as it's not a service that does most of it for you (someone could create that fairly simply) but it's working for me.

<comment><USER5> Excellent advice. Thanks for sharing.

</comment></comment></comment><comment><USER7> Here's my advice (which is contingent upon your actually selling a product or service):

Setup an affiliate program and promote that as assiduously as you promote your actual product or service.

Yes, doing so can take lots of work and managing it may take plenty of your time, but the trade-off can be well worth it. If you do things even 50% right you will end up with dozens, or even hundreds, of hungry internet marketers and webmasters promoting your product for you - at almost no cost to you.

Pay your affiliates only after you get paid, (and after your merchant-account- mandated CC chargeback threshold passes). Flatter your top grossing affiliates with audio, video or email interviews (which you could publish to your startup's blog and which they will definitely spam the heck out of to everybody they know).

Once you get enough traction and revenue to afford it, offload your affiliate management to a network like CJ or PepperJam.

I used to be one of them so I can tell you, internet marketers are ALWAYS looking for a great product to sell/promote. Cut revenue-sharing deals with Internet Marketing forum owners for even more exposure.

Do all that and, while I cannot guarantee that your product will succeed in the long run, I can guarantee that it won't fail as a result of nobody knowing it exists.

</comment><comment><USER8> One CAN get initial traction and customers without having to be an internet celebrity.

A fantastic first step is to ask to the internet marketing community. I'll summarize my tips on this issue to try and help the readers as much as I can, but please reach out to SEO/SEM/Branding people in the community at each stage of your start-up journey so you can keep learning, growing and driving traffic to your site. So here's my advice to find those early customers:

\- Build a fascinating product. Something that is better than every competitive proposal in one or more dimensions (design, speed, simplicity, robustness, etc). You know you have this when you feel passionate about your product. At this point, it doesn't matter to have erred in some minor market assumptions. Just do a solid MVP given your current understanding of the market needs.

\- Go to search.twitter.com and find 50 people that are looking for the solution you provide (i.e. search for "i want a widget that does x")

\- Network with this group of 50, give them premium accounts and give them early access to your product. Congrats, you've got a nice beta testing team with a desire for your product.

\- Reverse engineer the "mind-set" of this group of people: do they want speed, low price or robust functionalities? Then, according to this create "personas", ergo user profiles.

\- Now comes the fun part: you're going to market to each independent user profile with a separate marketing effort. Before doing this, install Mixpanel and make sure you're tracking EACH distinct user profile. Then place one Google Adwords campaign for each profile. You want to discover which user profile prefers your product, which type of user converts best, etc. To get ideas for keywords I recommend Wordtracker.com (some people like the Google keyword tool, but that's ok as well).

\- Since now you know the type of user you want to target raise your bets: create multiple landing pages for this user type (the article gives you a good idea of how to do just that).

\- Tweak the conversion rate (ratio of sign-ups per visits) that each page gives you. Ideas to do this include: creating professional introductory videos, adding testimonials, doing basic A/B testing, refining your copy, etc.

\- Keep refining you product. And. keep. marketing. There's so so much you can do on a budget: pay for press releases to boost your page rank and get initial awareness (under 400 dollars on prweb.com), join several interest groups and promote to their mailing list, etc.

\- Internet famous celebrities don't have THAT high of an advantage over you (when it comes to marketing). They DO have great advantages when it comes to raising money but, for the purpose of building a compelling MVP... how many people do you need? Not many. You're better off with a mix of the right people and a tight knit community.

</comment><comment><USER9> Being "internet famous" just gives you a head start on getting traction. I am working off the conviction that if I build something which solves a significant problem for people, I can build a solid user base. If I do this well enough, people with a large following will benefit from my work and share it. That's when rapid growth should occur.</comment>


Petition to Apple to recall butterfly keyboards - <AUTHOR> https://www.change.org/p/apple-apple-recall-macbook-pro-w-defective-keyboard-replace-with-different-working-keyboard <comment><USER2> I like these keyboards. The old ones feel like mush to me now.</comment>


The Power of Technical Debt - <AUTHOR> http://blog.ircmaxell.com/2012/03/power-of-technical-debt.html

<comment><USER2> I've never like the following expression.

"If you don't have enough time to do it right, when will you have time to do it over?"

It always seemed to me that an answer of "later" is potentially completely valid.

<comment><USER3> The idea is to not _always_ say "we'll do it later". "Later" works fine as long as the various decision-makers involved can be talked into doing it later. If their answer is always "if it works, don't touch it," then they are the target audience for that old saw.

</comment></comment><comment><USER4> I think it's valid to take on Technical Debt, but only when it's been explicitly decided that there's a good reason to take on technical debt. It's when you make a habit of always taking the quick and dirty approach and never take the time to refactor that you start running into problems.

<comment><USER5> I don't think its possible to avoid technical debt if you are making something new on a deadline.

Just like real companies, bootstrapping sounds like the ideal situation but it's not the reality for most people.</comment></comment>


Show HN: Child growth tracker to replace pen and paper charts - <AUTHOR> https://www.ismychildgrowing.com <comment><AUTHOR> I'm a father to two little boys and tracking their growth is typically done on paper charts such as [https://www.cdc.gov/growthcharts/data/who/GrChrt_Boys_24LW_1...](https://www.cdc.gov/growthcharts/data/who/GrChrt_Boys_24LW_100611.pdf) which are not very usable on screens and require you to draw lines with pen on the paper for accurate tracking. So I made a digital version instead with React and D3.

The charts are limited to those for children under two years of age since growth charts for older children differ based on nationality.</comment>