On Tue, Mar 17, 2015 at 12:05 PM, Aryeh Gregor wrote:
> 1) SNI is reportedly still not usable if you care about IE on XP.
> This means HTTPS is not usable on shared hosting, which is most small
> sites, unless you don't care that your site doesn't load in IE on XP.
> This is also a problem for lar
On Thu, Mar 12, 2015 at 3:56 PM, Adam Roach wrote:
> As an aside, the first three are not just fixable, but actually fixed within
> the next few months: https://letsencrypt.org/
That seems like a huge step forward. But putting my ex-sysadmin hat
on -- assuming it works as advertised, there are s
On Mon, Mar 16, 2015 at 3:24 PM, Eric Rescorla wrote:
> Lots of people have the cameras in their rooms pointing at them even when
> they are not using the computer, and so the camera can be used to spy on
> them (Again, I refer you to Checkoway's description of "ratting" [1]). This
> might be more
Aryeh,
Le 16 mars 2015 à 21:10, Aryeh Gregor a écrit :
> What's the use of taking a picture if the user isn't actively using
> the computer?
http://www.huffingtonpost.com/hemanshu-nigam/internet-hacking-protection_b_2641370.html
> Hacker-voyeurs easily access almost any computer and spy on vict
Aryeh,
Le 16 mars 2015 à 21:10, Aryeh Gregor a écrit :
> What's the use of taking a picture if the user isn't actively using
> the computer?
http://www.huffingtonpost.com/hemanshu-nigam/internet-hacking-protection_b_2641370.html
> Hacker-voyeurs easily access almost any computer and spy on vict
On Mon, Mar 16, 2015 at 5:10 AM, Aryeh Gregor wrote:
> On Thu, Mar 12, 2015 at 9:42 PM, Boris Zbarsky wrote:
> > On 3/12/15 3:31 PM, Aryeh Gregor wrote:
> >>
> >> 2) Attacker opens a background tab and navigates it to http://b.com (I
> >> can't think of a JavaScript way to do this, but if there
On 3/16/15 8:10 AM, Aryeh Gregor wrote:
What's the use of taking a picture if the user isn't actively using
the computer?
You get to see whatever the user _is_ doing at the time. You seriously
don't see the use of that, especially for nefarious ends?
Also, the user will almost certainly re
On 2015-03-12 2:06 PM, Boris Zbarsky wrote:
On 3/12/15 1:28 PM, Ehsan Akhgari wrote:
Another concern with persisting permissions requested from iframes
Can we persist them for the pair (origin of iframe, origin of toplevel
page) or something?
Yes, that sounds like a good idea to me.
___
On Thu, Mar 12, 2015 at 9:42 PM, Boris Zbarsky wrote:
> On 3/12/15 3:31 PM, Aryeh Gregor wrote:
>>
>> 2) Attacker opens a background tab and navigates it to http://b.com (I
>> can't think of a JavaScript way to do this, but if there isn't one,
>> making a big that covers the whole page
>> would w
On Thu, Mar 12, 2015 at 12:31 PM, Aryeh Gregor wrote:
> On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari
> wrote:
> >> 2) If the only common real-world MITM threat is via a compromise
> >> adjacent to the client (e.g., wireless), there's no reason to restrict
> >> geolocation, because the attacker
On 3/12/15 3:31 PM, Aryeh Gregor wrote:
2) Attacker opens a background tab and navigates it to http://b.com (I
can't think of a JavaScript way to do this, but if there isn't one,
making a big that covers the whole page
would work well enough)
This is presuming user interaction. I agree that a
On Thu, Mar 12, 2015 at 4:34 PM, Ehsan Akhgari wrote:
>> 2) If the only common real-world MITM threat is via a compromise
>> adjacent to the client (e.g., wireless), there's no reason to restrict
>> geolocation, because the attacker already knows the user's location
>> fairly precisely.
>
>
> I do
On Thu, Mar 12, 2015 at 2:56 PM, Adam Roach wrote:
> As an aside, the first three are not just fixable, but actually fixed within
> the next few months: https://letsencrypt.org/
Indeed, and for performance concerns there's a good read here:
https://istlsfastyet.com/ It's no longer an issue, unles
On 3/12/15 1:28 PM, Ehsan Akhgari wrote:
Another concern with persisting permissions requested from iframes
Can we persist them for the pair (origin of iframe, origin of toplevel
page) or something?
-Boris
___
dev-platform mailing list
dev-platform
On 2015-03-12 12:57 PM, Boris Zbarsky wrote:
On 3/12/15 12:19 PM, Ehsan Akhgari wrote:
(Note that the
fullscreen API cannot be used outside of user generated event handlers.)
Oh, good point. That helps a lot, yes.
So do you think it makes sense to restrict iframes requesting certain
permis
On 3/12/15 12:19 PM, Ehsan Akhgari wrote:
(Note that the
fullscreen API cannot be used outside of user generated event handlers.)
Oh, good point. That helps a lot, yes.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://l
On 2015-03-12 11:24 AM, Boris Zbarsky wrote:
On 3/12/15 10:26 AM, Ehsan Akhgari wrote:
Well, top level navigation cancels the fullscreen mode, right?
The attack scenario I'm thinking is:
1) User loads http://a.com
2) Attacker immediately sets location to http://b.com
3) Attacker's hacked-up b
On 3/12/15 10:26 AM, Ehsan Akhgari wrote:
Well, top level navigation cancels the fullscreen mode, right?
The attack scenario I'm thinking is:
1) User loads http://a.com
2) Attacker immediately sets location to http://b.com
3) Attacker's hacked-up b.com goes fullscreen, pretending to still be
On 2015-03-12 8:26 AM, Aryeh Gregor wrote:
Aha, that makes a lot more sense. Thanks. Yes, that does seem like a
more realistic attack. A few points come to mind:
1) The page has no way to know whether it has persisted permissions
without just trying, right? If so, the user will notice someth
On 2015-03-12 9:45 AM, Boris Zbarsky wrote:
On 3/12/15 6:28 AM, Anne van Kesteren wrote:
It does seem like there are some improvements we could make here. E.g.
not allow an to request certain permissions. Insofar we
haven't already.
That doesn't help much; the page can just navigate itself to
On 3/12/15 12:26, Aryeh Gregor wrote:
Because unless things have changed a lot in the last three years or
so, HTTPS is a pain for a few reasons:
1) It requires time and effort to set up. Network admins have better
things to do. Most of them either are volunteers, work part-time,
computers isn'
On 3/12/15 6:28 AM, Anne van Kesteren wrote:
It does seem like there are some improvements we could make here. E.g.
not allow an to request certain permissions. Insofar we
haven't already.
That doesn't help much; the page can just navigate itself to the attack
site instead of loading it in a
On Tue, Mar 10, 2015 at 5:00 PM, Boris Zbarsky wrote:
> The mitigation applies in this situation:
>
> 1) User connects to a MITMed network (e.g. wireless at the airport or
> coffeeshop or whatever) which I will henceforth call "the attacker".
> 2) No matter what site the user loads, the atta
On Tue, Mar 10, 2015 at 4:00 PM, Boris Zbarsky wrote:
> Right, and only work if the user loads such a site themselves on that
> network. If I load cnn.com and get a popup asking whether Google Hangouts
> can turn on my camera, I'd get a bit suspicious... (though I bet a lot of
> people would just
Is there any place in the UI to improve this via messaging? For example,
https://site.com/ => "Would you like to share your camera with
site.com?", but http://site.com/ => "Would you like to permanently share
your camera with any site claiming to be site.com? *Note: Firefox cannot
verify this c
I have a slight twist in thinking to offer on the topic of persistent
permissions.. part of this falls to the level of spitballing so forgive the
imprecision:
Restricting persistent permissions is essentially about cache poisoning
attacks. The assumptions seem to be that
a] https is not vulnerable
> Is there any place in the UI to improve this via messaging? For example,
> https://site.com/ => "Would you like to share your camera with site.com?",
> but http://site.com/ => "Would you like to permanently share your camera
> with any site claiming to be site.com? *Note: Firefox cannot verify th
On 3/10/15 8:05 AM, Aryeh Gregor wrote:
So the mitigation applies when:
1) Some users have already persisted the permission for the site.
2) The site asks for the permission either predictably or infrequently
enough that the user is not conditioned to just click "yes" every time
anyway.
The m
On Sat, Mar 7, 2015 at 10:33 PM, Eric Rescorla wrote:
> Let's consider a different example than the one you propose: access
> to the camera and microphone via getUserMedia(). Say that a site
> adds a feature which lets you take a picture of yourself for your
> avatar (come to think of it, I wish g
FWIW I am for the original set of HTTPS only restrictions proposed by Anne.
I think doing so sends a strong security minded message, even if some
think "too strong".
Pop-ups:
I realize including pop-ups in this is a minority opinion (judging by
this thread), however, I have not seen a single con
Thanks everyone for weighing in. It sounds like we don't want to touch
popups :-) And yes, negative persistence (never allow) should remain
available.
The Notifications API is a bit in flux and the most interesting
notifications require service workers so are already restricted. I
guess I'm okay w
On Fri, Mar 6, 2015 at 10:18 AM, Ehsan Akhgari
wrote:
> On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
>
>> I can no longer unblock popups on sites that use HTTP. The web is a big
>> place. It will take a long time for everyone to move.
>>
>
> I think Anne is not proposing that. He's propos
On Sat, Mar 7, 2015 at 11:48 AM, Aryeh Gregor wrote:
> On Fri, Mar 6, 2015 at 7: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
On Fri, Mar 6, 2015 at 7: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 t
Den 06-03-2015 kl. 19:04 skrev Gijs Kruitbosch:
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 e
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:
>
>
49 matches
Mail list logo
