RE: An interesting take on AMP versus PWP

Yes, Baldur is correct that we have not looked into security for our model yet. We know that it is a gaping hole. We also have not yet written a spec for PWP. I hope that Baldur (we know you’re watching) will be okay with our using this blog post to assist in writing robust use cases for security for PWP.

Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Alan Stearns [mailto:stearns@adobe.com]
Sent: Wednesday, March 30, 2016 2:44 PM
To: Nick Ruffilo; Bill Kasdorf
Cc: public-digipub-ig@w3.org
Subject: Re: An interesting take on AMP versus PWP

Further elaboration of Baldur’s position:

https://www.baldurbjarnason.com/notes/some-notes-on-security/


From: Nick Ruffilo <nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>>
Date: Wednesday, March 30, 2016 at 10:44 AM
To: Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>>
Cc: Alan Stearns <stearns@adobe.com<mailto:stearns@adobe.com>>, "public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>" <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Subject: Re: An interesting take on AMP versus PWP

I realize that AMP might simply be a 3-letter acronym that people just nod their head to - so hopefully I can explain a bit more about what AMP is.

AMP has the outward goal of creating extremely high-performance content (little/no javascript, low filesize) that can be delivered quickly.  While there are some political issues around why they do this - the goal of an AMP page is to deliver a snippet of content extremely quickly to a user from a search on a device that has low-connectivity extremely quickly.

AMP does that VERY well - at the cost of doing anything else.  It's goal is to strip content down to content itself - removing most of the chrome/navigation/interaction of a website to deliver content to mobile devices quickly - especially in low-connectivity situations.

The following article talks about some of the good/bads of AMP. http://www.wired.com/2016/02/googles-amp-speeding-web-changing-works/


-Nick

On Wed, Mar 30, 2016 at 10:04 AM, Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>> wrote:
This is also an example of the common confusion between "document" and "publication." Simply recognizing the issues around a "publication" as distinct from a simple "document" immediately reveals that AMP and PWP are apples and banquets. ;) AMP is basically a profile of HTML, mainly a subsetting. I don't see any reason why a content document in a PWP couldn't conform to AMP and thereby load and render faster. There is no conflict here, imo.—Bill Kasdorf

From: Nick Ruffilo [mailto:nickruffilo@gmail.com<mailto:nickruffilo@gmail.com>]
Sent: Tuesday, March 29, 2016 8:57 PM
To: Alan Stearns
Cc: public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>
Subject: Re: An interesting take on AMP versus PWP

I think it's worth noting that AMP could be considered a portable document format for sorts but by NO MEANS is it a complete or fully functional document that we hope to scope out with PWP.

It would be interesting for us to look at how AMP solves a few issues - but I really don't think it answers much - it just limits functionality to ensure high-performance (speed).

There are some interesting overviews and resources on AMP (https://www.ampproject.org/) but I personally disagree very strongly with Baldur's last paragraph (which sadly seems to be a theme - i like most of what Baldur says and then in his last paragraph he jumps the shark in a way that leaves me blinking...)

-Nick

On Tue, Mar 29, 2016 at 6:39 PM, Alan Stearns <stearns@adobe.com<mailto:stearns@adobe.com>> wrote:
I don’t know enough about AMP to evaluate this, but thought I should pass it on.

Thanks,

Alan

(an attempt to quote twitter in email)

https://twitter.com/fakebaldur/status/714941460416741376



Baldur Bjarnason
‏@fakebaldur

> An interesting side-effect of AMP's basic model is
> that anybody can run an AMP CDN and, because behaviour
> is well-defined, customise it
>
> If you have an app/platform & would like to control
> the performance or representation of AMP pages linked
> from it, you could do your own CDN
>
> That includes anything from aggressively pre-loading
> linked AMP pages to tweaking how its custom elements
> behave.
>
> By sub-setting HTML and limiting JS behaviour to a
> strictly defined set of custom elements, Google has
> effectively created portable web docs
>
> Which basically makes most of what the W3C's Digital
> Publishing Interest Group is working on, a modern
> XHTML2 to Google AMP's HTML5



--
- Nick Ruffilo
@NickRuffilo
Aer.io<http://Aer.io> an INGRAMcompany




--
- Nick Ruffilo
@NickRuffilo
Aer.io<http://Aer.io> an INGRAM company