Hi Jonathan On Thu, Mar 23, 2017 at 9:09 AM, Jonathan Kingston <jkings...@mozilla.com> 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. > Yes. I talk about it in https://salvadelapuente.com/posts/2016/07/29/towards-the-web-of-trust/ > > I agree that one web actor owning this power isn't a great place to be in > and that in itself might be enough justification in at least looking > further into this direction. > > If there was enough evidence to suggest we should revoke an advert > providers ability to track someone without breaking the web that might be > interesting. > There is also some research (which I am not sure I can share publicly) to > suggest we should limit API usage to avoid security flaws within browsers > based upon a strong correlation of Lines of Code, CVE's and the low number > of sites that use those APIs. Perhaps there is a rationale to make websites > earn enough trust for new features that have a high risk. For example would > Reddits sub resources really need WebVR or WebGL? > That's very interesting. Could you share those correlations with me privately? Of course, the tools needed to perform the software reviews could be supported by automatic tools. Here is a value proposition coming from browser vendors or anyone who want to adhere to the protocol. > But we would also have to counter the cost of building this over just > making the APIs secure in the first place and also understand we would hurt > web innovation with that too. > Ideally, the protocol is intended to worry "not too much" about misusing powerful APIs and so, to boost Web innovation and experimentation. > > On Tue, Mar 21, 2017 at 10:11 PM, 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. >> >> 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. >> >> -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
