Re: [whatwg] PSA: Chrome ignoring autocomplete=off for Autofill data
If the site sets autocomplete=off could you disable the saving of new suggestions? One of the main use cases for turning off autocomplete is to disable the saving of sensitive or irrelevant information. If the user is filling in an address or cc num it's likely they have the opportunity to save that on other sites. Sent from my iPhone On Nov 13, 2014, at 2:20 PM, Evan Stade est...@chromium.org wrote: Hi, Chrome already ignores the prevalent autocomplete=off for password fields. We plan to ignore this tag for Autofill (addresses, credit cards) fields as well. autocomplete=off will still be respected for autocomplete data (e.g. past searches on crbug.com). We think this will break a very small number of sites that use autocomplete=off for legitimate reasons, e.g. they use the Google Maps Places Autocomplete API, and don't want Chrome trying to autofill in addition. But it will improve behavior for a much larger set of sites which use autocomplete=off for confused reasons as a part of, e.g., their checkout flow. We have found the prevalence of autocomplete=off in top sites' checkout forms to be quite high. Currently this new behavior is available behind a flag. We will soon be inverting the flag, so you have to opt into respecting autocomplete=off. I am curious what other browsers do around autocomplete=off, and if they respect it for address/user profile/credit card type data. Since there's no way to feature detect the browser's behavior, it would be convenient if all browsers agreed on the meaning/value of the attribute. -- Evan Stade
Re: [whatwg] allow link in body + DOM position as a rendering hint
We talked a bit before about the idea of async stylesheets (like async scripts). That kind of functionality could implement something similar to this proposal (though in a bit more of a clunky way -- you need to have an inline visibility:hidden style for the content you want to hide then override that in css). It seems like there's a consistency problem between script loading and stylesheet loading. Would it be worth trying to ensure there is parity between those two things. Script tags already implement the behavior you are suggesting (a script can be inside the document body and will only block content that occurs after it). On Wed, Oct 29, 2014 at 2:46 PM, Ilya Grigorik igrigo...@gmail.com wrote: (based on discussion at the webperf group meeting at TPAC... hopefully I captured the discussion correctly. If not, please jump in!) HTML5 spec: If the rel attribute is used, the element is restricted to the head element. [1] Above language is too restrictive, allowing link element to be present in the body (as many sites already do, and all browsers support), would enable useful performance optimizations for stylesheets in particular - e.g. IE treats stylesheets in head as render blocking and will hold page rendering until they are downloaded and executed, however a link rel=stylesheet... within body is treated as render blocking for DOM-content before its declaration (although, this behavior is only triggered as an error condition based on some additional timeouts). Above IE behavior enables faster first-paint for above the link content and is already in use by some developers - i.e. sites are *forcing* the IE error condition to deliver faster paints. html style /* critical css */ /style body header.../header style rel=stylesheet href=other.css/ section.../section /body /html In above example header content may be painted by the browser before other.css is downloaded and processed. Effectively, the position of the link element in the document acts as a hint to the UA that it may (not must) paint the DOM-content before it without blocking on it. To be clear, this proposal does *not* change any existing semantics of CSS. Once processed, other.css *may* impact rendering of the content above it (it's applied against global context), which may cause reflows, etc. However, a well implemented site can avoid unnecessary reflows+paints by splitting relevant styles in a way that minimizes interaction between various sections. Baidu team has prototyped something similar via their First Screen Paint In Advance proposal [2] and saw significant improvement in rendering times on mobile devices. tl;dr: proposal is... 1) allow link tags in the body 2) add a note to implementors: consider treating link tags in body as a hint to the UA that what is above the link tag (in DOM order) should not be blocked on painting Above behavior is already deployed in the wild (both on sites and implemented in some browsers), and helps deliver faster first paints, as evidenced by Baidu and IE experience. Based on discussion at the TPAC meeting, there was interest from IE, Chrome, and Safari (we didn't have anyone from Mozilla to comment) in exploring this further... However, that would require some spec updates on HTML front. Thoughts? [1] http://www.w3.org/TR/html5/document-metadata.html#the-link-element [2] http://www.w3.org/Submission/first-screen-paint/
Re: [whatwg] allow link in body + DOM position as a rendering hint
On Thu, Oct 30, 2014 at 2:26 PM, Ilya Grigorik igrigo...@gmail.com wrote: On Thu, Oct 30, 2014 at 12:17 PM, Ben Maurer ben.mau...@gmail.com wrote: We talked a bit before about the idea of async stylesheets (like async scripts). That kind of functionality could implement something similar to this proposal (though in a bit more of a clunky way -- you need to have an inline visibility:hidden style for the content you want to hide then override that in css). Right, the problem with previous proposals for async stylesheets is that it is really hard to reason about how+when they will be applied, which would force you to manually hide most of the content and then modify the visibility when stylesheet is ready... at least, if you want to avoid FOUC. The proposal here is an in-between solution that's much simpler to deploy: the position of the link in the doc acts as a hint that DOM-content before it does not have to block paints on it, so the UA can do the bookkeeping for what can be painted vs what should remain hidden. All the developer has to do is move the link's in right positions in the doc. To be clear -- I'm suggesting we do both, not just async scripts. I agree that async stylesheets are harder to use. However, they also make some use cases simpler (For example, Facebook implements the idea of an early flush -- when we get a request we render all the resources we think the page might need before doing any computation. async stylesheets would prevent these resources from blocking early parts of the page). It seems like there's a consistency problem between script loading and stylesheet loading. Would it be worth trying to ensure there is parity between those two things. Script tags already implement the behavior you are suggesting (a script can be inside the document body and will only block content that occurs after it). Depends on what you mean by parity? If you mean async, etc, then personally I'd prefer that we keep that as a separate discussion (and I'm not convinced we need async for stylesheets). What we're proposing here requires minimal change to the spec and reflects the (already) implemented patterns both in markup and in some rendering engines... a simple update that could pay high perf dividends. So by parity I mean we should try to make sure roughly the same set of tools are available for loading scripts and stylesheets. For example, today you can achieve the semantic of this resource should only block resources after it with scripts: body divFast content/div script src=... / divThis will only show up after the script is loaded/div /body This proposal would add that functionality for stylesheets. I think this is a good thing. But I think it will be simpler for web developers if we can have similar functionality for script and stylesheet loading. This way we don't have to explain if you want a script not to block the page, we recommend you use async. On the other hand, if you have a stylesheet, you have to put it in the middle of the body. Having both things lets us have a simple explanation: Your CSS/JS will block content that comes after it in the DOM unless you use the async tag. Use the async tag if you can tolerate the resource in question not being loaded.
Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)
Hey, I think it'd be worth supporting encrypting the password. There are a number of reasons why a site might have trouble using a hash: 1) It is unlikely that whatever standard format the browser supports will be exactly how passwords are hashed today. It is possible to migrate hashes (if the user doesn't use the new hash format, on the first login, take their plain text password and re-hash it. alternatively, you can make your new format an extra hash on top of the old format). Both of these require either an unhashed password or a password hashed in some custom format. 2) Some sites may take measures to handle typos. For example, if your password is MyPassword and you log in with the password mYpASSWORD, Facebook lets you log in. The password does not need to be stored in plain text. You can simply do the reverse-all-caps transform and re-hash the password to verify. In theory a site could solve this by storing multiple hashes. 3) A user might have multiple username formats (eg, you can log in with email, phone# or username) 4) This functionality could be useful for credit card numbers, which obviously can't be hashed. Even though encryption doesn't prevent deriving the original password (like hashing would), it could still be very valuable. For example, it would prevent a 3rd party from seeing the users plain text password (even if they are able to replay it). It reduces the number of systems which are exposed to the password. -b On Thu, Oct 16, 2014 at 11:46 AM, Mike West mk...@google.com wrote: On Thu, Oct 16, 2014 at 11:43 AM, John Mellor joh...@google.com wrote: On 16 October 2014 08:52, Mike West mk...@google.com wrote: * Server stores credentials as `sha512(password + username)`. It might be better to require PBKDF2/bcrypt/scrypt. Yeah, that certainly makes sense. -mike
Re: [whatwg] Hashing autofilled data (was Re: Proposal: Write-only submittable form-associated controls.)
Correct. For example, if you used CloudFlare to terminate your SSL traffic, this measure would prevent CloudFlare from ever seeing your passwords. The key to decrypt the password (or CC#) can be limited to the absolute minimal surface area necessary. On Thu, Oct 16, 2014 at 2:27 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Oct 16, 2014 at 2:22 PM, Ben Maurer ben.mau...@gmail.com wrote: It reduces the number of systems which are exposed to the password. You mean after the password arrives at the server? Because for transfer we should advocate TLS. -- https://annevankesteren.nl/
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
- Would one be able to validate the password field (eg, to detect an empty password)? Is HTML5 validation allowed on a writeonly field. - Could a cross-domain XHR be made? Could FormData from such a field be limited to the same domain. - Something that could be interesting is if the password field only exposed an encrypted or hashed value. For example, it'd be pretty awesome if a website could put a public key and say when a user types in a password here, encrypt it with the public key before sending to the server. This could prevent an attacker from ever seeing the plain text password. Today you could do this with JS, but it would prevent one from using the writeonly attribute. On Wed, Oct 15, 2014 at 4:15 PM, Mike West mk...@google.com wrote: # Problem A user’s credentials are valuable, and are often the key target of phishing and content injection attacks. If a content injection attack can trick a user's credential manager into autofilling her credentials, then the user’s credentials will be available to the attacker directly via DOM APIs or indirectly via form submission to a malicious endpoint. The latter risk can be mitigated via the Content Security Policy `form-action` directive, but the former is a real problem. If passwords are a simple value accessor away, users are at risk. ## Proposal We could mitigate this latter risk by allowing sites to opt-in to denying DOM access to an element's content. If JavaScript can't grab the value, then script injection attacks have a much more difficult time exfiltrating interesting data. This might be as simple as adding a writeonly attribute to submittable elements: input writeonly type=password This would throw an `InvalidStateError` on `value*` accessors, bar the element from constraint validation, block `keydown`, `keyup`, `keypress` events, and probably other things I haven't considered yet. `FormData` objects created from forms including these writeonly elements would be opaque. You could use them to submit an XHR request, but you couldn't read the values directly from script. This state could also be controlled via a Content Security Policy directive which would set writeonly state for some arbitrary set of submittable elements, perhaps based on autocomplete attribute values. Perhaps: Content-Security-Policy: form-writeonly cc-number cc-csc ... current-password new-password ## Spec Suggestions I've strawmanned out the monkey-patching this would require of XHR, Fetch, and HTML in a bit of detail at https://mikewest.github.io/credentialmanagement/writeonly/, and there was a short-lived public-webapps thread at http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0165.html (and a shorter-lived discussion at http://specifiction.org/t/write-only-input-fields/598). ## Implementer Interest I'd like to implement pieces of this in Chrome to harden our password manager; if we can use this state as a heuristic to mark particular credentials as writeonly, we can keep them out of the renderer process entirely, which would be a nice win for security. I've also talked about it tangentially with Anne and Jonas at Mozilla (the former in relation to Fetch, the latter in relation to a proposed Credential Management API). Neither jumped on it as the best thing ever, but they were both more than marginally supportive. Thanks! -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Preloading and deferred loading of scripts and other resources
Thanks for writing this all up. A few questions/thoughts: (1) Dependencies in this model seem to be strict execution dependencies. It's possible some use cases might want to use dependencies to describe loading priority. As an example, imagine a Facebook page with 3 JS files: Feed.js -- Needed to render the user's feed Chat.js -- Displays the user's friends who are online PhotoViewer.js -- When the user clicks a photo, this file creates a photo viewer allowing the user to browse an album. Until the user clicks something, this file isn't needed. Roughly, the behavior we want here is: load Feed, then Chat, then PhotoViewer. But if the user clicks a photo move PhotoViewer to the front of the line. How do I express the relative ordering of Feed vs Chat vs PhotoViewer? I wouldn't want to use dependencies, because if PhotoViewer depended on Chat then if I call .load() on PhotoViewer it will force Chat to be downloaded. (2) Can inline scripts have needs? This seems like something potentially useful (eg, you include a script tag for Google maps then you have an inline script to create a map. You want the inline script to only execute once maps is loaded) (3) How does loading interact with the cache? For example, if I have a link load-policy=declare and the resource is in the browser's cache, would the ready promise be fulfilled? This could be very useful for applications -- sometimes there is functionality you are willing to execute immediately if the resource is in the user's cache. On Fri, Aug 22, 2014 at 5:44 PM, Ian Hickson i...@hixie.ch wrote: When I last looked at preloading scripts, it was pointed out to me that the Web Perf WG had some work ongoing in this space, so I decided to let them take care of it. However, nothing much seems to be happening there, and so I'm looking at this again. It's also been pointed out that limiting this to just scripts preloading maybe taking too narrow a view, and that we should also consider preloading and deferring loading of other resources, such as images, style sheets, and so forth. I will start by looking at use cases again, then go through some of the feedback on the last proposal I'd made in this space, and then make a new proposal intended to address the use cases and feedback. On Fri, 15 Aug 2014, Ben Maurer wrote: [Use-case F:] A website has a page where media is the primary content. It would like to make sure that media is downloaded before JS [e.g. flickr, youtube, facebook photos] [Use-case G:] A website knows there's a piece of Javascript code that the user might need if they click on a part of the page. The developer would like to have the user download it, but not at the expense of other resources. [Use-case H:] A website is prefetching photos in a photo album and would like to make sure these images are lower priority than images the user is actually viewing. On Mon, 28 Jul 2014, Ben Maurer wrote: [Use-case I:] Facebook uses an automated pipeline to decide what CSS/JS files to package together. If we could pass a custom header in the request for a CSS file (for example: what part of the page caused that file to be loaded) we could use this information in our packaging system to make smarter decisions. On Tue, 22 Jul 2014, Ben Maurer wrote: [Use-case J:] The way we render pages at Facebook [is essentially that we] flush sections of HTML with a list of CSS and JS dependencies for each section. The HTML is only rendered once these resources are loaded. [Use-case K:] We have a few other use cases for this type of dependency (for example, we have a method where you can say call this callback once resources X, Y and Z are requested). On Tue, 3 Sep 2013, Ryosuke Niwa wrote: [Use-case L:] A web page wants to load and execute a script widget.js if the script is already cached in the browser. However, it wants to load other essential assets such as images first if it's not already in the cache except as long as the user had not started interacting with the parts of the page that require widget.js. On Tue, 18 Mar 2014, Jonas Sicking wrote: [Use-case M:] Being able to specify that an image/video should only be downloaded on demand (aka lazily), i.e. when it's in view, or about to be in view. Use case is both to lower bandwidth in cases of long pages where the user doesn't always scroll to the bottom, as well as make sure to fill the network pipe with the most important resources first. [Use-case N:] Being able to specify that a stylesheet should not block rendering. Use case is to preload stylesheets that will be used by content that isn't rendered in the initial view, but that might be rendered later. [Use-case O:] Being able to specify some form of prioritization for resources like (non-blocking) stylesheets, (non-blocking) scripts, images, video, iframes etc. Use case is making sure to fill the network pipe with the most important
Re: [whatwg] exposing dependencies + weights (aka, priorities) to web developers
Hey, Thanks for writing this up! So to the extent we are simply exposing http/2 semantics, this spec seems pretty clear. Two questions that I have that aren't answered by the http/2 spec: - What do we expect the browser to do with priorities set cross domain. Eg, if I express that a.com/foo.js depends on b.com/bar.js, does the browser do anything about this. What if b.com/bar.js depends on a.com/blah.js. Would we tell a.com that foo.js depends on blah.js? - Developers might have something they would want to speculatively fetch only if http/2 is being used (and therefore they know the resource won't compete for bandwidth with other resources). Maybe this could be solved by simply allowing the user to tell if the browser supports http/2. A more advanced solution could be to allow the user to say don't send this fetch request unless it's over http/2. One other thing I didn't see any mention of in the write up -- it could be useful to change priority while the request is in flight. http/2 supports this, so it'd be great if this spec could expose it. On Thu, Aug 14, 2014 at 6:16 PM, Ilya Grigorik igrigo...@gmail.com wrote: (followup / continuation of [1]) Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. Would love to hear everyone's thoughts: https://docs.google.com/document/d/1jSpWc6jkrUoYtGWcxev9Blkkv9RhoO1XtqinBvXqhgY/edit ig [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html
Re: [whatwg] exposing dependencies + weights (aka, priorities) to web developers
Some cases I can think of off the top of my head: - A website has a page where media is the primary content. It would like to make sure that media is downloaded before JS (example: you go to flicker.com/my-image, the browser should probably prioiritize that image over a pice of javascript that is not critical to the user's interaction with the page). - A website knows there's a piece of Javascript code that the user might need if they click on a part of the page. The developer would like to have the user download it, but not at the expense of other resources. - A website is prefetching photos in a photo album and would like to make sure these images are lower priority than images the user is actually viewing. On Fri, Aug 15, 2014 at 9:17 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 14 Aug 2014, Ilya Grigorik wrote: Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. It would be great to get a set of use cases describing what your proposal is addressing, since that would more easily let people evaluate whether it's worth doing, and if so, whether this proposal does it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource hints and separating download from processing
Sweet, I think we're on the same page. I completely agree with your high
level goal of a declarative fetch interface.
Agreed that matching is still critical, eg for the Link header use case.
On Thu, Aug 7, 2014 at 10:40 PM, Ilya Grigorik igrigo...@gmail.com wrote:
On Thu, Aug 7, 2014 at 4:39 PM, Ben Maurer ben.mau...@gmail.com wrote:
On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik igrigo...@gmail.com
wrote:
It would be nice if there was a more declarative relationship between
the declarative fetch and the eventual use of the resource (assuming the
resources are on the same page).
I would like to break that dependency. I want layering separation where
we have a clean way to fetch resources (with custom parameters like
headers, priorities, dependencies, etc), and a layer that's responsible for
consuming fetched resources for processing in the right context (enforcing
security policies, etc), and at the right time -- e.g. see Example 3 under:
https://igrigorik.github.io/resource-hints/#preload
So I guess my worry here is that the loose dependency could be hard to
debug. As a concrete example, we use crossorigin=anonymous on our script
tags so that we can get stack traces. My understanding is that this
requires an Origin header to be sent with the request and a CORS header in
the response. If my link rel=preload doesn't have a crossorigin
setting, the requests wouldn't match up.
We can't control the response bits, but as far as emitting the right
request headers and communicating stream priority + dependencies, all of
that could be exposed via some set of options when the request is built up.
This is where we get back to the syntax (e.g. params={...}, or some
such), which would probably map directly to various Fetch API use cases and
options. Effectively, I want a declarative Fetch interface.
I guess what I'm asking for here is some programmatic way of connecting
the fetch with the consumption. For example, exposing the fetch object of
the rel=preload and allowing you to construct a script tag explicitly with
the fetch object.
+1. That said, we still *need* a mechanism where the matching does not
rely on manual plumbing with JavaScript - e.g. server returns a set of
hints via Link header for critical resources, which must be matched by the
user agent against appropriate requests later in the doc.
ig
Re: [whatwg] resource hints and separating download from processing
Hey,
Not sure if you've seen this thread:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html.
I had the same basic interest as you (decoupling resource fetching from
execution). I'd be curious to hear your thoughts about that thread.
I really like the concept of a declarative fetch -- being able to specify
arbitrary fetch parameters (eg, headers or a yet-to-be-defined interface to
define HTTP/2 priority) is very powerful. It would be nice if there was a
more declarative relationship between the declarative fetch and the
eventual use of the resource (assuming the resources are on the same page).
For example, in the thread I had suggested fetch.asScript() though it seems
like people preferred using an actual script tag to initiate the fetch
(with a parameter saying not to execute).
-b
On Thu, Aug 7, 2014 at 2:04 PM, Ilya Grigorik igrigo...@gmail.com wrote:
I'm working on the resource hints spec we've been discussing on
public-webperf...
This specification defines preconnect, preload, and prerender hints that
the developer, or the server generating or delivering the resources, can
use in an interoperable way to assist the user agent in the decision
process of which origins it should connect to, which resources it should
fetch to improve performance, and which resources may be required by the
next navigation.
Latest draft: https://igrigorik.github.io/resource-hints/
There are still plenty of details to iron out [1] and I'd appreciate any
thoughts or feedback, but in particular I'm interested on suggestions
around this discussion:
https://github.com/igrigorik/resource-hints/issues/6
Some background... Current browsers use resource context and content-type
as a signal for download priority (e.g. scripts get a higher download
priority than images). This is an imperfect signal, but it has served us
well. As a result, in first iteration of the spec I went with type
attribute (on link) as a way to communicate same information to the user
agent. Later (see issue above), it was suggested that context is a better
mechanism to express this and I agree.. except, it opens up a different set
of questions and challenges:
- There are cases where context is known: image, script, etc.
- There are cases where context depends on multiple signals: iframe vs.
iframe+seamless
- There are cases where context is not known precisely ahead of time - e.g.
prerender navigation can be triggered via multiple mechanisms (link click,
window.location, etc).
Long story short, the problem is that context is coupling download,
policy enforcement, and processing. I'm wondering if we should separate
these into:
(1) a mechanism for downloading resources with right priority, etc.
(2) a mechanism for processing downloaded resources where security and
other policies are applied.
Today, CSP blocks requests *before* they are issued. What I'm after here is
applying CSP (and other relevant policies) on a resource that was already
downloaded or is currently in flight -- I believe this is a requirement for
ServiceWorker anyway? I'm sure there are other examples where this is
relevant also.
Separating downloading from processing would expose an important and very
useful platform primitive: it'll allow us (regular developers) to compose
different download behaviors, define when resources are processed and in
which order, etc.
More concretely, picture something like this (don't pay too much attention
to syntax, just hand waving):
(1) link rel=preload href=//thirdparty.com/script.js
execution=required params={...}
...
(2) script src=//thirdparty.com/script.js
(3) script xhr = new XMLHttpRequest(); xhr.get(//
thirdparty.com/script.js
);
---
#1: initiates immediate download - effectively, it's a declarative fetch.
You can also specify execution [2] and other request parameters [via 3, or
something like it].
#2: script request is matched [4] against the preload request, proper
policies are applied and if that checks out, it's processed and executed.
#3: XHR request is matched against preload, proper policies are applied..
and it may get blocked due to same-origin restrictions, or some such.
Assuming this makes sense, I'd drop context and instead rely on
communicating download priority via [3], or something similar. As an aside,
I think [3] is not going far enough, but that's a subject for a separate
thread.
Thoughts?
ig
[1] https://github.com/igrigorik/resource-hints/issues
[2]
https://igrigorik.github.io/resource-hints/#required-vs-speculative-execution
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26533
[4]
https://github.com/igrigorik/resource-hints/issues/5#issuecomment-50809768
Re: [whatwg] resource hints and separating download from processing
On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik igrigo...@gmail.com wrote: It would be nice if there was a more declarative relationship between the declarative fetch and the eventual use of the resource (assuming the resources are on the same page). I would like to break that dependency. I want layering separation where we have a clean way to fetch resources (with custom parameters like headers, priorities, dependencies, etc), and a layer that's responsible for consuming fetched resources for processing in the right context (enforcing security policies, etc), and at the right time -- e.g. see Example 3 under: https://igrigorik.github.io/resource-hints/#preload So I guess my worry here is that the loose dependency could be hard to debug. As a concrete example, we use crossorigin=anonymous on our script tags so that we can get stack traces. My understanding is that this requires an Origin header to be sent with the request and a CORS header in the response. If my link rel=preload doesn't have a crossorigin setting, the requests wouldn't match up. I guess what I'm asking for here is some programmatic way of connecting the fetch with the consumption. For example, exposing the fetch object of the rel=preload and allowing you to construct a script tag explicitly with the fetch object. -b
Re: [whatwg] Accept header
On Thu, Jul 31, 2014 at 1:56 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Jul 30, 2014 at 8:43 PM, Ben Maurer ben.mau...@gmail.com wrote:
On Wed, Jul 30, 2014 at 11:35 AM, Ian Hickson i...@hixie.ch wrote:
1. Expose it on a fetch object available from all the places that can
do fetches. (HTMLImageElement, XMLHttpRequest, StyleSheet, etc)
var img = new Image();
img.src = 'foo.png';
img.fetch.doWhateverWithTheAcceptHeader('foo');
At what point is the fetch actually being initiated? It's possible that
fetch will offer some things which can be done post-request (eg,
dynamically
changing the spdy priority), but the accept header may need to be
specified
pre-request.
Probably not before the end of the current task. The only exception to
that is EventSource and maybe WebSocket, but they can have a
constructor argument of sorts to make this work I guess.
Otherwise you could not set attributes such as crossorigin either.
Ah, cool. If it's not already defined, it'd be great to have a clear
definition of this behavior. I could imagine it being useful for a site to
explicitly initiate the sending of the request (eg, if it was aware an
expensive JS function was about to execute).
I appreciate your guys' help in thinking out this use case.
-b
Re: [whatwg] Fetch Objects and scripts/stylesheets
Another concrete example with img tags: sometimes an abusive user will use a site like Facebook as a CDN -- they'll upload a picture and hotlink it from elsewhere. We could insert a time-stamped authentication token as a custom header. Today we sometimes do this via the query string -- giving the user a token that lasts for a few days. This means we bust the user's cache every time we rotate the token. With a custom header, the browser cache stays in tact. Images would also be a great example of where logging headers could be extremely helpful. For example, we could log what module within a page rendered an image and monitor bandwidth usage and CDN cache hit rate on a per module basis. In the past it's taken us a long time to debug issues that could easily be found with this method. On Mon, Jul 28, 2014 at 11:51 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 28, 2014 at 8:34 PM, Ian Hickson i...@hixie.ch wrote: What's the use case here? Why are we trying to send custom headers on a link? E.g. for img and such you want to turn authentication dialogs off. Cross-origin images can be fine, but not if they start spawning confusing dialogs to users making them leak passwords. -- http://annevankesteren.nl/
Re: [whatwg] Fetch Objects and scripts/stylesheets
The idea is you could specify any parameter to fetch. For example, if fetch allowed you to specify an HTTP/2 priority, you could specify that. As a concrete example of why passing a header might be useful, Facebook uses an automated pipeline to decide what CSS/JS files to package together. If we could pass a custom header in the request for a CSS file (for example: what part of the page caused that file to be loaded) we could use this information in our packaging system to make smarter decisions. While we do have the referrer header, a piece of interactive javascript on a page might be the cause of the CSS file being required. A custom header would allow logging this. On Mon, Jul 28, 2014 at 11:34 AM, Ian Hickson i...@hixie.ch wrote: On Mon, 28 Jul 2014, Ben Maurer wrote: What about initial parameters to fetch (vs modifications you could make in flight via the myfetch object). Would there be an attribute of link that you could use to pass parameters to fetch (eg a custom header)? What's the use case here? Why are we trying to send custom headers on a link? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Mon, Jul 28, 2014 at 12:51 PM, Ian Hickson i...@hixie.ch wrote: Ah, I see. Makes sense. Are there any cases where you'd know the headers you want to send at the time the markup is written, before JS is involved, or would you always be updating the fetch settings from script? I think there are cases where we'd want to send data directly from the markup. For example logging the fact that the load was initiated from the preloader could be useful! Also, I'm hoping that one of the things we could eventually accomplish with exposing the fetch object is increasing the number of our scripts that are accessible to the preloader. Today, Facebook avoids sending script tags directly in the document -- there is quite a bit of JS on the Facebook home page, but not all of it is needed to make the document interactive. Therefore, we send JSON blobs of which JS files will be needed for the document to our client side javascript code. This code schedules script loading, only putting in non-critical JS after the critical JS is loaded. By exposing the fetch object, we could take advantage of whatever functionality the browser gives us to control prioritization. For example, for clients using SPDY, if fetch exposed a way to set priority of the request, we could expose all of our JS to the preloader and let our CDN order it's response. We can definitely expose the fetch settings in markup, e.g. in the trivialest sense just by embedding a JSON blob in an attribute, or maybe in a more friendly dedicated microsyntax. I just want to make sure that that's the right thing to do before we go down that path -- meaning, that it has sufficient use cases to justify it, rather than require consumers to set these settings from script. I'd argue we're already expressing many of the fetch settings already. For example, the crossorigin attribute exposes the mode of a fetch ( http://fetch.spec.whatwg.org/#concept-request-mode). The sub-resource integrity spec provides a way to pass an integrity attribute to the fetch algorithm (http://www.w3.org/TR/SRI/). Directly exposing fetch parameters to the user could allow specification of this type of feature with adding new attributes to every type of request. As mentioned earlier in the thread, it could also help apply these attributes in difficult contexts (eg, the source of a background image in a CSS file). While providing fetch settings might not be the friendliest interface, I think this would be a huge win for advanced web sites. I'd point out that for sites that are advanced enough to benefit from this feature, they are highly unlikely to be writing their code by hands -- their server side code is likely generating the script tags to be inserted in their document.
Re: [whatwg] Fetch Objects and scripts/stylesheets
Hey,
Yeah, I think that API would be perfect (assuming that whenneeded=true
initiates the fetch, but not the load into the document). In combination
with allowing the user to specify an attribute with a set of parameters to
the fetch algorithm (eg, a custom header) I think that would cover the use
cases I was thinking of.
-b
On Tue, Jul 22, 2014 at 5:33 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 22 Jul 2014, Ben Maurer wrote:
To follow this up with a concrete suggestion:
var myfetch = window.fetch('my.css', {'fetch-as': 'stylesheet'});
myfetch.then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
...
Why not:
var mystyle = E('link', { rel: 'stylesheet', href: 'my.css',
whenneeded: true });
document.body.appendChild(mystyle);
var myfetch = mystyle.fetch;
...
...where E() is some mechanism to easily create new elements (we need
one of those regardless), and whenneeded is some attribute that controls
the load policy (and in this case, tells it to not load yet, since I
presume that's what you're going to do next with the myfetch variable)?
(whenneeded here is a placeholder. I don't expect to actually go with
that. I just used it because it's what I had proposed the last time this
came up.)
That seems like it'd be no more complicated, but would involve less new
API surface (not to mention fewer new ways to shoot yourself in the foot,
e.g. getting the 'fetch-as' value wrong), and wouldn't require us to come
up with a way to enumerate all the kinds of fetch in an API.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fetch Objects and scripts/stylesheets
On Tue, Jul 22, 2014 at 10:26 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 21 Jul 2014, Ben Maurer wrote:
(1) Allowing the user to specify parameters to Fetch. For example, a user
could say:
script src=/my.js params={'headers':{'myheader':'value'}}
id=myscript /
This would allow the user to make any type of request customization that
they could for a direct call to Fetch.
I think this would make a lot of sense. It's similar to earlier
suggestions for controlling Referer on a per-link basis, but more
generic. The problem I had with the proposals for controlling Referer was
that while there's an obvious way to do it for script and link, it
quickly starts breaking down don't have a 1:1 mapping of URL to element.
For example, how do you get the fetches of URLs in a style sheet? Or of
the poster frame of a video element? Or EventSource objects? Should we
just have different ways to set the options for each one?
I guess the upshot of of doing this through fetch is that once we added the
ability to specify fetch metadata it would hopefully reduce the need for
future modification of all the different ways one could load an object.
http://lists.w3.org/Archives/Public/public-webappsec/2014Jan/0129.html
suggests the idea of using fetch for stylesheet subresources in the context
of subresource integrity.
(3) Allowing the user to construct a script or stylesheet from a fetch.
Complex sites often want precise control over when scripts and
stylesheets are loaded and inserted into the DOM. For example, today
inserting a stylesheet blocks the execution of inline script tags. Some
sites may know that this dependency is not needed.
This specific use case is something I'm already working on. My long-term
plan is to integrate something like this with the HTML Imports dependency
model and the ES Module dependency model so that we have a single model
that can handle everything.
This sounds interesting. The way we render pages at Facebook seems very
similar to what you are suggesting. We essentially flush sections of HTML
with a list of CSS and JS dependencies for each section. The HTML is only
rendered once these resources are loaded. In essence, it seems like we're
doing inline HTML imports. We have a few other use cases for this type of
dependency (for example, we have a method where you can say call this
callback once resources X, Y and Z are requested.
var myfetch = window.fetch(...);
myfetch.then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
By calling asStyleSheet, the user could preserve the devtools experience
that exists today while still having complete control over the fetching
of their content.
We could do this too. It's mostly just a convenience method, right?
One advantage of doing this is that if there is some use case a site has
that isn't met by the dependency model they can still manually separate the
fetch of an object from its insertion into the DOM. Giving the author the
freedom to manually separate the fetch of a resource from it's use in the
document gives them a powerful ability to experiment with different
approaches to resource loading. asStyleSheet/asScript wouldn't merely be a
helper method to construct a stylesheet from a given string of text. For
example, line numbers in developer tools (or JS stack traces) as if they
were loaded directly from the given URL. A browser might decide to parse
the JS/CSS in a background thread as soon as the document was fetched (or
cache a pre-parsed version of the file).
This model also might be beneficial for sites that were written prior to
the dependency model you are describing. For example, at Facebook we
already schedule JS/CSS loading ourselves. This API would allow us to do
things like fetch a CSS stylesheet without blocking inline script execution
that follows while making a minimal number of changes to the site.
-b
Re: [whatwg] Fetch Objects and scripts/stylesheets
Nothing prevents a website from downloading content via fetch/XHR and simply inserting that text into the DOM. For example, Gmail seems to fetch many of its resources this way today. This API seems strictly better than a site that fetches text and just inserts it into the DOM. Also, it seems like CSP or extensions could still hook into this API, maybe not as early as before. For example, CSP would still know the URL of the resource that had been loaded as a script / stylesheet. While it wouldn't be able to block the loading, it could block the document from being turned into a script or stylesheet element. One could also imagine a flag passed to fetch saying fetch this document as if it were the src of a script tag. Perhaps that flag would be mandatory for one to use the asScript API. On Tue, Jul 22, 2014 at 11:34 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/22/14, 2:01 PM, Ben Maurer wrote: One advantage of doing this is that if there is some use case a site has that isn't met by the dependency model they can still manually separate the fetch of an object from its insertion into the DOM. One issue worth considering here: there are various situations (CSP, extension) in which a browser would like to know what sort of resource is being loaded, or more precisely how it will be consumed, before loading it. From that point of view, adding a way to customize fetch paramaters on link rel=stylesheet or some other mechanism that tells the UA up front what is being fetched is vastly preferable to taking an existing fetch and synthesizing a stylesheet from it, because it provides a lot more control to the user agent and user's extensions. -Boris
Re: [whatwg] Fetch Objects and scripts/stylesheets
I'm pretty new to this spec overall, so please tell me if I'm totally off track here -- the fetch spec states that it's goal is To unify fetching across the web platform by providing consistent handling of things such as CSP or priorities. It seems like the ultimate goal here is that the specification for something like script loading should be able to be explained in the terminology of Fetch. A corollary of this seems to be that a user should be able to simulate the behavior of a fetch initiated by the browser upon seeing a script or stylesheet. This could mean passing custom parameters to the fetch api (eg, asking for a specific priority or asking for CSP to be applied to the element). I understand that these things aren't there today -- and any site using a fetch based system might face the same poor interactions as an XHR based system would today. But in the long term, wouldn't the goal be to have parity between the parameters a user can pass to the fetch api and the parameters the browser passes internally to the fetch API? If the fetch api offers the same set of functionality available to the browser internally, users could experiment with different types of dependency management APIs. On Tue, Jul 22, 2014 at 12:13 PM, William Chan (陈智昌) willc...@chromium.org wrote: On Tue, Jul 22, 2014 at 12:03 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/22/14, 2:57 PM, Ben Maurer wrote: Nothing prevents a website from downloading content via fetch/XHR and simply inserting that text into the DOM. Yes, I know that. But we're trying to develop a better API so sites won't need/want to do that anymore, right? All I'm saying is that we should make the new API play nicer with CSP and extensions than the XHR and stick it in approach does. This won't stop _malicious_ sites, obviously, but it'll help with user control for normal sites who actually want to play nice with the user's settings. +1 Also, I'd like to note that, at least for now without a better prioritization system (I know you'd like to do client=server prior knowledge based prioritization mechanism, smuggling prioritization metadata via opaque-to-the-UA HTTP headers, using the headers attribute), browsers rely on resource type as a key input to their prioritization heuristics. Gmail and G+ both found that this interacted poorly with their XHR based resource loading [1] [2] since XHRs hide the true resource type. This API seems strictly better than a site that fetches text and just inserts it into the DOM. Sure. Also, it seems like CSP or extensions could still hook into this API, maybe not as early as before. For example, CSP would still know the URL of the resource that had been loaded as a script / stylesheet. While it wouldn't be able to block the loading, it could block the document from being turned into a script or stylesheet element. Again, sure. One could also imagine a flag passed to fetch saying fetch this document as if it were the src of a script tag. Right, exactly. That would actually simplify things for UAs as well; for example they have to do different kinds of sniffing on different request types, so knowing ahead of time what sort of thing you're requesting is quite helpful. -Boris [1] - https://insouciant.org/tech/spdy-prioritization-case-study-gmail/ [2] - https://plus.google.com/+ShubhiePanicker/posts/Uw87yxQFCfY
Re: [whatwg] Fetch Objects and scripts/stylesheets
To follow this up with a concrete suggestion:
var myfetch = window.fetch('my.css', {'fetch-as': 'stylesheet'});
myfetch.then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
You can only call asStyleShet if fetch-as=stylesheet. Passing this
parameter would cause the browser to do all the things it would do if it
were fetching a stylesheet. For example, it would specify an accept header
of text/css unless otherwise specified. It would request at the same
priority as the browser requests other stylesheets (again, unless
overridden with a yet-to-be-defined syntax). Rules around CORS and tainting
would be identical to a normal stylesheet fetch (namely that you could
call.asStyleSheet on a request to a different origin but it would have
whatever restrictions the browser has on stylesheets from different
origins). Links in the stylesheet would be interpreted relative to the URL
used to load it, etc.
Essentially, fetch-as=stylesheet would be the canonical definition of the
browser's behavior around loading stylesheets. It would define the behavior
if the proposals I suggested in the original email were implemented --
namely if the user chose to pass parameters to the fetch algorithm or if
the user accessed the result of a stylesheet's fetch.
Boris, Will -- would this setup address the concerns you have about the
problems websites that use XHR to load resources encounter?
On Tue, Jul 22, 2014 at 12:39 PM, Ben Maurer ben.mau...@gmail.com wrote:
I'm pretty new to this spec overall, so please tell me if I'm totally off
track here -- the fetch spec states that it's goal is To unify fetching
across the web platform by providing consistent handling of things such
as CSP or priorities. It seems like the ultimate goal here is that the
specification for something like script loading should be able to be
explained in the terminology of Fetch.
A corollary of this seems to be that a user should be able to simulate the
behavior of a fetch initiated by the browser upon seeing a script or
stylesheet. This could mean passing custom parameters to the fetch api (eg,
asking for a specific priority or asking for CSP to be applied to the
element). I understand that these things aren't there today -- and any site
using a fetch based system might face the same poor interactions as an XHR
based system would today. But in the long term, wouldn't the goal be to
have parity between the parameters a user can pass to the fetch api and the
parameters the browser passes internally to the fetch API?
If the fetch api offers the same set of functionality available to the
browser internally, users could experiment with different types of
dependency management APIs.
On Tue, Jul 22, 2014 at 12:13 PM, William Chan (陈智昌)
willc...@chromium.org wrote:
On Tue, Jul 22, 2014 at 12:03 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 7/22/14, 2:57 PM, Ben Maurer wrote:
Nothing prevents a website from downloading content via fetch/XHR and
simply inserting that text into the DOM.
Yes, I know that. But we're trying to develop a better API so sites
won't need/want to do that anymore, right? All I'm saying is that we
should make the new API play nicer with CSP and extensions than the XHR
and stick it in approach does. This won't stop _malicious_ sites,
obviously, but it'll help with user control for normal sites who actually
want to play nice with the user's settings.
+1
Also, I'd like to note that, at least for now without a better
prioritization system (I know you'd like to do client=server prior
knowledge based prioritization mechanism, smuggling prioritization metadata
via opaque-to-the-UA HTTP headers, using the headers attribute), browsers
rely on resource type as a key input to their prioritization heuristics.
Gmail and G+ both found that this interacted poorly with their XHR based
resource loading [1] [2] since XHRs hide the true resource type.
This API seems strictly
better than a site that fetches text and just inserts it into the DOM.
Sure.
Also, it seems like CSP or extensions could still hook into this API,
maybe not as early as before. For example, CSP would still know the URL
of the resource that had been loaded as a script / stylesheet. While it
wouldn't be able to block the loading, it could block the document from
being turned into a script or stylesheet element.
Again, sure.
One could also imagine a flag passed to fetch saying fetch this
document as if it were the src of a script tag.
Right, exactly.
That would actually simplify things for UAs as well; for example they
have to do different kinds of sniffing on different request types, so
knowing ahead of time what sort of thing you're requesting is quite helpful.
-Boris
[1] - https://insouciant.org/tech/spdy-prioritization-case-study-gmail/
[2] - https://plus.google.com/+ShubhiePanicker/posts/Uw87yxQFCfY
[whatwg] Fetch Objects and scripts/stylesheets
I was walking with Will about how the browser prioritizes the loading of
scripts and stylesheets. An idea that came up in our conversation was
allowing the user to directly access Fetch objects associated with scripts
and stylesheets. Some examples of how I could see this working:
(1) Allowing the user to specify parameters to Fetch. For example, a user
could say:
script src=/my.js params={'headers':{'myheader':'value'}}
id=myscript /
This would allow the user to make any type of request customization that
they could for a direct call to Fetch.
(2) Allowing the user to access the in progress fetch object. For example,
a user could say:
$(myscript).fetch.then(function(resp) { console.log(resp.status); })
Over time, the fetch object might add new functionality that would be
useful to the application developer. For example, I could imagine the fetch
object gaining a way to change HTTP/2 priorities mid-request. Developers
could take advantage of these functions for browser-initiated fetches.
(3) Allowing the user to construct a script or stylesheet from a fetch.
Complex sites often want precise control over when scripts and stylesheets
are loaded and inserted into the DOM. For example, today inserting a
stylesheet blocks the execution of inline script tags. Some sites may know
that this dependency is not needed. If one could construct stylesheets and
scripts directly from a fetch, the author could separate the act of
fetching the stylesheet from inserting into the DOM:
var myfetch = window.fetch(...);
myfetch.then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
By calling asStyleSheet, the user could preserve the devtools experience
that exists today while still having complete control over the fetching of
their content.
(4) Giving the user explicit access to initiate fetches from the preload
scanner. One downside of the approach in (3) is that it doesn't take
advantage of the preload scanner to initiate fetches. I could imagine
offering the user an explicit way to trigger a Fetch from the preload
scanner:
link id=foo rel=fetch href=/my.css /
$('foo').then(function(resp) {
document.body.appendChild(resp.body.asStyleSheet());
});
What do you guys think about allowing this type of access to the Fetch
object for script and stylesheet loads?
- Ben
