361–370 of 381 posts
Yes this has been a big issue for a very long time now. Google wants to push a release where it will display the hostname of the amp site even if the content is being served from google.com[1]. Mozilla (and Apple) are strictly against it and thank god for Mozilla. If Google had a bigger market share this would already be something we would have been living with. I'm sure there are better sources for this, but here is…
Earlier quoted context omitted.
I am conflicted Yes, AMP is an anti-competitive move by Google At the same time AMP is "faster" because it gets rid of all the nagware and JS crap that the original page has. So yeah, I don't like what Google is doing but I don't like what NYT is doing neither
> AMP is "faster" because it gets rid of all the nagware and JS crap that the original page has. AMP is faster only for poorly-optimized JS-heavy pages but the design is fundamentally flawed to require all of its own large amount of JavaScript to run before anything displays, whereas most of the traditional bloat doesn’t block rendering. That means any optimized page - Washington Post, NYT, etc. – loads noticeably fa…
Earlier quoted context omitted.
>"community driven" This concern has been raised time again with every major Google open-source project e.g. Android, Chromium, Golang etc. and that concerns have helped improve certain aspects of the project. But, I wonder whether a huge corporate like Google can build such large scale projects without such criticism, if the the project needs to be successful they to gain from it after-all they are investing their e…
> But, I wonder whether a huge corporate like Google can build such large scale projects without such criticism Yes: they could at least develop large projects in a foundation with many other companies > And them being invested in it, is a major reason for adoption by other parties and resulting in a successful open-source project. ...and the main source of pain when the projects are "pivoted" or just dropped due to…
IMO, we're the reason it failed. We as a consumer didn't buy FirefoxOS phone over Android, iOS. We haven't adopted Firefox browser enough for it to become have the major market share. The same argument can levelled against any proprietary product VS open-source product.
That proves my point, being 'completely community driven' open-source project isn't the only criteria for the success of a project.
Earlier quoted context omitted.
By reading the source code? def divisors(n): for d in range(1, n): if n % d == 0: yield d n = 1 while True: if n == sum(divisors(n)): break n += 2 print(n) I don’t know if this program halts. But I’m pretty sure it won’t steal my data and send it to third parties. Why? Because at no point does it read my data or communicate with third parties in any way: it would have to have those things programmed into it for that…
> at no point does it read my data Tracking doesn't require reading any of your data. All that is necessary is to trigger some kind of signal back to Google's servers on whatever user behavior they are interested in tracking. > or communicate with third parties Third parties like Google? Which is kind of the point? > [example source code] Of course you can generate examples that are trivial to inspect. Real world pro…
Earlier quoted context omitted.
Could Google give specific persons different versions or is technically impossible?
Technically yes, but not very practically. The domain is cookieless, so it would be difficult to even identify a specific user, other than by IP. Also, the JavaScript resource is delivered from the cache with a 1 year expiry, which means most times it's loaded it will be served from browser cache rather than the web.
People have been railing against Google's Amp on HN for years, and I think I finally figured out what it's for. It's Google way of combatting phone apps. If all of the world's information — especially current news and similar information — moves from the open web into apps, then Google can no longer crawl, index, or scrape that information for its own use. The rise of the mobile phone app is a threat to Google on so…
Earlier quoted context omitted.
Does NYTimes' use of Fastly subvert the meaning of the URL by literally covering it up in the address bar? Nope? Not the same thing, then. Personally I don't think there's anything wrong with the fundamental concept of signed exchanges. The only problem is that it's just that: a signed exchange of content, which should have nothing to do with the domain name authority in the URL. By all means, display "Content from:…
> the meaning of the URL The issue is that the technical meaning of the URL is very far from what most user think of. Is the URL an address for NYT's server? Not really because you are actually hitting Fastly's server. So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"? We can have a…
My argument is not really concerned with what most users think of, but humor me, what do they think of?
> So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"?
Yes, because HTTP/S scheme URLs have a definition that implies a meaning, which is subverted when you create exceptions to that meaning. NYT setting up a "magical" DNS config that resolves to some third party server is perfectly fine by that definition, and resolving one FQDN while displaying another is not. It's not sudden, this standard has existed in one form or another since 1994.
> We can have a real discussion of what the meaning of a URL is
Yeah, let's do that instead of harping on about what's fair and unfair. It's not a matter of fairness, it's a matter of standardized definitions. By all means, create a new "amp:" URI scheme where the naming authority refers to whoever signed the data and resolves to your favorite AMP cache, but don't call it http or https.
They could argue that Google is using The New York Times's branding and domain name to make it look like this content is controlled and provided by The New York Times, when in fact it isn't, and that an average person (“idiot in a hurry”) could be deceived.
If The New York Times willingly gives Google permission (or The New York Times willingly abets Google's monopoly position), then I guess Google can do whatever they like.
Earlier quoted context omitted.
For most JS served by CDN, you can (and should) use Subresource Integrity to verify the content. At least the last time I was involved in an AMP project, Google considered AMP to be an "evergreen" project and did not allow publishers to lock in to a specific version.
Long term versions are now supported, so publishers can lock in a specific version. Publisher hosted copies are in the pipeline, as I referenced in the parent comment. My choice of verbiage was a bit confusing it appears.
AMP's documentation seems to indicate that the LTS is stable only for one month (new features released via the same URL each month), and so is not compatible with SRI (see https://github.com/ampproject/amphtml/blob/master/contributi...)
You can specify a version (ie, https://cdn.ampproject.org/rtv/somenum/v0.js), but the AMP validator complains about that.
Earlier quoted context omitted.
> the meaning of the URL The issue is that the technical meaning of the URL is very far from what most user think of. Is the URL an address for NYT's server? Not really because you are actually hitting Fastly's server. So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"? We can have a…
> The issue is that the technical meaning of the URL is very far from what most user think of. My argument is not really concerned with what most users think of, but humor me, what do they think of? > So when NYT sets up a magical DNS config, it suddenly is fine, but using crypto to sign the package and serve it on a CDN that way, then it's suddenly "subverting the meaning of the URL"? Yes, because HTTP/S scheme URLs…
An example of where this occurs today is caching. You could be hitting a cache anywhere along the way. Hell you could be seeing an "offline" version, but the website would still show you the "address" of the content.
This is no different, you're hitting a different cache, but the "URL" you see is the canonical address of the content you are looking at, not where it was actually fetched from.