On Friday, July 18, 2014 at 4:31:53 PM UTC-4, Gavin Sharp wrote:
> https://addons.mozilla.org/en-US/firefox/blocked/p428
> It's not clear why some people in the bug are so up in arms about the
> overly broad block - is the plugin actually useful in ways we weren't
> aware of, or do people just not
On 3/6/15 17:27, Martin Thomson wrote:
On Fri, Mar 6, 2015 at 3:13 PM, Adam Roach wrote:
The only thing that I think we'd want to see in here that is currently
missing is an explicit statement that the "new set of low level
object-oriented APIs for real-time communication" (called "WebRTC NG" i
On Fri, Mar 6, 2015 at 3:13 PM, Adam Roach wrote:
> The only thing that I think we'd want to see in here that is currently
> missing is an explicit statement that the "new set of low level
> object-oriented APIs for real-time communication" (called "WebRTC NG" in
> the deliverables) will be backwa
+1
On Fri, Mar 6, 2015 at 3:13 PM, Adam Roach wrote:
> On 3/2/15 12:53, L. David Baron wrote:
> > The W3C is proposing a revised charter for:
> >
> > Web Real-Time Communications Working Group
> > http://www.w3.org/2015/02/webrtc-charter.html
> > https://lists.w3.org/Archives/Public/public
On 3/2/15 12:53, L. David Baron wrote:
> The W3C is proposing a revised charter for:
>
> Web Real-Time Communications Working Group
> http://www.w3.org/2015/02/webrtc-charter.html
> https://lists.w3.org/Archives/Public/public-new-work/2015Feb/0004.html
>
> Mozilla has the opportunity to send
>The W3C is proposing a revised charter for:
>
> Web Real-Time Communications Working Group
>Please reply to this thread if you think there's something we should
>say as part of this charter review. (Given our involvement, it
>seems to me like we should support the charter in general, possibly
>
It does seem to me that popup-blocking isn't a great fit for this list.
AIUI this started from Chrome's intent to start moving "powerful" features
to SSL-only (with this being a first step), and allowing popups doesn't
seem like that kind of feature.
It's also worth noting that our popup blocker i
For popup blocking and notifications, I agree with Andreas - the
tradeoff from the user perspective is not right.
Gavin
On Fri, Mar 6, 2015 at 10:23 AM, wrote:
>
>> On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari wrote:
>>
>> On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
>>>
On Mar 6, 201
I would also add that I've seen cases where attempting to allow a blocked
popup doesn't work, you have to allow the site then reload the page that
triggered the popup. Obviously that is a bug in our code that we should fix
but until we do removing the permission option would entirely break these
si
On Fri, Mar 6, 2015 at 12:10 PM, Jonas Sicking wrote:
> I have the same reaction. Not allowing the user to remember that
> popups should be enabled on a http site is going to "break" a lot of
> websites I bet. In that users will have to constantly re-enable
> popups.
>
> I don't think the added s
On Fri, Mar 6, 2015 at 10:12 AM, wrote:
>>
>> You might say that having a local network attacker able to see what
>> your webcam is looking at is not scary, but I'm going to disagree.
>> Also c.f. RFC 7258.
>
> I asked for something very specific: popups. What is the threat model for the
> popup
On 2015-03-06 1:23 PM, andreas@gmail.com wrote:
On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari wrote:
On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
On Mar 6, 2015, at 5:52 PM, Anne van Kesteren wrote:
On Fri, Mar 6, 2015 at 6:33 PM, wrote:
Is the threat model for all of these per
> On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari wrote:
>
> On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
>>
>>> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren wrote:
>>>
>>> On Fri, Mar 6, 2015 at 6:33 PM, wrote:
Is the threat model for all of these permissions significant enough to
On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
On Mar 6, 2015, at 5:52 PM, Anne van Kesteren wrote:
On Fri, Mar 6, 2015 at 6:33 PM, wrote:
Is the threat model for all of these permissions significant enough to warrant
the breakage?
What breakage do you envision?
I can no longer u
> On Mar 6, 2015, at 5:52 PM, Anne van Kesteren wrote:
>
> On Fri, Mar 6, 2015 at 6:33 PM, wrote:
>> Is the threat model for all of these permissions significant enough to
>> warrant the breakage?
>
> What breakage do you envision?
I can no longer unblock popups on sites that use HTTP. The
>
> You might say that having a local network attacker able to see what
> your webcam is looking at is not scary, but I'm going to disagree.
> Also c.f. RFC 7258.
I asked for something very specific: popups. What is the threat model for the
popup permission state?
Thanks,
Andreas
_
On Fri, Mar 6, 2015 at 9:27 AM, Anne van Kesteren wrote:
> I suggest we stop offering that
> functionality when there's no lock in the address bar.
Anne, thanks for doing this. +1 from me.
I've opened bugs on this in the past, but this is definitely a better
forum for having the discussion.
On
On 06/03/2015 17:27, Anne van Kesteren wrote:
A large number of permissions we currently allow users to store
persistently for a given origin. I suggest we stop offering that
functionality when there's no lock in the address bar.
Can we make an exception for localhost and its IPv4 and IPv6 equi
On Fri, Mar 6, 2015 at 6:33 PM, wrote:
> Is the threat model for all of these permissions significant enough to
> warrant the breakage?
What breakage do you envision?
Having said that:
* Geolocation allow for tracking the user
* Notifications allow for spamming the user
* Fullscreen allows fo
Is the threat model for all of these permissions significant enough to warrant
the breakage? Popups for example are annoying, but a spoofed origin to take
advantage of whitelisted popups seems not terribly dangerous.
Thanks,
Andreas
> On Mar 6, 2015, at 5:27 PM, Anne van Kesteren wrote:
>
>
A large number of permissions we currently allow users to store
persistently for a given origin. I suggest we stop offering that
functionality when there's no lock in the address bar. This will make
it harder for a network attacker to abuse these permissions. This
would affect UX for:
* Geolocatio
On 3/6/2015 10:44 AM, Jan De Mooij wrote:
We've deprecated [0] __noSuchMethod__ [1] support in SpiderMonkey. It's a
non-standard feature that no other engine supports, and it's been hindering
ongoing performance work as __noSuchMethod__ is not trivial to support in
the JITs.
I've posted patches
We've deprecated [0] __noSuchMethod__ [1] support in SpiderMonkey. It's a
non-standard feature that no other engine supports, and it's been hindering
ongoing performance work as __noSuchMethod__ is not trivial to support in
the JITs.
I've posted patches to convert all in-tree and add-on SDK uses a
>From the standard
>(https://html.spec.whatwg.org/multipage/scripting.html#dom-hitregionoptions-path):
"A Path2D object that describes the pixels that form part of the region. If
this member is not provided, or is set to null, the current default path is
used instead."
The bug: https://bugzi
24 matches
Mail list logo
