On Thu, Aug 18, 2011 at 1:53 AM, Anne van Kesteren wrote:
> On Thu, 18 Aug 2011 00:51:39 +0200, Rob Ennals wrote:
>>
>> Thoughts?
>
> APIs fail with .
I don't think sandbox would be a problem. If scripts are disabled with
then the page wouldn't run the
Hi Guys,
I'd like to present a proposal for a minimal API that would allow
clickjacking prevention, while still allowing useful cross-domain
iframing such as share buttons etc.
(for context: http://en.wikipedia.org/wiki/Clickjacking)
To allow an iframe to detect clickjacking, the browser would p
esn't* release the storage mutex, rather than specifying what
*does*, since previous efforts to enumerate everything that releases
the storage mutex seem to have got stuck.
-Rob
On Tue, Nov 24, 2009 at 5:36 PM, Boris Zbarsky wrote:
> On 11/24/09 7:46 PM, Rob Ennals wrote:
>>
>>
mutex easy enough to
implement that it would hopefully be more widely implemented -
although in a weaker manner.
-Rob
On Tue, Nov 24, 2009 at 5:19 PM, Jonas Sicking wrote:
> On Tue, Nov 24, 2009 at 4:46 PM, Rob Ennals wrote:
>> In spec language, I think it should be "MAY" rel
may be called by libraries
* Release on any API call : this proposal. It's ugly, but perhaps less
ugly than everything else.
-Rob
On Tue, Nov 24, 2009 at 4:44 PM, Mike Shaver wrote:
> On Tue, Nov 24, 2009 at 6:12 PM, Rob Ennals wrote:
>> If you run your browser in "supe
ead
with a potentially mutex-dropping operation in between.
-Rob
On Tue, Nov 24, 2009 at 4:26 PM, Jonas Sicking wrote:
> On Tue, Nov 24, 2009 at 3:12 PM, Rob Ennals wrote:
>> Yes. I think that *any* DOM operation, including getElementById should
>> be allowed to release the storage m
and set lock.
-Rob
On Tue, Nov 24, 2009 at 2:06 PM, Benjamin Smedberg
wrote:
> On 11/23/09 6:13 PM, Rob Ennals wrote:
>> The planned model is that if you don't want to lose the storage mutex
>> then you shouldn't call any code that you didn't write yourself. Any
&
Since discussion on this topic seems to have calmed down and AFAICT no
fundamental problems were identified, I've now submitted a bugzilla
report suggesting that this change be made to the spec.
-Rob
On Wed, Nov 4, 2009 at 2:13 PM, Rob Ennals wrote:
> [this is Rob Ennals from Intel,
r it might need to.
-Rob
On Sat, Nov 7, 2009 at 12:08 AM, Chris Jones wrote:
> Rob Ennals wrote:
>>
>> Missed out the important final qualifier. Here's take 3:
>>
>> "the user agent MUST NOT release the storage mutex between calls to local
>> storage,
also be the
namespace used by the HTML parser. There is then the question of
whether createElementNs should accept a prefix in place of a
namespace.
Barring niggles, this version seems to have tentative buy-in from
people on both "sides" of the namespace argument.
-Rob
On Thu, No
Ug.
s/compremise/compromise/
s/Ron Ennals/Rob Ennals/
I'm tired...
-Rob
On Nov 5, 2009, at 4:50 PM, Rob Ennals wrote:
[this is Ron Ennals from Intel, posting from gmail on my phone while
at tpac]
I've talked to a few people about the distibuted extensibility
problem and I
[this is Ron Ennals from Intel, posting from gmail on my phone while
at tpac]
I've talked to a few people about the distibuted extensibility problem
and I'd like to suggest a possible compremise:
* maintain a central registry of prefixes with standard meanings - so
eg fb always means fbml
se performance aspects of
LocalStorage
remain. I cringe every time I think of one event loop blocking
another.
But I will admit that the average time would be better--especially
if we're
unlocking fairly aggressively.
I'm interested to hear what others have to say on this proposal
'm interested to hear what others have to say on this proposal.
J
On Wed, Nov 4, 2009 at 3:31 PM, Rob Ennals
wrote:
Missed out the important final qualifier. Here's take 3:
"the user agent MUST NOT release the storage mutex between calls to
local storage, except that
op can release the mutex then the whole thing is
pointless :-)
-Rob
On Nov 4, 2009, at 3:15 PM, Rob Ennals wrote:
I suspect my suggested spec line was insufficiently precise. How
about this:
"the user agent MUST NOT release the storage mutex between calls to
local storage, except
"API operation" means, and I'm sure
this could be worded better, but hopefully this makes the basic idea
clearer.
-Rob
On Nov 4, 2009, at 2:56 PM, Mike Shaver wrote:
On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals
wrote:
Or to put it another way: if the thread can't call a
to release the storage mutex.
Does that claify things? Or am I missing something?
-Rob
On Nov 4, 2009, at 2:21 PM, Mike Shaver wrote:
On Wed, Nov 4, 2009 at 5:13 PM, Rob Ennals
wrote:
How about this for a solution for the localStorage mutex problem:
"the user agent MAY re
[this is Rob Ennals from Intel, posting from gmail over my phone while
at tpac]
How about this for a solution for the localStorage mutex problem:
"the user agent MAY release the storage mutex on *any* API operation
except localStorage itself"
This guarantees that the comm
18 matches
Mail list logo
