Re: [whatwg] Worker feedback

[Darin Fisher]

On Mon, Apr 6, 2009 at 8:57 PM, timeless  wrote:

> FWIW, iirc multiple processes from IE dates to at least IE4
>
> The best url I can find on the subject atm is
> .
>
> Michael Nordman  wrote:
> > There are additional constraints that haven't been mentioned yet...
> Plugins.
> > The current model for plugins is that they execute in a single-threaded
> > world. Chrome maintains that model by hosting each plugin in its own
> process
> > and RPC'ing method invocations back and forth between calling pages and
> the
> > plugin instances. All plugin instances (of a given plugin) reside on the
> > same thread.
>
> Robert O'Callahan  wrote:
> > Why can't instances of a plugin in different browser contexts be hosted
> > in separate processes?
>
> Michael Nordman  wrote:
> > It would be expensive, and i think has this would have some correctness
> > issues too depending on the plugin. Some plugins depend on instances
> knowing
> > about each other and interoperating with each other out of band of DOM
> based
> > means doing so.
>
> Michael Nordman  wrote:
> > And others probably assume they have exclusive access to mutable plugin
> > resources on disk.
>
> This seems unlikely. I can run Firefox, Safari, Chrome, IE, Opera, and
> others browsers at the same time, heck I can run multiple profiles of
> a couple of these (I can't find the option in the current version of
> Chrome, but I used it before).
>

chrome.exe --user-data-dir=c:\foo

Re: [whatwg] Start position of media resources

[Philip Jägenstedt]

On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double  
 wrote:


On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson   
wrote:
  Media time values are expressed in normal play time (NPT), the  
absolute

position relative to the beginning of the presentation.


I don't see mention of this in the spec which is one of the reasons I
raised the question. Have I missed it? If not I'd like to see the spec
clarified here.

Chris.


Indeed clarification is needed. In my opinion time 0 should correspond to  
the beginning of the media resource, no matter what the timeline of the  
container format says. This means that currentTime doesn't jump when  
playback begins and never goes beyond duration.


Taking Ogg as an example, there's no requirement that the granulepos start  
at zero nor does a non-zero granulepos imply any special semantics such as  
"the beginning of the file has been chopped off". A tool like oggz-chop  
might retain the original granulepos of each packet or it could just as  
well adjust the stream to start at granulepos 0. Neither is more correct  
than the other, so I'd prefer we not try to infer anything from it,  
especially since such low-level timing information might be hidden deep  
inside the platform media framework (if it normalizes the time like XiphQT  
presumably does).


Perhaps we would like to have some way to express where a resource is  
positioned on a timeline external to the resource itself, but could SMIL  
do this perhaps?


I suppose that an UA could parse the media fragment in the URL and adjust  
the timeline accordingly, but I'm not sure if it's a great idea...


--
Philip Jägenstedt
Opera Software

Re: [whatwg] The element

[James Ide]

> Going forward maybe we should add this to the keytype="" attribute,
> though, making it a space separated list instead of an enumerated
> attribute. For the parameters, maybe we can use different attributes for
> the different types? e.g. dsaparams="" ecparams="" etc? Netscape 4 used to
> have pqg="" for DSA (PQG is what DSA's parameters are called) so there is
> some precedent there.

Going one step further, if the  element does support multiple
algorithms, would it be worthwhile to allow it to contain parameters,
e.g. ? On one hand, the set of
widely-implemented algorithms seems small and fixing attribute names
like dsaparams="" makes sense. But on the other, allowing params with
arbitrary names seems like a more flexible approach.

Regards,
James

Re: [whatwg] Start position of media resources

[Conrad Parker]

2009/4/7 Philip Jägenstedt :
> On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double 
> wrote:
>
>> On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson 
>> wrote:
>>>
>>>  Media time values are expressed in normal play time (NPT), the absolute
>>> position relative to the beginning of the presentation.
>>
>> I don't see mention of this in the spec which is one of the reasons I
>> raised the question. Have I missed it? If not I'd like to see the spec
>> clarified here.
>>
>> Chris.
>
> Indeed clarification is needed. In my opinion time 0 should correspond to
> the beginning of the media resource, no matter what the timeline of the
> container format says. This means that currentTime doesn't jump when
> playback begins and never goes beyond duration.
>
> Taking Ogg as an example, there's no requirement that the granulepos start
> at zero nor does a non-zero granulepos imply any special semantics such as
> "the beginning of the file has been chopped off". A tool like oggz-chop
> might retain the original granulepos of each packet or it could just as well
> adjust the stream to start at granulepos 0. Neither is more correct than the
> other, so I'd prefer we not try to infer anything from it, especially since
> such low-level timing information might be hidden deep inside the platform
> media framework (if it normalizes the time like XiphQT presumably does).
>
> Perhaps we would like to have some way to express where a resource is
> positioned on a timeline external to the resource itself, but could SMIL do
> this perhaps?

For Ogg, the start time of the original file (prior to chopping) is
recorded in the skeleton headers by oggz-chop, so this info is
intrinsically in the media format itself.

cheers,

Conrad.

Re: [whatwg] The element

[Ian Hickson]

On Tue, 7 Apr 2009, James Ide wrote:
> 
> Going one step further, if the  element does support multiple 
> algorithms, would it be worthwhile to allow it to contain parameters, 
> e.g. ? On one hand, the set of 
> widely-implemented algorithms seems small and fixing attribute names 
> like dsaparams="" makes sense. But on the other, allowing params with 
> arbitrary names seems like a more flexible approach.

Why would it be more flexible to use another element? Surely attributes 
are just as flexible.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Start position of media resources

[Silvia Pfeiffer]

On Tue, Apr 7, 2009 at 5:12 PM, Philip Jägenstedt  wrote:
> On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double 
> wrote:
>
>> On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson 
>> wrote:
>>>
>>>  Media time values are expressed in normal play time (NPT), the absolute
>>> position relative to the beginning of the presentation.
>>
>> I don't see mention of this in the spec which is one of the reasons I
>> raised the question. Have I missed it? If not I'd like to see the spec
>> clarified here.
>>
>> Chris.
>
> Indeed clarification is needed. In my opinion time 0 should correspond to
> the beginning of the media resource, no matter what the timeline of the
> container format says. This means that currentTime doesn't jump when
> playback begins and never goes beyond duration.

I humbly disagree. If a media file explicitly knows at what time
offset it starts, the timeline needs to represent that, otherwise
there are contradictory user experiences.

For example, take a video that is a subpart of a larger video and has
been delivered through a media fragment URI
(http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/).
When a user watches both, the fragment and the full resource, and both
start at 0, he/she will assume they are different resources, when in
fact one is just a fragment of the other. Worse still: if he/she tries
to send a URI with a link to a specific time offset in the video to a
friend, he/she will come up with diverging URIs based on whether
he/she watched the fragment or the full resource. Representing the
wrong timeline for a media fragment will only cause confusion and
inconsistencies.


> Taking Ogg as an example, there's no requirement that the granulepos start
> at zero nor does a non-zero granulepos imply any special semantics such as
> "the beginning of the file has been chopped off". A tool like oggz-chop
> might retain the original granulepos of each packet or it could just as well
> adjust the stream to start at granulepos 0. Neither is more correct than the
> other, so I'd prefer we not try to infer anything from it, especially since
> such low-level timing information might be hidden deep inside the platform
> media framework (if it normalizes the time like XiphQT presumably does).

For Ogg and the definition of Skeleton
(http://wiki.xiph.org/index.php/Ogg_Skeleton), both the original
basetime of the beginning of the file and the presentation time of the
chopped off part are recorded, so it actually does imply special
semantics.


Regards,
Silvia.

Re: [whatwg] The element

[Anne van Kesteren]

On Tue, 07 Apr 2009 09:34:44 +0200, Ian Hickson  wrote:

On Tue, 7 Apr 2009, James Ide wrote:

Going one step further, if the  element does support multiple
algorithms, would it be worthwhile to allow it to contain parameters,
e.g. ? On one hand, the set of
widely-implemented algorithms seems small and fixing attribute names
like dsaparams="" makes sense. But on the other, allowing params with
arbitrary names seems like a more flexible approach.


Why would it be more flexible to use another element? Surely attributes
are just as flexible.


More importantly, we cannot use an element because  parses just  
like  and friends.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] Start position of media resources

[Philip Jägenstedt]

On Tue, 07 Apr 2009 10:26:15 +0200, Silvia Pfeiffer
 wrote:

On Tue, Apr 7, 2009 at 5:12 PM, Philip Jägenstedt   
wrote:
On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double  


wrote:


On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson 
wrote:


 Media time values are expressed in normal play time (NPT), the  
absolute

position relative to the beginning of the presentation.


I don't see mention of this in the spec which is one of the reasons I
raised the question. Have I missed it? If not I'd like to see the spec
clarified here.

Chris.


Indeed clarification is needed. In my opinion time 0 should correspond  
to

the beginning of the media resource, no matter what the timeline of the
container format says. This means that currentTime doesn't jump when
playback begins and never goes beyond duration.


I humbly disagree. If a media file explicitly knows at what time
offset it starts, the timeline needs to represent that, otherwise
there are contradictory user experiences.


If the media resource really does explicitly define an offset then I might
agree that it makes sense to adjust the timeline.

However, for plain Ogg or any other container format that just happens to
have a non-zero timestamp at the beginning of the file I think we should
definitely align them to zero. You can get such files easily by cutting
streams and it would be confusing if the timeline was relative to the
original file. As an example, in MPEG the PTS (Presentation Time Stamp)
can start at non-zero, be discontinuos and wrap around 0 so normalization
is necessary. I'm not sure if anyone disagrees, but it would be a very bad
idea to infer any semantics from the container time stamps in the absense
of some explicit mapping like Ogg Skeleton.

Not generally requiring low-level inspection of the container format time
stamps is important to us as that would virtually require that the UA
itself to demux and inspect the time stamps of different container
formats. If a platform media framework is used, time is normalized in some
way, likely differently depending on framework and plugins used.


For example, take a video that is a subpart of a larger video and has
been delivered through a media fragment URI
(http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/).
When a user watches both, the fragment and the full resource, and both
start at 0, he/she will assume they are different resources, when in
fact one is just a fragment of the other. Worse still: if he/she tries
to send a URI with a link to a specific time offset in the video to a
friend, he/she will come up with diverging URIs based on whether
he/she watched the fragment or the full resource. Representing the
wrong timeline for a media fragment will only cause confusion and
inconsistencies.


OK, I agree with this.

Taking Ogg as an example, there's no requirement that the granulepos  
start
at zero nor does a non-zero granulepos imply any special semantics such  
as

"the beginning of the file has been chopped off". A tool like oggz-chop
might retain the original granulepos of each packet or it could just as  
well
adjust the stream to start at granulepos 0. Neither is more correct  
than the
other, so I'd prefer we not try to infer anything from it, especially  
since
such low-level timing information might be hidden deep inside the  
platform

media framework (if it normalizes the time like XiphQT presumably does).


For Ogg and the definition of Skeleton
(http://wiki.xiph.org/index.php/Ogg_Skeleton), both the original
basetime of the beginning of the file and the presentation time of the
chopped off part are recorded, so it actually does imply special
semantics.


The most consistent behavior in my opinion would be to report duration as  
the duration of the whole resource and for buffered/played/seekable to  
only return ranges within the range indicated by the media fragment.  
Exposing the start and stop position of the fragment via the DOM seems  
like overkill to me at this point.


--
Philip Jägenstedt
Opera Software

[whatwg] About Descendent Tags

[Diego Eis]

Hello,
my name is Diego Eis. I'm from Brazil. Sorry for my bad english, ok? :D
I have a website about web standards in pt-br called Tableless.com.br.
And I have a little question.

I have read some HTML5 articles and the specifications in WHATWG
website. I read, for example, the element 'h3' or others headers not
appear as a descendant of the 'footer' element. And I see also the
element 'nav' must not appear as a descendant of the header element.
I don't understand why. The obviously for me when I use the element
header, I say to browsers that element is a header and all elements
descendant are components of this header.
When I write HTML or XHTML, the strutucture look like this:

   logo
   
   


With HTML5 header element, I can't do this. The structure above have a
good semantic. The obviously don't be the same code, but using the
header element and not div#header?

Forgive if this question pass to here in other time. I realy want to
know and discuss this point.

Cheers,
Diego Eis
Tableless.com.br

Re: [whatwg] About Descendent Tags

[Kristof Zelechovski]

The header element is not for the page header, it is for grouping section
headings, and the tag name chosen for this element is misleading.
HTH,
Chris

Re: [whatwg] About Descendent Tags

[Diego Eis]

> The header element is not for the page header, it is for grouping section
> headings, and the tag name chosen for this element is misleading.
This is a group of headings?

title
title2
title3


If yes, my question is: when I will use this?

Like I say: all pages have a header section. We write this header
section with div element and class or id attribute.
So, I write this to be more correct code?

 
   logo
 
 
   
 


No sense the header and h1 like your descendant.

thanks advanced
Diego Eis



On Tue, Apr 7, 2009 at 9:52 AM, Kristof Zelechovski
 wrote:
> The header element is not for the page header, it is for grouping section
> headings, and the tag name chosen for this element is misleading.
> HTH,
> Chris
>
>
>
>

Re: [whatwg] About Descendent Tags

[Kristof Zelechovski]

A group of headings looks as follows:

Romeo and Julieta tragedy in Italian style

This is meant to replace the clumsy HTML4 way:

Romeo and Juliet a tragedy in Italian style

HTH,
Chris

Re: [whatwg] Start position of media resources

[Ralph Giles]

On Tue, Apr 7, 2009 at 1:26 AM, Silvia Pfeiffer
 wrote:

> For example, take a video that is a subpart of a larger video and has
> been delivered through a media fragment URI
> (http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/).
> When a user watches both, the fragment and the full resource, and both
> start at 0, he/she will assume they are different resources, when in
> fact one is just a fragment of the other.

There is a ui problem here, in that the 'seek bar' control typically
displayed by web video players has finite resolution. It works great
for short-form clips a la YouTube, but a 30 second segment of a two
hour movie amounts to a few pixels. Displaying such a fragment in the
context of the complete work makes a linear progress bar useless for
seeking within the fragment itself, everything having been traded for
showing that it's part of a much larger resource. Never mind that a
temporal url can equally well reference a five minute section of a
2 hour webcam archive.

Showing a fragment in context is helpful, not just for the time
offset, but cue points, related resources, and so on. The default
controls the browser provides can't encompass all possible context
interfaces, so perhaps the focus here should be on what is necessary
to enable scripts (or browser vendors) to build more complicated
interfaces when they're appropriate.

 -r

Re: [whatwg] Start position of media resources

[Eric Carlson]

On Apr 6, 2009, at 9:11 PM, Chris Double wrote:

On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson  
 wrote:
 Media time values are expressed in normal play time (NPT), the  
absolute

position relative to the beginning of the presentation.


I don't see mention of this in the spec which is one of the reasons I
raised the question. Have I missed it? If not I'd like to see the spec
clarified here.

  I thought this was explicit in the spec, but maybe I am thinking of  
the discussion of "effective start" in a previous revision?


  In any case, I agree the wording should be clarified.

eric

Re: [whatwg] About Descendent Tags

[Diego Eis]

This is not correct in HTML4?
Romeo and Juliet
a tragedy in Italian style

I don't know why I mark the headers above with .


On Tue, Apr 7, 2009 at 10:30 AM, Kristof Zelechovski
 wrote:
> A group of headings looks as follows:
>
> >Romeo and Juliet>a tragedy in Italian style
>
> This is meant to replace the clumsy HTML4 way:
>
> Romeo and Juliet a tragedy in Italian style
>
> HTH,
> Chris
>
>
>
Hello,
my name is Diego Eis. I'm from Brazil. Sorry for my bad english, ok? :D
I have a website about web standards in pt-br called Tableless.com.br.
And I have a little question.

I have read some HTML5 articles and the specifications in WHATWG
website. I read, for example, the element 'h3' or others headers not
appear as a descendant of the 'footer' element. And I see also the
element 'nav' must not appear as a descendant of the header element.
I don't understand why. The obviously for me when I use the element
header, I say to browsers that element is a header and all elements
descendant are components of this header.
When I write HTML or XHTML, the strutucture look like this:

  logo
  
  


With HTML5 header element, I can't do this. The structure above have a
good semantic. The obviously don't be the same code, but using the
header element and not div#header?

Forgive if this question pass to here in other time. I realy want to
know and discuss this point.

Cheers,
Diego Eis
Tableless.com.br

Re: [whatwg] About Descendent Tags

[James Graham]

Diego Eis wrote:

This is not correct in HTML4?
Romeo and Juliet
a tragedy in Italian style


If you fed that markup into a tool that produced the outline of the 
document (e.g. for a screen reader, a toc generator or an ordinary 
browser navigation aid), it would look something like


+Romeo and Juliet
+--+--a tragedy in Italian style

Which isn't right; there is no subsection of the document called "a 
tragedy in Italian style". The idea of  is that you should be 
able to say:



Romeo and Juliet
a tragedy in Italian style


And get an outline like:

+Romeo and Juliet

As I have pointed out elsewhere the  element appears to be very 
confusingly named, hence I advocate introducing  for this use 
case and either using  to mean "the generic top matter of the 
document" or finding some other, less ambiguous, name to mean the same 
thing.

Re: [whatwg] Start position of media resources

[David Singer]

I think that there is a very real difference between the 
zero-to-duration 'seek bar' that the UI presents, and which users 
understand, from the 'represented time' of the content.  That might 
be a section of a movie, or indeed might be a section of real 
time-of-day (think of one of the millions of british surveillance 
cameras..., or not if you'd prefer not to).  Getting "what time is 
this media resource talking about" is a metadata question...

--
David Singer
Multimedia Standards, Apple Inc.

Re: [whatwg] Start position of media resources

[Křištof Želechovski]

OTOH, if the media player scroll bar has zoom function, the problem of
navigation deficiency in a short interval disappears.  When the browser
displays a fragment, it can just zoom the scroll bar to the fragment
displayed.
IMHO,
Chris

Re: [whatwg] Start position of media resources

[David Singer]

At 19:20  +0200 7/04/09, KÞi”tof Îelechovski wrote:

OTOH, if the media player scroll bar has zoom function, the problem of
navigation deficiency in a short interval disappears.  When the browser
displays a fragment, it can just zoom the scroll bar to the fragment
displayed.
IMHO,
Chris


That's a semantic problem I hope that the media fragments group will clarify.

 If a URL asks for

http://www.example.com/t.mov?time="10s-20s";

it's clear that all I have at the UA is a 10s 
clip, so that's what I present;  the ? means the 
trimming is done at the server.


However, if I am given

http://www.example.com/t.mov#time="10s-20s";

which means the UA does the selecting;  should 
the UA present a timeline representing all of 
t.mov, but start at 10s into it and stop at 20s, 
allowing the user (if they wish) to seek outside 
that range, or should the UA present (as in the 
query case) only a 10s clip?

--
David Singer
Multimedia Standards, Apple Inc.

Re: [whatwg] Start position of media resources

[Conrad Parker]

2009/4/8 Křištof Želechovski :
> OTOH, if the media player scroll bar has zoom function, the problem of
> navigation deficiency in a short interval disappears.  When the browser
> displays a fragment, it can just zoom the scroll bar to the fragment
> displayed.

When the video data is very long and complex a seek bar isn't
particularly useful anyway, compared to a custom HTML interface. An
application like metavid.org does a good job of syncing up long video
to text transcripts, and that is good for navigation. On the other
hand an archive of security cameras might seem unbounded, and use a
different navigation interface. As long as an API for times are
available then developers can make an interface that is useful for the
content.

I think it's ok to have a standard seek bar for short videos (up to an
hour or two in duration) but it's not practical to mandate how that
interface should work for longer videos.

Conrad.

[whatwg] GRDDL in whatwg IRC channel

[Julian Reschke]

Re: <http://krijnhoetmer.nl/irc-logs/whatwg/20090407#l-675>:


# # [18:31] * jgraham thought that GRDDL was basically a way of using an XSLT 
stylesheet to transform some HTML into some RDF
# # [18:31]  Yeah, basically
# # [18:32]  And that the author had to put the link to the sty;esheet 
in @profile
# # [18:32]  no
# # [18:32]  they have to put a link to a page that has a link to the xslt 


James is right: the HTML page can carry the transformation link, no 
indirection through an additional profile is needed (only the presence 
of profile="http://www.w3.org/2003/g/data-view"; as opt-in). See, for 
instance, <http://www.w3.org/2004/01/rdxh/spec#grddl-xhtml>).


(I'm having a deja vu, Ian :-)

BR, Julian

Re: [whatwg] Start position of media resources

[Silvia Pfeiffer]

On Wed, Apr 8, 2009 at 12:26 AM, Ralph Giles  wrote:
> On Tue, Apr 7, 2009 at 1:26 AM, Silvia Pfeiffer
>  wrote:
>
>> For example, take a video that is a subpart of a larger video and has
>> been delivered through a media fragment URI
>> (http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/).
>> When a user watches both, the fragment and the full resource, and both
>> start at 0, he/she will assume they are different resources, when in
>> fact one is just a fragment of the other.
>
> There is a ui problem here, in that the 'seek bar' control typically
> displayed by web video players has finite resolution. It works great
> for short-form clips a la YouTube, but a 30 second segment of a two
> hour movie amounts to a few pixels. Displaying such a fragment in the
> context of the complete work makes a linear progress bar useless for
> seeking within the fragment itself, everything having been traded for
> showing that it's part of a much larger resource. Never mind that a
> temporal url can equally well reference a five minute section of a
> 2 hour webcam archive.
>
> Showing a fragment in context is helpful, not just for the time
> offset, but cue points, related resources, and so on. The default
> controls the browser provides can't encompass all possible context
> interfaces, so perhaps the focus here should be on what is necessary
> to enable scripts (or browser vendors) to build more complicated
> interfaces when they're appropriate.


I think there is a misunderstanding here. The suggestion is not to
display the full timeline of the original resource and specially mark
the fragment, but to start and end the timeline with the in and out
times of the fragment. I mentioned "context" only in that the in and
out times imply that the media resource is a fragment of a larger
resource. Not that the full context is actually displayed in the
timeline.

Cheers,
Silvia.

Re: [whatwg] Start position of media resources

[Silvia Pfeiffer]

On Wed, Apr 8, 2009 at 3:30 AM, David Singer  wrote:
> At 19:20  +0200 7/04/09, KÞi”tof Îelechovski wrote:
>>
>> OTOH, if the media player scroll bar has zoom function, the problem of
>> navigation deficiency in a short interval disappears.  When the browser
>> displays a fragment, it can just zoom the scroll bar to the fragment
>> displayed.
>> IMHO,
>> Chris
>
> That's a semantic problem I hope that the media fragments group will
> clarify.
>
>  If a URL asks for
>
> http://www.example.com/t.mov?time="10s-20s";
>
> it's clear that all I have at the UA is a 10s clip, so that's what I
> present;  the ? means the trimming is done at the server.

Agreed.


> However, if I am given
>
> http://www.example.com/t.mov#time="10s-20s";
>
> which means the UA does the selecting;  should the UA present a timeline
> representing all of t.mov, but start at 10s into it and stop at 20s,
> allowing the user (if they wish) to seek outside that range, or should the
> UA present (as in the query case) only a 10s clip?

Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time="10s-20s"; may mean that only the
requested 10s clip is delivered, especially if all the involved
instances in the exchange understand media fragment URIs. During a
transition period, while the infrastructure does not support media
fragment URIs yet, the full resource will be delivered and it is up to
the UA to deal with the consequences. It could either terminate the
connection and decide that the resource is too long to accept and
report an error to the user. Or it could receive the full resource,
but decide to just play back the requested segment. Since ultimately
the aim is to have only the requested clip downloaded, I think the UI
presentation should be identical to the one where a query is used.

BTW: the media fragment WG will make suggestions as to what a UA
should do, but ultimately every application may have its own
motivations for what to display, so you will not see definite
specifications for what a UA is supposed to do UI-wise with media
fragments. Think, e.g., about a playlist that consists of fragments
from multiple Web resources (including different servers). Such a
mash-up should probably best be represented with on continuous
timeline that overrides the original timing of each clip. Only when
you drill into the clip will you actually get the original in and out
times.

Regards,
Silvia.

Re: [whatwg] Start position of media resources

[David Singer]

At 8:02  +1000 8/04/09, Silvia Pfeiffer wrote:

Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time="10s-20s"; may mean that only the
requested 10s clip is delivered, especially if all the involved
instances in the exchange understand media fragment URIs. During a
transition period, while the infrastructure does not support media
fragment URIs yet, the full resource will be delivered and it is up to
the UA to deal with the consequences. It could either terminate the
connection and decide that the resource is too long to accept and
report an error to the user. Or it could receive the full resource,
but decide to just play back the requested segment. Since ultimately
the aim is to have only the requested clip downloaded, I think the UI
presentation should be identical to the one where a query is used.

BTW: the media fragment WG will make suggestions as to what a UA
should do, but ultimately every application may have its own
motivations for what to display, so you will not see definite
specifications for what a UA is supposed to do UI-wise with media
fragments. Think, e.g., about a playlist that consists of fragments
from multiple Web resources (including different servers). Such a
mash-up should probably best be represented with on continuous
timeline that overrides the original timing of each clip. Only when
you drill into the clip will you actually get the original in and out
times.


Ah, OK.  I agree that telling UAs what they should do, ought to be 
for the most part, out of scope.  But if there is material that the 
page author does NOT want to have shown, they probably need to know 
whether the # syntax will assure them that the user is restricted. 
(Always understanding that if they copy-paste the URL, neitehr # nor 
? syntax stops them from changing the selection range).  Think of 
presenting a K-12 class with a clip from a movie...


My mental analogy was HTML, where an acnhor takes you to that part of 
the page as a convenience, but nothing stops you from navigating 
away.  And in the case where the UA optimizes for showing that 
section (by suitable handshakes/translations with the server), again, 
it could present a UI which offers other times -- at the expense of 
more handshakes.

--
David Singer
Multimedia Standards, Apple Inc.

Re: [whatwg] Start position of media resources

[Silvia Pfeiffer]

On Wed, Apr 8, 2009 at 8:21 AM, David Singer  wrote:
> At 8:02  +1000 8/04/09, Silvia Pfeiffer wrote:
>>
>> Note that in the Media Fragment working group even the specification
>> of http://www.example.com/t.mov#time="10s-20s"; may mean that only the
>> requested 10s clip is delivered, especially if all the involved
>> instances in the exchange understand media fragment URIs. During a
>> transition period, while the infrastructure does not support media
>> fragment URIs yet, the full resource will be delivered and it is up to
>> the UA to deal with the consequences. It could either terminate the
>> connection and decide that the resource is too long to accept and
>> report an error to the user. Or it could receive the full resource,
>> but decide to just play back the requested segment. Since ultimately
>> the aim is to have only the requested clip downloaded, I think the UI
>> presentation should be identical to the one where a query is used.
>>
>> BTW: the media fragment WG will make suggestions as to what a UA
>> should do, but ultimately every application may have its own
>> motivations for what to display, so you will not see definite
>> specifications for what a UA is supposed to do UI-wise with media
>> fragments. Think, e.g., about a playlist that consists of fragments
>> from multiple Web resources (including different servers). Such a
>> mash-up should probably best be represented with on continuous
>> timeline that overrides the original timing of each clip. Only when
>> you drill into the clip will you actually get the original in and out
>> times.
>
> Ah, OK.  I agree that telling UAs what they should do, ought to be for the
> most part, out of scope.  But if there is material that the page author does
> NOT want to have shown, they probably need to know whether the # syntax will
> assure them that the user is restricted. (Always understanding that if they
> copy-paste the URL, neitehr # nor ? syntax stops them from changing the
> selection range).  Think of presenting a K-12 class with a clip from a
> movie...
>
> My mental analogy was HTML, where an acnhor takes you to that part of the
> page as a convenience, but nothing stops you from navigating away.  And in
> the case where the UA optimizes for showing that section (by suitable
> handshakes/translations with the server), again, it could present a UI which
> offers other times -- at the expense of more handshakes.

Yes, I understand that analogy. But because video can be a very long
resource, media fragment URIs cannot be restriced to client-side
offsetting. Think e.g. about wanting the last 2 minutes out of a 5
hour discussion downloaded to your mobile phone.

The media fragment WG decided that fragment addressing should be done
with "#" and be able to just deliver the actual fragment. (BTW: this
is in contrast to the temporal URIs that were specified for Annodex,
where chopping happened in the UA for "#"  and on the server for "?").

Cheers,
Silvia.

Re: [whatwg] Start position of media resources

[David Singer]

At 8:29  +1000 8/04/09, Silvia Pfeiffer wrote:

 > My mental analogy was HTML, where an acnhor takes you to that part of the

 page as a convenience, but nothing stops you from navigating away.  And in
 the case where the UA optimizes for showing that section (by suitable
 handshakes/translations with the server), again, it could present a UI which
 offers other times -- at the expense of more handshakes.


Yes, I understand that analogy. But because video can be a very long
resource, media fragment URIs cannot be restriced to client-side
offsetting. Think e.g. about wanting the last 2 minutes out of a 5
hour discussion downloaded to your mobile phone.

The media fragment WG decided that fragment addressing should be done
with "#" and be able to just deliver the actual fragment. (BTW: this
is in contrast to the temporal URIs that were specified for Annodex,
where chopping happened in the UA for "#"  and on the server for "?").


But there is a huge difference between

a) the UA MUST optimize for the chosen fragment, and may/should offer 
the rest of the resource to the user (at the possible expense of more 
network traffic)


and

b) the UA MUST only offer the chosen fragment to the user, and 
optimize network traffic and downloads for just that section, and 
MUST NOT allow navigation outside the indicated range



Unfortunately, it does make a difference to the page author which of 
these is talked about (and, lacking anything else, (a) is probably 
what is expected).

--
David Singer
Multimedia Standards, Apple Inc.

Re: [whatwg] Start position of media resources

[Dan Brickley]

On 8/4/09 00:29, Silvia Pfeiffer wrote:


The media fragment WG decided that fragment addressing should be done
with "#" and be able to just deliver the actual fragment.


Interesting! Do you have a reference for this? I can't understand how 
this is possible if these are URI references, unless something very 
non-traditional is happening...


cheers,

Dan

Re: [whatwg] Start position of media resources

[Conrad Parker]

2009/4/8 Dan Brickley :
> On 8/4/09 00:29, Silvia Pfeiffer wrote:
>
>> The media fragment WG decided that fragment addressing should be done
>> with "#" and be able to just deliver the actual fragment.
>
> Interesting! Do you have a reference for this? I can't understand how this
> is possible if these are URI references, unless something very
> non-traditional is happening...

The media fragment WG is also discussing the use of query parameters.
The difference in behavior is subtle.

I prefer query syntax:
http://blog.kfish.org/2009/04/discovery-and-fallback-for-media.html

Conrad.

[whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

A commonly added feature in browsers these days is "private browsing  
mode" where the intention is that the user's browsing session leaves  
no footprint on their machine.  Cookies, cache files, history, and  
other data that the browser would normally store to disk are not  
updated during these private browsing sessions.


This concept is at odds with allowing pages to store data on the  
user's machine as allowed by LocalStorage and Databases.  Surly  
persistent changes during a private browsing session shouldn't be  
written to the user's disk as that would violate the intention of a  
private browsing session.


Let's take the specific case of LocalStorage, which is what I am  
currently working on with WebKit.  In attempting to fix this bug I  
came up with a few possible solutions:


1 - Disable LocalStorage completely when private browsing is on.   
Remove it from the DOM completely.
2 - Disable LocalStorage mostly when private browsing is on.  It  
exists at window.localStorage, but is empty and has a 0-quota.
3 - Slide a "fake" LocalStorage object in when private browsing is  
enabled.  It starts empty, changes to it are successful, but it is  
never written to disk.  When private browsing is disabled, all changes  
to the private browsing proxy are thrown out.
4 - Cover the real LocalStorage object with a private browsing layer.   
It starts with all previously stored contents.  Any changes to it are  
pretended to occur, but are never written to disk.  When private  
browsing is disabled, all items revert to the state they were in when  
private browsing was enabled and writing changes to disk is re-enabled.
5 - Treat LocalStorage as read-only when private browsing is on.  It  
exists, and all previously stored contents can be retrieved.  Any  
attempt to setItem(), removeItem(), or clear() fail.


Option 1 is simple but painful for applications to get such different  
behavior.
Option 2 is only a little more complicated, but also seems  
unsatisfactory.
Option 3 is simple to implement and option 4 would difficult to  
implement efficiently.  Both would lead to bizarre behavior where data  
that the application thought was saved really wasn't.


For now we're going with option 5.  setItem() during private browsing  
will fail with the QUOTA_EXCEEDED_ERR the spec mentions.  removeItem()  
and clear() will silently fail, since the spec assumes they always  
succeed and doesn't provide a failure mechanism.


It seems the same issues apply to all the storage mechanisms, be it  
LocalStorage, SessionStorage (with optional session resuming), and  
Databases.
I have a few questions I think it would be wise for the spec to  
address for all of these:

1 - What *should* the specified behavior be?
2 - If read-only ends up being the specified behavior, should we have  
a mechanism for removeItem() and clear() to demonstrate that they  
failed?


Thanks,
~Brady

Re: [whatwg] Private browsing vs. Storage and Databases

[イアンフェッティ]

In Chrome/Chromium, "incognito" mode is basically a new profile that is in
memory (plus or minus... the cache will never get written out to disk,
although of course the memory pages could get swapped out and hit the disk
that way...). The implication is that, for many of these features, things
could just naturally get handled. That is, whilst the session is active,
pages can still use a database / local storage / ... / and at the end of the
session, when that profile is deleted, things will go away. I personally
like that approach, as there may be legitimate reasons to want to use a
database even for just a single session. (Perhaps someone wants to edit a
spreadsheet and the spreadsheet app wants to use a database on the client as
a backing store for fast edits, I don't know...). I just don't like the idea
of saying "Sorry, incognito/private/... means a class of pages won't work"
if there's no reason it has to be that way.
In short, I would prefer something closest to Option 3. It lets pages just
work, but respects the privacy wishes of the user. (AppCache / persistent
workers are the one exception where I think Option3 doesn't apply and we
need to figure something out.)

-Ian

On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson  wrote:

> A commonly added feature in browsers these days is "private browsing mode"
> where the intention is that the user's browsing session leaves no footprint
> on their machine.  Cookies, cache files, history, and other data that the
> browser would normally store to disk are not updated during these private
> browsing sessions.
>
> This concept is at odds with allowing pages to store data on the user's
> machine as allowed by LocalStorage and Databases.  Surly persistent changes
> during a private browsing session shouldn't be written to the user's disk as
> that would violate the intention of a private browsing session.
>
> Let's take the specific case of LocalStorage, which is what I am currently
> working on with WebKit.  In attempting to fix this bug I came up with a few
> possible solutions:
>
> 1 - Disable LocalStorage completely when private browsing is on.  Remove it
> from the DOM completely.
> 2 - Disable LocalStorage mostly when private browsing is on.  It exists at
> window.localStorage, but is empty and has a 0-quota.
> 3 - Slide a "fake" LocalStorage object in when private browsing is enabled.
>  It starts empty, changes to it are successful, but it is never written to
> disk.  When private browsing is disabled, all changes to the private
> browsing proxy are thrown out.
> 4 - Cover the real LocalStorage object with a private browsing layer.  It
> starts with all previously stored contents.  Any changes to it are pretended
> to occur, but are never written to disk.  When private browsing is disabled,
> all items revert to the state they were in when private browsing was enabled
> and writing changes to disk is re-enabled.
> 5 - Treat LocalStorage as read-only when private browsing is on.  It
> exists, and all previously stored contents can be retrieved.  Any attempt to
> setItem(), removeItem(), or clear() fail.
>
> Option 1 is simple but painful for applications to get such different
> behavior.
> Option 2 is only a little more complicated, but also seems unsatisfactory.
> Option 3 is simple to implement and option 4 would difficult to implement
> efficiently.  Both would lead to bizarre behavior where data that the
> application thought was saved really wasn't.
>
> For now we're going with option 5.  setItem() during private browsing will
> fail with the QUOTA_EXCEEDED_ERR the spec mentions.  removeItem() and
> clear() will silently fail, since the spec assumes they always succeed and
> doesn't provide a failure mechanism.
>
> It seems the same issues apply to all the storage mechanisms, be it
> LocalStorage, SessionStorage (with optional session resuming), and
> Databases.
> I have a few questions I think it would be wise for the spec to address for
> all of these:
> 1 - What *should* the specified behavior be?
> 2 - If read-only ends up being the specified behavior, should we have a
> mechanism for removeItem() and clear() to demonstrate that they failed?
>
> Thanks,
> ~Brady
>

Re: [whatwg] The element

[James Ide]

> Why would it be more flexible to use another element? Surely attributes
> are just as flexible.

Attributes are flexible if they are named generically (e.g. just
params=""). But as soon as they are named dsaparams="" or ecparams="",
UAs are somewhat precluded from adding some new algorithm XYZ because
of the lack of an xyzparams="" attribute. In short, if it is likely
that UAs will support more than just two or three popular signature
algorithms, it may be worthwhile to allow authors to specify a name
and parameters for any arbitrary algorithm. (It doesn't have to be
with elements - that was just an initial suggestion.) Otherwise, if
RSA, DSA, and perhaps ECs are the only prevalent algorithms (and will
continue to be so), then adding rsaparams, dsaparams, and ecparams as
attributes sounds good to me (and less verbose!).

> More importantly, we cannot use an element because  parses just like
>  and friends.

Right - I'm not quite sure that it's worthwhile to bring on this change.

- James

Re: [whatwg] Start position of media resources

[Boris Zbarsky]

Silvia Pfeiffer wrote:

Note that in the Media Fragment working group even the specification
of http://www.example.com/t.mov#time="10s-20s"; may mean that only the
requested 10s clip is delivered


Since the part starting with '#' isn't sent as part of the HTTP GET 
request, I'm not sure how this is envisioned to work.


Is there a change to HTTP planned here?

-Boris

Re: [whatwg] Private browsing vs. Storage and Databases

[Aryeh Gregor]

On Tue, Apr 7, 2009 at 8:24 PM, Brady Eidson  wrote:
> 1 - Disable LocalStorage completely when private browsing is on.  Remove it
> from the DOM completely.
> 2 - Disable LocalStorage mostly when private browsing is on.  It exists at
> window.localStorage, but is empty and has a 0-quota.
> 3 - Slide a "fake" LocalStorage object in when private browsing is enabled.
>  It starts empty, changes to it are successful, but it is never written to
> disk.  When private browsing is disabled, all changes to the private
> browsing proxy are thrown out.
> 4 - Cover the real LocalStorage object with a private browsing layer.  It
> starts with all previously stored contents.  Any changes to it are pretended
> to occur, but are never written to disk.  When private browsing is disabled,
> all items revert to the state they were in when private browsing was enabled
> and writing changes to disk is re-enabled.
> 5 - Treat LocalStorage as read-only when private browsing is on.  It exists,
> and all previously stored contents can be retrieved.  Any attempt to
> setItem(), removeItem(), or clear() fail.

How are cookies handled right now?  Surely the issues should be pretty
much the same?

> Option 3 is simple to implement and option 4 would difficult to implement
> efficiently.  Both would lead to bizarre behavior where data that the
> application thought was saved really wasn't.

I certainly can't think of how 3 could ever cause a problem.  It
should be the same as the user just logging in from a computer they
haven't used before, shouldn't it?

I'm not certain about 4.  What would be a concrete case where 4 would
break, but normal use from multiple computers would not?

I don't think 1, 2, or 5 are good ideas, since they make localStorage
semi-usable at best when privacy mode is enabled.

Re: [whatwg] Private browsing vs. Storage and Databases

[イアンフェッティ]

On Tue, Apr 7, 2009 at 5:50 PM, Aryeh Gregor

> wrote:

> On Tue, Apr 7, 2009 at 8:24 PM, Brady Eidson  wrote:
> > 1 - Disable LocalStorage completely when private browsing is on.  Remove
> it
> > from the DOM completely.
> > 2 - Disable LocalStorage mostly when private browsing is on.  It exists
> at
> > window.localStorage, but is empty and has a 0-quota.
> > 3 - Slide a "fake" LocalStorage object in when private browsing is
> enabled.
> >  It starts empty, changes to it are successful, but it is never written
> to
> > disk.  When private browsing is disabled, all changes to the private
> > browsing proxy are thrown out.
> > 4 - Cover the real LocalStorage object with a private browsing layer.  It
> > starts with all previously stored contents.  Any changes to it are
> pretended
> > to occur, but are never written to disk.  When private browsing is
> disabled,
> > all items revert to the state they were in when private browsing was
> enabled
> > and writing changes to disk is re-enabled.
> > 5 - Treat LocalStorage as read-only when private browsing is on.  It
> exists,
> > and all previously stored contents can be retrieved.  Any attempt to
> > setItem(), removeItem(), or clear() fail.
>
> How are cookies handled right now?  Surely the issues should be pretty
> much the same?
>

In Chrome, basically like option 3. It's a new profile so it starts with no
cookies, cookies can pile up but when the session ends they go away.


>
> > Option 3 is simple to implement and option 4 would difficult to implement
> > efficiently.  Both would lead to bizarre behavior where data that the
> > application thought was saved really wasn't.
>
> I certainly can't think of how 3 could ever cause a problem.  It
> should be the same as the user just logging in from a computer they
> haven't used before, shouldn't it?
>

yes


>
> I'm not certain about 4.  What would be a concrete case where 4 would
> break, but normal use from multiple computers would not?
>
> I don't think 1, 2, or 5 are good ideas, since they make localStorage
> semi-usable at best when privacy mode is enabled.
>

Re: [whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

That's interesting.  I'm not exactly clear what an "incognito" session  
starts out with.  Does it start without any cookies, for example?


~Brady

On Apr 7, 2009, at 5:39 PM, Ian Fette (イアンフェッティ) wrote:

In Chrome/Chromium, "incognito" mode is basically a new profile that  
is in memory (plus or minus... the cache will never get written out  
to disk, although of course the memory pages could get swapped out  
and hit the disk that way...). The implication is that, for many of  
these features, things could just naturally get handled. That is,  
whilst the session is active, pages can still use a database / local  
storage / ... / and at the end of the session, when that profile is  
deleted, things will go away. I personally like that approach, as  
there may be legitimate reasons to want to use a database even for  
just a single session. (Perhaps someone wants to edit a spreadsheet  
and the spreadsheet app wants to use a database on the client as a  
backing store for fast edits, I don't know...). I just don't like  
the idea of saying "Sorry, incognito/private/... means a class of  
pages won't work" if there's no reason it has to be that way.


In short, I would prefer something closest to Option 3. It lets  
pages just work, but respects the privacy wishes of the user.  
(AppCache / persistent workers are the one exception where I think  
Option3 doesn't apply and we need to figure something out.)


-Ian

On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson   
wrote:
A commonly added feature in browsers these days is "private browsing  
mode" where the intention is that the user's browsing session leaves  
no footprint on their machine.  Cookies, cache files, history, and  
other data that the browser would normally store to disk are not  
updated during these private browsing sessions.


This concept is at odds with allowing pages to store data on the  
user's machine as allowed by LocalStorage and Databases.  Surly  
persistent changes during a private browsing session shouldn't be  
written to the user's disk as that would violate the intention of a  
private browsing session.


Let's take the specific case of LocalStorage, which is what I am  
currently working on with WebKit.  In attempting to fix this bug I  
came up with a few possible solutions:


1 - Disable LocalStorage completely when private browsing is on.   
Remove it from the DOM completely.
2 - Disable LocalStorage mostly when private browsing is on.  It  
exists at window.localStorage, but is empty and has a 0-quota.
3 - Slide a "fake" LocalStorage object in when private browsing is  
enabled.  It starts empty, changes to it are successful, but it is  
never written to disk.  When private browsing is disabled, all  
changes to the private browsing proxy are thrown out.
4 - Cover the real LocalStorage object with a private browsing  
layer.  It starts with all previously stored contents.  Any changes  
to it are pretended to occur, but are never written to disk.  When  
private browsing is disabled, all items revert to the state they  
were in when private browsing was enabled and writing changes to  
disk is re-enabled.
5 - Treat LocalStorage as read-only when private browsing is on.  It  
exists, and all previously stored contents can be retrieved.  Any  
attempt to setItem(), removeItem(), or clear() fail.


Option 1 is simple but painful for applications to get such  
different behavior.
Option 2 is only a little more complicated, but also seems  
unsatisfactory.
Option 3 is simple to implement and option 4 would difficult to  
implement efficiently.  Both would lead to bizarre behavior where  
data that the application thought was saved really wasn't.


For now we're going with option 5.  setItem() during private  
browsing will fail with the QUOTA_EXCEEDED_ERR the spec mentions.   
removeItem() and clear() will silently fail, since the spec assumes  
they always succeed and doesn't provide a failure mechanism.


It seems the same issues apply to all the storage mechanisms, be it  
LocalStorage, SessionStorage (with optional session resuming), and  
Databases.
I have a few questions I think it would be wise for the spec to  
address for all of these:

1 - What *should* the specified behavior be?
2 - If read-only ends up being the specified behavior, should we  
have a mechanism for removeItem() and clear() to demonstrate that  
they failed?


Thanks,
~Brady

Re: [whatwg] Private browsing vs. Storage and Databases

[Jonas Sicking]

On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson  wrote:
> A commonly added feature in browsers these days is "private browsing mode"
> where the intention is that the user's browsing session leaves no footprint
> on their machine.  Cookies, cache files, history, and other data that the
> browser would normally store to disk are not updated during these private
> browsing sessions.
>
> This concept is at odds with allowing pages to store data on the user's
> machine as allowed by LocalStorage and Databases.  Surly persistent changes
> during a private browsing session shouldn't be written to the user's disk as
> that would violate the intention of a private browsing session.
>
> Let's take the specific case of LocalStorage, which is what I am currently
> working on with WebKit.  In attempting to fix this bug I came up with a few
> possible solutions:
>
> 1 - Disable LocalStorage completely when private browsing is on.  Remove it
> from the DOM completely.
> 2 - Disable LocalStorage mostly when private browsing is on.  It exists at
> window.localStorage, but is empty and has a 0-quota.

For what it's worth, I believe we're currently planning on doing 2 in
firefox. (not sure if it's been implemented in nightly trunk builds
yet).

> 3 - Slide a "fake" LocalStorage object in when private browsing is enabled.
>  It starts empty, changes to it are successful, but it is never written to
> disk.  When private browsing is disabled, all changes to the private
> browsing proxy are thrown out.
> 4 - Cover the real LocalStorage object with a private browsing layer.  It
> starts with all previously stored contents.  Any changes to it are pretended
> to occur, but are never written to disk.  When private browsing is disabled,
> all items revert to the state they were in when private browsing was enabled
> and writing changes to disk is re-enabled.

We felt like there was a risk of data loss with this approach. For
example imagine a web app that lets you write an email. Every 2
minutes the app saves your email in case of a crash or power loss or
similar. The app uses localStorage if possible, but if not uses
XMLHttpRequest to save the data to the server.

In this model it is significantly worse if it looks like a write is
successful, but in fact isn't.

> 5 - Treat LocalStorage as read-only when private browsing is on.  It exists,
> and all previously stored contents can be retrieved.  Any attempt to
> setItem(), removeItem(), or clear() fail.

My concern with this is the same as the reason we in firefox clear all
cookies when entering private browsing mode. The concern is as
follows:

1. A search engine stores a user-id token in a cookie. They then use
this token to server side store the users 10 last searches.

2. A user uses this search engine to search for various items. Doing
this causes the user-id token to be stored in a cookie.

3. The user then switches to private browsing mode.

4. The user makes a search for a present for his wife.

5. The user switches back into normal browsing mode.

At this point it is still possible to see the search for the wifes
present in the websites store of recent searches.

Something very similar could happen for localStorage I would imagine,
where the user-identifing information is stored in the localStorage
rather than a cookie.

However other browsers have decided *not* to clear cookies as I
understand it. For these browsers 5 would make a lot of sense. So I
suspect we need to leave some headroom here for various implementation
strategies for private browsing mode.

/ Jonas

Re: [whatwg] Private browsing vs. Storage and Databases

[イアンフェッティ]

Yes. An incognito session starts with a blank profile, so no cookies, no
cache, ...
On Tue, Apr 7, 2009 at 5:52 PM, Brady Eidson  wrote:

> That's interesting.  I'm not exactly clear what an "incognito" session
> starts out with.  Does it start without any cookies, for example?
> ~Brady
>
> On Apr 7, 2009, at 5:39 PM, Ian Fette (イアンフェッティ) wrote:
>
> In Chrome/Chromium, "incognito" mode is basically a new profile that is in
> memory (plus or minus... the cache will never get written out to disk,
> although of course the memory pages could get swapped out and hit the disk
> that way...). The implication is that, for many of these features, things
> could just naturally get handled. That is, whilst the session is active,
> pages can still use a database / local storage / ... / and at the end of the
> session, when that profile is deleted, things will go away. I personally
> like that approach, as there may be legitimate reasons to want to use a
> database even for just a single session. (Perhaps someone wants to edit a
> spreadsheet and the spreadsheet app wants to use a database on the client as
> a backing store for fast edits, I don't know...). I just don't like the idea
> of saying "Sorry, incognito/private/... means a class of pages won't work"
> if there's no reason it has to be that way.
> In short, I would prefer something closest to Option 3. It lets pages just
> work, but respects the privacy wishes of the user. (AppCache / persistent
> workers are the one exception where I think Option3 doesn't apply and we
> need to figure something out.)
>
> -Ian
>
> On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson  wrote:
>
>> A commonly added feature in browsers these days is "private browsing mode"
>> where the intention is that the user's browsing session leaves no footprint
>> on their machine.  Cookies, cache files, history, and other data that the
>> browser would normally store to disk are not updated during these private
>> browsing sessions.
>>
>> This concept is at odds with allowing pages to store data on the user's
>> machine as allowed by LocalStorage and Databases.  Surly persistent changes
>> during a private browsing session shouldn't be written to the user's disk as
>> that would violate the intention of a private browsing session.
>>
>> Let's take the specific case of LocalStorage, which is what I am currently
>> working on with WebKit.  In attempting to fix this bug I came up with a few
>> possible solutions:
>>
>> 1 - Disable LocalStorage completely when private browsing is on.  Remove
>> it from the DOM completely.
>> 2 - Disable LocalStorage mostly when private browsing is on.  It exists at
>> window.localStorage, but is empty and has a 0-quota.
>> 3 - Slide a "fake" LocalStorage object in when private browsing is
>> enabled.  It starts empty, changes to it are successful, but it is never
>> written to disk.  When private browsing is disabled, all changes to the
>> private browsing proxy are thrown out.
>> 4 - Cover the real LocalStorage object with a private browsing layer.  It
>> starts with all previously stored contents.  Any changes to it are pretended
>> to occur, but are never written to disk.  When private browsing is disabled,
>> all items revert to the state they were in when private browsing was enabled
>> and writing changes to disk is re-enabled.
>> 5 - Treat LocalStorage as read-only when private browsing is on.  It
>> exists, and all previously stored contents can be retrieved.  Any attempt to
>> setItem(), removeItem(), or clear() fail.
>>
>> Option 1 is simple but painful for applications to get such different
>> behavior.
>> Option 2 is only a little more complicated, but also seems unsatisfactory.
>> Option 3 is simple to implement and option 4 would difficult to implement
>> efficiently.  Both would lead to bizarre behavior where data that the
>> application thought was saved really wasn't.
>>
>> For now we're going with option 5.  setItem() during private browsing will
>> fail with the QUOTA_EXCEEDED_ERR the spec mentions.  removeItem() and
>> clear() will silently fail, since the spec assumes they always succeed and
>> doesn't provide a failure mechanism.
>>
>> It seems the same issues apply to all the storage mechanisms, be it
>> LocalStorage, SessionStorage (with optional session resuming), and
>> Databases.
>> I have a few questions I think it would be wise for the spec to address
>> for all of these:
>> 1 - What *should* the specified behavior be?
>> 2 - If read-only ends up being the specified behavior, should we have a
>> mechanism for removeItem() and clear() to demonstrate that they failed?
>>
>> Thanks,
>> ~Brady
>>
>
>
>

Re: [whatwg] Private browsing vs. Storage and Databases

[Jonas Sicking]

2009/4/7 Ian Fette (イアンフェッティ) :
> In Chrome/Chromium, "incognito" mode is basically a new profile that is in
> memory (plus or minus... the cache will never get written out to disk,
> although of course the memory pages could get swapped out and hit the disk
> that way...). The implication is that, for many of these features, things
> could just naturally get handled. That is, whilst the session is active,
> pages can still use a database / local storage / ... / and at the end of the
> session, when that profile is deleted, things will go away. I personally
> like that approach, as there may be legitimate reasons to want to use a
> database even for just a single session. (Perhaps someone wants to edit a
> spreadsheet and the spreadsheet app wants to use a database on the client as
> a backing store for fast edits, I don't know...). I just don't like the idea
> of saying "Sorry, incognito/private/... means a class of pages won't work"
> if there's no reason it has to be that way.
> In short, I would prefer something closest to Option 3. It lets pages just
> work, but respects the privacy wishes of the user. (AppCache / persistent
> workers are the one exception where I think Option3 doesn't apply and we
> need to figure something out.)

I do agree that there's still need for storing data while in private
browsing mode. So I do think it makes a lot of sense for
.sessionStorage to keep working.

But I do have concerned about essentially telling a website that we'll
store the requested data, only to drop it on the floor as soon as the
user exits private browsing mode (or crashes).

/ Jonas

Re: [whatwg] Private browsing vs. Storage and Databases

[イアンフェッティ]

2009/4/7 Jonas Sicking 

> 2009/4/7 Ian Fette (イアンフェッティ) :
> > In Chrome/Chromium, "incognito" mode is basically a new profile that is
> in
> > memory (plus or minus... the cache will never get written out to disk,
> > although of course the memory pages could get swapped out and hit the
> disk
> > that way...). The implication is that, for many of these features, things
> > could just naturally get handled. That is, whilst the session is active,
> > pages can still use a database / local storage / ... / and at the end of
> the
> > session, when that profile is deleted, things will go away. I personally
> > like that approach, as there may be legitimate reasons to want to use a
> > database even for just a single session. (Perhaps someone wants to edit a
> > spreadsheet and the spreadsheet app wants to use a database on the client
> as
> > a backing store for fast edits, I don't know...). I just don't like the
> idea
> > of saying "Sorry, incognito/private/... means a class of pages won't
> work"
> > if there's no reason it has to be that way.
> > In short, I would prefer something closest to Option 3. It lets pages
> just
> > work, but respects the privacy wishes of the user. (AppCache / persistent
> > workers are the one exception where I think Option3 doesn't apply and we
> > need to figure something out.)
>
> I do agree that there's still need for storing data while in private
> browsing mode. So I do think it makes a lot of sense for
> .sessionStorage to keep working.
>
> But I do have concerned about essentially telling a website that we'll
> store the requested data, only to drop it on the floor as soon as the
> user exits private browsing mode (or crashes).
>
> / Jonas
>

Doesn't the website have to handle that anyways? I mean, I assume that all
the browsers are going to allow users some way to "manage" this stuff, much
like cache/cookies - e.g. you have to assume that at some point in time the
user is going to blow you away. (Especially on mobile devices where space is
more of a premium...)

-Ian

Re: [whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

On Apr 7, 2009, at 5:50 PM, Aryeh Gregor wrote:


How are cookies handled right now?  Surely the issues should be pretty
much the same?


They are unspecified.  From this thread I have learned that Chrome and  
Firefox start with no cookies.  Safari starts with a snapshot of  
cookies at the point where the user entered private browsing mode.  I  
would not be surprised if Opera or IE8 were subtley different from  
either of these two approaches.


Option 3 is simple to implement and option 4 would difficult to  
implement

efficiently.  Both would lead to bizarre behavior where data that the
application thought was saved really wasn't.


I certainly can't think of how 3 could ever cause a problem.  It
should be the same as the user just logging in from a computer they
haven't used before, shouldn't it?


I strongly share Jonas' concern that we'd tell web applications that  
we're storing there data when we already know we're going to dump it  
later.  For 3 and 4 both, we're basically lying to the application and  
therefore the user.  Imagine a scenario where a user has no network  
connection and unknowingly left their browser in private browsing  
mode.  Email, documents, financial transactions, etc could all be  
"saved" locally then later thrown away before they've had a chance to  
sync to a server.



I don't think 1, 2, or 5 are good ideas, since they make localStorage
semi-usable at best when privacy mode is enabled.


Apparently Firefox plans to implement #2, and so far I'm standing by  
WebKit choosing #5 for now.  Options 1, 2, and 5 all avoid the problem  
that 3 and 4 have which is that we're lying about saving data we have  
no intention to save.


~Brady

Re: [whatwg] Private browsing vs. Storage and Databases

[イアンフェッティ]

On Tue, Apr 7, 2009 at 6:07 PM, Brady Eidson  wrote:

>
> On Apr 7, 2009, at 5:50 PM, Aryeh Gregor wrote:
>
>>
>> How are cookies handled right now?  Surely the issues should be pretty
>> much the same?
>>
>
> They are unspecified.  From this thread I have learned that Chrome and
> Firefox start with no cookies.  Safari starts with a snapshot of cookies at
> the point where the user entered private browsing mode.  I would not be
> surprised if Opera or IE8 were subtley different from either of these two
> approaches.
>
>  Option 3 is simple to implement and option 4 would difficult to implement
>>> efficiently.  Both would lead to bizarre behavior where data that the
>>> application thought was saved really wasn't.
>>>
>>
>> I certainly can't think of how 3 could ever cause a problem.  It
>> should be the same as the user just logging in from a computer they
>> haven't used before, shouldn't it?
>>
>
> I strongly share Jonas' concern that we'd tell web applications that we're
> storing there data when we already know we're going to dump it later.  For 3
> and 4 both, we're basically lying to the application and therefore the user.
>  Imagine a scenario where a user has no network connection and unknowingly
> left their browser in private browsing mode.  Email, documents, financial
> transactions, etc could all be "saved" locally then later thrown away before
> they've had a chance to sync to a server.
>

The same argument could be made for retaining cookies set during private
browsing ;-)


>
>
>  I don't think 1, 2, or 5 are good ideas, since they make localStorage
>> semi-usable at best when privacy mode is enabled.
>>
>
> Apparently Firefox plans to implement #2, and so far I'm standing by WebKit
> choosing #5 for now.  Options 1, 2, and 5 all avoid the problem that 3 and 4
> have which is that we're lying about saving data we have no intention to
> save.
>
> ~Brady
>
>
>

Re: [whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

On Apr 7, 2009, at 6:04 PM, Ian Fette (イアンフェッティ) wrote:


2009/4/7 Jonas Sicking 

I do agree that there's still need for storing data while in private
browsing mode. So I do think it makes a lot of sense for
.sessionStorage to keep working.

But I do have concerned about essentially telling a website that we'll
store the requested data, only to drop it on the floor as soon as the
user exits private browsing mode (or crashes).

/ Jonas

Doesn't the website have to handle that anyways? I mean, I assume  
that all the browsers are going to allow users some way to "manage"  
this stuff, much like cache/cookies - e.g. you have to assume that  
at some point in time the user is going to blow you away.  
(Especially on mobile devices where space is more of a premium...)


Caches are always assumed to be temporary and recoverable, and cookies  
have severe size and lifetime limitations placed on them (ie - the  
User Agent can never be excepted to keep cookies around for any  
predictable lifetime, per the cookies spec).


LocalStorage and Databases are expected to be persistent unless a  
script or the user explicitly removes them.  They're more like files,  
where arbitrarily misplacing them is unacceptable.


~Brady


-Ian

Re: [whatwg] Private browsing vs. Storage and Databases

[イアンフェッティ]

FWIW, I think it would be helpful to expose via some manner that the user is
in an incognito/private/whatever mode, especially to plugins. (Right now
none of us can really control what plugins are doing). If we exposed that
fact, a page could check it and decide what it wants to do. To me, that
feels a lot better than just saying "No, sorry, you don't get XYZ."

2009/4/7 Ian Fette (イアンフェッティ) 

> On Tue, Apr 7, 2009 at 6:07 PM, Brady Eidson  wrote:
>
>>
>> On Apr 7, 2009, at 5:50 PM, Aryeh Gregor wrote:
>>
>>>
>>> How are cookies handled right now?  Surely the issues should be pretty
>>> much the same?
>>>
>>
>> They are unspecified.  From this thread I have learned that Chrome and
>> Firefox start with no cookies.  Safari starts with a snapshot of cookies at
>> the point where the user entered private browsing mode.  I would not be
>> surprised if Opera or IE8 were subtley different from either of these two
>> approaches.
>>
>>  Option 3 is simple to implement and option 4 would difficult to implement
 efficiently.  Both would lead to bizarre behavior where data that the
 application thought was saved really wasn't.

>>>
>>> I certainly can't think of how 3 could ever cause a problem.  It
>>> should be the same as the user just logging in from a computer they
>>> haven't used before, shouldn't it?
>>>
>>
>> I strongly share Jonas' concern that we'd tell web applications that we're
>> storing there data when we already know we're going to dump it later.  For 3
>> and 4 both, we're basically lying to the application and therefore the user.
>>  Imagine a scenario where a user has no network connection and unknowingly
>> left their browser in private browsing mode.  Email, documents, financial
>> transactions, etc could all be "saved" locally then later thrown away before
>> they've had a chance to sync to a server.
>>
>
> The same argument could be made for retaining cookies set during private
> browsing ;-)
>
>
>>
>>
>>  I don't think 1, 2, or 5 are good ideas, since they make localStorage
>>> semi-usable at best when privacy mode is enabled.
>>>
>>
>> Apparently Firefox plans to implement #2, and so far I'm standing by
>> WebKit choosing #5 for now.  Options 1, 2, and 5 all avoid the problem that
>> 3 and 4 have which is that we're lying about saving data we have no
>> intention to save.
>>
>> ~Brady
>>
>>
>>
>

Re: [whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

On Apr 7, 2009, at 6:09 PM, Ian Fette (イアンフェッティ) wrote:



I strongly share Jonas' concern that we'd tell web applications that  
we're storing there data when we already know we're going to dump it  
later.  For 3 and 4 both, we're basically lying to the application  
and therefore the user.  Imagine a scenario where a user has no  
network connection and unknowingly left their browser in private  
browsing mode.  Email, documents, financial transactions, etc could  
all be "saved" locally then later thrown away before they've had a  
chance to sync to a server.


The same argument could be made for retaining cookies set during  
private browsing ;-)


I disagree, as cookies are already specified to be of unspecified  
persistence.  I believe a user agent can - at any time - prune cookies  
from it's cookie store and not be in violation of the cookies spec.


~Brady

Re: [whatwg] Private browsing vs. Storage and Databases

[Michael Nordman]

I think a user agent has to harmonize across all manner of shared
resources being introduced to ensure a reasonable behavior is
provided.
* localstorage (and the breadth of the associated events)
* databases
* appcaches
* named shared workers

Starting with nothing, keeping it all walled-off from the 'real'
peristent data, and scrapping it all at the end of the ingocnito
session seems reasonable.

Throwing exceptions when these facilities are used would mean those
sites just couldn't be visited incognito.

Actually storing the data seems contrary to the point of incognito.


2009/4/7 Jonas Sicking :
> 2009/4/7 Ian Fette (イアンフェッティ) :
>> In Chrome/Chromium, "incognito" mode is basically a new profile that is in
>> memory (plus or minus... the cache will never get written out to disk,
>> although of course the memory pages could get swapped out and hit the disk
>> that way...). The implication is that, for many of these features, things
>> could just naturally get handled. That is, whilst the session is active,
>> pages can still use a database / local storage / ... / and at the end of the
>> session, when that profile is deleted, things will go away. I personally
>> like that approach, as there may be legitimate reasons to want to use a
>> database even for just a single session. (Perhaps someone wants to edit a
>> spreadsheet and the spreadsheet app wants to use a database on the client as
>> a backing store for fast edits, I don't know...). I just don't like the idea
>> of saying "Sorry, incognito/private/... means a class of pages won't work"
>> if there's no reason it has to be that way.
>> In short, I would prefer something closest to Option 3. It lets pages just
>> work, but respects the privacy wishes of the user. (AppCache / persistent
>> workers are the one exception where I think Option3 doesn't apply and we
>> need to figure something out.)
>
> I do agree that there's still need for storing data while in private
> browsing mode. So I do think it makes a lot of sense for
> .sessionStorage to keep working.
>
> But I do have concerned about essentially telling a website that we'll
> store the requested data, only to drop it on the floor as soon as the
> user exits private browsing mode (or crashes).
>
> / Jonas
>

Re: [whatwg] Private browsing vs. Storage and Databases

[イアンフェッティ]

And as of right now, afaict, a user / user agent can prune a database and
not be in violation of the database spec :)

On Tue, Apr 7, 2009 at 6:11 PM, Brady Eidson  wrote:

>
> On Apr 7, 2009, at 6:09 PM, Ian Fette (イアンフェッティ) wrote:
>
>
>>>
>> I strongly share Jonas' concern that we'd tell web applications that we're
>> storing there data when we already know we're going to dump it later.  For 3
>> and 4 both, we're basically lying to the application and therefore the user.
>>  Imagine a scenario where a user has no network connection and unknowingly
>> left their browser in private browsing mode.  Email, documents, financial
>> transactions, etc could all be "saved" locally then later thrown away before
>> they've had a chance to sync to a server.
>>
>
> The same argument could be made for retaining cookies set during private
> browsing ;-)
>
>
> I disagree, as cookies are already specified to be of unspecified
> persistence.  I believe a user agent can - at any time - prune cookies from
> it's cookie store and not be in violation of the cookies spec.
>
> ~Brady
>

Re: [whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

A user can, at any time, delete application resources from their file  
system while the application is in use, or before the application's  
next launch.  They will suffer the consequences of their own action.
The operating system probably shouldn't chose to do so on its own, the  
same way the OS shouldn't chose to pretend a file is safely on disk  
when it's not.


~Brady

On Apr 7, 2009, at 6:12 PM, Ian Fette (イアンフェッティ) wrote:

And as of right now, afaict, a user / user agent can prune a  
database and not be in violation of the database spec :)


On Tue, Apr 7, 2009 at 6:11 PM, Brady Eidson   
wrote:


On Apr 7, 2009, at 6:09 PM, Ian Fette (イアンフェッティ)  
wrote:



I strongly share Jonas' concern that we'd tell web applications  
that we're storing there data when we already know we're going to  
dump it later.  For 3 and 4 both, we're basically lying to the  
application and therefore the user.  Imagine a scenario where a  
user has no network connection and unknowingly left their browser  
in private browsing mode.  Email, documents, financial  
transactions, etc could all be "saved" locally then later thrown  
away before they've had a chance to sync to a server.


The same argument could be made for retaining cookies set during  
private browsing ;-)


I disagree, as cookies are already specified to be of unspecified  
persistence.  I believe a user agent can - at any time - prune  
cookies from it's cookie store and not be in violation of the  
cookies spec.


~Brady

Re: [whatwg] Private browsing vs. Storage and Databases

[イアンフェッティ]

Yeah, but my argument is more that Incognito / Private / whatever is like
starting from a boot cdrom with a filesystem that's in memory. The OS isn't
pretending, nobody's lying to the app, that's just the way it is.
I think Michael summarized it well -

Copying it over and making it read-only violates privacy concerns.
Turning it off entirely removes functionality when it could perhaps be
useful

I think that doing option 3, and perhaps providing a way for the app to know
that we're in this mode so it can do whatever is appropriate (saving to the
cloud more frequently, just not using localstorage all together, whatever is
right for that app) solves those problems.

On Tue, Apr 7, 2009 at 6:16 PM, Brady Eidson  wrote:

> A user can, at any time, delete application resources from their file
> system while the application is in use, or before the application's next
> launch.  They will suffer the consequences of their own action.
> The operating system probably shouldn't chose to do so on its own, the same
> way the OS shouldn't chose to pretend a file is safely on disk when it's
> not.
>
> ~Brady
>
> On Apr 7, 2009, at 6:12 PM, Ian Fette (イアンフェッティ) wrote:
>
> And as of right now, afaict, a user / user agent can prune a database and
> not be in violation of the database spec :)
>
> On Tue, Apr 7, 2009 at 6:11 PM, Brady Eidson  wrote:
>
>>
>> On Apr 7, 2009, at 6:09 PM, Ian Fette (イアンフェッティ) wrote:
>>
>>

>>> I strongly share Jonas' concern that we'd tell web applications that
>>> we're storing there data when we already know we're going to dump it later.
>>>  For 3 and 4 both, we're basically lying to the application and therefore
>>> the user.  Imagine a scenario where a user has no network connection and
>>> unknowingly left their browser in private browsing mode.  Email, documents,
>>> financial transactions, etc could all be "saved" locally then later thrown
>>> away before they've had a chance to sync to a server.
>>>
>>
>> The same argument could be made for retaining cookies set during private
>> browsing ;-)
>>
>>
>> I disagree, as cookies are already specified to be of unspecified
>> persistence.  I believe a user agent can - at any time - prune cookies from
>> it's cookie store and not be in violation of the cookies spec.
>>
>> ~Brady
>>
>
>
>

Re: [whatwg] Start position of media resources

[Ian Hickson]

On Tue, 7 Apr 2009, Boris Zbarsky wrote:
> Silvia Pfeiffer wrote:
> > Note that in the Media Fragment working group even the specification
> > of http://www.example.com/t.mov#time="10s-20s"; may mean that only the
> > requested 10s clip is delivered
> 
> Since the part starting with '#' isn't sent as part of the HTTP GET request,
> I'm not sure how this is envisioned to work.
> 
> Is there a change to HTTP planned here?

Presumably one would use byte range requests as if the user had just 
seeked to the given time.

Ideally most videos wouldn't be sent using HTTP but using a more 
appropriate protocol that is designed for sending video; such protocols 
might have dedicated ways of jumping to particular times.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Private browsing vs. Storage and Databases

[Jeremy Orlow]

I haven't decided for sure yet, but I was leaning towards either option #2
or option #3 for Chrome.  Option 5 seems like it'll be very confusing to
apps.  It's possible it'll even have undesired consequences like websites
popping up alerts or telling the user "you need to increase your quota" and
not allowing them to use the app until they do.  Web developers already need
to handle localStorage not being part of the DOM, localStorage having a 0
sized quota, and hitting the quota while running.  Why also make them assume
that localStorage could be populated and read-only?

Another question is whether a user in a "private" browsing session would
want an app to have access to existing storage at all.  I can see arguments
both ways.

The most important thing, however, is to be consistent.  For example, if
application cache was not read only but database was, then any application
'upgrading' its version in cache would fail while trying to upgrade the
database schema.  Even when "schemas" are implicit (like in localStorage)
this can be an issue.  Michael might have more to say on this.

I also agree that it'd be ideal if all the browsers responded similarly.  If
every browser implements it differently, it's much less likely that
developers will properly test for this.

I've inlined a couple additional comments...

Jeremy


On Tue, Apr 7, 2009 at 5:24 PM, Brady Eidson  wrote:

> A commonly added feature in browsers these days is "private browsing mode"
> where the intention is that the user's browsing session leaves no footprint
> on their machine.  Cookies, cache files, history, and other data that the
> browser would normally store to disk are not updated during these private
> browsing sessions.
>
> This concept is at odds with allowing pages to store data on the user's
> machine as allowed by LocalStorage and Databases.  Surly persistent changes
> during a private browsing session shouldn't be written to the user's disk as
> that would violate the intention of a private browsing session.
>
> Let's take the specific case of LocalStorage, which is what I am currently
> working on with WebKit.  In attempting to fix this bug I came up with a few
> possible solutions:
>
> 1 - Disable LocalStorage completely when private browsing is on.  Remove it
> from the DOM completely.
> 2 - Disable LocalStorage mostly when private browsing is on.  It exists at
> window.localStorage, but is empty and has a 0-quota.
> 3 - Slide a "fake" LocalStorage object in when private browsing is enabled.
>  It starts empty, changes to it are successful, but it is never written to
> disk.  When private browsing is disabled, all changes to the private
> browsing proxy are thrown out.
> 4 - Cover the real LocalStorage object with a private browsing layer.  It
> starts with all previously stored contents.  Any changes to it are pretended
> to occur, but are never written to disk.  When private browsing is disabled,
> all items revert to the state they were in when private browsing was enabled
> and writing changes to disk is re-enabled.
> 5 - Treat LocalStorage as read-only when private browsing is on.  It
> exists, and all previously stored contents can be retrieved.  Any attempt to
> setItem(), removeItem(), or clear() fail.
>
> Option 1 is simple but painful for applications to get such different
> behavior.
> Option 2 is only a little more complicated, but also seems unsatisfactory.
> Option 3 is simple to implement and option 4 would difficult to implement
> efficiently.


Re #4: Most sites will not be given much space and you could implement
copy-on-write, so I guess I only see this being an issue in a small minority
of cases.


> Both would lead to bizarre behavior where data that the application thought
> was saved really wasn't.


This matches up with how most private browsing sessions handle cookies,
right?  The data persists until the session is up (because some of the web
can't work correctly without them) but then they're deleted at the end.

For now we're going with option 5.  setItem() during private browsing will
> fail with the QUOTA_EXCEEDED_ERR the spec mentions.  removeItem() and
> clear() will silently fail, since the spec assumes they always succeed and
> doesn't provide a failure mechanism.
>
> It seems the same issues apply to all the storage mechanisms, be it
> LocalStorage, SessionStorage (with optional session resuming), and
> Databases.
> I have a few questions I think it would be wise for the spec to address for
> all of these:
> 1 - What *should* the specified behavior be?
> 2 - If read-only ends up being the specified behavior, should we have a
> mechanism for removeItem() and clear() to demonstrate that they failed?
>
> Thanks,
> ~Brady
>

Re: [whatwg] The element

[Ian Hickson]

On Tue, 7 Apr 2009, James Ide wrote:
> 
> Attributes are flexible if they are named generically (e.g. just 
> params=""). But as soon as they are named dsaparams="" or ecparams="", 
> UAs are somewhat precluded from adding some new algorithm XYZ because of 
> the lack of an xyzparams="" attribute.

I don't understand. Why can't we use xyzparams="" if we introduce an XYZ 
algorithm?


> In short, if it is likely that UAs will support more than just two or 
> three popular signature algorithms, it may be worthwhile to allow 
> authors to specify a name and parameters for any arbitrary algorithm. 

As we add algorithms, we would presumably add the attributes if they are 
needed.


Note that right now a browser isn't intended to just add more algorithms 
willy nilly; the list is theoretically limited to what's in the spec. If 
we were to make the list open-ended, we could just as easily allow the 
attributes to be open-ended as well.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] The element

[James Ide]

> As we add algorithms, we would presumably add the attributes if they are
> needed.

This clarifies everything.

Thanks,
James

Re: [whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

On Apr 7, 2009, at 6:19 PM, Ian Fette (イアンフェッティ) wrote:

Yeah, but my argument is more that Incognito / Private / whatever is  
like starting from a boot cdrom with a filesystem that's in memory.


This is actually not necessarily a fact, as it has become clear that  
the different private browsing modes from the different browsers  
behave differently.


The OS isn't pretending, nobody's lying to the app, that's just the  
way it is.


I think Michael summarized it well -

Copying it over and making it read-only violates privacy concerns.


It depends on the intention of your private browsing mode.  My  
understanding is that Safari's private browsing mode has always been  
about leaving a local footprint on the user's computer, not about the  
interaction with the web.


Turning it off entirely removes functionality when it could perhaps  
be useful


Agreed.

I think that doing option 3, and perhaps providing a way for the app  
to know that we're in this mode so it can do whatever is appropriate  
(saving to the cloud more frequently, just not using localstorage  
all together, whatever is right for that app) solves those problems.


I agree it is valuable for a page to know this mode is in effect, and  
it would be important for plug-ins as well which is why it's being  
discussed on some plug-ins lists.


But what you and Aryeh are suggesting is that LocalStorage have two  
modes, one where it violates one of it's primary purposes - that the  
data is persistent.  My suggestion is that LocalStorage have a  
specified failure mode.  I'm still leaning towards the failure mode  
instead of the "pretend to work" case.


Another problem with the "reset to an empty storage area" case is  
this: say the user starts using an application and it does some things  
with LocalStorage.  Then, without leaving the application, the user  
realizes "Oh, I should be in private browsing mode" and activates it.   
In one fell swoop, LocalStorage is reset to empty and the application  
is left in an inconsistent state.  Is that okay?


I'm not saying the read-only mode is perfect, but I feel the issues  
with the "start empty, pretend to work" solutions are more severe!


~Brady

Re: [whatwg] Private browsing vs. Storage and Databases

[Brady Eidson]

On Apr 7, 2009, at 6:24 PM, Jeremy Orlow wrote:

Both would lead to bizarre behavior where data that the application  
thought was saved really wasn't.


This matches up with how most private browsing sessions handle  
cookies, right?  The data persists until the session is up (because  
some of the web can't work correctly without them) but then they're  
deleted at the end.


I guess I'll raise this point yet again, as it's a favorite of  
mine...  ;)  Cookies are not expected to be persistent, and when space  
runs out for them and they're expired there is already no notification  
of that.  Any app writer that expected cookies to be a safe,  
persistent store of data or state was already playing with fire.


~Brady

Re: [whatwg] Private browsing vs. Storage and Databases

[Aryeh Gregor]

On Tue, Apr 7, 2009 at 9:10 PM, Brady Eidson  wrote:
> Caches are always assumed to be temporary and recoverable, and cookies have
> severe size and lifetime limitations placed on them (ie - the User Agent can
> never be excepted to keep cookies around for any predictable lifetime, per
> the cookies spec).
> LocalStorage and Databases are expected to be persistent unless a script or
> the user explicitly removes them.

Or unless the user just uses a different computer.  In Chrome's model,
at least, browsing a site in private-browsing mode is just the same as
using a public computer somewhere that you'll only use once and that
has no connection to the computer you normally use.  Surely you don't
expect apps to break or behave incorrectly when people use different
computers (possibly using some only once)?  That's a very common
use-case.

In other words, localStorage is *not* guaranteed to be persistent,
practically speaking.  The user might never use the computer again.

Re: [whatwg] Private browsing vs. Storage and Databases

[Jeremy Orlow]

On Tue, Apr 7, 2009 at 6:33 PM, Brady Eidson  wrote:

>
> On Apr 7, 2009, at 6:24 PM, Jeremy Orlow wrote:
>
>  Both would lead to bizarre behavior where data that the application
>> thought was saved really wasn't.
>>
>> This matches up with how most private browsing sessions handle cookies,
>> right?  The data persists until the session is up (because some of the web
>> can't work correctly without them) but then they're deleted at the end.
>>
>
> I guess I'll raise this point yet again, as it's a favorite of mine...  ;)
>  Cookies are not expected to be persistent, and when space runs out for them
> and they're expired there is already no notification of that.  Any app
> writer that expected cookies to be a safe, persistent store of data or state
> was already playing with fire.


(Sorry.  I started that email, walked away a bit, and sent it before seeing
the torrent of responses.)

I still think it's a valid point that, whether or not the intention for
cookies, many web apps assume that they are not so volatile.  And, in
practice, this is generally a safe assumption.

Re: [whatwg] Private browsing vs. Storage and Databases

[Michael Nordman]

On Tue, Apr 7, 2009 at 6:30 PM, Brady Eidson  wrote:
>
> On Apr 7, 2009, at 6:19 PM, Ian Fette (イアンフェッティ) wrote:
>
>> Yeah, but my argument is more that Incognito / Private / whatever is like
>> starting from a boot cdrom with a filesystem that's in memory.
>
> This is actually not necessarily a fact, as it has become clear that the
> different private browsing modes from the different browsers behave
> differently.
>
>> The OS isn't pretending, nobody's lying to the app, that's just the way it
>> is.
>>
>> I think Michael summarized it well -
>>
>> Copying it over and making it read-only violates privacy concerns.
>
> It depends on the intention of your private browsing mode.  My understanding
> is that Safari's private browsing mode has always been about leaving a local
> footprint on the user's computer, not about the interaction with the web.
>
>> Turning it off entirely removes functionality when it could perhaps be
>> useful
>
> Agreed.
>
>> I think that doing option 3, and perhaps providing a way for the app to
>> know that we're in this mode so it can do whatever is appropriate (saving to
>> the cloud more frequently, just not using localstorage all together,
>> whatever is right for that app) solves those problems.
>
> I agree it is valuable for a page to know this mode is in effect, and it
> would be important for plug-ins as well which is why it's being discussed on
> some plug-ins lists.
>
> But what you and Aryeh are suggesting is that LocalStorage have two modes,
> one where it violates one of it's primary purposes - that the data is
> persistent.  My suggestion is that LocalStorage have a specified failure
> mode.  I'm still leaning towards the failure mode instead of the "pretend to
> work" case.
>
> Another problem with the "reset to an empty storage area" case is this: say
> the user starts using an application and it does some things with
> LocalStorage.  Then, without leaving the application, the user realizes "Oh,
> I should be in private browsing mode" and activates it.  In one fell swoop,
> LocalStorage is reset to empty and the application is left in an
> inconsistent state.  Is that okay?
>
> I'm not saying the read-only mode is perfect, but I feel the issues with the
> "start empty, pretend to work" solutions are more severe!

Read-only mode will just plain break some sites. They won't function,
and you will not have the option of visiting them incognito... not
useful.

I'm not sure this has to be addressed in the standard. This seems like
something browser developers can address without grand unification.

>
> ~Brady
>
>
>

Re: [whatwg] Private browsing vs. Storage and Databases

[Jeremy Orlow]

2009/4/7 Michael Nordman 

> I'm not sure this has to be addressed in the standard. This seems like
> something browser developers can address without grand unification.


They can, but then it shifts burden onto web developers to test more or
users to deal with broken websites.

Re: [whatwg] Private browsing vs. Storage and Databases

[Jonas Sicking]

2009/4/7 Ian Fette (イアンフェッティ) :
> 2009/4/7 Jonas Sicking 
>>
>> 2009/4/7 Ian Fette (イアンフェッティ) :
>> > In Chrome/Chromium, "incognito" mode is basically a new profile that is
>> > in
>> > memory (plus or minus... the cache will never get written out to disk,
>> > although of course the memory pages could get swapped out and hit the
>> > disk
>> > that way...). The implication is that, for many of these features,
>> > things
>> > could just naturally get handled. That is, whilst the session is active,
>> > pages can still use a database / local storage / ... / and at the end of
>> > the
>> > session, when that profile is deleted, things will go away. I personally
>> > like that approach, as there may be legitimate reasons to want to use a
>> > database even for just a single session. (Perhaps someone wants to edit
>> > a
>> > spreadsheet and the spreadsheet app wants to use a database on the
>> > client as
>> > a backing store for fast edits, I don't know...). I just don't like the
>> > idea
>> > of saying "Sorry, incognito/private/... means a class of pages won't
>> > work"
>> > if there's no reason it has to be that way.
>> > In short, I would prefer something closest to Option 3. It lets pages
>> > just
>> > work, but respects the privacy wishes of the user. (AppCache /
>> > persistent
>> > workers are the one exception where I think Option3 doesn't apply and we
>> > need to figure something out.)
>>
>> I do agree that there's still need for storing data while in private
>> browsing mode. So I do think it makes a lot of sense for
>> .sessionStorage to keep working.
>>
>> But I do have concerned about essentially telling a website that we'll
>> store the requested data, only to drop it on the floor as soon as the
>> user exits private browsing mode (or crashes).
>>
>> / Jonas
>
> Doesn't the website have to handle that anyways? I mean, I assume that all
> the browsers are going to allow users some way to "manage" this stuff, much
> like cache/cookies - e.g. you have to assume that at some point in time the
> user is going to blow you away. (Especially on mobile devices where space is
> more of a premium...)

It's different in that the user managing his data is an explicit
action on the users part. I.e. the user has to go to a place in the UA
and click a 'clear data' button. Users are more likely to expect that
this results in a half composed message disappearing than if the same
thing happens when exiting private browsing mode.

I think :)

/ Jonas

Re: [whatwg] Private browsing vs. Storage and Databases

[Jeremy Orlow]

2009/4/7 Jonas Sicking 

> 2009/4/7 Ian Fette (イアンフェッティ) :
> > 2009/4/7 Jonas Sicking 
> >>
> >> 2009/4/7 Ian Fette (イアンフェッティ) :
> >> > In Chrome/Chromium, "incognito" mode is basically a new profile that
> is
> >> > in
> >> > memory (plus or minus... the cache will never get written out to disk,
> >> > although of course the memory pages could get swapped out and hit the
> >> > disk
> >> > that way...). The implication is that, for many of these features,
> >> > things
> >> > could just naturally get handled. That is, whilst the session is
> active,
> >> > pages can still use a database / local storage / ... / and at the end
> of
> >> > the
> >> > session, when that profile is deleted, things will go away. I
> personally
> >> > like that approach, as there may be legitimate reasons to want to use
> a
> >> > database even for just a single session. (Perhaps someone wants to
> edit
> >> > a
> >> > spreadsheet and the spreadsheet app wants to use a database on the
> >> > client as
> >> > a backing store for fast edits, I don't know...). I just don't like
> the
> >> > idea
> >> > of saying "Sorry, incognito/private/... means a class of pages won't
> >> > work"
> >> > if there's no reason it has to be that way.
> >> > In short, I would prefer something closest to Option 3. It lets pages
> >> > just
> >> > work, but respects the privacy wishes of the user. (AppCache /
> >> > persistent
> >> > workers are the one exception where I think Option3 doesn't apply and
> we
> >> > need to figure something out.)
> >>
> >> I do agree that there's still need for storing data while in private
> >> browsing mode. So I do think it makes a lot of sense for
> >> .sessionStorage to keep working.
> >>
> >> But I do have concerned about essentially telling a website that we'll
> >> store the requested data, only to drop it on the floor as soon as the
> >> user exits private browsing mode (or crashes).
> >>
> >> / Jonas
> >
> > Doesn't the website have to handle that anyways? I mean, I assume that
> all
> > the browsers are going to allow users some way to "manage" this stuff,
> much
> > like cache/cookies - e.g. you have to assume that at some point in time
> the
> > user is going to blow you away. (Especially on mobile devices where space
> is
> > more of a premium...)
>
> It's different in that the user managing his data is an explicit
> action on the users part. I.e. the user has to go to a place in the UA
> and click a 'clear data' button. Users are more likely to expect that
> this results in a half composed message disappearing than if the same
> thing happens when exiting private browsing mode.
>
> I think :)


If a user is in private browsing mode typing up a message, they should
definitely not expect it to be there when they leave such a mode.  If they
do expect it to be there, then they really wanted multiple profiles.

I know it's bad to make presumptions, but I just can't see any web developer
depending on the localStorage or database API as anything more than a cache.
 When a user is on a web application, they expect to be able to go to
another computer and access that information.

Also note that, if you assume these APIs are anything other than fairly
permanent caches, then your browser had better have a good story for when
the user upgrades/downgrades their browser or even switches computers.  This
feels like we're going back to the POP3 era of email.  :-)

Re: [whatwg] Private browsing vs. Storage and Databases

[Tab Atkins Jr.]

On Tue, Apr 7, 2009 at 7:24 PM, Brady Eidson  wrote:
> A commonly added feature in browsers these days is "private browsing mode"
> where the intention is that the user's browsing session leaves no footprint
> on their machine.  Cookies, cache files, history, and other data that the
> browser would normally store to disk are not updated during these private
> browsing sessions.
>
> This concept is at odds with allowing pages to store data on the user's
> machine as allowed by LocalStorage and Databases.  Surly persistent changes
> during a private browsing session shouldn't be written to the user's disk as
> that would violate the intention of a private browsing session.
>
> Let's take the specific case of LocalStorage, which is what I am currently
> working on with WebKit.  In attempting to fix this bug I came up with a few
> possible solutions:
>
> 1 - Disable LocalStorage completely when private browsing is on.  Remove it
> from the DOM completely.
> 2 - Disable LocalStorage mostly when private browsing is on.  It exists at
> window.localStorage, but is empty and has a 0-quota.
> 3 - Slide a "fake" LocalStorage object in when private browsing is enabled.
>  It starts empty, changes to it are successful, but it is never written to
> disk.  When private browsing is disabled, all changes to the private
> browsing proxy are thrown out.
> 4 - Cover the real LocalStorage object with a private browsing layer.  It
> starts with all previously stored contents.  Any changes to it are pretended
> to occur, but are never written to disk.  When private browsing is disabled,
> all items revert to the state they were in when private browsing was enabled
> and writing changes to disk is re-enabled.
> 5 - Treat LocalStorage as read-only when private browsing is on.  It exists,
> and all previously stored contents can be retrieved.  Any attempt to
> setItem(), removeItem(), or clear() fail.

Having read the thread, as both a user and an amateur author, I think
#3 or #4 are the most reasonable.  All of the others are going to
break sites and provide bad user experiences.

There's really no way to argue this.  Most authors are idiots (just
like most users are idiots).  They'll use exactly as much of a feature
as they need, and nothing more.  They won't read standards, and they
won't check for errors.  #1 will *obviously* break things, especially
if accesses to LocalStorage throw during private browsing.  #5 will
put applications in an inconsistent state pretty quickly, as they
assume their writes were successful.  #2 is probably the most
pernicious, as it will bite users hardest when the author is *just*
smart enough to do some basic error checking (such as testing for
quota size) before they start to use LocalStorage.

Those three, each in their own way, feel more technically correct than
#3 and #4, and so I perfectly understand why they seem attractive to
implementors.  But they *will* cause serious problems for users, and
they *will* prevent people from using private browsing on
badly-designed LocalStorage/Database-using sites (which will be a
large percentage of them).

#3 and #4 are the realistic solutions here, both of which address the
problem while acknowledging the limitations of common author
abilities.  Which one is chosen is largely a matter of preference, and
aren't that significant.

~TJ

Re: [whatwg] Private browsing vs. Storage and Databases

[Jonas Sicking]

2009/4/7 Ian Fette (イアンフェッティ) :
>>> I certainly can't think of how 3 could ever cause a problem.  It
>>> should be the same as the user just logging in from a computer they
>>> haven't used before, shouldn't it?
>>
>> I strongly share Jonas' concern that we'd tell web applications that we're
>> storing there data when we already know we're going to dump it later.  For 3
>> and 4 both, we're basically lying to the application and therefore the user.
>>  Imagine a scenario where a user has no network connection and unknowingly
>> left their browser in private browsing mode.  Email, documents, financial
>> transactions, etc could all be "saved" locally then later thrown away before
>> they've had a chance to sync to a server.
>
> The same argument could be made for retaining cookies set during private
> browsing ;-)

I do agree that the difference is subtle. But I do think there is a
general perception that cookies are more volatile than localStorage.
In fact, I think localStorage was invented partially because of this.

Additionally, while there isn't much we can do to fix the volatileness
of cookies, I do think we can try to make localStorage better.

/ Jonas

[whatwg] Opera2d-game Extensions to Canvas: setPixel() and getPixel()

[Jeff Creamer]

Hi.  Since March of '06, Opera 9 has supported a custom extension to
the canvas context called "opera-2dgame." Importantly, their extension
adds these methods:

getPixel(x, y)
Returns the pixel value (colour, opacity) at (x, y). Returned in
the form #rrggbb if fully opaque and rgba(r, g, b, a) if it has some
alpha transparency. 

setPixel (x, y, color)
Allows you to set the colour of the pixel at (x, y). The third
argument should be a CSS color - you could provide a string such as
‘red’, a HTML colour code or even a rgba() value.

I don't see any recent discussion of this.  And I am also aware that
the canvas drawing model is not pixel-oriented.  Nonetheless, mightn't
these functions be extremely useful?  As the Opera folk point
out,  they bless game developers, and it occurs to me that they could
be used for other neat, useful things, such as giving _javascript_ a
rudimentary RAM drive.  Description including several demo programs and
a discussion of security issues is available here. 


Why not make getPixel () and setPixel() a standard?

Regards,

Jeff Creamer
Computing Instructor
Long Beach Unified School District
cream...@roadrunner.com

Re: [whatwg] Opera2d-game Extensions to Canvas: setPixel() and getPixel()

[Oliver Hunt]

Why not make getPixel () and setPixel() a standard?


The ImageData APIs already provide the ability to do this and are  
already supported by Firefox, Opera and Safari.


--Oliver

Re: [whatwg] Private browsing vs. Storage and Databases

[timeless]

2009/4/8 Jeremy Orlow :
> If a user is in private browsing mode typing up a message, they should
> definitely not expect it to be there when they leave such a mode.  If they
> do expect it to be there, then they really wanted multiple profiles.
> I know it's bad to make presumptions, but I just can't see any web developer
> depending on the localStorage or database API as anything more than a cache.
>  When a user is on a web application, they expect to be able to go to
> another computer and access that information.

> Also note that, if you assume these APIs are anything other than fairly
> permanent caches, then your browser had better have a good story for when
> the user upgrades/downgrades their browser or even switches computers.  This
> feels like we're going back to the POP3 era of email.  :-)

speaking of which.

Is there any API in localStorage to enable the browser to tell the web
app that it wants to reduce the size of its cache, to e.g. 0?

Because if we had an API which would let the browser tell an app "my
user has decided to reduce your available space to " and the user
picks 0, then the app can choose to flush all of its pending data.

And private browsing could use that API at the end. Sadly, it might be
worth giving the user some indication of how much data has been stuck
in private browsing by a given web page.

I'd suggest 3 w/ a thing to flush stuff. Preferably flushing as soon
as the user closes the last page of a site (i.e. before the user
closes the last page in their private browsing session). It should
probably be in the form of a visible opt in bit:

This site is using  MB of data. When I leave it, I <[x] do
not> want the site to know that its data is being removed. [?] 

1 - Disable LocalStorage completely when private browsing is on.
Remove it from the DOM completely.

Many sites will just assume that they know a given useragent supports
localstorage, so they'll be surprised and break.
This will mean that a user can't use certain sites.

2 - Disable LocalStorage mostly when private browsing is on.  It
exists at window.localStorage, but is empty and has a 0-quota.

This will enable sites to know that the user is browsing in private,
which is probably also a violation of the user's trust model.
If I were to be browsing in private, I wouldn't want most sites to
know that I'm doing this (which is why the banner i mention above must
give the user the choice).

3 - Slide a "fake" LocalStorage object in when private browsing is
enabled.  It starts empty, changes to it are successful, but it is
never written to disk.  When private browsing is disabled, all changes
to the private browsing proxy are thrown out.

4 - Cover the real LocalStorage object with a private browsing layer.
It starts with all previously stored contents.  Any changes to it are
pretended to occur, but are never written to disk.  When private
browsing is disabled, all items revert to the state they were in when
private browsing was enabled and writing changes to disk is
re-enabled.

This means the site will know who you are (on average), and is almost
certainly never what the user wants. If the user wants to tell the
site who they are, then the user can log in after enabling private
browsing.

5 - Treat LocalStorage as read-only when private browsing is on.  It
exists, and all previously stored contents can be retrieved.  Any
attempt to setItem(), removeItem(), or clear() fail.

This acts like 4 and isn't helpful either.

Re: [whatwg] Private browsing vs. Storage and Databases

[Jeremy Orlow]

On Tue, Apr 7, 2009 at 8:39 PM, timeless  wrote:

> 2009/4/8 Jeremy Orlow :
> > If a user is in private browsing mode typing up a message, they should
> > definitely not expect it to be there when they leave such a mode.  If
> they
> > do expect it to be there, then they really wanted multiple profiles.
> > I know it's bad to make presumptions, but I just can't see any web
> developer
> > depending on the localStorage or database API as anything more than a
> cache.
> >  When a user is on a web application, they expect to be able to go to
> > another computer and access that information.
>
> > Also note that, if you assume these APIs are anything other than fairly
> > permanent caches, then your browser had better have a good story for when
> > the user upgrades/downgrades their browser or even switches computers.
>  This
> > feels like we're going back to the POP3 era of email.  :-)
>
> speaking of which.
>
> Is there any API in localStorage to enable the browser to tell the web
> app that it wants to reduce the size of its cache, to e.g. 0?


There's the window.onstorage event which fires whenever there's a change to
localStorage.  But what do you do if the user doesn't have any windows open
on that page when the size is reduced to 0?


> Because if we had an API which would let the browser tell an app "my
> user has decided to reduce your available space to " and the user
> picks 0, then the app can choose to flush all of its pending data.
>
> And private browsing could use that API at the end. Sadly, it might be
> worth giving the user some indication of how much data has been stuck
> in private browsing by a given web page.


This is a very interesting suggestion.  When in private mode, the browser
could do an implicit .clear() and smart applications could pick up on this.
 Unfortunately, most apps would probably just be confused by this.

I'd suggest adding a new event handler, but that still wouldn't solve the
problem of the user not being at the site.

Maybe something could be added to the spec with respect to App Cache.  For
example, an app in app cache could define something to be run when it's
being evicted from storage?  Of course, this could have some
interesting/negative security implications.  In addition, if the user is off
line, they're completely screwed.

I'd suggest 3 w/ a thing to flush stuff. Preferably flushing as soon
> as the user closes the last page of a site (i.e. before the user
> closes the last page in their private browsing session). It should
> probably be in the form of a visible opt in bit:
>
> This site is using  MB of data. When I leave it, I <[x] do
> not> want the site to know that its data is being removed. [?]  banner>
>
> 1 - Disable LocalStorage completely when private browsing is on.
> Remove it from the DOM completely.
>
> Many sites will just assume that they know a given useragent supports
> localstorage, so they'll be surprised and break.
> This will mean that a user can't use certain sites.


For sure.


> 2 - Disable LocalStorage mostly when private browsing is on.  It
> exists at window.localStorage, but is empty and has a 0-quota.
>
> This will enable sites to know that the user is browsing in private,
> which is probably also a violation of the user's trust model.
> If I were to be browsing in private, I wouldn't want most sites to
> know that I'm doing this (which is why the banner i mention above must
> give the user the choice).


Is this a real concern?  Someone threw out the idea of explicitly making
this data available to at least extensions and maybe even websites.  I think
it might help sites act as the user would want.  In addition, websites know
you've visited them.  I'm not sure if knowing that it was in private mode
really changes things much.


> 3 - Slide a "fake" LocalStorage object in when private browsing is
> enabled.  It starts empty, changes to it are successful, but it is
> never written to disk.  When private browsing is disabled, all changes
> to the private browsing proxy are thrown out.
>

I'll point out that this is the "I'm at a public workstation and wiped all
data when I was done" model, which I believe is the right way to think of
it.


> 4 - Cover the real LocalStorage object with a private browsing layer.
> It starts with all previously stored contents.  Any changes to it are
> pretended to occur, but are never written to disk.  When private
> browsing is disabled, all items revert to the state they were in when
> private browsing was enabled and writing changes to disk is
> re-enabled.
>
> This means the site will know who you are (on average), and is almost
> certainly never what the user wants. If the user wants to tell the
> site who they are, then the user can log in after enabling private
> browsing.
>
> 5 - Treat LocalStorage as read-only when private browsing is on.  It
> exists, and all previously stored contents can be retrieved.  Any
> attempt to setItem(), removeItem(), or clear() fail.
>
> This acts like 4 and

Re: [whatwg] Private browsing vs. Storage and Databases

[Scott Hess]

On Tue, Apr 7, 2009 at 6:33 PM, Brady Eidson  wrote:
> On Apr 7, 2009, at 6:24 PM, Jeremy Orlow wrote:
>> Both would lead to bizarre behavior where data that the application
>> thought was saved really wasn't.
>>
>> This matches up with how most private browsing sessions handle cookies,
>> right?  The data persists until the session is up (because some of the web
>> can't work correctly without them) but then they're deleted at the end.
>
> I guess I'll raise this point yet again, as it's a favorite of mine...  ;)
>  Cookies are not expected to be persistent, and when space runs out for them
> and they're expired there is already no notification of that.  Any app
> writer that expected cookies to be a safe, persistent store of data or state
> was already playing with fire.

As I periodically learn to my continued dismay, the database hasn't
been invented which can surmount obstacles such as broken hardware and
systems which report success optimistically (as when fsync doesn't
really mean bits on the disk).  Any app running at scale WILL see
missing databases, and surprisingly frequently.I think that saying
that databases and cookies have the same expected persistence
characteristics is a reasonable first approximation.

-scott

Re: [whatwg] Private browsing vs. Storage and Databases

[Scott Hess]

On Tue, Apr 7, 2009 at 6:30 PM, Brady Eidson  wrote:
> On Apr 7, 2009, at 6:19 PM, Ian Fette (イアンフェッティ) wrote:
>> I think that doing option 3, and perhaps providing a way for the app to
>> know that we're in this mode so it can do whatever is appropriate (saving to
>> the cloud more frequently, just not using localstorage all together,
>> whatever is right for that app) solves those problems.
>
> I agree it is valuable for a page to know this mode is in effect, and it
> would be important for plug-ins as well which is why it's being discussed on
> some plug-ins lists.

Everyone is free to implement their privacy mode as they see fit, but
if apps can trivially tell they are in incognito mode, as opposed to
running on a constrained environment (low quota, etc), then I think
that sort of defeats the purpose.  I don't want apps refusing to
operate because they detect incognito mode, incognito is about _me_
not trusting _them_, not them deciding that I can't be trusted because
I'm acting shifty.

When in incognito mode, well-behaved apps should already prompt you
before throwing huge amounts of data at you, just like they would if
you visited from a fresh browser install, so I think that's mostly a
non-issue.

-scott

Re: [whatwg] Opera2d-game Extensions to Canvas: setPixel() and getPixel()--Ooops!

[Jeff Creamer]

Aiee...sorry for the trouble; cancel my earlier note.  [I realize
putImageData and getImageData fill the bill : /.]

Sincerely,

Jeff C.


Hi.  Since March of '06, Opera 9 has supported a custom extension to
the canvas context called "opera-2dgame." Importantly, their extension
adds these methods:

getPixel(x, y)
Returns the pixel value (colour, opacity) at (x, y). Returned in
the form #rrggbb if fully opaque and rgba(r, g, b, a) if it has some
alpha transparency. 

setPixel (x, y, color)
Allows you to set the colour of the pixel at (x, y). The third
argument should be a CSS color - you could provide a string such as
‘red’, a HTML colour code or even a rgba() value.

I don't see any recent discussion of this.  And I am also aware that
the canvas drawing model is not pixel-oriented.  Nonetheless, mightn't
these functions be extremely useful?  As the Opera folk point
out,  they bless game developers, and it occurs to me that they could
be used for other neat, useful things, such as giving _javascript_ a
rudimentary RAM drive.  Description including several demo programs and
a discussion of security issues is available here. 


Why not make getPixel () and setPixel() a standard?

Regards,

Jeff Creamer
Computing Instructor
Long Beach Unified School District
cream...@roadrunner.com

Re: [whatwg] Start position of media resources

[Silvia Pfeiffer]

On Wed, Apr 8, 2009 at 8:37 AM, David Singer  wrote:
> At 8:29  +1000 8/04/09, Silvia Pfeiffer wrote:
>>
>>  > My mental analogy was HTML, where an acnhor takes you to that part of
>> the
>>>
>>>  page as a convenience, but nothing stops you from navigating away.  And
>>> in
>>>  the case where the UA optimizes for showing that section (by suitable
>>>  handshakes/translations with the server), again, it could present a UI
>>> which
>>>  offers other times -- at the expense of more handshakes.
>>
>> Yes, I understand that analogy. But because video can be a very long
>> resource, media fragment URIs cannot be restriced to client-side
>> offsetting. Think e.g. about wanting the last 2 minutes out of a 5
>> hour discussion downloaded to your mobile phone.
>>
>> The media fragment WG decided that fragment addressing should be done
>> with "#" and be able to just deliver the actual fragment. (BTW: this
>> is in contrast to the temporal URIs that were specified for Annodex,
>> where chopping happened in the UA for "#"  and on the server for "?").
>
> But there is a huge difference between
>
> a) the UA MUST optimize for the chosen fragment, and may/should offer the
> rest of the resource to the user (at the possible expense of more network
> traffic)
>
> and
>
> b) the UA MUST only offer the chosen fragment to the user, and optimize
> network traffic and downloads for just that section, and MUST NOT allow
> navigation outside the indicated range
>
>
> Unfortunately, it does make a difference to the page author which of these
> is talked about (and, lacking anything else, (a) is probably what is
> expected).

Navigation outside the indicated range could be done in several ways -
it does not have to be through indicating the full length of the
resource in the timeline.

Cheers,
Silvia.

Re: [whatwg] Start position of media resources

[Silvia Pfeiffer]

On Wed, Apr 8, 2009 at 10:49 AM, Boris Zbarsky  wrote:
> Silvia Pfeiffer wrote:
>>
>> Note that in the Media Fragment working group even the specification
>> of http://www.example.com/t.mov#time="10s-20s"; may mean that only the
>> requested 10s clip is delivered
>
> Since the part starting with '#' isn't sent as part of the HTTP GET request,
> I'm not sure how this is envisioned to work.
>
> Is there a change to HTTP planned here?

It will all be done within the HTTP, but by transforming the fragment
into a new fragment range request. So, there are additions to HTTP
that are within the scope of HTTP.

Cheers,
Silvia.

Re: [whatwg] Start position of media resources

[Silvia Pfeiffer]

On Wed, Apr 8, 2009 at 11:21 AM, Ian Hickson  wrote:
> On Tue, 7 Apr 2009, Boris Zbarsky wrote:
>> Silvia Pfeiffer wrote:
>> > Note that in the Media Fragment working group even the specification
>> > of http://www.example.com/t.mov#time="10s-20s"; may mean that only the
>> > requested 10s clip is delivered
>>
>> Since the part starting with '#' isn't sent as part of the HTTP GET request,
>> I'm not sure how this is envisioned to work.
>>
>> Is there a change to HTTP planned here?
>
> Presumably one would use byte range requests as if the user had just
> seeked to the given time.

If a mapping between time and byte ranges is available, that is
possible. For most formats, that is however not the case. Therefore
there will be new time range requests that will be converted to byte
ranges on the server or a clever proxy.

> Ideally most videos wouldn't be sent using HTTP but using a more
> appropriate protocol that is designed for sending video; such protocols
> might have dedicated ways of jumping to particular times.

Most videos nowadays are sent using HTTP - in particular YouTube
videos. But we (in the media fragments WG) do indeed include RTP/RTSP
as another protocol that already includes mechanisms for requesting
time fragments.

Cheers,
Silvia.