[whatwg] An BinaryArchive API for HTML5?
If this has already been covered just point me in that direction.
Assuming it hasn't...
What are people's feelings on adding a Binary Archive API to HTML5?
I'm sure for many that sets off alarms so let me try to describe what I mean
and a case for it.
It seems like it would be useful if there was browser API that let you
download something like gzipped tar files.
The API would look something like
var request = createArchiveRequest();
request.open("GET", "http://someplace.com/somearchive.tgz";);
request.onfileavailable = doSomethingWithEachFileAsItArrives;
request.send();
function doSomethingWithEachFileAsItArrives(binaryBlob) {
// Load every image in archive
if (binaryBlob.url.substr(-3) == ".jpg") {
var image = new Image();
image.src = binaryBlob.toDataURL(); // or something;
...
}
// Look for a specific text file
else if (binaryBlog.url === "myspecial.txt") {
// getText only works if binaryBlob is valid utf-8 text.
var text = binaryBlob.getText();
document.getElementById("content").innerHTML = text;
}
}
Hopefully from the example above you can see that a .tgz file is downloaded
and as each file becomes available it is handed to the JavaScript as binary
blobs through an onfileavailable callback. A blob can be passed to an img,
video, audio, assuming its in the correct format. It can also be gotten as a
string assuming it is valid utf-8
Why is this needed? Because with canvas tag and the upcoming 3dweb (canvas
3d) it will be common for an application to need to download thousands of
small files. A typical canvas 3d application will need all kinds of small
pieces of geometry data as well as hundreds of textures and sound files to
make even a modest game.
As it is now, each tag is apparently required to implement it's own network
stack for getting data. Image does things its way (progressively loading),
Video and Audio both support steaming. That's all great. But it seems like
as more and more types get added some support for a more centrally
implemented system would go a long way to helping some of these new APIs.
Thoughts?
Re: [whatwg] Canvas context.drawImage clarification
On Tue, Jul 28, 2009 at 4:07 AM, Aryeh Gregor > wrote: > On Tue, Jul 28, 2009 at 1:41 AM, Gregg Tavares wrote: > > It's ambiguous because images have a direction. An image that starts at > 10 > > with a width of -5 is not the same as an image that starts at 6 with a > width > > of +5 any more than starting in SF and driving 5 miles south is not the > same > > as starting in Brisbane and driving 5 miles north. > > > > The spec doesn't say which interpretation is correct. > > I think it's extremely clear. The spec gives four points which > determine a rectangle, which are in no particular order. The image is > rectangular, and is mapped into that rectangle. Rectangles have no > orientation, and the operation "paint the source region onto the > destination region" couldn't possibly be interpreted as requiring > reorientation of any kind. If it's so clear, why do you think 2 of the 4 browsers that implemented it apparently got it wrong? Would making the spec more explicit have avoided their mis-intepretation? > > > I think you got misled by the diagram, and now aren't reading the > normative text of the spec carefully enough -- it's *very* specific > (like most of HTML 5). >
Re: [whatwg] paths without a current point.
On Wed, 29 Jul 2009, Dean McNamee wrote: > > For the curves, I don't really get the point of moveTo()ing to one of > the control points. Me either, but at leave for quadratic and bezier curves, that seems to be what browsers do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTMLInputElement, "date" State, and Complexity
HTML 5 defines input type="date" as an input state. This is implemented in at least one userAgent (Opera). Which other browsers have implemented that? It seems like the added value to the programmer for valueAsDate appears to be convenience method to format to/parse from ISO 8601, but place on input as a behavior property, and working only when the input is in the "date" state. For setting[1], the convenience appears to be to set a date value when the Date's [[value]] is "valid", although a "valid" date does not seem to be mentioned, much less clearly defined, and the reference links to [GREGORIAN] are broken[1]. I can't see much other reason for having valueAsDate. Am I missing something? [1]http://www.whatwg.org/specs/web-apps/current-work/#valid-date-string Regards, Garrett
Re: [whatwg] Whitespace handling in ruby
On Thu, 30 Jul 2009 05:22:56 +0200, Roland Steiner wrote: (aside: an XHTML-like explicit container for the ruby base side-steps this problem, but is not a real option due to need for legacy support). "For the purposes of the CSS ruby model, runs of descendants of ruby elements that are not rt or rp elements are expected to be wrapped in anonymous boxes whose 'display' property has the value 'ruby-base'." http://www.whatwg.org/specs/web-apps/current-work/multipage/the-xhtml-syntax.html#display-types (That section also says rp should be display:block; shouldn't that be display:none instead?) -- Simon Pieters Opera Software
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Thu, Jul 30, 2009 at 11:09 AM, Maciej Stachowiak wrote: > On Jul 29, 2009, at 3:05 PM, Robert O'Callahan wrote: > > What happened to my idea for browsers to have a special window containing >> tabs for "background apps", which save screen real estate by just showing an >> icon and title (and a URL or domain?) and no actual tab content? You might >> modify the UI so that quitting the normal browser leaves this window open, >> possibly as a separate OS app. Seems to me that this would provide almost >> exactly the desired functionality but without introducing new security >> concerns and without requiring a trust decision. >> > > I haven't thought through this option in sufficient detail, but I'm not > sure that it resolves all of the risks I mentioned or the risks of content > outliving the page or the browser in general. Here's some questions that > come immediately to mind: > > 1) What exactly does the window look like? Just a normal tabbed browser > window with a window in each tab? I think users would find that confusing. I'm not a good person to design the appearance, but I was thinking of a specialized view, perhaps a narrow vertical list containing the favicon and the window title, with the domain or URL displayed on mouseover, plus a close box. Like a vertical list of tab headers. 2) What happens if users close the magic window (which likely they will, if > it's not obvious what it's for and just seems to be wasting real estate)? > Are all the background tasks killed or do they secretly keep running? Either > seems like a bad option. They die, that's the whole point I guess. There could be an alert before the window closes, like Firefox has today to warn about closing a window with many tabs. 3) In what way are users alerted to a new item being opened in the magic > window - is there a UI for this that can avoid being either too distracting > or too subtle? Again, I'm not the best person to design this, but the OS standard "window bounce" notification and highlighting of newly-inserted tabs until the window gets focus. Similar to the way, say, an IRC client like Colloquy alerts for a personal message being received. 4) Is it really ok for web content to survive browser quit and possibly even > reboot just because there is a visible indicator on screen, without some > explicit heavyweight form of user opt-in (like Prism)? I hope so, since you get that in Firefox today if a Web app opens a new window or tab and then you quit Firefox or reboot the machine. Firefox's session restore will offer to reopen the tabs and windows next time Firefox runs (along with a "don't ask me again" checkbox). I'm not sure it is. Especially if the magic window has tabs, if a number of > popular web apps start using it, then users will start to blank it out and > be vulnerable to the same kinds of risks I described (use for a botnet, > waiting for exploits to be found, etc). Possibly, I don't know how that would work out. But if a user has 100 tabs open that get automatically saved and restored across browser restarts, aren't we already faced with the same problem? (That is not an unusual scenario, apparently.) Given the risks I cited for the original form of the feature, I think we > need to keep in mind that a lot of the security risks are subtle and > insidious, and we need to be really cautious with any feature of this type. > I agree. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
[whatwg] Whitespace handling in ruby
As I am currently writing an implementation for ruby rendering, I wondered about the exact way white-space is supposed to be handled between runs of ruby text. As far as I see it, is fundamentally an inline element, and thus whitespace would normally be collapsed, but not entirely eliminated. However, for the examples given for the element, this would result in a single whitespace between the ideographic characters: *[ws]* 漢(かん) *[ws]* 字(じ) *[ws]* rendered without ruby support would become (easier for e-mail): 漢(かん)* [ws]* 字(じ) The whitespace would also be present with proper ruby rendering above the base characters. OTOH, removing those white-spaces may not be desirable if the bases are not ideographic scripts, e.g.: European(E) Union(U) (This example has yet another drawback: the white-space before "Union" would become part of the base and thus shift the annotation "U" slightly left of the center of the word "Union".) For the time being I'm using a block-based rendering approach that automatically eliminates leading and trailing white-space in the base text, but I wondered what the correct approach would be within the scope of HTML5 (aside: an XHTML-like explicit container for the ruby base side-steps this problem, but is not a real option due to need for legacy support). - Roland
Re: [whatwg] paths without a current point.
For the curves, I don't really get the point of moveTo()ing to one of the control points. Thanks -- dean On 7/29/09, Ian Hickson wrote: > On Thu, 16 Jul 2009, Dean McNamee wrote: > > > > Currently the spec says that if you call lineTo(), quadraticCurveTo(), > > bezierCurveTo(), etc without a "current point" (having called moveTo() > > first), they should do nothing. > > > The spec recently changed lineTo() quadraticCurveTo(), bezierCurveTo(), > and arcTo(). Please let me know if the recent changes aren't any good. > > Cheers, > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
[whatwg] HTML5 History Management
Ian et al.:
About a year ago, after I wrote the first version of my history
manager, I began the process of looking into the HTML5 history spec
and had a few conversations with folks like Bertrand Le Roy, Brad
Neuberg, and Brian Dillard. Some of my notes from back then have been
addressed, but I've still got a few more. Everything is included below
for your reading pleasure. Enjoy!
Nathan
***
Clarifications
1. window.history.pushState({}, "Title", "/path/to/new/file.html?
s=newvalue#newhash") replaces the current document object with the one
specified by the new URL. It then causes the event popstate to fire
immediately after the load event, correct?
2. window.history.pushState({}, "Title", "#newhash") creates a new
history state object with the specified data object, the specified
title, the same document object, and a location object that replaces
the existing hash with "#newhash", correct?
Possible Action Items
1. Specify the order in which history related events are triggered.
In what order would one expect the events triggered by
window.history.pushState({}, "Title", "#newhash")? There are two
events of interest: popstate, and hashchange. If popstate is fired
first it will make it easy to catch programmatic versus user changes
to the hash and respond accordingly. This would imply queueing the
popstate event prior to changing the URL when the document isn't
changing, or having the browser respond to the popstate event by
changing the hash. (This concern exists only when the new URL reuses
the same document object.) Regardless of the outcome, the order in
which these events are triggered really needs to be specified and each
individual triggering of these pair of events needs to be assured to
occur entirely before the next time the pair are triggered.
2. Specify a method to allow access to the history stack. (At least
readable within the context of same-origin, possibly mutable.)
This would allow for understanding on the client side of a user's path
through the site, even after navigating away from the page. If this is
not implemented the absolute first thing I will be implementing is a
method to track this information, a rather large duplication of effort
for something that could easily be made available. This would involve
a something like currentstate = { _previous: currentstate, title:
window.title, newval: true }; plus a form-based storage mechanism to
repopulate state in case the user exits on a page which they manually
changed the hash to get to (which would not have access to the data
object upon revisiting later since there wouldn't be one stored with
that history state).
I'm aware of the privacy ramifications, but at the same time, I'm
going to be exposing those exact same concerns with the above method.
3. Specify a method to modify the current history state without adding
a new history point.
This would alleviate the need for the (incredibly brittle) form-based
storage mechanism I describe above.
4. Specify additional properties on the hashchange event.
Lots of possible useful information with the number one most important
being the new hash that triggered the event to prevent race conditions
reading window.location.hash. Other fun things that are a bit more pie
in the sky: the previous hash and knowledge of how it was triggered
(manually? pushState? window.location.hash = ? window.location.href
= ?).
[whatwg] Stripping newlines from URI attributes
It seems that most browsers do some sort of newline and tab removal from URI
attributes. For example, if you have
browsers will still render the image called "foobar.jpg" despite the CRLF pair
in the middle of the src attribute. The behavior actually seems a bit more
complex; quote from one of my co-workers who investigated this:
> http://m.theglobeandmail.com/image-
> server/img//rO0ABXQAS2Z7aHR0cDovL2JldGEuaW1hZ2VzLnRoZWdsb2JlYW5kbWFpbC5jb20vaW1hZ2VzL21v
> YmlsZS9nYW1fZmxhZy5wbmd9dDBmMjg4dA==.png" alt="img" />
>
>
> alert( document.getElementById('bar').getAttribute('src').indexOf('\n') );
> alert( document.getElementById('bar').src.indexOf('\n') );
>
>
> Firefox and Sarafi both generate two alerts, 36 and -1.
>
> It seems mozilla ignores 0x09, 0x0a, 0x0d in the URI
> Whereas webkit seems to ignore 0x09, 0x0a, 0x0d in the path.
>
> Try putting a CRLF inside the authority and
> alert( document.getElementById('bar').src.indexOf('\n') );
>
> will return non -1 in safari. But will still fetch the image. Firefox seems
> to return -1 all the time.
>
> Opera is like firefox.
This behavior doesn't seem to be specced anywhere as far as I can tell.
Assuming the WEBADDRESSES spec referred to in HTML5 is the one at
http://www.w3.org/html/wg/href/draft.html that only says to trim
leading/trailing whitespace and url-encode the rest. This doesn't seem to match
existing behavior, so it should probably be updated.
On a related note, I was wondering if all these "spin-off" specs could be
listed somewhere easy to find; it took me a while to locate the web addresses
one and I had to use google to find it. Putting a list at, say,
http://www.whatwg.org/specs/ would be handy; or even better, the references
section in the HTML5 spec could list them.
Thanks,
kats
Re: [whatwg] Installed Apps
On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote: Hello folks - I'm an engineer on the Gmail team. We've been working on a prototype with the Chrome team to make the Gmail experience better. We thought we'd throw out our ideas to the list to get some feedback. THE PROBLEM We would like to enable rich internet applications to achieve feature parity with desktop applications. I will use Gmail and Outlook as examples for stating the problems we hope to solve. I already commented on the security risks of the proposed solution, but I'd also like to examine the use cases more closely. "Feature parity with desktop applications" is pretty open-ended, and it might be that the actual concrete use cases can be addressed with less general mechanisms. -- Slow startup: When a user navigates to mail.google.com, multiple server requests are required to render the page. The Javascript is cacheable, but personal data (e.g. the list of emails to show) is not. New releases of Gmail that require JS downloads are even slower to load. Caching the code part of GMail, and making loading fast in the face of updates, seems like a problem that can be solved by the HTML5 Application Cache. Maybe it would be more fruitful to study further improvements in startup speed once GMail has adopted AppCache. -- Native apps like Outlook can (and do) run background processes on the user's machine to make sure that data is always up-to-date. -- Notifications: Likewise, Outlook can notify users (via a background process) when new mail comes in even if it's not running. I'm not sure it's justifiable to say these features are required for a native-like experience. The Mail application on Mac OS X only fetches new mail and gives you new mail notifications while it is actually running. Users who want to know about new mail right away keep the app open, and users who would like to free up resources quit it. It seems like GMail can already get rough parity with this experience. That being said, I think there are valid use cases for out-of-band notifications, for example for calendar events or "status update" type applications such as Facebook or Twitter. I'd like to explore whether we can accommodate this notification use case without bringing the full power of the Web platform to bear, and thereby opening up a lot of attack surface on the client. Here's one rough sketch of an idea: * Notification Feeds * Often, web applications would like to give users the option to subscribe to notifications that occur at specific times or in response to server-side events, and for the user to get these UI notifications without a prerequisite that the web app is open or that the browser is running. There may be a desire to do client-side computation as well, but often just the ability to give the user a notification solves the basic user interaction problem. One possible way to address this kind of use case is to let users subscribe to a "feed" of notifications. This feed could use standard syndication formats, such as RSS or Atom. But instead of being displayed in a traditional feed reader, it's displayed in the form of transient notifications (along the lines of Growl on Mac OS X) which are posted for each new event. To allow some pre-scheduling of events, each item can have a date and won't be displayed until that date - this way a calendar can give you your feed of upcoming events and you can still get notifications when offline. In the case of something like email or Twitter, obviously there's no sensible way to get notifications when offline since they depend on unpredeictable server- side activity. There could even be a client-side API that lets a Web app schedule items on a subscribed notification feed from script, to enable scheduling calendar events offline. Each notification would have the option to unsubscribe from the notification feed, to reduce spam potential. Notice that this opens up a lot less attack surface. The user has to actively opt in to subscribing to the notification feed, just as for an RSS feed. This makes it much less likely they end up with a subscription to a shady site. And the notifications are passive data items (probably no script should be allowed in a notification, if the format is HTML and not just plain text), so they open up a lot less security risk. Obviously this is less powerful than the ability to run arbitrary code in the background. But it could address a large chunk of the use cases with much less security risk. I'd like us to think along these kinds of lines when expanding the web platform. Often there is a low-power alternative to fully general solutions, which addresses many of the same use cases. By proceeding in this manner, we can extend the power of the web platform without neutering its desirable security properties. Regards, Maciej
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
From: "Maciej Stachowiak" Sent: Wednesday, July 29, 2009 6:09 PM Given the risks I cited for the original form of the feature, I think we need to keep in mind that a lot of the security risks are subtle and insidious, and we need to be really cautious with any feature of this type. Regards, Maciej The security issues is one reason the Chrome way of doing things appeals to me. It's just a regular tab, but it gives some superficial functionality (shortcut, slim window, separation from browser) to look and act like an application.
Re: [whatwg] [html5] r3429 - [e] (0) Add a section on establishing a connection.
On Fri, 17 Jul 2009, Smylers wrote: > wha...@whatwg.org writes: > > > + The Web Socket protocol is an independent TCP-based > > + protocol. It's only relationship to HTTP ... > > An apostrofly has crept in there. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Security risks of persistent background content (Re:Installed Apps)
On Wed, Jul 29, 2009 at 6:54 PM, Robert O'Callahan wrote: > The Windows notification area isn't obtrusive enough for my security comfort > (even if you exclude the auto-icon-hiding stuff it does, which I don't > really understand). I think the logic there is "third-party apps put millions of useless icons there, so hide them because we're a closed-source ecosystem and can't fix the apps". It seems to be too aggressive in my experience, though. > Taskbar/Dock is OK. A dedicated window is probably > better. I'd like the option to keep just one browser window. I think some screen real estate could be set aside in the main window that only displays favicons until the user shows interest (by hovering/clicking/etc.). An informative notification could pop up the first time this happens, like maybe a balloon, and thereafter a one-sentence explanation could be given if the user hovers over the icons. Then what happens when the browser closes? The usual approach taken by apps that want to remain persistent in the background (like IM applications) is, in my experience, to display a dialog when they're closed saying "I'm going to stay running, right-click my icon in the notification area to really close me", then just stay as an icon in the notification area. The user is therefore aware that the program is running, at least in theory. I think Maciej is right that this doesn't fully address the botnet concerns, however.
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Jul 29, 2009, at 3:05 PM, Robert O'Callahan wrote: What happened to my idea for browsers to have a special window containing tabs for "background apps", which save screen real estate by just showing an icon and title (and a URL or domain?) and no actual tab content? You might modify the UI so that quitting the normal browser leaves this window open, possibly as a separate OS app. Seems to me that this would provide almost exactly the desired functionality but without introducing new security concerns and without requiring a trust decision. I haven't thought through this option in sufficient detail, but I'm not sure that it resolves all of the risks I mentioned or the risks of content outliving the page or the browser in general. Here's some questions that come immediately to mind: 1) What exactly does the window look like? Just a normal tabbed browser window with a window in each tab? I think users would find that confusing. 2) What happens if users close the magic window (which likely they will, if it's not obvious what it's for and just seems to be wasting real estate)? Are all the background tasks killed or do they secretly keep running? Either seems like a bad option. 3) In what way are users alerted to a new item being opened in the magic window - is there a UI for this that can avoid being either too distracting or too subtle? 4) Is it really ok for web content to survive browser quit and possibly even reboot just because there is a visible indicator on screen, without some explicit heavyweight form of user opt-in (like Prism)? I'm not sure it is. Especially if the magic window has tabs, if a number of popular web apps start using it, then users will start to blank it out and be vulnerable to the same kinds of risks I described (use for a botnet, waiting for exploits to be found, etc). Given the risks I cited for the original form of the feature, I think we need to keep in mind that a lot of the security risks are subtle and insidious, and we need to be really cautious with any feature of this type. Regards, Maciej
Re: [whatwg] Security risks of persistent background content (Re:Installed Apps)
On Thu, Jul 30, 2009 at 10:30 AM, Michael Kozakewich < mkozakew...@icosidodecahedron.com> wrote: > > How many applications do we expect any one user to have open? I would > imagine one would do fine on the Taskbar or in the Notification Area, like > other programs, but a manager would be good if a user had a great deal of > applications running at once. > The Windows notification area isn't obtrusive enough for my security comfort (even if you exclude the auto-icon-hiding stuff it does, which I don't really understand). Taskbar/Dock is OK. A dedicated window is probably better. Whether you quit the main browser or not, the browser process would have to > remain loaded, correct? Otherwise, it would be impossible to render pages. > Some browser process would have to remain loaded, yes, but that's true for any approach that lets pages run persistently with Web APIs. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Thu, Jul 30, 2009 at 10:15 AM, Tab Atkins Jr. wrote: > On Wed, Jul 29, 2009 at 5:05 PM, Robert O'Callahan > wrote: > > What happened to my idea for browsers to have a special window containing > > tabs for "background apps", which save screen real estate by just showing > an > > icon and title (and a URL or domain?) and no actual tab content? You > might > > modify the UI so that quitting the normal browser leaves this window > open, > > possibly as a separate OS app. Seems to me that this would provide almost > > exactly the desired functionality but without introducing new security > > concerns and without requiring a trust decision. > > I think I didn't understand what you were talking about the first time > through! > > How does inter-tab (inter-process) communication work here, then? > Except for the persistence issue, we already have specced methods for > handling this sort of thing, and it seems like it would be best to > solve any communication/manipulation issues there first, then tack on > something to help persist things. Separate issue. I'm just addressing the persistence needs here. Communication between tabs in the same domain is easier to solve, it doesn't bring up any new security issues. Also: would these pages be regenerated automatically when the browser > is reopened? > Up to the browser, but sure, if you quit the app holding the background tabs and then relaunch it, it's fine to reopen those tabs. It's just like the session management that browsers already offer. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Security risks of persistent background content (Re:Installed Apps)
From: Robert O'Callahan Sent: Wednesday, July 29, 2009 5:05 PM What happened to my idea for browsers to have a special window containing tabs for "background apps", which save screen real estate by just showing an icon and title (and a URL or domain?) and no actual tab content? You might modify the UI so that quitting the normal browser leaves this window open, possibly as a separate OS app. Seems to me that this would provide almost exactly the desired functionality but without introducing new security concerns and without requiring a trust decision. Rob How many applications do we expect any one user to have open? I would imagine one would do fine on the Taskbar or in the Notification Area, like other programs, but a manager would be good if a user had a great deal of applications running at once. The manager would have to stay out of the way, though; either by being called up through a menu option, like the downloads page, or by minimizing to the notification area. Whether you quit the main browser or not, the browser process would have to remain loaded, correct? Otherwise, it would be impossible to render pages. The browser itself IS a desktop app, and has a lot of freedom; it could stay silently in the background, or manage the applications itself, or give certain rendering abilities to the application window. As such, we should keep it in mind while we plan. An API for browsers to spin off a website as another application would be something to look into.
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Wed, Jul 29, 2009 at 5:05 PM, Robert O'Callahan wrote: > What happened to my idea for browsers to have a special window containing > tabs for "background apps", which save screen real estate by just showing an > icon and title (and a URL or domain?) and no actual tab content? You might > modify the UI so that quitting the normal browser leaves this window open, > possibly as a separate OS app. Seems to me that this would provide almost > exactly the desired functionality but without introducing new security > concerns and without requiring a trust decision. I think I didn't understand what you were talking about the first time through! How does inter-tab (inter-process) communication work here, then? Except for the persistence issue, we already have specced methods for handling this sort of thing, and it seems like it would be best to solve any communication/manipulation issues there first, then tack on something to help persist things. Also: would these pages be regenerated automatically when the browser is reopened? ~TJ
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Wed, Jul 29, 2009 at 6:05 PM, Robert O'Callahan wrote: > What happened to my idea for browsers to have a special window containing > tabs for "background apps", which save screen real estate by just showing an > icon and title (and a URL or domain?) and no actual tab content? You might > modify the UI so that quitting the normal browser leaves this window open, > possibly as a separate OS app. Seems to me that this would provide almost > exactly the desired functionality but without introducing new security > concerns and without requiring a trust decision. Hmm. This does sound like a good solution.
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Wed, Jul 29, 2009 at 1:39 PM, Drew Wilson wrote: > Agreed that this is a big deal, and is a problem I hadn't considered > previously. I would assume that browser malware detection would blacklist > these sites, but I hate to lean on some magical malware detection > infrastructure too heavily. This seems like an issue that Apple and > Microsoft have dealt with for years in their OS offerings - how do they > handle this? Why have they dealt with it? We're talking about trying to break out of a sandbox, by running code persistently in the sandbox until an exploit is discovered and you can push out appropriate code to all infected sandboxes. I don't see any parallel situation for general-purpose operating systems. Not much is run sandboxed on Windows or Mac. If you get any unsandboxed code running, then your exploit is finished. Theoretically someone could get unprivileged code running on a normal OS, then wait for a privilege escalation exploit to come along and get root access then. But it's rare that a hacker will care about getting administrative access. With user-level access you can still steal private data (probably all of it on a single-user machine) and use pretty much any system resources you like. The only thing unprivileged access won't give you is the ability to freely interfere with other users on the machine -- it doesn't stop you from joining a botnet.
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
What happened to my idea for browsers to have a special window containing tabs for "background apps", which save screen real estate by just showing an icon and title (and a URL or domain?) and no actual tab content? You might modify the UI so that quitting the normal browser leaves this window open, possibly as a separate OS app. Seems to me that this would provide almost exactly the desired functionality but without introducing new security concerns and without requiring a trust decision. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlow wrote: > On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson wrote: > >> On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr. >> wrote: >> > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson >> wrote: >> >> With a hidden page that's accessible to all Google Finance visible >> >> pages, they could share a connection to the server. Even if the hidden >> >> page is closed when the last Google Finance page is closed, this is a >> >> better situation than we currently have. >> > >> > Can't SharedWorkers do that right now? If all you're doing is polling >> > for data, it seems like you don't need all the extra stuff that these >> > various proposals are offering. >> >> It's my contention that frequently large web apps are doing more than >> just polling for data. They're trying to maintain complex data >> structures that they pass up to the UI. The programming model of >> SharedWorkers makes this difficult. Take the chat client in Gmail, for >> example. It's much more complex than passing stock quotes from a >> worker to the UI. > > > I understand that this isn't helpful for existing web apps like Gmail, but > I think a MVC type model will work pretty nicely with shared workers. It's > just the transition phase that's going to be painful. > > This idea of a hidden page just seems like a big hack to support today's > applications. If it were adapted into the spec, I think 5 years from now > we'd be very sorry that it was. > I disagree. The proposal plays to the strenths of the web platform. HTML parsing, layout, and rendering is very optimized, much more so than programmatic HTML DOM manipulation. The incorporation of stateful script contexts within each page considerably slows page loading. As navigations occur, that statefullness has to be reconstructed from scratch. In addition to creating and populating a new script context with the
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
On Wed, Jul 29, 2009 at 1:58 AM, Maciej Stachowiak wrote: > Here's some security risks I've thought about, for persistent workers and > persistent background pages: > > . . . The problems you lay out seem basically insurmountable for anything with a significantly less cumbersome and scary UI than extensions. Would it be valuable to recast this discussion as "let's standardize some type of browser extension"? So that authors could write a limited sort of cross-browser extension, basically? I'm not suggesting a change in the proposed feature set, just a different way of looking at the issue in terms of UI.
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 1:53 PM, Jeremy Orlow wrote: > I understand that this isn't helpful for existing web apps like Gmail, but I > think a MVC type model will work pretty nicely with shared workers. It's > just the transition phase that's going to be painful. In most MVC frameworks that I'm aware of, you can make a synchronous call from M up to V or V down to M. It's not just MVC, it's MVC where the C is entirely asynchronous. Michael
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 11:43 AM, Michael Davidson wrote: > On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr. > wrote: > > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote: > >> With a hidden page that's accessible to all Google Finance visible > >> pages, they could share a connection to the server. Even if the hidden > >> page is closed when the last Google Finance page is closed, this is a > >> better situation than we currently have. > > > > Can't SharedWorkers do that right now? If all you're doing is polling > > for data, it seems like you don't need all the extra stuff that these > > various proposals are offering. > > It's my contention that frequently large web apps are doing more than > just polling for data. They're trying to maintain complex data > structures that they pass up to the UI. The programming model of > SharedWorkers makes this difficult. Take the chat client in Gmail, for > example. It's much more complex than passing stock quotes from a > worker to the UI. I understand that this isn't helpful for existing web apps like Gmail, but I think a MVC type model will work pretty nicely with shared workers. It's just the transition phase that's going to be painful. This idea of a hidden page just seems like a big hack to support today's applications. If it were adapted into the spec, I think 5 years from now we'd be very sorry that it was. The other APIs we've been talking about that satisfy the requirements that were originally broken out by Drew seem like much more sustainable solutions. J
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
I intended the "resistant to malice and incompetence" definition of safe, not the idempotent definition of safe. Thanks for clarifying. Even in a world of exceptionally sophisticated applications, now and in the future, I think it is worth preserving the safe and stateless properties of the web. The challenge is exposing new capabilities in a way that is compatible with those properties. Naively bringing over APIs from desktop apps may not always work. For example, a typical desktop app can, at any time, read all of my files. Web apps need access to files too, but I don't want every web page see all my files. The API and UI were designed to grant access to only the files I want to make available, and do so in a way that is natural. Even in this simple case there were subtle security issues that took years to emerge and address. We need to take a similar approach with other new capabilities without adding a new install escape hatch to the web. For capabilities where we aren't yet clever enough to come up with a safe and stateless solution, using the existing install mechanism of extensions and their attendant security features seems like a good way forward. Linus On Wed, Jul 29, 2009 at 11:15 AM, Drew Wilson wrote: > I'd agree with #1, for some given value of "safe" - we've all heard tales > of search engines inadvertently deleting data on people's sites by following > links. Note that web storage violates #2 and #3 (and even cookies could be > viewed as a violation of #2, depending on how broadly you view "caches"). > But I would agree that what you've mentioned below are characteristics of > traditional web browsing. If we went back in time several years, we might > have added in some restrictions about how "data is only posted to the server > in response to explicit user activity/form submittal". I think we should be > open to the possibility that the characteristics of web browsing today are > not necessarily inherent to the web browsing experience, and may change over > time. Should web browsing in 2020 look like web browsing in 2010? Will web > pages still be restricted to a sandbox with a close button? > > It seems like the tenets below are quite appropriate for the "browser as > content-delivery platform". But they are already starting to change for > "browser as application platform". The challenge is to balance the safety of > a content-delivery platform while still giving applications the power they > need. > > -atw > > On Wed, Jul 29, 2009 at 10:48 AM, Linus Upson wrote: > >> This is a good analysis. I agree that it is important for the web to >> maintain some important properties that are in conflict with persistent >> background processing: >> 1. All links are safe to click >> >> 2. When a page is closed, the only artifacts left behind are items in >> various caches >> >> 3. The user agent is free to evict items from its various caches at any >> time >> >> For apps that desire capabilities that are not "safe and stateless" I like >> your suggestion to use the browser's extension mechanism (or runtimes such >> as prism or air). Those services usually involve some combination of >> multiple affirmative steps, vetting, reputation and revocation. >> >> Linus >> >> >> On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak wrote: >> >>> >>> On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote: >>> >>> I've been kicking around some ideas in this area. One thing you could do with persistent workers is restrict network access to the domain of that worker if you were concerned about botnets. That doesn't address the "I installed something in my browser and now it's constantly sucking up my CPU" issue, but that makes us no different than Flash :-P >>> >>> Here's some security risks I've thought about, for persistent workers and >>> persistent background pages: >>> >>> 1) If they have general-purpose network access, they are a tool to build >>> a DDOS botnet, or a botnet to launch attacks against vulnerable servers. >>> >>> 2) If they do not have general-purpose network access, this can be worked >>> around with DNS rebinding. Note that ordinarily, DNS rebinding is only >>> considered a risk for content protect by network position. But in the case >>> of a DDOS or attempt to hunt for server vulnerabilities, this doesn't matter >>> - the attack doesn't depend on the DDOS node sending credentials. >>> >>> 3) If they have notification capabilities, they can be used for >>> advertising spam. >>> >>> 4) If they have general network access only while a page from the same >>> domain is displayed, then they can use a misleading notification to trick >>> the user into going to a page on that domain, to gain network general >>> network access at the moment it's needed. >>> >>> 5) Even if they only have same-domain network access, they can be used to >>> create a botnet for computation - for example for purposes like distributed >>> password cracking. >>> >>> 6) They can be used to g
Re: [whatwg] paths without a current point.
On Thu, 16 Jul 2009, Dean McNamee wrote: > > Currently the spec says that if you call lineTo(), quadraticCurveTo(), > bezierCurveTo(), etc without a "current point" (having called moveTo() > first), they should do nothing. The spec recently changed lineTo() quadraticCurveTo(), bezierCurveTo(), and arcTo(). Please let me know if the recent changes aren't any good. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issues with Web Sockets API
On Wed, Jul 29, 2009 at 1:33 AM, Ian Hickson wrote: > > > Yes. But that's the case anyway -- events are asynchronous, so consider > the case of receiving two messages. Both are queued up, then eventually > the first is dispatched. If in response to that you close the connection, > that doesn't stop the second being dispatched, since it was already queued > up. > I'd note that this conforms to the behavior of MessagePorts - close disentangles the ports, but already-received/queued messages are still delivered.
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 11:38 AM, Tab Atkins Jr. wrote: > On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote: >> With a hidden page that's accessible to all Google Finance visible >> pages, they could share a connection to the server. Even if the hidden >> page is closed when the last Google Finance page is closed, this is a >> better situation than we currently have. > > Can't SharedWorkers do that right now? If all you're doing is polling > for data, it seems like you don't need all the extra stuff that these > various proposals are offering. It's my contention that frequently large web apps are doing more than just polling for data. They're trying to maintain complex data structures that they pass up to the UI. The programming model of SharedWorkers makes this difficult. Take the chat client in Gmail, for example. It's much more complex than passing stock quotes from a worker to the UI. Michael
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
On Wed, 29 Jul 2009, Michael Nordman wrote: > > 'Named' cache groups under a single manifest url is an interesting idea. > Presumably the webapp would be generating the 'name' in the manifest > file based on a cookie value. Another possibility is something along the > lines of what is proposed in the DataCache draft: the manifest indicates > a cookie name, and the value of that cookie determines the 'name' of the > subgroup. And the value of that cookie also determines which subgroup is > enabled at any given time. I'm reluctant to do anything explicitly based on cookies because that would link two features in a way that might not be useful for all authors. In general I'd much rather we keep features of the Web platform orthogonal. For example, I'd want appcache to also work with HTTP auth, or with some other authentication mechanism over FTP, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 1:34 PM, Michael Davidson wrote: > Here's something that hidden pages can help with that this solution can't: > > Let's say you're watching ten stocks on Google Finance, each in their > own window. > > Right now, each page has to have its own connection to the server. > Since these are polling connections, the experience is going to be > very bad. > > With a hidden page that's accessible to all Google Finance visible > pages, they could share a connection to the server. Even if the hidden > page is closed when the last Google Finance page is closed, this is a > better situation than we currently have. Can't SharedWorkers do that right now? If all you're doing is polling for data, it seems like you don't need all the extra stuff that these various proposals are offering. ~TJ
Re: [whatwg] Installed Apps
As another data point, the aforementioned Jetpack addon for Firefox actually *does* run in a hidden page. "about:jetpack" is *always* present while the add-on is installed, but hidden if you haven't explicitly pointed a tab at that url. This doesn't allow it to persist outside of the browser, but it does allow it to persist outside of the page. ~TJ
Re: [whatwg] Installed Apps
Here's something that hidden pages can help with that this solution can't: Let's say you're watching ten stocks on Google Finance, each in their own window. Right now, each page has to have its own connection to the server. Since these are polling connections, the experience is going to be very bad. With a hidden page that's accessible to all Google Finance visible pages, they could share a connection to the server. Even if the hidden page is closed when the last Google Finance page is closed, this is a better situation than we currently have. Michael
Re: [whatwg] Installed Apps
From: Drew Wilson
Sent: Wednesday, July 29, 2009 11:56 AM
On Wed, Jul 29, 2009 at 6:32 AM, Michael Kozakewich
wrote:
-- Notifications: I don't think I've ever had Outlook notify me of new mail
when it's not running. It usually starts up with Windows, and it runs in the
background. If you turn it off from the tray, it stops.
The way I've envisioned any of these "persistent running workers/pages"
operating is the browser would have a status bar icon which would allow
background apps to display status, and also give the user the opportunity to
exit the browser or (possibly) close down individual apps. So it's a very
similar situation.
Have you ever used Chrome's 'Create Application Shortcuts...'? It's pretty neat
how they work. You get a mini UI with an option button (also the favicon), the
title, and the mimize/maximize/close buttons. The rest is the site itself. It's
actually a modified browser tab, but you'd never know it just by looking at it.
I can close Chrome, and that one modified tab with Google Reader will still be
open. I've sized it to fit in a specific part of my desktop, so it's really
completely separate from the browser (except that, if you look in Task Manager,
the main browser process remains open, invisibly, in the background). It even
keeps my sizing and positioning preferences, so it'll open in the same place
next time I open it. I've got a shortcut to it on my Quick Launch bar, set to a
fancy 'Web 2.0' RSS icon. Every once in a while, I can glance to the title of
the 'application' or my Taskbar, and the number of new feeds is auto-updated
right there. I don't think it can pop up a notification, yet, but I'd love it
to play a sound when it finds more feeds.
If you want, you can also click the favicon (or right click on its taskbar
button) and select "Show as Tab" from the menu, then drag that into the browser
with the rest of your tabs.
The salient bits:
-Browser interface is gone: lets the page have its own navigation/toolbars.
-In the background is a hidden process, which writes the DOM and keeps the
window open.
-That background process isn't a hidden page, but rather the browser process
itself.
-You can open it with a link, which can starts with Windows if put in the
Startup folder.
-It can be given a custom icon.
The problems:
-No notification messages
-No minimization to the notification area
-95% of the web can't use it without switching browsers.
The solution:
-Get other browsers to adopt certain elements from this
-Get everyone to agree on a notification API
-Allow the option of minimizing to notification area ("Hide window when
minimized").
What I'd like is to hear of anything this doesn't solve. Can invisible pages do
anything that the invisible browser can't? An invisible page controlling a
visible page would still need the browser to be open, so we'd actually have one
less page open if it was just the browser and the page. Browsers could also add
an option where they'd secretly stay on in the background, without being any
less secure than it would be to have your browser sitting open right now.
Is it easier that we ask browser vendors to implement these changes, or to
create the whole hidden-page spec?
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 12:54 PM, Drew Wilson wrote: > My understanding (when I looked at Prism a while back) was that it was > essentially no different than a desktop shortcut that ran the page in a > separate profile. Has this changed? It runs a webpage in a separate process, in a special environment with minimal chrome, elevated privileges and a few other changes from a browser. Running in a separate process means that it's not affected by browser closings or crashes. On the wishlist for features is the ability to have a taskbar icon with balloon popups. ~TJ
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
I'd agree with #1, for some given value of "safe" - we've all heard tales of search engines inadvertently deleting data on people's sites by following links. Note that web storage violates #2 and #3 (and even cookies could be viewed as a violation of #2, depending on how broadly you view "caches"). But I would agree that what you've mentioned below are characteristics of traditional web browsing. If we went back in time several years, we might have added in some restrictions about how "data is only posted to the server in response to explicit user activity/form submittal". I think we should be open to the possibility that the characteristics of web browsing today are not necessarily inherent to the web browsing experience, and may change over time. Should web browsing in 2020 look like web browsing in 2010? Will web pages still be restricted to a sandbox with a close button? It seems like the tenets below are quite appropriate for the "browser as content-delivery platform". But they are already starting to change for "browser as application platform". The challenge is to balance the safety of a content-delivery platform while still giving applications the power they need. -atw On Wed, Jul 29, 2009 at 10:48 AM, Linus Upson wrote: > This is a good analysis. I agree that it is important for the web to > maintain some important properties that are in conflict with persistent > background processing: > 1. All links are safe to click > > 2. When a page is closed, the only artifacts left behind are items in > various caches > > 3. The user agent is free to evict items from its various caches at any > time > > For apps that desire capabilities that are not "safe and stateless" I like > your suggestion to use the browser's extension mechanism (or runtimes such > as prism or air). Those services usually involve some combination of > multiple affirmative steps, vetting, reputation and revocation. > > Linus > > > On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak wrote: > >> >> On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote: >> >> I've been kicking around some ideas in this area. One thing you could do >>> with persistent workers is restrict network access to the domain of that >>> worker if you were concerned about botnets. That doesn't address the "I >>> installed something in my browser and now it's constantly sucking up my CPU" >>> issue, but that makes us no different than Flash :-P >>> >> >> Here's some security risks I've thought about, for persistent workers and >> persistent background pages: >> >> 1) If they have general-purpose network access, they are a tool to build a >> DDOS botnet, or a botnet to launch attacks against vulnerable servers. >> >> 2) If they do not have general-purpose network access, this can be worked >> around with DNS rebinding. Note that ordinarily, DNS rebinding is only >> considered a risk for content protect by network position. But in the case >> of a DDOS or attempt to hunt for server vulnerabilities, this doesn't matter >> - the attack doesn't depend on the DDOS node sending credentials. >> >> 3) If they have notification capabilities, they can be used for >> advertising spam. >> >> 4) If they have general network access only while a page from the same >> domain is displayed, then they can use a misleading notification to trick >> the user into going to a page on that domain, to gain network general >> network access at the moment it's needed. >> >> 5) Even if they only have same-domain network access, they can be used to >> create a botnet for computation - for example for purposes like distributed >> password cracking. >> >> 6) They can be used to greatly extend the window of vulnerability from >> visiting a malicious site once. Consider the model where a browser patches a >> security vulnerability, and users apply the patch over some period after >> it's released. Assuming the vulnerability wasn't already known to attackers, >> users are at risk if they visit a malicious site in the period between >> release of the patch and install of the patch. But with persistent workers >> (or background pages) in the picture, users can be vulnerable if they have >> *every* visited a malicious site - because it could have installed a >> persistent worker that periodically "phones home" for exploit code to try. >> This can greatly increase the number of people who can be affected by a >> malicious web page, and therefore greatly increases the incentive to try >> such a thing. This works even with just same-doman network access. I think >> this risk is really serious because it makes every future browser >> vulnerability much more dangerous. >> >> 7) Even with only same-domain network access, the persistent worker could >> periodically "phone home" to allow tracking of the user by IP, which can be >> mapped to an approximate physical location. Normally, a page you don't have >> open can't do that to you. >> >> This list isn't necessarily exhaustive, I'm sure there's more risks I >>
Re: [whatwg] Installed Apps
My understanding (when I looked at Prism a while back) was that it was essentially no different than a desktop shortcut that ran the page in a separate profile. Has this changed? -atw On Wed, Jul 29, 2009 at 10:21 AM, timeless wrote: > On Wed, Jul 29, 2009 at 7:56 PM, Drew Wilson wrote: > > What I'd like, as a user, is some way to pin selected apps to run in the > > background - whether that's something I initiate through the UI myself, > or > > via a prompt from the application is really a matter of UX. > > in my book, you're definitely asking for prism. > > http://labs.mozilla.com/projects/prism/ > https://wiki.mozilla.org/prism > > and here's a prism link for google calendar: > http://starkravingfinkle.org/projects/webrunner/gcalendar.webapp > > there should and will be more documentation about how these bundles are > exposed. >
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
This is a good analysis. I agree that it is important for the web to maintain some important properties that are in conflict with persistent background processing: 1. All links are safe to click 2. When a page is closed, the only artifacts left behind are items in various caches 3. The user agent is free to evict items from its various caches at any time For apps that desire capabilities that are not "safe and stateless" I like your suggestion to use the browser's extension mechanism (or runtimes such as prism or air). Those services usually involve some combination of multiple affirmative steps, vetting, reputation and revocation. Linus On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak wrote: > > On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote: > > I've been kicking around some ideas in this area. One thing you could do >> with persistent workers is restrict network access to the domain of that >> worker if you were concerned about botnets. That doesn't address the "I >> installed something in my browser and now it's constantly sucking up my CPU" >> issue, but that makes us no different than Flash :-P >> > > Here's some security risks I've thought about, for persistent workers and > persistent background pages: > > 1) If they have general-purpose network access, they are a tool to build a > DDOS botnet, or a botnet to launch attacks against vulnerable servers. > > 2) If they do not have general-purpose network access, this can be worked > around with DNS rebinding. Note that ordinarily, DNS rebinding is only > considered a risk for content protect by network position. But in the case > of a DDOS or attempt to hunt for server vulnerabilities, this doesn't matter > - the attack doesn't depend on the DDOS node sending credentials. > > 3) If they have notification capabilities, they can be used for advertising > spam. > > 4) If they have general network access only while a page from the same > domain is displayed, then they can use a misleading notification to trick > the user into going to a page on that domain, to gain network general > network access at the moment it's needed. > > 5) Even if they only have same-domain network access, they can be used to > create a botnet for computation - for example for purposes like distributed > password cracking. > > 6) They can be used to greatly extend the window of vulnerability from > visiting a malicious site once. Consider the model where a browser patches a > security vulnerability, and users apply the patch over some period after > it's released. Assuming the vulnerability wasn't already known to attackers, > users are at risk if they visit a malicious site in the period between > release of the patch and install of the patch. But with persistent workers > (or background pages) in the picture, users can be vulnerable if they have > *every* visited a malicious site - because it could have installed a > persistent worker that periodically "phones home" for exploit code to try. > This can greatly increase the number of people who can be affected by a > malicious web page, and therefore greatly increases the incentive to try > such a thing. This works even with just same-doman network access. I think > this risk is really serious because it makes every future browser > vulnerability much more dangerous. > > 7) Even with only same-domain network access, the persistent worker could > periodically "phone home" to allow tracking of the user by IP, which can be > mapped to an approximate physical location. Normally, a page you don't have > open can't do that to you. > > This list isn't necessarily exhaustive, I'm sure there's more risks I > haven't thought of, but note that most of these problems are not resolved by > limiting networking to same-domain. > > I don't think a permissions dialog could possibly adequately explain these > risks, and in any case many users blindly click through alert dialogs. The > risks are subtle but nonetheless outside user expectations for a web > application. > > I do think offering a feature like this in the context of an application or > extension style install experience might be acceptable - specifically an > experience that is explicitly initiated by the user with multiple > affirmative steps. But web features are not usually designed around such an > expectation, usually this is the hallmark of a proprietary platform, at > times also including central vetting and revocation capabilities. > > Regards, > Maciej > >
Re: [whatwg] Security risks of persistent background content (Re: Installed Apps)
Maciej, thanks for sending this out. These are great points - I have a few responses below. The main thrust of your argument seems to be that allowing web applications to run persistently opens us up to some of the same vulnerabilities that native (desktop and mobile) apps have, and I agree with that. The question (as with native apps) is whether we can mitigate those vulnerabilities, and whether the functionality that persistence provides is worth the larger attack surface. On Tue, Jul 28, 2009 at 10:58 PM, Maciej Stachowiak wrote: > > On Jul 28, 2009, at 10:01 AM, Drew Wilson wrote: > > I've been kicking around some ideas in this area. One thing you could do >> with persistent workers is restrict network access to the domain of that >> worker if you were concerned about botnets. That doesn't address the "I >> installed something in my browser and now it's constantly sucking up my CPU" >> issue, but that makes us no different than Flash :-P >> > > Here's some security risks I've thought about, for persistent workers and > persistent background pages: > > 1) If they have general-purpose network access, they are a tool to build a > DDOS botnet, or a botnet to launch attacks against vulnerable servers. Indeed. There are mitigations against this (basically, leveraging some of the same infrastructure we have in place to warn users of malware), although not all browsers have this protection currently. But, yes, this (intentionally) makes the browser more similar to the desktop environment, and so more vulnerable to desktop-style attacks. > > 2) If they do not have general-purpose network access, this can be worked > around with DNS rebinding. Note that ordinarily, DNS rebinding is only > considered a risk for content protect by network position. But in the case > of a DDOS or attempt to hunt for server vulnerabilities, this doesn't matter > - the attack doesn't depend on the DDOS node sending credentials. That's an interesting point. Basically, once I've gotten a farm of people to install persistent workers, I can just rebind my domain to any arbitrary IP address, and now that domain could get a flood of HTTP connections. > > 3) If they have notification capabilities, they can be used for advertising > spam. Yes, although the point of notifications is that 1) they are opt-in and 2) they are easy to opt-out (there's a "block" button on the notification). So I don't know that this is a real issue - the point of notifications is that it's really easy to undo your decision to grant access. I'd say that rather than this being a security issue, it's a UX issue to make sure that users have a way to get rid of annoying notifications easily and permanently. > > 4) If they have general network access only while a page from the same > domain is displayed, then they can use a misleading notification to trick > the user into going to a page on that domain, to gain network general > network access at the moment it's needed. Good point, although I don't think this would be an acceptable restriction anyway. One of the whole points behind persistent workers is that they can keep a local data cache up-to-date (i.e. "list of upcoming calendar events") regardless of whether a page is open. > > 5) Even if they only have same-domain network access, they can be used to > create a botnet for computation - for example for purposes like distributed > password cracking. > Agreed. Once you have your software running on many machines, there are many things you could do with those cycles. Attackers probably won't be folding proteins :) > > 6) They can be used to greatly extend the window of vulnerability from > visiting a malicious site once. Consider the model where a browser patches a > security vulnerability, and users apply the patch over some period after > it's released. Assuming the vulnerability wasn't already known to attackers, > users are at risk if they visit a malicious site in the period between > release of the patch and install of the patch. But with persistent workers > (or background pages) in the picture, users can be vulnerable if they have > *every* visited a malicious site - because it could have installed a > persistent worker that periodically "phones home" for exploit code to try. > This can greatly increase the number of people who can be affected by a > malicious web page, and therefore greatly increases the incentive to try > such a thing. This works even with just same-doman network access. I think > this risk is really serious because it makes every future browser > vulnerability much more dangerous. Agreed that this is a big deal, and is a problem I hadn't considered previously. I would assume that browser malware detection would blacklist these sites, but I hate to lean on some magical malware detection infrastructure too heavily. This seems like an issue that Apple and Microsoft have dealt with for years in their OS offerings - how do they handle this? > > This list isn't necessaril
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 7:56 PM, Drew Wilson wrote: > What I'd like, as a user, is some way to pin selected apps to run in the > background - whether that's something I initiate through the UI myself, or > via a prompt from the application is really a matter of UX. in my book, you're definitely asking for prism. http://labs.mozilla.com/projects/prism/ https://wiki.mozilla.org/prism and here's a prism link for google calendar: http://starkravingfinkle.org/projects/webrunner/gcalendar.webapp there should and will be more documentation about how these bundles are exposed.
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 6:32 AM, Michael Kozakewich <
mkozakew...@icosidodecahedron.com> wrote:
>
>> It sounds like the "hidden page" idea is just the solution you thought up
> to the problem of keeping a page running. How many other reasons are there
> for it?
Not sure what other motivations there may be, but one shouldn't
underestimate the value of keeping a page running. It's one of the major
differences between desktop and web apps.
>
> - Data up-to-date: Even Outlook checks online every X minutes, and has an
> options panel where you can set that value. Google Reader checks for new
> feeds, for me, *if I just leave it open on my desktop.* It works great.
Exactly - but you have to leave it open on your desktop. I can't tell you
how many meetings I've missed because I've inadvertently closed (or crashed
:) my browser, and forgotten to start up my web calendar when I restart.
What I'd like, as a user, is some way to pin selected apps to run in the
background - whether that's something I initiate through the UI myself, or
via a prompt from the application is really a matter of UX.
>
> -- Notifications: I don't think I've ever had Outlook notify me of new mail
> when it's not running. It usually starts up with Windows, and it runs in the
> background. If you turn it off from the tray, it stops.
The way I've envisioned any of these "persistent running workers/pages"
operating is the browser would have a status bar icon which would allow
background apps to display status, and also give the user the opportunity to
exit the browser or (possibly) close down individual apps. So it's a very
similar situation.
>
> If browsers could tear off tabs, minimize them to tray and allow them to
> send pop-up notifications, I think it would solve your main problem. Chrome
> seems to be halfway there, with the "Create Application Shortcuts..."
> option, but I believe only Chrome and Firefox support tear-away tabs. This
> sounds largely like a browser issue. If Chrome does it first, I'm sure the
> others will see and follow along.
Agreed. I like this way of looking at the issue - framed in this manner, it
highlights this as primarily a UX challenge ("how to present the idea of
'pinned' tabs to the user").
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
'Named' cache groups under a single manifest url is an interesting idea. Presumably the webapp would be generating the 'name' in the manifest file based on a cookie value. Another possibility is something along the lines of what is proposed in the DataCache draft: the manifest indicates a cookie name, and the value of that cookie determines the 'name' of the subgroup. And the value of that cookie also determines which subgroup is enabled at any given time. On Tue, Jul 28, 2009 at 9:04 PM, Ian Hickson wrote: > On Tue, 28 Jul 2009, Adam de Boor wrote: > > > > the difficulty with a named-section option is that the manifest > generation > > for an application would have to know which users use a particular > machine, > > which is pretty much a non-starter. > > I meant that each named appcache would have a separate manifest, and the > manifest would just say the name of the one it was setting up. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' >
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 7:19 AM, Tab Atkins Jr. wrote: > > > Firefox's Jetpack addon (essentially Greasemonkey turned up to 11) > exposes a super-convenient jetpack.notifications.show() function for > doing exactly that. It pops up an attractive notification in the > lower right-hand corner of the screen for a few seconds with a custom > title, text, and icon. I'd like to have something like this as a > general feature. > > ~TJ Something similar to this is in the works for WebKit as well: https://bugs.webkit.org/show_bug.cgi?id=25463 It's experimental and so would be exposed via window.webkitNotifications. In addition to the text+icon functionality, this also enables scripted HTML notifications, to allow things like notifications that display number of unread emails, a dynamic countdown for an event reminder, etc. It sounds like enough people are prototyping in this area (us, mozilla jetpack, Palm) that we might get consensus on a general API at some point. -atw
Re: [whatwg] Spec comments, sections 1-2
On Wed, Jul 29, 2009 at 4:39 AM, Ian Hickson wrote: > There is value in not changing them unless they are actually broken -- > when I edit the spec, there's always a risk I'll break something. Okay, not a big deal then. > I've required UAs to catch this case and added this example. Okay, great. > Which others are needed for compatibility? I don't know, but there are certainly some. Otherwise, why would browsers support so many? For instance, baidu.com is #9 on Alexa and serves gb2312 as far as I can tell. So does qq.com, which is #14. And sina.com.cn, #19. vkontakte.ru is #30 and serves Windows-1251. tudou.com (#60) uses gbk. rakuten.co.jp (#68) serves EUC-JP. This is just from a quick manual look at a few of the largest non-English sites. I'd think it would be fairly easy for someone (e.g., Google) to come up with a rough summary of character encoding usage on the web by percentage, and for vendors to say which encodings they support, so a useful common list could be worked out. If browsers differ in which encodings they accept, that harms interoperability, so I'd think it would be ideal if HTML 5 would specify the exact list of encodings that must be supported and prohibited support for any others. The union of encodings supported by existing browsers would be a reasonable start, since supporting a new encoding is presumably pretty cheap. Unless this is viewed as outside the scope of HTML 5 -- e.g., if browsers tend to rely on the operating system for encoding support.
Re: [whatwg] Installed Apps
On Wed, Jul 29, 2009 at 8:32 AM, Michael Kozakewich wrote: > From: "Michael Davidson" > Tuesday, July 28, 2009 11:24 PM >> >> Having some sort of desktop presence is important for parity >> with desktop apps. Perhaps the install UI could look and feel more >> like the UI for installing a native app? >> >> Michael >> > > If you're going to have an installation, why not make it an actual program? > I thought what you wanted was a regular webpage -- and I'd say one of the > most important things about a webpage is that you don't have to install it. > It sounds like the "hidden page" idea is just the solution you thought up to > the problem of keeping a page running. How many other reasons are there for > it? Agreed that having an actual persistent entity separate from the browser is, well, an application separate from the browser. There's probably something useful and cool possible here with a browser window communicating with a separate program. > That being said: > > Pop-up notifications would be a great thing to do, where someone can use > JavaScript similar to an alert() box that pops up in a corner for a few > seconds and displays a message. I think I'll call this one out a few times, > so someone sees it, because it really would be a worthwhile thing to add to > a spec. Firefox's Jetpack addon (essentially Greasemonkey turned up to 11) exposes a super-convenient jetpack.notifications.show() function for doing exactly that. It pops up an attractive notification in the lower right-hand corner of the screen for a few seconds with a custom title, text, and icon. I'd like to have something like this as a general feature. ~TJ
Re: [whatwg] Installed Apps
From: "Michael Davidson" Tuesday, July 28, 2009 11:24 PM Having some sort of desktop presence is important for parity with desktop apps. Perhaps the install UI could look and feel more like the UI for installing a native app? Michael If you're going to have an installation, why not make it an actual program? I thought what you wanted was a regular webpage -- and I'd say one of the most important things about a webpage is that you don't have to install it. It sounds like the "hidden page" idea is just the solution you thought up to the problem of keeping a page running. How many other reasons are there for it? I'll go back to your original problems: -- Slow startup: Besides caching, I can't see anything except a skilled planning and development of the application making things faster -- They HAVE to download it all at some point. Merge requests (sprites, for example). I can't think of how to load new JavaScript quicker, unless you can let them use the cached old version while the new one downloads in the background, then cache it. -- Data up-to-date: Even Outlook checks online every X minutes, and has an options panel where you can set that value. Google Reader checks for new feeds, for me, if I just leave it open on my desktop. It works great. -- Notifications: I don't think I've ever had Outlook notify me of new mail when it's not running. It usually starts up with Windows, and it runs in the background. If you turn it off from the tray, it stops. Another couple things: -- Notifications: Web pages can't pop up a notification, but they CAN play sounds. If you add a sound to Gmail or Reader when it finds new items, that would certainly help me, as a user. (Even without having it as a desktop app, because it'll be open in a tab and I'll be able to hear any sound it makes). Actually, I'd love that feature. -- Clutter: I think this is your main concern: Outlook will minimize to the tray; where you can reach it, but it's not in the way. It's not invisible, and won't persist after shutting down. If browsers could tear off tabs, minimize them to tray and allow them to send pop-up notifications, I think it would solve your main problem. Chrome seems to be halfway there, with the "Create Application Shortcuts..." option, but I believe only Chrome and Firefox support tear-away tabs. This sounds largely like a browser issue. If Chrome does it first, I'm sure the others will see and follow along. That being said: Pop-up notifications would be a great thing to do, where someone can use JavaScript similar to an alert() box that pops up in a corner for a few seconds and displays a message. I think I'll call this one out a few times, so someone sees it, because it really would be a worthwhile thing to add to a spec.
Re: [whatwg] Spec comments, sections 1-2
On Wed, 15 Jul 2009, Aryeh Gregor wrote:
>
> In 2.4.4.1:
>
> "If position is not past the end of input, return to the top of the
> step labeled loop in the overall algorithm (that's the step within
> which these substeps find themselves)."
>
> Why not just "go to step 9"?
Which part specifically are you saying should be changed? I'm not sure I
follow.
> In any event this is inconsistent with
> 2.4.4.2, which says
>
> "If position is not past the end of input, return to the top of step 9
> in the overall algorithm (that's the step within which these substeps
> find themselves)."
I guess I didn't screw that one up yet. :-) I originally wrote algorithms
using numeric step jumps, then when editing them I broke a bunch of jumps
(adding steps but not updating numbers), and so whenever I edit an
algorithm now, I make it symbolic rather than numeric.
> Either both should say "the top of step 9" or both should say "the top
> of the step labeled loop".
There is value in not changing them unless they are actually broken --
when I edit the spec, there's always a risk I'll break something.
> I don't see the value in the whole "in the overall algorithm . . ."
> part, since in context there's no ambiguity with just giving the number.
For now -- what if I later add a dozen more substeps?
> "If sign is "positive", return value, otherwise return 0-value."
>
> I initially read "0-value" as a single word, like "p-value" or
> whatever. Perhaps it should have spaces to make it more immediately
> obvious that it's subtraction ("0 - value").
I've rephrased this.
> In 2.6.2:
>
> The specification says that user agents may serve HTTPS content as
> though it were unencrypted. For instance, an example states: "If a user
> connects to a server with a self-signed certificate, the user agent
> could allow the connection but just act as if there had been no
> encryption." If this is done, however, man-in-the-middle attacks become
> trivial, unless the user is expected to notice the lack of encryption
> (unlikely).
>
> For instance, suppose a user navigates to PayPal and bookmarks it.
> PayPal is configured so if you try using HTTP (e.g., typing "paypal.com"
> in the URL bar), it will redirect to HTTPS. Therefore the user will
> bookmark a URL such as https://www.paypal.com/. Now suppose the user
> later attempts to access this site from the bookmark with a MITM present
> (e.g., a free wireless router placed in a public place by a malicious
> person).
>
> The router can intercept the HTTPS request, make its own identical HTTPS
> request, and return the results to the original HTTPS request, but
> signed with its own key instead of the original. If the user agent
> behaves as described in the example, the only way for the user to notice
> this is to notice that the URL bar looks different, or whatever visual
> cue the browser uses. If the user agent raises a prominent scary
> warning or even makes it difficult for the user to continue, on the
> other hand, there's no way for the attacker to prevent this, AFAIK.
>
> The section should prohibit user agents from displaying self-signed
> pages without at least giving a warning. Or, at a minimum, it should
> strongly discourage it. Currently it seems to indicate that this
> behavior is acceptable. As far as I know, existing browsers all present
> scary warnings for self-signed pages (probably so scary as to be
> misleading, in fact, but that's a separate issue).
I've required UAs to catch this case and added this example.
> In 2.7:
>
> "User agents must at a minimum support the UTF-8 and Windows-1252
> encodings, but may support more.
>
> "It is not unusual for Web browsers to support dozens if not upwards
> of a hundred distinct character encodings."
>
> Why aren't the most important ones listed as requirements?
They are. UTF-8 and 1252 are the most important ones.
> This seems to be contrary to the usual HTML 5 philosophy of mandating
> (or at least precisely specifying) existing behavior that's required for
> compatibility.
Which others are needed for compatibility?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issues with Web Sockets API
On Wed, 29 Jul 2009, Fumitoshi Ukai (��~\飼�~V~G�~U~O) wrote: > > I'm wondering why send() doesn't raise INVALID_STATE_ERR exception when > readyState is CLOSED and is required to queue up the data after closed. > What is the reason for this behavior? So that scripts don't get unexpected exceptions randomly based on network weather. > > > 8) Many HTTPS proxies only allow connecting to port 443. Do you have > > > the data on whether relying on existing proxies to establish > > > connections to arbitrary ports is practical? > > > > I do not. I expect most people to use direct connections over port 81 > > or TLS over port 443, as discussed in the introduction. > > You mean TLS over port 815 here, although TLS over port 443 would be > practical because of common firewall configuration? No, I meant what I wrote. I don't expect most people to use port 815, though it is the right thing to do. Maybe on the long term 815 will get used more. > > > 11) There is no way for the client to know that the connection has been > > > closed. For example: > > > - socket.close() is called from JavaScript; > > > - onclose handler is invoked; > > > - more data arrives from the server, and onmessage is dispatched (which I > > > think is correct, and it matches what TCP does); > > > - finally, a TCP FIN arrives, indicating that there will be no more data > > from > > > the server (the underlying TCP connection is in TIME_WAIT state after > > that); > > > - the client never learns that the server is done sending data. > > > > The onclose only fires once the connection has closed, which is after the > > TCP FIN, so it happens after the last 'message' event. > > so, it means we might receive message events even after we call > websocket.close(), until we get close event? Yes. But that's the case anyway -- events are asynchronous, so consider the case of receiving two messages. Both are queued up, then eventually the first is dispatched. If in response to that you close the connection, that doesn't stop the second being dispatched, since it was already queued up. > > The attribute now lets you just wait until the buffer is empty, which > > is more or less equivalent, I think. > > Do we need to check bufferedAmount periodically by setTimeout? > How about firing some event when buffer is empty? If you need to send the information anyway, just send it. This is really only useful in the case where you're sending information that you can omit completely, for example, if you're sending events on an interval, in which case you can just avoid sending messages if there is any buffered data. There's no point buffering the data in JS while waiting for the send buffer to be empty, since the buffer in JS and the send buffer are from the same pool of RAM. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issues with Web Sockets API
On Wed, Jul 29, 2009 at 8:40 AM, Ian Hickson wrote: > On Tue, 14 Jul 2009, Jeremy Orlow wrote: > > > > > > > > I think 'readyState' should just go away since an application will > > > > have to keep track of state updates through the fired events and use > > > > try/catch blocks around all API calls anyway. > > > > > > The attribute is mostly present for debugging purposes. I wouldn't > > > expect anyone to actually use it for production work. > > > > Is there precedent for other portions of the API that are mostly for > > debugging purposes? (I can't think of anything off the top of my head.) > > readyState on Document and aren't realy useful for anything but > debugging either, as far as I can tell. > > > > Also, maybe it should be noted as such in the spec? > > I don't really see much benefit to including such a statement; if someone > wants to use it for a non-debugging reason, why not do so? > > > > If it's only for debugging purposes, maybe a cleaner way to define it is > > to simply be the last event fired on a given WebSocket? > > I don't really understand what problem we would be trying to solve by > changing that. > > > > One other random question: in the IDL for WebSockets, the three > > constants for ready state are all defined as shorts but the value of > > ready state is a long. Is this an oversight? > > Fixed. > > > On Mon, 27 Jul 2009, Alexey Proskuryakov wrote: > > > > I agree with Michael that send() should not silently drop data that > > could not be sent. It is very easy to fill send buffers, and if bytes > > get silently dropped, implementing app-level acks becomes quite > > difficult. > > I've made it clear that if bytes can't be sent, the connection must be > closed. I'm wondering why send() doesn't raise INVALID_STATE_ERR exception when readyState is CLOSED and is required to queue up the data after closed. What is the reason for this behavior? > > > > > However, I do not think that raising an exception is an appropriate > > answer. Often, the TCP implementation takes a part of data given to it, > > and asks to resubmit the rest later. So, just returning an integer > > result from send() would be best in my opinion. > > I think we are best off abstracting away this level of complexity from > authors, especially since we'd need to make sure that data was not sent > half-way through a UTF-8 sequence, and since the framing is under the > control of the UA, not the application. There's no way to retry a > partially-successful send() from the API here. > > > > 1) Web Sockets is specified to send whatever authentication credentials > > the client has for the resource. However, there is no challenge-response > > sequence specified, which seems to prevent using common auth schemes. > > HTTP Basic needs to know an authentication realm for the credentials, > > and other schemes need a cryptographic challenge (e.g. nonce for Digest > > auth). > > I expect to address this in more detail in a future version. For now, use > in-band authentication in the WebSocket once you are connected. We may > find that that is actually enough. > > > > 2) It is not specified what the server does when credentials are > > incorrect, so I assume that the intended behavior is to close the > > connection. Unlike HTTP 401 response, this doesn't give the client a > > chance to ask the user again. Also, if the server is on a different > > host, especially one that's not shared with an HTTP server, there isn't > > a way to obtain credentials, in the first place. > > How we address this will likely depend on how we address the earlier > point. > > > > 3) A Web Sockets server cannot respond with a redirect to another URL. > > I'm not sure if the intention is to leave this to implementations, or to > > add in Web Sockets v2, but it definitely looks like an important feature > > to me, maybe something that needs to be in v1. > > What's the use case? Why does this need to be at the connection layer > rather than the application layer? (Why would we need this, when TCP > doesn't have it? Would you also need "redirect"-like functonality in IRC, > IMAP, SSH, and other such protocols?) > > > > 4) "If the user agent already has a Web Socket connection to the remote > > host identified by /host/ (even if known by another name), wait until > > that connection has been established or for that connection to have > > failed." > > > > It doesn't look like "host identified by /host/" is defined anywhere. > > Does this requirement say that IP addresses should be compared, instead > > of host names? > > Right. I've tried to clarify this. > > > > I'm not sure if this is significant for preventing DoS attacks, and > > anyway, the IP address may not be known before a request is sent. This > > puts an unusual burden on the implementation. > > Without this requirement, you can just have a DNS server return the victim > IP for a wildcard DNS entry, and then just have attackers open connections > to thousands of "hosts". > > > > 5) We
