You're right! Google and Cloudflare are already jointly destroying the meaning of URLs through their "AMP real URLs" specification which allows any AMP gateway to impersonate a host, guaranteeing authenticity of the content through public-key cryptography.
https://blog.cloudflare.com/announcing-amp-real-url/
These changes to the fundamental bricks of the web are not without consequences. They are deliberate attacks on a free and neutral network of equal peers.
Or, from another perspective, they’re pushing for a URL shown in a navigation bar to represent the origin of a document, rather than where you attained it from. (Which is already true of SOCKS and HTTP CONNECT proxies, of course.)
Personally, I’m for that change, because if it becomes a predictable part of clients, formats will emerge to attach signed origins to more document types (e.g. images; PDFs) and then people won’t be able to do easily lose the source of these documents. Imagine Wikipedia being able to automatically cite the “original origin” of anything you link!
Very good points, but the devil lies in the details. Preserving authenticity of web content through public-key cryptography is of course a welcome change. But HTTPS is for encryption from the client to the server (Transport Layer Security). So browser UIs were designed so a lock next to a URL meant you securely connected to the host of the URL. That's what we've been teaching people browsing the web for more than a decade.
Subverting the meaning of URL bars and HTTPS indicators to make Google's control over the web less visible to the end user is of course a very politically-motivated choice and is yet another direct attack on the web as we know it to promote corporate interests. I would be all in favor of adding cryptographically-enforced authorship information in browser UIs, but would rather add a clickable "person" icon next to the HTTPS lock.
So in the end you would end up with visual indication that a secure connection was established to the Google AMP gateway (or whatever website) and that this website is sharing content that provably originated from somewhere/someone; you would just have to click the button to figure it out (just like for TLS connection details).
Also, if authentication of content is a concern or interest of yours, maybe content-addressable systems such as IPFS/DAT (among others) could interest you.
> formats will emerge to attach signed origins to more document types (e.g. images; PDFs) and then people won’t be able to do easily lose the source of these documents.
There are already standards for doing precisely this on the web. ActivityStreams with Linked Data Signatures comes to mind, for example. But these corporations have no interest whatsoever in building an open and federated web.
We're talking about Google. The company who, for example (among many other scandals) stopped federating their XMPP server (GTalk). From the switch of the button, they consciously chose to prevent millions of people who were previously chatting just fine to do just that. If that's not a manifestation of evil corporate power, i don't know what is.
That's just not the way Google is headed.
Well clearly Google expect people not to. They expect people to "Google" for whatever they want.
Imagine a world where 99% of users do not have any concept of URLs or any other fundamental WWW concepts. Instead, they open Chrome type whatever they want and get the results. It is not difficult to imagine a world where the non-tech users do not think of google as search engine but as internet in itself.
What chrome did by training users to enter their searches in the address bar (via the default tab’s fake google search box which moves the cursor to the URL field) was stupid, expensive, and probably undermines Google’s ability to be a destination web site in the long term.
At this point, the overwhelming number of devices are not Google’s. There is no reason to think that in the future they will be. After this anti trust stuff their influence over android may be even less than it is now.
Sadly then Android will probably falter. As much as things are a shitshow, the unified app ecosystem is a big deal to allow competition for smartphones themselves which allows users to switch without getting burnt on app costs. Otherwise corporations are all about vendor lockin and fucking over the consumer for short term gain because greed is king these days.
Someone should fund a "cash back for not using google" browser extension.
They've introduced mouse support (in 2019 no less), but even then it's disabled by default and buried in the Accessibility settings menu.
While I'm not a fan of obscuring what a URL is actually doing, this already is happening with headers.
But this is news because it's Google.
Apple does this and it's a "feature".
Marketing is a dangerous tool.
Edit: come to think of it, a keyword in Japanese is easier to remember/type than an url in latin characters. Sure, now there's IDN in domains and TLDs, but that wasn't a thing until relatively recently, and that's still harder to remember/type than keywords.
i.e. instead of a poster telling you to go to "https://news.ycombinator.com" it might say
Search: Hacker News
I get the discussion about Google changing the web to something that pleases their pockets over everything else, but I am not so sure whether that's the actual motivation in this case. Non-technical users can't do a lot with the rest of the URL anyway and even I as a technical user didn't mind Safari hiding the path and scheme up to now.
Granted, they revoked his cert after he published, but it goes to show how easy it would be to fake an EV cert and have safari users have no idea.
I'm just blown away that Apple hasn't reverted this. Imo it's a huge vuln.
I know it's fashionable to hate Google right now, but this reaction seems a little over the top.
Who uses Safari? People depend on Chrome on all sorts of platforms. Screwing with the URL field affects millions of people.
On a more generally level, I think, it's probably more about amplification vs augmentation, the kind of human-computer symbiosis, what this dialog really is. (Actually, I do prefer Licklider over Engelbart.) Take for example a middle-aged worker in India, who has now one of those new, cheap, not-that-smart phones on a $2/month mobile plan. S/he connects to streaming services via voice search and communicates by the press of a single button. For the first time in her/his life, s/he's able to reach out on her/his own. This is certainly empowering. There's much to be said in favor of such interfaces on devices like this.
However, Licklider's vision of a human-computer symbiosis was of a completely different nature, of partners in cooperation on equal levels. This was not about amplification in this sense, it was about mutual comprehension and directing work flows, with the later heavily depending on the former. This is the desktop environment. Here, simple amplification models are ultimately doing more harm as they may be convenient.
Now, where are the growing markets, what should a company care about? However, this may be a question and an answer too simple. When will our Indian worker gain access to a laptop? The answer may be quite well, "never". Is this still the same market, the same product, the same network?
Maybe in the future we’ll have 2 different apps with a UI optimized for each usage, ie Chrome for Apps and Chrome for web, even if the rendering is the same.
I think the point is that Google doesn't want users to be able to parse this much information. Keep the people dumb, if you want to call it that way. Or uninformed, uneducated, whatever.
"Enter whatever you want to know or see in this field and we will do some magic so you get what you want".
That's where they want to go, no doubt about it as Google probably profits the most from technically-uneducated users of its services.
What I am trying to point at is the vast number of users born after 1990 that have a decent basic understanding of these technologies. And within that generation, the portion that has a similar deep understanding to 1990s users is a population which by absolute size is several orders of magnitude larger what it was in the 1990s. And it is going to keep increasing.
> the proportion of technically litterate users will go up over time not down.
I take the proportion to mean "out of all internet/computer users". That has gone down. And that's the proportion that I think matters as it's what dictates the direction internet/computer technologies go. The proportion is going down, precisely because more people are using these technologies and the majority are not willing to learn as much.
arguably the web is the legacy thing for places that dont have apps, and native apps are mostly what they are familiar with.
See also the classical 2013 rant on the topic: http://www.coding2learn.org/blog/2013/07/29/kids-cant-use-co....
So long as sites that aren't using SSL are highlighted, and its not possible to spoof the browser into displaying a domain you're not looking at, I honestly don't see what benefit the typical user gets from seeing https://www.google.com vs google.com.
You may be amused, but in Europe the technical details of a car engine, transmission, breaks, etc, and how to perform a quick repair have been part of the drivers test (and was still, when I made mine). It was a three parts test, involving a technical part, a legal part, regarding rules and laws regulating traffic, and, finally, a practical test. (Similarly, understanding how analog radio works was part of high school curriculum.) This was based on the conviction that dealing with a technology also afforded a basic understanding of it, not the least for legal/liability reasons.
Analogously, just making that red "No SSL" alert "go away" may be not enough. It may be preferable, if users were to understand what this is and why it is important, what the possibles consequences are, etc, if they would be actively looking for this, if they would and could confirm the mode of their interaction. Not the least for legal/liability reasons. (Teach them first to never engage in any critical interaction unless there's a verified, secure connection as indicated by such and such icon or signal. Facilitate them in asserting this. Then put on an additional warning light, but don't replace the former by the latter. There's no "easy mode", no "My First Sony" – which was, by today's standards overly complex, anyway –, when it comes to your livelihood.)
A critical mass of people able to make informed technical decisions — which is what both business & democratic self-government require.
> We don't expect people to understand the details of how their car engine works, or how digital radio signals are encoded and decoded, why should we make it necessary that they do so for the internet?
We don't expect them to know the deep details of those technologies, but we do expect them to know that flammable gasoline powers an engine; we do expect them to know that radio signals can be received by anyone with a receiver (and a key, if encrypted).
This has always driven me bonkers about the ProofPoint URL-obfuscation 'security'. My work started enforcing this recently, and it drives me crazy:
1. rather than training you to think more carefully about links in e-mails, it trains you to click blindly, because the software says it's safe;
2. it obscures the target of the URL, so that a URL that even a novice would recognise as fishy becomes a garbled string like any other—here's an example (but safe) mangled URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__escholarship.org_content_qt5dj9b74w_qt5dj9b74w.pdf&d=DwIC-g&c=7Q-FWLBTAxn3T_E3HWrzGYJrC4RvUoWDrzTlitGRH_A&r=fDFfg5N-sxMSxbW3hS6WsQ&m=giTLUqirmM6FZGAOLKIp-AHow2YDDWYuGHGz6jjxykY&s=FhP_G8aKAp6QmXR9rR0Pl8L5Z5_XlDPql2uQqmKhDxM&e=
3. it filters outgoing links, meaning it assumes that the university employees, not just outside spammers, are hostile (but maybe this is a reasonable assumption?).Phishing is definitely possible inside your email org, anything from a malicious browser extension to desktop malware might be geared to send bad links to all users (or a subset) within the logged-in Gmail/Outlook directories.
But ya, that sounds like some pretty bad anti-phishing software. Sounds like vendor lock-in more than anything, especially if it's replacing the email links on the mail server itself.
What are the chances it just runs the domain through Google safe browsing? :P
That it drives traffic to their search engine and increases their revenue. A lot of people always use a search engine to navigate to sites anyway, even if it's a site they've been to many times before and even if the URI is as simple as https://somecompany.com.
Personally, I always want to see the full URI.
(There was a learning process. In the early days, there was reoccurring theme with clients and new websites, which were also their first intense exposure to the web, where first as much as possible pages had to open in a new window -- "I don't want my page to go away" -- followed by the moment, the client learned the back button and asked, why it wasn't working with those links.)
Regarding big names hoisted to TLDs: They are free to buy one, if they care. (For those big names, it's a small investment.) Otherwise, who is to decide, who is big enough and who just fails the test? Is this discriminatory, may it even hurt a viable interest? Is this still net-neutral? And, ultimately, I'm not sure, if single-word host names weren't rather apt to add to the confusion. (Autocompletion works just fine for this, anyway.)
You could show all the nitty gritty details of the URL and more tech-savvy users could learn over time, but non-tech users would have a simple alias that always takes them to a trusted site.
Something like a cross between AOL terms and trust-on-first-use system.
They will: http://apple
I guess they are meant to color up speech / break monotony, but it gets irritating when metaphors are overused and nobody just says "battery", so in the end, just using the boring regular word feels more refreshing. Similarly for articles that keep overuse words like "whopping" instead of usual formal words (to appear more friendly, I guess), or infallibly say "invest" for everything rather than just "buy".
Empirically (I've done the comparison), desktop browser UIs have been growing in vertical screen occupation since Netscape Navigator 2 quite continuously, including the most recent versions, while reducing the amount of information and control provided by the interface. (That is, tabs introduced a new demand of some legitimacy. – However, another vertically stacked horizontal bar isn't the single imaginable solution to the problem. Previously, there had been sidebars with extracted link lists, we can do it for bookmarks and reading lists… We're even better at scanning vertical lists. There's quite some dogma involved. Arguably, a horizontal tab list shouldn't exceed 5 items.)
. / - _ (dot, slash, dash, underscore) all mean very specific things, and different things in different context (period specifically), and if you dont have their meanings memorized and what order to read things in, (right to left from the tld, pausing at each period, then left to right from the first slash, pausing at each slash) then URLs look like illegible nonsense.
Users are able to parse post addresses and apply specific meaning and rules to the various parts. (Compared to URIs post adddresses are exceptionally messy und full of edge cases and exceptions.) Before mobile, users have been able to identify phone numbers by country, region, city and district. Where is the crucial difference? Isn't just because they are told it does 't matter and they won't understand anyway!
Here's an experiment: walk down any street in the US. Actually, scratch that, because there's a good chance that you live in SF or Seattle and your streets are filled with computer programmers.
Call a random number in a random area code. Ask them what the difference between HTTP and HTTPS is.
The users already don't know.
Do you have a plan to educate even 90% of users? That would be a dream come true, but that still leaves a gaping hole of 10%. I would guess 90% of programmers could explain the difference between HTTP and HTTPS (the other 10% being the dreadfully incompetent).
Right now I'm guessing we're at 5% or so and no amount of wanting that to not be true will change that.
No, but I could easily create one if I was paid to put my mind to it. Just as a hobby, I already educate peers about how a lot of the internet and web and technology work anyway.
I don't really have a desire to add to my life the stress of dealing with the terrible decisions, past and present, of "modern" UI driven almost completely by shady marketing tactics encouraged and often forced by business. I certainly don't have the desire to do so without compensation to offset that stress.
Users already don't know anything about addresses. Even security professionals botch the "look at some visual indicator of connection security" all the time (see SSLStrip). As a security feature the URL bar is almost entirely useless for the huge majority of users.
URL bars also don't really tell you where your content is coming from. Iframes don't have URL bars. All that javascript downloaded from somewhere when the page loaded doesn't have a URL bar. The web isn't made of uniquely identifiable documents anymore.
- current situation: http is normal, https with bad certificate is bad, https with good certificate is good
- future situation: http is bad, https with bad certificate is bad/acceptable, https with good certificate is normal
i.e instead of telling people to check for the padlock icon and the green name that should be everywhere, tell people to check for the red warning that indicates a problem. I think it's lifting the expectation to something more secure by default.
Understanding the basics of a secure connection and what possible consequences are is part of liability and being of sound mind. Teach them first, what it is and why it matters, to never engage in a critical communication without a verified secure connection as indicated by this and that signal. Facilitate users in asserting the mode of their electronic interactions. Then put an additional warning line on. But never replace the former by the latter. There is no "easy mode" when it comes to your livelihood.
And, if users are able to grasp these basics (and sure they are – heck, not that long ago drivers had to understand and to be able to describe the workings of a car engine and transmission in order to pass a drivers test), understanding why a basic connection has become unbearable, shouldn't be much of a problem.
Edit: E.g., have a dedicated status bar, displaying to whom the certificate was issued by what CA and what the security level (level of identification) is, possibly color coded. (Your bank must have a red certificate issued on its name, otherwise, run.) Prefetch certificates for links and display them side by side with the link target in said status bar, etc,...
What we are working towards is the thing users had been assuming was true all along, that when they visit google.com that's google.com, else why would it say so? They are astonished to learn that Tim's toy hypermedia system didn't do that and we're only fixing it now in the 21st century.
Whereas you're talking about the sort of imaginary world where everybody begins a novel by perusing the copyright notice just inside the cover, to discern whether they are in fact permitted to read further.
Users aren't going to try to figure out what your "dedicated status bar" means, they'll be annoyed that they can't switch it off since it wastes space with things they don't care about and then they'll just stop seeing it, the way they don't really see those channel ID logos (DOGs) on a modern TV channel.
Your "prefetching" idea is not only terrible for privacy it also doesn't actually do what you probably expect it does, because web pages are too complicated and have been for decades, for this to be effective. In practice because there are so many HTTP transactions _only_ the checks the software can do automatically are worth anything, any time you start talking about how a user should be examining certificate details you're talking about an idea that can't actually work.
Not so much. I'm referring to a world where different weight and importance apply to different matter. There are things that are important and things that are really important (like your bank connection) and it is really the latter which matter.
> Users (…) e annoyed that they can't switch it off since it wastes space with things they don't care about (…)
With much the same anticipation we may expect users to hate the Start menu in Windows, since it occupies some space and they neither understand nor use it. Now guess, what happened. (Turns out, users are interested in knowing how to control their devices.)
Regarding prefetching, this was just escalating the idea. (In actuality, I'm not a friend of prefetching for any means. Don't waste bandwidth on a general level, just because you can't serve your assets in a time span that had been barely bearable with modems.)
But more importantly, user control is not at all the same thing as throwing a bunch of useless data at the user. Is it the site? Yes or no.
The start menu doesn't occupy space during normal use. (That's why I though you meant the start button.)
You were talking about getting rid of something that occupied space, but they didn't get rid of the start menu. In fact they made it bigger when activated.
And the changes they made had nothing to do with whether the user can control their device.
So I don't think any argument based on the windows 8 start menu is suitable for saying that an extra bar is a good idea.
Oh well, thanks for clarifying.
We gave all the information to users already, they didn't know what to do with it.
> Just establishing "any TLS" as the new normal doesn't especially help in a world, where you get a certificate for free with a new domain.
Establishing non-TLS as insecure is the end goal.
> possibly color coded. (Your bank must have a red certificate issued on its name, otherwise, run.) Prefetch certificates for links and display them side by side with the link target in said status bar, etc,...
Colors mean different things in cultures and have to be manually learned. Due to frequently broken TLS configurations and similar users will ignore the warnings as well. I really really don't think warnings help, either a fail-shut behavior is enforced (with annoying bypasses) or it might as well not exist.
As for colors or other signaling, yes, these are mostly cultural and are to be learned. (E.g., red isn't naturally "bad" or a warning, it may be rather "important") However, this is such a crucial technology, isn't it a viable option having a set of rules, which easily fits on a single page of legal paper in big print, and teach this to everyone? (How do people manage to cross the street, if they can't be expected to incorporate a simple set of rules? We, on the other hand, rather teach them to be careless and suspend judgement. Notably, I'm speaking of the desktop environment, mobile has a completely different set of requirements and widely proliferated alternatives, like dedicated apps for crucial tasks.)
And, regarding don't care about the identity as long as it is TLS, I'm not so sure.
That all you need is keywords and a good search engine. Platform companies hate URLs because they enable interoperability.
they will replace the domain with google.com, and it already started
It's how Google has approached most things lately. "Oh yeah, we're removing this API for user security. No, it has nothing to do with the same move killing ad-blockers in one blow, why do you ask?! And we're very offended you even think we'd do it for that reason! We'd never..."
You've accurately assessed the current state of affairs. The current average user knows essentially nothing about addresses. They might have a vague sense that domain matters, but that's about it.
Displaying more information that they do not understand does not enhance the security of the average user. Displaying more information useful to the exceptional user (i.e., us) has to be weighted the degree to which it leads average users to a learned helplessness reaction.
(My go to example is the level of understanding required to operate a kitchen and to prepare a meal, which is surprisingly high, but not worth even mentioning. Users do understand the difference of a spoon and a knife, as long as they understand the relevance of this to them. They are even able to operate an oven and to deviate from complex recipes in creative ways, while finding and managing all kind of equipment and managing time critical work flows. Is a similar operational understanding of what may be the most important technology of our time really asking too much?)
In my opinion, what's changed is that someone won the political battle between "URIs are so simple and well-defined! Everyone understands them." and "Users don't understand URIs" camps.
With that said, it's perhaps worth considering that most users might regard computers as essentially magical and fundamentally incomprehensible things. In such a context, could it be possible that it might actually be too much to ask for your average user to have a good operational understanding of something that seems to them to be fundamentally incomprehensible? A great many people have already learned helplessness in the face of technology. Could it be that decades of exposing people to the elegant simplicity of URLs has not created widespread operational comprehension?
(What's the alternative? Just stumble into the pits the dogma didn't provide for? If I'm hurt, it's the will of the Web? – "Nexus vult", as the web-fathers put it?)
Seriously speaking: If browsers are simplifying the URI scheme for the alleged benefit of users, how do we expect these users to know anything about addresses? Isn't this rather undermining security than enhancing it? Highlighting significant parts may be preferable to hiding those deemed insignificant. Moreover, regarding https, I personally prefer positive affirmation over lack of warning.
For me, this worked best for desktop browsers with the padlock icon (and, before this, the key icon) shown together with a display of link targets in a status bar as a separate, reserved area. (While allowing pages to overwrite `window.status` was certainly not a good idea.) A consistent display of the authority issuing the certificate of the current page in a status bar like this may be also nice. I'm not convinced that less but more opaque information is the way to go.
Dedicating 20 vertical pixels of virtual real estate to security relevant information may be worth it. It may be also easier to parse than an overloaded omnnibox/location/search/navigation/security/menu bar. Cutting down any information which is displayed too densely right from the beginning won't help the issue. How many bits of information are there in this "everything bar"? Yes, there's still a bit of grouping left, mainly by spacing, but color is mostly gone as a signal in order to make the information density bearable. So users will be applying quite an amount of selectivity when parsing this display, by this inevitably missing relevant information. (That this densely combined display is rather homogenous both for esthetics and acceptance just aggravates the need for selective parsing, which is likely to become a habit.) "We'll pre-filter this for you" isn't addressing the problem, it's rather "living with the outcome".
Edit: A legitimate reason for redacting the host name are extensive names, crafted to exceed the space available in the location display in order to deceive users regarding the identity of the host. Here, abbreviating by an ellipsis (compare text-overflow: ellipsis) in order to fully display the domain may be a way to go.
--
P.S.: What's the general lesson taught by such redactions by the browser vendor? That it is OK to ignore these things, as they are truly irrelevant? (Must be without significance, since Google told me so?)