Hacker News Reader

Comment by ducuboy | Hacker News Reader

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 <amp-ad> and <amp-pixel> 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 easily clean up their websites as they ought to do to make it AMP compliant, but use valid HTML tags instead of the invalid amp-tags. Google could have easily promoted performance by applying penalties to heavy pages via Page Rank. But it's not about performance. It's all about the money.

View on HN

AMP is just broken HTML, hardly a standard.

https://validator.w3.org/nu/?doc=http%3A%2F%2Fwww.theverge.c...

I think this tweet from the AML project lead sums up pretty well how much they thought about standards

https://twitter.com/cramforce/status/651769139204259840

So its Google they cant even implement the sitemaps.org standard fully to spec or handle robots.txt files with BOM markers.

I wonder what the average Googler would make of OSI standards like x.400 and x.500.

I don't understand why they don't just use data-* attributes and stay valid.

Absolute control.

Please explain because that makes absolutely no sense. It's just an attribute.

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.

I was as annoyed as the next person when Google killed Reader but, to be honest, RSS was killed off for typical users way before that when browser manufacturers dropped/hid support for it. I still use RSS every day, as do many of our customers.

Indeed, also Google Chrome.

Chrome never had support. RSS support was always (and still is) from extensions.

Not just browsers, but Facebook and Twitter both killed their RSS feed at some point.

That's much worse than Google killing Reader, because reader is just a reader, you can still switch to a different one. If the source doesn't provide an RSS feed, there's not much you can do.

>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.

If a single company killing a sigle product could kill RSS, then it wasn't that alive in the first place.

The fact is, after 10 years of RSS being available in blogs, news sites and elsewhere, Reader still had an insignificant number of users in the web scale of things. A few tens of millions (all estimates put it in the low tens, like 20 to 40 millions).

Ok but that still shows how much Google cares about open standards.

And did you just say "few tens of millions" of users is insignificant? How many users are we here on Hacker News again?

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.

RSS -> Twitter

Usenet -> many proprietary platforms

IRC -> Slack

XMPP never took off

Many open, interoperable services died off or never took off, but companies built similar services and are enjoying success.

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

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.

I cackled and spat on my screen when I read the /s, well played.

"Some of these parallels are obvious, and even more or less literal: Gmail is IMAP and SMTP, and Google Talk is (or was) XMPP, all on port 80 in the same browser window. Others are more metaphorical. Twitter is IRC on port 80, although one primarily listens to users instead of channels — but listening to channels is still possible, if one uses a client that can follow hashtags, and the syntax is even the same. Dropbox is FTP on port 80. Reddit is Usenet on port 80." https://medium.com/@maradydd/on-port-80-d8d6d3443d9a

Good article, it makes the point I was trying to make better than I did.

>And did you just say "few tens of millions" of users is insignificant?

Yes.

>How many users are we here on Hacker News again?

I'd say well under a million (or around that at most). What does that have to do with anything? Did anybody say that HN has a significant amount of users web-wise?

Slashdot and then Digg, which were both something like 100 times HN in size fell off the side and nobody much cared.

I would say that Hacker News' few hundred thousand users are extremely significant both for YC and web-wise. I really hope we'll not end up with a Facebook-only Internet because that's the only service big enough to keep running.

>Reader still had an insignificant number of users in the web scale of things. A few tens of millions

an order of magnitude more than G+

Never really got used to Reader.

G+ I have used a bit. I guess I'm not alone.

Just a data point since it seems to be unreasonably many G+ haters around here.

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 <link>-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.

Yep, we're not done. Being careful with defining this finally because it can basically never be changed. Follow the project for details.

RSS never was an open standard like you would expect from a real standards organisation, e.g. IETF or W3C.

Because of dominance posturing and fights between the multiple parties involved in the development of RSS, it is a train wreck of ad-hoccery and incompatibilities, and serves as a prime example of how not to do things. https://web.archive.org/web/2004/http://diveintomark.org/arc...

> Remember who actually killed it?

Atom.

I wonder what sort of input Vox, as a publishing partner, has had on the development of AMP.

Loading the article in your validator reference shows me 80 some requests returning from 48(!) unique sources.

Interesting how on the HN link it says:

> The page you are currently reading is an AMP HTML document.

Yet it has a proper doctype of "<!doctype html>"

Custom elements are not "broken" HTML. They're very close to being a finalized standard, too:

http://w3c.github.io/webcomponents/spec/custom/

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...

<amp-pixel> 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.

<amp-ad> currently supports these ad networks https://github.com/ampproject/amphtml/blob/master/builtins/a... We are super happy to add more. We want to support all networks.

You suggest elsewhere there is revenue sharing involved, but that is not true. amp-ad just loads an ad. This is controlled by the publishers and and their agreement with the advertiser. Google only plays a role if it happens to be the ad network (or the advertiser) involved.

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.

While there's bound to be other (more efficient) solutions, blockers could start filtering by the content returned. This sort of behavior leads to an arms race, with ad blockers ultimately losing (cost to detect >> cost to circumvent).

I follow your thinking. The ad networks could begin transforming their content in subtle ways which the eye cannot detect but which could throw off simple pattern matching thereby forcing the blocker client to employ an algorithmic approach.

see https://en.wikipedia.org/wiki/BPCS-Steganography

The networks would be able to utilize many cores in parallel to mutate the content, but the blocker client would have to run it's detection on mobile devices.

The more processing the blocker client must perform the more burden it places on that relatively underpowered mobile CPU which increases latency. Also when you get into algorithmic detection you have to start considering false positive ratio because any noticeable false positives will break the user's expectation causing them to eventually lose confidence in the client's utility.

As you rightly point out there may be both vectors for either side which neither of us has thought of though.

> You suggest elsewhere there is revenue sharing involved, but that is not true.

It's the data sharing which is worrying. Exactly which entities have access to what data gathered by `ampproject.org`?

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

What are they selling, exactly? Why does this need to be a framework, with js and all that?

I'm not asking cynically, and following it up with "oh, they should just do x instead".... I legitimately do not understand what's going on here. What's the added functionality? I read the article twice, I don't get it. I'm going through the spec, I don't get it. I looked at the article source, I really don't get it, it's just html and common sense.

A platform for sharing ad revenue.

They deliver all the amp-ads via that single piece of js, and will share some of the revenue with the publishers. It's not a bad idea after all, if only they had presented it for what it is: a Google fork of the Web. The "performance story" is just the bullshit.

If they're putting ads in custom tags that makes it extremely easy to block them.

I think it's nothing so sinister as a "fork of the web", but a badly thought out approach of going back to faster loading web1.0 by recognizing that quite a lot of JS adds no value to the end user.

My point is that this project is not about providing value to the user. Google could have done that more easily.

It may not be so sinister because it's a badly thought out approach indeed. Although they got quite a few big partners already, this undertake requires rewriting the whole Web which is too much to ask even if you are Google.

It also becomes extremely easy for browser vendors to not allow blocking them.

The closed source ones, perhaps.

Many ad networks are supported already, all will be. There is no rev share at all.

Of course this can't be DoubleClick only.

But please tell us more about the business model, I see you're a Google employee.

Business model is the same as any other content website. Monetization through ads, paywalls, etc.

Same as before, just with happier users including myself. Happy users are good for business in the long term.

You might get it :) There isn't that much to it. AMP is as much about technology as finally getttig that tech adopted. Since AMP is built on web tech there is nothing in it that you cannot chose to do yourself

The problem we are solving is that many sites don't.

So what's with the approach then? Why would websites choose to use AMP (whatever "using AMP" means), when they don't apply common sense in the first place?

Forgive the skepticism but this screams XKCD927.

One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.

With general web content prerendering is pretty dangerous and you certainly cannot do it with say more than 1 doc at a time because it may use arbitrary bandwidth and CPU.

That allows for instant feeling loading of pages (because they are already loaded when the user clicks) which in turn makes users happy :) While all web pages can be fast, AMP allows proving that they are which makes such a feature possible.

A referrer like Twitter or Pinterest or Google could e.g. indicate: Clicks on these links will be super fast (because they are AMP docs). If users click them more (because they like fast) there is a strong incentive for everyone to be fast – and then we all win.

I don't think XKCD927 applies, because we only combine existing standards and restrict ourselves voluntarily to a subset of those. Its still just HTML, CSS, JS. Browsers do not need to change. 't

You're not "combining" standards though. As other comments pointed out, this is not a subset of html. It's a separate spec, based on a subset of html, which is different enough that it's not quite compatible. For example, what's with the amp-prefixed tags? Why amp-img instead of img with data-amp- attributes?

You also didn't address my first point: If you're building this for people who don't make the effort right now, why would they suddenly make a seemingly bigger effort to support something they haven't even heard of before today?

I think the other comments are wrong. Custom elements are a part of the web platform http://www.w3.org/TR/custom-elements/

We use amp-img instead of the img tag to be able to control when resources load (read not load them unless actually needed). Doing this with a different hack like <img data-src="foo"> is possible but a less explicit hack.

To your first point: It might have been just the right point in time, but maybe it isn't. I argue that if adoption is good users will win. It could totally fail, but then it was still worth trying.

In case you haven't tried, check out this video https://www.youtube.com/watch?v=i2_lAEzmOPo&feature=youtu.be I so much want my experience to be like that (or try g.co/ampdemo on your phone yourself).

Good demo. The benefits are indeed attractive, but you still have not sold me on why this is a better approach than ... well, everything that's been suggested in this thread. This stuff is possible without what you're proposing, as you yourself admit. What I see amp giving is a framework in which it is impossible to "mess up", which can be beneficial but I agree with the general sentiment here: New tech has a cost to it. Learning it has a cost. Implementing it in browsers has a massive cost (because I'm sure this will eventually find its way in Chrome, which means Firefox will follow suit, which means a larger potential for technical debt and a higher bar to developing a web browser from scratch).

Like someone else said: If Google wants performance, Google can start aggressively penalizing article-type websites which make unnecessary requests etc. I know you guys already penalize slow sites, so what's wrong with that approach? Especially since such an approach has a much higher chance of actually working.

I totally agree that the "penalizing" approach is important.

But I like to present both a solution "this is how you make it fast" as well as the penalty.

If you only take AMP as a guide or tutorial that puts current best practices in a neat package that is fine with me. We are totally not claiming to have invented a new wheel.

Browsers could do what AMP does (e.g. super lazy prerendering) but I'm an impatient person and I don't like waiting for what a browser with a yearly release cycle might do.

The custom-elements document you linked to is a W3C Working Draft, not a Recommendation. It might someday be part of the Web platform (w.r.t. standardization), but for now it's just under discussion.

It has an implementation in Chrome and Firefox and both Microsoft Edge and the WebKit teams have indicated that they will support it. On top of that there are 2 super excellent polyfills.

In the world of the web platform it doesn't get much more standard than that.

> One of the things that AMP allows is to know that is it save to prerender a page. Documents can be instructed by a viewer to e.g. only load resources visible above the fold and absolutely no external JS.

Which begs the questions: Who prerenders and on what criteria?

Assume page A which has a link to AMP-forked page B.

Does that link need rel=prerender for every browser? Does one need to query the AMP-ness of every page one links to? Does one need to be Googles page cache to link to AMP-pages and get in the benefit of prerendering?

Or is the prerendering implemented in the AMP runtime? Does it only work if page A and page B are both AMP-enhanced?

AMP tags are custom elements, they're not invalid. See http://www.w3.org/TR/custom-elements/

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.

Yes, custom elements are not fully finalized, but all of the browser vendors are invested in the spec and finalizing it. There is a lot of activity on it right now.

> 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.

What annoys me are people who speak out of ignorance without really knowing what they're talking about, but like to give the impression to others they do.

AMP is an open source project any publisher can use and tailor to their needs. If you don't want to factor Google into the solution then you don't have to.

But, keep on praising Facebook because you at least got their agenda right.

> This isn't an "open standard" guys

They never said it was? The web site just says AMP is open source (which it is). It says nothing about standards.

> Google could have easily promoted performance by applying penalties to heavy pages via Page Rank.

They have been since 2010: http://googlewebmastercentral.blogspot.com/2010/04/using-sit...

>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 <amp-ad> and <amp-pixel> that only Google controls.

This is not a Google project.

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

Registrant Fax Ext:

Registrant Email:dns-admin@google.com

The tech lead of the project is Malte Ubl who by their twitter page : @cramforce indicates that "I make www internet web pages for Google. "

Unless it's a 20% off time project (or a side project of some kind), 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.

Yep, I'm a Google employee. ampproject.org has the full list of partners working together. One example is https://blog.twitter.com/2015/introducing-accelerated-mobile...

>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 industry leaders (like Twitter, and lots of others) don't people understand?

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.

Looks like it is https://googleblog.blogspot.dk/2015/10/introducing-accelerat...

Its a joined project by many partners. See other comment in thread for details.

Google's slogan shifted from "don't be evil" to "do the right thing", the former is arguable to say the least based on its records, but moving to the latter is worse, as google can just do the "right" thing for its own benefit, which could be selfish, and blatantly evil sometimes.

> Google's slogan shifted from "don't be evil" to "do the right thing"

False. Google's slogan did not change.

Also the full slogan for Alphabet is "do the right thing – follow the law, act honorably, and treat each other with respect." This cannot be selfish & blatantly evil.

Reply on news.ycombinator.com