<oembed><type>rich</type><version>1.0</version><author_name>npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs</author_name><author_url>https://nostr.ae/npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2012-11-26&#xA;📝 Original message:On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:&#xA;&gt; They could be included as well of course, but from a seller&#xA;&gt; perspective the most important thing is consistency. You have to be&#xA;&gt; able to predict what CAs the user has, otherwise your invoice would&#xA;&gt; appear in the UI as unverified and is subject to manipulation by&#xA;&gt; viruses, etc.&#xA;&#xA;That&#39;s expected behaviour - except it&#39;s mainly be manipulated by *users*, not &#xA;viruses (which can just as easily manipulate whatever custom cert store we &#xA;use). If I don&#39;t trust Joe&#39;s certs, I don&#39;t want Bitcoin overriding that no &#xA;matter who Joe is or what connections he has.&#xA;&#xA;&gt; So using the OS cert store would effectively restrict merchants to the&#xA;&gt; intersection of what ships in all the operating systems their users&#xA;&gt; use, which could be unnecessarily restrictive. As far as I know, every&#xA;&gt; browser has its own cert store for that reason.&#xA;&#xA;Browsers with this bug are not relevant IMO.</html></oembed>