I think it would be acceptable to explore a path that didn't allow the HTML page to run any JS, and restricted it to a worker.
-
-
Replying to @wycats @cramforce
i'm not optimistic that workers will be resistant to fingerprinting: https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas …
1 reply 0 retweets 0 likes -
Replying to @lawnsea @cramforce
Deferring JS until actual rendering might be a better approach.
1 reply 0 retweets 0 likes -
Replying to @wycats @cramforce
yep, but then the perf guarantees are far weaker. hmm this is an interesting one.
1 reply 0 retweets 0 likes -
Replying to @lawnsea @cramforce
The real issue is AMP circumvents this issue by centralizing allowed JS through approved (but nonstandard) WCs.
1 reply 0 retweets 0 likes -
You can't make AMP work with just platform features, and Google isn't willing to trust "just anyone" with the power of JS, so here we are
2 replies 0 retweets 0 likes -
The answer really cannot be "we trust Google to vet all JS that works in this context".
1 reply 0 retweets 0 likes -
Replying to @wycats @cramforce
right. nor is the answer "eventually all sites are amp" i think the amp team is acting in good faith. i wish there was more transparency.
2 replies 0 retweets 0 likes -
Replying to @lawnsea @cramforce
I've said so repeatedly. But the amount of concentrated power makes it easy for bad outcomes to slip through the cracks.
1 reply 0 retweets 0 likes -
AMP defers to search policy as out of scope for OSS project repeatedly.
2 replies 0 retweets 0 likes
I don't think they're acting in bad faith, but there's too much complexity around various levers of power for ppl to get it right.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.