Re: ISSUE-1: Mandatory algorithms (was Re: ISSUE-3: Algorithm discovery)

On Tue, Jul 10, 2012 at 12:51 PM, Seetharama Rao Durbha
<S.Durbha@cablelabs.com> wrote:
> I was not arguing against defining the exceptions. It is definitely a
> required feature, we need to define them. I agree that algorithm discovery
> is needed.
>
> I was just commenting on the reference to ISSUE-1 - mandatory list (sorry
> for the confusion).
>
> So, with respect to ISSUE-1…
>
>>>When there (and there eventually will) exist two different sets of
>>> MUST-IMPLEMENT, how will the web application behave then? When SHA-1 is
>>> broken, or SHA-3 is the new MUST-IMPLEMENT, how will that be addressed?
>
> I am not sure how there can be two (or more) MUST-IMPLEMENT sets. The whole
> point of a standard is avoiding confusion.
> On the second sentence, "when SHA-1 is broken…", I would like to see it
> 'deprecated', rather than 'removed' from MUST-IMPLEMENT, for a period of
> time. In my work, I see that there are hard reasons why people need 'legacy'
> support. When people do decide they are ready to migrate to SHA-N, catching
> the exception makes sense – because, they would have put in place a
> migration strategy for moving from SHA-1 to SHA-N, and that strategy is what
> goes into the catch block. I do not see a reason for any catch block logic
> from day 1. If we do not provide mandatory algorithms, what do we expect
> people to put in the catch block?

Every time we modify the standard, there will be N versions of the
standard, because there will be user agents that implement version 1,
version 2, version 3, etc. Web applications that wish to work with
these user agents must be prepared for each user agent having a
different view of what "MUST-IMPLEMENT" means, which is why I don't
think there's any particular added value in MUST-IMPLEMENT.

Just like web applications today cannot assume that all user agents
accessing their site support CSS4 selectors, web applications will
have to be prepared for user agents that may (no longer / not yet)
support the desired algorithm.

And while I agree that it would be nice for a period of "deprecation",
I would rather not have the matter of determining when to go from
"deprecated" to "removed" be decided by committee. Different browser
vendors have different views on security, and they have different
value-tradeoffs: Some U-As may be focused on a particular market
segment where no old feature can be removed, while other U-As may be
focused on market segments where security is the most important
aspect.

Having the standard dictate MUST-IMPLEMENT means that U-As will lose
the flexibility to make independent security choices while still being
a compliant implementation. For example, a U-A may decide to go from
implemented -> disabled by default, and require a user to explicitly
enable it before it's available. Under a MUST-IMPLEMENT scenario, this
would be non-compliant behaviour.

Aside from theory, I think as an implementor, if we had security
concerns with an algorithm that we believed put our users at risk,
then regardless of the any MUST-IMPLEMENT language in the spec, we'd
move to disable it to protect our users. And I suspect other browsers
would do the same. So that's why I think any MUST-IMPLEMENT language
is non-binding.

"Recommended" algorithms are both fine and a good thing, and I don't
think there will be much of any debate about adding new algorithms to
recommended - but must-implement feels like a reach.

Cheers,
Ryan

>
>
>
> On 7/10/12 11:43 AM, "Ryan Sleevi" <sleevi@google.com> wrote:
>
>
>
> On Tue, Jul 10, 2012 at 10:22 AM, Seetharama Rao Durbha
> <S.Durbha@cablelabs.com> wrote:
>>
>> On 7/9/12 7:26 PM, "Ryan Sleevi" <sleevi@google.com> wrote:
>>
>> >>Note that none of the above semantics would necessarily be altered by a
>> >> MUST-IMPLEMENT registry (ISSUE-1), since there would still
>> >>need to be some form of error handling for invalid constants/strings and
>> >> for unsupported key+algorithm+operation tuples.
>>
>> The difference is whether the developer needs to 'explicitly' catch
>> UnsupportedAlgorithmException and 'do something about it', or 'just not
>> bother', as the algorithm they picked is guaranteed to be available.
>>
>> Errors caused by invalid constants/strings must be caught at development
>> time.
>>
>>
>
> I do not believe this is a reasonable approach, nor does it seem to be
> encouraged by the recommendations for W3C standard web APIs. [1] [2] [3].
>
> My comment was reflecting a the need to have the error handling state
> machine fully defined in the spec. Failing to specify what happens when an
> invalid constant/string is provided means the API is incomplete, and
> developers have no way of knowing what will happen. Will the U-A just crash?
> Will the API ever call the onerror callback? If not, what happens if the
> user keeps calling processData() and supplying more data? Will it cause a
> syntax error that causes all JavaScript to fail executing on the page?
>
> When there (and there eventually will) exist two different sets of
> MUST-IMPLEMENT, how will the web application behave then? When SHA-1 is
> broken, or SHA-3 is the new MUST-IMPLEMENT, how will that be addressed?
>
> If we update the specification, and say "SHA-1 is no longer MUST-IMPLEMENT
> because it was broken", what does that mean for web applications that were
> using SHA-1? What will their execution environments be like? Will it break
> all script on that page?
>
> For interop testing and for reference implementations, I do not believe we
> will be able to escape the need to specify error handling. Which is why I
> believe that these concerns remain wholly independent of the discussion of
> MUST-IMPLEMENT question. Because we MUST have error handling, we implicitly
> have discovery. The only question is whether we want to use error handling
> as the /only/ form of discovery.
>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0058.html
> [2]
> http://scriptlib-cg.github.com/api-design-cookbook/#don-t-use-numerical-constants
> [3]
> http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis#privacy-enhancing-api-patterns
>

Received on Tuesday, 10 July 2012 20:05:21 UTC