Re: Revocation protocol idea

2017-03-31 Thread Salvador de la Puente
Hi Johann On Thu, Mar 23, 2017 at 6:37 PM, Johann Hofmann wrote: > Hey, > > concerns about the viability of such a decentralized systems aside, I > still don't understand the advantage of blocking on an API level vs. simply > showing the SafeBrowsing error page that we

Re: Revocation protocol idea

2017-03-31 Thread Salvador de la Puente
Hi Jonathan On Thu, Mar 23, 2017 at 9:09 AM, Jonathan Kingston wrote: > This seems a little like the idea WOT(https://www.mywot.com/) had, > Showing the user that they might be looking at a website that isn't > considered great but isn't perhaps bad enough to be blocked.

Re: Revocation protocol idea

2017-03-31 Thread Eric Rescorla
On Fri, Mar 31, 2017 at 4:20 AM, Salvador de la Puente < sdelapue...@mozilla.com> wrote: > Hi Eric > > On Wed, Mar 22, 2017 at 6:11 AM, Eric Rescorla wrote: > >> There seem to be three basic ideas here: >> >> 0. Blacklisting at the level of API rather than site. >> 1. Some

Re: Revocation protocol idea

2017-03-31 Thread Salvador de la Puente
Hi Eric On Wed, Mar 22, 2017 at 6:11 AM, Eric Rescorla wrote: > There seem to be three basic ideas here: > > 0. Blacklisting at the level of API rather than site. > 1. Some centralized but democratic mechanism for building a list of > misbehaving sites. > 2. A mechanism for

Re: Revocation protocol idea

2017-03-23 Thread Johann Hofmann
Hey, concerns about the viability of such a decentralized systems aside, I still don't understand the advantage of blocking on an API level vs. simply showing the SafeBrowsing error page that we currently have in place. Why would we continue to allow a user to visit a clearly harmful page?

Re: Revocation protocol idea

2017-03-22 Thread Jonathan Kingston
This seems a little like the idea WOT(https://www.mywot.com/) had, Showing the user that they might be looking at a website that isn't considered great but isn't perhaps bad enough to be blocked. I agree that one web actor owning this power isn't a great place to be in and that in itself might be

Re: Revocation protocol idea

2017-03-21 Thread Eric Rescorla
There seem to be three basic ideas here: 0. Blacklisting at the level of API rather than site. 1. Some centralized but democratic mechanism for building a list of misbehaving sites. 2. A mechanism for distributing the list of misbehaving sites to clients. As Jonathan notes, Firefox already has

Re: Revocation protocol idea

2017-03-21 Thread Salvador de la Puente
Hi Jonathan In the short and medium terms, it scales better than a white list and distributes the effort of finding APIs misuses. Mozilla and other vendor browser could still review the code of the site and add its vote in favour or against the Web property. In the long term, the system would

Re: Revocation protocol idea

2017-03-08 Thread Jonathan Kingston
Hey, What would be the advantage of using this over the safesite list? Obviously there would be less broken sites on the web as we would be permitting the site to still be viewed by the user rather than just revoking the permission but are there other advantages? On Sun, Mar 5, 2017 at 4:23 PM,

Revocation protocol idea

2017-03-05 Thread Salvador de la Puente
Hi, folks. Some time ago, I've started to think about an idea to experiment with new powerful Web APIs: a sort of "deceptive site" database for harmful uses of browsers APIs. I've been curating that idea and come up with the concept of a "revocation protocol" to revoke user granted permissions