Re: [whatwg] Proposal for a web application descriptor
Am 30.04.2011 um 01:41 schrieb Glenn Maynard gl...@zewt.org: On Fri, Apr 29, 2011 at 6:40 PM, Simon Heckmann si...@simonheckmann.dewrote: Some challenges include: * how to justify the request to the user being asked to grant the privileges starting with a text string and a link to more information Well, this is what I thought of: The users visit a website they have never visited before. A notifications pops up allowing them to set all permissions required for this page. The users might not trust the site yet so they do not grant all permissions immediately. There's a more common issue: when you ask me for a bunch of permissions at once, I don't know why you want them. This happens constantly with Android apps: you install a simple notepad or clock app, and it'll ask for Internet access and the ability to make phone calls, and you don't know why. This is why--in general--I like the model so far: the user is asked for permission in response to actually doing something that uses a feature. In the notepad app, you're asked for permission to access the internet when you select sync notes to your desktop PC; it's immediately obvious why it's asking for it. (That's an Android example, of course, not a web app example.) Hopefully the ultimate solution will deal with both, allowing UAs the option of asking all at once or on-demand, depending on the situation. (Some permissions inherently have to be asked in advance, like Web Notifications, which doesn't happen in response to a user action.) -- Glenn Maynard I agree: That is why the example you quote from my previous mail went on like this: As the users continue to use the page, the web site could check the status of the permission using javascript and remind the user to rethink his permission settings: This site would like to access your camera to scan for a barcode. If you want to use this feature, please use the global permissions dialog to set them. This way users that trust/know the application can give permissions directly while others might grant permissions one at the time. Thats why I like the idea of a consolidated dialog. The user could always quicky return to it and maintain all permissions at once.
Re: [whatwg] Proposal for a web application descriptor
On Sat, Apr 30, 2011 at 11:41 AM, Glenn Maynard gl...@zewt.org wrote: This is why--in general--I like the model so far: the user is asked for permission in response to actually doing something that uses a feature. In the notepad app, you're asked for permission to access the internet when you select sync notes to your desktop PC; it's immediately obvious why it's asking for it. (That's an Android example, of course, not a web app example.) Hopefully the ultimate solution will deal with both, allowing UAs the option of asking all at once or on-demand, depending on the situation. (Some permissions inherently have to be asked in advance, like Web Notifications, which doesn't happen in response to a user action.) The application could have a settings page with a checkbox Enable desktop notifications. When you click on that box, the browser shows its (passive, asynchronous) UI for enabling desktop notifications for that application. Asking for specific permissions in the context of a user action is the only model that makes sense to me. When applications ask for a big bundle of permissions in advance, how can I as a user know what to do? I'm sure to get into a habit of either blindly denying the permissions (crippling applications), or granting the permissions (terrible for security). While some Mozilla developers may think big bundle of permissions is a good idea, others such as me do not. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Proposal for a web application descriptor
On Sat, Apr 30, 2011 at 3:30 AM, Simon Heckmann si...@simonheckmann.dewrote: I agree: That is why the example you quote from my previous mail went on like this: As the users continue to use the page, the web site could check the status of the permission using javascript and remind the user to rethink his permission settings: This site would like to access your camera to scan for a barcode. If you want to use this feature, please use the global permissions dialog to set them. This way users that trust/know the application can give permissions directly while others might grant permissions one at the time. Thats why I like the idea of a consolidated dialog. The user could always quicky return to it and maintain all permissions at once. This is what I was cautioning against. Scripts prompting manually is both a bad API and bad UI. Scripts shouldn't pop up a message telling the user to track down some other UI; they should simply attempt to use what they want to use, so the browser can just ask. On Sat, Apr 30, 2011 at 5:23 AM, Robert O'Callahan rob...@ocallahan.org wrote: The application could have a settings page with a checkbox Enable desktop notifications. When you click on that box, the browser shows its (passive, asynchronous) UI for enabling desktop notifications for that application. This still implies having an API to ask for permission for a feature before using it. (Web Notifications has a draft for this: http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html .) Also, many developers won't want a UI like that, since when you disable a feature and expect users to enable it in settings, a lot of them won't. Many people never look at settings pages at all. Pages are more likely to request permissions as soon as they can. Asking for specific permissions in the context of a user action is the only model that makes sense to me. When applications ask for a big bundle of permissions in advance, how can I as a user know what to do? I'm sure to get into a habit of either blindly denying the permissions (crippling applications), or granting the permissions (terrible for security). While some Mozilla developers may think big bundle of permissions is a good idea, others such as me do not. I'd wonder what their response is to Android; the problems on that platform are obvious. The result is exactly as you say: people end up giving up and just accepting everything. (The permissions request for Skype includes: read contact data, write contact data, coarse (network-based) location, full Internet access, act as an account authenticator, manage the accounts list, user the authentication credentials of an account, modify/delete USB storage contents, change your audio settings, record audio, read phone state and identity, disable keylock, modify global system settings, prevent phone from sleeping, retrieve running applications, write sync settings, view network state, view Wi-Fi state, control vibrator, read sync settings, read sync statistics, discover known accounts. It's hopeless; if take out a mortgage on your house was in there, nobody would notice.) Of course, asking each of these while using the application would also be painfully annoying, and it's not obvious how to make permissions meaningful to the user (eg. when you use its feature) while also scaling to lots of permissions. -- Glenn Maynard
Re: [whatwg] Proposal for a web application descriptor
On Sun, May 1, 2011 at 1:52 AM, Glenn Maynard gl...@zewt.org wrote: On Sat, Apr 30, 2011 at 5:23 AM, Robert O'Callahan rob...@ocallahan.org wrote: The application could have a settings page with a checkbox Enable desktop notifications. When you click on that box, the browser shows its (passive, asynchronous) UI for enabling desktop notifications for that application. This still implies having an API to ask for permission for a feature before using it. (Web Notifications has a draft for this: http://dev.w3.org/2006/webapi/WebNotifications/publish/FeaturePermissions.html .) Also, many developers won't want a UI like that, since when you disable a feature and expect users to enable it in settings, a lot of them won't. Many people never look at settings pages at all. Pages are more likely to request permissions as soon as they can. Notifications are a particularly hard case for the principle of requesting permissions in response to user action, because the whole point of notifications is that they happen when the user isn't giving the application attention :-). Another possible approach would be to have the default be for notifications to show up in browser UI associated with the page --- e.g., highlight the tab title and show the notification(s) at the top of the page if you switch to the tab --- and in that notification-showing UI, offer a show on desktop button which lets the notifications for that application migrate to the desktop --- effectively a permission grant. Of course, asking each of these while using the application would also be painfully annoying, and it's not obvious how to make permissions meaningful to the user (eg. when you use its feature) while also scaling to lots of permissions. I think we have to consider specific cases. For Skype, it depends on whether all those permissions are really needed, and why... It might not be that hard to figure out how to make on-demand permission grants intelligible. We owe it to users to try. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] Indicate a file name for data: URLs?
On 3/21/11, Philip Jägenstedt phil...@opera.com wrote: On http://foolip.org/microdatajs/live/#json I have a Download it! function which uses data: URLs to save JSON generated by JavaScript. The only real limitation with this approach is that one cannot suggest a file name, so in Opera the suggested file name is default. Sorry for my naïvety, but does there need to be a suggested file name?
Re: [whatwg] Content-Disposition property for a tags
On Mon, Apr 11, 2011 at 1:28 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Apr 11, 2011 at 12:48 PM, Eric Uhrhane er...@google.com wrote:
Folks did propose making FileSaver do this at TPAC, but we haven't
gotten around to hashing out the details yet. The idea was that
FileSaver would take a URL instead of a Blob, and thus could also be
used for downloading arbitrary links.
I missed that API; I like that approach. a href=url
onclick=if(FileSaver in window) { new FileSaver(this.href); return false;
}
Thinking about this some more, FileSaver can't handle
Content-Disposition: filename adequately. For example, compare
FileSaver to the approach originally posted (with a slight
modification):
a href=http://example.com/datastore/76cf656d2240be006aef7466a45628d1e531eb5c;
onclick=new FileSaver(this.href, 'downloaded_image.psd'); return
false;Download PSD/a
a href=http://example.com/datastore/76cf656d2240be006aef7466a45628d1e531eb5c;
disposition=attachment filename=downloaded_image.psdDownload PSD/a
The FileSaver method breaks if the user opens the context menu and
selects save link as. It also breaks if he selects the region of
text and uses a download manager's download all selected links
feature. Tools like wget couldn't support this. Drag-and-drop could
also take hints from @filename, so dragging the link into Photoshop
could give it the correct filename.
--
Glenn Maynard
Re: [whatwg] Content-Disposition property for a tags
On Sat, Apr 30, 2011 at 2:24 PM, Michal Zalewski lcam...@coredump.cx wrote: Note that somewhat counterintuitively, there would be some security concerns with markup-level content disposition controls (or any JS equivalent). For example, consider evil.com doing this: a href='http://example.com/user_content/harmless_text_file.txt' disposition='attachment; filename=Important_Security_Update.exe' To do some contriving, in trying to follow the example: if example.com is a site trusted by the user or administrator, it may be flagged in the browser as always allow saving sensitive file types from this site. If you can override the C-D header remotely, and if there exists (for example) a text file whose contents happen to alias to a dangerous executable, then you could cause a dangerous executable to be saved to disk. Browsers might need a mechanism to remember whether the effective Content-Disposition header is trusted (received from the response, or overridden from the same origin) or not, which is sort of annoying. Maybe a bit more contriving could come up with a more plausible example. Downloading files in general is a very problematic area, because there's a very fragile transition between HTTP MIME type and filesystem extension or other OS-level content determination mechanism. Many browsers either don't try to do anything useful to prevent weird promotions from safe to unsafe document types; or enforce decidedly imperfect logic. Allowing attackers to further control this process has some risks. It's also a very important area for web apps, and one that's currently lacking, so I do think it's worth the work. -- Glenn Maynard
Re: [whatwg] Content-Disposition property for a tags
On Sat, Apr 30, 2011 at 2:54 PM, Michal Zalewski lcam...@coredump.cx wrote: My concern is a bit more straightforward. To use a practical example: just because a social networking site allows nearly arbitrary JPEG files to be uploaded and served as profile pictures (Content-Type: image/jpeg) does not mean that the applications wants users to be offered that content as a download named Security_Update.exe, supposedly coming from that trusted site. So, it's not so much the security issue (the browser's job), but an appearance-of-fault issue: the site not wanting to be blamed if the browser fails at that job. But yes, there are probably also potential interactions with whitelisted domains, especially given that the whitelist-based capabilities are expanding rapidly. That suggests that this should be added sooner rather than later, so the concept of filenames for files on trusted domains being set by untrusted domains is considered in the design of these capabilities, rather than being bolted on later. -- Glenn Maynard
Re: [whatwg] sic element, was: Re: Exposing spelling/grammar suggestions in contentEditable
I've been convinced that the there's not enough need for a sic element to introduce one, mostly by Tab Atkins Jr. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029585.html and Benjamin Hawkes-Lewis http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029586.html Thanks! However, I disagree with some points made in the latter e-mail. I'll address these points below. Now that I agree that the proposed element doesn't need to be introduced, the following is largely irrelevant though. Am 31.12.2010 um 17:30 schrieb Benjamin Hawkes-Lewis: On Fri, Dec 31, 2010 at 3:17 PM, Martin Janecke whatwg@kaor.in wrote: Am 30.12.2010 um 22:49 schrieb Benjamin Hawkes-Lewis: [snip] 1. What problem(s) does indicating where mistakes have been reproduced solve? I understand the question in this context as a concrete formulation of questions such as What problem(s) does meta data solve? What problem(s) does semantic markup solve? Not really. Semantic markup is a tool HTML uses to solve problems. The sort of problem statements we're looking for are things more like this. End-users need to find information within complicated pages quickly. By marking up headings semantically we allow users to scan the page visually, or select a heading from a list, or jump to the next heading with a shortcut key. I see. Nevertheless, I don't really understand the necessity to explain why one would indicate where mistakes have been reproduced in a quoted text. It's a common thing to do and sometimes it is actually important to do it. I think we all know why text is sic'ed, don't we? I do understand the necessity to discuss whether a new HTML element is the best approach to the problem, though. Apart from informing human readers about the correct reproduction of a misspelled word, a HTML sic would indicate the same to web applications. Think of a search engine, which, as one factor of their ranking algorithm, considers orthography and grammar in a page as quality factor. The search engine could be made to ignore (reasonably few) sic-marked errors in such an algorithm; i.e. not let sic-marked errors rank the page lower. Would search engines benefit from markup for this? Seems to me it would be fairly easy for an search engine to spot plain text [sic] and act accordingly. Sic'ing text is a concept independent of the human language the sic'ed text is written in. Writing [sic] in plain text is – although common in many languages – not used universally in all languages. I'm sure it's expressed differently in Japanese, for example. Recognizing an element is easier than recognizing many different ways to express this in different languages. Also, computer programs could better act according to an explicitly sic'ed range of text (the quick sicborn phox/sic jumps over ...) than to a single plain text [sic] which just indicates a reproduced error somewhere before (the quick born phox [sic] jumps over ...). [...] In either case, I think the effect of all this on rankings would in practice be so small that it wouldn't be worth the costs to add a feature to HTML to support it. Search engine vendor testimony to the opposite would be very useful here. I agree. There doesn't seem to be much interest in it. I think sic is a more HTMLish solution than a plain text [sic] -- just like ulli...li... styled with list-style-type:decimal is more HTMLish than div1. ...div2. ... I think that's like arguing sentenceThe cat sat on the mat/sentence is more HTMLish than The cat sat on the mat. ;) I disagree. But your comment made me think more about what makes sic and ol (sorry, I meant ol instead ul for a numbered list, of course!) better HTML, while I'd reject sentence. Both examples div1. ...div2. ... and … [sic] convey textual information (represented by ... here) and both examples also include meta information: the first example an intentional order of items, the second example an intentional (mis)spelling to reproduce an original source without changes. In both examples this meta information is hard-coded as additional plain text in one specific style, although other styles are very well possible: for example people also use a. … b. … to convey an order and (sic!) or [isic/i] to convey intentional (mis)spellings in English texts. You'll find other styles in other languages to convey the same meta information. But note that not the meta information itself is language specific. Only the way of conveying the meta information is. Furthermore, in case of [sic], its language specific style doesn't depend on the language of the quote it is placed in, but on the language of the context of the quote. For example, a webpage in Chinese that quotes an English text, would rather style sic in a Chinese way within the English text, because the sic isn't part of the original English text but an information added by the Chinese publisher for a Chinese
