11 ms·

Improving URLs for AMP Pages

96 points by taytus 9y ago

fragmede 9y ago
In related news, Firefox Quantum is out; rewritten in Rust. And, good news The mobile version supports extensions, in case you're missing ad block on mobile Chrome.
- jhasse 9y ago
  Unfortunately it's a pretty bad experience on Android thanks to https://bugzilla.mozilla.org/show_bug.cgi?id=806385 https://bugzilla.mozilla.org/show_bug.cgi?id=806385 (for example YouTube links won't open the native app)
  - vocatus_gate 9y ago
    If that's the worst that happens I'll take it.
    - jhasse 9y ago
      Scrolling performance is also a lot worse.
  - dcow 9y ago
    Get the beta version 58. It's much better.
    - jhasse 9y ago
      The bug is still present, isn't it? I use an app for reddit, an app for hacker news, an app for YouTube, etc. If I stumble upon a URL of one of those sites I always want it to open in the app, since the UX is so much better there.
ericflo 9y ago
I don't understand. So now the URL bar won't always show where the page was actually loaded from? It could show example.com but really be loaded from Google'S AMP servers? If I'm reading this right, I find it very sad.
- cramforce 9y ago
  Web Packaging [https://github.com/WICG/webpackage https://github.com/WICG/webpackage] allows the authority over an origin to delegate serving to a third party (and support things like offline serving). This is similar, but better than e.g. what a CDN does today, because the third party does not need access to the private key.
- wmf 9y ago
  That's how CDNs already work. For example, apple.com is served from Akamai. And AMP is planning to use cryptographic signing so that the browser can verify that the CDN didn't tamper with the page.
  - jopsen 9y ago
    Well, today Apple is trust Akamai with a certificate for their origin: apple.com In this future, it seems like the content will be signed with Apples TLS certificate/key and then the content can be distributed by anyone. This could open the doors for a more distributed web too :)
    - ericflo 9y ago
      To be honest, the more that I've looked into this, the more it seems like a good idea. It was not presented as a new and fairly dramatically different way of distributing content on the web, it was presented as a way to get around showing the URL in response to pushback from the web community. I think if this announcement were written differently, I would've come away with a much better impression of the whole thing.
      - jopsen 9y ago
makecheck 9y ago
Somewhat predictable to see the mess evolving. Once you start peanut-buttering over something, not quite all the nagging problems go away and then you need even more “solutions”. Then even more. Enough, Google. Making small web sites is EASY, OK? No AMP needed: just write your content and, as if by magic, it is small and loads nearly instantly. If web sites are bloated and slow, close them and use something else. Stop hyperextending the web to make lousy programming practices the norm.
- mikeokner 9y ago
  Yeah I find it strange that publishers & such bother to release AMP versions of their sites but then opt to keep their crappy, bloated versions around as the default. Google should just more explicitly rank pages based on load times and incentivize sites to fix their crap.
  - wmf 9y ago
    Google should just more explicitly rank pages based on load times and incentivize sites to fix their crap. Apparently they already did this and it had no effect. It seems like anything less than a binary signal (in the carousel vs. not) is too subtle for publishers to understand.
    - CaptSpify 9y ago
      They could just strengthen the weight of that to be more noticeable. But Google has a vested interest in keeping JS everywhere. I seriously doubt that they tried hard.
      - Andrex 9y ago
        > Google has a vested interest in keeping JS everywhere I believe AMP pages have no JavaScript.
  - deleted 9y ago
    [deleted]
niftich 9y ago
The meat of the story is: "We embarked on a multi-month long effort, and today we finally feel confident that we found a solution: As recommended by the W3C TAG [1], we intend to implement a new version of AMP Cache serving based on the emerging Web Packaging standard [2]." I'm just reading through this so I'm gleaning as I go, but it looks like the W3C TAG came out with a recommendation for 'Distributed and Syndicated Content' [1] that specifically addresses AMP by name, and recommends strategies to do this kind of content syndication in a way that preserves the original provenance of the data. The Web Packaging Format [2] aims to, apparently [3], solve packing together resources, but, rather, HTTP request-response pairs, maybe HPACKed?, and signed and hashed for integrity, in a flat hierarchy, in a CBOR envelope, that nonetheless has MIME-like properties? I'm still digesting what's all involved. [1] https://www.w3.org/2001/tag/doc/distributed-content/ https://www.w3.org/2001/tag/doc/distributed-content/ [2] https://github.com/WICG/webpackage https://github.com/WICG/webpackage [3] https://github.com/WICG/webpackage/blob/master/explainer.md https://github.com/WICG/webpackage/blob/master/explainer.md
jopsen 9y ago
The most interesting thing to me seems that they plan to decoupled signing of content from TLS connections. So that packages could be signed using normal TLS certificates (or something like that). Hmm, so maybe in some future static-only sites will be able to sign a bundle with offline keys and not use TLS at all. Or maybe we just sign static bundle with a TLS key for our origin and upload the bundle to Google and other web caches. As in maybe the internet can be distributed again. I see lots of interesting potential in decoupling origin verification from TLS connections. Web Packaging Format Explainer: https://github.com/WICG/webpackage/blob/master/explainer.md https://github.com/WICG/webpackage/blob/master/explainer.md
- geofft 9y ago
  The thing I'm very curious to see is whether Google will permit uploading custom webpackages and whether it will treat them as equivalent to actual Google-blessed AMP webpackages in terms of results page placement. With some rules on the webpackages being small and not referencing too much external stuff, sure, but if I have an actual lightweight web page, I should be able to generate a pretty small webpackage containing my page and its CSS, with no reference to the AMP JS library or anything, and I should be able to send that to anyone who wants to cache/CDN my website. I'm imagining a world where a static site generator + Let's Encrypt automatically generates these webpackages for you and uploads them to Google, and also DuckDuckGo, Bing, etc. And when someone creates an HN or Reddit post, the HN / Reddit server checks to see if there is a webpackage available for that page and if it's not too many kilobytes, and serves that when you click on the link. That seems like it delivers on the original promise/vision of AMP, and also gets entirely out of the vendor lock-in problem that AMP has today and into something genuinely novel and good for the web.
- tlrobinson 9y ago
  Web Packaging sounds really interesting. I think there's a need for another layer of security in certain types of web applications (secure messaging, financial, cryptocurrency). It sounds like this is a "nice to have" use-case: https://github.com/WICG/webpackage/blob/master/draft-yasskin-webpackage-use-cases.md#third-party-security-review-security-review https://github.com/WICG/webpackage/blob/master/draft-yasskin... I've almost been able to abuse Service Workers for this purpose. After the Service Worker is installed on first load you can intercept any requests (including the HTML and JavaScript) and verify a signature on them using a key embedded in the Service Worker. The big problem is it seems like you can't reliably prevent the browser from trying to update the Service Worker itself, which is obviously a deal breaker. Also shift-reload bypasses the Service Worker completely.
bla2 9y ago
I don't get all the amp hate. They seem to make an effort to do the right thing, and from a user perspective it's a great experience imho.
- acdha 9y ago
  > from a user perspective it's a great experience imho. Until you need to share a link, wonder why the page loaded slower than normal thanks to 100Kb of render-blocking JavaScript, or get phished or believe a spoof because it has google.com in the URL. I really like the stated goals but shipping something with usability problems is a great way to get tarnish its reputation. Hopefully this new incarnation will live up to the original hope.
  - deleted 9y ago
    [deleted]
- librexpr 9y ago
  As an AMP "hater", I couldn't care less about the AMP user experience. My problem with AMP is that to be on Google's Carousel, which shows up at the top of mobile search results, you need to serve your content from Google's servers. If Google allowed people to host AMP pages on their own servers and still show up on the Carousel, I would have no problem with AMP. As it is, though, AMP is a blatant power-grab from a corporation that's already got way too much control over the web.
- geofft 9y ago
  It's been a bad user experience for me - I've run into a fair number of AMP sites that load part of the content but not all of it (some websites, like Know Your Meme, put truncated content + a "read more" button in AMP; some host video or embedded documents or whatever and those don't make it to AMP), so my experience has been that I load the AMP page, scroll a bit, and then end up needing to load the real page. Also I end up on AMP pages (generally the origin's AMP-reduced pages, not the Google cache thereof) way too often on desktop. That said, yes, I still lean towards clicking on AMP sites and hoping that it's faster. But that's the irrational part of my brain, and the rational part would be happier with an additional 200-300 ms loading time in exchange for reliability.
spc476 9y ago
Can someone explain what this is about? > As we detailed in a deep-dive blog post last year, privacy reasons make it basically impossible to load the page from the publisher’s server. Publishers shouldn’t know what people are interested in until they actively go to their pages. Instead, AMP pages are loaded from the Google AMP Cache but with that behavior the URLs changed to include the google.com/amp/ URL prefix. To me, this reads as "for our privacy, we don't tell the publisher what page has loaded" but that may be an uncharitable interpretation. I read the referenced blog post and it didn't clear up anything about the "privacy" issues.
- niftich 9y ago
  The post makes the case that they don't want the publisher to know that AMP thinks the user would want to visit, and that's more of a matter of the user's privacy, since that implementation would have the user's user-agent as the origin. Instead, the concern is sidestepped by the extra indirection: the user's user-agent will load the prefetches from the AMP cache. How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable.
  - pgeorgi 9y ago
    > How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable. There's a difference between explicit prefetching (given by html tags, ie there's intent), speculative prefetching on the same origin (you already talk to them) and speculative prefetching across the entire net (you talk to somebody new out of the blue). Preloading search results for faster display without a local Google-side cache means that more parties know that you (IP, User Agent, cookies) are potentially interested in certain pages due to a Google search (referer header). With the AMP cache as currently implemented (and with the TAG bundles in a future version), Google gets to know that you just got the URLs A, B and C proposed by Google. Which is no additional information for anybody, at Google or elsewhere. If this new scheme allows rolling back some of the less fortunate effects of AMP (the visibility of the AMP cache URL, the in-page URL bar emulation as a workaround to that), all the better.
ENGNR 9y ago
A step in the right direction but it doesn't entirely solve the issue. To make this complete they simply need to remove all Google nav/branding/back button from AMP pages (or at least offer the option) AMP should have been purely an open source library implementing a specification, not a way to opt-in to becoming a sub page within Google If I go out to a new URL it should then cut away the relationship with the old site, even if AMP makes that transition a bit quicker and gives the new site tools to load the page more quickly
- geofft 9y ago
  It looks like this will enable doing that, right? The big reason for the AMP top bar is to show the original domain and provide a way to get a link - this proposal has the AMP page running actually under the original domain (as far as the browser UI is concerned; network traffic is still to Google, but the data is signed by the website), so there's no reason for it not to behave just like an actual link to the website, and rely on the browser back button.
  - tyingq 9y ago
    Since there's no technical reason for it to stay, what Google decides to do here will be telling.
    - jopsen 9y ago
      There are other browsers...
      - topaxi 9y ago
        sadly not used enough...
    - Ajedi32 9y ago
      Are you suggesting they may be planning to leave the AMP bar at the top of the page? Even though they just went through a "multi-month long effort" with the explicit goal of removing that UI in favor of using the real URL bar?
ghughes 9y ago
> Publishers shouldn’t know what people are interested in until they actively go to their pages. Yes, that privilege is reserved for Google.
- baddox 9y ago
  Well, Google doesn’t know anything until you go to a Google page either. Not counting things like Google Analytics, of course, but publishers choose to share that info with Google.
  - dannyw 9y ago
    Google Chrome, when signed in, uploads your web history to Google by default.
    - jankey 9y ago
      Emphasis "when signed in".
      - dmitriid 9y ago
        You don't need to sign in. Everybody knows everything about you. Whether it's through tracking cookies, or through Google Analytics, or through device fingerprinting. Google quoting privacy concerns is especially disingenuous, as they can track you and your activities across multiple devices.
      - deleted 9y ago
        [deleted]
dcow 9y ago
Usually I try to be constructive, but I just need to get this out: fuck AMP. I don't care downvote me to oblivion I'm a little buzzed but FFS who actually wants AMP and why is it even a thing? Why can't Chrome just prefetch shit from the actual servers and let ISPs handle the caching? Why does mother Google need to serve me all the content from its overly suckled teat? I know everyone working on AMP means well but why why why does Google insist on destroying the internet and entirely undermining TLS in the process? Sorry. That was therapeutic. Bonus Quiz: 1. When I encounter an AMP link I... a) Click it. b) Don't click it. c) I don't see AMP links using FireFox. 2. When my friends send me an AMP link... a) I click it. b) I don't click it. c) Friends don't send friends AMP links. 3. Reasons I've switched to FireFox... a) I love RUst. b) I care about privacy. c) I hate AMP. 4. My ISP is... a) Google b) Chrome c) None of the above. The answer is 'c'.
- DyslexicAtheist 9y ago
  same thoughts. it's hard to contain myself when smart people seriously discuss it's merits instead of burning it with fire.
- ec109685 9y ago
  An ISP can’t see https content to cache. Having google prefetch normal html pages would thoroughly break most website’s analytics, be potentially a violation of privacy and do a hundred other horrendous things if they tried to instantly load cached normal html pages within the google search result page.
  - dcow 9y ago
    But if Google does it on effectively their own network it's okay? Nothing changes there except analytics and bandwidth usage. Too much for the internet but not to fear Google is here with a web scale solution: build a new internet a googlenet where services only get info Google blesses them with......
    - ec109685 9y ago
      Google is caching pages specifically designed to be cached, including supporting ads and analytics for the publisher. You isp caching solution can’t do that.
dveeden2 9y ago
I once wrote something similar to figure out what happened based on corrupted and non-corrupted input. http://unicode-doctor.myname.nl/ http://unicode-doctor.myname.nl/
benatkin 9y ago
It's tacky reading "y'all" in an official google blog post about how they're going to hijack browsers to further centralize the web, and where they're suggesting that giving google all the traffic helps improve privacy, but I guess that's the kind of world we live in.
- kavok 9y ago
  Y’all is a pretty useful word. Is using you’re or they’ll tacky as well? It might be that you have a subconscious cultural bias against the word.
  - vog 9y ago
    > It might be that you have a subconscious cultural bias against the word. Poe's law is very strong here.
  - mattmanser 9y ago
    Outside a certain community of Americans, it's an incredibly tacky word that really grates whenever I read it. Why anyone think it's the slightest bit professional to use it in official communications is mind boggling. It was sort of trendy for a little bit on Reddit with a certain type of abrasive and annoying American, but thankfully it seems to becoming uncool again. It is also an extremely imperialistic word. Americans use it, it feels as if it only refers to Americans, and Google is only listening to Americans.
    - kavok 9y ago
      It isn't only used in America, but I would agree that it is predominantly known for that. Usage of the word appears to be increasing. It fulfills a role in the English language that no other word seems to hit as easily. It'd be nice if the word were more publicly acceptable. I didn't grow up in the south but always found the word to be useful.
      - dcow 9y ago
        Keep in mind it's American southern slang and not everyone can necessarily help that they use it. It's effectively an accent. Be careful what y'alls implying about its usage (;
garganzol 9y ago
What a nice touch they published that on amphtml.wordpress.com. Like, "see, we are free as in beer and represent the voice of people". By using .wordpress.com instead of .google.com they execute a well-calculated PR strategy. But in reality, Google tries to racket the free and open web in order to squeeze even more juice to feed its insatiable corporate greed.
- ec109685 9y ago
  No, they have a marketing company run their amp website.
mcny 9y ago
I'm sorry. I don't get this hatred for amp. Amp is not the problem here. The problem is that we accept third party JavaScript on every page on our monetized website. From what I understand, you can completely self-host and be amp-compliant. Is that not the case? If you care about user experience, you should not let the highest bidder* run JavaScript on your website on your user's devices. Demand your ad network that they provide ads that are just text and images. Demand your ad network to host that text and those images themselves with a reliably low latency and so on. Or better yet, remove the advertising if you care about user experience. If you are a news organization and Google won't let you be in a certain section without serving on Google, complain. My understanding is that AMP exists to solve a problem. It obviously isn't the only way to solve that problem.
- lucideer 9y ago
  > From what I understand, you can completely self-host and be amp-compliant. Is that not the case? I don't believe this is the case, no. Unless how AMP works has significantly changed recently, it requires your site to be hosted on, and served from, Google's servers. This hosting is called "AMP Cache". When AMP first launched, Google's servers were the only available "AMP Cache". They have since added the ability to set up your own AMP Cache, which seems like some attempt to appease people's concerns with AMP being Google-only, but doing so seems an utterly pointless enterprise because of the below (from AMP's docs): > How do I choose an AMP Cache? > As a publisher, you don't choose an AMP Cache, it's actually the platform that links to your content that chooses the AMP Cache (if any) to use. So if you set up your own AMP Cache, this just means your site will be hosted on Google's servers, and served from Google search results on Google's, and probably noone will ever visit the copy on your own AMP Cache server.
  - pgeorgi 9y ago
    The idea of additional AMP cache servers is that bing, yahoo, facebook, twitter, ... could set them up for their outbound links, so they can implement the same preloading behavior as an optimization (since they tend to have servers that are closer to users, and the connection already exists and can be reused). Think of the Google AMP cache as an extended web site snippet on the google.com search, not as your primary delivery mechanism: To make this safe and useful for all parties (publisher, user, link service providers such as google search or twitter), AMP defines an html/css/js subset that is considered safe but still functional - so that (for example) analytics can still be made to work, which is important to publishers, but without working in the AMP cache hoster's domain context, which is important for their security. Another AMP cache provider is Bing: https://blogs.bing.com/search/September-2016/bing-app-joins-the-amp-open-source-effort https://blogs.bing.com/search/September-2016/bing-app-joins-...
matthewmacleod 9y ago
Still shite. AMP still breaks scrolling and results in weird stub pages that are missing features. And I can't turn it off. AMP-enabled pages load faster, but on the other hand I have an ad-blocker and LTE that gets 10Mbps, so the improvement is negligible. Not worth breaking the web, IMHO.
- dcow 9y ago
  Stop using Chrome. Problem solved.
ferongr 9y ago
I'll go against the grain. I like amp. The less 50MB pages drain my 250MB data plan, the better.
lucideer 9y ago
From the article: > while maintaining the [...] privacy benefits of AMP Cache serving "AMP Cache serving" == hosted on Google's server. This makes this statement at best, stupidly oxymoronic, at worst, deliberately dishonest advertising. > privacy reasons make it basically impossible to load the page from the publisher’s server. Browsers (including Firefox[0][1]) already do this. There are no "privacy reasons" preventing this. The only reason not to do this is to present another justification for opting into their AMP Cache product. > can take advantage of privacy-preserving preloading and the performance of Google’s servers Also a contradiction of terms. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1016628 https://bugzilla.mozilla.org/show_bug.cgi?id=1016628

96 points by taytus 9y ago

In related news, Firefox Quantum is out; rewritten in Rust. And, good news The mobile version supports extensions, in case you're missing ad block on mobile Chrome.

jhasse 9y ago
Unfortunately it's a pretty bad experience on Android thanks to https://bugzilla.mozilla.org/show_bug.cgi?id=806385 https://bugzilla.mozilla.org/show_bug.cgi?id=806385 (for example YouTube links won't open the native app)
- vocatus_gate 9y ago
  If that's the worst that happens I'll take it.
  - jhasse 9y ago
    Scrolling performance is also a lot worse.
- dcow 9y ago
  Get the beta version 58. It's much better.
  - jhasse 9y ago
    The bug is still present, isn't it? I use an app for reddit, an app for hacker news, an app for YouTube, etc. If I stumble upon a URL of one of those sites I always want it to open in the app, since the UX is so much better there.

ericflo 9y ago

I don't understand. So now the URL bar won't always show where the page was actually loaded from? It could show example.com but really be loaded from Google'S AMP servers? If I'm reading this right, I find it very sad.

cramforce 9y ago
Web Packaging [https://github.com/WICG/webpackage https://github.com/WICG/webpackage] allows the authority over an origin to delegate serving to a third party (and support things like offline serving). This is similar, but better than e.g. what a CDN does today, because the third party does not need access to the private key.
wmf 9y ago
That's how CDNs already work. For example, apple.com is served from Akamai. And AMP is planning to use cryptographic signing so that the browser can verify that the CDN didn't tamper with the page.
- jopsen 9y ago
  Well, today Apple is trust Akamai with a certificate for their origin: apple.com In this future, it seems like the content will be signed with Apples TLS certificate/key and then the content can be distributed by anyone. This could open the doors for a more distributed web too :)
  - ericflo 9y ago
    To be honest, the more that I've looked into this, the more it seems like a good idea. It was not presented as a new and fairly dramatically different way of distributing content on the web, it was presented as a way to get around showing the URL in response to pushback from the web community. I think if this announcement were written differently, I would've come away with a much better impression of the whole thing.
    - jopsen 9y ago

makecheck 9y ago

Somewhat predictable to see the mess evolving. Once you start peanut-buttering over something, not quite all the nagging problems go away and then you need even more “solutions”. Then even more. Enough, Google. Making small web sites is EASY, OK? No AMP needed: just write your content and, as if by magic, it is small and loads nearly instantly. If web sites are bloated and slow, close them and use something else. Stop hyperextending the web to make lousy programming practices the norm.

mikeokner 9y ago
Yeah I find it strange that publishers & such bother to release AMP versions of their sites but then opt to keep their crappy, bloated versions around as the default. Google should just more explicitly rank pages based on load times and incentivize sites to fix their crap.
- wmf 9y ago
  Google should just more explicitly rank pages based on load times and incentivize sites to fix their crap. Apparently they already did this and it had no effect. It seems like anything less than a binary signal (in the carousel vs. not) is too subtle for publishers to understand.
  - CaptSpify 9y ago
    They could just strengthen the weight of that to be more noticeable. But Google has a vested interest in keeping JS everywhere. I seriously doubt that they tried hard.
    - Andrex 9y ago
      > Google has a vested interest in keeping JS everywhere I believe AMP pages have no JavaScript.
- deleted 9y ago
  [deleted]

niftich 9y ago

The meat of the story is: "We embarked on a multi-month long effort, and today we finally feel confident that we found a solution: As recommended by the W3C TAG [1], we intend to implement a new version of AMP Cache serving based on the emerging Web Packaging standard [2]." I'm just reading through this so I'm gleaning as I go, but it looks like the W3C TAG came out with a recommendation for 'Distributed and Syndicated Content' [1] that specifically addresses AMP by name, and recommends strategies to do this kind of content syndication in a way that preserves the original provenance of the data. The Web Packaging Format [2] aims to, apparently [3], solve packing together resources, but, rather, HTTP request-response pairs, maybe HPACKed?, and signed and hashed for integrity, in a flat hierarchy, in a CBOR envelope, that nonetheless has MIME-like properties? I'm still digesting what's all involved. [1] https://www.w3.org/2001/tag/doc/distributed-content/ https://www.w3.org/2001/tag/doc/distributed-content/ [2] https://github.com/WICG/webpackage https://github.com/WICG/webpackage [3] https://github.com/WICG/webpackage/blob/master/explainer.md https://github.com/WICG/webpackage/blob/master/explainer.md

jopsen 9y ago

The most interesting thing to me seems that they plan to decoupled signing of content from TLS connections. So that packages could be signed using normal TLS certificates (or something like that). Hmm, so maybe in some future static-only sites will be able to sign a bundle with offline keys and not use TLS at all. Or maybe we just sign static bundle with a TLS key for our origin and upload the bundle to Google and other web caches. As in maybe the internet can be distributed again. I see lots of interesting potential in decoupling origin verification from TLS connections. Web Packaging Format Explainer: https://github.com/WICG/webpackage/blob/master/explainer.md https://github.com/WICG/webpackage/blob/master/explainer.md

geofft 9y ago
The thing I'm very curious to see is whether Google will permit uploading custom webpackages and whether it will treat them as equivalent to actual Google-blessed AMP webpackages in terms of results page placement. With some rules on the webpackages being small and not referencing too much external stuff, sure, but if I have an actual lightweight web page, I should be able to generate a pretty small webpackage containing my page and its CSS, with no reference to the AMP JS library or anything, and I should be able to send that to anyone who wants to cache/CDN my website. I'm imagining a world where a static site generator + Let's Encrypt automatically generates these webpackages for you and uploads them to Google, and also DuckDuckGo, Bing, etc. And when someone creates an HN or Reddit post, the HN / Reddit server checks to see if there is a webpackage available for that page and if it's not too many kilobytes, and serves that when you click on the link. That seems like it delivers on the original promise/vision of AMP, and also gets entirely out of the vendor lock-in problem that AMP has today and into something genuinely novel and good for the web.
tlrobinson 9y ago
Web Packaging sounds really interesting. I think there's a need for another layer of security in certain types of web applications (secure messaging, financial, cryptocurrency). It sounds like this is a "nice to have" use-case: https://github.com/WICG/webpackage/blob/master/draft-yasskin-webpackage-use-cases.md#third-party-security-review-security-review https://github.com/WICG/webpackage/blob/master/draft-yasskin... I've almost been able to abuse Service Workers for this purpose. After the Service Worker is installed on first load you can intercept any requests (including the HTML and JavaScript) and verify a signature on them using a key embedded in the Service Worker. The big problem is it seems like you can't reliably prevent the browser from trying to update the Service Worker itself, which is obviously a deal breaker. Also shift-reload bypasses the Service Worker completely.

bla2 9y ago

I don't get all the amp hate. They seem to make an effort to do the right thing, and from a user perspective it's a great experience imho.

acdha 9y ago
> from a user perspective it's a great experience imho. Until you need to share a link, wonder why the page loaded slower than normal thanks to 100Kb of render-blocking JavaScript, or get phished or believe a spoof because it has google.com in the URL. I really like the stated goals but shipping something with usability problems is a great way to get tarnish its reputation. Hopefully this new incarnation will live up to the original hope.
- deleted 9y ago
  [deleted]
librexpr 9y ago
As an AMP "hater", I couldn't care less about the AMP user experience. My problem with AMP is that to be on Google's Carousel, which shows up at the top of mobile search results, you need to serve your content from Google's servers. If Google allowed people to host AMP pages on their own servers and still show up on the Carousel, I would have no problem with AMP. As it is, though, AMP is a blatant power-grab from a corporation that's already got way too much control over the web.
geofft 9y ago
It's been a bad user experience for me - I've run into a fair number of AMP sites that load part of the content but not all of it (some websites, like Know Your Meme, put truncated content + a "read more" button in AMP; some host video or embedded documents or whatever and those don't make it to AMP), so my experience has been that I load the AMP page, scroll a bit, and then end up needing to load the real page. Also I end up on AMP pages (generally the origin's AMP-reduced pages, not the Google cache thereof) way too often on desktop. That said, yes, I still lean towards clicking on AMP sites and hoping that it's faster. But that's the irrational part of my brain, and the rational part would be happier with an additional 200-300 ms loading time in exchange for reliability.

spc476 9y ago

Can someone explain what this is about? > As we detailed in a deep-dive blog post last year, privacy reasons make it basically impossible to load the page from the publisher’s server. Publishers shouldn’t know what people are interested in until they actively go to their pages. Instead, AMP pages are loaded from the Google AMP Cache but with that behavior the URLs changed to include the google.com/amp/ URL prefix. To me, this reads as "for our privacy, we don't tell the publisher what page has loaded" but that may be an uncharitable interpretation. I read the referenced blog post and it didn't clear up anything about the "privacy" issues.

niftich 9y ago
The post makes the case that they don't want the publisher to know that AMP thinks the user would want to visit, and that's more of a matter of the user's privacy, since that implementation would have the user's user-agent as the origin. Instead, the concern is sidestepped by the extra indirection: the user's user-agent will load the prefetches from the AMP cache. How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable.
- pgeorgi 9y ago
  > How much of this is moot given that many browsers, including Chrome, offer speculative fetching as a feature, is debatable. There's a difference between explicit prefetching (given by html tags, ie there's intent), speculative prefetching on the same origin (you already talk to them) and speculative prefetching across the entire net (you talk to somebody new out of the blue). Preloading search results for faster display without a local Google-side cache means that more parties know that you (IP, User Agent, cookies) are potentially interested in certain pages due to a Google search (referer header). With the AMP cache as currently implemented (and with the TAG bundles in a future version), Google gets to know that you just got the URLs A, B and C proposed by Google. Which is no additional information for anybody, at Google or elsewhere. If this new scheme allows rolling back some of the less fortunate effects of AMP (the visibility of the AMP cache URL, the in-page URL bar emulation as a workaround to that), all the better.

ENGNR 9y ago

A step in the right direction but it doesn't entirely solve the issue. To make this complete they simply need to remove all Google nav/branding/back button from AMP pages (or at least offer the option) AMP should have been purely an open source library implementing a specification, not a way to opt-in to becoming a sub page within Google If I go out to a new URL it should then cut away the relationship with the old site, even if AMP makes that transition a bit quicker and gives the new site tools to load the page more quickly

geofft 9y ago
It looks like this will enable doing that, right? The big reason for the AMP top bar is to show the original domain and provide a way to get a link - this proposal has the AMP page running actually under the original domain (as far as the browser UI is concerned; network traffic is still to Google, but the data is signed by the website), so there's no reason for it not to behave just like an actual link to the website, and rely on the browser back button.
- tyingq 9y ago
  Since there's no technical reason for it to stay, what Google decides to do here will be telling.
  - jopsen 9y ago
    There are other browsers...
    - topaxi 9y ago
      sadly not used enough...
  - Ajedi32 9y ago
    Are you suggesting they may be planning to leave the AMP bar at the top of the page? Even though they just went through a "multi-month long effort" with the explicit goal of removing that UI in favor of using the real URL bar?

ghughes 9y ago

> Publishers shouldn’t know what people are interested in until they actively go to their pages. Yes, that privilege is reserved for Google.

baddox 9y ago
Well, Google doesn’t know anything until you go to a Google page either. Not counting things like Google Analytics, of course, but publishers choose to share that info with Google.
- dannyw 9y ago
  Google Chrome, when signed in, uploads your web history to Google by default.
  - jankey 9y ago
    Emphasis "when signed in".
    - dmitriid 9y ago
      You don't need to sign in. Everybody knows everything about you. Whether it's through tracking cookies, or through Google Analytics, or through device fingerprinting. Google quoting privacy concerns is especially disingenuous, as they can track you and your activities across multiple devices.
    - deleted 9y ago
      [deleted]

dcow 9y ago

Usually I try to be constructive, but I just need to get this out: fuck AMP. I don't care downvote me to oblivion I'm a little buzzed but FFS who actually wants AMP and why is it even a thing? Why can't Chrome just prefetch shit from the actual servers and let ISPs handle the caching? Why does mother Google need to serve me all the content from its overly suckled teat? I know everyone working on AMP means well but why why why does Google insist on destroying the internet and entirely undermining TLS in the process? Sorry. That was therapeutic. Bonus Quiz: 1. When I encounter an AMP link I... a) Click it. b) Don't click it. c) I don't see AMP links using FireFox. 2. When my friends send me an AMP link... a) I click it. b) I don't click it. c) Friends don't send friends AMP links. 3. Reasons I've switched to FireFox... a) I love RUst. b) I care about privacy. c) I hate AMP. 4. My ISP is... a) Google b) Chrome c) None of the above. The answer is 'c'.

DyslexicAtheist 9y ago
same thoughts. it's hard to contain myself when smart people seriously discuss it's merits instead of burning it with fire.
ec109685 9y ago
An ISP can’t see https content to cache. Having google prefetch normal html pages would thoroughly break most website’s analytics, be potentially a violation of privacy and do a hundred other horrendous things if they tried to instantly load cached normal html pages within the google search result page.
- dcow 9y ago
  But if Google does it on effectively their own network it's okay? Nothing changes there except analytics and bandwidth usage. Too much for the internet but not to fear Google is here with a web scale solution: build a new internet a googlenet where services only get info Google blesses them with......
  - ec109685 9y ago
    Google is caching pages specifically designed to be cached, including supporting ads and analytics for the publisher. You isp caching solution can’t do that.

dveeden2 9y ago

I once wrote something similar to figure out what happened based on corrupted and non-corrupted input. http://unicode-doctor.myname.nl/ http://unicode-doctor.myname.nl/

benatkin 9y ago

It's tacky reading "y'all" in an official google blog post about how they're going to hijack browsers to further centralize the web, and where they're suggesting that giving google all the traffic helps improve privacy, but I guess that's the kind of world we live in.

kavok 9y ago
Y’all is a pretty useful word. Is using you’re or they’ll tacky as well? It might be that you have a subconscious cultural bias against the word.
- vog 9y ago
  > It might be that you have a subconscious cultural bias against the word. Poe's law is very strong here.
- mattmanser 9y ago
  Outside a certain community of Americans, it's an incredibly tacky word that really grates whenever I read it. Why anyone think it's the slightest bit professional to use it in official communications is mind boggling. It was sort of trendy for a little bit on Reddit with a certain type of abrasive and annoying American, but thankfully it seems to becoming uncool again. It is also an extremely imperialistic word. Americans use it, it feels as if it only refers to Americans, and Google is only listening to Americans.
  - kavok 9y ago
    It isn't only used in America, but I would agree that it is predominantly known for that. Usage of the word appears to be increasing. It fulfills a role in the English language that no other word seems to hit as easily. It'd be nice if the word were more publicly acceptable. I didn't grow up in the south but always found the word to be useful.
    - dcow 9y ago
      Keep in mind it's American southern slang and not everyone can necessarily help that they use it. It's effectively an accent. Be careful what y'alls implying about its usage (;

garganzol 9y ago

What a nice touch they published that on amphtml.wordpress.com. Like, "see, we are free as in beer and represent the voice of people". By using .wordpress.com instead of .google.com they execute a well-calculated PR strategy. But in reality, Google tries to racket the free and open web in order to squeeze even more juice to feed its insatiable corporate greed.

ec109685 9y ago
No, they have a marketing company run their amp website.

mcny 9y ago

I'm sorry. I don't get this hatred for amp. Amp is not the problem here. The problem is that we accept third party JavaScript on every page on our monetized website. From what I understand, you can completely self-host and be amp-compliant. Is that not the case? If you care about user experience, you should not let the highest bidder* run JavaScript on your website on your user's devices. Demand your ad network that they provide ads that are just text and images. Demand your ad network to host that text and those images themselves with a reliably low latency and so on. Or better yet, remove the advertising if you care about user experience. If you are a news organization and Google won't let you be in a certain section without serving on Google, complain. My understanding is that AMP exists to solve a problem. It obviously isn't the only way to solve that problem.

lucideer 9y ago
> From what I understand, you can completely self-host and be amp-compliant. Is that not the case? I don't believe this is the case, no. Unless how AMP works has significantly changed recently, it requires your site to be hosted on, and served from, Google's servers. This hosting is called "AMP Cache". When AMP first launched, Google's servers were the only available "AMP Cache". They have since added the ability to set up your own AMP Cache, which seems like some attempt to appease people's concerns with AMP being Google-only, but doing so seems an utterly pointless enterprise because of the below (from AMP's docs): > How do I choose an AMP Cache? > As a publisher, you don't choose an AMP Cache, it's actually the platform that links to your content that chooses the AMP Cache (if any) to use. So if you set up your own AMP Cache, this just means your site will be hosted on Google's servers, and served from Google search results on Google's, and probably noone will ever visit the copy on your own AMP Cache server.
- pgeorgi 9y ago
  The idea of additional AMP cache servers is that bing, yahoo, facebook, twitter, ... could set them up for their outbound links, so they can implement the same preloading behavior as an optimization (since they tend to have servers that are closer to users, and the connection already exists and can be reused). Think of the Google AMP cache as an extended web site snippet on the google.com search, not as your primary delivery mechanism: To make this safe and useful for all parties (publisher, user, link service providers such as google search or twitter), AMP defines an html/css/js subset that is considered safe but still functional - so that (for example) analytics can still be made to work, which is important to publishers, but without working in the AMP cache hoster's domain context, which is important for their security. Another AMP cache provider is Bing: https://blogs.bing.com/search/September-2016/bing-app-joins-the-amp-open-source-effort https://blogs.bing.com/search/September-2016/bing-app-joins-...

matthewmacleod 9y ago

Still shite. AMP still breaks scrolling and results in weird stub pages that are missing features. And I can't turn it off. AMP-enabled pages load faster, but on the other hand I have an ad-blocker and LTE that gets 10Mbps, so the improvement is negligible. Not worth breaking the web, IMHO.

dcow 9y ago
Stop using Chrome. Problem solved.

ferongr 9y ago

I'll go against the grain. I like amp. The less 50MB pages drain my 250MB data plan, the better.

lucideer 9y ago

From the article: > while maintaining the [...] privacy benefits of AMP Cache serving "AMP Cache serving" == hosted on Google's server. This makes this statement at best, stupidly oxymoronic, at worst, deliberately dishonest advertising. > privacy reasons make it basically impossible to load the page from the publisher’s server. Browsers (including Firefox[0][1]) already do this. There are no "privacy reasons" preventing this. The only reason not to do this is to present another justification for opting into their AMP Cache product. > can take advantage of privacy-preserving preloading and the performance of Google’s servers Also a contradiction of terms. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1016628 https://bugzilla.mozilla.org/show_bug.cgi?id=1016628