Live data from Hacker News

A new approach to web performance

ampproject.org

161–170 of 177 posts

Re: A new approach to web performance

#162

Earlier quoted context omitted.

It's, ironically, a case of the "embrace and extinguish" philosophy that Microsoft was reviled for. I remember reading posts by several people which said they weren't going to build a RSS reader because they didn't want to compete with Google Reader.. and then they went ahead and killed it. RSS didn't really "take off" with mainstream users (I guess today's equivalent is Twitter), but it filled an interesting niche.…

As a distributed platform, the internet has failed. The solution is to rebuild the OS and network from the ground up: http//www.urbit.org /s

Urbit looks cool, but it will not magically make things distributed. What causes centralization are business factors. It's just a lot easier to build a great product if you have a revenue source, which is most easily acquired if you can lock people into paying for your proprietary thing.

Also, it's a lot easier to make good protocol decisions if you don't have to get them published into a standard and deal with the beauracracy etc. If you look at the level of polish in slack vs one of the many previous open source irc clients, the difference is clear. It helps to have money.

Re: A new approach to web performance

#163
post #38

What annoys me is how Google is selling this project. At least Facebook is honest about their Instant Articles. This isn't an "open standard" guys, and it's not about performance! It's about the single piece of js that's allowed on AMP pages and the amp-tags such as and that only Google controls. Performance is just the story they are selling in exchange of absolute control of the Web. After all, any publisher can ea…

First of all this is not a Google-only project. There are many partners. See e.g. https://blog.twitter.com/2015/introducing-accelerated-mobile... supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work. currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/a... We are supe…

Scanning your comments, I haven't learned about what tracking is accomplished by serving the https://cdn·ampproject·org/v0·js file itself, can you please comment on what data (if any) is collected by being 'the' place all AMP sites phone home to on page load by default?

Two other points, and I hope these are received as constructive criticism.

1- You only score 'B' on SSL labs for the domain serving the AMP JS file.[0] Maybe this is intentional so as to include support for Android devices that no longer get updates but it's not great security for the rest of us.

2- Your page explaining the project executes Google Analytics tracking code and has no privacy policy and does not disclose the fact that you are tracking visits. This is a breach of your very own Google Analytics T&C's[1] which read in part "...You must post a Privacy Policy and that Privacy Policy must provide notice of Your use of cookies that are used to collect data. You must disclose the use of Google Analytics, and how it collects and processes data...".

Neither of these inspire confidence and I hope you can get at least one of them corrected soon.

[0]https://www.ssllabs.com/ssltest/analyze.html?d=ampproject.or...

[1]https://www.google.com/analytics/terms/us.html

Re: A new approach to web performance

#164

Earlier quoted context omitted.

if you run a whois on ampproject.org, the results clearly indicate it's owned by google. Registrant ID:mmr-87489 Registrant Name:DNS Admin Registrant Organization:Google Inc. Registrant Street: 1600 Amphitheatre Parkway Registrant City:Mountain View Registrant State/Province:CA Registrant Postal Code:94043 Registrant Country:US Registrant Phone:+1.6502530000 Registrant Phone Ext: Registrant Fax: +1.6502530001 Registr…

> I can't understand why you say it's not a Google project if it's being funded by google and made by a google employee. For the same way that tons of open/collaborative projects with multiple partners are not "X projects" even if they started and/or are hosted by X. Heck, even something like Webkit is not an "Apple project"... Downvotes? Are you kidding me? What part of "open source initiative" containing multiple i…

Would you consider angular to not be a google project either then?

Re: A new approach to web performance

#165

Earlier quoted context omitted.

Authored by Google, how surprising. Also, I'm not familiar with the W3C process, but since this is a working draft, I'd assume they're invalid until the draft is finalized.

> Also, I'm not familiar with the W3C process Then don't pull random statements out of your ass about it? What are accepted as standards spend most of their life as W3C working drafts. The W3C doesn't finalize a draft until the feature is obsolete, more or less. WebWorkers, for example, is still a working draft. So is Web Storage. The only thing that has ever mattered is browser support, not W3C specs.

To expand on this, custom elements are supported in Chrome and Firefox (behind a flag in FF at the moment), and there has been public support from both Webkit and Edge, as well as high quality, high performance polyfills.

Re: A new approach to web performance

#167
post #59

Earlier quoted context omitted.

What about RSS? That offered good performance, was widely adopted and was a real standard working for both publishers and consumers. Remember who actually killed it? Yeah, that was also Google.. by discontinuing their Reader - a very good tool with lots of users but no revenue. That's how much open standards matter. Too bad @aaronsw is not around anymore, he would have said something about AMP.

This is kind of orthogonal to RSS. AMP and RSS work great together. Your feed reader can detect that the feed item URL has an AMP alternate and chose to display that instead.

How? Multiple -Element as in Atom with special rel-values? Or a link in the already linked HTML page?

There's nothing on that in the Github Wiki and neither on the project page. The superset of HTML is specced, yes, but information on the containing ecosystem is spare.

Re: A new approach to web performance

#168
post #4

Earlier quoted context omitted.

Well, most publishers actually use fairly optimized HTML/CSS and most publishers use a CDN. But there's only so much you can do if you don't want to get rid of those 5 ad networks, 7 analytics services, 2 sidebars and just generally a whole bunch of crap that has nothing to do with the article. The innovation of Facebook instant articles and AMP isn't technical, it's that they have been able to convince publishers th…

The search engines just need to penalize sites or result pages that have all these piles of bloat in them if they want to be a forcing function in the mobile web getting quicker. Push crappy experiences lower in the results and you can be sure news and aggregator sites will clean up their act. That Google et. al. are publishing a parallel framework to HTML indicates their goal is not just making mobile web faster, bu…

> The search engines just need to penalize sites or result pages that have all these piles of bloat in them if they want to be a forcing function in the mobile web getting quicker.

Isn't Google already claiming to demote sites that are slow to load, have content below the fold, etc?

Re: A new approach to web performance

#169

Earlier quoted context omitted.

> I can't understand why you say it's not a Google project if it's being funded by google and made by a google employee. For the same way that tons of open/collaborative projects with multiple partners are not "X projects" even if they started and/or are hosted by X. Heck, even something like Webkit is not an "Apple project"... Downvotes? Are you kidding me? What part of "open source initiative" containing multiple i…

Would you consider angular to not be a google project either then?

Is Angular involving multiple major-name partners such as Tweeter, and has been such from the start -- to the point of downplaying Google's involvement in the project site?

For something like SPDY/HTTP2 etc, I can say it's Google first and foremost (even if it got adoption later on).

For this not so much.

Re: A new approach to web performance

#170

Earlier quoted context omitted.

First of all this is not a Google-only project. There are many partners. See e.g. https://blog.twitter.com/2015/introducing-accelerated-mobile... supports all kinds of tracking. You just give it a URL. Ironically it does not work with Google Analytics but we'll fix that eventually. Most others should work. currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/a... We are supe…

Taking into account that Google "happens to be" the largest ad company around, it is hard to not see this as a defensive move to protect themselves at a time when the disproportionately negative impact of ad-tech has put their business at the mercy of adblockers and native apps.

In general, I think that there is an important conversation to be had about how this newly proposed cacheing tier would effect the overall cat and mouse game between tracking networks and ad blockers on mobile phones. Since the web community is being asked to choose to adopt a new technology, I don't think there's anything wrong with trying to reason about what would be technically possible to achieve in terms of tracking tech with this architecture. Here one rough estimate:

If ads are all served locally (from a single domain) then it becomes technically feasible to utilize a short-lived rotating mutation URI generation scheme. Under such a tracking system each ad unit URI would be instantiated "just in time" to redirect a certain amount of load after which it would expire away. This JIT transient URI generator could be aware of the domain's application routing table so that it can dynamically spin out each new tracking/ad unit URI in a camouflaged form. In other words each URI could appear to be only a mutated variation of organic cached content.

In computer security parlance this would establish a "covert channel" on top of HTTP via a timing attack vector (extremely short-lived URLs).

https://en.wikipedia.org/wiki/Covert_channel https://en.wikipedia.org/wiki/Timing_attack

I would imagine that ads propagated through such a system would be pretty much impossible for an ad-blocker to identify within a low-enough latency window. In other words by the time the ad unit's URI is discovered by a blocking server and it's clients are notified the URI has already vanished as if it never existed.

What's I find slightly humorous about this approach to tracking is that the scheme would closely resemble several of the "blackhat SEO" techniques which are frowned upon by Matt Cutts' "Quality Guidelines" for example "link schemes", "automatically generated content", "cloaking", and "sneaky redirects". Surely it's unfathomable to think that Google would one day resort to such forms of trickery in order to confuse other search engines :)

https://support.google.com/webmasters/topic/6001971

By the way this is only something I came up with earlier today and definitely not something that I've even heard discussed although I'm not in the advertising business myself. In other words it's entirely possible that I could have missed something here.

Post reply on HN