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?
You're saying that a user should be allowed to shoot their own feet. How
would that be different from the existing permission prompts? This
sounds like it could be easily maneuvered with some social engineering
from the website.
Your proposal says " what happens from here is up to the browser". This
doesn't really make a good impression to me as a browser developer since
it appears like important UI questions are just hand-waved away in your
concept.
Cheers,
Johann
On 23/03/2017 02:09, 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.
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?
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.
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
_______________________________________________
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
