Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WK3mN-00031a-2X for bitcoin-development@lists.sourceforge.net; Sun, 02 Mar 2014 10:37:55 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.180 as permitted sender) client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f180.google.com; Received: from mail-ob0-f180.google.com ([209.85.214.180]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WK3mM-0006P6-31 for bitcoin-development@lists.sourceforge.net; Sun, 02 Mar 2014 10:37:55 +0000 Received: by mail-ob0-f180.google.com with SMTP id wn1so148211obc.25 for ; Sun, 02 Mar 2014 02:37:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.33.35 with SMTP id o3mr22415465obi.15.1393756668750; Sun, 02 Mar 2014 02:37:48 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.71.231 with HTTP; Sun, 2 Mar 2014 02:37:48 -0800 (PST) In-Reply-To: References: Date: Sun, 2 Mar 2014 11:37:48 +0100 X-Google-Sender-Auth: tzdT3Mdk_aE1h_2umKcYuWy3HlA Message-ID: From: Mike Hearn To: Jeremy Spilman Content-Type: multipart/alternative; boundary=001a11c1fbba24f55904f39d43ab 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: 1WK3mM-0006P6-31 Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Positive and negative feedback on certificate validation errors 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: Sun, 02 Mar 2014 10:37:55 -0000 --001a11c1fbba24f55904f39d43ab Content-Type: text/plain; charset=UTF-8 I'm hoping I can convince Saivann to do a bit of graphics work for this at some point :-) Something like a green stamp that appears (like a watermark) in the background, might be good. On Sat, Mar 1, 2014 at 8:50 AM, Jeremy Spilman wrote: > On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir wrote: > > Such a thing would be interesting for a future BIP standard. I see one > problem here: for an unsigned payment request there isn't really an > "origin". Browser URI handlers don't send the referrer either. > > > Yeah, good point. If you have a cert, we have the CN from the cert, which > becomes the string displayed as 'Pay To' and alternatively 'Merchant'. > > But if there's no cert then all you have is memo. > > So the best way to differentiate signed requests is by prominently > displaying that Merchant string. Really the green part should just be the > 'Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that > would make the lack of certificate highly apparent. > > > > > ------------------------------------------------------------------------------ > Flow-based real-time traffic analytics software. Cisco certified tool. > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > Customize your own dashboards, set traffic alerts and generate reports. > Network behavioral analysis & security monitoring. All-in-one tool. > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --001a11c1fbba24f55904f39d43ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm hoping I can convince Saivann to do a bit of graph= ics work for this at some point :-)

Something like a gre= en stamp that appears (like a watermark) in the background, might be good.<= /div>


On Sat,= Mar 1, 2014 at 8:50 AM, Jeremy Spilman <jeremy@taplink.co> = wrote:
On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir <laanwj@gmail.com> w= rote:

Such a thing would be interesting for a future BIP standard. I see one prob= lem here: for an unsigned payment request there isn't really an "o= rigin". Browser URI handlers don't send the referrer either.
Yeah, good point. If you have a cert, we have the CN from th= e cert, which becomes the string displayed as 'Pay To' and alternat= ively 'Merchant'.

But if there's no ce= rt then all you have is memo.

So the best way to differentiate signed requests is by = prominently displaying that Merchant string. Really the green part should j= ust be the 'Pay To' line, the rest is content. If it showed a BLANK= 'Pay To' that would make the lack of certificate highly apparent.= =C2=A0



-----------------------------------= -------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gam= pad/clk?id=3D126839071&iu=3D/4140/ostg.clktrk
__________________= _____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11c1fbba24f55904f39d43ab--