On 2015-05-06 1:40 PM, Justin Dolske wrote:
On 5/6/15 10:02 AM, Ehsan Akhgari wrote:
1. The scenario that you're describing is already possible on the Web,
through Flash. However, I have not seen any evidence of this kind of
thing ever occurring in the wild. Given the fact that people have
literally had years to start trying to do this. Web sites do have an
incentive to not annoy users, and we have seen how they have largely
stopped doing annoying things such as blocking the context menu in the
past.
Well... Did Flash offer sites a way to to this without user interaction?
No, and as I said in the first email of this thread, neither are we.
I think the "web sites do have an incentive to not annoy users" claim is
dubious too. Some sites certainly do, but we still see widespread
annoyance/abuse of features like popups, onbeforeunload traps, playing
unexpected audio in background tabs. And some legit sites (eg wendys.com
/ t-mobile.com) kind of abuse geolocation by prompting for it on every
page upon page load.
I never said that there are no websites that do annoying things. I did
say that they have an incentive to not annoy the user, because they
typically want the user to spend as much time on their website as
possible. Perhaps this is anecdotal, but I don't see examples of the
above abuses on the majority of websites that I visit.
Also, in this case I can safely make a stringer claim, because there has
been years of experience with an equivalent API.
This isn't such a severe problem that we have to completely solve it
right away, but I'd hate to see us painted into a corner where we have
no options for mitigating abuse or giving our users control.
As I said in the email that you're replying to, this will actually not
paint us into a corner. We can always revisit this decision. Websites
will need to have fallbacks for older browsers for a while, and I don't
know if Safari plans to implement this yet.
2. Even if we decided that this is a serious issue that we need to
solve, there is no good solution here.
One off-the-cuff thought would be to place some reasonable restrictions
on the usage (tab must be in foreground, maybe in response to a user
interaction), and perhaps provide some (fairly subtle) UI indication of
when it's invoked. That at least gives the user a chance to see a
clearer cause/effect.
Please read the original email of the thread again. Perhaps I was not
clear enough. This API is going to be restricted to code that runs in
response to a user event (which means by definition it is restricted to
the foreground tab as well).
I don't think we shoiuld show a UI indication because a) such an
indication does not exist in any other app and b) it is not clear to me
what the user is supposed to do with such an indication.
Or, along the vein of retroactively revoking permissions -- just keeping
a usage log somewhere. That at least enables motivated/SUMO users to be
able to discover what site is causing the problem, and then either
revoke it off or stop going there. Seems like kind of an interesting
idea that would scale to other seldomly-abused permissions...
Before we even begin to think about measures such as this, I would like
to see some evidence that this is a problem _in practice_.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
