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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; 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: <op.xb09eip8yldrnw@laptop-air> References: <op.xb05iptvyldrnw@laptop-air> <CA+s+GJBD-L8Lz+dsEgL+_xzJbrqjC7z_9Z45ow=xoccxwEdssQ@mail.gmail.com> <op.xb09eip8yldrnw@laptop-air> Date: Sun, 2 Mar 2014 11:37:48 +0100 X-Google-Sender-Auth: tzdT3Mdk_aE1h_2umKcYuWy3HlA Message-ID: <CANEZrP3V+AhoMwq=UmatrhF19cswVm3LX19PwqrURPFqnTw-Xg@mail.gmail.com> From: Mike Hearn <mike@plan99.net> To: Jeremy Spilman <jeremy@taplink.co> 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" <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: <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: 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 <jeremy@taplink.co> wrote: > On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir <laanwj@gmail.com> 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 <div dir=3D"ltr">I'm hoping I can convince Saivann to do a bit of graph= ics work for this at some point :-)<div><br></div><div>Something like a gre= en stamp that appears (like a watermark) in the background, might be good.<= /div> </div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,= Mar 1, 2014 at 8:50 AM, Jeremy Spilman <span dir=3D"ltr"><<a href=3D"ma= ilto:jeremy@taplink.co" target=3D"_blank">jeremy@taplink.co</a>></span> = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><u></u> <div><div class=3D"">On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir <<a hr= ef=3D"mailto:laanwj@gmail.com" target=3D"_blank">laanwj@gmail.com</a>> w= rote:<br><br><blockquote style=3D"margin:0 0 0.80ex;border-left:#0000ff 2px= solid;padding-left:1ex"> 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.</bloc= kquote> <br></div><div>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'.</div><div><br></div><div>But if there's no ce= rt then all you have is memo.</div> <div><br></div><div>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</div> <div><br></div><div><br></div></div><br>-----------------------------------= -------------------------------------------<br> Flow-based real-time traffic analytics software. Cisco certified tool.<br> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer<br> Customize your own dashboards, set traffic alerts and generate reports.<br> Network behavioral analysis & security monitoring. All-in-one tool.<br> <a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D126839071&iu= =3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam= pad/clk?id=3D126839071&iu=3D/4140/ostg.clktrk</a><br>__________________= _____________________________<br> Bitcoin-development mailing list<br> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= pment@lists.sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= " target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment</a><br> <br></blockquote></div><br></div> --001a11c1fbba24f55904f39d43ab--