Reasons Not to Use Google (2015) - <AUTHOR> https://stallman.org/google.html <comment><USER3> _> In general, most Google services require running nonfree Javascript code. If you refuse to run that (for instance, by running LibreJS), you'll see that you should not use those services._

Well, I use Google Maps just about every single day so Stallman's advice banning Javascript is way too hardcore for me.

But for sake of discussion, let's entertain what he's suggesting. What are the _most practical alternatives_ to avoid Google's Javascript maps in 2019?

\- other websites like Bing Maps and even openstreetmap.org also don't work without Javascript

\- using local software like old CDROMs of map software means I'm using data that's 20 years old because no mainstream software publisher (e.g. Microsoft Streets, DeLorme, etc) is selling it and only cover a region instead of the entire globe. Also that CD software is _proprietary_ and not free-as-in-libre.

\- using folding paper maps like Rand McNally have similar problems to CDROMs -- the maps are old and more cumbersome.

\- other alternatives I overlooked are ... ?

Inevitably, this leads to the condescending question... _" How did we get by _before_ Google Maps?!?"_

I got by in the past by making the usage of maps more _inconvenient._

EDIT to replies about OpenStreetMap: Last I checked, OpenStreetMap doesn't have publicly accessible satellite images or 3D/birdseye views or street-level 360 degree views. Openstreetcam is missing a lot of roads. I use that type of photographic imagery _even more_ than the line drawings of streets. Is there a practical non-Javascript alternative for that data?

<comment><USER4> It won't satisfy rms but seriously: Apple Maps, which is actually good now.

The Maps app on Macs and iOS does not use JavaScript. It also supports satellite and 3d views, and the street view shipping in a month looks better than what Google offers:

[https://twitter.com/rvdsteege/status/1139264604918485005](https://twitter.com/rvdsteege/status/1139264604918485005)

<comment><USER5> He doesn't want to use Javascript because he doesn't want non-free software (the JS code) running on his computer.

Using a proprietary software on a proprietary OS is not going to be any better.

<comment><USER6> Serious question: why is JavaScript not free (as in 'freedom' to use)? Who is the owner of JS and do web browsers have to pay for it?

edit: tried to make my questions clearer :)

<comment><USER7> You can read [https://www.gnu.org/philosophy/javascript- trap.html](https://www.gnu.org/philosophy/javascript-trap.html).

Note that the discussion here is about JavaScript code, not JavaScript the programming language (there seems to have been some confusion in this thread).

Also note that being able to read the code doesn't entail that the code is free as in freedom (i.e., released under a corresponding license). If you share some non-trivial[0] code of yours on GitHub, or deploy a website with your own non-trivial JS code, it still fully belongs to you, and people are not free to reuse it without asking you.

[0]: you probably cannot claim much for a hello world even if you wrote it yourself

<comment><USER6> Thanks for that link and info. My reading is that it seems the GNU's/FSF's issue with JavaScript is that the code is not always available (to view/peruse):

"It is possible to release a JavaScript program as free software, by distributing the source code under a free software license. If the program is self-contained—if its functioning and purpose are independent of the page it came in—that is fine; you can copy it to a file on your machine, modify it, and visit that file with a browser to run it. But that is an unusual case." [0]

JS code can obviously be client-side (generally readable in a browser via View Source, but not always, unless I am mistaken) or server-side (not generally readable, unless explicitly shared by the devs).

But based on [1] and [2] and [3], it appears that JS the language is owned and maintained by ECMA, which is a not-for-profit standards org.

So then I'm still a bit confused as to who whose lawyers would be coming after you if you published some JS code on Github or your own web-site? Not the ECMA's right?

[0] [https://www.gnu.org/philosophy/javascript- trap.html](https://www.gnu.org/philosophy/javascript-trap.html) [1] [https://en.m.wikipedia.org/wiki/JavaScript](https://en.m.wikipedia.org/wiki/JavaScript) [2] [https://en.m.wikipedia.org/wiki/Ecma_International](https://en.m.wikipedia.org/wiki/Ecma_International) [3] [https://www.quora.com/Who-is-the-owner-of- javascript](https://www.quora.com/Who-is-the-owner-of-javascript)

<comment><USER8> You can publish as much of your own javascript code as you want under any license on your website or github, or anywhere. The issue they have is not with the ownership of javascript the language. The issue is that if you wanted to take the frontend code to Facebook, Google Maps, Office 365, or something like that, and modify it to create your own version, you have two problems. One, that it probably isn't allowed by the license and the Facebook/Google/Microsoft lawyers could come after you if you tried to redistribute it. Two, it's likely it will be very difficult to attempt to do that because the code is intentionally obfuscated by a javascript minifier.

<comment><USER6> Thanks for that.

So really their (FSF/GNU) issue is not with JS at all, but with devs who don't licence their code under a free software licence? In other words, who enforce the copyright of their own algorithms?

What I also find a bit confusing (inconsistent?) with this stance is that a dev can do a reasonable amount of interesting things with HTML+CSS+SVG (obviously there are limits on the 'interaction' side of things), and assumably devs can also licence their HTML+CSS+SVG under whatever licence they wish: so then why pick on JS?

<comment><USER8> I think they would if we got to a point where HTML+CSS+SVG alone was turing- complete and became useful enough to perform general computations, and large programs were written in it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Only Stallman would begin a "reasons to not use Google" post with a rant about modern webpages requiring JavaScript, as if there aren't a million higher priority reasons _TO DUMP GOOGLE_.

I can't help but feel that having such an extremist as the face of the FSF has greatly hindered it in its mission.

<comment><USER10> Stallman is the diametric opposite of Google. As such he is ground zero of the opposition. He raises awareness and has concrete if impractical solutions. The truth we seek is, IMO, somewhere close to the Google/ad network and Stallman/privacy concerns nexus.

<comment><USER9> That's like saying Fascists and Communists are polar opposites. They may disagree completely on economic policy, but they're both authoritarian assholes. Stallman is only for "freedom" as long as it's his complete and unwavering vision for his personal freedom, damn everyone else.

<comment><USER11> I don't know if I see how your analogy extends to this situation. Are you saying you like neither Stallman or Google?

<comment><USER9> Yes, they're two sides of the same, "my way or the highway" coin. Stallman has made it clear that he would destroy the right of private digital property, if he had the power.

<comment><USER8> I don't know how you draw that conclusion. The goal of the FSF, since the beginning, has been to make a computing platform that the user has full control over. They aren't the ones trying to push everyone's data into the cloud.

</comment></comment></comment></comment></comment></comment><comment><USER12> I understand Stallman's viewpoint, but his personal website looks like a litany of complaints :)

"What's bad about: Airbnb | Amazon | Amtrak | Ancestry | Apple | Discord | Ebooks | Eventbrite | Evernote | Facebook | Google | Intel | LinkedIn | Lyft | Meetup | Microsoft | Netflix | Patreon | Pay Toilets | Skype | Slack | Spotify | Twitter | Uber | Wendy's |"

<comment><USER13> _> Pay Toilets_

While I understand the moral absolute standpoint, he fails to state how he sees such free facilities being maintained. While in many areas this can be done by local councils and paid for via relevant taxation, or by requiring local businesses to provide free facilities as part of their requirements of doing business in the area, those options do not cover everywhere (and the latter will be fought hard by business lobbying groups).

I hope he isn't naive enough to expect to be able to rely on human nature meaning the general public will keep free facilities in good working order and in a sanitary state!

<comment><USER14> Stallman lives in a particular bubble and that bubble has defined his viewpoints to a degree that he cannot fathom not being able to live his life in that way.

The question of "who does that" or "who pays for that" ultimately comes down to some form of slavery or coercion. Or the question is just avoided. Because "capitalism is evil". Or "what about wage slavery". Or something about how we have intrinsic value as sentient beings and shouldn't be required "to provide value" in order to "just survive".

And I'm like "Ok. But who cleans the public toilet?" How do you get someone to agree to that? I'll clean _my_ toilet, sure. But I'm not cleaning the public toilet unless I'm being forced to or I'm being compensated for doing so.

<comment><USER11> Using the words "slavery" and "coercion" makes taxes sound like a horrible idea, but I don't think it's a radical idea to have clean public toilets paid for by taxes.

<comment><USER15> Its the perfect use case of taxes: a pool of money for public well being. Being able to pee freely in a sanitary area and not on the ground is benefitting the public well being.

</comment></comment></comment></comment></comment><comment><USER16> Or all the Google properties, I believe YouTube has the biggest moat and the barrier to exit, for users if not creators, because of all the content on it.

Given that all this content is publicly available, And I believe there were some legal cases, such as LinkedIn v. HiQ one, which, IMNAL, but allowed scraping of public content, I wonder if an entity can legally scrape YouTube and provide non-Google access to it, while preserving creator's copyright?

<comment><USER17> Definitely. Youtube is pretty much the only Google service I still use regularly (unless chromecast counts).

</comment></comment><comment><USER18> The biggest problem with google is not the JavaScript but the fact hat if they delete your account you lose everything including YouTube, gmail, saved stuff, etc. and appeal is virtually impossible. Anyone that relies on google accounts is at risk of having their account closed for arbitrary reasons.

<comment><USER19> You can take your data out before that.

<comment><USER20> No you can't. When Google blocks your login, there's no way to get your data out. This happens constantly with someone posting on Hackernews as their support channel when this happens to them.

</comment></comment></comment><comment><USER21> Had no clue about Google storing purchases made connected to a gmail account. That is discomforting.

<comment><USER22> Your gmail account stores the purchases.

Google can help you search the purchases.

If you see either of those as odd, then I pretty much don't get your viewpoint.

But sure, the next question is does Google explicitly USE that data in any other way. That's a different question, though.

<comment><USER21> it doesn't store the purchase, it stores the email, then parses it into a list of purchases. Also if you delete the email, the purchase list remains.

</comment></comment></comment><comment><USER23> add (2015)

read more here

[https://news.ycombinator.com/item?id=13342941](https://news.ycombinator.com/item?id=13342941)

</comment><comment><USER24> Can someone explain this quote to me?

>Then again, maybe you shouldn't eat any fast food. It is meant for fasting, not for eating.

</comment><comment><USER18> it must be a lot of fun being with this guy , not being able to use so many services

<comment><USER21> This is THE Richard Stallman. He would be fascinating to hang out with and hear his thoughts.

<comment><USER25> His pedantic personality is unbearable to me.

He held a talk at my university recently. During the QA, every time a student asked RMS a question, he would spend 2 minutes correcting the formulation of the question, and then dismissing the actual question with a snarky remark.

For instance, one student asked something about RMS being the "CEO" of FSF, followed by snarky remarks by RMS that "FSF is not a company and that he is actually the president". (I might remember wrong, but it was something along those lines)

I understand and respect him and his beliefs, but his personality just annoys me.

<comment><USER26> RMS might appear a bit difficult at times, but I don't think that was a good example. Other left-leaning founders of public benefit organizations might be mildly insulted by being called CEO as well.

</comment></comment></comment></comment><comment><USER27> What we are building is the perfect society for the rule of individualism. Capitalism is the god, greed is the motivation, and not being liable is how we be careful.

There's no way out. Even TNG predicted WWIII entire global population and for humanity to suffer its most embarrassing chapter to get out of it:

[https://memory-alpha.fandom.com/wiki/World_War_III](https://memory- alpha.fandom.com/wiki/World_War_III)

There are other modes of life, based on trust of mankind, instead of fear of it. That's the other thing TNG shows - all those people in Starfleet - <USER2> aren't being paid to be on that ship. They're trying to show that humanity is capable of post-capitalism. It doesn't have to be this way.

(That's the planet Stallman lives - or at least wants to)

<comment><USER14> The ship also cleans itself.

The Federation is a post-scarcity society. They've figured out how to change matter into energy and back again. That does change a lot of things. We don't get to the Federation without solving scarcity.

And while no one is being paid to be on that ship (although that is debatable as there does seem to be some form of currency that individual Starfleet members receive and use), there is competition to be on that ship.

 _Being_ on that ship is the compensation for the work. Being one of the few selected to essentially be in this sort of elite class is the privilege.

And even on the ship, there are differences between crew members. The captain's quarters are better than the lower officers. The captain has his own private office just off the bridge.

And being a television show and work of fiction, they get to gloss over a ton of stuff. The acquisition and creation of the materials to build something like the Enterprise is as much a fantasy in the work as is the fact that they can replicate Earth-like gravity in the middle of space.

<comment><USER27> I get all that - I am just kinda hoping for you know, something between what we have and what we look forward to / dream about. I won't be disappointed if we go further away from 1985 and closer to TNG even if we never reach it.

<comment><USER14> I think you mean 1984.

And our current system _is_ driving us more towards TNG than 1984.

Things are better now. We're more tolerant. More peaceful. By just about any measure you can take, we're becoming better.

</comment></comment></comment></comment><comment><USER28> To Stallman one of the only technologies that's ok is Emacs running in some linux distro where your wifi might not work out of the box.

Wired connections are also a problem for him as well since the provider has your identity and they can trace you.

Stallman's rants, while they might not be technically wrong, should be read in the context of someone whose mindset is not the most positive one.

<comment><USER27> Meh, that's subjective - he's extremely cogent if you watch or read his talks. If you turn your mind to think that the society we are in is not the healthiest one, then he's very healthy.

</comment></comment><comment><USER29> I found it interesting that OP chose to post the page for Google specifically, when there are many other services/companies listed on that page.

Turns out, pearjuice is a Trump supporter ([https://news.ycombinator.com/item?id=12675679](https://news.ycombinator.com/item?id=12675679), [https://news.ycombinator.com/item?id=12741738](https://news.ycombinator.com/item?id=12741738), [https://news.ycombinator.com/item?id=12675971](https://news.ycombinator.com/item?id=12675971)) and hence has a reason to target Google, which is known for its employees opinions against Trump ([https://www.nytimes.com/2018/09/12/technology/leaked- google-...](https://www.nytimes.com/2018/09/12/technology/leaked-google-video- trump.html)) and conservatives in general.

This does not take away from the validity of the points made on the link itself, but I thought it worth mentioning.

<comment><USER30> Distrust and dislike for Google transcends political ideology.</comment></comment>


Disagreeing with Matt Cutts - <AUTHOR> http://blog.fairsoftware.net/2011/02/04/is-matt-cutts-turning-into-a-marketing-drone-and-other-stuff-i-shouldnt-say/

<comment><USER2> [meta] Someone decided to change the title to "Disagreeing with Matt Cutts" and the post got flagged and promptly disappeared from view. Because clearly it's better for debate if you hear only one side of the argument, right?

The real discussion is that Microsoft is spying (legally) on their users behavior. And Google can't call them on it because they do the same, so they cry copy-wolf.

<comment><USER3> > _And Google can't call them on it because they do the same_

Didn't Matt categorically deny that Google uses Bing's users' clicks in Google's rankings.

edit: just after the 10:30 mark. <http://bigthink.com/ideas/26740></comment></comment>


Two Hidden Features Firefox 3 - <AUTHOR> http://www.sitepoint.com/blogs/2008/05/23/two-hidden-features-new-in-firefox-3/ <comment><USER2> Not exactly "hidden", but the two new features in the article are soft hyphens (for automatic mid-word line breaking) and CSS display:inline-block. Good stuff, although it's a shame that it hasn't been supported earlier, the Mozilla team have been slow to catch up on these.

The soft hyphens are going to be tedious in practice if you're going to have to insert them manually. LaTeX does automatic breaking, has anyone used any stand-alone libraries that will insert the soft hyphens into a given chunk of text automatically? The rules for this are different for each (human) language, so it's not a 100% trivial problem; in some cases soft hyphen support alone might not be enough, such as in case of the now obsolete German way of breaking words containing ck into k-k. (the new rule is that the ck isn't broken up and moved onto the new line entirely, so soft hyphens will work now)</comment>


Eric Schmidt says Elon Musk is 'exactly wrong' about AI - <AUTHOR> https://techcrunch.com/2018/05/25/eric-schmidt-musk-exactly-wrong/ <comment><USER2> I agree Elon Musk is wrong. a corporate dis-utopia is way more likely than a robot takeover.</comment>


Show HN: BotList Messenger Bot - <AUTHOR> https://www.messenger.com/t/botlistco <comment><AUTHOR> We launched BotList one year ago today, and to celebrate, we're releasing a new version of our Messenger Bot.

Search for bots across all platforms, not just Messenger, to find the best bot for your needs, with the connivence of searching in a Bot :)

We hope to release additional bots for other platforms in the near future.

<comment><USER2> Would really love to see a search voice bot on Amazon.</comment></comment>


George Osborne closes tax loophole on music and book downloads - <AUTHOR> http://www.theguardian.com/music/2014/mar/23/george-osborne-tax-loophole-music-downloads

<comment><USER2> Isn't this the same thing Italy tried to do only to get shot down by the European courts ? Bound to make the EU even less popular in the UK though.</comment>


Ask HN: Are there any jobs yet in WebAssembly? - <AUTHOR> When I Googled about it recently, I saw one post at Apple and maybe one at Google. But even then, WASM was just listed as a nice-to-have on top of other job specifications. <comment><USER2> I mean, webassembly bascially _is_ a technology on top of others, either being a compile target for or an input to software that needs additional skills to write.

<comment><USER3> is it "a technology on top of others"?

Would you say the same about LLVM? How is it any different? I've never heard anyone say anything like "oh, well LLVM is a technology on top of ..." They're both compile targets that run within a VM right?

Now, I'd agree that there aren't many jobs "in LLVM". There are just a handful of folks working on LLVM compilers and VMs. For the same reason I wouldn't expect any jobs "in WASM" any time soon, other than ones working on compilers targeting the format or enabling other language runtimes to consume it.

<comment><USER2> Well, LLVM is a specific project, so "working on LLVM" is a lot clearer than "working on WebAssembly" (which would be spec work I guess).

And e.g. if we're talking about improving WebAssembly support in LLVM, I'd primarily consider that an LLVM job: Familarity with LLVM, compilers, ... is probably more important than knowing WebAssembly. If you work on a project targeting WebAssembly in the end, knowing the source language (and if targeting the browser, browser APIs) is probably the primary part.

I agree that "on top of others" wasn't the best wording. Another attempt at describing what I meant: You're unlikely to be a "WebAssembly developer", in the same way that you won't a be a "LLVM IR" developer, and "x86 assembly" developers are rare. Way more commonly, knowing about those lower-level things are an add-on to the primary label, e.g. useful things for a C++ developer to know. I don't think WebAssembly is big enough that a specialist role of e.g. "WebAssembly on $platform performance expert" would be a job description yet, even if there's maybe already a few people being effectively that.

</comment></comment></comment><comment><USER4> Kitware is currently working to use WebAssembly to deliver our open source C++ medical image analysis library (ITK) in the browser as itk-js. By looking at the commit history of that repo, [https://github.com/InsightSoftwareConsortium/itk- js/graphs/c...](https://github.com/InsightSoftwareConsortium/itk- js/graphs/contributors) , you can see that no one at the company works full time in WebAssembly, but a decent number of us touch on it fairly regularly.

</comment><comment><USER5> I've been wondering the same thing since I've been focusing on UI development lately, but AFAIK most frontend development is currently Angular/React/Vue and a bit of Svelte

</comment><comment><AUTHOR> All of these are pretty good points. It makes sense that there aren't many jobs specifically focusing on WASM yet or that anyone working on it now is still seen as a Front End Developer who just does the WASM stuff.

Thanks everyone!

</comment><comment><USER6> These guys might have wasm related work. [https://www.linkedin.com/company/wasmerio](https://www.linkedin.com/company/wasmerio)</comment>


Tesla Model 3 accounted for over 12% of Norwegian auto market in Jan-July - <AUTHOR> https://cleantechnica.com/2019/08/16/tesla-model-3-12-4-of-all-norwegian-vehicle-sales-january-july-2019/ <comment><USER2> It's depressing looking at the other EVs on that list. Where's my electric BMW 3 series?

Over the last decade people have been quite rightly pointing out that Tesla are in trouble because sticking some batteries and electric engines into a car isn't actually crazy difficult and all Tesla's production problems will kill it in competition with real car manufacturers. Yet somehow that just hasn't happened at all. The people who talked about the inability of large incumbents to react were dead right.

I'm still bearish on Tesla - I think they've pumped their share price with false claims about self-driving, but they have really dominated electric vehicles.

<comment><USER3> I was talking to a big wig at Ford the other day, without too much detail, he works on their EV program. He admitted they are behind and Tesla is actually way ahead of the competition in many areas.

It _is_ difficult to put a battery and electric engines in a car and they've run into difficulties. Though it sounds like they're on their way to putting out a decent EV, and he thinks they and others will eventually catch up.

He also thinks Telsa will ultimately be killed by Chinese battery manufactures, which I thought was interesting.

<comment><USER4> Did he say what areas Tesla was ahead in?

</comment></comment></comment><comment><USER5> For Norwegians currently looking for an electric car, it's a no-brainer. It's slightly more expensive than the Nissan Leaf 2 that has similar range, but you also get the option of a tow hitch, and the driving experience is in a different league. Plus access to supercharger network that actually works and doesn't require fifteen minutes of fiddling every time.

My parents just bought one in spite of having initially dismissed it as likely too expensive. Turned out to be perfectly competitive with everything that's comparable in range and features, and a much better user experience overall. We'll see how the service and reliability turns out, that's the only wildcard I can think of.

<comment><USER6> Can you expand on a few of your comments. I have an older Leaf in Japan and I've never seen a Model 3 before, so I'm curious about the difference.

\- "the driving experience is in a different league". In what way? I was surprised at how much I enjoy driving the leaf (except for very poor turning radius, which I can't quite understand). What's better in the Model 3?

\- "doesn't require fifteen minutes of fiddling every time". What does that mean? I don't have trouble charging my Leaf. Is that something specific about the supercharger network (which isn't in Japan), or are you referring to something else?

<comment> pi-rat Not OP, but..

The superchargers just work. Arrive, plug in, it's charging.

Other fast chargers are often much more cumbersome, requiring you to installing an app, registering an RFID tag, adding your credit card, etc. I've 6 different apps installed on my phone for different charging networks here in Norway, and 2-3 RFID tags in my car.

Many of them are also unstable, or have terrible UX and weird quirks. If you need to make a seven minute video[1] to explain how to use it, you're doing it wrong..

It's getting better though, software is improving, growing pains handled. A future CCS revision (the most used charge plug in Europe) will include "plug&charge" with payment handled by the car - making it more super charger like.

[1]: [https://www.youtube.com/watch?v=YLe5jvx0NkI](https://www.youtube.com/watch?v=YLe5jvx0NkI)

<comment><USER6> Really interesting. In Japan, the navigation unit on the Leaf has all of the charging stations built in. Then you plug it in and put your charging card on the proximity sensor (well, you have to push a button 3 times as well). But that's it. I think that's probably the advantage of owning the charging infrastructure. I'm very much wondering how the landscape will change once Toyota enters the fray (which I think it later this year if I'm not mistaken).

</comment></comment></comment></comment><comment> Pete-Codes I was speaking to a Norwegian friend last night and she confirmed it. There are so many incentives like paying less/no vehicle tax and yeah, they are 100% hydroelectric so they are perfect place. Might have to move there!

<comment><USER7> The Teslas are not more affordable there than in the US, they're just less of a bad option - petrol cars are taxed so heavily in the Nordics that it makes an electric a good value for money. You're still better off in the US though, where electric costs the same, but you have an option of reasonably priced petrol cars.

<comment><USER8> Well that's good that they're racing petrol cars and I applaud them for doing it. They're wealthy enough to be able to afford it. It's what's necessary to move away from carbon.

<comment><USER9> > It's what's necessary to move away from carbon.

You hear that a lot and yet the second someone poses the hypothetical question of whether everything should be taxed according to its actual "carbon lifecycle"# (and perhaps even beyond carbon) you usually get a "weelll... buuuuttt...".

#That [whatever] that came on the most polluting cargo ship humans could build? Add $xxx to the price tag.

<comment><USER10> I gather you are referring to the oft-quoted stat about the cargo ship being "more polluting" than so many millions of cars? That is referring specifically to SOx I believe. It definitely is not referring to carbon emissions. Container ships have the lowest gCO2/(km*kg)

<comment><USER9> It was more generic than that (see mention of beyond carbon). Otherwise we'd still be heavily promoting diesel as the clean alternative to gasoline. The cargo ship was just something to exemplify the point of taxing for destroying the environment. You're free to pick any example you feel suits better and the principle will still apply.

<comment><USER10> I'm all in favour of carbon tax to reduce emissions. They would result in pressure for electric vehicles of all sorts, improve the economics for renewable electricity, maybe increase funding availability for carbon capture research. Cargo ships would likely stay the same for a long time in the future (but might implement fuel reduction techniques that are at a lower TRL (thinking specifically of a long lead parasail/kite that I read about a couple years back)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> 1\. 100% taxes on petrol cars

2\. no VAT on electric cars

3\. average income of $3500 in Oslo, one of the highest in the EU

4\. total population of 5 million, less than Denmark, less than the city of Hong Kong

considering these facts i would say it is a bit surprising they didn't sell more than they did. but still great to see those number.

<comment><USER12> On point 3: Norway isn't in the EU.

On point 4: what does the population have to do with it? If they had a population of 50 million, would that negate points 1-3 in some way? Another way of describing their population might be, "roughly the same size as the average US state".

</comment></comment><comment><USER13> Some context: [https://en.wikipedia.org/wiki/Plug- in_electric_vehicles_in_N...](https://en.wikipedia.org/wiki/Plug- in_electric_vehicles_in_Norway#Government_goals_and_incentives)

</comment><comment><USER14> Looks like a quite different car market. The first 3-row SUV is the Mitsubishi Outlander in 6th place. The market looks like mostly compact sedans and compact/subcompact SUVs. There is a lack of pickups and mid/large SUVs.

From other sources, it appears that the VW Transporter/Caravelle and the VW Caddy both sell in volumes that would put them in the middle of the list. So there may be a difference in how light vehicles are classified between the US and Norway. [https://www.statista.com/statistics/731767/number-of-sold- va...](https://www.statista.com/statistics/731767/number-of-sold-vans-and- trucks-in-norway-by-model/)

<comment><USER15> Different than North America maybe. Not different from most of Europe.

</comment></comment><comment><USER16> With the price of fuel in Norway, it's not surprising to see people turning towards EV.

<comment><USER17> Surprising. Most oil-producing countries have dirt-cheap domestic fuel prices.

<comment><USER18> Norway is more forward thinking than most countries.

They know that oil is not going to make their country rich forever.

</comment></comment></comment><comment><USER19> It's actually interesting that there's no major American car in that list. Not even Bolt or Volt. :-/ Might not be much of a signal, but might be that the big 3 have really missed the road on EV.

</comment><comment><USER20> A car sold today is more likely than not to still be on the road in 2030. Meeting our 2030 goals would be a _lot_ easier if the majority of cars sold this year were zero-emissions world-wide.

</comment><comment><USER21> In the UK company car market, Tesla 3 seems be making a smash for similar reasons - a friend currently pays almost 6k in tax on their car - but is changing their fleet to Tesla's - and that 6k cost vanishes for same price to the company - effectively a 6k salary hike.

That will make a huge difference if marketed right.

</comment><comment><USER22> Tesla sales in Norway are down quarter over quarter. See [http://eu- evs.com](http://eu-evs.com).

</comment><comment><USER23> I do wonder how the electrical grid in Norway is going to hold up to the massive increase in demand that EV charging will cause.

<comment><USER2> Norway is in a great position, they're world leaders in hydro and their geography makes that a great source of energy. In 2015 Norway's Hydro-electric generation accounted for 95.8% of it's electricity generation. Norway accounts for _half_ of Europe's entire hydro reservoir capacity. Meanwhile if demand rises they can also import electricity via the North Sea wind power hub, or from Sweden.

That's one of the great things about electric cars in Norway - you're actually going to get electricity from renewable sources.

<comment><USER24> What is the ecological impact of hydro there? In the US PNW we seem to be taking _out_ hydro due to fish rather than putting in new dams, although I haven't followed it closely

<comment><USER25> Building damns have a huge impact and there have been many fights over them as in Alta [1]. They also have a large CO2 cost [2] when being built as it requires massive amounts of concrete.

However they are now built and there is still plenty of capacity so there have been no new major ones built for a long time.

There are some smaller privately owned ones being built but not on a big scale.

[1] [https://en.wikipedia.org/wiki/Alta_Hydroelectric_Power_Stati...](https://en.wikipedia.org/wiki/Alta_Hydroelectric_Power_Station)

[2] [https://en.wikipedia.org/wiki/Environmental_impact_of_concre...](https://en.wikipedia.org/wiki/Environmental_impact_of_concrete)

</comment></comment></comment></comment><comment><USER26> I'm waiting for a reliable long range battery vehicle. Most vehicles in Indian market have to replace batteries in 5yrs.

<comment> pi-rat Didn't the Hyundai Kona launch recently in India? I'm super happy with mine here in Norway. Comes with a 8 year battery warranty here. Easily does over 500 km per charge on Norwegian roads.

<comment><USER26> It did. But the issue is the price. It costs equal to an entry level Mercedes or Audi

</comment></comment></comment><comment><USER27> I still feel that only EV is not the answer. You have also get the electricity somewhere so some investment in modern nucler power plants and fusion would be even better then just blindly pushing EVs.

<comment><USER28> To get to zero carbon emissions we'll need both zero carbon transportation and zero carbon electricity. $100B's are being invested in zero carbon electricity, so your suggestion that EVs are taking away from that are mistaken.

As for nuclear, the US and Europe have been unable to build plants that do not go 3x+ over budget and time.</comment></comment>


"They call it swatting" - <AUTHOR> https://arstechnica.com/tech-policy/2017/12/kansas-mans-death-may-have-resulted-from-call-of-duty-swatting/ <comment><USER2> This is so terrible. My heart goes out to his family.</comment>


Django is only a framework - <AUTHOR> http://blog.alonsebastian.com.ar/post/15396980983/django-is-only-a-framework

<comment><USER2> The beauty of frameworks is that you _only_ need to focus on creating the content and user experience.

Much of the less interesting things like security features (think CSRF or salting passwords) have been taken care of by experts.

Frameworks also promote best practices (this is especially true for RoR) and take away the hassle of dealing with a database by providing a nice ORM layer.

<comment><AUTHOR> I know. However most people often miss this, that's the whole point of it. Real content comes from developers, not framework.</comment></comment>


Critical Flaw Found In Security Pros' Favorite: Backtrack Linux - <AUTHOR> https://threatpost.com/en_us/blogs/critical-flaw-found-security-pros-favorite-backtrack-linux-041112 <comment><USER2> BT5 isn't the only distro that ships with Wicd. Plus a lot of people install wicd as an alternative to NetworkManager anyway. I guess the "BackTrack 0day OMG!" title is more gripping though.</comment>


StrongLoop announces most complete process manager for Node.js clustering - <AUTHOR> https://strongloop.com/strongblog/node-js-process-manager-cluster-load-balancer/

<comment><USER2> Looks like this could be an alternative to pm2 that doesn't have the AGPL copyleft?

<comment><AUTHOR> The license is one benefit, yes... but the StrongLoop PM also has support for deployment across multiple machines and integration with nginx for load balancing. And everything can be monitored (including across machines) from a single GUI: StrongLoop Arc.

pm2 is great, but this is not an "added features" play, StrongLoop wrote this process manager from scratch based on experience with very large enterprise clients. In other words, this is a new beast entirely!</comment></comment>


HTTP/2.0 — Bad protocol, bad politics - <AUTHOR> https://queue.acm.org/detail.cfm?id=2716278 <comment><USER2> "HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc."

I wish the article had spent more time talking about these things rather than rambling about "politics".

"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier."

That would have destroyed any hope of adoption by content providers and probably browsers.

"HTTP/2.0 will require a lot more computing power than HTTP/1.1 and thus cause increased CO2 pollution adding to climate change."

Citation? That said, I'm not considerably shocked that web standards aren't judged based on the impact of whatever computing devices may end up using them on their power grids and those power grids' use of energy sources.

"The proponents of HTTP/2.0 are also trying to use it as a lever for the "SSL anywhere" agenda, despite the fact that many HTTP applications have no need for, no desire for, or may even be legally banned from using encryption."

In the same paragraph, the author complains that HTTP/2.0 has no concern for privacy and then that they attempted to force encryption on everybody.

"There are even people who are legally barred from having privacy of communication: children, prisoners, financial traders, CIA analysts and so on."

This is so close to "think of the children" that I don't even know how to respond. The listed groups may have restrictions placed on them in certain settings that ensure their communications are monitored. But this doesn't prevent HTTP/2.0 with TLS from existing: there are a variety of other avenues by which their respective higher-ups can monitor the connections of those under their control.

<comment><USER3> "HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier."

In fact there's no need for this to be tied in with HTTP/2.0 at all. Alternate systems could be designed without regard to HTTP/1.x or HTTP/2.y, they just have to agree on some headers to use and when to set them.

Making these kind of changes as part of a new version of HTTP would just be bloat on an already bloated spec, it is actually a good thing that the spec writers did not touch this!

<comment><USER4> Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially equivalent to a cookie (in terms of privacy, and ability of the client to control persistence).

<comment><USER5> It's really very simple:

Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits.

In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie.

If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session.

If instead you send a one bit in front of the 127 random bits, you tell the server that once _you_ consider this "session" over, and that you do not want them to track you.

Of course this can be abused, but not nearly as much as cookies are abused today.

But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.

<comment><USER4> Seems like anything a server could do via cookies, they could also do via your client-generated session id.

Servers which currently drop lots of individual cookies on you now, would just start dropping that data in the server-side session data. In either case they can tie your client to the same persistent information. Same for situations where javascript sets or gets cookie values - these could all be achieved via ajax, storing server-side against your session id.

If anything, it possibly reduces my options as a client, in situations where a site previously dropped lots of cookies on me, as now my only options are to completely close my session, or persist all data, when before there were situations where I could maintain, say, my logged in user session, while removing the "is_a_jerk=true" cookie.

<comment><USER6> Well, yeah, for a basic implementation, it's rather easy to track like that. What about a system where the unique id returned is based on a random value hashed with the domain name of the window? Then third party trackers would get a different id from you on each site, but your sessions would be static on the site.

<comment><USER4> True it would make it difficult to do third-party tracking across multiple sites (unless there was server-side information connecting your accounts, like an email address). And leaving aside browser fingerprinting.

That could also just by achieved by disallowing third party cookies though - feels on the cusp of being a browser implementation problem (just stop allowing third party cookies).

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> > _The same browsers, ironically, treat self-signed certificates as if they > were mortally dangerous, despite the fact that they offer secrecy at trivial > cost. (Secrecy means that only you and the other party can decode what is > being communicated. Privacy is secrecy with an identified or authenticated > other party.)_

I'm frustrated to read this myth being propagated. We should know better.

In the presence of only passive network attackers, sure, self-signed certs buy you something. But we know that the Internet is chock-full of powerful active attackers. It's not just NSA/GHCQ, but any ISP, including Comcast, Gogo, Starbucks, and a random network set up by a wardriver that your phone happened to auto-connect to. A self-signed cert buys you nothing unless you trust every party in the middle not to alter your traffic [1].

If you can't know whom you're talking to, the fact that your communications are private to you and that other party is useless.

I totally agree that the CA system has its flaws -- maybe you'll say that it's no better in practice than using self-signed certs, and you might be right -- but my point is that unauthenticated encryption is not useful as a widespread practice on the web.

Browser vendors got this one right.

[1] Unless you pin the cert, I suppose, and then the only opportunity to MITM you is your first connection to the server. But then either you can never change the cert, which is a non-option, or otherwise users will occasionally have to click through a scary warning like what ssh gives. Users will just click yes, and indeed that's the right thing to do in 99% of cases, but now your encryption scheme is worthless. Also, securing first connections is useful.

<comment><USER8> Yes, pinning the cert, (i.e. TOFU - Trust On First Use) is exactly the right way to treat self signed certificates and under that model they offer real security. The idea that you can't do anything with self signed certs and nothing makes them okay is a much more troublesome untruth, IMO.

Rejecting self-signed certs and only allowing users to use the broken CA PKI model is the wrong choice. Browsers didn't get it right. The CA model is broken, is actually being used to decrypt people's traffic and though your browser might pin a couple big sites, won't protect the rest very well by default. It's a bad hack and we should fix the underlying issue with the PKI. I believe moxie was right, a combination of perspectives + TOFU is the way to do this.

Things that also work like this that we all rely on and generally seems more secure than most other things we use: SSH.

<comment><USER9> >TOFU - Trust On First Use

The scenarios where this works are pretty limited. Pretty much only a server you set up. Jane User has no idea if the first use of ecommercesite.com is actually safe. You generally do because you have other band access to that server to see the key or key fingerprint. Even that can be thwarted by a clever MITM attack.

>Things that also work like this that we all rely on and generally seems more secure than most other things we use: SSH.

Yeah, that's generally for system administrative access not general public access for the web. For that kind of access, you need higher safeguards, thus the CA system we have today.

</comment></comment></comment><comment><USER10> If _there are already so many ways to fingerprint via cookies, JavaScript, Flash, etc. that it probably doesn 't matter_ then why do cookies matter? That the EU parliament decided to pass some weird law is not much of an argument. They're not exactly known for their technological proficiency. And it did nothing for privacy. It only annoys people[1].

Sure, we could start with cookies. However, that would break a lot of the web with no immediate benefit.

On SSL everywhere (not "anywhere"), how much resources does it cost to _negotiate SSL /TLS with every single smartphone in their area_? Supposedly, not much[2]. I run https websites on an Atom server.

Frankly, that was rather unconvincing. Although it does seem likely than the entire process was driven by IETF trying to stay politically relevant in the face of SPDY.

[1] [https://github.com/r4vi/block-the-eu-cookie-shit- list](https://github.com/r4vi/block-the-eu-cookie-shit-list)

[2] [https://istlsfastyet.com/#cpu-latency](https://istlsfastyet.com/#cpu- latency)

<comment><USER11> For what it's worth, the cookie law in the EU is far more general than cookies, and had a totally different origin. Originally, the law was to require explicit consent when installing something on an electronic device, to combat malware. However, some clever politicians later realized that setting a cookie also "installs" something on an electronic device, and thus the law further known as the cookie law was passed.

If a webserver were to set some secure session identifier, the same laws still apply -- just as installing software without explicit consent is covered by the same law.

<comment><USER12> Not if you are using the session identifier for it's intended purpose, see the exceptions at: [http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#se...](http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm#section_2)

<comment><USER11> We all know how broad "intended usage" can be defined. Google has a cookie that is required for logging in into gmail (clearly intended usage), but is reusing that exact same cookie for tracking purposes.

Until there is actual legal precedence after people sueing businesses abusing these abilities, I have no idea how to interpret these laws other than "they are very broad and vague".

<comment><USER12> I don't think the laws are vague so much as how we use cookies today. With different mechanisms for different purposes it would (could) be much more transparent to the end users how things work. It would be more like the "save password" feature in various browsers. Of course since all the major browsers vendors also make money from ads this isn't really in their interest.

</comment></comment></comment></comment></comment><comment><USER13> The article is basically a rant. I was hoping the author would go more into layer violation issues.

Most of the interesting stuff from HTTP/2.0 comes from the better multiplexing of requests over a single TCP connection. It feels like we would have been better off removing multiplexing from HTTP altogether and then adopt SCTP instead of TCP for the lower transport. Or maybe he had other things in mind.

> There are even people who are legally barred from having privacy of > communication: children, prisoners, financial traders, CIA analysts and so > on.

This argument is quite weak, SSL can easily be MITMed if you control the host, generate custom certs and make all the traffic go trough your regulated proxy.

<comment><USER14> In the early days of SPDY there was an article comparing SPDY to HTTP/1.1 over SCTP. The short version was other than the lack of header compression, it got nearly all the wins of SPDY, except:

1) Unless tunneled over UDP (which has its own problems) failed to work with NATs and stateful firewalls.

2) HTTP(s) only environments (e.g. some big corporations) would not work with it; SPDY will look enough like HTTPS to fool most of these.

3) Lack of Windows and OS X support for SCTP (without installing a 3rd party driver) means tunneling over UDP.

<comment><USER15> What are the problems with SCTP over UDP, except the obvious extra (eight byte) overhead?

<comment><USER14> UDP is just not as reliable over NAT (mainly due to crappy NAT implementations). SCTP tries really hard to keep it working (including heartbeats on idle connections), but implementing the 50% of SCTP that HTTP benefits from over TCP will work exactly as well as HTTPS whereas SCTP over UDP runs into lots of tiny issues due to nobody having tested it on their $5 NAT before putting it in a wifi router or a DSL/CABLE modem.

</comment></comment></comment></comment><comment><USER16> I'll just leave this here: [http://www.w3.org/Protocols/HTTP-NG/http-ng- status.html](http://www.w3.org/Protocols/HTTP-NG/http-ng-status.html)

In 1995, the process began for HTTP to be replaced by a ground up redesign. The HTTP-NG project went on for several years and failed. I have zero confidence that a ground up protocol that completely replaces major features of the existing protocol used by millions of sites and would require substantial application level changes (e.g. switching from cookies to some other mechanism) would a) get through a standards committee in 10 years and b) get implemented and deployed in a reasonable fashion.

We're far into 'worse is better' territory now. Technical masterpieces are the enemy of the good. It's unlikely HTTP is going to be replaced with a radical redesign anymore than TCP/IP is going to be replaced.

Reading PHK's writings, his big problem with HTTP/2 seems to be that it is not friendly to HTTP routers. So, a consortium of people just approved a protocol that does not address the needs of one's major passion, http routers, and a major design change is desired to support this use case.

I think the only way HTTP is going to be changed in that way is if it is disrupted by some totally new paradigm, that comes from a new application platform/ecosystem, and not as an evolution of the Web. For example, perhaps some kind of Tor/FreeNet style system.

<comment><USER5> Yes, clearly nothing has changed since 1995 at all, obviously nobody has gotten any wiser or anything.

My big problem with HTTP/2 is that it's crap that doesn't solve any of the big problems.

<comment><USER17> You say that, but as a small site operator, my experience is that I add the characters "SPDY" to my nginx config, and clients are happy cause stuff loads faster.

Why did nothing happen since the HTTP1.1 spec? Everyone say around until Google decided to move stuff forward.

</comment></comment></comment><comment><USER18> I really don't understand this bit:

> Local governments have no desire to spend resources negotiating SSL/TLS with > every single smartphone in their area when things explode, rivers flood, or > people are poisoned.

I remember some concerns about performance of TLS five to ten years ago, but these days is anybody really worried about that? I remember seeing some benchmarks (some from Google when they were making HTTPS default, as well as other people) that it hardly adds a percent of extra CPU or memory usage or something like that.

Also, these days HTTPS certificates can be had for similar prices to domains, and hopefully later this year the Let's Encrypt project should mean free high quality certificates are easily available.

With that in mind, forcing HTTPS is pretty much going to be only a good thing.

<comment><USER19> On my load balancers it is more like 5-10%. Not terrible, but not trivial either. Also, it multiplies throughout the environment. If you are dealing with PII or financials, everything needs to be encrypted on the wire.

Load balancer decrypts, looks at headers, decides what to do, re-encrypts, down to the app tier, decrypt, respond encrypted, etc. I'm not saying that is a bad thing, but that's why some people get cranky.

Somewhat unrelated, compressed headers in HTTP 2.0 makes sense if you only think about the browser, it saves 'repeated' information. The problem is the LB has to decrypt them every time anyways, so someone still have to do the work, it just isn't on the wire. Server push on the other hand could be awesome for performance (pre-cache the resources for the next page in a flow) but also has the potential for abuse.

<comment><USER20> Why not just run unencrypted behind the load balancer? Unless they're on wholely different networks, it shouldn't be needed.. SSL termination makes sense at a load balancer, reverse proxy, etc.

<comment><USER18> Like how Google used to do it? [http://cdn01.androidauthority.net/wp- content/uploads/2014/06...](http://cdn01.androidauthority.net/wp- content/uploads/2014/06/SSL-Added-and-Removed-Here.jpg)

</comment></comment></comment></comment><comment><USER3> _Twenty-six years later, [...] the HTTP protocol is still the same._

Not true at all. Early HTTP (which became known as HTTP/0.9) was _very_ primitive and very different from what is used today. It was five or six years until HTTP/1.0 emerged, with a format similar to what we have today.

<comment><USER21> Thank you, I was going to point it out myself. Early HTTP was literally just this:

      GET /somepath

That's it. Nothing more (well, that and a CRLF), nothing less. The response was equally barren: just pure HTML. Existent page? HTML. Non-existent page? HTML error message. Plaintext file? HTML. (The text is wrapped in a <plaintext> tag.) Anything else? Probably HTML, though you could also deliver binary files this way (good luck reliably distinguishing HTML and binary without a MIME type)!

I actually like HTTP/0.9. If you're stuck in some weird programming language without an HTTP/1.1 client (HTTP/1.0 is useless because it lacks Host:, while HTTP/0.9 actually does support shared hosts, just use a fully-qualified URI) you can just open a TCP port to a web server and send a GET request the old fashioned way.

</comment></comment><comment><USER22> After learning how public key infrastructure really works, I've become quite disillusioned by the security it seems to provide. After all, what use is a certification authority, if basically any authoritarian state and intelligence service can get on that list? In some countries the distinction between government officials, spies and organized crime is already extremely blurry...

<comment><USER18> You can remove their CA certificates from your browser/OS and if you click the lock icon on your browser you can check what CA the website you're on was signed.

You're right to say that the PKI doesn't work if you just want to trust any site that shows a padlock in the address bar, but it's useful if you do a little work.

<comment><USER23> > You're right to say that the PKI doesn't work if you just want to trust any > site that shows a padlock in the address bar, but it's useful if you do a > little work.

Not it isn't. It still suffers from not respecting name constraints. You can't setup trust for only a list of domains. If i run my own CA for some list of domains, there is no way i can prevent my CA from being able to sign for google.com. Instead people use wildcard certs so they can be delegated responsibility for a subdomain.

<comment><USER24> You can get a certificate for a fixed list of domains.

If name constraints were implemented more widely, that'd be great. But someone has to write the code, debug it, ship it, etc, and then you have to wait until lots of people have upgraded, etc, and ultimately wildcard certs work well enough.

<comment><USER23> > If name constraints were implemented more widely, that'd be great. But > someone has to write the code, debug it, ship it

Without name constraints I assert the system is inherently broken. You cannot limit trust other than yes/no.

> ultimately wildcard certs work well enough.

Well enough is arguable. The problem is that your attack surface grows with each machine rather than having a private key per machine.

</comment></comment></comment></comment></comment><comment><USER25> Interesting that one of the primary developers of FreeBSD does not understand one of the two major use cases for SSL, namely identity assurance. News sites and local governments don't care about privacy when transmitting news or emergency information, true, but citizens should be concerned about making sure that information is coming from who they think it's coming from.

I'm no fan of HTTP/2, but this article does not effectively argue against it. Too many bare assertions without any meat to them. And when you fail to mention a major purpose of a protocol (SSL) you dismiss as useless, you lose a lot of credibility.

<comment><USER5> SSL does not provide identity assurance (=authentication), the CA-cabal does, SSL just does the necessary math for you.

CA's are trojaned, that's documented over and over by bogus certs in the wild, so in practice you have no authentication when it comes down to it.

Authentication is probably the hardest thing for us, as citizens to get, because all the intelligence agencies of the world will attempt to trojan it.

Secrecy on the other hand, we can have that trivially with self-signed certs, but for some reason browsers treat those as if they were carriers of Ebola.

<comment><USER26> That's an argument against showing scary warnings on self-signed certs, not against SSL. It would be nice if there was a httpr:// scheme that would be like HTTPS but without certificate checking.

<comment><USER5> I'm not arguing against SSL.

I'm arguing against making SSL mandatory, because that will force NSA to break it so they can do their work, and then we will have nothing to protect our privacy.

More encryption is not a solution to a political problem: [http://queue.acm.org/detail.cfm?id=2508864](http://queue.acm.org/detail.cfm?id=2508864)

<comment><USER27> > I'm arguing against making SSL mandatory, because that will force NSA to > break it so they can do their work, and then we will have nothing to protect > our privacy.

That line of reasoning sounds bizarre to me. It sounds like "don't add a lock to your door, because that will force the criminals to break the lock, and then your door will be unlocked".

<comment><USER5> A bad analogy is like a wet screwdriver.

Try this one, it's better, but not perfect:

Imagine what happened if some cheap invention turned all buildings into inpenetrable fortresses unless you had a key for the lock.

Now police can not execute a valid judge-sanctioned search warrant.

How long time do you think lawmakers will take to react ?

<comment><USER27> You were talking about the NSA breaking SSL, not lawmakers forbidding it.

If the problem is with the analogy, without analogies this time:

> I'm arguing against making SSL mandatory, because that will force NSA to > break it so they can do their work, and then we will have nothing to protect > our privacy.

Without SSL, our privacy is unprotected, since eavesdroppers can read our traffic. Now add SSL, and eavesdroppers cannot read the traffic. Then NSA breaks it, and eavesdroppers can read our traffic again - we've just circled back to the beginning. We will have nothing to protect our privacy, but we already had nothing to protect our privacy before we added SSL; and in the meantime before the NSA breaks it, we had privacy.

And it assumes that the NSA will be able to break it, and that the NSA is the only attacker which matters.

<comment><USER5> NSA does what the do because lawmakers told them to and gave them the money -- you cannot separate these two sides of the problem.

There are many ways to break SSL, the easiest, cheapest and most in tune with the present progression towards police-states is to legislate key-escrow.

Google "al gore clipper chip" if you don't think that is a real risk.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> Nitpick - It's HTTP/2 not HTTP/2.0

We've all learned from the failure of SNI and IPv6 to gain widespread adoption. (Thank you windows xp and Android 2.2) HTTP/2 has been designed with the absolute priority of graceful backward compatibility. This creates limits and barriers on what you can do. Transparent and graceful backward compatibility will be essential for adoption.

I agree, HTTP/2 is Better - not perfect. But better is still better.

<comment><USER29> Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good enough').

<comment><USER30> > Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the > same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good > enough').

HTTP/2 isn't really like IPv6 in that fewer people need to act to adopt it -- if the browser vendors do (which they are already) and the content providers do (which some of the biggest are already), then its used. Its specifically designed to be compatible with existing intermediate layers (particularly when used with TLS on https connections) so that as long as the endpoints opt in, no one else needs to get involved -- and with one of the biggest content providers also being a browser vendor who is also one of the biggest HTTP/2 proponents...

IPv6 requires support at more different levels (client/server/ISP infrastructure software & routers, ISPs actually deciding to use it when their hardware/software supports it, application software and both client and server ends, etc.) which makes adoption more complex.

<comment><USER31> _> > Not that I believe SNI and IPv6 are failures, but HTTP/2 faces exactly the same failure case as IPv6 (the lack of adoption due to HTTP/1.x being 'good enough')._

 _> HTTP/2 isn't really like IPv6 in that fewer people need to act to adopt it -- if the browser vendors do (which they are already) and the content providers do (which some of the biggest are already), then its used._

I, for one, welcome the HTTP/1.x+2 future of 5-10 years from now. (Obligatory [http://xkcd.com/927/](http://xkcd.com/927/) )

</comment></comment></comment></comment><comment><USER30> > The proponents of HTTP/2.0 are also trying to use it as a lever for the "SSL > anywhere" agenda, despite the fact that many HTTP applications have no need > for, no desire for, or may even be legally banned from using encryption.

What is the basis of this claim? ISTR that SPDY and the first drafts of HTTP/2 were TLS-only, and that some later drafts had provisions which either required or recommended TLS on public connections but supported unencrypted TCP for internal networks, but the current version seems to support TLS and unencrypted TCP equally.

<comment><USER32> Unencrypted HTTP/2 is a fake concession that isn't usable in the real world.

<comment><USER30> The only respect in which that appears to be true is that no major browser vendor has yet committed to supporting HTTP/2 other than over TLS-encrypted connections.

But given that that both some HTTP/2-supporting browssers _and_ much of the server-side software supporting HTTP/2 is open source, and given that all the logic will be implemented and the only change will be allowing it on unencrypted TCP connection, it'll probably be fairly straightforward to anyone who cares much to put the proof of concept of the value of unencrypted HTTP/2 together.

OTOH, the main _gain_ of HTTP/2 seems to be on secure connections, so I'm not sure why one would _want_ unencrypted HTTP/2 over unencrypted HTTP/1.1, and given that no browser seems to have short-term plans to stop supporting HTTP/1.1, there's probably no real use case.

But the _protocol_ supports unencrypted use just fine.

<comment><USER14> IIRC, the main issue with nonTLS HTTP/2 is broken web proxies. This is why Google deployed SPDY in https only, and also why they didn't use SCTP as the basis, but instead reinvented about 50% of it on top of TCP.

Google didn't want something that would break even a tiny percentage of existing installs.

</comment></comment></comment></comment><comment><USER33> As I keep having to mention: The omission of the use of SRV records is maddening, and the reasons given don't make any sense.

[https://news.ycombinator.com/item?id=8550133](https://news.ycombinator.com/item?id=8550133)

[https://news.ycombinator.com/item?id=8404788](https://news.ycombinator.com/item?id=8404788)

<comment><USER34> From the responses given to your linked comments, it seems like there was a technically valid reason not to use them: performance You just kept pushing that it wasn't a good enough reason. Are you just going to keep posting and asking until people decide you're right and they're wrong?

<comment><USER35> Take a better look at the responses. There's no inherent reason for the performance degradation (it's mainly because of noncompliance on Bind), and without it we are stuck with the much slower HTTP redirects.

<comment><USER33> Yes. Also CDNs and having your servers in the Cloud™ for automatic failover would be _no longer necessary_. So _of course_ every company providing these services are against it. These companies are also, of course, the "stakeholders" interested in development of HTTP/2.

</comment></comment></comment></comment><comment><USER36> The argument about computing power and CO2 pollution is misguided. HTTP/2 no longer requires encryption, so the TLS/non-TLS trade-offs remain the same as before (and their compute impact is mitigated by hardware AES support, etc.). The other relevant changes (SPDY, header compression, push) reduce the number of context switches and network round-trips required and the total time required for devices to spend in high power mode, and for the user to spend waiting. That results in a reduction, not increase, in total power consumption.

Taking server CPU utilization numbers as an indicator of total power consumption is pretty misguided in this context, and my understanding is that even those are optimized (and will continue to be optimized) to the point where TLS and SPDY have negligible overhead (or, in the case of SPDY, may even result in lower CPU usage).

<comment><USER5> Show me the mainstream browsers that will use HTTP/2 without SSL/TLS ?

The difference between you and me, may be that I have spent a lot of time measuring computers power usage doing all sorts of things. You seem to be mostly guessing ?

<comment><USER36> I don't have Kill-a-Watts or rack PDU data for fleets of webservers, unfortunately. What I do have is CPU performance data from running with and without SSL gateways and SPDY in production, and all I can say is that the server's CPU utilization is not significantly impacted by them. I also have client-side data that shows substantial load speed improvements when using SPDY. That should result in a C-state profile improvement on the CPU, but I'll need to collect more data to confirm.

</comment></comment></comment><comment><AUTHOR> phk (poul henning kamp) is the lead developer of varnish, in case people are not familiar with him.

<comment><USER37> His technical prowess are only matched by his privacy champion credentials, see e.g. his Operation ORCHESTRA talk [https://www.youtube.com/watch?v=fwcl17Q0bpk](https://www.youtube.com/watch?v=fwcl17Q0bpk)

<comment><USER38> > Local governments have no desire to spend resources negotiating SSL/TLS with > every single smartphone in their area when things explode, rivers flood, or > people are poisoned.

That's one horrible argument, though. The cost of a text-based protocol on ethernet, over TCP greatly outweighs the cost of the encryption process.

Yes, of course encrypting things will increase computational requirements yet the cost is negligible in comparison to the problem being solved (stopping the trade of personal data).

It's hard for me to associate a privacy champion with these statements.

</comment></comment></comment><comment><USER39> " _HTTP /2.0 could have done away with cookies, replacing them instead with a client controlled session identifier._"

It doesn't make much sense to get rid of cookies alone, not when there are multiple ways of storing stuff in a user's browser, let alone for fingerprinting - [http://samy.pl/evercookie/](http://samy.pl/evercookie/)

Getting rid of cookies doesn't really help with privacy at this point and just wait until IPv6 becomes more widespread. Speaking of which, that EU requirement is totally stupid.

The author also makes the mistake of thinking that we need privacy protections only from the NSA or other global threats. That's not true, we also need privacy protections against local threats, such as your friendly local Internet provider, that can snoop in on your traffic and even inject their own content into the web pages served. I've seen this practice several times, especially on open wifi networks. TLS/SSL isn't relevant only for authentication security, but also for ensuring that the content you receive is the content that you asked for. It's also useful for preventing middle-men from seeing your traffic, such as your friendly network admin at the company you're working for.

For example if I open this web page with plain HTTP, a middle-man can see that I'm reading a rant on HTTP/2.0, instead of seeing just a connection to queue.acm.org. From this it can immediately build a useful profile for me, because only somebody with software engineering skills would know about HTTP, let alone read a rant on IETF's handling of version 2.0. It could also inject content, such as ads or a piece of Javascript that tracks my movement or whatever. So what's that line about " _many HTTP applications have no need for [SSL]_ " doing in a rant lamenting on privacy?

HTTP/2.0 probably has flaws, but this article is a rant about privacy and I feel that it gets it wrong, as requiring encrypted connections is the thing that I personally like about HTTP/2.0 or SPDY. Having TLS/SSL everywhere would also make it more costly for the likes of NSA to do mass surveillance of user's traffic, so it would have benefits against global threats as well.

<comment><USER5> Actually, getting rid of cookies would fit almost all HTTP requests into a single packet, so there are tangible technical benefits, even without the privacy benefits.

You seem confused about cryptography.

Against NSA we only need secrecy, privacy is not required.

Likewise integrity does not require secrecy, but authentication (which doesn't require secrecy either).

You don't think that anybody can figure out what you are doing when you open a TCP connection to queue.acm.org right after they posted a new article, even if that connection is encrypted ? Really ? How stupid do you think NSA is ?

Have you never heard of meta-data collection ?

And if you like your encrypted connections so much, you should review at the certs built into your browser: That's who you trust.

I'll argue that's not materially better than unencrypted HTTP.

(See also Operation Orchestra, I don't think you perceive the scale of what NSA is doing)

<comment><USER39> The line on secrecy vs privacy doesn't make sense. Actually help me out, because I'm not a native English speaker - if you're implying that the NSA should be able to snoop in on my traffic without a warrant, as long as it keeps it secret, then I beg to differ.

Visiting an article doesn't happen only after it was posted. And surely the NSA can certainly figure out ways to track you, but their cost will be higher. Just like with fancy door locks and alarm systems, making it harder for thieves to break in means the probability of it happening drops. Imperfect solutions are still way better than no protections at all (common fallacy nr 1).

All such rants are also ignoring that local threats are much more immediate and relevant than the NSA (common fallacy nr 2).

On trusting the certificate authorities built into my browser, of course, but then again this is a client-side issue, not one that can be fixed by HTTP 2.0 and we do have certificate pinning and even alternatives championed by means of browser add-ons. Against the NSA, nothing is perfect of course, unless you're doing client-side PGP encryption on a machine not connected to the Internet. But then again, that's unrelated to the topic of HTTP/2.0.

<comment><USER5> With unencrypted HTTP, NSA can just grab the packets on the fiber and search for any keyword they want.

With a self-signed cert they would have to do a Man In The Middle attack on you to see your traffic.

They don't have the capacity (or ability! man of their fibertaps are passive) to do that to all the traffic at all the time.

The problem with making a CA-blessed cert a requirement for all or even most of the traffic, is that it forces the NSA to break SSL/TLS or CAs definitively, otherwise they cannot do their job.

Fundamentally this is a political problem, just slapping encryption on traffic will not solve it.

But it can shift the economy of the situation -- but you should think carefully what way you shift it.

<comment><USER27> > The problem with making a CA-blessed cert a requirement for all or even most > of the traffic, is that it forces the NSA to break SSL/TLS or CAs > definitively, otherwise they cannot do their job.

Isn't the whole point of pervasive authenticated encryption to prevent the NSA from "doing their job" (at least the spying part of it)?

> But it can shift the economy of the situation -- but you should think > carefully what way you shift it.

It shifts more than the economy of the situation. It also forces a shift from passive attacks to active attacks, which are easier to detect and harder to justify. Forcing the attacker to justify their acts has a political effect.

<comment><USER5> Pervasive authenticated encryption will not prevent the NSA from doing their job, as long as lawmakers think they should do their job.

Instead you will see key-escrow laws or even bans on encryption.

You cannot solve the political problem by applying encryption.

<comment><USER39> Laws against encryption will never be international. In the US it happened before [1], so there is indeed precedent. But such laws prevent a country from being competitive in the international marketplace, therefore many countries will not agree to it, just as they aren't agreeing with IP laws. And yes, I also believe that this trend on having national firewalls for censoring content will also not last for long, for the same reason.

What I love about technology is that it cannot be stopped with lawmaking.

[1] [http://en.wikipedia.org/wiki/Export_of_cryptography_from_the...](http://en.wikipedia.org/wiki/Export_of_cryptography_from_the_United_States)

<comment><USER5> The historical evidence that technology cannot be stopped by lawmakers is very weak, if it even exists in the first place.

Very few lawmakers have really tried, and few technologies have been worth it in the first place.

The relevant question is probably if technology can be delayed by lawmaking and how long time.

There is no doubt however that policies can be changed, most places it just takes elections but a few places may need a revolution.

Thinking this is a problem you can solve by rolling out SSL or TLS is incredibly naive.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER40> _" HTTP/2.0 will be SSL/TLS only"_

Yes! Finally 99% of users won't be hacked by a default initial plaintext connection! We finally have safe(r) browsing.

 _" , in at least three out of four of the major browsers,"_

You had ONE JOB!

Jokes aside, privacy wasn't a consideration in this protocol. Mandatory encryption is really useful _for security_ , but privacy is virtually unaffected. And the cookie thing isn't even needed; every browser today could implement a "click here to block cookies from all requests originating from this website" button.

We need the option to remove encryption. But it should be the _opposite_ of what we currently do, which is to default to plaintext unless you type an extra magic letter into the address (which no user ever understands, and is still potentially insecure). We _should_ be secure by default, but allow non- secure connections if you type an extra letter. Proxies could be handled this way by allowing content providers to explicitly mark content (or domains) as plaintext-accessible.

The problem I fear is as everyone adopts HTTP/2 and HTTP/1.1 becomes obsolete (not syntactically but as a strict protocol) it may no longer be possible to write a quick-and-dirty HTTP implementation. Before I could use a telnet client on a router to test a website; now the router _may_ need an encryption library, binary protocol parser, decompression and multiplexing routines to get a line of text back.

</comment><comment><USER41> HTTPS can also be used to protect you from malware [1] [2] and stop censorship [3]. If anything, news sites should be among the first to adopt strong HTTPS connections since many people visit them and the news also needs to not be censored.

[1] [https://citizenlab.org/2014/08/cat-video-and-the-death-of- cl...](https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/)

[2] [http://www.ap.org/Content/AP-In-The-News/2014/AP-Seattle- Tim...](http://www.ap.org/Content/AP-In-The-News/2014/AP-Seattle-Times-Upset- About-FBI-Impersonation)

[3] [http://ben.balter.com/2015/01/06/https-all-the- things/](http://ben.balter.com/2015/01/06/https-all-the-things/)

As for the performance side, SPDY is probably not perfect, but it seems to generally improve over current HTTP, even if it uses secure connection. But even if it didn't, using HTTPS seems to add negligible overhead, and compared to the security it gives I think it's well worth it.

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

</comment><comment><USER42> A very well written rant.

HTTP is supposed to have had opportunistic encryption, as per RFC 7258 (Pervasive Monitoring Is an Attack, [https://news.ycombinator.com/item?id=7963228](https://news.ycombinator.com/item?id=7963228)), but it looks like the corporate overlords don't really understand why is it at all a problem for the independent one-man projects to acquire and update certificates every year, for every little site.

As per a recent conversation with Ilya Grigorik over at nginxconf, Google's answer to the cost and/or maintenance issues of https --- just use CloudFlare! Because letting one single party do MITM for the entire internet is so sane and secure, right?

</comment><comment><USER26> What's exactly the difference between cookies and session identifiers exactly? There's no law requiring you to send kilobytes of cookies (news.ycombinator.com gets by with a 22-byte cookie). Of course the way HTTP cookies handle ambient authority is _rather imperfect_ , but that can be solved within the system.

<comment><USER5> The difference is who makes the decisions: session id is controlled by the client. cookies by the server.

FaceBook, Twitter etc. track you all over the internet with their cookies, even if you don't have an account with them, whenever a site puts up one of their icons for you to press "like".

With client controlled session identifies, uses would get to choose if they wanted that.

The reason YC gets by with 22 bytes is probably that they're not trying to turn the details of your life into their product.

</comment></comment><comment><USER43> > The so-called "multimedia business," which amounts to about 30% of all > traffic on the net, expresses no desire to be forced to spend resources on > pointless encryption.

I thought that "pointless encryption" was basically the definition of DRM? And the largest video site, traffic-wise (YouTube) is already encrypted.

<comment><USER11> I thought Netflix was the largest video site, traffic-wise?

<comment><USER43> Seems like it depends on who you ask. I imagine something closer to the truth is that Netflix are bigger in the US but YouTube are bigger globally.

</comment></comment></comment><comment><USER44> > _the IETF can now claim relevance and victory by conceding practically every > principle ever held dear in return for the privilege of rubber-stamping > Google 's initiative._

What principles does he claim the IETF is conceding here?

</comment><comment><USER45> > One remarkable property of this name is that the abbreviation "WWW" has > twice as many syllables and takes longer to pronounce.

World Wide Web

Dou Ble U Dou Ble U Dou Ble U

I count three times as many, is this an accent thing?

<comment><USER34> I think it's an accent thing. When I say WWW at normal speed, it sounds more like dubble-u dubble-u dubble-u. American, east coast USA.

<comment><USER46> Unless you say "duh blew duh blew duh blew", you're still using 9 syllables rather than six 6.

<comment><USER34> I'm not arguing that it's nine syllables, just saying that it's most likely an accent / speed of speech thing as far as the author's six-vs-four thing goes.

</comment></comment></comment></comment><comment><USER47> Couldn't agree with most of this more. HTTP/2.0 seems to be me to be an entirely pointless set of unwanted complications and agendas disguised as technical improvements.

</comment><comment><USER48> "Has everybody in IETF forgotten CNN's exponential traffic graph from 14 years ago?"

Any ideas?

<comment><USER49> I guess it's a reference to september 11th 2001.

</comment></comment><comment><USER50> Upvoted, not because I think it is a particularly good article, but we seem to have a pretty good discussion based on it.

</comment><comment><USER5> I have go go shopping and cook dinner, but if I'll be back in a couple of hours.

Poul-Henning

</comment><comment><USER51> I dont care about IETF or HTTP/2.

Ill just keep using HTTP/1.1. It works on my computer.

</comment><comment><USER52> When an article about technical problems with a protocol starts whining about how the protocol will increase CO2 pollution I know it's BS. WTH was the ACM thinking by wasting out time with this crap?

</comment><comment><USER53> This is the sort of self-important technorant that I've come to despise in tech news. It is another example of a blogger pandering to readers' absurd addiction with outrage. HTTP/2.0 is not an outrage. It is imperfect, just as HTTP/1.1 is imperfect and ill-suited to today's rich web applications that were not envisioned at its inception.

[edit] It's a bit ironic that this story was delivered to many of us (via Hacker News) over SPDY--HTTP/2.0's dominant source of inspiration.

<comment><USER54> Considering phk works as a developer for a very popular HTTP based application (Varnish) and contributed to competing specs for HTTP2 he's hardly a pandering blogger. He's an expert annoyed that the improvements in standards in his field are absurdly slow and perfectly entitled to voice his ire.

<comment><USER53> He is no doubt perfectly entitled to rant. I'm also fairly confident that phk has contributed to more important projects vital to the tech ecosystem than I ever will. I simply argue that there are more constructive and productive ways to go about pointing out a protocol's flaws.

Phk has had issues with the process for quite some time, and I feel that his embitterment about the process has jaded his view of the protocol. Phk on SPDY/HTTP/2.0 [http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/...](http://lists.w3.org/Archives/Public/ietf-http- wg/2014AprJun/0815.html)

<comment><USER55> "I simply argue that there are more constructive and productive ways to go about pointing out a protocol's flaws."

Which he has done: [https://www.varnish- cache.org/docs/trunk/phk/http20.html](https://www.varnish- cache.org/docs/trunk/phk/http20.html)

It's a pet peeve of mine when people just fling this sort of accusation about as if every _word-count limited column_ isn't any good unless it's 20 times longer and basically includes half of Wikipedia transitively. It's a column in a trade magazine. There isn't a place for a detailed technical discussion there, so complaining that there isn't one is complaining about something that can't be fixed.

Besides, cards on the table, I think he's basically correct, cynicism and all here. Sometimes the right answer is to just say no, and failure to say no is not good thing when that is what is called for.

<comment><USER53> "Which he has done: [https://www.varnish- cache.org/docs/trunk/phk/http20.html"](https://www.varnish- cache.org/docs/trunk/phk/http20.html")

You are highlighting my point. The arguments made here are far more pragmatic.

My qualms are with how his points are made in the original blog post, not with what points he is making; many of which are quite valid.

With that said, the totality of his argument allows the perfect to be the enemy of the good. Which in my opinion is an invariably flawed position.</comment></comment></comment></comment></comment>


Ask HN: How do you manage your obsession - <AUTHOR>

After few years of reading more than a few articles on startups and more than hundred books (audible + kindle only) it is hard not to think about it good part of the waking time and harder not to talk about it at all. But your friends do not quite understand what you are talking. Specially when your family and friends think that, you have a job that pays, a nice family (this is true) and a "hobby" of reading about startups but they are very annoyed when you sometimes (they view as almost always) skip the weekend funs for doing some boring stuff staring at the monitor. Some will say, some will be nice not to say, but still will think about almost certainly. Worse part is there is no way to argue any of these since you have nothing tangible in your hand other than few stories X lines of code or a working beta where users grow not in millions, not even in thousands but just a few every week. <comment><USER3> Sounds like you have a great life. I would not take it for granted.

I think that you have to be careful about the start-up dream stories. They are like chocolate cake. Eating it makes you feel good, and you want to eat a lot of it, but it is not good for your long-term health or happiness. Time spent reading a start-up book or story is time you will never get back.

If you are serious about starting a start-up, you have to be working tirelessly on the product. This is what I have gathered from watching start-up school videos. It seems that people who are successful focus on building the product (and catering to their user base) for much of their waking hours.

I am being sort of a hypocrite though, because I peruse Hacker News almost daily! Haha, but I do spend a good amount of time trying to build a product, too. I feel less guilty about reading so much by taking action to try and counteract the lost time. At least, it works that way in my mind.

<comment><AUTHOR> Thanks for your thoughts. Its not the glorious part that is interesting- but to create something that helps people. Right now I am working on a hardware device that will make communication easy specially for older and challenged people. But if it works it should crate more than a few jobs (one of which can be mine).

<comment><USER3> That sounds heart-warming! Do you have a blog or something that you track your progress with? I understand that hardware is difficult because you have to keep a lot of things secret. I am pretty curious now. Do you live in the states? There are lots of accelerators other than YCombinator (if you have not applied there yet).

<comment><AUTHOR> I have not shared anything on blog yet. The idea is actually very simple - <USER2> much thing to hide - but it is not easy to implement without at least basic knowledge in telecom and electronics. Here are the ideas- A video phone system attached to a TV + webcam that can be operated with only a remote control. As a side effect we have Netflix, Hulu-Plus, youtube etc. on it for free. I use arduino for remote control part using a infra-red sensor and it is connected to a beagle bone black. BBB controls the communication. I use SIP for signaling. It will to be sub 40$ I guess when custom built and manufactured as a single device. A media capable home phone - nothing new or special but hopefully easier to use than existing ones. Still need to answer why someone use it instead of Skype. I am mostly depending on its design rather than cutting edge technology.

All the parts work separately but need to make a solid device that does not fail. I have talked to my friends in here, Europe, Australia and Asia- it works ([https://www.facebook.com/w3voice](https://www.facebook.com/w3voice) has some video call photo) - they don't have the device yet- but my system works from browser with webrtc as well (no plugin required for firefox and chrome). The ssl certificate has expired (was using a 3 month trial) so can not share the site now. But prototype to product seems harder than I thought while doing weekends only. I even needed to buy a wooden box for this. This is frustrating because I am sure I will need to change things before people finds it interesting. So, need to build one as soon as possible. As it is now it may be actually a bad idea.

And yes, I live in Seattle area in Washington (west one). I did not think YC or anyone would be interested to find a solo guy working from living room with probably a bad idea in the first place (I have not applied to any yet- including YC). I was planning to complete it in a few months and go for them. I got few people interested to buy, so will have some customers as well.

</comment></comment></comment></comment><comment><USER4> It's important to seek-out like minded people, especially those that have successfully a chartered a similar path. As for competing time demands with family/friends. We all have that. Eliminating time wasters like TV & web surfing can be huge.

<comment><AUTHOR> Like minded people - yes- that would help. Sometimes it helps when people thinks about computer startup process instead of shoes when you use the word "boot".

</comment></comment><comment><USER5> Famous inventors like Tesla and Frederik Chopin had quite bizarre working habits[1] that became part of their mythos, so go ahead and embrace your obsession as much as possible - without harming your relationships and losing your humanity.

[1] [http://cbpowerandindustrial.wordpress.com/2014/05/09/work- ri...](http://cbpowerandindustrial.wordpress.com/2014/05/09/work-rituals- famous-inventors-artists/)</comment>


Restarting Live Music: Band Members Must Wear Masks, No Wind Instruments - <AUTHOR> https://www.westword.com/music/denver-and-colorado-begin-plans-to-bring-back-concerts-and-live-music-11727708 <comment><USER2> Yup, not happy with Denver leadership and how they have and are still managing this. Voting against every single one of them

<comment><USER2> Why are people downvoting? Isn't everyone dissatisfied with their govt leaders right now?</comment></comment>


Ask HN: Sabbatical Stories - <AUTHOR> Lets hear some stories.  Why did you do it?  What did you do? Would you do it again?<p>Call it a quarter-life crisis and almost being 30, but I'm currently looking at my ability to take ~1 year off.  I'm not terribly happy at work and before I buy a house and settle in for the next 30 years, this could make sense.  Worst case scenario, I take a 30% pay cut in 1.5 years.  Best case, I start a business or learn new skills or god forbid, relax. <comment><USER2> I did this, taking off from February through August 2001.

Taking a sabbatical destroyed my professional career but probably saved my life.

If you do it make sure you have a rough plan of what you hope to accomplish during the sabbatical, and figure out what you're going to do for work at the end of the sabbatical, before you start it.</comment>