Richard,
The WHATWG mailing list is actually not an appropriate place for either
this kind of e-mail (I'm not even really sure what this e-mail was supposed
to be... are you an implementor?) nor your other recent e-mail (voting for
a feature doesn't help in the WHATWG, all that matters is the
Personally. I'd vote for endpoint mapping to be done in the Message Service
with Topic based subscriptions. Just like GCM/GCM, Amazon, Apple, and
Microsoft support.
On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters
wrote:
>
> Right now the specification for window.opener() is seriously insecure,
> allowing for cross-domain script access by default.
>
I believe that's a bit of an overstatement. There are certainly risks
involved in
On 11/30/2016 05:23 PM, Ian Hickson wrote:
On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters
wrote:
Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by default.
I believe that's a bit of an
On 11/30/2016 06:21 PM, Michael A. Peters wrote:
On 11/30/2016 05:23 PM, Ian Hickson wrote:
On Wed, Nov 30, 2016 at 4:49 PM Michael A. Peters
wrote:
Right now the specification for window.opener() is seriously insecure,
allowing for cross-domain script access by
https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
3.2. Priority of Constituencies
In case of conflict, consider users over authors over implementors over
specifiers over theoretical purity. In other words costs or difficulties
to the user should be given more weight
I guess this issue was discussed at the following thread on chromium.org,
with comment #10 offering the more interesting exploit vector that seems to
happen on sites with user-generated content (UGC):
https://bugs.chromium.org/p/chromium/issues/detail?id=168988#c10
... and Comment 11 right after
On 12/1/16 1:41 AM, Chris Holland wrote:
I think the devil would be in implementation detail. Slapping a
"rel/noopener" attribute on a specific link is very deterministic and
straightforward from a logic standpoint Whichever window was created
from this link can't control the parent.
It's
Hello.
I'm writing about arithmetic coded JPEG support. Historically, it wasn't
supported by browsers due patents. But all of these patents are expired
several years ago, and modern libjpeg, libjpeg-turbo and mozjpeg have
optional support of the arithmetic coding.
Arithmetic coded JPEG support