10 ms·

I’m against chrome taking always the URL. While they make points about security and dumb users, I don’t believe they have altruistic motives. An issue with AMP

I’m against chrome taking always the URL. While they make points about security and dumb users, I don’t believe they have altruistic motives. An issue with AMP is the terrible URLs- because they are hosted by google. Once Chrome no longer has URLs, then Chrome gets to decide what name to show you in the address bar - potentially a name that has very little to do with the actual location of the document. Maybe I’m being a bit extreme or pessimistic, but do not believe this is a good change for the web, and I don’t think Google can be trusted to be the stewards of the internet.

jeffjose 8y ago
The AMP team is working on the exact opposite, which is adopting Web Packaging [1] that fixes the URL issue you are describing. https://amphtml.wordpress.com/2018/11/13/developer-preview-of-better-amp-urls-in-google-search/ https://amphtml.wordpress.com/2018/11/13/developer-preview-o... [1] - https://github.com/WICG/webpackage https://github.com/WICG/webpackage
- clhodapp 8y ago
  From the parent: > ... then Chrome gets to decide what name to show you in the address bar - potentially a name that has very little to do with the actual location of the document That doesn't seem to be the opposite of what the parent post is describing, it seems to be an implementation of it.
  - ehsankia 8y ago
    How so? The web package comes from the real source you see. The only reason Google needed to serve the content from its own domain is because of security and limitation of content delivery. But with this, they can serve you a "package" that's identical to what you get from the source.
    - clhodapp 8y ago
      Common techniques like relative paths will allow the proxy-cache to see much deeper into a site than the end user is aware. The url bar might say that you're on some site you trust but your traffic may all still be openly readable by Google (or some other proxy). Of course, Google is always going to know about links that users click in its search result list and a huge number of sites blindly run Google (or other third party) scripts anyway but this opens up a new vector for Google to see into your traffic.
- sodosopa 8y ago
  AMP has it's own issues: https://www.polemicdigital.com/google-amp-go-to-hell/ https://www.polemicdigital.com/google-amp-go-to-hell/
  - jeffjose 8y ago
    Didnt read past the first section since that appears outdated already. AMP Project is run similar to nodejs by adopting an open-governance model. This was first announced here - https://amphtml.wordpress.com/2018/09/18/governance/ https://amphtml.wordpress.com/2018/09/18/governance/ and the went live later that year. https://amphtml.wordpress.com/2018/11/30/amp-projects-new-governance-model-now-in-effect/ https://amphtml.wordpress.com/2018/11/30/amp-projects-new-go... In the link above you can see non-Google decision makers that drive strategy and vision of the project.
    - geofft 8y ago
      > AMP Project is run similar to nodejs by adopting an open-governance model. OK, but the only thing I want out of AMP is for it to not exist. Is there any chance that I can get involved in AMP's open governance with a "stop existing" goal? It is already quite surprising that AMP has gone in the direction of "We'll accept signed webpackages and publish those so we aren't acting as the origin". But my goal is that even this should not need to exist: websites that genuinely load fast on their own, comparable to downloading the webpackage, should be ranked as high as AMP websites. And it's preferable for websites to do that. So there should be no boost for AMP websites, just a boost for fast pages, and if AMP does anything it should just provide guidelines for how to build fast pages. Examples of fast pages include HN and most things published before 1998. At the end of the day AMP exists because it's privileged by Google Search, and AMP is privileged by Google Search because Malte Ubl has whatever amount of influence he does within Google and has convinced them that AMP is a good idea (or other people have decided it's a good idea and have put Malte Ubl in charge of making sure it happens, or whatever). No matter how many non-Google people you put on the steering committee you won't change that. You don't have the internal access to change Google's mind about it. This is like saying that it's okay that I should be happy living in a city that always votes $party because I can get involved in the party. If my personal political views are $opposing_party, that statement is technically true but completely useless.
- dane-pgp 8y ago
  As a nice side effect of Google pushing Web Packaging, we get one step closer to having web apps that are signed with an offline key and served with a clear version number. This would mean you could have at least a TOFU security model, where a web app that you trust can't be replaced (without you knowing) by an insecure version you haven't seen before. Add some binary transparency [1] logging on top of that, and it might be possible to make browser-based JavaScript crypto almost as secure as the equivalent desktop app. [1] https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
  - zozbot123 8y ago
    You could do this quite simply by requesting trusted apps to be identified by Named Information (ni:// or nih://) URIs (see https://tools.ietf.org/html/rfc6920 https://tools.ietf.org/html/rfc6920 ) using a digest algorithm of sufficient strength. But the ability to "seamlessly" replace web apps is something that many websites would insist on, I think. Of course ni:// and nih:// can be applied to documents as well. They work on the IPFS model, where you enter some digest of the desired content as your URI (it's actually a URN, not a URL!) and then it's the user agent's job to fetch it from wherever, perhaps in a decentralized way.
ken 8y ago
They don't say anything about "dumb users", and I wish the conversation around this didn't even use that phrase. Hardhats aren't just for clumsy people, seatbelts aren't just for bad drivers, and memory protection isn't just for careless programmers. There's no shame in engineering a situation to maximize safety for the people who will use it. There's a whole lot of smart people who like static typing for the safety benefits it brings to their programming. Web browsers are the front lines: where one click on a stringly-typed reference can cause unknown third-party code to run on your computer. You are protected only by your human ability to spot the visual difference between two strings, one of which is constructed by someone trying their hardest to trick you. If you advocate for type safety within software, you should also advocate for a better system than URIs.
- SllX 8y ago
  Or advocate for disabling the ability for your web browser to run 3rd party code just by clicking a link. Google is not trustworthy because between Chrome and Search they have too much of a stake in the eventual outcome of anything that could replace URLs. Any system that eventually does replace URIs should be able to tell me at a glance: is it http, ftp or a local file? Is there a TLS cert? What is the domain of the server I am accessing? Approximately where in the site directory am I? I simply don’t trust browsers or sites which try to obscure what is actually useful information because some UX guru told them it was unnecessary. If anything, I want URLs with even more information. Which version of “http” is in use would be a nice start at this point.
  - dagenix 8y ago
    Different resources can be loaded with different versions of http, so, I don't know how you can say which version of http is in use. But, even if you could, I struggle to see what useful decision that would enable anyone to make outside of niche cases.
  - mrhappyunhappy 8y ago
    Feels like every point you mention can be designed in a user friendly way. I’m a UX designer and have some ideas for this.
ledriveby 8y ago
What does AMP have to do with anything? The fine article is about flagging potential URL homograph attacks. It's a reasonable thing for a browser to do, since those attacks are incredibly hard to spot. I don't know why Wired clickbaited the headline like this.
- geofft 8y ago
  WIRED published a (relatively positive!) article last fall entitled "Google Wants to Kill the URL": https://www.wired.com/story/google-wants-to-kill-the-url/ https://www.wired.com/story/google-wants-to-kill-the-url/ I'm interpreting the title as a reference to that. And the relevance is that AMP shows its own fake-URL bar, and Google could choose to "kill the URL" by trusting https://www.google.com/amp/ https://www.google.com/amp/ with not-URL overrides. (But, they could do that presently and trust themselves with URL overrides.)
- ehsankia 8y ago
  They've been running wild with "KILLING THE URL" for some time now. Put it right next to "Google murdering ad blockers" and "Google decapitating hangouts classic". Is there any unbiased article out there going over the proposals?
- gsich 8y ago
  The reasonable thing would be to display the real domain, and the punycode one, in the same bar. Then you can at least detect some homograph attacks. Or possible use a monospace font for the URL bar. So that 0 with a dash and O are actually visible at first glance.
  - namibj 8y ago
    Please distinguish between fonts-for-data and monospace-fonts. E.g. http://input.fontbureau.com/info/#writing http://input.fontbureau.com/info/#writing has a sample of a not-actually-monospace font with IMHO awesome legibility in the mentioned "matter-of-fact" category of typefaces. 0 with a dash and O without are not at all bound to monospaced fonts. FYI, I left console editors due to their inability to handle my preferred Input Sans Narrow Light 14pt (16pt on my 110 dpi screen), just so you can understand the pain of monospace.
hkai 8y ago
Eventually they just want to whitelist the "good" sites and make it harder to access small independent sites, further centralizing the web and getting more tools to censor content. Imagine that they would make it hard to access a small competitor to Gmail or restrict a website that has news they don't like.
- mrhappyunhappy 8y ago
  Introducing “trusted content providers”. Default opt in, opt out only if you acknowledge you’ll be exposed to phishing (red scary screen).
- sh87 8y ago
  Outright restricting would seem unlikely given the anti-trust scene they are having to put up against. But, I can totally imagine them introducing an extra step under the garb of "protecting" users like a dialog, a popup coupled with a red banner on the URL is enough to discourage significant number of people from visiting the target website.
  - api 8y ago
    You don't have to outright restrict. Just adding a little bit of friction will keep 90% of users away and will completely destroy adoption for any independent business. I really think it's time to drop Chrome and to campaign for others to drop Chrome. I'm sticking with either Safari (on my Mac) or Firefox.
- tyingq 8y ago
  Anyone remember "AOL keywords"? You would pay AOL to make your content discoverable. And some keywords were reserved only for AOL use.
geofft 8y ago
I think that Google is a big organization and the fact that the search team thinks that AMP is a good idea is not necessarily evidence that the Chrome team does - or even if they do, that they'd want to let AMP be considered as some origin other than google.com. For instance: - Google's phishing quiz https://phishingquiz.withgoogle.com https://phishingquiz.withgoogle.com has a question where the right answer is that a URL that starts with google.com is actually an AMP page for a URL shortener that sends you to a Google login phishing page. - The Chrome team's document about displaying URLs https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md https://chromium.googlesource.com/chromium/src/+/master/docs... is at best neutral on the case where "a domain owner is willing to supply content from a third-party within their own address space," calling out AMP as a specific example of this, and pointing out (in the section "A Caveat on Security Sensitive Surfaces") that anything in the renderable area of the webpage is below the "line of death" and untrustworthy. - Google search once penalized Google Chrome for breaking SEO rules. https://searchengineland.com/google-chrome-page-will-have-pagerank-reduced-due-to-sponsored-posts-106551 https://searchengineland.com/google-chrome-page-will-have-pa... - Also I think I've seen Chrome developers tweet things that are less-than-happy about AMP, but I can't find them any more. (That said, I do agree that we shouldn't be trusting Google to be stewards of the internet - and that is a huge part of the value Firefox provides, honestly - just that I think in this regard they're unlikely to abuse the trust.)
- deleted 8y ago
  [deleted]
- bad_user 8y ago
  In a conflict of ideas between the Search team and the Chrome team, I'm pretty sure it's irrelevant what the Chrome team wants.
  - kkarakk 8y ago
    yup we're seeing product teams getting shit on all over every product space if they're not core. Amazon did the same thing to their UI/Search team with their sponsored results that turned web/app search into a massive clusterfuck of unrelated "Promoted" items
wmf 8y ago
a name that has very little to do with the actual location of the document I'm sorry to tell you that you've already been tricked — not once but thousands of times. You think you're browsing wired.com? Wake up Neo, you're really on Fastly. Every major site uses CDNs. Once AMP uses Web Packaging to show the URL of the original site instead of google.com, it will be... no worse than any other CDN.
- 3xblah 8y ago
  It is true. The only way you will see where you are is to observe DNS. What the browser authors like Google are doing is further hiding DNS from the user. Many years ago Firefox was already hiding and highlighting parts of urls in the address bars to "protect" users. It will only get worse. I often navigate by first doing automated lookup using only non-recursive queries, then storing the address permanently until it changes (rarely does), and finally after I have the needed address, navigating to the url. I see every DNS answer, and thus I can see all CDN use. Fastly has really emerged over recent years and is very popular among sites appearing on HN. CDNs are popular but not all sites on HN or elsewhere use them. There are still many, many sites that do not use CDN's nor share IP addresses with other sites.
- move-on-by 8y ago
  > Every major site uses CDNs. Once AMP uses Web Packaging to show the URL of the original site instead of google.com I disagree. Although wired.com might be served by fastly, fastly is not in the URL scheme and is treated as a 3rd party. There are a lot of browser restrictions on 3rd parties. Having fastly become a first party would definitely be different in terms of browser restrictions
samstave 8y ago
I am of the opinion that the reality behind AMP is much more insidious than security and dumb user mitigation. I believe that AMP is the mortar that builds the solid connection between users and ALL their activities and views and logins and accounts and handles across their browsing behavior. Which links you clicked, not matter what site you are on or who you are logged in as. It seems to completely dissolve any anonymity, period.
- tareqak 8y ago
  Actually, you totally have a point. Consider the case of China and its Great Firewall. If you can control the URL and separate it from the content, then you can control what people see on yet another level e.g. we aren't blocking what Wikipedia says about the Tienanmen Square massacre this is what that URL actually says. tl;dr gaslighting / rewriting history on a mass scale if you can't use the URL to get to particular server.
  - samstave 8y ago
    Now imagine taking all that data and building the "social credit score" on the sentiment analysis for the consumption habits of all users' actions online...
    - romeisendcoming 8y ago
      And adding mandatory, recorded, voice commands for a subset of functionality.
- taneq 8y ago
  As always with Google, there are two outcomes. An improvement to some engineering or social issue, and an increase in the amount of data flowing into Google from the rest of the world. Of course the latter is pure coincidence, but it's always there.
  - baud147258 8y ago
    > Of course the latter is pure coincidence You should have added a /s. It's not a coincidence, it's part of how Google say they are improving their services
throwaway2048 8y ago
Reminds me of chromium dev discussions about severely limiting ad-blockers, for your safety of course, and only for the users. Not for Google's massive benefit.
princekolt 8y ago
I think the only hope would be pushing more people to drop Chrome and start using different browsers. This would reduce the leverage Google has to bully other browsers to follow them. This might sound impossible today, but 10 years ago we'd be saying the same thing about IE.
- mancerayder 8y ago
  Firefox has become increasingly usable. I've transitioned to it and DuckDuckGo, using Chrome only for the Google business apps. On mobile on Android it gets mad and freez-y if you open too many tabs, and on desktop it gets angry and pause-y if you're behind a proxy, but otherwise it's pretty decent.
cm2187 8y ago
It's the same argument about file hierarchies. Apple doesn't think users should even be aware that there is a file hierarchy (iOS). I don't think users are confused at all by files and folders. But somehow Apples seems to think they are. What I do not understand is that the percentage of people who didn't grow up with a computer is only going to go down, not up. These evolutions I think go in the wrong direction.
- webmobdev 8y ago
  > I don't think users are confused at all by files and folders. But somehow Apples seems to think they are. Agreed. And am glad that they were forced to reconsider and have introduced a FILES (https://www.imore.com/files-app https://www.imore.com/files-app) App on ios.
  - amelius 8y ago
    It seems still not possible to attach a USB drive, though :(
eeeeeeeeeeeee 8y ago
Killing or obfuscating the URL is really only good for Google. They don’t want people going directly to any website, they want you arriving at it through a Google property so they can pitch ads to you or at least track you through that funnel.
tylerl 8y ago
It's dumb that I actually have to say this.... But chrome isn't actually killing URLs or even taking steps toward killing URLs, despite the clickbait story title. Instead they're taking steps toward better identifying fraud. But nobody would read the story if that's all it said.

jeffjose 8y ago

The AMP team is working on the exact opposite, which is adopting Web Packaging [1] that fixes the URL issue you are describing. https://amphtml.wordpress.com/2018/11/13/developer-preview-of-better-amp-urls-in-google-search/ https://amphtml.wordpress.com/2018/11/13/developer-preview-o... [1] - https://github.com/WICG/webpackage https://github.com/WICG/webpackage

clhodapp 8y ago
From the parent: > ... then Chrome gets to decide what name to show you in the address bar - potentially a name that has very little to do with the actual location of the document That doesn't seem to be the opposite of what the parent post is describing, it seems to be an implementation of it.
- ehsankia 8y ago
  How so? The web package comes from the real source you see. The only reason Google needed to serve the content from its own domain is because of security and limitation of content delivery. But with this, they can serve you a "package" that's identical to what you get from the source.
  - clhodapp 8y ago
    Common techniques like relative paths will allow the proxy-cache to see much deeper into a site than the end user is aware. The url bar might say that you're on some site you trust but your traffic may all still be openly readable by Google (or some other proxy). Of course, Google is always going to know about links that users click in its search result list and a huge number of sites blindly run Google (or other third party) scripts anyway but this opens up a new vector for Google to see into your traffic.
sodosopa 8y ago
AMP has it's own issues: https://www.polemicdigital.com/google-amp-go-to-hell/ https://www.polemicdigital.com/google-amp-go-to-hell/
- jeffjose 8y ago
  Didnt read past the first section since that appears outdated already. AMP Project is run similar to nodejs by adopting an open-governance model. This was first announced here - https://amphtml.wordpress.com/2018/09/18/governance/ https://amphtml.wordpress.com/2018/09/18/governance/ and the went live later that year. https://amphtml.wordpress.com/2018/11/30/amp-projects-new-governance-model-now-in-effect/ https://amphtml.wordpress.com/2018/11/30/amp-projects-new-go... In the link above you can see non-Google decision makers that drive strategy and vision of the project.
  - geofft 8y ago
    > AMP Project is run similar to nodejs by adopting an open-governance model. OK, but the only thing I want out of AMP is for it to not exist. Is there any chance that I can get involved in AMP's open governance with a "stop existing" goal? It is already quite surprising that AMP has gone in the direction of "We'll accept signed webpackages and publish those so we aren't acting as the origin". But my goal is that even this should not need to exist: websites that genuinely load fast on their own, comparable to downloading the webpackage, should be ranked as high as AMP websites. And it's preferable for websites to do that. So there should be no boost for AMP websites, just a boost for fast pages, and if AMP does anything it should just provide guidelines for how to build fast pages. Examples of fast pages include HN and most things published before 1998. At the end of the day AMP exists because it's privileged by Google Search, and AMP is privileged by Google Search because Malte Ubl has whatever amount of influence he does within Google and has convinced them that AMP is a good idea (or other people have decided it's a good idea and have put Malte Ubl in charge of making sure it happens, or whatever). No matter how many non-Google people you put on the steering committee you won't change that. You don't have the internal access to change Google's mind about it. This is like saying that it's okay that I should be happy living in a city that always votes $party because I can get involved in the party. If my personal political views are $opposing_party, that statement is technically true but completely useless.
dane-pgp 8y ago
As a nice side effect of Google pushing Web Packaging, we get one step closer to having web apps that are signed with an offline key and served with a clear version number. This would mean you could have at least a TOFU security model, where a web app that you trust can't be replaced (without you knowing) by an insecure version you haven't seen before. Add some binary transparency [1] logging on top of that, and it might be possible to make browser-based JavaScript crypto almost as secure as the equivalent desktop app. [1] https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
- zozbot123 8y ago
  You could do this quite simply by requesting trusted apps to be identified by Named Information (ni:// or nih://) URIs (see https://tools.ietf.org/html/rfc6920 https://tools.ietf.org/html/rfc6920 ) using a digest algorithm of sufficient strength. But the ability to "seamlessly" replace web apps is something that many websites would insist on, I think. Of course ni:// and nih:// can be applied to documents as well. They work on the IPFS model, where you enter some digest of the desired content as your URI (it's actually a URN, not a URL!) and then it's the user agent's job to fetch it from wherever, perhaps in a decentralized way.

ken 8y ago

They don't say anything about "dumb users", and I wish the conversation around this didn't even use that phrase. Hardhats aren't just for clumsy people, seatbelts aren't just for bad drivers, and memory protection isn't just for careless programmers. There's no shame in engineering a situation to maximize safety for the people who will use it. There's a whole lot of smart people who like static typing for the safety benefits it brings to their programming. Web browsers are the front lines: where one click on a stringly-typed reference can cause unknown third-party code to run on your computer. You are protected only by your human ability to spot the visual difference between two strings, one of which is constructed by someone trying their hardest to trick you. If you advocate for type safety within software, you should also advocate for a better system than URIs.

SllX 8y ago
Or advocate for disabling the ability for your web browser to run 3rd party code just by clicking a link. Google is not trustworthy because between Chrome and Search they have too much of a stake in the eventual outcome of anything that could replace URLs. Any system that eventually does replace URIs should be able to tell me at a glance: is it http, ftp or a local file? Is there a TLS cert? What is the domain of the server I am accessing? Approximately where in the site directory am I? I simply don’t trust browsers or sites which try to obscure what is actually useful information because some UX guru told them it was unnecessary. If anything, I want URLs with even more information. Which version of “http” is in use would be a nice start at this point.
- dagenix 8y ago
  Different resources can be loaded with different versions of http, so, I don't know how you can say which version of http is in use. But, even if you could, I struggle to see what useful decision that would enable anyone to make outside of niche cases.
- mrhappyunhappy 8y ago
  Feels like every point you mention can be designed in a user friendly way. I’m a UX designer and have some ideas for this.

ledriveby 8y ago

What does AMP have to do with anything? The fine article is about flagging potential URL homograph attacks. It's a reasonable thing for a browser to do, since those attacks are incredibly hard to spot. I don't know why Wired clickbaited the headline like this.

geofft 8y ago
WIRED published a (relatively positive!) article last fall entitled "Google Wants to Kill the URL": https://www.wired.com/story/google-wants-to-kill-the-url/ https://www.wired.com/story/google-wants-to-kill-the-url/ I'm interpreting the title as a reference to that. And the relevance is that AMP shows its own fake-URL bar, and Google could choose to "kill the URL" by trusting https://www.google.com/amp/ https://www.google.com/amp/ with not-URL overrides. (But, they could do that presently and trust themselves with URL overrides.)
ehsankia 8y ago
They've been running wild with "KILLING THE URL" for some time now. Put it right next to "Google murdering ad blockers" and "Google decapitating hangouts classic". Is there any unbiased article out there going over the proposals?
gsich 8y ago
The reasonable thing would be to display the real domain, and the punycode one, in the same bar. Then you can at least detect some homograph attacks. Or possible use a monospace font for the URL bar. So that 0 with a dash and O are actually visible at first glance.
- namibj 8y ago
  Please distinguish between fonts-for-data and monospace-fonts. E.g. http://input.fontbureau.com/info/#writing http://input.fontbureau.com/info/#writing has a sample of a not-actually-monospace font with IMHO awesome legibility in the mentioned "matter-of-fact" category of typefaces. 0 with a dash and O without are not at all bound to monospaced fonts. FYI, I left console editors due to their inability to handle my preferred Input Sans Narrow Light 14pt (16pt on my 110 dpi screen), just so you can understand the pain of monospace.

hkai 8y ago

Eventually they just want to whitelist the "good" sites and make it harder to access small independent sites, further centralizing the web and getting more tools to censor content. Imagine that they would make it hard to access a small competitor to Gmail or restrict a website that has news they don't like.

mrhappyunhappy 8y ago
Introducing “trusted content providers”. Default opt in, opt out only if you acknowledge you’ll be exposed to phishing (red scary screen).
sh87 8y ago
Outright restricting would seem unlikely given the anti-trust scene they are having to put up against. But, I can totally imagine them introducing an extra step under the garb of "protecting" users like a dialog, a popup coupled with a red banner on the URL is enough to discourage significant number of people from visiting the target website.
- api 8y ago
  You don't have to outright restrict. Just adding a little bit of friction will keep 90% of users away and will completely destroy adoption for any independent business. I really think it's time to drop Chrome and to campaign for others to drop Chrome. I'm sticking with either Safari (on my Mac) or Firefox.
tyingq 8y ago
Anyone remember "AOL keywords"? You would pay AOL to make your content discoverable. And some keywords were reserved only for AOL use.

geofft 8y ago

I think that Google is a big organization and the fact that the search team thinks that AMP is a good idea is not necessarily evidence that the Chrome team does - or even if they do, that they'd want to let AMP be considered as some origin other than google.com. For instance: - Google's phishing quiz https://phishingquiz.withgoogle.com https://phishingquiz.withgoogle.com has a question where the right answer is that a URL that starts with google.com is actually an AMP page for a URL shortener that sends you to a Google login phishing page. - The Chrome team's document about displaying URLs https://chromium.googlesource.com/chromium/src/+/master/docs/security/url_display_guidelines/url_display_guidelines.md https://chromium.googlesource.com/chromium/src/+/master/docs... is at best neutral on the case where "a domain owner is willing to supply content from a third-party within their own address space," calling out AMP as a specific example of this, and pointing out (in the section "A Caveat on Security Sensitive Surfaces") that anything in the renderable area of the webpage is below the "line of death" and untrustworthy. - Google search once penalized Google Chrome for breaking SEO rules. https://searchengineland.com/google-chrome-page-will-have-pagerank-reduced-due-to-sponsored-posts-106551 https://searchengineland.com/google-chrome-page-will-have-pa... - Also I think I've seen Chrome developers tweet things that are less-than-happy about AMP, but I can't find them any more. (That said, I do agree that we shouldn't be trusting Google to be stewards of the internet - and that is a huge part of the value Firefox provides, honestly - just that I think in this regard they're unlikely to abuse the trust.)

deleted 8y ago
[deleted]
bad_user 8y ago
In a conflict of ideas between the Search team and the Chrome team, I'm pretty sure it's irrelevant what the Chrome team wants.
- kkarakk 8y ago
  yup we're seeing product teams getting shit on all over every product space if they're not core. Amazon did the same thing to their UI/Search team with their sponsored results that turned web/app search into a massive clusterfuck of unrelated "Promoted" items

wmf 8y ago

a name that has very little to do with the actual location of the document I'm sorry to tell you that you've already been tricked — not once but thousands of times. You think you're browsing wired.com? Wake up Neo, you're really on Fastly. Every major site uses CDNs. Once AMP uses Web Packaging to show the URL of the original site instead of google.com, it will be... no worse than any other CDN.

3xblah 8y ago
It is true. The only way you will see where you are is to observe DNS. What the browser authors like Google are doing is further hiding DNS from the user. Many years ago Firefox was already hiding and highlighting parts of urls in the address bars to "protect" users. It will only get worse. I often navigate by first doing automated lookup using only non-recursive queries, then storing the address permanently until it changes (rarely does), and finally after I have the needed address, navigating to the url. I see every DNS answer, and thus I can see all CDN use. Fastly has really emerged over recent years and is very popular among sites appearing on HN. CDNs are popular but not all sites on HN or elsewhere use them. There are still many, many sites that do not use CDN's nor share IP addresses with other sites.
move-on-by 8y ago
> Every major site uses CDNs. Once AMP uses Web Packaging to show the URL of the original site instead of google.com I disagree. Although wired.com might be served by fastly, fastly is not in the URL scheme and is treated as a 3rd party. There are a lot of browser restrictions on 3rd parties. Having fastly become a first party would definitely be different in terms of browser restrictions

samstave 8y ago

I am of the opinion that the reality behind AMP is much more insidious than security and dumb user mitigation. I believe that AMP is the mortar that builds the solid connection between users and ALL their activities and views and logins and accounts and handles across their browsing behavior. Which links you clicked, not matter what site you are on or who you are logged in as. It seems to completely dissolve any anonymity, period.

tareqak 8y ago
Actually, you totally have a point. Consider the case of China and its Great Firewall. If you can control the URL and separate it from the content, then you can control what people see on yet another level e.g. we aren't blocking what Wikipedia says about the Tienanmen Square massacre this is what that URL actually says. tl;dr gaslighting / rewriting history on a mass scale if you can't use the URL to get to particular server.
- samstave 8y ago
  Now imagine taking all that data and building the "social credit score" on the sentiment analysis for the consumption habits of all users' actions online...
  - romeisendcoming 8y ago
    And adding mandatory, recorded, voice commands for a subset of functionality.
taneq 8y ago
As always with Google, there are two outcomes. An improvement to some engineering or social issue, and an increase in the amount of data flowing into Google from the rest of the world. Of course the latter is pure coincidence, but it's always there.
- baud147258 8y ago
  > Of course the latter is pure coincidence You should have added a /s. It's not a coincidence, it's part of how Google say they are improving their services

throwaway2048 8y ago

Reminds me of chromium dev discussions about severely limiting ad-blockers, for your safety of course, and only for the users. Not for Google's massive benefit.

princekolt 8y ago

I think the only hope would be pushing more people to drop Chrome and start using different browsers. This would reduce the leverage Google has to bully other browsers to follow them. This might sound impossible today, but 10 years ago we'd be saying the same thing about IE.

mancerayder 8y ago
Firefox has become increasingly usable. I've transitioned to it and DuckDuckGo, using Chrome only for the Google business apps. On mobile on Android it gets mad and freez-y if you open too many tabs, and on desktop it gets angry and pause-y if you're behind a proxy, but otherwise it's pretty decent.

cm2187 8y ago

It's the same argument about file hierarchies. Apple doesn't think users should even be aware that there is a file hierarchy (iOS). I don't think users are confused at all by files and folders. But somehow Apples seems to think they are. What I do not understand is that the percentage of people who didn't grow up with a computer is only going to go down, not up. These evolutions I think go in the wrong direction.

webmobdev 8y ago
> I don't think users are confused at all by files and folders. But somehow Apples seems to think they are. Agreed. And am glad that they were forced to reconsider and have introduced a FILES (https://www.imore.com/files-app https://www.imore.com/files-app) App on ios.
- amelius 8y ago
  It seems still not possible to attach a USB drive, though :(

eeeeeeeeeeeee 8y ago

Killing or obfuscating the URL is really only good for Google. They don’t want people going directly to any website, they want you arriving at it through a Google property so they can pitch ads to you or at least track you through that funnel.

tylerl 8y ago

It's dumb that I actually have to say this.... But chrome isn't actually killing URLs or even taking steps toward killing URLs, despite the clickbait story title. Instead they're taking steps toward better identifying fraud. But nobody would read the story if that's all it said.