I tried to get some folks internally to look at this, and so far nobody has
said that they oppose landing the changes as is very strongly so unless
there is no strong objections, I am going to ask Michael to submit his work
for landing tomorrow.
Cheers,
Ehsan
On Wed, Jul 1, 2015 at 2:54 AM, Micha
The patches I am working on already use Bobby Holley's OriginAttributes, in
fact we use the origin attribute on the nsIPrincipal, and only expose an
nsIPrincipal from the API.
Internally, we use the origin attribute for serialization, but to external
consumers of the API, all that is available are
On Tue, Jun 30, 2015 at 5:50 PM, Jonas Sicking wrote:
> On Tue, Jun 30, 2015 at 4:16 PM, Ehsan Akhgari
> wrote:
>> On 2015-06-30 6:04 PM, Jonas Sicking wrote:
>>>
>>> There are actually one downside with this change.
>>>
>>> It means that if a user denies access to https://website.com to use
>>>
On Tue, Jun 30, 2015 at 3:55 PM, Martin Thomson wrote:
> I wonder, has the subject of double-keying been raised in this
> context? It comes up frequently in this context. And when I say
> double-keying, I mean forming a key from the tuple of the requesting
> principal and the top level browsing c
On Tue, Jun 30, 2015 at 4:16 PM, Ehsan Akhgari wrote:
> On 2015-06-30 6:04 PM, Jonas Sicking wrote:
>>
>> There are actually one downside with this change.
>>
>> It means that if a user denies access to https://website.com to use
>> cookies, then http://website.com will still have full ability to
On Tue, Jun 30, 2015 at 4:18 PM, Ehsan Akhgari wrote:
> I personally am not sure if that is a sound idea for all permission types.
> It's probably the right thing for geolocation, but not for cookies.
As I understand it, the key for permission manager is a simple string.
Rather than make new APIs
On 2015-06-30 6:55 PM, Martin Thomson wrote:
I wonder, has the subject of double-keying been raised in this
context? It comes up frequently in this context. And when I say
double-keying, I mean forming a key from the tuple of the requesting
principal and the top level browsing context principal
On 2015-06-30 6:04 PM, Jonas Sicking wrote:
There are actually one downside with this change.
It means that if a user denies access to https://website.com to use
cookies, then http://website.com will still have full ability to use
cookies since it's a different origin.
That is a good point.
A
I wonder, has the subject of double-keying been raised in this
context? It comes up frequently in this context. And when I say
double-keying, I mean forming a key from the tuple of the requesting
principal and the top level browsing context principal (though origin
may suffice).
If there are disr
There are actually one downside with this change.
It means that if a user denies access to https://website.com to use
cookies, then http://website.com will still have full ability to use
cookies since it's a different origin.
For a DENY policy it often makes more sense to deny a whole domain
name
Historically our permissions database has used host names as part of the
permission entry, which means that if we stored a permission for
http://example.com, it would also apply to https://example.com (and
http://example.com:8080 for that matter). This is undesirable specially
once you note that t
11 matches
Mail list logo
