Re: [last call feedback] Last Call of Web Crypto API; deadline May 20

[Ryan Sleevi]

On May 16, 2014 7:20 PM, "Jonas Sicking"  wrote:
>
> On Tue, Mar 25, 2014 at 12:31 PM, Arthur Barstow 
wrote:
> > WebApps was asked to review the Last Call Working Draft of the Web
Crypto
> > API:
> >
> >   
> >
> > Individual WG members are encouraged to provide individual feedback.
>
> I don't really have the crypto chops to do anything more than a
> superficial review here, so just a couple of pieces of feedback:
>
> Should Key be a dictionary rather than an interface?

No. There is a hidden opaque handle for the cryptosystem that is
represented by the Key object, that is a Platform object that can't be
polyfilled.

The TAG review on github digs into this much deeper.

>
> Same question for KeyAlgorithm and anything that derives from it. It
> looks like these interfaces just provides a bunch of properties.
> Unless it also stores internal data (?) it looks like this would be
> better done as a dictionary.

This was raised during TAG and is being corrected. It will be an object
type, converted from Dictionaries of the same (existing) types. The
dictionaries serve as spec shorthand.

>
> The fact that KeyAlgorithm is a [NoInterfaceObject] further indicates
this.
>
> / Jonas
>

[last call feedback] Last Call of Web Crypto API; deadline May 20

[Jonas Sicking]

On Tue, Mar 25, 2014 at 12:31 PM, Arthur Barstow  wrote:
> WebApps was asked to review the Last Call Working Draft of the Web Crypto
> API:
>
>   
>
> Individual WG members are encouraged to provide individual feedback.

I don't really have the crypto chops to do anything more than a
superficial review here, so just a couple of pieces of feedback:

Should Key be a dictionary rather than an interface?

Same question for KeyAlgorithm and anything that derives from it. It
looks like these interfaces just provides a bunch of properties.
Unless it also stores internal data (?) it looks like this would be
better done as a dictionary.

The fact that KeyAlgorithm is a [NoInterfaceObject] further indicates this.

/ Jonas

Re: Blob URL Origin

[Jonas Sicking]

On Fri, May 16, 2014 at 8:15 AM, Boris Zbarsky  wrote:
> On 5/16/14, 11:08 AM, Anne van Kesteren wrote:
>>
>> Not tainting ? Same-origin ? Doesn't matter?
>
> The same-origin  bit.  I think everyone is on board with not
> tainting  for data: things.

And I agree with them. The fact that s end up same-origin
makes it easier to XSS a website by tricking it to load a URL of the
attackers choice in an iframe. Or open a worker using a URL of the
attackers choice.

But really, I'd recommend reaching out to the browsers that currently
treat data: URLs as having a unique origin. They can probably much
better speak to why they feel that that's needed.

/ Jonas

Re: Blob URL Origin

[Boris Zbarsky]

On 5/16/14, 11:08 AM, Anne van Kesteren wrote:

Not tainting ? Same-origin ? Doesn't matter?


The same-origin  bit.  I think everyone is on board with not 
tainting  for data: things.


-Boris

Re: Blob URL Origin

[Glenn Maynard]

On Fri, May 16, 2014 at 9:11 AM, Anne van Kesteren  wrote:

> I think the sad thing is that if you couple origins with blob URLs you
>
can no longer hand a blob URL to an -based widget and let them
> play with it. E.g. draw, modify, and hand a URL back for the modified
> image. But I guess this is a scenario you explicitly want to outlaw,
> even though you could do the equivalent by passing a Blob object
> directly and that would always work.
>

As I recall, when I asked why blob URLs were same-origin only, the answer
was that it was uncertain whether all platforms had a good enough PRNG to
allow generating securely-unguessable tokens for blob URLs in order to make
sure sites can't guess blob URLs for other sites.  I don't think that's an
issue (if you don't have an entropy source to implement a secure PRNG, you
don't even have basic crypto).  I think that the same-origin restriction
for blob URLs should be removed.

-- 
Glenn Maynard

Re: Blob URL Origin

[Anne van Kesteren]

On Fri, May 16, 2014 at 5:04 PM, Boris Zbarsky  wrote:
> On 5/16/14, 10:39 AM, Anne van Kesteren wrote:
>>> The fact that some UAs don't want to implement it?
>>
>> Do we know why?
>
> They think it's a security problem.

Not tainting ? Same-origin ? Doesn't matter?


-- 
http://annevankesteren.nl/

Re: Blob URL Origin

[Boris Zbarsky]

On 5/16/14, 10:39 AM, Anne van Kesteren wrote:

The fact that some UAs don't want to implement it?


Do we know why?


They think it's a security problem.

-Boris

Re: Blob URL Origin

[Anne van Kesteren]

On Fri, May 16, 2014 at 4:31 PM, Boris Zbarsky  wrote:
> On 5/16/14, 10:11 AM, Anne van Kesteren wrote:
>> What exactly is wrong with the data URL model that we have today
>
> The fact that some UAs don't want to implement it?

Do we know why?


>> But I guess this is a scenario you explicitly want to outlaw,
>> even though you could do the equivalent by passing a Blob object
>> directly and that would always work.
>
> Where by "directly" you mean "postMessage", right?

Yes.


-- 
http://annevankesteren.nl/

Re: Blob URL Origin

[Boris Zbarsky]

On 5/16/14, 10:11 AM, Anne van Kesteren wrote:

What exactly is wrong with the data URL model that we have today


The fact that some UAs don't want to implement it?


and how do we plan on fixing it?


We don't have a plan yet.


But I guess this is a scenario you explicitly want to outlaw,
even though you could do the equivalent by passing a Blob object
directly and that would always work.


Where by "directly" you mean "postMessage", right?

-Boris

Re: Blob URL Origin

[Anne van Kesteren]

On Thu, May 15, 2014 at 8:17 PM, Jonas Sicking  wrote:
> I did. It's not very attractive to use the model of something that so
> far we haven't been able to make work consistently across UAs, and
> which isn't looking like we will be able to get consistently working
> across UAs for a long time to come. Not only does that mean that we'll
> keep blob: in the same limbo, it also means that we don't know if
> after that limbo we'll get something that is particularly great.

You did say this, but this does not explain the actual problem. What
exactly is wrong with the data URL model that we have today and how do
we plan on fixing it?


> Another argument that I'm not sure if I've raised yet is that so far I
> don't see any good solutions for data:. The rfc seems to currently
> call for all data: URLs to be given a unique origin. That means that
> you can't do new Worker("data:..."), which seems bad. And for blob:
> it'd be particularly sad if we couldn't do new Image("blob:") and then
> using that image in WebGL or in canvas2d without the canvas getting
> tainted.

The origin you get out of a URL is not the origin assigned to a
resource, necessarily. At the moment Fetch (and HTML before it)
defines that fetching a data URL is the same as fetching a same-origin
resource and gives you something back that is not tainted. This is the
same for blob URLs, they won't get tainted either. Or about:blank.


> The best solution that I've been able to think of so far was what I
> proposed in another thread of requiring explicit opt-in. However that
> requires messy and unusual syntax everywhere where URLs are used and
> where we might want to treat data: as same-origin. So also not
> something I'd be sad not to have to do for blob:.

I think the sad thing is that if you couple origins with blob URLs you
can no longer hand a blob URL to an -based widget and let them
play with it. E.g. draw, modify, and hand a URL back for the modified
image. But I guess this is a scenario you explicitly want to outlaw,
even though you could do the equivalent by passing a Blob object
directly and that would always work.


-- 
http://annevankesteren.nl/