In a manifest version that already has most professional extension developers panicking to try to find workarounds for communication holes and missing features, you're proposing * a fundamental break in how content scripts work: ![]() Something being useful does not justify the continued existence of a security hole. Where functionality is dangerous, or has a history of being misused (as in this case), it forms a strong argument to fix or replace. Web or content scripts can use window.postMessage with a targetOrigin of "*" to broadcast to every listener, but this is discouraged, since an extension cannot be certain the origin of such messages, and other listeners (including those you do not control) can listen in.īeing able to think of one specific scenario where something can be misused isn't sufficient to justify removing that piece from the platform. Place as little trust in messages from the DOM as possible. Origin and source validation are a necessity, but even still, messages could come from JavaScript that was inserted into a page via XSS, via another malicious Chrome extension, etc. This proposed deprecation presupposes that an alternative mechanism be in place for this functionality.Įxamples where security issues have been highlighted: It is proposed that any script that that is not in a position to identify the origin of that script, for example content scripts, be excluded from receiving messages via window.postMessage(). The problem this creates is that web extension developers and webpage developers are being invited to broadcast potentially private information to potentially hostile code. This broadcasts a message to anyone who wants to listen. Right now, the only cross platform way for a content script and a webpage to communicate with each other is using the window.postMessage(message, '*') function.
0 Comments
Leave a Reply. |