Chrome 69: "www." subdomain missing from URL - <AUTHOR> https://bugs.chromium.org/p/chromium/issues/detail?id=881410 <comment><USER3> Considering a subdomain "trivial" is ridiculous... there's a difference between "www.example.com" and "example.com". Not only can they serve different sites, they can even have different DNS records!

It seems that "m." is also considered a trivial subdomain. So when a user clicks a link to a "m.facebook.com" uri, they'll be confused why FB looks different when the browser reports it's on "facebook.com".

I sincerely hope Firefox doesn't follow suit.

<comment><USER4> >there's a difference between "www.example.com" and "example.com"

Can you link to a site where these two are different?

<comment><USER5> From one of the comments there:

[http://www.pool.ntp.org](http://www.pool.ntp.org) vs [http://pool.ntp.org](http://pool.ntp.org)

One takes you to the website about the project, the other goes to a random ntp server.

<comment><USER4> Those go to the same place for me

<comment><USER6> Some small subset of pool servers run an HTTP server that redirects you to www. Not all of them. You just got lucky.

<comment><USER7> That's exactly right. www.pool.ntp.org is the project site. pool.ntp.org is for getting an NTP server. Which one you get will depend on your location and random chance. That server will run NTP, but what it happens to run on port 80, if anything, is up to the operator of the server.

</comment></comment></comment></comment></comment></comment><comment><USER8> Lots of people saying this is for the benefit of non-technical users.

For me, this is a minor inconvenience, precisely because I'm technically capable/interested enough to handle the inconsistency.

But this kind of stuff (and I am speaking somewhat generally here) tends to frustrate me, precisely when I'm trying to educate or deal with a non- technical user in some capacity where it happens to matter. I can't just tell them, " _that_ is the address of the page, and that will _always_ lead to the exact same place if you type it fully and correctly, and that's that". Instead I have to get my head around what if they're using browser X or operating system Y, I have to ask on the phone first, "hang on, tell me what you see on your screen", I have to say to the lady who's eagerly sat in front of me with pen hovered above paper waiting for me to dictate how to do a thing in straightforward steps, "well it depends, first you have to check this thing, and if it's like this then you can do this but it might also be like that in which case it's a bit different, let me explain" \- and this is usually the point at which the non-technical user gets tired and throws the book at me.

In short, I think _consistency_ of information and process is usually much more understandable and useful to users of any level, than the dumb 'simplification' of this half-baked information-hiding.

<comment><USER9> I wholeheartedly agree with this. There are two sides of the debate now. One side says that the machines should be clever enough to guess the user's intention and go around of their mistakes, while the other side says that the machines should stay as dumb and square. The question is about who is handling the complexity of this world, and in my opinion it should be often left to the human, not to the machines.

<comment><USER10> The worse outcome may be, if there's an ambiguity involved and the smart system takes precedent, but occasionally happens to take the wrong route – and suppresses any feedback for the user to intervene or even notice. Which is much, where we have arrived by this. I guess, collateral damage has become a matter of everyday life.

</comment></comment></comment><comment><USER11> Most comments assume that this is for solving user confusion, or security, or building a better URL scheme, et al.

It's not, that is all smokescreen.

As ivs wrote[1] They are going to hide amp subdomain, so you don't know if you're looking at AMP or the actual destination. And then suddenly the whole world funnels through AMP.

And for that reason, it won't be reversed until people call them for what they are actually trying to do.

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

<comment><USER12> AMP pages are served through google.com, though? It's one of the big problems with them.

<comment><USER13> Not always. Sometimes Google results have taken me to websites like "amp.reddit.com" on mobile.

</comment></comment></comment><comment><USER14> This and many other changes over a course of a short period of time have caused me to go to Firefox exclusively now. I heard Firefox is going to stop third party cookie tracking altogether. Why not give Google the big finger and use a different browser? Vote with your cold hard actions if you feel so strongly about something.

<comment><USER15> I switched to firefox a year ago. Its a little slower, but im a lot happier.

Ive been trying to degoogle as much as reasonable. I moved to fastmail as well. Still using an android, but would switch if a reasonable alternative that wasnt iphone came up. Im not paranoid or a privacy nut, just think google is too involved in my life.

<comment><USER16> Same here. Have you found any viable alternative to the Google Calendar? I'm at the point where I'm thinking about hosting a calendar project from GitHub myself.

<comment><USER17> Nextcloud, whether self-hosted or otherwise, works great! It's just WebDAV. You can get calendar, contacts, task, and note syncing, and it can even host your documents for reference management software like Zotero.

</comment></comment></comment></comment><comment><USER18> Safari already hides "www.". In fact it hides everything except the root-level domain, e.g. "[https://www.google.com/about/"](https://www.google.com/about/") shows just "[lock] google.com".

Firefox and Opera show the full domain but gray out everything in the entire URL except the root-level domain, so "www." is gray.

Just saying, de-emphasizing and hiding parts of the URL is clearly a trend. This isn't just a Google thing.

<comment><USER19> this is actually the main reason I cannot use Safari. It always boggled my mind that they made this decision.

For power users, they never look at the url unless they want information from it, in which case the `www` is valuable.

For low tech users, it can lead to straight up incomprehensible issues, like sites not rendering properly (think of a `m.*`).

The UI gains are so small, that part of the screen is never really looked at, but needs to be there, and typically has tons of horizontal room... I don't get it

<comment><USER20> Low-tech users don't often understand that a difference could possibly exist between "m." and "www." at all.

However, if it shows the TLD, they can confirm it says "google.com". Imagine they're visiting a Paypal phishing link, to the domain:

www.paypal.com.www.com

The most important thing to show the user is "www.com", because they're expecting "paypal.com". All the rest is nonessential for protecting users from bad actor sites.

<comment><USER21> Looking at the bug report, Chrome would actually show "www.paypal.com.www.com" as "paypal.com.com". At least Safari does the wrong thing the right way.

Personally, I always want to see the full URL. It's fine if part of the domain, the scheme etc. are grayed out to emphasize the second and top level domains, but don't omit elements that are necessary to fully identify the resource because the lowest common denominator may think that fishing.com/paypal.com is paypal.

<comment><USER20> Yep, I verified that bug as well, apparently they never planned for "www" being somewhere other than at the front of the domain name. Sounds like they already know, woot!

</comment></comment></comment></comment></comment><comment><USER22> The UX of moving what I'm looking at instantly under click is very unpleasant too, www. and http and even the "secure" "not secure" banners is like 200px shifts.

Lots of google's UI is getting (or has) things shifting instantly under the pointer it's quite annoying. The new gmail design quick-tools are often in the way, unknown until you actually click. Hell calling on my phone shifts the speaker and keypad buttons over instantly when someone picks up. Often placing the person I just called on hold if they answer too fast.

Wasn't this a pretty well covered UX rule to not move shit around on users. Up there with don't use modes and the like.

<comment><USER23> > The UX of moving what I'm looking at instantly under click is very > unpleasant too,

Could you expand on this? What are you referring to?

<comment><USER24> I don't know if it's the same thing, but I'll bite: it's absolutely maddening to edit or select part of a URL.

Click in the address bar and the entire address is selected, then you click on any part of it to either select a part or to place your cursor in order to add to it, after which Chrome appears to first shift the entire URL to the right in order to show the protocol, then it places the cursor within the shifted URL under your pointer. This causes (attempted) selections to be established from some other place in the URL than the user intended.

<comment><USER25> chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains

<comment><USER24> This is about Google having a fundamental weakness in product management and UX, giving me the equivalent of a Windows Registry setting to change is not helping, practical as it may be.

</comment></comment></comment></comment></comment><comment><USER26> Those who are saying this change is to make things "easier" for certain non- literate users may be correct, but they should consider whether such a justification is desirable at all from a moral perspective.

No doubt all of us have at some point been forced to learn things that we did not find particularly useful or pleasant to learn at the time, but then later experienced a great "satisfaction of knowledge" when faced with a situation in which that knowledge became advantageous or even essential, and then proceeded to use it to better ourselves.

Imagine a world in which none of that learning took place; one in which you never have to think, everything you see and do automatically satisifies you and keeps you in a blissful state of ignorance. Who makes the decisions in that world; or rather, who _can_ make those decisions? Who is in charge of your life? Not you.

Gradually reducing the motivation to learn, by making things "easy" and hiding/obfuscating anything that could be used as a starting point for more learning, makes for a population that won't think, won't learn, won't question or rebel. It makes them docile and easy to control.

Making statements like "ordinary users will never learn" is one thing, but explicitly making decisions to ensure that status quo is a horrible trend. It's quite a genius plan, and certainly used by organisations other than Google, but thoroughly disturbing.

I've said a few times before in the past: "knowledge is power --- they don't want you to have too much."

<comment><USER27> Some of my comments from 4 years ago when Chrome hiding URLs was just an "experiment":

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

</comment></comment><comment><USER28> I'm ok with hiding "www.", but it also hides "m." which is sometimes very confusing (I once opened a m.facebook.com link and was very puzzled why it uses the mobile site when the URl bar just shows "facebook.com").

<comment><USER29> What you may be surprised to learn is that Chrome isn't just stripping "www." from the beginning of the subdomain. "subdomain.www.domain.com" displays as "subdomain.domain.com"

<comment><USER30> I just downloaded canary and tried it and you are absolutely right.

about.www.github.io shows as about.github.io

I'm on board with this change in general, but this is absolutely something that needs to be fixed.

Not only is that just annoying and wrong, but it could be dangerous in some situations.

Also, it doesn't just stop at one removal.

        http://www.www.about.www.www.stuff.www.www.example.com

shows as

        about.stuff.example.com

Interestingly though it doesn't remove it if it's the TLD, or the actual domain (so stuff.www.whatever shows as stuff.www.whatever).

<comment><USER31> I'm guessing this is implemented as s/www\\.//

<comment><USER32> Here is the implementation: [https://github.com/chromium/chromium/blob/master/components/...](https://github.com/chromium/chromium/blob/master/components/url_formatter/url_formatter.cc#L71)

</comment></comment></comment></comment></comment><comment><USER33> Looks like this is intentional. To change it back go to chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains and disable the setting.

<comment><USER34> Additionally, if this flag ever goes away, the "kFormatUrlOmitTrivialSubdomains" is the internal flag for this, it seems[1], though its description says it's "Not in kFormatUrlOmitDefaults"[2].

Back when they removed the "http:" off of URLs, I used to use a hex editor to turn the kFormatUrlOmitHTTP bit flag off every time I got a new build, so I'd get the URL formatting I wanted, but eventually lost the mental wherewithal to continue the hack every week.

[1] [https://github.com/chromium/chromium/blob/3d41e77125f3de8d72...](https://github.com/chromium/chromium/blob/3d41e77125f3de8d722b6d8303599abaf2a91667/components/url_formatter/url_formatter.cc#L454)

[2] [https://github.com/chromium/chromium/blob/78aae16be65e409075...](https://github.com/chromium/chromium/blob/78aae16be65e409075816860e948d1536a548234/components/url_formatter/url_formatter.h#L82)

<comment><USER35> I have wanted to figure out for ages how to compute the location of these types of flags/vars in binary files.

Incidentally I want to figure out how to do this on Linux.

I presume I need debug symbol files, which I can download easily.

How would I do this?

</comment></comment></comment><comment><USER36> I hope people start moving from chrome to firefox. The standards they pushing are harming the web in ways.

<comment><USER37> If only Firefox's JS handling didn't melt my laptop.

<comment><USER38> Then turn it off.

<comment><USER37> I actually like to use websites that were made in the last decade, so instead of doing that I just use Chrome.

</comment></comment></comment></comment><comment><USER39> It begins. I saw this this morning, and thought it was something that was coming in the next few versions, not _right now_.

[https://www.wired.com/story/google-wants-to-kill-the- url/](https://www.wired.com/story/google-wants-to-kill-the-url/)

WTF? People get angry when you just move their cheese without notice.

<comment><USER40> >People get angry when you just move their cheese without notice.

Sorry, unrelated, but ahah, what is this saying? I love it and have never heard it before. I guess it's from some sort of book? [https://hbswk.hbs.edu/item/cheese-moving-effecting-change- ra...](https://hbswk.hbs.edu/item/cheese-moving-effecting-change-rather-than- accepting-it)

<comment><USER39> It's an idiom.

[https://www.quora.com/What-exactly-does-who-moved-my- cheese-...](https://www.quora.com/What-exactly-does-who-moved-my-cheese-mean)

</comment></comment></comment><comment><USER41> Even if you believe this is in theory a good idea, in practice it's clear that Chrome has implemented this extremely badly.

As Comment 5 on that issue points out:

> _This does appear to be inconsistent /improperly implemented. Why is www > hidden twice if the domain is "www.www.2ld.tld"? [...] If the root zone is a > 301 to the "www" version, removing "www" from the omnibox would be > acceptable since the server indicated the root zone isn't intended for use. > This isn't the behavior, though._

> _If example.com returns a 403 status, and www.example.com returns a 404 > status, the www version is still hidden from the user. The www and the root > are very obviously different pages and serve different purposes, so I > believe the should be some logic regarding whether or not www should be > hidden._

It's not very difficult to come up with a simple algorithm that checks HTTP standard responses and implements this in a sensible way: it seems Chrome's developers haven't even stopped to think about how this should be done properly though.

This is not so much a new policy issue as a buggy implementation issue.

<comment><USER42> Even dumber, from another comment-

> Another case I ran into:

> "subdomain.www.domain.com" displays as "subdomain.domain.com".

<comment><USER43> And people like github.com/m can now host something and it'll look as `github.io` hosted it.

</comment></comment></comment><comment><USER44> This is the third story today about a Google's handling/intentions towards web addresses and general webpages. The theme is Google wants/may want to push a new set of Google orientated web standards. This seems the least likely of the three to be strategically related,however.

The other two: Google may/may not be pushing the open web standard towards their own AMP pages, instead:

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

Google wants to get rid of URLs but doesn't know what to replace it with:

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

</comment><comment><USER45> I stumbled upon this bug too, and here's why this is not okay to me:

For a couple of hours, I thought Citibank Singapore's website was down.

If one tries accessing citibank.com.sg, there's no redirect to the www. subdomain. (That's still the case, if anyone wants to try.)

If Chrome didn't hide the www., I would have been able to tell from Chrome's search/address bar that the various banking services that I've been accessing were all on the www. subdomain.

While that is shoddy implementation on Citibank's part, hiding the www. most definitely didn't help with the troubleshooting process.

<comment><USER46> It's not a shoddy implementation on Citibank's part. Google are just fucking the web over so we all have to fit their structure.

This is standard incumbent behaviour, they are drawing up the moat bridge, inch by inch.

<comment><USER47> I think the downvotes here are uncalled-for. This is correct. Google is leveraging a dominant market position to make seemingly frivolous changes that will ultimately benefit them commercially.

Come on, you know where this is going: They are going to hide amp subdomain, so you don't know if you're looking at AMP or the actual destination. And then suddenly the whole world funnels through AMP.

<comment><USER48> > Come on, you know where this is going: They are going to hide amp subdomain, > so you don't know if you're looking at AMP or the actual destination. And > then suddenly the whole world funnels through AMP.

That's probably the reason for this utterly bizarre change.

<comment><USER49> isn't it because urls are Number 1 for phishing thou? wouldn't removing urls altogether and move towards full identity checks be better for the web? and relying on citibank singapore to hire the right people to fix their website... never going to happen.

<comment><USER50> > wouldn't removing urls altogether and move towards full identity checks be > better for the web?

Hey we'd be open to it, but we'd really prefer to have an RFC to read...

Instead, we got a quiet auto-update, without patch notes.

Good bye, open web. It was fun while it lasted.

</comment></comment></comment></comment></comment></comment><comment><USER51> This is idiotic and harmful. We already lost information about the protocol, because somebody believed it is "too complex" for users. Now we're losing other parts of the URL. It's making a joke of the SSL/TLS padlock, too — what exactly is the padlock supposed to tell me? It used to signify that a "known authority" certified that I'm connected to whatever I see in the URL bar. But now that browsers take liberties with modifying the URL bar as they see fit, it becomes increasingly meaningless.

<comment><USER52> 99.9% of users have no idea what any of the words you just said mean. The change was made for them, not for you (the .1%)

<comment><USER53> You're missing jwr's point. He's arguing that this is harmful for users, especially the ones who don't know what the words mean.

If I were solving this, I'd instead push to eliminate "www" altogether, not sweep it under the rug. It was useful circa 1996, when users might plausibly be using something other than the WWW with a browser. But it has become entirely vestigial.

<comment><USER54> Why not drop .com then as well? Most sites are on .com domains after all.

It is exactly the same issue.

A domain is a domain. Google is arbitrarily dictating your CNAME from the user's perspective.

What if you don't serve your site off of mysite.com is google going to automatically try again at www.mysite.com?

What if you have distinct content at both domains?

This decision is stupid.

<comment><USER53> It's not the same issue at all, in that domains with different suffixes are controlled by different people while foo.com and www.foo.com are controlled by the same people.

If you have an example of somebody who needs to serve different web content for foo.com and www.foo.com, I look forward to seeing it. But I've never seen one, and when I've seen it happen accidentally it's due to idiocy.

<comment><USER55> > while foo.com and www.foo.com are controlled by the same people

Sometimes. Far from always.

In some environments, `www` may be under an entirely different administrative domain, with lesser authority than the top level domain which is delegating web services to the `www` group by way of creating a dns record and/or adding an http(s) redirect to the parent domain.

Having some string values arbitrarily considered trivial is dangerous.

See: lbl.gov has address 22.214.171.124 vs www.lbl.gov has address 188.8.131.52

The root domain points to hosts at the lab. The subdomain has been delegated off to Google.

<comment><USER56> Isn't that simply due to internal politics? Whoever owns foo.com might delegate www.foo.com to someone else, but they ultimately control both.

<comment><USER55> It's due to different groups controlling different parts of the infrastructure, allowing for separation of privilege -- and is the whole reason www even existed to begin with.

Often these separate groups _aren 't_ part of the same organization. They're a different organization or contractor paid to maintain a web presence.

<comment><USER56> Yes, but those are decisions made by whoever controls foo.com. This may not be a good decision by Google, but I don't think they should be held responsible for a decision that was made by whoever controls foo.com.

<comment><USER57> This is completely backwards, because Google just made this decision _now_!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER58> Yo, this is... going too far, c'mon now.

While sure, www seems odd now, it's still a subdomain and we're inching into territory of obscuring things that matter for small gains in end-user perception that aren't _that_ impactful.

<comment><USER59> Yeah this is weird. Which users are bothered enough by the leading www enough to justify messing with semantics?

<comment><USER60> My bet is this decision is driven somewhere by marketing morons who want 'www.google' (presumably a domain that will at some point exist, the TLD already does) to render as simply 'google'

<comment><USER3> Technically there's no reason why a TLD can't have an A record. If they own "google." they can point it to whatever address and serve whatever they want.

<comment><USER61> Until recently, [http://ai](http://ai) did exactly this. They also had MX records, so n@ai was a valid email address.

<comment><USER62> That link works fine for me. It doesn't for you?

</comment></comment></comment></comment></comment></comment><comment><USER63> If the browser uses some technique to detect that www.domain.com is functionally identical to domain.com for a given domain, then I don't see a serious problem with this. But if they are short of that certainty, they're obscuring a critical part of the URL, and harming usability (e.g., if I want to jot down a site's URL for later use, I might get something unexpected).

<comment><USER64> That's not the case. I run a server that does not respond to "www." If I enter "www.myserver.com" into the address bar, I get a DNS lookup failure, but the address bar is now showing "myserver.com." That's damn confusing, and this is an idiotic default on Chrome's part.

<comment><USER65> That seems like an edge case worth submitting a separate bug for.

<comment><USER66> Think public suffixes! It is long, so definitely not an edge case.

You can write a small script to look up all PSL domains and check if the www and APEX domain has the same dns records.

Our implementation (we control 15 or so) does not, have a www-subdomain for the domains. Anybody can register the www-subdomains.

</comment></comment></comment></comment><comment><USER67> Lest anyone think that Chrome is being innovative here, this is Safari's default behavior for when the URL bar isn't focused. When you click on the URL bar, the subdomain, protocol, and path all appear.

<comment><USER68> Which drives me crazy, because my users send me screenshots in support requests. Now I have to spend even more time explaining to them how to click/copy/paste the URL. It was a terrible UX choice when Safari did it, and it's a terrible UX choice now that Chrome has done it.

<comment><USER69> Fortunately, it's trivial to toggle this setting in the Safari preferences-- and then the full URL will appear by default.

</comment></comment></comment><comment><USER70> Suddenly "www.com"'s value has skyrocketed in the eyes of scammers. How about:

* login.<target_site>.www.com -> login.<target_site>.com

* members.<target_site>.www.com -> members.<target_site>.com

Even some carefully chosen <target_site>.www.com's will now be valuable:

* login.www.<target_site>.www.com -> login.<target_site>.com

What a stupid idea...

<comment><USER71> That's just a bug which I'm sure will be fixed in the next release.

For this to actually help scammers (after the bug is fixed) they'd need to own www.example.com but not example.com, which is unlikely to say the least.

<comment><USER70> Yes, it is a bug, but until it's fixed it's a potential attack vector.

</comment></comment></comment><comment><USER72> Dear Google, just do syntax highlighting. Make the subdomain gray. You can even color https: green and http: red. But don't hide them. I really think syntax highlighting will accomplish the same thing for less technical users.

<comment><USER73> Grey is usually understood as greyed out: not selectable, non-functional and therefore counter-intuitive as well.

</comment></comment><comment><USER52> Why does this matter? Users don't care and its easier to remember/understand that all websites are just "x.com" rather than sometimes being "www.x.com". If you have some server/troubleshooting/network/dev problem with it, the missing info should be moved to developer tools.

This is just removing data that is useless and confusing to 99.9% of users - whats the problem?

<comment><USER46> Because they are on www. and not *.

What happens when you copy and paste that URL?

Now every single website that wants to support Chrome needs to ensure that [https://foo.com](https://foo.com) is always redirected to [https://www.foo.com](https://www.foo.com), or at least works as if it's www. It doesn't matter that most websites already do this, it's not standard, and represents Google breaking standards because they are big enough to do their own thing.

It's just one of the 1000s of papercuts that google is inflicting to keep users from switching web browser.

<comment><USER74> When you copy and paste, it has the whole URL - just like when you copy and paste now it will include http(s)://

<comment><USER75> What if you visually copy and paste? Parent is right.

<comment><USER76> One more reason to set up a redirect from or to www. _

<comment><USER77> Many MANY legacy sites serve different information at those two domains.

<comment><USER78> And this is wrong.

<comment><USER79> Maybe you have a niche target and not looking for mass adoption. It's not "wrong" it's just not normally the way things are done.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER80> This reminds me of Windows hiding file extensions by default. So annoying... now you don't know what your dealing with, it's harder to modify etc

</comment><comment><USER81> Seriously? This is such a bad change, I hope they revert this patch in the next update. There's a world of difference between the two and this is going to cause an ecosystem nightmare.

</comment><comment><USER82> That took just 8 years....

[http://blogoscoped.com/archive/2010-09-17-n17.html](http://blogoscoped.com/archive/2010-09-17-n17.html)

</comment><comment><USER83> _> This is a dumb change. No part of a domain should be considered "trivial". As an ISP, we often have to go to great lengths to teach users that "www.domain.com" and "domain.com" are two different domains..._

What ISPs teach their users anymore these days? Why the heck do we want to go back to that?

Time for a modicum of historical perspective.

If you care about usability this is clearly an improvement. This is part of a long-running industry trend -- Safari does this too -- to improve the usability of the Internet and technology in general.

At EVERY STEP in that journey there has whining and griping from the more technically advanced folks (like all of us on this forum). They zero in on the negatives, the tradeoffs that come with simplification. They don't see the positives because they're technically advanced enough and don't benefit from simplification (or so they think).

Then after the griping whines (sic) down and they realize the world didn't end and the downsides really weren't that bad and we move forward towards a better, simpler, more usable web.

Like, who actually runs separate HTTP servers on example.com and www.example.com anyway? Everyone is hyperventilating over contrived "the principle of it all" examples. Bottom line, Apple & Google are putting usability above technical pedantry. That's the right priority for mass market technology products.

<comment><USER84> Two prominent examples noted in the bug: [https://citibank.com.sg](https://citibank.com.sg) and [https://www.citibank.com.sg](https://www.citibank.com.sg) are different, [http://www.pool.ntp.org](http://www.pool.ntp.org) and [http://pool.ntp.org](http://pool.ntp.org) are different.

Like, big companies run separate servers on the two domains.

That's besides the fact where if you have www.example.www.example.com, it rewrites to example.example.com.

<comment><USER85> The first citibank url doesn't load for me, so it is site vs not site rather than two different sites, and both those ntp urls are redirecting me to [https://www.ntppool.org/en/](https://www.ntppool.org/en/) \- perhaps there's less substance than meets the eye to those complaints.

<comment><USER86> user1 - [https://citibank.com.sg](https://citibank.com.sg) doesn't work for me

user2 - it's fine, here is a screenshot of it working (while showing "beautified" [https://www.citibank.com.sg](https://www.citibank.com.sg))

how is that not confusing?

<comment><USER87> I think it's more on the website owners to fix their sites, users expect domain.com to be the same/auto-redirected to www.domain.com or vice versa. I think it's a good thing what Chrome is doing, it will push website owners to correctly set up their domain redirects and in the end, lessen end-user confusion.

<comment><USER23> I think this is a fair comment but Chrome has been doing this a lot lately. They'll make a change and developers must scramble to fix their websites.

It's the same with autocomplete earlier this year. One day Google decides to ignore autocomplete="off" and all hell breaks lose.

Interesting to note, they have reverted this change. Google now respects autocomplete="off" in some scenarios (i.e. when autofill is not triggered via name attribute).

Note: autocomplete !== autofill

</comment></comment></comment></comment></comment></comment><comment><USER88> Is this really a big deal? Don't many websites either redirect the www to the non-www, or the other way around?

<comment><USER89> It's about the principle. www is a valid subdomain.

Browsers are supposed to be as unopinionated as possible since they are _browsers_ , not mediators, and their job is to implement the standards of the web.

<comment><USER90> You want your browser to show unlimited popup windows too?

<comment><USER91> No, but I want my browser to notify me that its blocking popups rather than just hiding them from me entirely and assuming I never wanted to see them anyway.

</comment></comment></comment></comment><comment><USER92> To be honest, I want to see the actual domain I'm on in the location bar, and not some obscured version of it. In what universe is hiding part of the domain an usability improvement? What does it improve? Confusion? Misinformation? Lack of trust in the location showed by the browser? It's so stupid I had to check the calendar to make sure it's not the 1st of April today. I didn't check it in Chrome though, for fear that some days might have been hidden away as they have been considered trivial.

</comment><comment><USER93> You know, as much as I'm all for considering www a trivial subdomain, this should have had much more public discussion before implementing it into the most used browser in the world.

</comment><comment><USER64> To be clear, the "www" is only missing from the URL that is displayed in the address bar, while the browser is still attempting to resolve and fetch the URL with the "www." So instead of something that would completely break many websites, this is just something that is as confusing as hell for no good reason.

When a website requires "www" to resolve and respond, who in their right mind would want it hidden in the displayed URL?

</comment><comment><USER94> URLs can be complex and sometimes not intended for human consumption.

So fine, don't display the URL. Define a full-on standard that lets a user agent show a "friendly but not unwieldy" name to the user. You have that funky Graph API or whatever Facebook started to allow URL posts in Facebook to expand to include site info. Why not just use that at the top of browse? Then design the browser to allow access and editing of the URL somehow if desired (an old browser called 'OB1' didn't display the URL unless you pressed Ctrl-W, for example), but don't display it by default.

The truth is probably not many technical people directly enter URLs in browsers any more.

Honestly maybe it wasn't a good idea to allow query strings in URLs. Perhaps deprecate them and keep URLs looking like hierarchical filenames. Which honestly, is still something difficult to understand for non-technical people.

But this crap of hiding parts of it is dumb.

</comment><comment><USER95> I, for one, cannot wait until this is exploited somehow by phishers

</comment><comment><USER96> Safari has been doing this for some time.

The "trivial subdomain" will show when you click the url bar, however.

<comment><USER97> I'm much more okay with Safari's implementation, because it's significantly more discoverable. Safari also makes it much simpler to disable this behavior altogether, with it earning a place in the settings ... rather than being behind some "flag" that may disappear in some future release.

</comment></comment><comment><USER98> Google has signed a contract with ICANN as it is a registry and a registrar. In that contract it has agreed to limit behaviour that affects the security and stability of the name system. This behaviour of chromium is in contravention of that contract.

</comment><comment><USER99> I like how hugues.a. summarized it there:

This is Google making subdomain usage decisions for other entities outside of Google. My domains and how subdomains are assigned and delegated are not Google's business to decide.

</comment><comment><USER100> We allowed this to happen, we allowed Google to claim Internet and web, they make rules now, give up to and embrace hiding www. and to AMP before it's too late and you're out of the loop.

</comment><comment><USER101> I can somewhat understand the urge to de-clutter the URL and emphasize which parts are most important.

But I'd prefer they did it in another way which doesn't involve hiding anything. For example, render the most important parts of the URL in bold type, a color that contrasts more, or a slightly larger point size.

That way, you still make it easier for the eye to pick up the parts that the browser believes probably matter most, but you don't make it impossible to see the parts that might also matter.

</comment><comment><USER102> This makes me glad I use Firefox and have dropped chrome entirely.

</comment><comment><USER103> Google doesn't want you to use URLSs.

It must be this. They haven't given a single positive reason, except "users need not concern them with this information", which is so vague it's not even a reason.

Google is still (partly) a search engine, and people interacting with the address bar is pretty much the opposite of using a search engine. So Google wants to discourage that. They will never teach users how URLs work, how to read them and definitely not how to construct them, because it makes people less dependent on their search engine.

Think about it. Even the security part. Google wants to be the arbiter of what is secure and what is trustworthy. Anything that lets users figure this out for themselves, or that can be mediated without Google coming in between, takes away from this power.

They don't show http/https any more, just a coloured lock icon. The meaning of that lock icon is for Google to decide, unlike the meaning of http/https.

Now they take away information from the address bar, claiming it is irrelevant and none of our concern. They just want you to click on the links in their search engine, or some app or assistant thing.

One thing it is NOT about though, is distraction. If anyone knows that users can tune out irrelevant information perfectly fine, it's Google. They are an advertising network, after all.

</comment><comment><USER104> > _Why is www hidden twice if the domain is "www.www.2ld.tld"?_

plus

> _" subdomain.www.domain.com" displays as "subdomain.domain.com"._ <USER2>
> _[http://m.tumblr.com/](http://m.tumblr.com/) _[1]

Hoo boy. Can we officially call this a "shit-storm"? It seems extremely poorly thought through.[2]

[1] seriously, visit that right now. utterly brilliant username, I wish them all the best.

[2] unless you want to sell invisible AMP URLs. but then I want you to lose your job.

</comment><comment><USER105> The issue has only 46 comments at this moment because they have restricted the permission to comment, very nice. I thought there would be hundreds of, otherwise.

BTW, it sucks that existing comments cannot be voted or reacted with emojis, they should know this: [https://bugs.chromium.org/p/monorail/issues/detail?id=4248](https://bugs.chromium.org/p/monorail/issues/detail?id=4248)

</comment><comment><USER106> This should have been an opt-in feature. And if enough people opted in, only then do you make it the default, and _when_ you do that, alert all users to that change.

Hiding the protocol was understandable. For web pages it was 99% http or https, and they could convey which with an icon. (iOS Chrome still shows it for some strange reason). Then mobile Safari dropped everything but the domain name and everyone freaked out. But you can get everything back in Safari by clicking on it, but not on Chrome. Such a simple thing to implement.

If anything they could have just hid the query string, unless it's fairly simple like HN comments pages (item?id=17927972). But with pushstate, you could just hide the ugly bits (tracking, language, etc.) from the user. Take this Chrome promo URL:

      https://www.google.com/chrome/whatsnew/?hl=en&brand=CHZQ&utm_source=google.com&utm_medium=homepagepromo&utm_campaign=m69-whatsnew

Using JavaScript, before anything is displayed, simplify it to:

      www.google.com/chrome/whatsnew

And if you don't like _www._ , don't host at or link to that subdomain!

</comment><comment><USER107> Not in favor of Google deciding yet again how I want to browse/view the web. I've been extricating myself from Google services slowly, and I think it's time for Firefox again. Kind of arrogant to decide something like this for more than a billion users, and a step backward for those of us in IT who have a hard time getting the user to understand a visual difference in the address bar.

</comment><comment><USER108> If only we had something other than the subdomain to indicate what protocol we want to use to access the host in question. Like maybe some kind of... port number and/or protocol prefix.

"www." is useless. Eliminating it wouldn't be a bad thing.

"m." for mobile sites is extremely archaic. Sites should work on mobile without special subdomains.

If you issue subdomains to strangers on your root domain, the URL bar showing the subdomain shouldn't be your "security model."

The root domain is the root authority behind the site in question. Chrome showing users that information in a clear and concise way isn't "subverting the domain name system".

Safari has been doing this for a long time, and Chrome/Chromium have settings/flags that allow you to turn this behavior off. The amount of crying over this change is ridiculous in my opinion. As long as they keep this configurable (in fact, they should add a UI config for it) I see no problem here.

<comment><USER109> "www." is useless until you have multiple servers. Say you run a game server and a website on a web server for that game server as well. You need to give them separate domains so that they can resolve to separate IP addresses i.e. "www.example.com" might resolve to <web server IP> and "example.com" might resolve to <game server IP>. This is far more robust, faster and simpler (and how the system was intended to be used) than trying to set up some kind of proxying system on one of the servers to handle traffic really intended for the other one. In real world usage of course you'd probably put the game server at "game.example.com" and the web server at "example.com" but either way you end up with a subdomain, the arrangement with "www." as the subdomain instead of "game." is not really any more useless. I believe this can possibly be worked around with SRV records but then you have to rely on whatever your client might be handling SRV records.

> If you issue subdomains to strangers on your root domain, the URL bar > showing the subdomain shouldn't be your "security model."

What do you propose instead? Azure gives me custom subdomains for my servers that are immensely useful, being much more regular and memorable than IP addresses. I only see two solutions here: stop doing that or let anybody with access to subdomain creation pretend to be "azure.com". One of them is comically dangerous and the other is throwing out a perfectly good feature to save a handful of characters in the URL bar.

</comment></comment><comment><USER110> The point of this change is not to mess with www. or m. any other subdomain. The real reason for this change is obviously from latest google moves is to hide one and only one subdomain from users - amp. They really don't want you to know when you are not on independent website but actually inside google silo, playing by google rules.

</comment><comment><USER111> Is this supposed to be the first step of this? : [https://arstechnica.com/gadgets/2018/09/google-wants-to- get-...](https://arstechnica.com/gadgets/2018/09/google-wants-to-get-rid-of- urls-but-doesnt-know-what-to-use-instead/)

</comment><comment><USER103> This is such bullshit. They call it a "trade off", but a trade off between what exactly? On the one side there's a non-trivial number of negative consequences to this change, and on the other hand, the maintainer person literally is unable to give _any_ other reason besides, "this isn't information that most users need to concern themselves with in most cases".

No other reason given besides that _very_ vague assumption about .. I'm not even sure, say if most users _need_ not concern themselves with information that isn't there, does that mean they would otherwise be concerned about it? And what does that mean? And how is it bad? And why don't you just say so?

I'm calling bullshit. If there is a reason why they decided this, it is not that. My bet it's something political.

</comment><comment><USER112> Surprised to see not a single mention of Brave [1] in this large thread of comments as an alternative browser. It's not the best for development, but for casual browsing it's great. Brave blocks all ads and trackers.

[1] [https://brave.com](https://brave.com)

</comment><comment><USER113> I would just point out that HN does this in the title of every link posted, and has been doing this for years.

<comment><USER114> HN removes all subdomains, not just "trivial" ones. That's a separate issue.

</comment></comment><comment><USER115> As a developer on multi-tenant applications that are mounted on different subdomains, considering `site.com` same with `www.site.com` should be outright illegal! There is nothing trivial about the domains above and are considered separate unless configured to be pointing to the same record.

</comment><comment><USER116> [http://www3.www.audi.ch/](http://www3.www.audi.ch/)

</comment><comment><USER117> This is only visually what's displayed in the address bar, similar to how they started dropping http/https from the start of URLs a while back.

While I'd personally disagree with these kind of changes, and I would always prefer it to show the http/https and the www dot, it doesn't actually break things like copy and pasting the URL from the address bar. You still go to www.google.com when you type in www.google.com, it's just trimming away the www dot displayed in the address bar.

I think for the vast majority of non-technical people it's not really going to make even a little bit of difference. If anything it'll make it easier to spot what domain they're on, assuming they're even checking to begin with.

</comment><comment><USER118> Have any of you with corporate-type proxies been seeing authentication issues? Since moving to Chrome 69 a number of our users are reporting repeated proxy auth prompts when this should normally be handled transparently by Kerberos.

<comment><USER119> Yes, Chrome 69 has a bug with Kerberos:

[https://bugs.chromium.org/p/chromium/issues/detail?id=872665](https://bugs.chromium.org/p/chromium/issues/detail?id=872665)

<comment><USER118> PS: This becomes REALLY fun if you use cnames to load balance proxies. Which use Kerberos. <sigh>

</comment></comment></comment><comment><USER120> It's technically correct that www.example.com and example.com are different domains and can serve different stuff.

So are [https://example.com](https://example.com) and [http://example.com](http://example.com).

If you serve materially different content based on small differences, that's user-hostile, and common tools have no obligation to support you. Chrome shouldn't cater to sites that change behavior based on a www prefix, because the vast majority of users expect those sites to be the same. Hiding the prefix won't change their mind.

<comment><USER57> Small differences? A subdomain or an entire protocol is a small difference? And what about any web site that uses a "m." subdomain that doesn't intend it for mobile? I don't think that calling these things "small differences" is reasonable. And really, it makes perfect sense to not serve the same content over an insecure connection than over a secure one, but thankfully that change hasn't happened!

</comment></comment><comment><USER121> So now they've added "Restrict-AddIssueComment-EditIssue" to the bug. [Edit: This means that only users with EditIssue permissions may comment on it] Apparently we've complained too loudly for their liking.

</comment><comment><USER122> Most people don't notice or care, so this change makes no difference for them. For the few that do care, this change makes things worse.

So basically a dumb design-by-committee change that just wasted effort for negative progress.

</comment><comment><USER123> Thank you to whomever submitted this. My main annoyance is that when I want to go to a subdomain, I'll typically start typing foo.domain.com, but now the browser sets it to www.foo.domain.com. Annoying.

<comment><USER124> What browser auto inserts www? It's neither firefox or chrome.

<comment><USER123> Let me clarify: since the subdomain is hidden, I now have to munge with the URL input field to just get the full url to show up so that I can then modify the subdomain.

</comment></comment></comment><comment><USER125> If I was designing the user experience for accessing content from a global information, entertainment, and commerce network that would be used by a large, global, non-technical user base, I would not use the current URL format.

I would wager the twelve character prefix "[https://www."would](https://www."would) make no sense to 99.9% of the users and should be the default for over 99.9% of requests they would be making any given day.

I am guessing Google has evidence that this is the case.

</comment><comment> cc-d Between this and AMP it looks like google's abusing their market dominance to seize control over the open internet.

We were able to somewhat break up microsoft's attempt at something similar in the 90s through anti-trust legislation, perhaps it's time to look at google?

On a side note, it seems like the openness of the internet has come under attack more and more often in the past few years, from a combination of corporate and government entities. It's absolutely essential that we keep the internet open, transparent, and free.

</comment><comment><USER71> This isn't entirely without precedent. Firefox does something similar by greying out the `www` in the UI, Chrome just decided to take things a step further by hiding it entirely.

<comment><USER126> Firefox's behaviour is that is makes everything except the eTLD+1 grey, because that's what's normally useful for evaluating authenticity. There's no distinction made between `www` and any other subdomain.

<comment><USER127> These are all in the same origin so they can read cookies and manipulate pages.

<comment><USER128> This is not true unless the cookie is specifically marked to be domain-wide.

There was a time when IE misbehaved. Not sure if this fixed in Edge: [https://www.mxsasha.eu/blog/2014/03/04/definitive-guide- to-c...](https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-cookie- domains/)

<comment><USER126> > There was a time when IE misbehaved. Not sure if this fixed in Edge: > [https://www.mxsasha.eu/blog/2014/03/04/definitive-guide- > to-c...](https://www.mxsasha.eu/blog/2014/03/04/definitive-guide-to-c..).

Pretty sure that was fixed in Edge _and_ IE (as a security issue).

<comment><USER128> While that certainly may be the case, it's been shown time and time again how many users (and even sys admins!) are bad at installing patches.

</comment></comment></comment></comment></comment></comment><comment><USER129> I don't understand the war on URLs. I can't even _edit the link a bookmark uses_ in some browsers now, which is infuriating for SharePoint or other sites where "currently displayed URL" is not a clean and canonical URL (even though one exists). And when the terrible random URL jumble currently in the address bar won't even reproduce the page correctly later, this ceases to be a bookmark.

URLs may be _weird_ but they are _not_ so complex that we need these games.

</comment><comment><USER130> This is a classic example of techies, marketers and MBAs deciding what is "too confusing" for "normal" people to understand.

This is why the History channel shows reality TV instead of programs about, you know, history. It was decided that "history" that doesn't involve celebrities, aliens or Nazis is just too boring for normal people.

Google has decided that the 50% of population who are confused about the basics of URLs are more important than the rest of us who have been using them for over 25 years without problems. This will in theory allow Google to target a larger swath of the population. In practice, it simply takes something useful away from the rest of us.

It's "digital ochlocracy": The targeting of the least common denominator to the detriment of those with greater knowledge or expertise.

<comment><USER99> It's more sinister than that, they are devaluing the importance of URL so that you would have to search for it; the worst is yet to come.

</comment></comment><comment><USER131> ...I'm okay with this, I think. Has www (http over tcp/ip) not become the default protocol for "the internet" in the average person's mind?

<comment><USER132> I think websites should just stop using "www." entirely and host directly on their domain rather than a subdomain.

<comment><USER133> This causes browser security problems, it creates load balancing issues, it makes failover harder, etc. Only works for small sites that don't need to be highly available.

<comment><USER132> Why does it make loadbalancing and fail-overs harder?

</comment></comment></comment></comment><comment><USER134> Spirited discussion! I think for the average Joe, this change does not matter (i.e neither good, nor bad). Two better changes: a) highlight https / secure connections even more prominently, and b) detect and highlight misspelled domain names (a major cause of phishing attacks). Rationale is that for the average Joe, a clear warning that they are about to go to a bad site is more valuable than looking at the accurate domain name.

</comment><comment><USER135> Anyone know if this checks for a DNS record that supports equivalency between the www/empty subdomains? It's possible for them to have different values.

<comment><USER136> Even if DNS is the same, the host receives full host name in http and/or TLS headers and can trivially serve different content.

</comment></comment><comment> ezequiel-garzon Whether "we" like it or not, URLs are increasingly becoming a rare techy term. It is no wonder the average user has a problem with URLs with the advent of omnibars. I for one can't sometimes "force" Chrome to go to domain.com instead of searching that expression. Oh, and try to view the full URL you're accessing on your iPhone, particularly if you're GETting something other than /.

</comment><comment><USER137> I like the implementation bug mentioned that shortens subdomain.www.example.com to subdomain.example.com. That's just actively dangerous for users.

</comment><comment><USER138> Looking at everything that Google is doing at the moment, it looks like a shameful power grab for the entire WWW.

I suspect that Google wants to gradually get rid of URLs, because if users can't identify websites by their addresses, they will be more dependent on Google Search. Landing on search pages means that users will click on more of their well-concealed ads.

I think it's also the reason why Google Chrome's URL bar has such terrible auto-completion functionality. It appears designed to send users to Google Search to click on ads instead of taking them directly to their destinations. Firefox's old address bar didn't do that. (The newer address bar in Firefox appears to be following Chrome's time-wasting functionality, and its auto- completion no longer works well.)

Without URLs, users won't know whether they are really on your site, viewing your content on google.com (via AMP), or in some kind of app or PWA. To get to an item of content, most people will end up clicking on an ad in Google Search or land on an AMP page that eliminates most monetization options that don't involve passing the money through Google's systems.

URLs shouldn't be trimmed at all. When you're on the URL, [http://example.com/](http://example.com/), (note the trailing slash), Chrome will only display "[http://example.com"](http://example.com"), even if you copy it onto the clipboard. (It's still possible to fix it in Firefox with about:config.)

Technology shouldn't be made more restrictive and stupid -- users should be taught how to use technology correctly, and they will adjust. I've even met professional programmers who don't really understand URLs because their browsers mask the real URLs. The WWW isn't only about consumption -- it's about creating as well. People need to know how it works in order to create things.

</comment><comment><USER139> When people say they're sick of Google deciding what's good for the whole internet and leveraging their massive marketshare.. it's stuff like this they're talking about. Other little things too like their own non-standard implementation of IMAP/POP stuff. Invisible to most average users, who continue to merrily click away on Google $EVERYTHING and Gmail.

</comment><comment><USER140> Isn't this the same logic that still results in Windows users running malware because someone sent them _sexy_nudes.jpeg.exe_?

</comment><comment><USER141> I'm going to assume there will be no convincing The Team of people whose Wonderful Idea this was. [https://www.wired.com/2016/11/googles-chrome- hackers-flip-we...](https://www.wired.com/2016/11/googles-chrome-hackers-flip- webs-security-model/)

No more red purses? Give me a break.

</comment><comment><USER77> Surely Google of all companies has the resources to see exactly how much disruption this will actually cause. And I don't believe they get to make the decision based on that, but they should share the numbers. Any domain that returns different content between "m." and "www." vs. the apex domain are affected.

</comment><comment><USER47> Does it hide AMP subdomain? If so, I think we all know what this is about, and it's dirty and should be stopped.

</comment><comment><USER142> Google shouldn't be the authority to decide whether one Domains' part or another is "trivial".

</comment><comment><USER143> This is kind of what happened to the KeeFox addon for Firefox. The developer one day decided to have a new default for URL matching. Instead of matching the hostname, i.e. old.reddit.com, it would then match the 'domain' i.e *reddit.com. Back then it was as stupid as this is now...

</comment><comment><USER144> I am in favor of the change. I do not think hiding technical information from non-technical users is a bad thing. Making it impossible for technical users to work it out is the bad thing.

If technical users want their own browser mode, where all these things are readily available, then I'd be all for that.

Clicking on the browser location bar should reveal the full URL. But the noise of the protocol, the www. prefix, and the param string is all irrelevant to the experience of the casual user of web browsers and should indeed be hidden. We're already hiding a ton of stuff from them already, if you want to go see it, you can always "view source".

One argument in the thread was that 'www.pool.ntp.org' and 'pool.ntp.org' go to a website and a nameserver respectively. Nontechnical users will never want to use a web browser to access a nameserver, so there's no UX benefit to distinguishing them. From a URL entry standpoint, it should go to the URL that was typed into the location bar. There isn't a conflict.

<comment><USER145> It breaks how the web is supposed to function. There is no consensus on the utilization of subdomains and which ones are considered to be trivial. I could write an app which maps usernames to subdomains and Chrome would break this if a user had a username which was in the trivial list. I think Tumblr is a site which does this. It really isn't about technical or non-technical, it is about what subdomains can be used for.

Edit: well I was right, this breaks in the new Chrome, [http://m.tumblr.com/](http://m.tumblr.com/) , tumblr usernames on the 'trivial' list are broken.

<comment><USER144> There's no such thing as "how the web is supposed to function." There is an ideal that the plurality of the early web once sought to chase. There are more ideals that the more commerce-friendly users and creators of the web started to chase.

The norm is always shifting. It's our job as technologists to accommodate how people want to use technology, not to tell them that the way they want to use it is wrong. Because if we try to tell them no, then they're going to use the freedoms we labored so hard to give them to stop listening to us.

<comment><USER99> > There are more ideals that the more commerce-friendly users and creators of > the web started to chase.

What are those?

> It's our job as technologists to accommodate how people want to use > technology, not to tell them that the way they want to use it is wrong.

If some kids wish to use the technology to do DDos attacks it doesn't mean we should build it into the browser, the same is true here.

> Because if we try to tell them no,

Just say No to this crap, that's all.

</comment></comment></comment></comment><comment><USER146> For web developers it's a pain, but I can see how it might help everyone else (which is I assume the vast majority).

At least they haven't been as idiotic as Apple and didn't remove everything but the domain name like Apple did, and they did it incrementally.

</comment><comment><USER147> From the chrome flags [1] page: "On Mac, this enables MacViews, which uses toolkit-views for native browser dialogs." What is MacViews and how do I check if it is enabled?

[1] chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains

</comment><comment><USER148> Wow, if this actually gets released, might be the final straw to get me to switch off Chrome.

</comment><comment><USER149> I switched to the Firefox some time ago when Chromium always eat precious whole one CPU core time for stupid field trials.

Now I know Chromium is developed by bunch of idiots who don't understand the practical consequence of omitting the part of domain name.

</comment><comment><USER150> It's 2018 ffs and internet is everywhere. People should be expected to have better understanding of the internet and of what they see on their address bars.

Maybe instead of masking users from the "complexity" we should be teaching them instead.

</comment><comment><USER151> This is AWESOME! Thank you Chrome!

On a completely unrelated topic, there is a bug I'm noticing: ICANN doesn't allow emojis in TLDs.

What? That's ridiculous-- I can put them in the _main_ part of the domain name along with an enormous number of cute homoglyphs. So why not smileys and homoglyphs in TLDs? If users can deal with smileys in the main domain that tells where the site is, surely they can deal with them in the little extra part that comes at the end. Everything's just .com underneath anyway so what would problem be?

Google has done the work to remove the unsafe part of domains. Now our domains can really shine. So give us more bling to put in there, ICANN! C'mon.

Also-- why not www as tld? I love "biz" and "pizza" as much as anyone, but excuse me they got nuthin on the world wide web. C'mon ICANN give us "www" in the Trailing Little Domain! We're ready for it now! :)

Best, Your Userbase

</comment><comment><USER152> Just noticed: When clicking the main 'home' logo on facebook in Chrome 68, it's taking me to [https://www.facebook.com](https://www.facebook.com)

I'm sure it never used to do this. Did it?

</comment><comment><USER153> This is about as ridiculous as javascript making == not homomorphic for the reason of "making it easy for newcomers".

Please, _predictability_ and _consistency_ is what helps newcomers, not pandering to prejudiced intuitions.

</comment><comment><USER154> So apparently when Google said they would like to "fix" URLs, what they actually meant was that they would like to break them, whine about how broken they are in the future, and then come up with something worse.

</comment><comment><USER155> Although a firm NO-WWW believer this is hilarious because it is not the same as hiding http(s):// this is technically speaking an alternation of the url.

Still..with Google's horrible AMP efforts this seems nice :)

</comment><comment><USER156> Has anyone tried www.www.com? what's the bet that domain will display oddly...

And what if I setup a domain with a subdomain of the www? I'm sure also someone clever could find a way of using this for phishing.

</comment><comment><USER157> Isn't this on purpose?

</comment><comment><USER158> I would love to get rid of www but this going to confuse the heck out of people. We could get rid of www if more DNS providers supported ANAME. And Google Domains does not. How bout start there.

</comment><comment><USER159> [https://www.wired.com/story/google-wants-to-kill-the- url/](https://www.wired.com/story/google-wants-to-kill-the-url/)

</comment><comment><USER160> Curious, why did www.foo.com become the standard instead of using the apex/root foo.com domain? Was this because of the DNS limitations of using CNAME records at the apex/root?

<comment><USER161> Because HTTP was one service among many, not the primary one, and failed to use a different DNS record than A to look up the target, unlike other protocols which manage this redirection to the "$protocol server" that way instead of through a subdomain name. (E.g. mail has MX records to find the mail server, many other protocols use SRV records to discover their specific targets)

</comment></comment><comment><USER162> Instead, what they ought to do is go through the top 10,000 domains and test to make sure that:

1\. www.* doesn't end up as a 404 or DNS resolution error

2\. www.example.com matches the content from example.com

3\. www.example.com -> example.com is a valid permanent redirect

and then finally

4\. Publicly shame them. Don't hide it from people because you run into all sorts of UX issues.

I really hate www. for a multitude of reasons, but the biggest one is just thinking about the amount of time spent saying it out loud. Nothing aggrivates me more than turning on the radio and hearing "go to our website DOUBLE YEW DOUBLE YEW DOUBLE YEW DOT <some long name like nelsonfurnishingandrepair dot com>". That's like two seconds of air time they could recover.

</comment><comment><USER163> relevant quotes from a recent Wired article "Google Wants to Kill the URL"

> "People have a really hard time understanding URLs" \- Adrienne Porter Felt, > Chrome's engineering manager.

> "But I do know that whatever we propose is going to be controversial." \- > Parisa Tabriz, director of engineering at Chrome.

[https://www.wired.com/story/google-wants-to-kill-the- url/](https://www.wired.com/story/google-wants-to-kill-the-url/)

</comment><comment><USER164> Firefox is my primary browser, so it doesn't affect me, however this has already caused confusion within the web agency world I work in, both with technical staff and clients.

</comment><comment><USER165> Many not tech-savvy users I know, never use URL's. They use the address bar for doing a google search and then they click on the correct site in the search results.

URL's is already dead.

</comment><comment><USER166> Look at this [http://www.this.www.is.www.not.www.really.www.google.com](http://www.this.www.is.www.not.www.really.www.google.com) :-D

</comment><comment><USER167> The worst case of this that I've seen is with Safari on mac. The domain gets completely hidden if it's an HTTPS site that is "verified" (i.e. the entity shows up in Dunn and Broadstreet)

Visit "www.apple.com" in Safari and you will get "Apple, Inc" in the URL bar after a moment.

This seems like a potentially reasonable choice until you realize that someone could register, say "Apple, Inc" in another state and get a HTTPS cert to match it. One phishing email later and the Safari user is convinced they are logging in to the correct domain.

I can see lots of new phishing attacks made possible because of this. :(

</comment><comment><USER168> Between this and other recent changes they sure have been making some pretty terrible decisions lately. Hopefully this change is reverted.

</comment><comment><USER169> Pressing alt+d selects the address in the address bar but does not expand it, the expanded one is copied when you press ctrl+c. Hilarious.

</comment><comment><USER152> Crikey. Looking at the various tests done by people on that thread highlights some pretty amateur string logic by whoever implemented it.

</comment><comment><USER170> as a developer i can already forsee the pain of debugging an issue with cookies and realizing that it comes down to the subdomain

</comment><comment><USER171> Chrome 69 has been a joke so far, in UX, design and bugs (on Mac). It's good, because it will push more people to Firefox.

</comment><comment><USER172> Goodbye Chrome.

I dumped Microsoft when they tried to shove Windows 10 down my throat. I use them only when I have to now.

It's now Firefox for me.

</comment><comment><USER173> It's wierd how everyone seems to be so against to this change. hasn't safari been doing this since forever?

</comment><comment><USER174> What a stupid bug and yes it's a purposely developed bug. Will cause a lot of problems as noted.

</comment><comment><USER175> Embrace, extend, and extinguish. The story of Google and the Web. Don't AMPlify the issue.

</comment><comment><USER176> it's true that this change is going to break some stuff for some people, but i welcome it. www has to go. it provides no meaning (as opposed to john.example.com) and it serves no purpose, we have schema in URLs to figure out the protocol and port.

</comment><comment><USER177> Lol at "subdomain.www.domain.com" displays as "subdomain.domain.com".

</comment><comment><USER178> the amount of assumptions that browsers make nowadays is really getting out of hand.

Chrome on my work laptop doesn't even bother resolving a name that certainly does not look like an url but exists in the network.

Instead it will look it up on (guess what?) Google.

<comment><USER179> There's a particular 8-letter, simple subdomain for my domain (.com) where Chrome treats it as a Google search. Doesn't do it for any other subdomains. It makes no sense.

</comment></comment><comment><USER180> Where's the list for which subdomains Google considers "trivial"?

</comment><comment><USER181> Is this a Mac-only bug? I'm running Chrome OS and it looks just fine to me.

<comment><USER182> Chrome 69 has not be rolled out to ChromeOS yet, at-least on the stable channel.

</comment></comment><comment><USER183> Just updated to see it in action. Seems like a nice improvement for end users. Don't think there is any reason not to do this, other than a nostalgic desire for things to stay the same. Most sites already have a www. to . redirect in place and if you don't its a trivial change.

<comment><USER54> Why not drop the .com then as well? Most sites are on .com domains after all.

<comment><USER184> The obvious difference is that that's higher up in the hierarchy rather than lower in it. www.example.com and example.com are controlled by the same entity; example.com and example.foo may well not be.

</comment></comment></comment><comment><USER185> How immature to submit this as a bug. It was obviously an intended feature.

<comment> ng-user However it was intended by the developers is irrelevant to the average user using the product. To many many people this is a glaring bug.

<comment><USER185> Bugtrackers are not an appropriate place to post feedback on products. They are for listing bugs.

</comment></comment></comment><comment><USER23> This is worse than the time Google ruined autocomplete and autofill: [https://bugs.chromium.org/p/chromium/issues/detail?id=587466](https://bugs.chromium.org/p/chromium/issues/detail?id=587466)

</comment><comment><USER186> Same response as yesterday, stop using Chrome, now, there are alternatives.

</comment><comment><USER187> This seems fine.

I'm assuming you can always click to expand and show the full URL.

For a lot of people (devs especially) it would be nice to be able to change an option to see the whole URL at a glance, but for most people it's just a confusing mess they have to look through for the domain name.

</comment><comment><USER188> Ja this is terrible idea !

</comment><comment><USER189> It's been like this on mobiles for a couple of years right?

</comment><comment><USER190> Doesn't this make it easier to phish? Seems like it to me.

</comment><comment><USER191> Fellow HN's, why the hell are you still using chrome?

</comment><comment><USER192> Who cares will switch the flag. Who doesn't, just doesn't.

</comment><comment><USER193> Presumably chromium doesn't do this. I can see www.

</comment><comment><USER194> Subdomains are very important, stop hiding where I am.

</comment><comment><USER195> Chrome is a new IE.

</comment><comment><USER196> Is anyone else starting to see parallels between Google's attitude toward "progressing" Chrome and Microsoft's attitude towards IE in the 3-8 version days?

</comment><comment><USER197> chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains

disables this new "feature"

</comment><comment><USER198> "trivial", yeah okay sure...

</comment><comment><USER199> Just leave it alone Google. Sheesh.

</comment><comment><USER200> Man, I hate authoritarians.

</comment><comment><USER201> Next up: ".com" is trivial too, let's remove that too.

</comment><comment><USER202> Nice

</comment><comment><USER203> epic bikeshed

</comment><comment><USER204> Since everyone is wondering why, and since I happened to stumble across a reason during my time as a pentester, here you go:

Spearphishing is still one of the most common ways of breaching a corporate network. If I target you, you will likely fall for one of my attempts. If you are a company rather than a person, my odds go way up, because I have N chances to trick someone rather than 1 (where N is roughly the number of people at the company with email access).

This is one of those things that everyone says "Ha, I'm smart. _I 'd_ notice. You can't trick me."

And maybe you are. But you're also distracted. And that's my greatest advantage against you. All I need is to sneak in an unexpected Github prompt that looks completely authentic, and now I have your Github password. Wanna bet you don't have 2FA turned on, even though you know you really ought to? And even if you do, it's getting easier to social engineer your way past AT&T's lovely customer support: [https://www.youtube.com/watch?v=caVEiitI2vg](https://www.youtube.com/watch?v=caVEiitI2vg)

Ok, what's the point?

This: _Every character in the URL bar unrelated to the apex name is a deadly distraction._

Right now, how do you know you're actually on HN instead of some knockoff? "ycombinator.com".

How many characters do you have to read unrelated to that? "[https://news](https://news). /item?id=17927972"

The most _vital_ part of a URL for vetting identity is also, usually, the hardest to see.

Now, I don't know whether google made this change in order to assist with this. But it's one possible justification, and a step in a good direction.

We may not like it, just like we didn't like when Google removed the clickable "cached" links from search results, but in this case consumer protection outweighs our urges as a power user.

<comment><USER205> if the idea is to protect users so that you don't end up clicking on [https://news.ycombinator.com.myhackerdomain.com](https://news.ycombinator.com.myhackerdomain.com) , you then open the attack of a platform where they offer custom subdomains, and you have

[https://original.blogger.com](https://original.blogger.com)

and then

[https://fake-original.blogger.com](https://fake-original.blogger.com)

if I make them look the same, and the address will hide the subdomain, it looks like a step backwards in securing the web

now, imagine the actual platform has a payment section, and I create a fake subdomain that looks pretty similar, email you, boom, I get your cc info because I tricked you into entering new cc info (assuming your scenario of someone being distracted)

<comment><USER128> Only supposed " _trivial_ " subdomains are hidden, such as www. and m.

Anything else is still shown. fake-original.blogger.com will still show up as fake-original.blogger.com because fake-original. isn't a trivial subdomain.

I still think it's a stupid move, though. It's a simplification that is incredibly unnecessary and may be harmful when dealing with the rare site that doesn't treat www.domain.com and domain.com as the same.

</comment></comment></comment><comment><USER206> Once you get as big as Google or Apple, you're too big to fail and there is no longer any pressure to make good decisions because there are no actual consequences for making moronic decisions.

</comment><comment><USER207> A bunch of monkeys would have caught most of these bugs during testing - <USER2> have done a better job with the coding in the first place.

>[http://www.example.www.example.com](http://www.example.www.example.com) -> example.example.com

What the fuck. I don't even.

</comment><comment><USER208> The fix is to change your subdomain from "www" to "amp". You can read more about it at the IETF website located here:

[https://www.ampproject.org/](https://www.ampproject.org/)

Please submit any complaints you have as a video on YouTube.

<comment><USER209> Please tell me this is a joke...

<comment><USER88> The "Please submit any complaints you have as a video on YouTube." part really makes it look like a joke

<comment><USER210> That line was added as an edit

</comment></comment></comment></comment><comment> another-cuppa Glad I don't use Chrome. Hope this doesn't happen too Firefox or that'll be another entry in my /etc/portage/patches

</comment><comment><USER211> I would guess this makes Chrome and non-standards compliant browser.

</comment><comment><USER133> Google attempted a more extreme version of this four years ago: [https://www.extremetech.com/computing/181657-google-moves- to...](https://www.extremetech.com/computing/181657-google-moves-to-kill-off- the-url-entirely-in-new-version-of-chrome)

So they're doing it again, just slower: [https://www.extremetech.com/computing/276454-google-wants- to...](https://www.extremetech.com/computing/276454-google-wants-to-kill-the- url)

I'm pretty sure the eventual plan is to force everyone to browse the web using a version of the App Store, which we all know is incredibly secure, and never difficult to use.

<comment><USER182> I don't think your conclusion is correct, but the assertion that they want to get rid of the URL was posted on Hacker News a couple of days ago:

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

</comment></comment><comment><USER212> Cool, the internet is changing is to my personal preference. Don't like www.

</comment><comment><USER213> Stupid crap like that is one of the reasons why Chrome isn't my primary browser.</comment>


Please scan my towel - <AUTHOR> http://jerrygamblin.com/2016/03/01/please-scan-my-towel/ <comment><USER3> RFID is one of those things that seem cool until you start playing with it and then it turns out that the only uses for it are really boring. Like, you can't use it to locate stuff because the range is too short; you can't rely on stuff to have chips (food, or clothes or whatever) and it's a major time sink if you'd have to start tagging stuff yourself; it's cumbersome to install readers everywhere and not being able to rely on half lives measured in decades instead of months, etc.

I used to have an rfid chip implanted in my hand. I had all these ideas of what I was going to do with it - log on to my computer by putting an rfid reader in my keyboard, build a magic 'touch the wall and music starts playing' thing etc. All of them turned out to be very boring and useless in practice. Logging into my machine - meh, turns out that it takes longer for monitors to come back on than to type the password. Building (useful) user interfaces based on rfid is very hard and doesn't add anything over a regular proximity sensor.

The only idea I have left is that in my current house, I have a place where I could put an rfid reader so that if I'd get a chip implanted in my gluteus maximus (my butt, essentially) I could activate an automatic door opener by bumping into it when I have my hands full. I just can't motivate myself to set this up and discovering again that it's a dud in real life.

<comment><USER4> Wait, sorry... what?! You had an RFID chip implanted in your hand???

I think that story deserves a little elaboration.

EDIT: Wow, this is apparently a thing. [0]

[0] [https://en.wikipedia.org/wiki/Microchip_implant_(human)#Hobb...](https://en.wikipedia.org/wiki/Microchip_implant_\(human\)#Hobbyists)

<comment><USER3> Not much to it, really. It became feasible around 2007-2008 ish or so, when you could buy glass ampules with rfid tags in them and simple readers retail online (my timing might be a few years off). There were several forums about it at the time, most of them gone now it seems; I suspect because people found out the same thing I did, that it's just not that useful and that the novelty wears off after the first 5 times you wave your hand over a reader and have a led go on or a dialog pop up on a screen.

I went to a piercing study, girl stamped a hole in the upper layers of my skin, made a small cut to open it up a bit further, slid in the ampule (which had been autoclaved first of course). Band aid on it, done. It was strange being in a studio with a bunch of people with facial tattoos and horn implants and discs the size of my wrist in their ears - and _them_ looking at _me_ like I was a freak from out of space. I do have to say though that I had to search around a bit to find someone willing to do it. There are plenty of places that will take your money to suspend you from their ceiling with flesh hooks in your back, but that won't stick a glass pill under your skin. Go figure.

You can also buy kits online if you want to DIY - basically big needle guns that are used to tag cattle which you just jam into your hand and pull the trigger on, literally. That would've been a bit too hard core for me, tbh.

<comment><USER5> Compared to using a biometric such as a fingerprint it makes some sense. Fingerprints can in theory be stolen and reproduced, and you can't change them if that happens. You could replace an implanted RFID tag if that were ever to become necessary, but otherwise it's something you always have like your fingerprint.

</comment></comment></comment></comment><comment><AUTHOR> I posted this in part because I love the idea and because today is the anniversary of the birth of Douglas Adams.

Edit: said death meant birth.

<comment><USER6> It's actually his birthday. He died on 11 May 2001.

<comment><USER7> It's March :)

</comment></comment></comment><comment><USER8> This story doesn't quite make sense. I believe that his RSA pass was clonable and that his towel also had an RFID chip embedded in it. What I find hard to believe is that the towel had a _writable_ RFID tag.

My main experience with RFID is cloning tags onto T5557 chips, and I don't think I've ever come across a writable tag in the wild. It doesn't seem to make economic sense to spend an extra penny or two on every towel to put in a tag you are never going to change.

<comment><USER9> I recently was at a Panera Bread, and when I put my Android phone (with NFC) onto the table, it immediately helpfully popped open tagwriter.

Turns out they didnt lock the tables' tags, so you could write urls and when people placed their phones down, had those urls open. (they used the tags for their food pager system)

<comment><USER10> The ones at the Panera I used to work at weren't writable (I know this because I saw people trying more than once). How long ago was this?

<comment><USER9> A couple of weeks ago. It did take some work, it seems like there's a "sweet spot" that I had to hit, and some experimentation that required rotating the phone on the surface, but I was able to write google.com and then pop it open on my tablet.

</comment></comment></comment></comment><comment><USER11> OK, the RSA conference failed here. They're supposed to be a security conference, yet they didn't use an RFID tag that's challenge/encrypt/response, so you can't clone it by passive listening. RSA itself used to make such things.

That tag is about the right level of security for towel inventory. The big win in this is managing outsourced laundry costs. Knowing how many items went to the laundry, and how many came back, rather than just counting linen carts, matters a lot. ABS Laundry Solutions overview (with ominous music) [1]

[1] [http://www.abslbs.com/](http://www.abslbs.com/)

<comment><USER12> That might not have been an oversight.

Having designed the RFID tag system for a conference before, there's a real cost difference between crypto-capable NFC tags and ordinary ones, once you factor in the number of badges you need to print.

Then consider that (a) the conference probably has very little budget for an RFID implementation, and (b) the NFC tag isn't used for anything that's security-sensitive -- mostly checking in at vendor booths, attendance tracking, etc.

Given that, I can totally understand why RSA didn't use something more secure.

The BIG fail here is that the towel manufacturers didn't toggle the read-only fuse in the tags, which allows them to be overwritten by anyone with an Android smartphone.

</comment></comment><comment><USER13> Reminds me of how someone embedded the chip from their Oyster card (London travel card) in a magic wand :)

<comment><USER14> I also immediately thought about this! :) [https://41.media.tumblr.com/tumblr_m3i9ic6qKJ1qg9f5xo1_400.j...](https://41.media.tumblr.com/tumblr_m3i9ic6qKJ1qg9f5xo1_400.jpg)

</comment></comment><comment><USER15> Wait, towels have RFID tags?! Never heard of that before.

<comment><USER16> Hotel towels, to prevent theft.

<comment><USER17> How do they prevent theft, exactly?

<comment><USER18> A customer checks in and is given a towel with a customer specific RFID attached. If at the point the customer checks out and the towel is not in the room, it is assumed to be missing or stolen.

<comment><USER19> Er, no. Have you been to a hotel? They don't normally give you a single towel for your entire stay. The hotel changes the towels every day. Bulk RFID scanning during laundry lets them keep track of how many towels have gone wandering and individually track how many times specific towels have been laundered, which is probably useful information for managing towel quantities in bulk. I don't think tracking down and identifying individual towel thiefs is generally the idea, though I guess you can detect towels in places they are not meant to be (such as in their suitcases on the way out of the lobby).

</comment></comment></comment></comment></comment><comment><USER20> There's a frood who really knows where his towel is.

</comment><comment><USER21> Discussed thrice already. Kinda, never caught up.

[https://news.ycombinator.com/item?id=11212357](https://news.ycombinator.com/item?id=11212357) [https://news.ycombinator.com/item?id=11207155](https://news.ycombinator.com/item?id=11207155) [https://news.ycombinator.com/item?id=11217681](https://news.ycombinator.com/item?id=11217681)

</comment><comment><USER22> Interesting. Where I can find more information about reading RFID chips?

<comment><USER23> [https://en.wikipedia.org/wiki/MIFARE#Security_of_MIFARE_Clas...](https://en.wikipedia.org/wiki/MIFARE#Security_of_MIFARE_Classic.2C_MIFARE_DESFire_and_MIFARE_Ultralight) seems to be a good start.

<comment><USER24> This reminds me of the ubiquity of insecure MIFARE Classic chips.

My previous workplace (an international organization that shall remain anonymous) had vending machines where you could "buy" an RFID key that acted sort of like a "wallet". You could refill it by putting it inside the vending machine and then inserting coins, or you could use it to buy goods from the machines. It used MIFARE Classic and was trivial to break, and the cash amount was stored as cents in a short integer. Fun stuff, you could even buy deodorant and panties.

Then, several towns in my country use RFID cards for public transportation payment. Guess what? Even systems implanted AFTER these cards were deemed highly insecure are using them.

<comment><USER25> One place I worked at while in college had a similar thing with smart cards. The vending of the product and debiting of the card wasn't an atomic operation, so if you removed the card at the right time you'd still get the product but not be charged.

<comment><USER26> They must have changed that. At a cafeteria that uses MIFARE cards the operation is still not atomic, but the customer loses: If you remove the card at the wrong time, the card is debited but the transaction does not show up on the cashier's terminal, leading to heated arguments. The transaction _does_ show up in the central database, so after spending 20 min writing a complaint you get your money back after a few days.

I guess this is called progress.

</comment></comment></comment></comment></comment><comment><USER27> I was a CTO strategy consultant for an RFID MIST startup back in 2008 - <USER2> is RFID chips on documents, id badges, and any item of value within an organization. The MIST is a series of wireless sensors & network placed throughout the organization, enabling 3D location of any RFID marked object within range of the MIST network. The system could track who, when, and where of any person or item of interest simply by following the RFID through the series of sensors. However, there was zero plan for security of the RFID signals nor the MIST network itself, they were planning on security by obscurity. As I made more and more noise that security was their entire mission, and by not having any themselves they were setting themselves up for massive hacking. Thankfully, their main inventor was more interested in surfing than working, and their investor got deported for tax fraud.

</comment><comment><USER28> This article succeeds with just a few words and well chosen pictures.

</comment><comment><USER29> The Proxmark is a great tool... there is a nice forum here: [http://proxmark.org/forum](http://proxmark.org/forum)

</comment><comment><USER30> RFID is definitely one of the cooler things that exist on the practical/futuristic feeling matrix. Really wish I had some need for one

</comment><comment><USER31> Could this be done using a phone with NFC? Thats pretty much RFID tech isn't it?

<comment><USER12> Yes, it was a Mifare Ultralight C, which most Android phones can talk to.

</comment></comment><comment><USER32> Disney has a pretty neat use for RFID that was featured in a previous HN post. [https://news.ycombinator.com/item?id=9177105](https://news.ycombinator.com/item?id=9177105)

</comment><comment><USER33> I'm kind of wondering what sort of towel hacks can be done now to truly create a hitchhiker's kind of towel

</comment><comment><USER34> Oh, what a hoopy frood.

</comment><comment><USER35> Is proxmark3 still the device to get?</comment>


Internet Explorer: How did IE get to be so bad? - <AUTHOR> http://www.quora.com/Internet-Explorer/How-did-IE-get-to-be-so-bad-relative-to-Chrome-Safari-Firefox#ans2196677 <comment><USER2> Simply put: Because of neglect.

</comment><comment><USER3> windows ME, windows vista, windows 8, IIS 7, SQL...How did they get to be so bad</comment>


Ask HN: Are software UX patents still used/enforced? - <AUTHOR> The last big patent issue I can remember is the [1] Samsung vs Apple on the slide to unlock lawsuit.
Which is strange because it seems software is more homogeneous than ever. Everyone's using the same standardised components and UX designs. Hamburger menus, pinch zoom, pull down to refresh... etc
Have companies given up trying to protect their UX ideas? Or is everyone somehow using open and free ideas, which can't be patented?
[1] https://www.google.com/amp/s/www.news18.com/amp/news/tech/apple-wins-120-million-in-slide-to-unlock-patent-infringement-case-against-samsung-1569345.html <comment><USER2> Ideas shouldn't be patentable, implementation on the other hand might

[https://www.theregister.com/2020/05/21/gnome_foundation_sett...](https://www.theregister.com/2020/05/21/gnome_foundation_settles_patent_troll_lawsuit/)</comment>


Scrum Friendly Features in FogBugz 7 - <AUTHOR> http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

<comment><USER2> Based on the number of popular essays Joel Spolsky has squeezed out of FogBugz, you would think it was a revolutionary software project on a par with Engelbart's 1968 demo, rather than... a bug tracker.

I have never used it myself. Perhaps it is the Platonic bug tracker. Still, like Manila or fetchmail, the project itself seems out of all proportion to the mighty river of wisdom that its author has coaxed out of it.

<comment><USER3> I haven't used Version 7, but I have used previous versions, and I can assure you, it's not at all the Platonic bug tracker. In fact, if you take a look at this article, you'll see that certain basic features (such as setting milestones) have been pretty clumsily implemented through the first 6 versions, at least.

You'd think that a team of rock stars in a a cubicle-free paradise with the benefit of Joel's wisdom would be able to really nail an application as trivial as bug tracking over the course of 7 versions. You'd think.

<comment><USER4> I think that even a team of rock stars in a cubicle-free paradise are still beholden to whatever set of development priorities they are handed.

</comment></comment></comment><comment><USER5> I once had the displeasure of using Fogbugz (hosted version). You could only reply to a bug if it was sent in via E-mail. Any other correspondence was to be performed via actually editing the ticket data, inline.

I called to ask if there was a way and the dude I talked to actually insinuated that I had not taken time to read the documentation. WTF?

Apparently that requirement was a "feature" -- they assumed that a bug entered manually did not require correspondence.

Yes, I was told that as well.

</comment><comment><USER6> Show of hands. Who is using Scrum at their startups?

<comment><USER7> I've used it before in G.ho.st (<http://G.ho.st>) and I'm using it again in a new project I'm building.

</comment></comment><comment><USER8> I like Joel's essays as much as anyone, but how is this not pure advertising?

<comment><USER4> I too have a hard time lasting it out through an essay that seems very self- promotional. Many essayists whose work I used to look forward to reading (J. Spolsky, P. Graham, etc) seem to have become stuck in a rut of beating a particular set of drums. These drums seem to promote in some way, the business interests of the person writing.

To me this diminishes their credibility and puts me off their writing.

Strangely when I see Lessig doing this for his various causes it does not inspire the same reaction in me. Possibly this is because I don't think that Lessig is deliberately writing in a way that can lead directly to personal monetary profit, although he certainly could profit from his growing cachet due to his political activity.

Possibly I am just being cynical.

</comment></comment><comment><USER9> "Each "Sprint" lasts around 15-30 day"

This seems to be ignorant of the use of one-week sprints on some projects. Also, what kind of sprint lasts "around 15 days"? Sprints are always fixed- length (scope is varied to fit the sprint). Two-week sprints are used by some, but nobody does 15 day (aka two weeks plus one day) sprints.

<comment><USER10> For some, 15 days is exactly 3 work weeks.

<comment><USER9> 15 _working_ days is 3 work weeks. "Exactly 15 working days" might be a reasonable length for a sprint, but "around 15 days" is not.</comment></comment></comment>


Kepler team just announced the discovery of FIVE new planets - <AUTHOR> http://blogs.usatoday.com/sciencefair/2010/01/nasas-kepler-mission-finds-5-new-planets.html

<comment><USER2> More new planets discovered, our knowledge of our Universe expanded by a large percentage. And I find I can't get very excited. This syndrome needs a new name: Cosmic-mindblowing-discovery-burnout syndrome doesn't roll of the tongue.</comment>