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 <e...@rtfm.com> 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 distributing the list of misbehaving sites to clients. >> > > I think I did not explain it well. It would be a black list on site level > and it would not be centralised but distributed. > I had understood your point that it would be centrally organized but democratically decided and then distributed to users. The idea is that is a site is harmful for the user, all their permissions > should be revoked and we shuold communicate the user why this site is > harmful. The list of misbehaving sites, the reasons of why them are > dangerous and the evidence supporting misbehaving should be in a > cross-browser distrubuted DB. > Yes, I understood that. As Jonathan notes, Firefox already has a mechanism for doing #2, which is >> to say >> "Safe Browsing". Now, Safe Browsing is binary, either a site is good or >> bad, but >> specific APIs aren't disabled, but it's easy to see how you would extend >> it to that >> if you actually wanted to provide that function. I'm not sure that's >> actually >> very attractive--it's hard enough for users to understand safe browsing. >> Safe >> Browsing is of course centralized, but that comes with a number of >> advantages >> and it's not clear what the advantage of decentralized blacklist >> dissemination >> is, given the networking realities. >> >> You posit a mechanism for forming the list of misbehaving sites, but >> distributed >> reputation is really hard, and it's not clear that Google is actually >> doing a bad >> job of running Safe Browsing, so given that this is a fairly major >> unsolved problem, >> I'd be reluctant to set out to build a mechanism like this without a >> pretty clear >> design. >> > > I've been looking at this paper on prediction markets based on BitCoin > <http://bravenewcoin.com/assets/Whitepapers/Augur-A-Decentralized-Open-Source-Platform-for-Prediction-Markets.pdf> > for inspiration. It is true that distributed reputation is a hard problem > but I think we could adapt the concepts on that paper to this scenario if > reviewers "bet" on site reputation and there is some incentive. Of course, > further research is needed to mitigate the chance for a reviewer to lie in > its report and prevent forms of Sybil attack but it seems to be some > solutions out there. > As I said, we have mechanisms that seem to me to be doing a fairly adequate job at this general class of problem, with the major drawback being that they are centralized. I'm not saying that that couldn't be addressed, but it doesn't seem like such a solution is ready to hand. As such, this seems like it is fairly far outside the realm of anything Firefox would do in in the short to medium term. -Ekr > >> >> -Ekr >> >> >> >> >> >> >> >> On Tue, Mar 21, 2017 at 2:40 PM, Salvador de la Puente < >> sdelapue...@mozilla.com> wrote: >> >>> 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 help finding new security threats >>> such a >>> tracking or fingerprinting algorithms by encouraging the honest report of >>> evidences, somehow. >>> >>> With this system, the threat is considered the result of both potential >>> risk and chances of actual misuse. The revocation protocol reduces >>> threatening situations by minimising the number of Web properties abusing >>> the APIs. >>> >>> As a side effect, it provides the infrastructure for a real distributed >>> and >>> cross browser database which can be of utility for other unforeseen uses. >>> >>> What do you think? >>> >>> >>> El 8 mar. 2017 10:54 p. m., "Jonathan Kingston" <jkings...@mozilla.com> >>> escribió: >>> >>> 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, Salvador de la Puente < >>> sdelapue...@mozilla.com> wrote: >>> >>> > 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 for origins >>> > abusing those APIs. >>> > >>> > I published the idea on GitHub [1] and I was wondering about the >>> utility >>> > and feasibility of such a system so I would thank any feedback you >>> want to >>> > provide. >>> > >>> > I hope it will be of interest for you. >>> > >>> > [1] https://github.com/delapuente/revocation-protocol >>> > >>> > -- >>> > <salva /> >>> > _______________________________________________ >>> > dev-platform mailing list >>> > dev-platform@lists.mozilla.org >>> > https://lists.mozilla.org/listinfo/dev-platform >>> > >>> _______________________________________________ >>> dev-platform mailing list >>> dev-platform@lists.mozilla.org >>> https://lists.mozilla.org/listinfo/dev-platform >>> >> >> > > > -- > <salva /> > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
