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
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YL9Ss-00027Y-Vk
for bitcoin-development@lists.sourceforge.net;
Tue, 10 Feb 2015 11:58:51 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.174 as permitted sender)
client-ip=74.125.82.174; envelope-from=natanael.l@gmail.com;
helo=mail-we0-f174.google.com;
Received: from mail-we0-f174.google.com ([74.125.82.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YL9Sr-0001RE-2m
for bitcoin-development@lists.sourceforge.net;
Tue, 10 Feb 2015 11:58:50 +0000
Received: by mail-we0-f174.google.com with SMTP id w55so1205949wes.5
for <bitcoin-development@lists.sourceforge.net>;
Tue, 10 Feb 2015 03:58:42 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.172.35 with SMTP id az3mr52077086wjc.43.1423569522837;
Tue, 10 Feb 2015 03:58:42 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Tue, 10 Feb 2015 03:58:42 -0800 (PST)
Received: by 10.194.92.208 with HTTP; Tue, 10 Feb 2015 03:58:42 -0800 (PST)
In-Reply-To: <CALkkCJYDUvtuWGQ5Pq85krGQp=bRYQ1sazg-3T0B8ipr8SGuYA@mail.gmail.com>
References: <CAAt2M18H0K99bmD4H_FRSeE+O9nGFDruCmo63GOQt1kxAdVBmQ@mail.gmail.com>
<CAAt2M188whrv9VgV8UYBq+kcmgN9b6QQH7+wd7wQYNj8bd4Pcg@mail.gmail.com>
<CANEZrP2LhgFWWJYQGO+XbDX1o5=hwPtFbE+etEHoQo+3AfUSrA@mail.gmail.com>
<CAAt2M19F2fWj7Ovw_aWvJ5+7osQG6WA=RuT3G+QYiYm-mnNnyg@mail.gmail.com>
<CALkkCJYDUvtuWGQ5Pq85krGQp=bRYQ1sazg-3T0B8ipr8SGuYA@mail.gmail.com>
Date: Tue, 10 Feb 2015 12:58:42 +0100
Message-ID: <CAAt2M182P9BpJ=H1rSGF45qNWii12n1YpKOxnULcPW1L4XLZ+w@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: =?UTF-8?B?TeKStnJ0aW4gSOKStmJv4pOLxaF0aWFr?= <martin.habovstiak@gmail.com>
Content-Type: multipart/alternative; boundary=089e0122e8b6b8d175050eba9bf9
X-Spam-Score: -0.6 (/)
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
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1YL9Sr-0001RE-2m
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Standardizing automatic pre-negotiation
of transaction terms with BIP70? (Emulating Amazon one-click purchase at
all merchants)
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: Tue, 10 Feb 2015 11:58:51 -0000
--089e0122e8b6b8d175050eba9bf9
Content-Type: text/plain; charset=UTF-8
> In what universe is that simple? Your solution: browser extension +
> wallet + comminucation API + all the wallets need to implement it
> Our solution: just browser extension.
Browser extension would only be required until browsers add native support
for detecting the tag and prompting a wallet client. This probably won't
happen in the near future, though.
Also, the kind of browser extension you're talking about would be limited
to just one device or require manually configured syncing between your
devices, and would also likely be limited to just a few platforms.
The communication is done between the wallet and merchant the same as
always with BIP70, but with some extra BIP70 extensions for this purpose.
It just starts talking earlier.
It supports graceful degradation just fine, if the browser or wallet don't
support it or the wallet isn't linked to that computer's browser, then
nothing out of the ordinary happens. The browser extension really don't do
anything special, it just relays the details in the HTML tag.
> > As one example, your browser could ask your hardware wallet over BLE for
> > this data. This way you barely have to trust the computer you're using
at
> > all, as everything it does is confirmed on the hardware wallet before
> > payment (assuming it has a screen, which it should). Linking your
hardware
> > wallet over BLE to new devices which you then use for browsing and
shopping
> > could be trivial and yet allow secure auto-fill of this kind.
>
> This looks more interesting but is information about your location
> really so secret that you need to hold it in HW wallet? Because if so,
> you probably don't want to use untrusted machine anyway. (Or just use
> Qubes OS.)
It isn't necessarily top secret, but why not be protective by default? Your
hardware wallet is already designed to keep secrets. Lets say you're at a
library computer, or at a friend's house, why not let your hardware wallet
deal with all the security?
In this scenario it is likely already functioning as a central point for
all your Bitcoin related purchases anyway, so it might as well be the
device that remembers all your shopping preferences for you. So let's make
it simple to use!
--089e0122e8b6b8d175050eba9bf9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
> In what universe is that simple? Your solution: browser extension +<br=
>
> wallet + comminucation API + all the wallets need to implement it<br>
> Our solution: just browser extension.</p>
<p dir=3D"ltr">Browser extension would only be required until browsers add =
native support for detecting the tag and prompting a wallet client. This pr=
obably won't happen in the near future, though. </p>
<p dir=3D"ltr">Also, the kind of browser extension you're talking about=
would be limited to just one device or require manually configured syncing=
between your devices, and would also likely be limited to just a few platf=
orms. </p>
<p dir=3D"ltr">The communication is done between the wallet and merchant th=
e same as always with BIP70, but with some extra BIP70 extensions for this =
purpose. It just starts talking earlier. </p>
<p dir=3D"ltr">It supports graceful degradation just fine, if the browser o=
r wallet don't support it or the wallet isn't linked to that comput=
er's browser, then nothing out of the ordinary happens. The browser ext=
ension really don't do anything special, it just relays the details in =
the HTML tag. </p>
<p dir=3D"ltr">> > As one example, your browser could ask your hardwa=
re wallet over BLE for<br>
> > this data. This way you barely have to trust the computer you'=
;re using at<br>
> > all, as everything it does is confirmed on the hardware wallet be=
fore<br>
> > payment (assuming it has a screen, which it should). Linking your=
hardware<br>
> > wallet over BLE to new devices which you then use for browsing an=
d shopping<br>
> > could=C2=A0 be trivial and yet allow secure auto-fill of this kin=
d.<br>
><br>
> This looks more interesting but is information about your location<br>
> really so secret that you need to hold it in HW wallet? Because if so,=
<br>
> you probably don't want to use untrusted machine anyway. (Or just =
use<br>
> Qubes OS.)</p>
<p dir=3D"ltr">It isn't necessarily top secret, but why not be protecti=
ve by default? Your hardware wallet is already designed to keep secrets. Le=
ts say you're at a library computer, or at a friend's house, why no=
t let your hardware wallet deal with all the security?</p>
<p dir=3D"ltr">In this scenario it is likely already functioning as a centr=
al point for all your Bitcoin related purchases anyway, so it might as well=
be the device that remembers all your shopping preferences for you. So let=
's make it simple to use! </p>
--089e0122e8b6b8d175050eba9bf9--
|
