1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WjnTI-0001Be-UL
for bitcoin-development@lists.sourceforge.net;
Mon, 12 May 2014 10:28:36 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.53 as permitted sender)
client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f53.google.com;
Received: from mail-oa0-f53.google.com ([209.85.219.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WjnTH-0004Yu-7S
for bitcoin-development@lists.sourceforge.net;
Mon, 12 May 2014 10:28:36 +0000
Received: by mail-oa0-f53.google.com with SMTP id m1so7947665oag.40
for <bitcoin-development@lists.sourceforge.net>;
Mon, 12 May 2014 03:28:29 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.236 with SMTP id ox12mr1701234oeb.81.1399890509480;
Mon, 12 May 2014 03:28:29 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.162 with HTTP; Mon, 12 May 2014 03:28:29 -0700 (PDT)
In-Reply-To: <CALKy-wq6FZs39KX-gk2PizEEikLvHhxMkt=OT61fcUchsaLpfg@mail.gmail.com>
References: <CALKy-wq6FZs39KX-gk2PizEEikLvHhxMkt=OT61fcUchsaLpfg@mail.gmail.com>
Date: Mon, 12 May 2014 12:28:29 +0200
X-Google-Sender-Auth: YG471RO4VKICh1Q3Su_8rI-0QMw
Message-ID: <CANEZrP0Ea-goS-Ba58z62E4cv5QKvYzbOkwT0JJPaXLniE_m5g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Alness <andy@coinbase.com>
Content-Type: multipart/alternative; boundary=047d7b41cd288acbd204f93168f6
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WjnTH-0004Yu-7S
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Allow cross-site requests of payment
requests
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 12 May 2014 10:28:37 -0000
--047d7b41cd288acbd204f93168f6
Content-Type: text/plain; charset=UTF-8
>
> Would it be a terrible idea to amend BIP 70 to suggest implementors
> include a "Access-Control-Allow-Origin: *" response header for their
> payment request responses? I don't think this opens up any useful attack
> vectors.
>
It sounds OK to me, although we should all sleep on it for a bit. The
reason this header exists is exactly because mobile code fetching random
web resources can result in surprising security holes.
For this to be useful, someone would have to actually want to fully
implement the payment protocol (with its own root cert store, ASN.1
parsing, RSA etc) in browser-sandboxed Javascript rather than just
providing a real app for people to download.
Is that really going to be popular, though? I think it's unclear.
--047d7b41cd288acbd204f93168f6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">Would it be a terrible idea to =
amend BIP 70 to suggest implementors include a "Access-Control-Allow-O=
rigin: *" response header for their payment request responses? I don&#=
39;t think this opens up any useful attack vectors.</div>
</blockquote><div><br></div><div>It sounds OK to me, although we should all=
sleep on it for a bit. The reason this header exists is exactly because mo=
bile code fetching random web resources can result in surprising security h=
oles.=C2=A0</div>
<div><br></div><div>For this to be useful, someone would have to actually w=
ant to fully implement the payment protocol (with its own root cert store, =
ASN.1 parsing, RSA etc) in browser-sandboxed Javascript rather than just pr=
oviding a real app for people to download.</div>
<div><br></div><div>Is that really going to be popular, though? I think it&=
#39;s unclear.</div></div></div></div>
--047d7b41cd288acbd204f93168f6--
|
