Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote:
Or, should persistent notifications not use a constructor at all?
What's the purpose of having a reference to a Notification object if
no events will ever fire on it? Maybe we should have a function like
promise = createPersistentNotification(...);
promise.then(notificationWasShown, notificationWasRejected);
Well presumably we still want to share an object of sorts as part of
the event, so all the notification data is exposed somehow. A promise
does not make much sense to me as a service worker can be killed at
any point. new Notification(..., {serviceWorker:...}) still makes
the most sense. You create a new notification and by assocation with a
service worker you extend its lifetime.
If we tie non-persistent notifications to the lifetime of a global,
then I don't know that it makes sense to allow them to be created from
a worker.
Dedicated workers are tied to the lifetime of a global. And shared
workers are tied to the lifetime of the union of their associated
globals. The point is mostly that they will be removed from the
notification center at some point.
--
https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: Or, should persistent notifications not use a constructor at all? What's the purpose of having a reference to a Notification object if no events will ever fire on it? Maybe we should have a function like promise = createPersistentNotification(...); promise.then(notificationWasShown, notificationWasRejected); Well presumably we still want to share an object of sorts as part of the event, so all the notification data is exposed somehow. A promise does not make much sense to me as a service worker can be killed at any point. I'm not sure I understand what you are saying here. The above code is the creation steps, not the notification steps. I agree that the click event needs to expose the Notification object. But the SW click event needs to be fired at the SW global, and have as one of its properties the Notification object. Exactly because the SW might have been killed previously and is just getting spawned in order to fire the click event. Thus no other references to the Notification object might exist. / Jonas
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: promise = createPersistentNotification(...); promise.then(notificationWasShown, notificationWasRejected); Well presumably we still want to share an object of sorts as part of the event, so all the notification data is exposed somehow. A promise does not make much sense to me as a service worker can be killed at any point. I'm not sure I understand what you are saying here. The above code is the creation steps, not the notification steps. Oh, but shown implies it's displayed, which currently can happen later. But as per the other thread maybe we should get rid of that. Assuming we get rid of that, this seems to help a bit with error handling, but is otherwise mostly identical in approach to just keeping the constructor. I agree that the click event needs to expose the Notification object. But the SW click event needs to be fired at the SW global, and have as one of its properties the Notification object. Exactly because the SW might have been killed previously and is just getting spawned in order to fire the click event. Thus no other references to the Notification object might exist. Sure. -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 1:42 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: None of Twitter, Hangouts, or IRCCloud cares a whit if you close their notifications; they still record stuff as unread until you actually visit the app. I can't recall any other app I've ever used treating a notification closing as a significant event and taking any action, either. So, at least based on my immediate testing and long-term memory of the notification patterns of the apps I use, I don't think there's any use-case for a close event. Jake, would be interesting to hear your thoughts on this. If we can simplify notifications by getting rid of some events I'm all for it. -- https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
Let me reply to a few points mentioned in this thread -- it's quite
overloaded :-).
I've also added Andrew, who might know some historical reasons for the
events. (Andrew: most of this is in context of persistent notifications.)
* Life-time of existing notifications.
Chrome currently treats Web Notifications as persistent ones. When the
page goes away, the notification stays. Interaction with the notification
is not going to trigger anything anymore. While I'm in favor of changing
this, we have to be very cautious to not break user expectations of
existing users of the Web Notification API, for example in calendar
applications.
* Dropping the close event.
I've been wondering myself whether it's valuable to support this. Like Tab,
I'm not aware of any messaging application actually using the close event
as an indication that the message has been read. There is the dismiss all
button on most platforms, which definitely does not imply having read the
message. It's actually an interesting privacy question as well, for
example, if a user dismisses a Facebook notification in their notification
center without actually starting the app, should the sender be informed
about them having at least looked at their phone?
Synchronizing closing of the notification on all the user's devices is an
interesting one, but opt-in would be sufficient for this.
Given the cost of starting up a Service Worker, I'm interested in exploring
opt-in. One potential optimization a UA could do is detect the events bound
on a Service Worker's global when it starts, and check whether
notificationclose is part of this for future invocations.
* Dropping the show event.
There is one scenario in which Chrome doesn't fire the show event, and
that's when no permission has been granted to show notifications (in which
case we fire the error event). One theoretical concern with this property
is that if we choose to support delayed notifications, it could be used to
set precise timers. Depending on how we're going to deal with
(asynchronous) errors for persistent notifications, I'm fine with dropping
this for them.
* Supporting non-persistent notifications in Service Workers.
I'd prefer not to, especially if we would auto-close the notifications.
There seems to be little point beyond indicating to the user that the
Service Worker is running, which feels more like a UA thing if they choose
to do so.
* Supporting non-persistent notifications in Shared and Dedicated Workers.
As long as we continue to support non-persistent notifications, I see no
reason not to do this. The globals of both kinds of workers have well
defined lifetimes, making the notifications as reliable as in-page ones,
most notably on desktop.
* Not using the constructor for persistent notifications.
There is one more argument to make in favor of creating a promise
somewhere, and that's consistency with other Service Worker based APIs. As
I understand it, both Web Push and Background Sync are planning to expose
their creation methods on the ServiceWorkerRegistration object. If we were
to do something analogous, it'd be:
navigator.serviceWorker.ready.then(function (registration) {
registration.createNotification('Title', { ... });
});
Instead of:
navigator.serviceWorker.ready.then(function (registration) {
new Notification('Title', { serviceWorker: registration });
});
I have no strong feelings here either, and think it's fine to continue
using the constructor with the serviceWorker property set. Both would still
use the Notification statics. Having a promise would clean up the error
handling a bit, which may occur in the no-permission case.
* Extra-persistent notifications (non-removable ones)
Let's have a separate thread about this. I think it's a loaded subject
given that it's incredibly easy to badly annoy the user when using these,
and we have to make some careful considerations here.
Thanks,
Peter
On Fri, Sep 26, 2014 at 2:41 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Sep 26, 2014 at 1:42 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
None of Twitter, Hangouts, or IRCCloud cares a whit if you close their
notifications; they still record stuff as unread until you actually
visit the app. I can't recall any other app I've ever used treating a
notification closing as a significant event and taking any action,
either. So, at least based on my immediate testing and long-term
memory of the notification patterns of the apps I use, I don't think
there's any use-case for a close event.
Jake, would be interesting to hear your thoughts on this. If we can
simplify notifications by getting rid of some events I'm all for it.
--
https://annevankesteren.nl/
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 6:40 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: promise = createPersistentNotification(...); promise.then(notificationWasShown, notificationWasRejected); Well presumably we still want to share an object of sorts as part of the event, so all the notification data is exposed somehow. A promise does not make much sense to me as a service worker can be killed at any point. I'm not sure I understand what you are saying here. The above code is the creation steps, not the notification steps. Oh, but shown implies it's displayed, which currently can happen later. But as per the other thread maybe we should get rid of that. Assuming we get rid of that, this seems to help a bit with error handling, but is otherwise mostly identical in approach to just keeping the constructor. It's a good point that if the above call happens in a SW, then there's no guarantee that it'll receive either of those callbacks. So it comes down to if we need show, and I guess error, events. One option that I could think of is that Windows that create a notification could detect if the notification fails to be displayed, and if so display in-page UI. Either to replace the notification, or to indicate to the user that notifications currently don't work. In this case the above API could work since a SW can't display such UI anyway, and so it doesn't matter that it might not receive the promise callbacks. / Jonas
Re: [whatwg] Notifications and service workers
On Fri, Sep 26, 2014 at 7:36 AM, Peter Beverloo bever...@google.com wrote: Let me reply to a few points mentioned in this thread -- it's quite overloaded :-). I've also added Andrew, who might know some historical reasons for the events. (Andrew: most of this is in context of persistent notifications.) * Life-time of existing notifications. Chrome currently treats Web Notifications as persistent ones. When the page goes away, the notification stays. Interaction with the notification is not going to trigger anything anymore. While I'm in favor of changing this, we have to be very cautious to not break user expectations of existing users of the Web Notification API, for example in calendar applications. The current situation feels pretty broken in that the API was designed for, and only really works for, non-persistent notifications, however all implementations implement persistent notifications, presumably because that's what the most urgent need was. I think we might need some form of transition period to transition to whatever API we decide is the right one. * Dropping the close event. I've been wondering myself whether it's valuable to support this. Like Tab, I'm not aware of any messaging application actually using the close event as an indication that the message has been read. There is the dismiss all button on most platforms, which definitely does not imply having read the message. It's actually an interesting privacy question as well, for example, if a user dismisses a Facebook notification in their notification center without actually starting the app, should the sender be informed about them having at least looked at their phone? Synchronizing closing of the notification on all the user's devices is an interesting one, but opt-in would be sufficient for this. Ah, that's the best use case I've heard so far. Though, do you really want to close a given notification on all devices just because the user pressed clear all on one device? Or is it better to close the notification on all devices once the user engages with the relevant part of the app, for example by clicking the notification. Given the cost of starting up a Service Worker, I'm interested in exploring opt-in. One potential optimization a UA could do is detect the events bound on a Service Worker's global when it starts, and check whether notificationclose is part of this for future invocations. Yeah. Though I think interest in did this notification close will vary with notification. Which means that if you are interested in close events for one type of notifications in your app, suddenly you pay the price for all of them. * Supporting non-persistent notifications in Service Workers. I'd prefer not to, especially if we would auto-close the notifications. There seems to be little point beyond indicating to the user that the Service Worker is running, which feels more like a UA thing if they choose to do so. The main use case I can think of is if we enable playing audio from a SW, in which case you might want to notify about change in songs. But I'm fine with leaving this unsupported for now. As long as whatever syntax we use doesn't preclude it from being added later should the need arise. * Supporting non-persistent notifications in Shared and Dedicated Workers. As long as we continue to support non-persistent notifications, I see no reason not to do this. The globals of both kinds of workers have well defined lifetimes, making the notifications as reliable as in-page ones, most notably on desktop. I'm a bit skeptical about tying even non-persistent notifications to the lifetime of a global of any sort. Either window or worker. If the use case of non-persistent notifications is to give background apps some temporary screen real estate where they can inform the user about a change, then shouldn't that generally disappear after a short timeout? I believe (but am not sure) that Android and iOS have the concept of non-persistent notifications that are displayed at the top of the screen for a few seconds. These do not go into the notification center. OSX is somewhat different in that it displays an on-screen non-persistent notification. But it also adds the notification to a notification center. Though this notification center is more of a log than stuff that happened since you last looked at your device. I.e. stuff on this list doesn't go away when you click it, and applications don't remove items from here when you interact with the app. Most importantly, I don't know of any types of notifications on any platform that go away when you close the app. While I agree that we generally should leave UI up to UAs, we need to have some model of what type of interaction authors can expect when using various APIs. Leaving UI too undefined is part of what has gotten us into the current somewhat messy state (though the lack of SW certainly didn't help). So all that said, I'm fine with allowing
[whatwg] ARIA semantics of implied rows
Hi WHATWG, ยง4.9.12 Processing model ( https://html.spec.whatwg.org/multipage/tables.html#processing-model-3 ) currently states: A *row* is a complete set of slots from x=0 to x=x_width-1, for a particular value of y. Rows usually correspond to tr elements, though a row group can have some implied rows at the end in some cases involving cells spanning multiple rows. I am thinking that implied rows refers to cases such as: table id=theTable border=1 tbody tr td rowspan=10 colspan=3These are the first 10 rows./td /tr /tbody tbody tr tdRow 11, Column 1/td tdRow 11, Column 2/td tdRow 11, Column 3/td /tr tr tdRow 12, Column 1/td tdRow 12, Column 2/td tdRow 12, Column 3/td /tr tr tdRow 13, Column 1/td tdRow 13, Column 2/td tdRow 13, Column 3/td /tr tr tdRow 14, Column 1/td tdRow 14, Column 2/td tdRow 14, Column 3/td /tr tr tdRow 15, Column 1/td tdRow 15, Column 2/td tdRow 15, Column 3/td /tr /tbody /table .. where because the first row group has a TD spanning 10 rows but only one TR, there are 9 implied rows in that row group. As specified by WAI-ARIA 1.0: The HTML Working Group is incorporating WAI-ARIA into HTML 5. Official support for WAI-ARIA in HTML will be provided in that specification. This DTD is made available only as a bridging solution for applications requiring DTD validation but not using HTML 5. http://www.w3.org/TR/wai-aria/appendices#html_dtd One issue is that the ARIA semantics for implied rows are not defined. Currently, browsers that I have tested (Chrome 37.0.2062.124, Firefox 32.0.3, Safari 7.1, and Internet Explorer 11) only expose 6 rows for the example listed above. In order to get all 15 rows exposed to assistive technologies, I need to insert empty TR elements for the implied rows. It would be very useful if implied rows were exposed implicitly, using the same role as the row containing the anchor slot of the first cell in the implied row. Sincerely, Daniel Trebbien
Re: [whatwg] ARIA semantics of implied rows
On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: http://www.w3.org/TR/wai-aria/appendices#html_dtd DTDs have nothing to do with what you're seeing here. They're best ignored. One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? -- https://annevankesteren.nl/
Re: [whatwg] ARIA semantics of implied rows
(sorry, forgot to copy the list) On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: ... One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? The issue is that, as far as I can tell, HTML 4.01 does not support implied rows: http://www.w3.org/TR/html401/struct/tables.html This is new to HTML5. WAI-ARIA does define roles for a table (grid, row, rowgroup, gridcell, etc.), but you can't specify the role and state attributes for HTML5 implied rows. I ran through the forming a table steps ( https://html.spec.whatwg.org/multipage/tables.html#forming-a-table ) on paper for the example and I came up with x_width is 3 and y_height is 15. If the table model has 3 columns and 15 rows (9 of which are implied), then browsers should expose 3 columns and 15 rows.
Re: [whatwg] ARIA semantics of implied rows
On Fri, Sep 26, 2014 at 11:39 AM, Daniel Trebbien dtrebb...@gmail.com wrote: On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? The issue is that, as far as I can tell, HTML 4.01 does not support implied rows: http://www.w3.org/TR/html401/struct/tables.html This is new to HTML5. No, HTML4 supported this; it probably didn't actually have any normative text around it, but browsers certainly supported having a rowspan go past the end of the explicit rows. ~TJ
Re: [whatwg] ARIA semantics of implied rows
On Fri, Sep 26, 2014 at 3:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Sep 26, 2014 at 11:39 AM, Daniel Trebbien dtrebb...@gmail.com wrote: On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com wrote: One issue is that the ARIA semantics for implied rows are not defined. I'm not sure I understand why ARIA would come into play at all when it comes to tables. Weren't tables accessible (I realize it has always been somewhat hard to convey them properly) long before ARIA existed? The issue is that, as far as I can tell, HTML 4.01 does not support implied rows: http://www.w3.org/TR/html401/struct/tables.html This is new to HTML5. No, HTML4 supported this; it probably didn't actually have any normative text around it, but browsers certainly supported having a rowspan go past the end of the explicit rows. That's true. Browsers supported this. What I mean is that HTML4 didn't have normative specification of this, but HTML5 does. I guess what I wanted to clarify is that when a browser exposes a table to the operating system's accessibility layer which screen readers use to announce the content of a web page, the model of the table in the accessibility layer should match the HTML5 table model. Using the Accessibility Inspector tool on Mac and the Inspect tool on Windows, I am seeing that browsers are currently not exposing the implied rows. Chrome, Firefox, Safari, and Internet Explorer are only exposing 6 rows for the example. Using the example table HTML in Chrome for Mac, Chrome is not exposing to Mac's accessibility hierarchy the 15 rows of the table, but only 6 rows; there are only 6 AXRow children of the AXTable. With Accessibility Inspector I see that the AXCell corresponding to the first cell in the first row has the AXColumnIndexRange attribute set to loc=0, len=3 and the AXRowIndexRange attribute set to loc=0, len=10 (which are correct). However, when I navigate to the Row 11, Column 1 cell, VoiceOver announces row 2 of 6 Row 11, Column 1. If I modify the example HTML to insert empty TR elements for each of the 9 implied rows: table id=theTable border=1 tbody tr td rowspan=10 colspan=3These are the first 10 rows./td /tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr tr/tr /tbody tbody tr tdRow 11, Column 1/td tdRow 11, Column 2/td tdRow 11, Column 3/td /tr tr tdRow 12, Column 1/td tdRow 12, Column 2/td tdRow 12, Column 3/td /tr tr tdRow 13, Column 1/td tdRow 13, Column 2/td tdRow 13, Column 3/td /tr tr tdRow 14, Column 1/td tdRow 14, Column 2/td tdRow 14, Column 3/td /tr tr tdRow 15, Column 1/td tdRow 15, Column 2/td tdRow 15, Column 3/td /tr /tbody /table .. then when I navigate to the Row 11, Column 1 cell, VoiceOver announces row 11 of 15 Row 11, Column 1. Also, Chrome then exposes 15 AXRow children of the AXTable. Using the original example in Internet Explorer 11, IE11 is exposing only 6 rows like Chrome, Safari, and Firefox; with the Windows SDK Inspect tool, I see that the UIA_TableControlTypeId has the Grid.RowCount attribute set to 6. Switching on Narrator, when I navigate to the Row 11, Column 1 cell, Narrator announces Row 11, Column 1. Column 1 row 2 item. Using the modified HTML containing the 9 empty TR elements, the Grid.RowCount attribute is set to 15 and Narrator will announce Row 11, Column 1. Column 1 row 11 item for the Row 11, Column 1 cell. I am fairly certain that the model of the table that browsers expose to the accessibility layer should match the HTML5 table model, but I wanted to confirm. Also, I wanted to ask what the ARIA semantics of the implied rows are. For example, suppose I have this (admittedly contrived): table border=1 tbody tr aria-selected=true role=row td rowspan=5Spans 5/td tdnbsp;/td tdnbsp;/td tdnbsp;/td /tr tr aria-disabled=true role=presentation td rowspan=4Spans 4/td tdnbsp;/td tdnbsp;/td /tr tr aria-hidden=true role=row td rowspan=3Spans 3/td tdnbsp;/td /tr tr aria-busy=true role=presentation td rowspan=2Spans 2/td /tr /tbody /table There is 1 implied row in this example, but what are the ARIA state attributes of this implied row? Is it selected and/or disabled and/or hidden and/or busy? What is the implied row's role? There should probably be a requirement that ARIA roles and state should be consistent.
[whatwg] Autofill-related feedback
On Mon, 28 Apr 2014, Evan Stade wrote: On Thu, 24 Apr 2014, Evan Stade wrote: Ian wrote: Why would this only apply to requestAutocomplete()? Surely it would be just as important for the case where the user agent is filling in a form without using that API. That is true, but I don't know of a better way to convey this information from the page to browser. Additional attributes on the cc-number field? Well, if we're going to use type=hidden fields to expose the username, we could also use it to expose the amount and currency. Would that work? I agree with those upthread who said that overloading autocomplete= to provide information to the user agent is confusing. If we introduce something like autocomplete=transaction-currency then it's easy to misinterpret that as the site asking the browser what the currency is for the payment method, then having a site author use transaction-currency in a non type=hidden input. Is that so bad? What I ended up going with (based on discussion in the relevant bug) is the type=hidden proposal, along with making transaction-currency a first-class autofill field type. On Mon, 5 May 2014, Matthew Noorenberghe wrote: In Firefox, we save the form values after validation but before the submit event is dispatched to content. This way we successfully save the form fields in form history when a script is handling the actual submission. This also helps against sites who try to manipulate the form fields upon submission to avoid having them saved (see https://bugzilla.mozilla.org/show_bug.cgi?id=257781 ). We've been doing this for a long time and I don't recall any complaints as long as I've been working on password and form manager for Firefox (since 2009). Assuming that by form history you mean the back-forward behaviour, this isn't really consistent with the way the spec is written currently. If you think we should change the spec, please don't hesitate to file a bug on this. (http://whatwg.org/newbug) There are many websites that use click handlers on buttons outside forms instead of using form submission and those fields don't get saved in Firefox. Per spec, for session history purposes they would get saved during navigation, IIRC. They wouldn't get saved for autofill though, right. I suspect web developers don't realize that they are losing out on form history and other benefits like being able to submit the form with the Enter key from a text input. I don't see sites that are not having their fields saved by not using form submission switching to calling a new API when they can instead use an onsubmit handler which has other benefits. Given that Firefox already saves values with preventDefault inside form submit handlers and click handlers on submit buttons, and the other benefits of sites using form submission, I don't think a new API is needed. I agree that a new API isn't needed for saving fields for autofill if pages can rely on browsers saving the values during submission, but I think that the issue of when to store values for autofill and when to store values for the session history are independent issues. https://www.w3.org/Bugs/Public/show_bug.cgi?id=25238 It seems like more evangelism is needed to let authors know that preventDefault inside a form submission handler is the better way to handle forms where navigation isn't wanted. The benefits are: form history, password management, better UX (allowing submission via Enter when inputs are in a form), and possibly better accessibility(?). I've been thinking about cases where we could detect the pattern of fake forms (using text inputs and buttons with click handlers together without a form) and provide notices in developer tools to help evangelize but it's looking to be tricky. Yeah, I'm not sure how to do that usefully, unfortunately. On Fri, 16 May 2014, Garrett Casto wrote: The problem right now is that there are two legitimate reasons that a site may return false from the submit handler, either because the submission failed validation in some way or because submission is being handled via script. Browsers can either ignore this distinction (e.g. Firefox) or try and separate the two heuristically (e.g. Chrome). Both are reasonable approaches given the current state of the world, but neither are ideal. We should allow sites to make this distinction. I agree that we shouldn't necessarily add contortions for sites that don't use form submission, but currently there isn't a right way to do this even if the site wants to. We could add a new method= like method=dialog to handle this. Or we could just tell people to use action=javascript: (which does nothing). On Tue, 6 May 2014, Evan Stade wrote: If a country experiences political turmoil and changes the number of types of administrative divisions it has, I guess it's reasonable to redefine level4
Re: [whatwg] AppCache Content-Type Security Considerations
On Tue, 13 May 2014, Eduardo Vela wrote: On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote: What about X-Content-Type-Options: nosniff? Could we formalize it and remove the X and disable sniffing all together? Do you mean for manifests specifically, or more generally? I agree it's wrong to do it as a one-off, so was hoping to make it more generally (since there seems to be a move on moving out of the CT model). I don't think removing sniffing in general is ever going to happen, if for no other reason than for many types it's just trivial to sniff and very unlikely to go wrong (e.g. binary image types). If that's not OK, then CSP is probably a reasonable way forward (I'll take a look at the Service Worker thread to ensure we have a similar mitigation in place). Yeah, CSP seems like the logical way to do this. On Tue, 13 May 2014, Michal Zalewski wrote: I disagree. Much of the Web actually relies on this today, and for the most part it works. For example, when you do: img src=foo ... ...the Content-Type is ignored except for SVG. Well, img is actually a fairly special case of content that is difficult for attackers to spoof and that can't be easily read back across domains without additional CORS headers. But I believe that in Chrome and in Firefox, C-T checks or other mitigations have been recently added at least script, link rel=stylesheet, and object / embed, all of which lead to interesting security problems when they are used to load other types of documents across origins. Similar changes are being made also for a couple of other cases, such as a download. script is news to me. Per spec it has no sniffing or Content-Type checking, it just assumes text/javascript. object/embed, at least if it matches the spec's Content-Type requirements, still involves plenty of sniffing. link rel=stylesheet has required text/css for some time. CSS is a text format with no signature so there's no good way to sniff it. On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote: If CSS, JS and plugins had magic numbers at the beginning of the file, then that would prevent the issues that you are discussing right? Some of them. I think that's Ian's point, that for those file types, we need CT, but for others, like manifest files, and image and plugins we shouldn't need. Right. PDFs, and JARs are a special case here, since they scan the content (first N bytes, or last N bytes) for the signature, but if the content match was done for the exact first byte, then this would help prevent security issues I think? Having a loose signature is problematic, indeed. Note that the MIME Sniffing spec, for PDF, doesn't allow scanning. On Tue, 13 May 2014, Michal Zalewski wrote: If we take this route, I think we'd be essentially making sure that many web applications that are safe today will gradually acquire new security bugs out of the blue as the UA magic signature detection logic is extended in the future (as it inevitably will - to account for new plugins, new formats with scripting capabilities or other interesting side effects, etc). An out-of-band signalling mechanism has far superior security properties compares to an in-band one, given how many if not most web apps are designed today. It may be that they are designed the wrong way, but the security rules were never particularly clear, and serving content off-domain added a lot of complexity around topics such as auth, so I think it's best to be forgiving and accommodate that. The examples of CSV exports, text documents, and several more exotic things aside, most JSONP APIs give the attacker broad control over the first few bytes of the response. I agree that out-of-band signalling has some security advantages, but I think they are far outweighed by the costs of configuring out-of-band signalling in practice. Either way, the Web now is in this weird mix of both approaches, and we're unlikely to be able to do anything about that. On Tue, 13 May 2014, Eduardo' Vela\ Nava wrote: @Ian, is there a way to find out what was the Content-Type that the authors that complained were getting? Hopefully we can figure out a list of Content-Types that are unlikely to cause security problems? I think the mitigation in the spec (scoping the fallbacks to the manifest URL path) is probably sufficient. It means you can only take over the part of the site that has the upload vulnerability. Supporting just the default types is unlikely to help, since those are the types most likely to be used to label an uploaded file in this scenario. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
