Loading ...
Sorry, an error occurred while loading the content.

The Mashup Problem

Expand Messages
  • Douglas Crockford
    A recent development in web application development is The Mashup. A mashup is a page that is obtaining data from multiple sources and producing a useful
    Message 1 of 5 , Jun 21, 2007
    • 0 Attachment
      A recent development in web application development is The Mashup. A
      mashup is a page that is obtaining data from multiple sources and
      producing a useful result. A popular example is getting listings from
      a real estate site, and applying that location data to the display
      from a mapping site.

      Mashups are sometimes represented as widgets or gadgets. They take up
      some visual space and cooperate to produce valuable services. This is
      a powerful indication of the evolution of web architecture.

      The Problem comes from applications getting significantly ahead of the
      security architecture of the browser. The browser assumes that all of
      the components of a page are equally trusted. All scripts run with the
      same authority and have access to all of the information and
      connections that are available to the page. The only exception is the
      iframe, which because of the Same Origin Policy is unable to cooperate
      with the other components at all. The Same Origin Policy is too
      restrictive, so developers are circumventing it by putting all scripts
      where the Same Origin Policy does not apply. This allows mashups to
      work, but it is dangerous.

      The Caplet Group is looking at a communications method that will allow
      putting widgets into iframes or worker pools, and allow them to safely
      exchange messages. This would give us a pattern for mashups which is
      not dangerous.

      The communications method would ultimately connect all our client
      technologies, including Flash, Silverlight, JavaFX, Yahoo Widgets, and
      advertisements. It will also allow communication with web services
      which conform to the method.

      The mission for this group is to recommend the interfaces and
      mechanisms for this communication method, and to show why it will be safe.
    • Mike Stay
      ... Which method is that? Or did you mean that the group trying to come up with one? -- Mike Stay stay@google.com
      Message 2 of 5 , Jun 21, 2007
      • 0 Attachment
        On 6/21/07, Douglas Crockford <douglas@...> wrote:
        > The Caplet Group is looking at a communications method that will allow
        > putting widgets into iframes or worker pools, and allow them to safely
        > exchange messages. This would give us a pattern for mashups which is
        > not dangerous.

        Which method is that? Or did you mean that the group trying to come
        up with one?
        --
        Mike Stay
        stay@...
      • Douglas Crockford
        ... Right. JavaScript is dependent on global variables. Because of that dependency, it is unlikely that JavaScript can ever be made secure. HTML s DOM
        Message 3 of 5 , Jun 22, 2007
        • 0 Attachment
          --- In caplet@yahoogroups.com, "Mike Stay" <stay@...> wrote:
          > Or did you mean that the group trying to come
          > up with one?
          > --
          > Mike Stay

          Right.

          JavaScript is dependent on global variables. Because of that
          dependency, it is unlikely that JavaScript can ever be made secure.
          HTML's DOM interface is similarly insecure.

          But if we step up a level, we have vats. The HTML page runs in a vat.
          Each iframe is a vat. Each worker in the Google Gears worker pool is a
          vat. All of the sandboxed client technologies are vatty.

          So I think we can solve a much simpler problem. I think it takes the
          form of a capability communications manager that can issue unguessable
          ids to each vat, provide message routing via those ids, and provide
          location services.

          It could be implemented in the short term as a browser extension, so
          we could enjoy a much faster adoption curve than if we had to wait for
          the browsers to be ungraded.

          It also could civilize the upcoming battle between Silverlight, Air,
          and JavaFX. A common capability communication mechanism would allow
          all of these technologies to be mashed up.
        • Helen Wang (MSR)
          This is a great topic for us to explore. We, from Microsoft Research, have been working on the MashupOS project. Back in March, we submitted a paper on the
          Message 4 of 5 , Jun 22, 2007
          • 0 Attachment
            This is a great topic for us to explore.
            We, from Microsoft Research, have been working on the MashupOS project. Back in March, we submitted a paper on the topic of protection and communication abstractions for web browsers. The submission is now accepted to SOSP 2007.

            I attached our submission version of the paper; we are working towards a camera-ready, final version of the paper -- so please don't distribute the paper without communicating with me first. We'd love to hear your feedback and critiques. I am particularly interested in hearing your thoughts on the "sandbox" abstraction/tag, and the "restricted service".

            Cheers,

            Helen

            > -----Original Message-----
            > From: caplet@yahoogroups.com [mailto:caplet@yahoogroups.com] On Behalf Of
            > Douglas Crockford
            > Sent: Thursday, June 21, 2007 11:48 AM
            > To: caplet@yahoogroups.com
            > Subject: [caplet] The Mashup Problem
            >
            > A recent development in web application development is The Mashup. A
            > mashup is a page that is obtaining data from multiple sources and
            > producing a useful result. A popular example is getting listings from
            > a real estate site, and applying that location data to the display
            > from a mapping site.
            >
            > Mashups are sometimes represented as widgets or gadgets. They take up
            > some visual space and cooperate to produce valuable services. This is
            > a powerful indication of the evolution of web architecture.
            >
            > The Problem comes from applications getting significantly ahead of the
            > security architecture of the browser. The browser assumes that all of
            > the components of a page are equally trusted. All scripts run with the
            > same authority and have access to all of the information and
            > connections that are available to the page. The only exception is the
            > iframe, which because of the Same Origin Policy is unable to cooperate
            > with the other components at all. The Same Origin Policy is too
            > restrictive, so developers are circumventing it by putting all scripts
            > where the Same Origin Policy does not apply. This allows mashups to
            > work, but it is dangerous.
            >
            > The Caplet Group is looking at a communications method that will allow
            > putting widgets into iframes or worker pools, and allow them to safely
            > exchange messages. This would give us a pattern for mashups which is
            > not dangerous.
            >
            > The communications method would ultimately connect all our client
            > technologies, including Flash, Silverlight, JavaFX, Yahoo Widgets, and
            > advertisements. It will also allow communication with web services
            > which conform to the method.
            >
            > The mission for this group is to recommend the interfaces and
            > mechanisms for this communication method, and to show why it will be safe.
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
          • Helen Wang (MSR)
            Sorry that the MashupOS paper I sent out earlier was defective. Here is a better copy: http://research.microsoft.com/%7Ehelenw/papers/mashupOS03-19-2007.pdf
            Message 5 of 5 , Jun 22, 2007
            • 0 Attachment
              Sorry that the MashupOS paper I sent out earlier was defective.
              Here is a better copy:
              http://research.microsoft.com/%7Ehelenw/papers/mashupOS03-19-2007.pdf

              We'd love to hear your feedback!

              Helen

              > -----Original Message-----
              > From: caplet@yahoogroups.com [mailto:caplet@yahoogroups.com] On Behalf
              > Of Douglas Crockford
              > Sent: Thursday, June 21, 2007 11:48 AM
              > To: caplet@yahoogroups.com
              > Subject: [caplet] The Mashup Problem
              >
              > A recent development in web application development is The Mashup. A
              > mashup is a page that is obtaining data from multiple sources and
              > producing a useful result. A popular example is getting listings from
              > a real estate site, and applying that location data to the display
              > from a mapping site.
              >
              > Mashups are sometimes represented as widgets or gadgets. They take up
              > some visual space and cooperate to produce valuable services. This is
              > a powerful indication of the evolution of web architecture.
              >
              > The Problem comes from applications getting significantly ahead of the
              > security architecture of the browser. The browser assumes that all of
              > the components of a page are equally trusted. All scripts run with the
              > same authority and have access to all of the information and
              > connections that are available to the page. The only exception is the
              > iframe, which because of the Same Origin Policy is unable to cooperate
              > with the other components at all. The Same Origin Policy is too
              > restrictive, so developers are circumventing it by putting all scripts
              > where the Same Origin Policy does not apply. This allows mashups to
              > work, but it is dangerous.
              >
              > The Caplet Group is looking at a communications method that will allow
              > putting widgets into iframes or worker pools, and allow them to safely
              > exchange messages. This would give us a pattern for mashups which is
              > not dangerous.
              >
              > The communications method would ultimately connect all our client
              > technologies, including Flash, Silverlight, JavaFX, Yahoo Widgets, and
              > advertisements. It will also allow communication with web services
              > which conform to the method.
              >
              > The mission for this group is to recommend the interfaces and
              > mechanisms for this communication method, and to show why it will be
              > safe.
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.