Re: Simple approach for

[Scott Wilson]

In our implementation we plan to use the <access> information to provide the information needed for our whitelist proxy server; however it would be a hint to the administrator to confirm adding the whitelist rules requested by the widget rather than be an automated addition to the whitelist.

S

On 16 Apr 2009, at 16:23, Thomas Roessler wrote:

So far we haven't come across a widget thats needed more than - at most - access to a few services, all coded as a single URL or single domain. The only exception to the rule are RSS widgets, but these are right at the other end of the spectrum, and would need <access href="*"/>. I think the wording here is perhaps phrased in an 'inverted' way: <access> provides hints to the UA that it should permit access to the specified resource, its not about restricting restrict access to unspecified resources, which would seem to me to be entirely a question for the implementation. For example, Apache Shindig ships with completely open network access for widgets as the default.

Robin wrote:

The <access> element is used to restrict a widget's access to a
limited set of network resources. In the absence of an <access>
element, all access to network resources is forbidden.


is an IRI-like string. The access opening that is specified by that
string is defined as follows:

  - the scheme component MUST be present, and access is granted only
for that scheme; and
  - the host component MUST be present. If it begins with "*." then

its lower-level domains; otherwise access is only granted for that
domain; and
  - if the port component is absent, it is considered to be specified
to be the default for the provided scheme. Access is granted only to
that port; and
  - if the path and query string component is present, then access is
granted for any path and query string that starts with the specified
string. It is treated as an opaque string, no attempt must be made to
map to potential directories on the remote server; and
  - if a fragment component is specified, it must be ignored.

The <access> element has a single @href attribute the content of which the host that follows the "*." is granted access to, as well as all of

Two questions:







Thanks,
--
Thomas Roessler, W3C  <t...@w3.org>

1. How is the information in this access element going to be used at installation time or distribution time? I'd like to see some spec text that explains this. 2. If one of the risks we're interested in is firewall traversal, then then proposed domain name wildcard has a somewhat different risk profile than just a single domain name: while you can do a DNS rebinding attack for a single hostname, that's a well-known issue, and hopefully worked around in today's browser engines. With the wildcard, though, it becomes relatively easy to do firewall traversal: For example, one could simply generate DNS records n.n.n.n.example.com that point to the IP address n.n.n.n. I wonder whether it might be useful to clearly distinguish the two cases (given the different risk profiles); I'd also like to see some discussion of this effect in the security considerations.

smime.p7s
Description: S/MIME cryptographic signature