A well-known URL for changing passwords - <AUTHOR> https://github.com/WICG/change-password-url <comment><USER4> This is a nice simple convenience feature, for sure [1]:

> example.com provides a /.well-known/change-password resource which redirects > to their change password form, wherever it happens to already be.

> Password managers check for the existence of /.well-known/change-password on > [https://example.com](https://example.com).

> If it's there (the response code is 2xx or 3xx), the password manager can > cause the user's browser to navigate there when the user indicates they'd > like to change their password.

It's not trying to enforce a particular password schema, it's not an API endpoint to automate changing passwords, and it is not trying to dictate site design or form layout.

It's also dirt simple to implement with practically zero cost.

Aside from Safari, it doesn't seem like any password managers have implemented this yet. It's also not in the IANA well-known URI registry [2] yet (even as draft), so that would probably at least allow it to get a bit more traction. Apparently they are working towards that [3].

[1] [https://github.com/WICG/change-password-url/blob/gh- pages/ex...](https://github.com/WICG/change-password-url/blob/gh- pages/explainer.md#proposal)

[2] [https://www.iana.org/assignments/well-known-uris/well- known-...](https://www.iana.org/assignments/well-known-uris/well-known- uris.xhtml)

[3] [https://twitter.com/rmondello/status/1042008520105779206](https://twitter.com/rmondello/status/1042008520105779206)

<comment><USER5> How about something like:

      /.well-known/delete-account
      /.well-known/request-user-data

This would also be nice as we wouldn't need things like [https://justdelete.me](https://justdelete.me)

<comment><USER6> I can't imagine those taking off without legislation. Making it easier to change passwords is more or less in the interest of the companies who make web sites; making it easier to delete accounts or export all of your data, by comparison, is not.

<comment><USER7> Until users decide that the businesses interests of the companies that run the websites they use are less important than their own interests these features will never catch on. How about we stop using websites that fail to implement things that are good for _us_?

In fact, someone could write a browser plugin to put a screen between the user and the website that states "This website fails to implement .well-known link. Are you sure you want to continue?" like Chrome does for sites that have borked DNS. If a reasonably large number of people used that you'd see lots of sites implement this idea without needing regulations. I'd use that.

<comment><USER8> But then how would users get to Facebook? /s

You could have that plugin have a database of sites and also provide easy links for those sites that try to hide those functions.

</comment></comment></comment></comment></comment><comment><USER9> A lot of people in this thread seem to be unaware of the purpose of /.well- known/ .

You can read the memo about it here:

[https://tools.ietf.org/html/rfc5785](https://tools.ietf.org/html/rfc5785)

Basically /.well-known/ is a place to check for common site meta data and you can suggest new urls that can be registered.

/.well-known/change-password

Has been accepted and added for the use case of pointing to where to change your password.

If you think this is insufficient then there is nothing stopping you from trying to put forward a more comprehensive proposal for say /.well- known/change-password-api that would contain all the meta data for whatever standardized scheme for informing multifactor/username/email api combinations you eventually come up with. Just because /.well-known/change-password exists it does not in any way limit what other suggestions can be made and implimented later (it only means that you need to use a different url).

</comment><comment><USER10> Here is the actual spec: [https://wicg.github.io/change-password- url/index.html](https://wicg.github.io/change-password-url/index.html)

Presumably this is only for accounts you are already logged into and want to change the password of, since change password forms usually aren't accessible unless you are already logged in.

However, the same domain may involve multiple account types. AWS and other popular websites have multiple types of accounts, different login methods, and different change-password forms, on the same domain. If all this URL does is redirect to one single page per domain, it won't work for cases of more than one type of login.

Also, it seems that password _reset_ is a lot more common than just changing a password, so maybe this spec could be extended to that form, too?

<comment><USER11> I wonder if URLs like /.well-known/login and /.well-known/logout would be a good idea, and should belong to a similar spec. Maybe even /.well- known/register, too.

<comment><USER12> Why not use simple HTTP authentication?

<comment> munk-a A lot of site design requirements won't fit well with simple HTTP auth. If the company wants to display a password recovery link or display pricing information to potential customers it's incompatible with using HTTP auth without a lot of extra bells and whistles.

These are all relatively common business requirements.

</comment></comment></comment></comment><comment><USER13> They say that iCloud Keychain on iOS 12 and Safari 12 have implemented this feature.

And sure enough, [https://www.icloud.com/.well-known/change- password](https://www.icloud.com/.well-known/change-password)

Looking through the referenced RFC, there's a whole raft of "well known" urls that are registered

[https://www.iana.org/assignments/well-known-uris/well- known-...](https://www.iana.org/assignments/well-known-uris/well-known- uris.xml)

How widely adopted are these?

<comment><USER14> The one that Apple's browsers request on every domain isn't even in the list:

/.well-known/apple-app-site-association

That's the only .well-known request we have in our logs from the last year or more. Seems to be looking for an app associated with our site.

Aside from that, I don't know anyone or anything else using .well-known. Seems to be an Apple thing.

<comment><USER15> I think LetsEncrypt uses it, no?

<comment><USER16> Yes, also OpenID Connect.

<comment><USER17> sadly only for discovery. but it would be great if oauth/openid connect would actually use .well-known/authorize, etc. instead each provider has it's own sauce.

</comment></comment></comment></comment></comment><comment><USER18> That looks like a good idea, but why not go one step further? Provide a common API interface for password changes.

Think about it: If you assume your pw manager database is compromised - <USER2> do you do? Go to a hundred webpages and change your password? probably not. Your PW Manager can't provide a feature to do it for you. But it could if there was such an API.

<comment><USER19> On that note though, if we start using standard APIs for this sort of thing, I question whether we should just go farther and "solve" the problem.

Ie, as a dumb example, why should I expect them to implement an API for my password manager, and instead not simply allow oauth where my pass manager becomes my token provider?

Doesn't that fake example solve both problems, while also getting rid of bizarre password churn? Sure, it has the downside of _" what happens when my password provider is compromised.."_ but that's always true, right?

An API for password managers feels like a solution to a problem we've created.

Don't get me wrong, I love the idea of reducing password churn. I'm just not sold on this specific method of handling it.

<comment><USER20> I think you answer yourself already. You expect this:

> simply allow oauth where my pass manager becomes my token provider

to be a simpler implementation then "PUT [https://blabla.com/change- password"](https://blabla.com/change-password") or whatever a password change request would look like?

<comment><USER21> That "simpler implementation" of PUT [https://example.com/magic-api/change- password](https://example.com/magic-api/change-password) has all sorts of security concerns you aren't considering. How do you stop "rogue" password managers from using it? How do you stop replay and man-in-the-middle attacks?

The other poster is correct that immediately people would jump to using OAuth as one solution to manage which password manager apps can access that change password flow somewhat securely. At which, yes, why not just invert the OAuth flow and find better ways to make the Password Manager the provider rather than [https://example.com](https://example.com) and maybe eliminate the password entirely from the equation while we are at it.

<comment><USER20> > How do you stop replay and man-in-the-middle attacks?

Replay what? Me setting my password over HTTPS? How?

The sample URL was deliberately just an example. It would surely need more thought but i'm pretty sure the "PUT ..." solution is simpler then throwing oAuth at the problem.

So you're confident that the same people who can't secure the simple PUT request are better suited to implement the custom oAuth solution you are talking about? And that will be secure? I'd bet against that.

<comment><USER21> I'm saying that the closest thing we have to a well-adopted standard for securing a "simple PUT request" for something as security critical as a password is called OAuth.

You need CSRF tokens to avoid replay attacks. You need some way for an app to Authorize: that they have permission to update someone's password. That's probably some sort of application whitelist. That application whitelist probably needs a permissions flow for a user to agree that Password Manager Brand X is indeed their password manager application of choice. Do we have a standard for such permission flows and app-specific bearer tokens? Oh look, it's OAuth that says "hi".

<comment><USER20> You're clearly far too deep into the oAuth mindset:

      - You don't need "persmissin flows"
      - You don't need "to update *someone's password" (just your own!)
      - You don't need an "application whitelist" because HTTP doesn't know what an application is

All you need is to say "hey, here is my current password/hash. Update it to this one." on a secure channel (let's say, HTTPS). Alternatively "Hey, i am XYZ and this cookie tells you so. Update my password to XXX". I'm pretty sure there are a gazillion ways to securely make a request to some URL to update a password.

<comment><USER21> You're clearly not thinking of repercussions of having an open REST endpoint that anyone on the internet could just curl/postman/httpie to change someone's password.

Good password change forms have had CSRF tokens for _decades_ now: [https://en.wiktionary.org/wiki/CSRF_token](https://en.wiktionary.org/wiki/CSRF_token)

There are many known attacks whereby an attacker changes someone's password to control an account.

I don't care about OAuth at all. It's not an "OAuth mindset", it's a "I wouldn't trust a website at all in 2018 if it had an unsecure PUT endpoint to change my password" mindset.

HTTPS alone is not sufficiently secure. It's a start, but it is nowhere near enough on its own. SSL MITM attacks and Phishing are still problems today.

Requiring my current password isn't necessarily sufficient either: password cracking botnets exist. If the first sign that your password was cracked is that your password was changed to something only your attacker knows, that's not great. This is also where replay attacks come in. An attacker MITM or phishes this endpoint, and social engineers you into thinking you need to change your password, they get your old and new password together in one nice bundle.

Cookies aren't a sufficient answer for similar reasons. Again, take a look at cross-site request forgery issues and the history of replay attacks on password forms.

Application whitelists are a _minimal_ security precaution to mitigate some botnets and phishing algorithms. HTTP does know what an application is, we often see application blacklisting done the hard way with User Agent strings and IP address ranges. Whitelisting is a more secure approach, but a lot harder to do securely (and why we have standards like OAuth; OAuth isn't the only answer, it's just the current easiest answer).

<comment><USER20> > that anyone on the internet could just curl/postman/httpie to change > someone's password.

But that's my point. Keep it simple, let my password manager (be it on my mobile, laptop or whereever i want) change my password! Yes, i'd like that.

You don't even need that CSRF token, i don't know why. To prove your identity you'll only need to prove that you know you your password. That's possible, securely. See [https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...](https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol) and [https://en.wikipedia.org/wiki/Zero- knowledge_password_proof](https://en.wikipedia.org/wiki/Zero- knowledge_password_proof)

Why do you need an application whitelist?! The website i am visiting isn't whitelisting my browser, so why would it need to whitelist my password manager?

<comment><USER21> How lucky for you in 2018 that you don't seem to have any trouble with botnets trying to crack your passwords, hack your accounts, or even just break your accounts so that you cannot use them.

<comment><USER20> Exactly. Most password leaks seem to come from hacked websites and thus badly implemented security. And that's another point i was making: Keep it simple but secure, so that implementors have it simple and don't mess it up.

Can you point me to some source for botnets which crack passwords? I would be surprised. It's not feasible to brute-force a password over HTTP.

<comment><USER21> My Steam account has had high entropy, sole use passwords cracked in the timeframe of months, which would seem to indicate (if Valve is not leaking [1]) a botnet using their "simple" HTTPS login endpoints to brute force passwords. So far Steam Guard (2FA) has stopped the attacks, but that doesn't make me feel that much better given the speed in which the passwords seem to be cracking.

That's just one account I see as currently most at risk. There are plenty of others I'm concerned about as well.

Passwords are fragile, brittle things. "Simple" security is _no longer_ an answer when dealing with passwords. FULL STOP. It's time we moved past passwords altogether, but even where we can't, we absolutely have to be serious about password security from top to bottom.

You can victim blame "hacked websites" for "badly implemented security" all you want, but that's part of the point, too. Password infrastructure will always be lowest common denominator, because it is "easy", because it is "simple". _Everyone_ thinks they can implement password security, and _everyone_ is wrong. There are still people that don't hash, much less salt, their passwords in 2018. There are still people that don't realize "Security Questions" are Plaintext Passwords and a giant security risk. In the age of bitcoin mining there is no such thing as a hashed or salted password that cannot be brute forced. Bitcoin mining is password brute force at massive scale, and dropped rainbow table hardware to the price floor.

I'm sorry that you still have any illusions left that passwords are and/or can be "simple". Passwords are dead and yet we're all going to be fighting that forest fire for decades to come.

[1] Which admittedly, is a possibility, but it would be a surprising shock for an application as big as Steam.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Seems like a nice subtle way to hijack the changing password mechanism, particularly on a sub-domain you control. Just set the URL to e.g. "[https://evilsite/changepasswords"](https://evilsite/changepasswords") and wait for Password Managers to be updated.

The fact that the spec says nothing about where a user can be redirected, and which domains/sub-domains are within scope for which change password requests seems like an oversight.

For example if my password manager saves a password for login.example.com, is a .well-known/Change-Password on evil.example.com, or example.com in scope? Who decides? Is it left to the password manager to figure out the security scope?

<comment><USER22> I don't understand your concern. If the attacker controls `[https://example.com/.well-known/change-password`](https://example.com/.well- known/change-password`) wouldn't they also control `[https://example.com/my_profile/settings`](https://example.com/my_profile/settings`)?

Why bother redirecting the user to a third party site when you can just inject some password-logging JS into the _legitimate_ change password form?

<comment><USER14> If an attacker controls a subdomain and can trick a user into visiting it (e.g. evil.example.com), the cookies may be out of scope, but the password manager may (or may not) treat the subdomain as part of the domain in terms of .well-known/change-password requests, allowing a subdomain to redirect the password manager and potentially stealing credentials.

It is undefined behaviour. The spec is under-defined. That's my issue, there has been no security pass of this at all. It is left up to each individual password manager to make this secure (or not).

<comment><USER22> I still don't see your point.

If your password manager autofills your credentials for `example.com` when you visit `evil.example.com` then the owner of `evil.example.com` already has an easy way to steal your credentials regardless of whether or not this spec is implemented.

</comment></comment></comment></comment><comment><USER23> This is so relevant. Just 10 mins ago, I got a short, casual, no-reply email from Teachable about an email & passwords breach.

If you're a startup and you're storing plaintext passwords out of expediency, realize you're doing a massive disservice to your customers. It seems they changed this in 2015, but didn't go back and fix it for their earliest adopters. Your early adopters make you what you are! Protect their data. And if you do mess up, don't send out a self-focused apology from a no-reply address.

 _We are writing to inform you of a suspected data breach involving accounts created between September 17, 2013 and November 21, 2015. We have reason to suspect that personal information related to accounts on Bitfountain (joined 2014-08-18) may have been compromised. This includes the email addresses and passwords associated with the school 's Teachable (formerly Fedora) account.

As a precaution we are enforcing password resets...If you happen to use this password with any other service, we highly recommend updating your password there as well.

We apologize for the inconvenience, and thank you for your understanding in helping us keep Teachable safe. _

<comment><USER24> Storing plaintext passwords is no faster than storing a cryptographically secure hash of the same password. We're not even talking lines of extra code, just a few extra characters actually hash the input.

It's not expediency, it's laziness bordering on criminal stupidity/negligence.

<comment><USER25> Well it should be faster than storing a cryptographically secure hash. If hashing the data is too fast, an attacker could just brute force all of the passwords.

<comment><USER26> That's why you should always use salt with your hash.

Unsalted, your password hash =

Hash({{Your Password}})

The attacker can brute force it from a dictionary or stepping through characters (possibly from another breach somewhere, or a silly password like boobies123).

Salted hashes are way more secure:

Hash({{Your Password}} + {{Secret}})

Now the attacker has to guess an extra secret phrase, which is often really long, that was fed into the hash function along with the user's password. And due to the beauty of one way hash functions both salted and unsalted hashes use the same amount of bytes in the DB... It's a no brainer.

<comment><USER27> The reason to use a salt is mostly that an attacker doesn't then have a precomputed library of hash values.

Say, if someone uses the password 'gwpmkq' and a site uses plain MD5, they store cc733aac12981561dfc4944dd34a595f in their database. Now, even a stupid attacker can google for a hash search engine, input the hash and get the password in seconds.

On the other hand, with salting the value to be hashed could be something like 'email@example.com:@362#^h6329hgtew:gwpmkq'. That won't be precomputed anywhere.

Of course it's also a good idea to either try to keep the salt secret or use a per-user random salt (which you store in the database). But when someone gets a full database dump, chances are they'll also get the salt.

<comment><USER28> The specific attack that per-user random salts are designed to prevent are pre-computed rainbow tables. Brute-forcing MD5 is nearly as fast as using rainbow tables, so the benefits are possibly dubious.

<comment><USER29> Who uses MD5 for hashing password anymore?

<comment><USER24> People one step above those who think storing plain-text passwords is okay.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> I see the argument for simplicity, but I think it would be much more impactful to have a well-known URL for automated password changes.

It's common to see advice to "change all your passwords" following incidents like Heartbleed or Cloudbleed or after having a personal computer hacked.[0]

This advice is useless -- it's way too time consuming, and also comes too late. If you need to change all your passwords now, you actually needed to do it six months ago.

A well-known URL that specified password requirements and an endpoint to hit with username, old and new passwords would let password managers reliably and routinely update passwords instead. To the extent "change all your passwords" is ever good advice, it would become advice you could follow automatically instead of never.

[0] Example of the form: [https://securitywatch.pcmag.com/hacking/322494-heartbleed- fa...](https://securitywatch.pcmag.com/hacking/322494-heartbleed-fallout- change-all-your-passwords)

<comment><USER31> There's room for both ideas.

This one has the benefit of being stupid simple to implement and maintain. In 10 minutes I can throw this together for all of our login stuff.

But a fully automated password changing system/API? That's not exactly as "maintenance free". Now you are maintaining a full API separate from your normal routines, and it's in an area that I always advocate for simplicity since subtle mistakes can mean compromised accounts. And the "fully automated" API would also have to work with "multi-factor" systems, which alone make everything more complicated to cover all the different ways it's done.

Don't let the possibility of a better solution kill the benefits of this simpler one.

</comment></comment><comment><USER32> From the spec:

> Servers must not locate the actual change password page at the change > password url, per RFC5785 §1.1 Appropriate Use of Well-Known URIs.

I scanned the RFC but can't fine the prohibition against this. Curious, why does it matter? Just because .well-known URLs are not meant to be exposed to the user?

<comment><USER33> That section says:

       There are a number of possible ways that applications could use Well-
       known URIs.  However, in keeping with the Architecture of the World-
       Wide Web [W3C.REC-webarch-20041215], well-known URIs are not intended
       for general information retrieval or establishment of large URI
       namespaces on the Web.  Rather, they are designed to facilitate
       discovery of information on a site when it isn't practical to use
       other mechanisms; for example, when discovering policy that needs to
       be evaluated before a resource is accessed, or when using multiple
       round-trips is judged detrimental to performance.

I am guessing they consider "general information retrieval" and "URI namespaces" to exclude it.

<comment><USER32> I did see that section, but don't see how it follows. Putting your PW reset page at this address would be using the URI spec for exactly it's intent, not "general information retrieval". My read of this clause is just that they don't want you to start using .well-known as your primary namespace or cluttering the registrations with junk that's not broadly applicable.

</comment></comment></comment><comment><USER34> Can someone clarify, is this actually for resetting a forgotten password? I don't quite follow.

example.com's _change password_ functionality should be behind an authenticated page that requires a) the user be already logged in, and 2) the user's current password (for confirmation).

Whereas example.com's _forgot /reset password_ functionality is usually a wide-open page anyone can reach to begin the process of password reset (more inline with what this spec seems to be describing).

<comment><USER35> Did you read the explainer?

> Currently, if the user of a password manager would like to change their > password on example.com, basically all the password manager can do is load > example.com in a browser tab and hope the user can figure out how to update > their password themselves.

> The goal of this spec is to do the simplest possible thing to improve this > situation.

It's an attempt to standardize the endpoint for changing a password. Which is kinda random for each website currently.

<comment><USER34> > Did you read the explainer?

I did. My confusion arose from it. Something is clear to you that is not to me :)

<comment><USER36> [https://news.ycombinator.com/.well-known/change- password](https://news.ycombinator.com/.well-known/change-password) will just redirect to [https://news.ycombinator.com/changepw](https://news.ycombinator.com/changepw). If the user isn't logged in, that page asks the user to log in.

<comment><USER34> Ah I see, and from the perspective of a password manager it would know what password to fill into the password field to get the user into the site. After that, once on the change password screen said manager would also take over generating a new password, yes?

</comment></comment></comment></comment></comment><comment><USER37> I haven't read the proposal but it made me think of something like:

/.well-known/personal-access-token

To get an access token for API access to my own data. You know, for our right to be represented by a bot[1]

[1] [https://continuations.com/post/172413445510/we-need- mandator...](https://continuations.com/post/172413445510/we-need-mandatory- enduser-apis-for-social-and)

</comment><comment><USER38> Actual spec here: [https://wicg.github.io/change-password- url/index.html](https://wicg.github.io/change-password-url/index.html)

</comment><comment><USER39> ooh can we also get /.well-known/delete-account ??

seriously though, I would love this for all those sites that bury it as far as possible...

<comment><USER40> This would be great, but like you said, the sites you would really want to use this for would likely never implement it. Unless it were a requirement of something like GDPR..

</comment></comment><comment><USER41> Used by Safari for website password it identifies as used on multiple websites.

</comment><comment><USER42> > If it's there (the response code is 2xx or 3xx), the password manager can > cause the user's browser to navigate there when the user indicates they'd > like to change their password.

The primary issue I see here is that there are a lot of websites that do 301 redirects from either non-www to www subdomain or non-https to https, would this not confuse the password managers in assuming there is a .well-known even though it's just a benign redirect?

<comment><USER43> This is being tracked by [https://github.com/WICG/change-password- url/issues/4](https://github.com/WICG/change-password-url/issues/4)

</comment></comment><comment><USER42> One thing I really wish when it comes to Firefox Containers if I create a container for Gmail and am logged into Google I want all the email links (mailto:) to open in that container. I know currently you can have all the sites with a specific URL to open in specific containers but I'm not sure if there is a way to open various protocols in separate containers.

</comment><comment><USER44> I wish every site would just use emailed sign-in links instead of passwords. We wouldn't have to deal with all these password relative nonsenses - <USER3> managers, .well-knowns, password requirements, password resets, weak passwords, gazilion passwords in my head. Everything would be so much simpler

<comment><USER45> And then your email gets compromised and everything is immediately lost? No thanks

<comment><USER46> Everything is already lost if your email is compromised as they can just use the "forgotten password" functionality and reset it thanks to their access to your email.

<comment><USER47> And that is why I have a 2FA app for my email.

</comment></comment></comment></comment><comment><USER48> [https://wicg.io/.well-known/change-password](https://wicg.io/.well- known/change-password)

Also:

[https://news.ycombinator.com/.well-known/change- password](https://news.ycombinator.com/.well-known/change-password)

</comment><comment><USER49> After learning about this a few days ago, I created a Laravel package for managing .well-known URLs: [https://github.com/tnorthcutt/laravel-well- known](https://github.com/tnorthcutt/laravel-well-known)

I plan to add other URLs that make sense as well.

</comment><comment><USER50> YES, this is what I have been waiting for. A month ago I lost a USB with my keepass file on it. The file is encrypted with a good password but I would feel better if I could reset all my passwords just in case but that would take me days.

</comment><comment><USER51> It up to browser standards to make this thing reality. example.com does not have any incentive to provide this url. However, if a users browser would treat sites implementing this feature as "more secure", example.com will gladly implement it.

</comment><comment><USER52> I was looking to do this for my pass-rotate project:

[https://github.com/ddevault/pass- rotate/issues/1](https://github.com/ddevault/pass-rotate/issues/1)

I hope a spec gains traction.

</comment><comment><USER53> I'd rather we hade /.well-known/delete-account

</comment><comment><USER54> You really only have one password for web sites with password resets via email and that's the password to log into your email account.

</comment><comment><USER55> Note to self, create some express middleware that listens to .well-known GETs and redirects to a map of developer-supplied URLs.

</comment><comment><USER56> But works only on Apple devices..so in a very small amount of devices

</comment><comment><USER57> Allow me to change username/email while I'm at it!

</comment><comment><USER58> How about a well-known URL for unsubscribe?

<comment><USER59> Not quite the same thing, but there are official email headers for unsubscribing from email mailing lists. [https://tools.ietf.org/html/rfc2369](https://tools.ietf.org/html/rfc2369)

</comment></comment><comment><USER60> Don't we have AI by now that can figure out what button to click to change the password?

</comment><comment><USER61> To be pedantic, 'well known' things are not usually specified in advance :D

</comment><comment><USER62> The real problem is that every single site needs its own separate password.

(Even worse are products and services where you need a separate password for different features.)

The better way to solve this is to push for better account portability. We already (kind-of) have this with websites that let you sign in with your Google or Facebook ID. (Unfortunately, these systems still have privacy problems because they share your email, or the web site fails if you don't want to share your email.)

<comment><USER63> [https://www.grc.com/sqrl/sqrl.htm](https://www.grc.com/sqrl/sqrl.htm)

Though I think he will need a more convincing marketing site if he intends for people to try it out.

<comment><USER64> GRC is not known for giving much importance to marketing.</comment></comment></comment>


The Hydrocarbon Era's Spectacular End - <AUTHOR> https://www.bloomberg.com/news/articles/2019-08-06/the-hydrocarbon-era-s-spectacular-end <comment><USER2> As an aside, I found this article the be spectacularly well written:

> A central argument for fossil fuels' continued dominance is that humanity > will surpass 10 billion at some point, and all those people will want > something like the Western living standards built over the past 100 years on > the back of coal, gas, and oil. Yet what a poverty of imagination this > betrays, especially in light of climate change, which hits the poorest > hardest. How can that be the pinnacle of civilization? What even constitutes > "higher living standards" in a world where the costs of our existing > technologies are so transparent? Far from securing hydrocarbon dominance for > another 100 years, the needs and aspirations of future generations demand it > give way to something more sustainable.

<comment><USER3> When I go by the numbers it looks like there is _easily_ room for enough renewable energy generation for everyone to consume energy services at "Western" rates. But a number of caveats:

Energy production is the easier part. Storage is the harder part. It seems like renewable electricity storage is just now getting to the point of maturity that solar electricity production was 10-15 years ago. [1]

The model Westerner in question is someone more like the median Dane than the median Texan. [2]

Some forms of consumption are going to be limited by constraints other than CO2 emissions from energy. Ruminants emit too much methane for everyone to eat beef like Australians. There are not enough redwood trees for the world's populations to install redwood hot tubs like Californians used to. There is not enough usable space in Luzon for most of the population to have a large detached house even if there were clean energy for all those houses.

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

[2] [https://en.wikipedia.org/wiki/List_of_countries_by_energy_co...](https://en.wikipedia.org/wiki/List_of_countries_by_energy_consumption_per_capita) [https://www.eia.gov/state/rankings/](https://www.eia.gov/state/rankings/)

<comment><USER4> In the cited statistics, they may be conflating energy production/refining with consumption. In Europe, the Benelux region has much higher consumption then their neighbors. A bit surprising given similar weather, their love for bicycles and well developed train infrastructure. State side, Louisiana has a much higher consumption than rest of the deep South. Perhaps due to the small population and the oil & gas production off of the carcinogenic coast?

<comment><USER3> Louisiana has a large number of facilities that make chemicals and fuels from natural gas and crude oil. Those facilities dissipate much of the primary energy in the inputs in the course of making refined output products. I think that's where the high per capita figure comes from; it's e.g. energy losses in facilities making ethylene from fossil inputs, _not_ the mere fact of extracting fossil fuels. Since that energy dissipation happens in facilities located within the state of Louisiana, staffed by Louisianans, I think it's fair to include those facilities in the per-capita statistics for Louisiana.

The other popular perspective is that those figures really "belong" more to the end consumer than to the producer. I don't agree, for reasons both philosophical and pragmatic.

Pragmatic: it is easier to track what happens in large production facilities than to track the ultimate retail fate of every gallon of gasoline coming from Louisiana refineries. Trying to trace production to millions of consumers instead of monitoring dozens of primary producers is a recipe for getting much less actionable data.

Philosophical: producers are (IMO) more responsible for the efficiency/pollution of production than consumers are. A consumer has no way of telling at the point of sale how efficiently/cleanly the aluminum in a laptop or plastic in a bucket was produced. Primary producers reap the profits and make those process choices about production; it's also producers who should most face the criticism for wasteful or polluting practices.

</comment></comment></comment></comment><comment><USER5> >Despite the falling costs and growing market share of renewable energies, they still lack the killer app: a price on carbon emissions that would expose the frequently hidden costs of fossil fuels. Conventional wisdom holds that Americans, especially, wouldn't stand for that.

This is why I desperately want a carbon tax above all else. Price in the externalities, to accelerate existing trends in the energy replacement cycle.

I don't think government can magic a solution into existence (thought basic r snd d funding helps), but it is _well_ within government power to price externalities. We can even lower other taxes that have negative effects but are currently needed for revenue.

We may or may not make it, but such a tax will help speed all of our efforts by growing the reward for non-carbon energy.

<comment><USER6> I may be naive, but I think the real problem here isn't Americans per se, but American corporations; once an industry in the states is large enough, taxing it (in any meaningful way) is virtually impossible because of lobbying dollars and backdoor dealings with politicians (e.g. "regulators," lol). Look at sugar, plastic, corn, beef, etc. There are examples a plenty.

<comment><USER5> A bit of both. Corporations can't lobby for open murder or human sacrifice: they have to hew to popular opinion, as politicians do.

PR and propaganda can sway this somewhat, but not in a limitless way. The single biggest factor blocking more urgent action is human nature: we tend to the short term, we like to be comfortable, and we have a hard time imagining things being radically different than they are.

I am not saying it's impossible to convince the populace. I only mean to counter the perception that resistance comes only or even largely from corporations.

Iirc correctly americans only have a 10-15% spread on climate issues compared to europeans.

<comment><USER7> Motivation for broader action may wait for a climate change Pearl Harbor

</comment></comment></comment></comment><comment><USER8> > Primary energy consumption _grows at about 1% to 2% a year_ , and that rate > has trended downward, more or less, since the 1960s. That's _linear growth_

How come? Even "just" 1% per year growth in consumption is still exponential: starting with consuming 100 of something this year, in 70 years you'll consume 200 per year, but after the next 70 years you'll consume 400 per year.

During the first 70 years you would have totally consumed 10000 of that something, and during the next 70 years 20000 of that total. In the next 70 years, 40000 of that etc.

For 2% growth, each _doubling_ takes just 36 years.

More details, quoting Al Bartlett's "The greatest shortcoming of the human race is our inability to understand the exponential function" here:

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

</comment><comment><USER9> [https://outline.com/ExnMdm](https://outline.com/ExnMdm)

</comment><comment><USER10> It's so disconcerting to watch organizations and architects like Arup and Bjarke Ingels support stuff like this. From an artistic perspective it's less interesting than Jeff Koons' proposed animated replica steam locomotive dangling vertically from a crane ([https://www.thedailybeast.com/whatever- happened-to-jeff-koon...](https://www.thedailybeast.com/whatever-happened-to- jeff-koons-dollar25m-nyc-steam-engine)) and from an engineering perspective it's silly. Koons' loco could have held itself together without any feats of calculation but this is in the category of artist's fantasy made real by extensive structural analysis (and quite probably extensive interior reinforcement, not to mention a huge (floating?) foundation below the waterline.)

Arup was paid tens of millions of public money by the London "garden bridge" promoters. It's now expected to see their name on unusual large scale spectacular engineering projects. But their organizational ethos is loudly advertised as being altruistic and responsible: [https://www.arup.com/perspectives/publications/speeches- and-...](https://www.arup.com/perspectives/publications/speeches-and- lectures/section/ove-arup-key-speech). It just comes across as smug and sanctimonious, given the way Arup will apparently implement almost anything with a large enough price tag attached. They really aren't a more evolved form of consultancy, even if they claim that they are.

<comment><USER11> I think it looks rather spectacular, and have no idea why "[...] an artist's fantasy made real by extensive structural analysis" is anything negative.

If I were to define the perfect consultancy it would be pretty close to "do really strange stuff that gets people thinking about important problems and get paid well for it".

And FWIW, I believe they are proposing to build it on land, not have it floating in water.

<comment><USER12> (I've had to create another account to reply as I'm doing my best to leave HN permanently. Part of this involves forgetting passwords as quickly as possible.)

You admit that you have "no idea" what I'm talking about when I complain that this is an artist's fantasy that can only be realized by recourse to massive engineering resources. So it would have been nice if, instead of dismissing what I was saying, you acknowledged the possibility that I have a legitimate position on this, e.g. by asking for clarification.

If you research Thomas Heatherwick, the Garden Bridge, and Dustin Yellin, you will find that Heatherwick is widely derided as a pied piper figure or a "billionaire whisperer". His special talent lies in convincing the wealthy that his expensive and impractical design ideas are worth implementing. The Vessel at Hudson Yard is a recent example of a lame but mega-expensive Heatherwick project.

The real point I'm trying to make here is that almost any project can be realized if enough money is thrown at it. Being an artist is not necessarily about having dreams and then raising tens of millions of dollars to make them into reality. Economy of means is an important part of all creative activity, and Heatherwick in particular doesn't get it. It's the old story of any fool being able to do something for a dollar, but only an engineer being able to do it for fifty cents. This applies to artists just as much, and it applies to the bang-for-the-buck they get when making work.

Heatherwick is a good example of a designer who presides over bloated, unclever vanity projects. Arup cheerfully accept millions of pounds to actually bring his ideas somewhere near becoming reality. To take a built example: Arup engineered the museum Heatherwick designed in South Africa which includes a large atrium carved out of a preexisting set of concrete grain silos. You can read here [https://www.arup.com/-/media/arup/files/publications/t/arup-...](https://www.arup.com/-/media/arup/files/publications/t/arup- journal_issue-1_2018.pdf) about the very extensive trickery necessary to make this happen.

This Yellin proposal has all the hallmarks of that same process—an impractical and unnecessary megalomaniacal creative gesture that only becomes possible with a lot of engineering ingenuity and capital. The hard work is done by the engineers, and of course they are delighted to be paid to be involved in something so prestigious. They don't realize or just don't care that it's bullshit by any measure of artistic value. That is the frustrating smugness and foolishness that I am complaining about. This kind of project is a blue- chip "boutique engineering" gravy train for Arup and similar organizations, and the projects have zero positive impact on the world while at the same time rubbing everyone's noses in the mediocre concepts of overrated designers like Heatherwick and Yellin. It is grotesque, it has everything to do with vanity, greed and wealth and nothing to do with stimulating important conversations or improving quality of life.

You can find out all about Yellin online, and make up your own mind whether he's a real artist with an important and thought-provoking message, or just a hyperactive self-promoter. (He's well connected in certain circles but not taken seriously as an artist by the art world any more than Banksy is.)

</comment></comment></comment><comment><USER13> It's pretty short-sighted to point to latest market trends and infer that the hydrocarbon fuels are on their way out and renewables are there to replace them.

Yes, fossil fuels are down. Commodities are down. Companies benefiting from government spending are up, and government spending is at record highs. Not only that, pretty much any asset that you would expect to outperform in a bull market is way up.

No surprises there, this is a decade-old bull market fueled by trillions of worldwide cheap debt and quantitative easing. Yet, despite a supposedly roaring economy, the money-machine that is supposed to be "for emergency use only" just keeps on running. It's been working so well that "more spending" is the only valid political platform for both parties.

What could possibly go wrong?

<comment><USER14> The central issue, is that fossil fuels are a commodity, and solar and wind are technologies. Both, of course, have physical components (coal, sand, metal, etc.), and both involve technological progress (fracking is a particularly important example), but the long-term trend of commodities is, at best, up and down and up and down, whereas the long-term trend of technologies is down.

This means that, because both solar and wind electricity have prices that decline at an exponential rate (different from Moore's Law in the %/year, but not in their shape), the fact that they are competitive now, means that they will be far, far cheaper in the future. No matter how much of a head start you give a linear process over an exponential one, eventually the exponential one wins. Commodity prices are worse than linear; they are more similar to sinusoidal.

The real issue now, which is not widely discussed, is how to prepare the world for a time, within a decade, when every fossil-fuel dependent economy goes the way of Venezuela. I don't think we are remotely ready to handle the fallout from that.

<comment><USER13> This idea that technology improves exponentially ad infinitum is bogus. Nothing in nature can grow exponentially in the long run. There are plenty of technologies that have almost plateaued, passenger airplanes for instance.

In the past, people envisioned an era of free electricity because surely nuclear energy would improve exponentially. It did not. Neither will renewables.

<comment><USER14> Sure, and Moore's Law for semiconductor transistors didn't last forever, either. But, it lasted from the mid-20th century well into the 21st, over several orders of magnitude reduction in cost.

The current exponential decline in the cost/kWh of solar and wind generated electricity is not as steep, but it is exponential, and it has been going on for decades. If it continues for even one more decade (and that seems quite likely, as the amount of R&D going into it is increasing), then it will drive all fossil fuels off the market. I don't think we're ready for that.

</comment></comment></comment></comment><comment><USER15> Related article and discussion: [https://news.ycombinator.com/item?id=19564179](https://news.ycombinator.com/item?id=19564179)

</comment><comment><USER16> Great article except for this prediction, Which fails to grasp the continuous exponential momentum of solar price decay:

all-in cost of solar power has dropped 85% since 2010, and BloombergNEF forecasts an additional 63% drop through 2050.

</comment><comment><USER17> [http://archive.is/IYuQ6](http://archive.is/IYuQ6)

</comment><comment><USER18> Sorry but this is wishful thinking to say the least.

Oil, coal and gas not only are cheap, reliable, plentiful and versatile materials we have learned to turn into an excellent source for transportation, they are also used for many other things we take for granted. Probably 80% of the stuff we surround ourselves with is made of oil-based products some way or another.

I happen to be involved with a group that is trying to find alternatives to ex. plastic but it's simply not even close to looking like we have useful alternative let alone for the multitude of usages plastic can be used for.

For energy, we are even further of. This is a physics problem it's not like there were just a bunch of easy solutions waiting for someone to pick them up. Oil won for a number of reasons.

What most people forget is that it's not like oil somehow dominated simply because it was being promoted by some evil conglomerate, oil dominated and still dominates because of the many different ways we can utilize it to make our live better, safer, easier, richer more plentiful etc.

Furthermore things like this:

"> A central argument for fossil fuels' continued dominance is that humanity will surpass 10 billion at some point, and all those people will want something like the Western living standards built over the past 100 years on the back of coal, gas, and oil. Yet what a poverty of imagination this betrays, especially in light of climate change, which hits the poorest hardest. How can that be the pinnacle of civilization? What even constitutes "higher living standards" in a world where the costs of our existing technologies are so transparent? Far from securing hydrocarbon dominance for another 100 years, the needs and aspirations of future generations demand it give way to something more sustainable."

Is especially missing the point.

Nature didn't give us a safe and friendly environment we made unsafely, it gave us a hostile and unfriendly environment that we through the use of ex fossil fuels have made safe.

The poor nations will only be hardest affected if they don't have access to cheap and plentiful energy which is what the environmental movement seems to be pushing for.

I don't think that's done on purpose but the result is that poor nations will be more dependent on rich nations if we don't allow them to gain propserity.

I know that this is heresy on HN but it needs to be said.

<comment><USER19> It seems reasonable to me that the transition to renewables will make energy even cheaper, and absolutely less dependent on international markets (like the little problem that 40% of internationally exchanged oil flows through the Strait of Hormuz). So it's almost certainly a good thing for poorer nations.

Contrast this with the ever-popular HN push for nuclear power. Many nations lack the infrastructure to support such a complex and expensive endeavor, and some frankly can't be trusted with it. So a nuclear future is far, far worse than a renewable future.

Oil won for good reasons a hundred years ago. And it's going to lose for good reasons over the next hundred years.

<comment><USER18> Which renewables are you referring to?

What renewables can both give us plastic, pesticides, concrete?

What renewables can deliver cheap, reliable, scalable energy anywhere needed?

The most popular forms of renewables like wind and solar are not even close to being stable, reliable or cheap, furthermore they only deliver electricity which is what? 20% of the total energy needs?

Nuclear is expensive because of the regulations not because of technology and more people die from wind and solar than from nuclear.

Having been involved in investing in this space it's pretty obvious that we aren't even close to having alternatives, as in not even in a couple of decades.

You take away the Chinese investment in renewables and the rest of the world's investment in renewables are falling not rising and even with the Chinese investments it's stalling.

There is such an insane amount of groupthink going on here that I know people aren't going to actually accept it but it's very easy to get a reality check simply by taking $10K and find a company which you trust will succeed after you do due diligence. You will quickly find out that we are kind of at the forefront of energy and alternatives where we are and that means less than 1% of the worlds global energy consumption (not just electricity) is wind and solar.

A far cry from what you will hear german and danish politicians claim.

<comment><USER19> Ok, you're just wrong on some of this stuff. When I say "renewable", I mean wind and solar for the most part, so keep that in mind.

No, renewables don't solve the plastic/pesticides/concrete problem. It's energy, not hardware.

Renewables can and do deliver cheap, reliable, scalable energy. The automobile is a really good example of that, and electric cars are quickly edging out internal combustion. I imagine we're no more than two decades from total electric car base. There is such a thing as batteries, you know.

Wind and solar are only delivering x% of our power _now_ , but time moves, and they are growing exponentially. Their lower cost provides a strong financial incentive to do all new construction in renewables. So again, over the next few decades, we will transition to a mostly-renewable grid.

Nuclear is expensive because it's hard, not because of "regulation". And considering the track record of the industry and the consequences of failure, I'm all for the regulation. If regulation was the problem, we'd see more nuclear in nations with very little environmental regulation and strong central governments, like Russia and China. But they still only get a small fraction of their power from nuclear, and it's about to be outstripped by renewables. Because renewable is much cheaper.

I wouldn't invest in the industry because a: speculating on individual companies is just gambling (an industry fund would be different), and b: the cost of energy is going to go down, so profit margins won't be great. It'll wipe out the fossil energy industry, but the end result will be the world spending less money for more energy. Bad investment, good for humanity.

<comment><USER20> > _Renewables can and do deliver cheap, reliable, scalable energy. The > automobile is a really good example of that, and electric cars are quickly > edging out internal combustion. I imagine we 're no more than two decades > from total electric car base. There is such a thing as batteries, you know._

The electric cars are still made, transported, maintained, and powered by fossil fuels and nuclear.

Renewables at the moment (and for the foreseeable future) can't handle changing the world's fleet (?), or even 20% of it, to electric cars...

Renewables are to projected to be around 16%-18% in 2040:

"Should progress continue at the pace currently forecast, the share of renewables in final energy consumption would be roughly 18% by 2040"

[https://www.iea.org/renewables2018/](https://www.iea.org/renewables2018/)

[https://upload.wikimedia.org/wikipedia/commons/e/e1/United_S...](https://upload.wikimedia.org/wikipedia/commons/e/e1/United_States_electricity_generation_by_fuel_1990-2040.png)

<comment><USER19> Yes, electric car manufacturing is still done largely with non-renewable sources. But it's happening nonetheless. Manufacturers like Porsche and Volvo expect to be over 50% EV by 2025. Even for fuel-based cars, plug-in hybrids are becoming more common. So the auto industry will be switching quickly.

Unfortunately, we will still have other pockets where fossil fuels are much harder to root out - heavy oil for shipping, jet fuel, and the existing base of coal plants that aren't financially viable to replace. But how many decades are left in those coal plants? Who will build a new coal plant to replace the old one?

And as gasoline and coal are phased out, they will become more expensive, as economies of scale drop out. Meanwhile, economies of scale in manufacturing are a key reason for the drop in the cost of renewables. Market forces are mostly on the side of renewables here, and trends even more so.

<comment><USER18> "expecting" is the problem word here. That means absolutely nothing. Its marketing talk with no real foundation in reality.

Gasoline and coal will be phased out but it's not because of wind and solar as they literally can't deliver what is needed and will need at a minimum nuclear or oil or coal as backup when the wind isn't blowing or the sun isn't shining.

We are nowhere near fuel cells. One could even make a case for us being closer to fusion than fuel cells.

<comment><USER19> "When the sun isn't shining" shows that you really don't understand the field. Again... ever heard of batteries? There are any number of ways to temporarily store power. Collect wind/solar when the wind blows and the sun shines, and have some spare energy cached when demand exceeds supply.

There's no "can't" anywhere in this. It's just a question of cost. And if wind/solar + sufficient storage is _still_ cheaper than coal and gas peaker plants, it wins. That's the way the entire industry is betting, worldwide. The experts whose careers are on the line think this is the right path for a reason.

<comment><USER18> I understand the field perfectly well, well enough to know a thing or two about capacity factors.

It's not a question of cost but of simple physics.

Batteries aren't going to solve anything what so ever. We would need fuel cells which is theoretically possible but as far out as fusion when it comes to actually have something that works in practice.

<comment><USER19> Until we get fuel cells that don't need a platinum catalyst, they're irrelevant. Not enough platinum to scale.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> And the thing that's going to save us boiling frogs, if it's not too late already, is the invisible hand of the free market. Fossil fuels are rapidly getting out-priced by renewables, which are getting order-of-magnitude improvements in cost.

We got lucky.

<comment><USER21> I'd hardly say that the free market is the savior, The innovation in renewables was the result of heavy government spending in R&D grants to universities, subsidies on renewable tech, and cap and trade on emissions. Lets hope that the free market can take the baton after government intervention pushed down the initial price barriers.

<comment><USER19> Mostly nonsense. The improvements we've seen over the past decade have been improvements in manufacturing and other process, not subsidy. It truly is cheaper now, and will get cheaper still. The free market has had the baton for the past decade, at least. The main impediment is mostly the time scale of power plant projects, and the cost of intermediate storage (which has also plummeted).

And of course, this doesn't take into account our direct and indirect subsidies to the fossil fuel industry - you know, like what we spend on a military presence in the Middle East.

<comment><USER22> > Mostly nonsense.

Citation needed. Even a market darling like Tesla benefited greatly from government subsidies on "green" technologies.

<comment><USER19> Tesla has more than doubled in size every year since it was founded. It has grown faster than Amazon did. That's not subsidy, because subsidy is bound politically and could not keep up with that sort of growth. No, that's what being the best-bet winner for a trillion dollar market looks like.

</comment></comment></comment></comment></comment><comment><USER23> I recently thought... sure everyone says it's the CO², but then I saw articles that said, the CO² didn't change as much as they said it did. 4% of the atmosphere or so, because water takes it up and some kinds of stones do the same. What if we generally just generate too much heat? And the heat gets trapped in the atmosphere? Every time someone uses energy, it generates heat. Everytime we make energy from hydrocarbon, we generate heat. Would there be a way to let the heat go to space? Or if we want to preserve it on earth, a way to turn heat back into hydrocarbon?

<comment><USER24> > And the heat gets trapped in the atmosphere?

That's what CO2 does. It is a greenhouse gas, meaning it traps heat that would otherwise have escaped into space.

> Or if we want to preserve it on earth, a way to turn heat back into > hydrocarbon?

It is literally impossible to turn heat, by itself, into anything useful. That's the 2nd law of thermodynamics, and it's a cruel mistress.

It's nice to think about alternative solutions to these problems, but you need to have at least a _basic_ understanding of _basic_ level physics if you want to discuss this sort of thing.

<comment><USER25> My biggest frustration with global warming deniers has been that I understood the basics of global warming as a 6-7 year old, when I first read something about the greenhouse effect (it wasnt even in the context of global warming).

The only basic pieces of information you need to understand climate change are:

1) The greenhouse effect exists. That is, when you have something like glass, it will let energy in in the form of light, but it won't let as much energy escape once it's converted to heat. This concept can be grasped by anyone who has walked into a car that has been parked out in the sun. And by the massive clue in the name, that is the existence of greenhouses.

2) Carbon Dioxide is a greenhouse gas. That is, it acts like glass does in a greenhouse. This is harder to believe from first principles, but it's not that hard to believe. For me the clinching explanation (again, as a kid) was learning Venus was hotter than Mercury. And there is no reason to believe folks are lying about this, and I don't believe anyone is even contesting this.

3) Understanding how fossil fuels came into existence (basically, organic material trapped over centuries in the ground. again, the clue is in the name) and understanding the CO2 lifecycle, and how burning fossil fuels adds material to the CO2 lifecycle that was not there earlier. This isn't something that can be determined easily by a kid from 1st principles, but it's something that no one is really contesting either.

Once you accept these 3 fairly straightforward basic physics phenomena, global warming is inevitable.

The only questions are whether the release of CO2 is significant enough to have an impact, where we have to rely on measurements and scientists. But seeing that there was a fairly standard progression in how deniers would first deny global warming was ever happening, then deny that it was anthropogenic, then claim it wouldnt have as negative an impact, and now claim that well, it's too late...let's look at mitigation; I was able to filter them out when they were at step 1 itself.

Aside: I also want to point out the horrific misunderstanding people have about the terms "global warming" and "climate change" which are fairly self descriptive, but apparently is a nefarious effort to "hide the spike". Global Warming (i.e., more energy in the earth's ecosystem due to the greenhouse effect) leads to Climate Change (that is, changes in our climate behavior).

One is a cause, and the other is the effect. Both are valid and orthogonal concepts, and not some sort of conspiracy.

<comment><USER26> > 3) Understanding how fossil fuels came into existence (basically, organic > material trapped over centuries in the ground. again, the clue is in the > name) and understanding the CO2 lifecycle, and how burning fossil fuels adds > material to the CO2 lifecycle that was not there earlier.

Adds material to the CO2 lifecycle that was not there earlier? Isn't it just rereleasing CO2 that _was_ in the atmosphere earlier?

<comment><USER27> Much of the coal comes from a unique period in earth's history when there were many trees, but enzymes that could deal with lignins hadn't yet evolved. Which led to a steady and significant accumulation of carbon in that coal.

Humans, and much of the life we see around us, evolved in the subsequent periods of higher oxygen and depleted CO2. As we reverse that effect, we return the atmosphere nearer to how it once was - when humans and such weren't around. The planet and its life will be fine. Us and the multiple species on which we depend may well not be.

By burning it we are releasing carbon that has been stored for millennia and accumulated over millennia. It's introduced as though it were new into our carbon cycle.</comment></comment></comment></comment></comment>


Ask HN: How can we estimate the salaries of people in SF? - <AUTHOR>

Really simple question I don't know how to answer:
I've never lived in SF (though visit all the time). Trying to put together projections of what it would cost to hire people in SF, and I realize I have no idea. They're probably much higher than I assume, because the cost of living is just out of control. I know that if I were guessing what the price of housing is, I'd be way low, and I worry about estimating incorrectly in other places.
Are there general guidelines for what it may costs (for example) for different types of developers? Only looking for ballpark numbers, but as the SF economy seems to be unique to every other place in the world, I'm not sure how to ballpark this stuff. <comment><USER2> [http://www.glassdoor.com/index.htm](http://www.glassdoor.com/index.htm) collects salary information from self-reporting employees of various companies. Twitter, Uber, and other startups are in SF. Google, Facebook, and Apple use private buses to move employees from SF to their campuses in Silicon Valley.

A new grad from a leading CS school would start at over $ 100k, plus tiny stock option. Of course you need free food (at least lunch), and other perks.

[http://h1bdata.info/](http://h1bdata.info/) is a searchable database of H1-B visa requests. It can be searched by company, city, job title. Set the year to 2015. For example: Twitter software engineer median $127K, Senior SE $155K, Staff SE $ 169K, etc.

</comment><comment><USER3> I don't know of any databases or online suggestions to your answer, but they are probably out there with varying degrees of accuracy (GlassDoor?).

I also don't life in SF, but from HN comments I think the only guideline to salaries is 1) expensive as hell :)

I might suggest using your network to get these answers -- are there other companies that are similar to yours, already located in SF? As a founder, I think you would be building your network anyway, and this is a great question to ask founders of other companies. Like you said, ballpark is key -- so you're not off by a lot that might sink your company from the start.</comment>


AppStore Preferences can be unlocked by a local admin with any bogus password - <AUTHOR> https://openradar.appspot.com/36350507 <comment><USER2> This does not help at all for the drubbing that macOS High Sierra has been getting recently. Long term OS X users have been waiting for a Snow Leopard like release, but it seems like Apple isn't taking as much care as required on security and stability on the Mac. Something has to give — either Apple's organizational structure needs a change or Apple needs to abandon certain things completely instead of releasing sub-standard products that aren't expected from it.

As a long time Mac user, I keep hoping that Apple will decide to double down on better and deeper focus on all its products, including the Mac, its OS and ecosystem, and make the changes necessary across its organization and its teams.

<comment><USER3> I'm also a long-time Mac user, but I've really had about enough of this. Between the seemingly constant stream of security problems and the dumbing down of OSX (MacOS, whatever), I'm not sure I'm willing to pay a premium for this product anymore.

At the same time the Apple seems to be dropping the ball, some of the more noob-friendly linux distros are starting to look very attractive. And while Apple still seems to have the best hardware overall, a Lenovo Carbon X1 seems like a very decent option. I'm by no means a "pro" user (I have a decent understanding of computers, can get around on linux command line, some basic experiences in programming, etc), but I'm probably going to start making the switch, at least for my laptop.

Slightly off topic, but one of the only software issues holding me back previously was 1Password compatibility on linux, but apparently, it is now available (1). Anyone tried it? It's not a stand-alone application, but I'm probably okay with that.

(1) [https://discussions.agilebits.com/discussion/79940/a-present...](https://discussions.agilebits.com/discussion/79940/a-present- for-chrome-os-and-linux-users)

<comment><USER4> If some of the Linux distros would start trying to look like MacOS instead of constantly aping Windows, then switching would be a lot easier.

That's been the big reason I've never really taken to Linux. The GUIs all look like Windows with a skin. Where's the innovation?

<comment><USER5> This is not true in general. Linux Desktop UIs like Gnome 3 have taken a lot of criticism precisely because they have _not_ been copying Windows and have deviated considerably (due to patent concerns). Of course, there are some fringe "garage effort" Linux distros that don't care about patents and do just give some part of the community what they want.

As for innovation, Linux desktop UIs had virtual desktops and window tiling features long before Windows and MacOS.

<comment><USER6> > As for innovation, Linux desktop UIs had virtual desktops and window tiling > features long before Windows and MacOS.

Well, all commercial UNIXes had them before Linux was even a thing.

<comment><USER5> Yes I remember the CDE desktop had virtual desktops, but they go back even to Xerox Parc (according to Wikipedia). There are many minor aspects that have been tweaked and are perhaps newer ideas though. For example, on my desktop, I can search for a window title and get a list of windows across virtual desktops that are matches, and jump to the relevant desktop and window.

</comment></comment></comment></comment></comment></comment><comment><USER7> The interesting implication from this is that while it works for the App Store preferences, it doesn't work for the others, showing that there is a manual check that each pane is doing. Why aren't all of these calls identical? If each has to be handled manually, it's no wonder that there are bugs like this appearing.

<comment><USER8> My guess is that the App Store preferences isn't even meant to have the padlock. iCloud prefs doesn't have it, so I can only assume it's there by mistake.

If you try the same thing with say "Time & date prefs", it pauses with an incorrect password for a few seconds, then visually shakes indicating it's a wrong password. With the App Store prefs, it just instantly closes the authentication dialog, even with a blank password.

I don't really understand the logic as to why some panels in preferences have padlocks and others don't... Why does date/time need admin rights whereas Network (delete/add/reconfigure networking), Internet Accounts (delete/add any accounts?), iCloud (do all manner of things), Time Machine (back a machine up elsewhere?) don't require it?

<comment><USER9> Most OS's require admin rights to change the date/time because of the ability to mess with things like kerberos ticket TTL's, and other security issues.

<comment><USER8> I can understand why it would be there for date & time. I guess I more don't understand why it's not there for networking - you can add a proxy in (or even a whole new network adapter) for all network traffic without admin rights!?

<comment><USER10> I don't think "sharing-only" accounts can; only regular accounts. Keep in mind that a non-"sharing only" account is an account with a special privilege: it can log in through the local-framebuffer LoginWindow. This translates to an assumption that the computer is–at least temporarily— _in the physical possession_ of said user. They're at least sitting down in front of it; they may have been leased it by their employer.

The global prefs that can be reconfigured by "regular users" (i.e. non-"sharing only" users) are precisely those prefs required to keep the system in a working state if you're physically in possession of it and doing the things that possession of a computer implies. For example, you can move a computer you physically possess to a new location–at which point the same wireless networks won't be available, and maybe you won't be able to get online without a proxy. So, in order to ensure that just going places doesn't necessitate a call to corporate IT, the default† is to let any non-"sharing only" user configure networking.

† "Default" because these prefs _can_ be locked down using a configuration profile (like a windows Group Policy Object) by corporate IT if they need a computer specifically secured against these changes, such as a public-use kiosk.

</comment></comment></comment></comment></comment><comment><USER11> I have a feeling this isn't actually that High Sierra is that much worse, but more that people are now actively pen-testing macOS to find the next embarrassing bug.

And that scares me even more because of the unknown of how long such bugs must've existed in the system.

Is this Apple's Windows XP moment? (Like when MS stopped everything and did massive security training that resulted in XP SP 2 being worlds more secure?)

<comment><USER12> Most of the recently discussed High Sierra bugs were not there on Sierra, while the features were there, like this one.

So it's not that much pen tensting, but Apple making changes and not validating them correctly. Maybe they have their Vista moment with High Sierra, maybe we forgot previous buggy versions.

<comment><USER13> Could this be the result of shifting quality assurance to the general public through public betas?

<comment><USER14> For security-related bugs, maybe. When I file bugs with Apple (which I've mostly given up on), they are usually marked as a duplicate of another still- open bug. So it seems that people actually file bugs -- free QA works! -- but there's not enough time to fix them.

</comment></comment></comment></comment><comment><USER15> If you read the notes:

This only appears to be when logged in as a local admin. Tested with a non- admin account and I cannot unlock the prefpane with incorrect credentials.

So basically they are checking to see if you have credentials already. I guess this is a caching issue since you locked it.

<comment><USER16> That makes an awful lot of sense, in which case the bug is just not checking that the login is 'cached' before displaying the dialog. In a similar vein to another comment, though, why doesn't that dialog detect the state of the 'login cache' consistently across all occurrences?

</comment></comment><comment><USER17> Cmon Apple I know security people are in short supply but:

A) You have the resources B) This is the type of bug that any semi decent QA process should catch anyway

<comment><USER18> It seems like the type of bug that there should be a unit test for.

</comment></comment><comment><USER19> I'm on 10.12.6 and a local admin account, and it only unlocks to my actual password. That might mean it's a recently-introduced bug (assuming someone else can reproduce my result).

<comment><USER20> It doesn't reproduce for me on 10.12.6 either. It only works on High Sierra (10.13).

<comment><USER21> I can't reproduce it on 10.13.3 Beta (17D29a). So it might have been fixed already.

</comment></comment></comment><comment><USER22> sorry if this is a dumb question, but: why is it unreasonable for a local admin to have the power to change AppStore preferences? without knowing much about the osx security model, this sounds like not a big deal?

<comment><USER23> For certain features, they want you to reconfirm that the user presently at the keyboard is the real admin at the moment that you do it.

This prevents a situation where the actual admin logs in, their attention is taken away from the computer, and someone sits at their chair and does awful things with the computer.

<comment><USER24> What "awful" things could be done exactly in the App Store panel?

<comment><USER25> If they have "'Always Require' Password for Purchase" enabled, you could disable that and buy apps from the app store without a password.

For example you could let your kid use your Mac, but you don't want them spending your money via your app-store linked credit card. If they have access to the App Store Preferences panel they can disable the requirement and do so.

<comment><USER24> They would be prompted for the App Store password the first time a purchase was made after this is disabled so, no, that's not an issue here.

</comment></comment></comment></comment></comment><comment><USER26> If an Apple developer is reading this, your team should consider system-wide input testing. It'd be worth the developer time. Who knows how things can break if long, crazy strings are inserted.

</comment><comment><USER27> What do you get when you tell everyone that "MacOS and desktop computing are as important to our company as ever" when in reality you barely give a crap about it.

<comment><USER28> a cookie.

And a raise.

</comment></comment><comment><USER29> This is a fairly minor bug, since, apparently, it's only happens when already logged in as admin (and it's "just" App Store prefs). (I get that you can come up with scenarios to exploit this, but come in.)

But, wow, how many bugs is this for High Sierra where a password prompt can be bypassed?

It's like password prompt flu is going around Apple.

Was there bad sample code distributed or some change in the default behavior of some key API? (In addition to the obviously inadequate testing.) I guess it would make more sense to me if there was something connecting all these issues. (Besides the inadequate testing.)

</comment><comment><USER30> Can confirm it doesn't work on "Sierra", so it must be high sierra's feature.

</comment><comment><USER31> Can confirm - with my colleagues laptop - much to his amusement :)

</comment><comment><USER32> Though it is "queer", it doesn't seem to be that much a security issue, or - more probably - I am failing to understand the risk implied.

Can anyone describe a possible scenario where this would pose a security risk?

<comment><USER33> A user with access to a mac could enable the option to automatically install macOS updates, which given recent trends, could impose a security risk.

<comment><USER34> > could impose a security risk

How?

Installing a Mac OS update could be considered a security risk? That makes little sense since the security risks you're alluding to were solved by updates. 10.13.2 partially fixed the Intel problem in December and 10.13.3 will have more fixes. If you were still running 10.13.1, you'd have both the root login bug and the Intel security issues.

If you were still running Sierra, keeping Sierra updated results in solving the following security issues: [https://support.apple.com/en- us/HT207483](https://support.apple.com/en-us/HT207483)

The Mac OS version out right now is more secure than the previous minor or major version. There really isn't any credible evidence to the contrary.

It's irresponsible to not update your system. I understand not moving up to a new version of an OS because of compatibility issues (i.e. audio interfaces often are sluggish to update, libraries you need might not work, etc.,) but not updating because of security fears -- that's just ridiculous. 10.13.3 is more secure than 10.12.2.

Also, in order to "exploit" the reported bug, you would have to already be signed into the computer AS AN ADMIN. Which means that you could already change the updating behavior. So unless you are sharing your admin login/account with non admin users, the risk you cite is pretty trivial.

If you are in a higher risk computing environment, it would be logical that you would sign out of your account after you've finished using the system -- you would essentially have to provide an unauthorized person access to your Mac while you were signed in before this would be an actual threat. That doesn't make the bug less "real," but it does make the real-world security ramifications much less dire than being implied.

<comment><USER32> >If you are in a higher risk computing environment, it would be logical that you would sign out of your account after you've finished using the system -- you would essentially have to provide an unauthorized person access to your Mac while you were signed in before this would be an actual threat.

So, the most that can realistically happen is that if you leave your Mac unattended while logged in as Admin, a co-worker or friend might get in and install some app to play a prank on you.

I mean, unless _somehow_ a malicious app has been approved on the Apple store and is available to download through the changed setting (and the "evil" co- worker/friend knows about it), but still the base security risk remains leaving the device unattended and making it phisically accessible by smeone else while still logged in as Admin.

</comment></comment></comment></comment><comment><USER35> I don't know if I'm doing it wrong or maybe the problem has been fixed in the latest beta, but I can't replicate the problem on 10.13.3 Beta (17D34a). I lock the App Store preference pane and can't unlock it with anything except my real password. And yes, I am logged in as an Admin user.

</comment><comment><USER36> Maybe it's Apple's strategy - let macOS slowly disintegrate and then give iOS to frustrated desktop users as the only right way? Last time I've seen that strategy was when Nokia had a mole as CEO installed, though the outcome wasn't very nice to either Nokia nor MS...

</comment><comment><USER37> My AppStore preferences do not even have a lock icon on 10.11.6. Must be in newer versions only?

</comment><comment><USER38> FYI—I'm running the latest public beta of 10.13.3 (17D34a) and couldn't duplicate this issue.

</comment><comment><USER39> It's a bug. Bugs happen. It will be fixed. Take a deep breath, or a sedative, and relax.

</comment><comment><USER40> So is it that they don't have an automated test suite or the coverage is poor?

</comment><comment> oh-kumudo macOS High Sierra is such a disaster. Did Apple has any quality control over software at this point? No security vending? How could they have customers' trust if they keep making such idiotic mistake?

</comment><comment><USER34> Kind of a silly title "AppStore Preferences lock is a lie" \-- it isn't a "lie" unless Apple intended for it to not lock correctly. But obviously, it's a bug. It isn't like Apple is trying to deceive users.

Interesting bug, unnecessarily hyperbolic title for it.

<comment><USER21> It's supposed to be amusing. Think 'the cake is a lie'.

</comment></comment><comment><USER41> So basically it's a UI bug, not a serious security vulnerability.</comment>


5 Most Embarrassing Software Bugs in History - <AUTHOR> http://www.scientificamerican.com/article/pogue-5-most-embarrassing-software-bugs-in-history/

<comment><USER2> I just realised that quite a few HN readers would have been young children in 1994 and so won't really know much about the Pentium FDIV bug.

It was a big thing! All software has bugs; most processors have bugs; so when this one was found Intel downplayed the seriousness of the bug. For the vast majority of users there would be no problem. Intel eventually agreed to replace the device for anyone who asked. But this software bug was reported widely, in mainstream media.

[http://engineeringfailures.org/?p=466](http://engineeringfailures.org/?p=466)

This site has some nice technical information about it.

</comment><comment><USER3> "The Pentium chip's math error (1993)"

Pretty sure that's a hardware bug.</comment>


Dropbox ends XP support with only a month's notice - <AUTHOR> https://www.dropbox.com/help/9227 <comment><USER2> I think we're at a point with XP where any assumed support should be taken with a big handful of salt. If it works, that's great for you but don't rely on it.

XP has awful TLS/SSL support. No SNI (that's what allows you to host more than one domain/certificate on a single IP), ancient ciphers. This sort of encryption stuff is the bread-and-butter of Dropbox's service and having to maintain an in-client replacement to supplant the host's must be exhausting.

That's well before you consider that allowing XP machines to keep puffing along makes the internet a worse place. They get no updates, they're infected, rotting, smouldering sludge heaps just another day away from joining a botnet if they aren't already part of one. Third party software on them is starting to rot too. This all puts the rest of us at risk.

XP is the passive smoke of the computing world. Kicking it off the internet is the best result for everybody.

Edit: That isn't to defend the way Dropbox has done this. Just checked the Wayback machine and their minimum requirements page has been bleating on about supporting XP right up until now. They should have removed it from being officially supported when Microsoft did in 2014.

<comment><USER3> Why would Dropbox bother doing more than give a month's notice for an OS that is already unsupported by its vendor? I'm surprised they are giving that much notice in advance.

If you still use XP, you either have to for some legacy piece of software controlling some piece of expensive hardware, where it lives in some sandboxed environment (i.e., no public internet), or you are a government paying Microsoft through the nose for extended support contracts. If you really need Dropbox in that latter case, you can either afford to pay Dropbox an outrageous amount of money for that extended support (I am sure they are more then willing to if the price is right), or you just have to deal with it.

Anyone running XP should by now be aware that things will break down at awkward times and with little warning.

<comment><USER2> I generally agree but it sets a worrying precedent. "Today they came for XP and I said nothing" etc.

A public deprecation plan would be better next time.

<comment><USER3> But there was: Microsoft ended support for XP with a more than amiable deprecation plan. Anyone running XP after the final deadline knew they were on borrowed time, and any Dropbox customers remaining on XP after that were on a grace period.

How many people still use XP with Dropbox on an internet connected computer? And how many of those are paying customers? For Dropbox it makes no sense to go with more than what they are doing now. Why spend a lot of money in postponing the inevitable? It won't net them any returns, whilst dropping supported for a legacy OS does have tangible benefits (e.g., reduced build times, less (untestable) code, less support).

If you really need to run software on an unsupported, unpatched OS, you are way out of the realm of of-the-shelf supported software. You need a custom agreement with the vendor to get that level of support, and you would have gotten ample warning on the impending loss of support with such a contract.

It would be different if Dropbox axed support for Windows 8 with only a month of warning, even though they are fully within their rights to do so.

<comment><USER2> You're missing the point. Yes old buggy, unpatched software is awful. I know that. I _SAID_ that a few posts ago. The problem here is about how Dropbox communicated with their customers. Or —as in this case— how they didn't communicate.

Dropbox has known about the death of XP from 2014. It shouldn't have taken them over two years to remove XP from being a headline supported operating system. They should have said something months ago. They're the service provider. The onus is on them to communicate this stuff in good time.

Notice is important because organisations (of all sizes) have legacy systems that can take years to migrate to newer operating systems. Long notice about when your software dies allows you to plan. 30 days notice is going to ruin August for some people.

</comment></comment></comment></comment></comment><comment><USER4> This is inaccurate. I got an email back in April (4 months ago) letting me know about the deprecation. And I've gotten a reminder or two since. Maybe you missed the other notices?</comment>