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 ) 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 ; 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: References: Date: Tue, 10 Feb 2015 12:58:42 +0100 Message-ID: From: Natanael To: =?UTF-8?B?TeKStnJ0aW4gSOKStmJv4pOLxaF0aWFr?= 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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


> 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 pr= obably 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 platf= orms.

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.

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.

> > As one example, your browser could ask your hardwa= re 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 be= fore
> > payment (assuming it has a screen, which it should). Linking your= hardware
> > wallet over BLE to new devices which you then use for browsing an= d shopping
> > could=C2=A0 be trivial and yet allow secure auto-fill of this kin= d.
>
> 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 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?

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!

--089e0122e8b6b8d175050eba9bf9--