cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kerri Shotts <>
Subject Re: [iOS] proposed major whitelist change
Date Wed, 26 Aug 2015 14:59:44 GMT
+1; sounds like a good change to me! :)

Kerri Shotts , photoKandy Studios LLC • @photokandy 


This email and any attachments may be confidential. If you are not the intended recipient,
please let us know by replying to this message, and then remove the message and its attachments
from your system. You should not disseminate, distribute, or otherwise copy or release the
information contained herein, nor can we accept any liability for any loss or damages resulting
from the use, abuse, or mis-use of the information contained herein.


Computer viruses can be distributed via email. It is the recipient’s responsibility to check
this email and any attachments for viruses. Email transmission cannot be guaranteed to be
secure or error-free as the email could have been intercepted, corrupted, delayed, and/or
re-transmitted. The sender does not accept any liability for errors or omissions within this
message or its attachments, nor for any viruses which may be present.

Note: We do our very best to ensure that nothing we send contains viruses. However, because
of the nature of email and the way it is sent, we can’t promise that some other party hasn’t
intercepted our email and added malicious content. Due to the nature of email, we can’t
accept any liability for any damage or loss arising from the use, abuse, or mis-use of this
email and any of its attachments.


Email is not a secure communications medium. When replying to this or any message, you should
not include any information that you do not want the entire world to be capable of seeing.
In other words, don’t send financial accounts (CC#s, Bank Account #s, etc.), passwords,
social security numbers, or the like, even when asked directly. photoKandy Studios LLC will
never  ask you for this information.

Information transmitted via email may be intercepted and retransmitted by any number of other
entities. This is the nature of email, and as such, we can’t be held liable for any loss
or damage incurred by replying to this message with compromising information. Review your
message prior to sending it, and ensure that there is no information you wouldn’t be comfortable
with the entire world knowing.

On Wed, Aug 26, 2015 at 6:14 AM -0700, "Shazron" <> wrote:

Any objections or further feedback? If not I will move on to what we seem
to have consensus about:

If there are no  entries, then network requests are wide open
(wildcard * default) and security is handled via CSP.
We would recommend no  entries to be used, users should use CSP.

On Tue, Aug 11, 2015 at 7:01 PM, Shazron  wrote:

> So, is the whitelist plugin network request list "*" with no 
>> entries, or
>> "*" because of the  entry added to the default project?
> "*" would be the default. So if there are no  entries, it would be
> added. If the default project had the  wildcard, then no change
> (since that is the default anyway).
> The old way you would need an explicit  entry wildcard for
> unrestricted native and web code access -- the new way is unrestricted
> native code access (unless set explicitly), and CSP for web code access.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message