Re: [Feature Proposal] New attributes "library" and "version" on script tags

Well, I see no problem with it, either!
I believe that if a page did that(lied about the library) they would
identify the problem when they are still developing the page, once it would
break!

Also, it would not require a hash for the file(specially because it would
most likely not match, once one file would have BOM and other might not,
one could be indented with tabs instead of spaces, or not indented at all,
some files are delivered with a timestamp commented on their top, etc...)
This is where the URI(i, standing for identifier) are put to work...the uri
on a CDN is supposed to unique, as the library stored on the browser!



On Sat, Aug 10, 2013 at 12:49 AM, Chris <chris@cbojar.net> wrote:

> On 08/09/2013 11:32 PM, Boris Zbarsky wrote:
>
>> On 8/9/13 11:12 PM, François REMY wrote:
>>
>>> This is an interesting concept but something else to consider: what is
>>>> to prevent someone from from "lying" about which script they are
>>>> referencing?
>>>>
>>>> e.g. <script library="jQuery" version="1.0"
>>>> src="/somethingNotjQuery.js<ht**tp://codeorigin.jquery.com/**
>>>> jquery-1.10.2.min.js<http://codeorigin.jquery.com/jquery-1.10.2.min.js>
>>>> >"></**script>
>>>>
>>>
>>> You can't. This is why this won't happen, at least not like that.
>>>
>>> The only option for this would be to provides a cryptographically strong
>>> hash of the file as the version, but this prevents minor fixes (ie using
>>> 1.1 instead of 1.0 where the release only fix bugs).
>>>
>>> The other option is to have a server you trust and which can download
>>> the best files for you. A kind of local CDN+cache, in some way.
>>>
>>
>> I feel like I'm missing something...
>>
>> The proposal was specifically that the browser should provide a built-in
>> jQuery 1.0 in this situation, right?
>>
>> So if the src points to some other script, there are three possibilities:
>>
>> 1)  The page expects the other script and will break in a browser that
>> implements this proposal.
>>
>> 2)  The page expects jQuery 1.0 and will break in a browser that does not
>> implement this proposal.
>>
>> 3)  The page doesn't care what's loaded here at all.
>>
>> Ignoring #3 for the moment, "lying" will just mean the page ends up
>> broken.  The main impact of this is how willing UAs are to give pages this
>> footgun, I guess, but it doesn't seem like a fatal problem to me offhand.
>>
>> Note that if the proposal were to download from one page but share across
>> others, _then_ lying like this would have cache-poisoning issues.  But if
>> the proposal is to just have browsers use built-in versions of libraries
>> it's not obvious to me that there is a problem from the lying aspect.
>>
>> -Boris
>>
>>
> I was going to say exactly that, but Boris beat me to it. :) If anything,
> this can provide a (albeit small) level of additional security against,
> say, the compromise of a large public CDN such as Google's Hosted
> Libraries, since it would use the trusted version shipped by the browser
> rather than a possibly compromised version. Using something like the lying
> example given, one might be able to determine the type or version of a
> browser, but there are surely much easier ways to go about that.
>
> Boris is also quite right to note that this should not be used as a cache
> population mechanism, since it would make it almost trivial to poison that
> cache.
>
> -Chris.
>
>


-- 
*Felipe N. Moura*
Senior Web Developer

Website:  http://felipenmoura.org
 Twitter:    @felipenmoura <http://twitter.com/felipenmoura>
LinkedIn: http://goo.gl/qGmq

Meet some of my projects:
BrazilJS Conference <http://braziljs.com.br/>  |  BrazilJS
Foundation<http://braziljs.org>
|  Power Polygon <http://github.com/braziljs/power-polygon>  |
TheWebMind<http://thewebmind.org/>  |
PHPDevBar<https://addons.mozilla.org/pt-BR/firefox/addon/php-developer-toolbar/>
---------------------------------
LinuxUser #508332
*Changing  the  world*  is the least I expect from  myself!