On 05/03/15 07:40, Anne van Kesteren wrote:
> This would require everything that's like github.io to register as a
> public suffix.
github.io already is a public suffix :-) If some private entity is
handing out subdomains to mutually-untrusting 3rd parties, there are a
number of reasons they shou
Le 5 mars 2015 à 06:54, Jonas Sicking a écrit :
> Also, we might want to do something similar for permissions. It's
> somewhat annoying if a website can keep asking for geolocation by
> simply using new subdomains to do so, even if the user repeatedly
> clicks "no" and "remember this decision".
On Wed, Mar 4, 2015 at 10:54 PM, Jonas Sicking wrote:
> Also, we might want to do something similar for permissions. It's
> somewhat annoying if a website can keep asking for geolocation by
> simply using new subdomains to do so, even if the user repeatedly
> clicks "no" and "remember this decisio
On Tue, Mar 3, 2015 at 11:36 PM, Anne van Kesteren wrote:
> On Wed, Mar 4, 2015 at 12:48 AM, Justin Dolske wrote:
>> I don't actually think about:permissions is a good start, or that it's
>> implemented "most of the complicated bits." Quite the opposite, really: it
>> was a useful experiment, but
I don't actually think about:permissions is a good start, or that it's
implemented "most of the complicated bits." Quite the opposite, really: it
was a useful experiment, but has some serious problems. I'd briefly
summarize the two main flaws as (1) "manager" UIs are generally not great
(they provi
(Added dev.platform back.)
On Tue, Mar 3, 2015 at 7:04 PM, Shane Caraveo wrote:
> I tend to agree with Gerv, there should be an overly simplistic top level "I
> trust [social network name] to do something wrong but let them do it anyway"
> setting with a way to dig into more detailed settings if
On Wed, Mar 4, 2015 at 12:48 AM, Justin Dolske wrote:
> I don't actually think about:permissions is a good start, or that it's
> implemented "most of the complicated bits." Quite the opposite, really: it
> was a useful experiment, but has some serious problems. I'd briefly
> summarize the two main
+1, Philipp has thought about this a lot. Also: I'm really glad we're
having this conversation. We want to tackle this sooner than later.
On Mar 3, 2015 6:48 PM, "Justin Dolske" wrote:
> I don't actually think about:permissions is a good start, or that it's
> implemented "most of the complicated
Anne van Kesteren schrieb:
I'd like to ask that we start investigating how to best present these
to the user, including their persistence and implications.
Note that one idea that I had about 5 years back is implemented by default in SeaMonkey
as "Data Manager" and available as a Firefox add-o
On 2015-03-03 9:36 AM, Eric Rescorla wrote:
On Tue, Mar 3, 2015 at 5:55 AM, Anne van Kesteren mailto:ann...@annevk.nl>> wrote:
On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun mailto:fbr...@mozilla.com>> wrote:
> The good news is that most of the complicated bits are already
> implem
On Tue, Mar 3, 2015 at 5:55 AM, Anne van Kesteren wrote:
> On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun wrote:
> > The good news is that most of the complicated bits are already
> > implemented. See about:permissions.
>
> That seems like a good start, although it fails to cover a number of
> t
On Tue, Mar 3, 2015 at 2:17 PM, Frederik Braun wrote:
> The good news is that most of the complicated bits are already
> implemented. See about:permissions.
That seems like a good start, although it fails to cover a number of
things, such as cache, storage APIs, and the notifications API. And we
The good news is that most of the complicated bits are already
implemented. See about:permissions.
Though it operates on hostnames and not origins (bug 1066517).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listi
On Tue, Mar 3, 2015 at 12:40 PM, Anne van Kesteren wrote:
> I'd like to ask that we start investigating how to best present these
> to the user, including their persistence and implications. As well as
> strongly considering updating about:preferences to reveal how much we
> store for each page (a
14 matches
Mail list logo