web+ and registerProtocolHandler

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

web+ and registerProtocolHandler

masinter
since this affects ietf and w3c, and public-ietf-w3c is publicly archived, could someone explain why allowing registering arbitrary web+xxx scheme handlers is any better than allowing arbitrary (unblacklisted) xxx scheme handlers?


-----Original message-----
From: Adam Barth <[hidden email]>
To:
Larry Masinter <[hidden email]>
Cc:
"[hidden email]" <[hidden email]>, Tony Hansen <[hidden email]>, Philippe Le Hegaret <[hidden email]>, Peter Saint-Andre <[hidden email]>, Adil Allawi <[hidden email]>, Robin Berjon <[hidden email]>, Ted Hardie <[hidden email]>, John O'Conner <[hidden email]>, Pete Resnick <[hidden email]>, "Martin J. Dürst" <[hidden email]>, Chris Weber <[hidden email]>
Sent:
Sun, Sep 9, 2012 19:09:22 GMT+00:00
Subject:
RE: 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER

We should discuss further on a publicly archived mailing list.

Adam

On Sep 9, 2012 12:00 PM, "Larry Masinter" <[hidden email]> wrote:
Why doesn't "web+"  introduce all the same problems a blacklist approach (where everything is allowed unless explicitly disallowed) introduces?
That's kind of what Chris' tests are showing.

And what's the point, anyway, of a precise specification but leaving out the necessary steps to implement the spec securely?



-----Original Message-----
From: Adam Barth [mailto:[hidden email]]
Sent: Sunday, September 09, 2012 10:20 AM
To: Chris Weber
Cc: Larry Masinter; "Martin J. Dürst"; Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete Resnick; Robin Berjon
Subject: Re: 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER

Folks can be unhappy with a whitelist all they want.  A blacklist
isn't secure and we won't implement it.

Adam


On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber <[hidden email]> wrote:
> Thanks for the message Martin and Larry.  I will not be in Atlanta
> unfortunately,  I'm guessing Peter will..?  I'd be happy to schedule
> some design meeting time for next week after the expiring drafts have
> been re-submitted.
>
> As far as web+xxx, I'm still afraid that a user fingerprinting and
> tracking risk exists - though I didn't test the
> isProtocolHandlerRegistered() method for exploitability because it
> didn't exist, I see Safari has implemented it now and Chrome and Firefox
> have some active bugs for tracking.
>
> Also, I notice that some developers are not happy with the whitelist vs
> blacklist approach: https://github.com/jquery/standards/issues/12
>
> -Chris
>
> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in Lyon)
>>
>> I'd like to better coordinate the IETF and W3C specs on URLs, IRIs, etc. Doing so was my original motivation for revising these specs in the first place.
>> I'd like to also see if we can make progress on "web+xxx" and (if it's still in W3C specs) "http+aes".
>>
>> I see Chris is doing testing. Making progress on open issues was stymied by lack of testing, so perhaps now that we have some testing capabilities we can make more rapid progress.
>>
>> Larry
>>
>>
>> -----Original Message-----
>> From: "Martin J. Dürst" [mailto:[hidden email]]
>> Sent: Friday, September 07, 2012 8:10 PM
>> To: Peter Saint-Andre; Chris Weber
>> Cc: Larry Masinter; Tony Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete Resnick
>> Subject: Fwd: 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER
>>
>> Dear IRI WG chairs,   (cc. to editors and AD)
>>
>> I'm sorry I haven't been able to get to this earlier (vacations and
>> following catch-up). We have to decide whether to request a meeting slot
>> at the upcomming 85th IETF or not.
>>
>> Like most of the previous IETFs, I will not be able to attend this one.
>> Who among you will be there? (my guesses are Pete 99%, Ted 98%, but then
>> quickly downwards from there).
>>
>> If it looks like we have enough participants who plan to attend (which
>> would include AT LEAST one chair), I'll do my best to participate
>> remotely. If many or most of you don't plan to attend, then it makes
>> more sense to not schedule a meeting.
>>
>> I have co-chaired an IETF WG (LTRU) that never met, so I know it's
>> possible to do work even without actual meetings.
>>
>> Regards,   Martin.
>>
>> P.S.: Of our four drafts, two (Guidelines and Registration Procedures,
>> Comparison and Canonicalization) are currently expired and one (Bidi) is
>> close to expiring. I'll resubmit Bidi and Comparison and
>> Canonicalization this weekend, and I hope that Tony, Ted, and Larry can
>> take care of Guidelines and Registration Procedures soon.
>>
>> P.P.S: I'm also looking forward to schedule some design team meetings
>> (or whatever we call them) to move things along.
>>
>> P.P.P.S: One of my students, Shunsuke Oshima, is working on an analysis
>> of bidi interactions between "separators" and "content characters" in an
>> extension of the analysis that Harald Alvestrand did for IDNA. He is
>> making steady progress, and I hope we can sooner or later use his
>> results for the Bidi document.
>>
>>
>>
>> -------- Original Message --------
>> Subject: 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER
>> Date: Fri, 07 Sep 2012 12:40:50 -0700
>> From: IETF Agenda <[hidden email]>
>> To: Working Group Chairs <[hidden email]>
>> CC: [hidden email]
>>
>> -----------------------------------------------------------------
>> 85th IETF - Atlanta, GA, USA
>> Meeting Dates: November 4-9, 2012
>> Host: North American Cable Industry
>> -----------------------------------------------------------------
>> IETF meetings start Monday morning and run through Friday afternoon (13:30).
>>
>> We are accepting scheduling requests for all Working Groups and BOFs
>> starting today.  The milestones and deadlines for scheduling-related
>> activities are as follows:
>>
>> NOTE: cutoff dates are subject to change.
>>
>> - 2012-09-10 (Monday): Cutoff date for requests to schedule Working
>> Group meetings at UTC 24:00. To request a Working Group session, use the
>> IETF Meeting Session Request Tool.
>> - 2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area
>> Directors at UTC 24:00. To request a BOF, please see instructions on
>> Requesting a BOF.
>> - 2012-09-27 (Thursday): Cutoff date for Area Directors to approve BOFs
>> at UTC 24:00.
>> - 2012-10-04 (Thursday): Preliminary agenda published for comment.
>> - 2012-10-08 (Monday): Cutoff date for requests to reschedule Working
>> Group and BOF meetings UTC 24:00.
>> - 2012-10-08 (Monday): Working Group Chair approval for initial document
>> (Version -00) submissions appreciated by UTC 24:00.
>> - 2012-10-12 (Friday): Final agenda to be published.
>> - 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00,
>> upload using IETF Meeting Materials Management Tool.
>> - 2012-10-29 (Monday): Revised Working Group agendas due by UTC 24:00,
>> upload using IETF Meeting Materials Management Tool.
>> - 2012-12-07 (Friday): Proceedings submission cutoff date by UTC 24:00,
>> upload using IETF Meeting Materials Management Tool.
>> - 2012-12-26 (Wednesday): Proceedings submission corrections cutoff date
>> by UTC 24:00, upload using IETF Meeting Materials Management Tool.
>>
>> Submitting Requests for Working Group and BOF Sessions
>>
>> Please submit requests to schedule your Working Group sessions using the
>> "IETF Meeting Session Request Tool," a Web-based tool for submitting all
>> of the information that the Secretariat requires to schedule your sessions.
>>
>> The URL for the tool is:
>>
>> https://pub.ietf.org/sreq/
>>
>> Please send requests to schedule your BOF sessions to [hidden email].
>> Please include the acronym of your BOF in the subject line of the
>> message, and include all of the information specified in item (4) of
>> "Requesting Meeting Sessions at IETF Meetings" in the body.  (This
>> document is included below.)
>>
>> Submitting Session Agendas
>>
>> For the convenience of meeting attendees, we ask that you submit the
>> agendas for your Working Group sessions as early as possible.  Draft
>> Working Group agendas are due Wednesday, October 24, 2012 at UTC 24:00.
>>   Revised Working Group agendas are due no later than Monday, October
>> 29, 2012 at UTC 24:00.  The proposed agenda for a BOF session should be
>> submitted along with your request for a session.  Please be sure to copy
>> your Area Director on that message.
>>
>> Please submit the agendas for your Working Group sessions using the
>> "IETF Meeting Materials Management Tool," a Web-based tool for making
>> your meeting agenda, minutes, and presentation slides available to the
>> community before, during, and after an IETF meeting.  If you are a BOF
>> chair, then you may use the tool to submit a revised agenda as well as
>> other materials for your BOF once the BOF has been approved.
>>
>> The URL for the tool is:
>>
>> https://pub.ietf.org/proceedings/
>>
>> Additional information about this tool is available at:
>>
>> http://www.ietf.org/instructions/meeting_materials_tool.html
>>
>> Agendas submitted via the tool will be available to the public on the
>> "IETF Meeting Materials" Web page as soon as they are submitted.
>>
>> The URL for the "IETF 85 Meeting Materials" Web page is:
>>
>> https://datatracker.ietf.org/meeting/85/materials.html
>>
>> If you are a Working Group chair, then you already have accounts on the
>> "IETF Meeting Session Request Tool" and the "IETF Meeting Materials
>> Management Tool."  The same User ID and password will work for both
>> tools.  If you are a BOF chair who is not also a Working Group chair,
>> then you will be given an account on the "IETF Meeting Materials
>> Management Tool" when your BOF has been approved.  If you require
>> assistance in using either tool, or wish to report a bug, then please
>> send a message to:
>> [hidden email].
>> ================================================
>> For your convenience, comprehensive information on requesting meeting
>> sessions at IETF 85 is presented below:
>>
>> 1. Requests to schedule Working Group sessions should be submitted using
>> the "IETF Meeting Session Request Tool," a Web-based tool for submitting
>> all of the information required by the Secretariat to schedule your
>> sessions.  The URL for the tool is:
>>
>> https://pub.ietf.org/sreq/
>>
>> Instructions for using the tool are available at:
>>
>> http://www.ietf.org/instructions/session_request_tool_instruction.html
>>
>> If you require an account on this tool, or assistance in using it, then
>> please send a message to [hidden email].  If you are unable to use
>> the tool, then you may send your request via e-mail to [hidden email],
>> with a copy to the appropriate Area Director(s).
>>
>> Requests to schedule BOF sessions must be sent to [hidden email] with a
>> copy to the appropriate Area Director(s).
>>
>> When submitting a Working Group or BOF session request by e-mail, please
>> include the Working Group or BOF acronym in the Subject line.
>>
>> 2. BOFs will NOT be scheduled unless the Area Director(s) approved the
>> BOF. The proponents behind a BOF need to contact a relevant Area
>> Director, preferably well in advance of the BOF approval deadline date.
>> The AD needs to have the full name of the BOF, its acronym, suggested
>> names of chairs, an agenda, full description of the BOF and the
>> information covered in item 4. Please read RFC 5434 for instructions on
>> how to drive a successful BOF effort. The approval depends on, for
>> instance, Internet-Drafts and list discussion on the suggested topic.
>> BOF agenda requests, if approved, will be submitted to the IETF
>> Secretariat by the ADs.
>>
>> 3. A Working Group may request either one or two sessions.  If your
>> Working Group requires more than two sessions, then your request must be
>> approved by an Area Director.  Additional sessions will be assigned,
>> based on availability, after Monday, July 2, 2012 at 17:00 PT, the
>> cut-off date for requests to reschedule a session.
>>
>> 4. You MUST provide the following information before a Working Group or
>> BOF session will be scheduled:
>>
>>     a. Working Group or BOF full name with acronym in brackets:
>>
>>     b. AREA under which Working Group or BOF appears:
>>
>>     c. CONFLICTS you wish to avoid, please be as specific as possible:
>>
>>     d. Expected Attendance:
>>
>>     e. Special requests:
>>
>>     f. Number of sessions:
>>
>>     g. Length of session:
>>        - 1 hour
>>        - 1 1/2 hours
>>        - 2 hours
>>        - 2 1/2 hours
>>
>> For more information on scheduling Working Group and BOF sessions,
>> please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and
>> Procedures" (http://www.ietf.org/rfc/rfc2418.txt).
>> ================================================
>> For your convenience please find here a list of the IETF Area Directors
>> with their e-mail addresses:
>>
>> IETF Chair
>> Russ Housley <[hidden email]>
>>
>> Applications Area (app)
>> Barry Leiba <[hidden email]>
>> Pete Resnick <[hidden email]>
>>
>> Internet Area (int)
>> Ralph Droms <[hidden email]>
>> Brian Haberman <[hidden email]>
>>
>> Operations & Management Area (ops)
>> Ronald Bonica <[hidden email]>
>> Benoit Claise <[hidden email]>
>>
>> Real-time Applications and Infrastructure Area (rai)
>> Gonzalo Camarillo <[hidden email]>
>> Robert Sparks <[hidden email]>
>>
>> Routing Area (rtg)
>> Stewart Bryant <[hidden email]>
>> Adrian Farrel <[hidden email]>
>>
>> Security Area (sec)
>> Stephen Farrell <[hidden email]>
>> Sean Turner <[hidden email]>
>>
>> Transport Area (tsv)
>> Wesley Eddy <[hidden email]>
>> Martin Stiemerling <[hidden email]>
>> ================================================
>> 84th IETF Meeting Attendance Number:
>>
>> Working Group - (Actual Attendance) - Number Requested
>> 6man - (130) - 150
>> 6renum - (60) - 75
>> abfab - (35) - 40
>> alto - (77)    - 100
>> apparea - (175) - 100
>> appsawg - (175) - 100
>> atoca - (18) - 25
>> avtcore - (74) - 100
>> avtcore 2nd session - (21) - 100
>> avtext - (37) - 100
>> behave - (53) - 80
>> bfcpbis - (20) - 40
>> bfd - (30) - 75
>> bmwg - (13) - 25
>> ccamp - (71) - 150
>> ccamp 2nd session - (62) - 150
>> cdni - (108) - 120
>> cdni 2nd session - (69) - 120
>> clue - (76) - 100
>> clue 2nd session - (49) - 100
>> conex - (47) - 100
>> core - (60) - 120
>> core 2nd session - (52) - 120
>> dane - (125) - 100
>> dhc - (76) - 75
>> dime - (25) - 30
>> dispatch - (54) - 125
>> dmm - (66) - 70
>> dnsop - (118) - 100
>> dsii BoF - (72) - 100
>> eai - (22) - 50
>> ecrit - (37) - 60
>> eman - (27) - 80
>> emu - (23) - 60
>> forces - (41)
>> geopriv - (34) - 50
>> grow - (49) - 90
>> homenet - (216) - 250
>> httpbis - (96) - 70
>> httpbis 2nd session - (92) - 70
>> hybi - (38) - 100
>> iccrg RG - (79) - 50
>> icnrg RG - (119) - 60
>> idr - (97) - 110
>> insipid - (36) - 40
>> intarea - (88) - 150
>> ipfix - (34) - 50
>> ipsecme - (36) - 50
>> IRTF Open Meeting - (195) - 200
>> jose - (46) - 90
>> karp - (52) - 100
>> l2vpn - (114) - 125
>> l3vpn - (102) - 100
>> l3vpn 2nd session - (41) - 100
>> lisp - (68) - 75
>> lwig - (56) - 80
>> manet - (41) - 50
>> mboned - (38) - 50
>> mif - (64) - 80
>> mile - (27) - 45
>> mmusic - (69) - 100
>> mpls - (186) - 200
>> mpls 2nd session - (80) - 200
>> mptcp - (39) - 70
>> multimob - (26) - 50
>> netconf - (49) - 40
>> netext - (43) - 70
>> netmod - (31) - 50
>> nfsv4 - (22) - 25
>> ntp - (40) - 40
>> nvo3 BoF - (244) - 150
>> oauth - (72) - 50
>> opsarea - (78) - 100
>> opsawg - (78) - 100
>> opsec - (64) - 100
>> ospf - (42) - 80
>> p2psip - (27) - 60
>> paws - (32) - 35
>> pce - (51) - 80
>> pcp - (71) - 75
>> pcp 2nd session - (36) - 75
>> pim - (30) - 50
>> pkix - (43) - 50
>> ppsp - (18) - 50
>> precis - (27) - 35
>> pwe3 - (85) - 120
>> radext - (21) - 25
>> rfcform BoF - (99) - 100
>> rmcat BoF - (123) - 100
>> rmt - (10) - 30
>> rtcweb - (165) - 150
>> rtcweb 2nd session - (141) - 150
>> rtgarea - (169) - 120
>> rtgwg - (80) - 100
>> saag - (120) - 125
>> sdnrg - (203) - 100
>> sidr - (64) - 120
>> sipcore - (49) - 70
>> siprec - (26) - 40
>> soc - (40) - 50
>> softwire - (67) - 100
>> straw - (43) - 60
>> sunset4 - (147) - 200
>> tcpm - (47) - 60
>> tictoc - (19) - 40
>> tls - (59) - 50
>> trill - (42) - 85
>> trill 2nd session - (37) - 85
>> tsvarea - (138) - 200
>> tsvwg - (38) - 75
>> v6ops - (146) - 300
>> v6ops 2nd session - (130) - 300
>> websec - (85) - 110
>> weirds BoF - (62) - 100
>> xmpp - (29) - 40
>> xrblock - (19) - 40
>>
Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Julian Reschke
On 2012-09-10 10:01, Larry Masinter wrote:
> since this affects ietf and w3c, and public-ietf-w3c is publicly
> archived, could someone explain why allowing registering arbitrary
> web+xxx scheme handlers is any better than allowing arbitrary
> (unblacklisted) xxx scheme handlers?
> ...

I think the idea is that when the next "http" comes around, web sites
will not be able to change the system default for it.

That being said, registering a system-wide URI handler needs admin
privileges anyway, right? (at least on Windows).

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Sam Ruby-2
In reply to this post by masinter
On 09/10/2012 04:01 AM, Larry Masinter wrote:
> since this affects ietf and w3c, and public-ietf-w3c is publicly
> archived, could someone explain why allowing registering arbitrary
> web+xxx scheme handlers is any better than allowing arbitrary
> (unblacklisted) xxx scheme handlers?

The following (publicly archived) email may provide useful context:

   http://lists.w3.org/Archives/Public/public-html/2012Aug/0115.html

I particularly encourage people to look at the "Revisiting this Issue"
section at the bottom of that email.

- Sam Ruby

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Julian Reschke
On 2012-09-10 14:48, Sam Ruby wrote:

> On 09/10/2012 04:01 AM, Larry Masinter wrote:
>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>> archived, could someone explain why allowing registering arbitrary
>> web+xxx scheme handlers is any better than allowing arbitrary
>> (unblacklisted) xxx scheme handlers?
>
> The following (publicly archived) email may provide useful context:
>
>    http://lists.w3.org/Archives/Public/public-html/2012Aug/0115.html
>
> I particularly encourage people to look at the "Revisiting this Issue"
> section at the bottom of that email.

I have already stated that I think that decision was flawed (in that
Maciej didn't get the "doesn't scale" argument, but then also didn't
ask), but I don't want to re-open it until *this* thread (started by
Philippe after all) has come to a conclusion.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Adam Barth-5
In reply to this post by masinter
It's just a practical issue.  Many folks have URI schemes registered
on their computers that are not safe for web sites to hijack (i.e.,
register).  It's not practical to create an blacklist that effectively
mitigates that risk.  As it happens, we not aware of any folks who
have such registrations for URI schemes that begin with "web+".

Adam


On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter <[hidden email]> wrote:

> since this affects ietf and w3c, and public-ietf-w3c is publicly archived,
> could someone explain why allowing registering arbitrary web+xxx scheme
> handlers is any better than allowing arbitrary (unblacklisted) xxx scheme
> handlers?
>
>
> -----Original message-----
>
> From: Adam Barth <[hidden email]>
> To: Larry Masinter <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>, Tony Hansen <[hidden email]>,
> Philippe Le Hegaret <[hidden email]>, Peter Saint-Andre <[hidden email]>,
> Adil Allawi <[hidden email]>, Robin Berjon <[hidden email]>, Ted Hardie
> <[hidden email]>, John O'Conner <[hidden email]>, Pete Resnick
> <[hidden email]>, "Martin J. Dürst" <[hidden email]>, Chris
> Weber <[hidden email]>
> Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER
>
> We should discuss further on a publicly archived mailing list.
>
> Adam
>
> On Sep 9, 2012 12:00 PM, "Larry Masinter" <[hidden email]> wrote:
>>
>> Why doesn't "web+"  introduce all the same problems a blacklist approach
>> (where everything is allowed unless explicitly disallowed) introduces?
>> That's kind of what Chris' tests are showing.
>>
>> And what's the point, anyway, of a precise specification but leaving out
>> the necessary steps to implement the spec securely?
>>
>>
>>
>> -----Original Message-----
>> From: Adam Barth [mailto:[hidden email]]
>> Sent: Sunday, September 09, 2012 10:20 AM
>> To: Chris Weber
>> Cc: Larry Masinter; "Martin J. Dürst"; Peter Saint-Andre; Philippe Le
>> Hegaret; John O'Conner; Tony Hansen; Ted Hardie; [hidden email]; Adil
>> Allawi; Pete Resnick; Robin Berjon
>> Subject: Re: 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER
>>
>> Folks can be unhappy with a whitelist all they want.  A blacklist
>> isn't secure and we won't implement it.
>>
>> Adam
>>
>>
>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber <[hidden email]> wrote:
>> > Thanks for the message Martin and Larry.  I will not be in Atlanta
>> > unfortunately,  I'm guessing Peter will..?  I'd be happy to schedule
>> > some design meeting time for next week after the expiring drafts have
>> > been re-submitted.
>> >
>> > As far as web+xxx, I'm still afraid that a user fingerprinting and
>> > tracking risk exists - though I didn't test the
>> > isProtocolHandlerRegistered() method for exploitability because it
>> > didn't exist, I see Safari has implemented it now and Chrome and Firefox
>> > have some active bugs for tracking.
>> >
>> > Also, I notice that some developers are not happy with the whitelist vs
>> > blacklist approach: https://github.com/jquery/standards/issues/12
>> >
>> > -Chris
>> >
>> > On 9/8/2012 9:32 AM, Larry Masinter wrote:
>> >> I'm planning to go to IETF Atlanta (direct from W3C TPAC in Lyon)
>> >>
>> >> I'd like to better coordinate the IETF and W3C specs on URLs, IRIs,
>> >> etc. Doing so was my original motivation for revising these specs in the
>> >> first place.
>> >> I'd like to also see if we can make progress on "web+xxx" and (if it's
>> >> still in W3C specs) "http+aes".
>> >>
>> >> I see Chris is doing testing. Making progress on open issues was
>> >> stymied by lack of testing, so perhaps now that we have some testing
>> >> capabilities we can make more rapid progress.
>> >>
>> >> Larry
>> >>
>> >>
>> >> -----Original Message-----
>> >> From: "Martin J. Dürst" [mailto:[hidden email]]
>> >> Sent: Friday, September 07, 2012 8:10 PM
>> >> To: Peter Saint-Andre; Chris Weber
>> >> Cc: Larry Masinter; Tony Hansen; Ted Hardie; [hidden email]; Adil
>> >> Allawi; Pete Resnick
>> >> Subject: Fwd: 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER
>> >>
>> >> Dear IRI WG chairs,   (cc. to editors and AD)
>> >>
>> >> I'm sorry I haven't been able to get to this earlier (vacations and
>> >> following catch-up). We have to decide whether to request a meeting
>> >> slot
>> >> at the upcomming 85th IETF or not.
>> >>
>> >> Like most of the previous IETFs, I will not be able to attend this one.
>> >> Who among you will be there? (my guesses are Pete 99%, Ted 98%, but
>> >> then
>> >> quickly downwards from there).
>> >>
>> >> If it looks like we have enough participants who plan to attend (which
>> >> would include AT LEAST one chair), I'll do my best to participate
>> >> remotely. If many or most of you don't plan to attend, then it makes
>> >> more sense to not schedule a meeting.
>> >>
>> >> I have co-chaired an IETF WG (LTRU) that never met, so I know it's
>> >> possible to do work even without actual meetings.
>> >>
>> >> Regards,   Martin.
>> >>
>> >> P.S.: Of our four drafts, two (Guidelines and Registration Procedures,
>> >> Comparison and Canonicalization) are currently expired and one (Bidi)
>> >> is
>> >> close to expiring. I'll resubmit Bidi and Comparison and
>> >> Canonicalization this weekend, and I hope that Tony, Ted, and Larry can
>> >> take care of Guidelines and Registration Procedures soon.
>> >>
>> >> P.P.S: I'm also looking forward to schedule some design team meetings
>> >> (or whatever we call them) to move things along.
>> >>
>> >> P.P.P.S: One of my students, Shunsuke Oshima, is working on an analysis
>> >> of bidi interactions between "separators" and "content characters" in
>> >> an
>> >> extension of the analysis that Harald Alvestrand did for IDNA. He is
>> >> making steady progress, and I hope we can sooner or later use his
>> >> results for the Bidi document.
>> >>
>> >>
>> >>
>> >> -------- Original Message --------
>> >> Subject: 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER
>> >> Date: Fri, 07 Sep 2012 12:40:50 -0700
>> >> From: IETF Agenda <[hidden email]>
>> >> To: Working Group Chairs <[hidden email]>
>> >> CC: [hidden email]
>> >>
>> >> -----------------------------------------------------------------
>> >> 85th IETF - Atlanta, GA, USA
>> >> Meeting Dates: November 4-9, 2012
>> >> Host: North American Cable Industry
>> >> -----------------------------------------------------------------
>> >> IETF meetings start Monday morning and run through Friday afternoon
>> >> (13:30).
>> >>
>> >> We are accepting scheduling requests for all Working Groups and BOFs
>> >> starting today.  The milestones and deadlines for scheduling-related
>> >> activities are as follows:
>> >>
>> >> NOTE: cutoff dates are subject to change.
>> >>
>> >> - 2012-09-10 (Monday): Cutoff date for requests to schedule Working
>> >> Group meetings at UTC 24:00. To request a Working Group session, use
>> >> the
>> >> IETF Meeting Session Request Tool.
>> >> - 2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area
>> >> Directors at UTC 24:00. To request a BOF, please see instructions on
>> >> Requesting a BOF.
>> >> - 2012-09-27 (Thursday): Cutoff date for Area Directors to approve BOFs
>> >> at UTC 24:00.
>> >> - 2012-10-04 (Thursday): Preliminary agenda published for comment.
>> >> - 2012-10-08 (Monday): Cutoff date for requests to reschedule Working
>> >> Group and BOF meetings UTC 24:00.
>> >> - 2012-10-08 (Monday): Working Group Chair approval for initial
>> >> document
>> >> (Version -00) submissions appreciated by UTC 24:00.
>> >> - 2012-10-12 (Friday): Final agenda to be published.
>> >> - 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00,
>> >> upload using IETF Meeting Materials Management Tool.
>> >> - 2012-10-29 (Monday): Revised Working Group agendas due by UTC 24:00,
>> >> upload using IETF Meeting Materials Management Tool.
>> >> - 2012-12-07 (Friday): Proceedings submission cutoff date by UTC 24:00,
>> >> upload using IETF Meeting Materials Management Tool.
>> >> - 2012-12-26 (Wednesday): Proceedings submission corrections cutoff
>> >> date
>> >> by UTC 24:00, upload using IETF Meeting Materials Management Tool.
>> >>
>> >> Submitting Requests for Working Group and BOF Sessions
>> >>
>> >> Please submit requests to schedule your Working Group sessions using
>> >> the
>> >> "IETF Meeting Session Request Tool," a Web-based tool for submitting
>> >> all
>> >> of the information that the Secretariat requires to schedule your
>> >> sessions.
>> >>
>> >> The URL for the tool is:
>> >>
>> >> https://pub.ietf.org/sreq/
>> >>
>> >> Please send requests to schedule your BOF sessions to [hidden email].
>> >> Please include the acronym of your BOF in the subject line of the
>> >> message, and include all of the information specified in item (4) of
>> >> "Requesting Meeting Sessions at IETF Meetings" in the body.  (This
>> >> document is included below.)
>> >>
>> >> Submitting Session Agendas
>> >>
>> >> For the convenience of meeting attendees, we ask that you submit the
>> >> agendas for your Working Group sessions as early as possible.  Draft
>> >> Working Group agendas are due Wednesday, October 24, 2012 at UTC 24:00.
>> >>   Revised Working Group agendas are due no later than Monday, October
>> >> 29, 2012 at UTC 24:00.  The proposed agenda for a BOF session should be
>> >> submitted along with your request for a session.  Please be sure to
>> >> copy
>> >> your Area Director on that message.
>> >>
>> >> Please submit the agendas for your Working Group sessions using the
>> >> "IETF Meeting Materials Management Tool," a Web-based tool for making
>> >> your meeting agenda, minutes, and presentation slides available to the
>> >> community before, during, and after an IETF meeting.  If you are a BOF
>> >> chair, then you may use the tool to submit a revised agenda as well as
>> >> other materials for your BOF once the BOF has been approved.
>> >>
>> >> The URL for the tool is:
>> >>
>> >> https://pub.ietf.org/proceedings/
>> >>
>> >> Additional information about this tool is available at:
>> >>
>> >> http://www.ietf.org/instructions/meeting_materials_tool.html
>> >>
>> >> Agendas submitted via the tool will be available to the public on the
>> >> "IETF Meeting Materials" Web page as soon as they are submitted.
>> >>
>> >> The URL for the "IETF 85 Meeting Materials" Web page is:
>> >>
>> >> https://datatracker.ietf.org/meeting/85/materials.html
>> >>
>> >> If you are a Working Group chair, then you already have accounts on the
>> >> "IETF Meeting Session Request Tool" and the "IETF Meeting Materials
>> >> Management Tool."  The same User ID and password will work for both
>> >> tools.  If you are a BOF chair who is not also a Working Group chair,
>> >> then you will be given an account on the "IETF Meeting Materials
>> >> Management Tool" when your BOF has been approved.  If you require
>> >> assistance in using either tool, or wish to report a bug, then please
>> >> send a message to:
>> >> [hidden email].
>> >> ================================================
>> >> For your convenience, comprehensive information on requesting meeting
>> >> sessions at IETF 85 is presented below:
>> >>
>> >> 1. Requests to schedule Working Group sessions should be submitted
>> >> using
>> >> the "IETF Meeting Session Request Tool," a Web-based tool for
>> >> submitting
>> >> all of the information required by the Secretariat to schedule your
>> >> sessions.  The URL for the tool is:
>> >>
>> >> https://pub.ietf.org/sreq/
>> >>
>> >> Instructions for using the tool are available at:
>> >>
>> >> http://www.ietf.org/instructions/session_request_tool_instruction.html
>> >>
>> >> If you require an account on this tool, or assistance in using it, then
>> >> please send a message to [hidden email].  If you are unable to
>> >> use
>> >> the tool, then you may send your request via e-mail to [hidden email],
>> >> with a copy to the appropriate Area Director(s).
>> >>
>> >> Requests to schedule BOF sessions must be sent to [hidden email] with
>> >> a
>> >> copy to the appropriate Area Director(s).
>> >>
>> >> When submitting a Working Group or BOF session request by e-mail,
>> >> please
>> >> include the Working Group or BOF acronym in the Subject line.
>> >>
>> >> 2. BOFs will NOT be scheduled unless the Area Director(s) approved the
>> >> BOF. The proponents behind a BOF need to contact a relevant Area
>> >> Director, preferably well in advance of the BOF approval deadline date.
>> >> The AD needs to have the full name of the BOF, its acronym, suggested
>> >> names of chairs, an agenda, full description of the BOF and the
>> >> information covered in item 4. Please read RFC 5434 for instructions on
>> >> how to drive a successful BOF effort. The approval depends on, for
>> >> instance, Internet-Drafts and list discussion on the suggested topic.
>> >> BOF agenda requests, if approved, will be submitted to the IETF
>> >> Secretariat by the ADs.
>> >>
>> >> 3. A Working Group may request either one or two sessions.  If your
>> >> Working Group requires more than two sessions, then your request must
>> >> be
>> >> approved by an Area Director.  Additional sessions will be assigned,
>> >> based on availability, after Monday, July 2, 2012 at 17:00 PT, the
>> >> cut-off date for requests to reschedule a session.
>> >>
>> >> 4. You MUST provide the following information before a Working Group or
>> >> BOF session will be scheduled:
>> >>
>> >>     a. Working Group or BOF full name with acronym in brackets:
>> >>
>> >>     b. AREA under which Working Group or BOF appears:
>> >>
>> >>     c. CONFLICTS you wish to avoid, please be as specific as possible:
>> >>
>> >>     d. Expected Attendance:
>> >>
>> >>     e. Special requests:
>> >>
>> >>     f. Number of sessions:
>> >>
>> >>     g. Length of session:
>> >>        - 1 hour
>> >>        - 1 1/2 hours
>> >>        - 2 hours
>> >>        - 2 1/2 hours
>> >>
>> >> For more information on scheduling Working Group and BOF sessions,
>> >> please refer to RFC 2418 (BCP 25), "IETF Working Group Guidelines and
>> >> Procedures" (http://www.ietf.org/rfc/rfc2418.txt).
>> >> ================================================
>> >> For your convenience please find here a list of the IETF Area Directors
>> >> with their e-mail addresses:
>> >>
>> >> IETF Chair
>> >> Russ Housley <[hidden email]>
>> >>
>> >> Applications Area (app)
>> >> Barry Leiba <[hidden email]>
>> >> Pete Resnick <[hidden email]>
>> >>
>> >> Internet Area (int)
>> >> Ralph Droms <[hidden email]>
>> >> Brian Haberman <[hidden email]>
>> >>
>> >> Operations & Management Area (ops)
>> >> Ronald Bonica <[hidden email]>
>> >> Benoit Claise <[hidden email]>
>> >>
>> >> Real-time Applications and Infrastructure Area (rai)
>> >> Gonzalo Camarillo <[hidden email]>
>> >> Robert Sparks <[hidden email]>
>> >>
>> >> Routing Area (rtg)
>> >> Stewart Bryant <[hidden email]>
>> >> Adrian Farrel <[hidden email]>
>> >>
>> >> Security Area (sec)
>> >> Stephen Farrell <[hidden email]>
>> >> Sean Turner <[hidden email]>
>> >>
>> >> Transport Area (tsv)
>> >> Wesley Eddy <[hidden email]>
>> >> Martin Stiemerling <[hidden email]>
>> >> ================================================
>> >> 84th IETF Meeting Attendance Number:
>> >>
>> >> Working Group - (Actual Attendance) - Number Requested
>> >> 6man - (130) - 150
>> >> 6renum - (60) - 75
>> >> abfab - (35) - 40
>> >> alto - (77)    - 100
>> >> apparea - (175) - 100
>> >> appsawg - (175) - 100
>> >> atoca - (18) - 25
>> >> avtcore - (74) - 100
>> >> avtcore 2nd session - (21) - 100
>> >> avtext - (37) - 100
>> >> behave - (53) - 80
>> >> bfcpbis - (20) - 40
>> >> bfd - (30) - 75
>> >> bmwg - (13) - 25
>> >> ccamp - (71) - 150
>> >> ccamp 2nd session - (62) - 150
>> >> cdni - (108) - 120
>> >> cdni 2nd session - (69) - 120
>> >> clue - (76) - 100
>> >> clue 2nd session - (49) - 100
>> >> conex - (47) - 100
>> >> core - (60) - 120
>> >> core 2nd session - (52) - 120
>> >> dane - (125) - 100
>> >> dhc - (76) - 75
>> >> dime - (25) - 30
>> >> dispatch - (54) - 125
>> >> dmm - (66) - 70
>> >> dnsop - (118) - 100
>> >> dsii BoF - (72) - 100
>> >> eai - (22) - 50
>> >> ecrit - (37) - 60
>> >> eman - (27) - 80
>> >> emu - (23) - 60
>> >> forces - (41)
>> >> geopriv - (34) - 50
>> >> grow - (49) - 90
>> >> homenet - (216) - 250
>> >> httpbis - (96) - 70
>> >> httpbis 2nd session - (92) - 70
>> >> hybi - (38) - 100
>> >> iccrg RG - (79) - 50
>> >> icnrg RG - (119) - 60
>> >> idr - (97) - 110
>> >> insipid - (36) - 40
>> >> intarea - (88) - 150
>> >> ipfix - (34) - 50
>> >> ipsecme - (36) - 50
>> >> IRTF Open Meeting - (195) - 200
>> >> jose - (46) - 90
>> >> karp - (52) - 100
>> >> l2vpn - (114) - 125
>> >> l3vpn - (102) - 100
>> >> l3vpn 2nd session - (41) - 100
>> >> lisp - (68) - 75
>> >> lwig - (56) - 80
>> >> manet - (41) - 50
>> >> mboned - (38) - 50
>> >> mif - (64) - 80
>> >> mile - (27) - 45
>> >> mmusic - (69) - 100
>> >> mpls - (186) - 200
>> >> mpls 2nd session - (80) - 200
>> >> mptcp - (39) - 70
>> >> multimob - (26) - 50
>> >> netconf - (49) - 40
>> >> netext - (43) - 70
>> >> netmod - (31) - 50
>> >> nfsv4 - (22) - 25
>> >> ntp - (40) - 40
>> >> nvo3 BoF - (244) - 150
>> >> oauth - (72) - 50
>> >> opsarea - (78) - 100
>> >> opsawg - (78) - 100
>> >> opsec - (64) - 100
>> >> ospf - (42) - 80
>> >> p2psip - (27) - 60
>> >> paws - (32) - 35
>> >> pce - (51) - 80
>> >> pcp - (71) - 75
>> >> pcp 2nd session - (36) - 75
>> >> pim - (30) - 50
>> >> pkix - (43) - 50
>> >> ppsp - (18) - 50
>> >> precis - (27) - 35
>> >> pwe3 - (85) - 120
>> >> radext - (21) - 25
>> >> rfcform BoF - (99) - 100
>> >> rmcat BoF - (123) - 100
>> >> rmt - (10) - 30
>> >> rtcweb - (165) - 150
>> >> rtcweb 2nd session - (141) - 150
>> >> rtgarea - (169) - 120
>> >> rtgwg - (80) - 100
>> >> saag - (120) - 125
>> >> sdnrg - (203) - 100
>> >> sidr - (64) - 120
>> >> sipcore - (49) - 70
>> >> siprec - (26) - 40
>> >> soc - (40) - 50
>> >> softwire - (67) - 100
>> >> straw - (43) - 60
>> >> sunset4 - (147) - 200
>> >> tcpm - (47) - 60
>> >> tictoc - (19) - 40
>> >> tls - (59) - 50
>> >> trill - (42) - 85
>> >> trill 2nd session - (37) - 85
>> >> tsvarea - (138) - 200
>> >> tsvwg - (38) - 75
>> >> v6ops - (146) - 300
>> >> v6ops 2nd session - (130) - 300
>> >> websec - (85) - 110
>> >> weirds BoF - (62) - 100
>> >> xmpp - (29) - 40
>> >> xrblock - (19) - 40
>> >>

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Peter Saint-Andre-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In the context of whitelisting vs. blacklisting, the concern I have
with the prefixing idea is that it implicitly whitelists any URI
scheme that starts with the string "web+", yet the proponents of this
idea have not specified any criteria for review of such prefixed URI
schemes (or even answered the questions raised here and elsewhere
about whether additional review is needed for such schemes by the
designated experts or the IANA).

I agree that blacklisting doesn't scale and isn't secure. I disagree
that implicit whitelisting is the answer.

Peter

On 9/10/12 9:56 AM, Adam Barth wrote:

> It's just a practical issue.  Many folks have URI schemes
> registered on their computers that are not safe for web sites to
> hijack (i.e., register).  It's not practical to create an blacklist
> that effectively mitigates that risk.  As it happens, we not aware
> of any folks who have such registrations for URI schemes that begin
> with "web+".
>
> Adam
>
>
> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
> <[hidden email]> wrote:
>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>> archived, could someone explain why allowing registering
>> arbitrary web+xxx scheme handlers is any better than allowing
>> arbitrary (unblacklisted) xxx scheme handlers?
>>
>>
>> -----Original message-----
>>
>> From: Adam Barth <[hidden email]> To: Larry Masinter
>> <[hidden email]> Cc: "[hidden email]"
>> <[hidden email]>, Tony Hansen <[hidden email]>, Philippe Le
>> Hegaret <[hidden email]>, Peter Saint-Andre <[hidden email]>,
>> Adil Allawi <[hidden email]>, Robin Berjon <[hidden email]>,
>> Ted Hardie <[hidden email]>, John O'Conner
>> <[hidden email]>, Pete Resnick <[hidden email]>,
>> "Martin J. Dürst" <[hidden email]>, Chris Weber
>> <[hidden email]> Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
>> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling -
>> REMINDER
>>
>> We should discuss further on a publicly archived mailing list.
>>
>> Adam
>>
>> On Sep 9, 2012 12:00 PM, "Larry Masinter" <[hidden email]>
>> wrote:
>>>
>>> Why doesn't "web+"  introduce all the same problems a blacklist
>>> approach (where everything is allowed unless explicitly
>>> disallowed) introduces? That's kind of what Chris' tests are
>>> showing.
>>>
>>> And what's the point, anyway, of a precise specification but
>>> leaving out the necessary steps to implement the spec
>>> securely?
>>>
>>>
>>>
>>> -----Original Message----- From: Adam Barth
>>> [mailto:[hidden email]] Sent: Sunday, September 09, 2012
>>> 10:20 AM To: Chris Weber Cc: Larry Masinter; "Martin J. Dürst";
>>> Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony
>>> Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete
>>> Resnick; Robin Berjon Subject: Re: 85th IETF - Working
>>> Group/BOF/IRTF Scheduling - REMINDER
>>>
>>> Folks can be unhappy with a whitelist all they want.  A
>>> blacklist isn't secure and we won't implement it.
>>>
>>> Adam
>>>
>>>
>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>> <[hidden email]> wrote:
>>>> Thanks for the message Martin and Larry.  I will not be in
>>>> Atlanta unfortunately,  I'm guessing Peter will..?  I'd be
>>>> happy to schedule some design meeting time for next week
>>>> after the expiring drafts have been re-submitted.
>>>>
>>>> As far as web+xxx, I'm still afraid that a user
>>>> fingerprinting and tracking risk exists - though I didn't
>>>> test the isProtocolHandlerRegistered() method for
>>>> exploitability because it didn't exist, I see Safari has
>>>> implemented it now and Chrome and Firefox have some active
>>>> bugs for tracking.
>>>>
>>>> Also, I notice that some developers are not happy with the
>>>> whitelist vs blacklist approach:
>>>> https://github.com/jquery/standards/issues/12
>>>>
>>>> -Chris
>>>>
>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in
>>>>> Lyon)
>>>>>
>>>>> I'd like to better coordinate the IETF and W3C specs on
>>>>> URLs, IRIs, etc. Doing so was my original motivation for
>>>>> revising these specs in the first place. I'd like to also
>>>>> see if we can make progress on "web+xxx" and (if it's still
>>>>> in W3C specs) "http+aes".
>>>>>
>>>>> I see Chris is doing testing. Making progress on open
>>>>> issues was stymied by lack of testing, so perhaps now that
>>>>> we have some testing capabilities we can make more rapid
>>>>> progress.
>>>>>
>>>>> Larry

<snip/>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBQoGQACgkQNL8k5A2w/vxCAgCfXencuCpjpoP1OqvSvgCb2m/B
OwcAnR7QcQGgy5ZGuuUS60Rcfu1ylNJk
=T5l0
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Adam Barth-5
I should be clear that I'm not advocating "web+" as a good idea.  I'm
just explaining the security consequences of the various options.

Adam


On Wed, Sep 12, 2012 at 7:47 AM, Peter Saint-Andre <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In the context of whitelisting vs. blacklisting, the concern I have
> with the prefixing idea is that it implicitly whitelists any URI
> scheme that starts with the string "web+", yet the proponents of this
> idea have not specified any criteria for review of such prefixed URI
> schemes (or even answered the questions raised here and elsewhere
> about whether additional review is needed for such schemes by the
> designated experts or the IANA).
>
> I agree that blacklisting doesn't scale and isn't secure. I disagree
> that implicit whitelisting is the answer.
>
> Peter
>
> On 9/10/12 9:56 AM, Adam Barth wrote:
>> It's just a practical issue.  Many folks have URI schemes
>> registered on their computers that are not safe for web sites to
>> hijack (i.e., register).  It's not practical to create an blacklist
>> that effectively mitigates that risk.  As it happens, we not aware
>> of any folks who have such registrations for URI schemes that begin
>> with "web+".
>>
>> Adam
>>
>>
>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>> <[hidden email]> wrote:
>>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>>> archived, could someone explain why allowing registering
>>> arbitrary web+xxx scheme handlers is any better than allowing
>>> arbitrary (unblacklisted) xxx scheme handlers?
>>>
>>>
>>> -----Original message-----
>>>
>>> From: Adam Barth <[hidden email]> To: Larry Masinter
>>> <[hidden email]> Cc: "[hidden email]"
>>> <[hidden email]>, Tony Hansen <[hidden email]>, Philippe Le
>>> Hegaret <[hidden email]>, Peter Saint-Andre <[hidden email]>,
>>> Adil Allawi <[hidden email]>, Robin Berjon <[hidden email]>,
>>> Ted Hardie <[hidden email]>, John O'Conner
>>> <[hidden email]>, Pete Resnick <[hidden email]>,
>>> "Martin J. Dürst" <[hidden email]>, Chris Weber
>>> <[hidden email]> Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
>>> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling -
>>> REMINDER
>>>
>>> We should discuss further on a publicly archived mailing list.
>>>
>>> Adam
>>>
>>> On Sep 9, 2012 12:00 PM, "Larry Masinter" <[hidden email]>
>>> wrote:
>>>>
>>>> Why doesn't "web+"  introduce all the same problems a blacklist
>>>> approach (where everything is allowed unless explicitly
>>>> disallowed) introduces? That's kind of what Chris' tests are
>>>> showing.
>>>>
>>>> And what's the point, anyway, of a precise specification but
>>>> leaving out the necessary steps to implement the spec
>>>> securely?
>>>>
>>>>
>>>>
>>>> -----Original Message----- From: Adam Barth
>>>> [mailto:[hidden email]] Sent: Sunday, September 09, 2012
>>>> 10:20 AM To: Chris Weber Cc: Larry Masinter; "Martin J. Dürst";
>>>> Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony
>>>> Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete
>>>> Resnick; Robin Berjon Subject: Re: 85th IETF - Working
>>>> Group/BOF/IRTF Scheduling - REMINDER
>>>>
>>>> Folks can be unhappy with a whitelist all they want.  A
>>>> blacklist isn't secure and we won't implement it.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>> <[hidden email]> wrote:
>>>>> Thanks for the message Martin and Larry.  I will not be in
>>>>> Atlanta unfortunately,  I'm guessing Peter will..?  I'd be
>>>>> happy to schedule some design meeting time for next week
>>>>> after the expiring drafts have been re-submitted.
>>>>>
>>>>> As far as web+xxx, I'm still afraid that a user
>>>>> fingerprinting and tracking risk exists - though I didn't
>>>>> test the isProtocolHandlerRegistered() method for
>>>>> exploitability because it didn't exist, I see Safari has
>>>>> implemented it now and Chrome and Firefox have some active
>>>>> bugs for tracking.
>>>>>
>>>>> Also, I notice that some developers are not happy with the
>>>>> whitelist vs blacklist approach:
>>>>> https://github.com/jquery/standards/issues/12
>>>>>
>>>>> -Chris
>>>>>
>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in
>>>>>> Lyon)
>>>>>>
>>>>>> I'd like to better coordinate the IETF and W3C specs on
>>>>>> URLs, IRIs, etc. Doing so was my original motivation for
>>>>>> revising these specs in the first place. I'd like to also
>>>>>> see if we can make progress on "web+xxx" and (if it's still
>>>>>> in W3C specs) "http+aes".
>>>>>>
>>>>>> I see Chris is doing testing. Making progress on open
>>>>>> issues was stymied by lack of testing, so perhaps now that
>>>>>> we have some testing capabilities we can make more rapid
>>>>>> progress.
>>>>>>
>>>>>> Larry
>
> <snip/>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlBQoGQACgkQNL8k5A2w/vxCAgCfXencuCpjpoP1OqvSvgCb2m/B
> OwcAnR7QcQGgy5ZGuuUS60Rcfu1ylNJk
> =T5l0
> -----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Chris Weber-4
It might be helpful to see some end-to-end use case scenarios for
web+.  I can see the rather obvious ones, but have they been
documented or discussed in more detail anywhere?

Regarding registerProtocolHandler in general, how was the whitelist of
allowed schemes determined?  Why is 'ssh' in the list?

The crux of security defense with registerProtocolHandler comes down
to yet another modal dialog presented to the end user, a troubling
scenario given the enumerated list of threats in the spec:

Hijacking all Web usage
Hijacking defaults
Registration spamming
Misleading titles
Hostile handler metadata
Leaking Intranet URLs
Leaking secure URLs
Leaking credentials

Best regards,
-Chris


On 9/12/2012 9:52 AM, Adam Barth wrote:

> I should be clear that I'm not advocating "web+" as a good idea.
> I'm just explaining the security consequences of the various
> options.
>
> Adam
>
>
> On Wed, Sep 12, 2012 at 7:47 AM, Peter Saint-Andre
> <[hidden email]> wrote: In the context of whitelisting vs.
> blacklisting, the concern I have with the prefixing idea is that
> it implicitly whitelists any URI scheme that starts with the
> string "web+", yet the proponents of this idea have not specified
> any criteria for review of such prefixed URI schemes (or even
> answered the questions raised here and elsewhere about whether
> additional review is needed for such schemes by the designated
> experts or the IANA).
>
> I agree that blacklisting doesn't scale and isn't secure. I
> disagree that implicit whitelisting is the answer.
>
> Peter
>
> On 9/10/12 9:56 AM, Adam Barth wrote:
>>>> It's just a practical issue.  Many folks have URI schemes
>>>> registered on their computers that are not safe for web
>>>> sites to hijack (i.e., register).  It's not practical to
>>>> create an blacklist that effectively mitigates that risk.  As
>>>> it happens, we not aware of any folks who have such
>>>> registrations for URI schemes that begin with "web+".
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>>>> <[hidden email]> wrote:
>>>>> since this affects ietf and w3c, and public-ietf-w3c is
>>>>> publicly archived, could someone explain why allowing
>>>>> registering arbitrary web+xxx scheme handlers is any
>>>>> better than allowing arbitrary (unblacklisted) xxx scheme
>>>>> handlers?
>>>>>
>>>>>
>>>>> -----Original message-----
>>>>>
>>>>> From: Adam Barth <[hidden email]> To: Larry Masinter
>>>>> <[hidden email]> Cc: "[hidden email]"
>>>>> <[hidden email]>, Tony Hansen <[hidden email]>,
>>>>> Philippe Le Hegaret <[hidden email]>, Peter Saint-Andre
>>>>> <[hidden email]>, Adil Allawi <[hidden email]>, Robin
>>>>> Berjon <[hidden email]>, Ted Hardie
>>>>> <[hidden email]>, John O'Conner <[hidden email]>,
>>>>> Pete Resnick <[hidden email]>, "Martin J. Dürst"
>>>>> <[hidden email]>, Chris Weber <[hidden email]>
>>>>> Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00 Subject: RE:
>>>>> 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER
>>>>>
>>>>> We should discuss further on a publicly archived mailing
>>>>> list.
>>>>>
>>>>> Adam
>>>>>
>>>>> On Sep 9, 2012 12:00 PM, "Larry Masinter"
>>>>> <[hidden email]> wrote:
>>>>>>
>>>>>> Why doesn't "web+"  introduce all the same problems a
>>>>>> blacklist approach (where everything is allowed unless
>>>>>> explicitly disallowed) introduces? That's kind of what
>>>>>> Chris' tests are showing.
>>>>>>
>>>>>> And what's the point, anyway, of a precise specification
>>>>>> but leaving out the necessary steps to implement the spec
>>>>>> securely?
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: Adam Barth
>>>>>> [mailto:[hidden email]] Sent: Sunday, September 09,
>>>>>> 2012 10:20 AM To: Chris Weber Cc: Larry Masinter;
>>>>>> "Martin J. Dürst"; Peter Saint-Andre; Philippe Le
>>>>>> Hegaret; John O'Conner; Tony Hansen; Ted Hardie;
>>>>>> [hidden email]; Adil Allawi; Pete Resnick; Robin
>>>>>> Berjon Subject: Re: 85th IETF - Working Group/BOF/IRTF
>>>>>> Scheduling - REMINDER
>>>>>>
>>>>>> Folks can be unhappy with a whitelist all they want.  A
>>>>>> blacklist isn't secure and we won't implement it.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>>>> <[hidden email]> wrote:
>>>>>>> Thanks for the message Martin and Larry.  I will not
>>>>>>> be in Atlanta unfortunately,  I'm guessing Peter
>>>>>>> will..? I'd be happy to schedule some design meeting
>>>>>>> time for next week after the expiring drafts have been
>>>>>>> re-submitted.
>>>>>>>
>>>>>>> As far as web+xxx, I'm still afraid that a user
>>>>>>> fingerprinting and tracking risk exists - though I
>>>>>>> didn't test the isProtocolHandlerRegistered() method
>>>>>>> for exploitability because it didn't exist, I see
>>>>>>> Safari has implemented it now and Chrome and Firefox
>>>>>>> have some active bugs for tracking.
>>>>>>>
>>>>>>> Also, I notice that some developers are not happy with
>>>>>>> the whitelist vs blacklist approach:
>>>>>>> https://github.com/jquery/standards/issues/12
>>>>>>>
>>>>>>> -Chris
>>>>>>>
>>>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>>>> I'm planning to go to IETF Atlanta (direct from W3C
>>>>>>>> TPAC in Lyon)
>>>>>>>>
>>>>>>>> I'd like to better coordinate the IETF and W3C specs
>>>>>>>> on URLs, IRIs, etc. Doing so was my original
>>>>>>>> motivation for revising these specs in the first
>>>>>>>> place. I'd like to also see if we can make progress
>>>>>>>> on "web+xxx" and (if it's still in W3C specs)
>>>>>>>> "http+aes".
>>>>>>>>
>>>>>>>> I see Chris is doing testing. Making progress on open
>>>>>>>> issues was stymied by lack of testing, so perhaps now
>>>>>>>> that we have some testing capabilities we can make
>>>>>>>> more rapid progress.
>>>>>>>>
>>>>>>>> Larry
>
> <snip/>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Martin J. Dürst
On 2012/09/13 4:04, Chris Weber wrote:
> It might be helpful to see some end-to-end use case scenarios for
> web+.  I can see the rather obvious ones, but have they been
> documented or discussed in more detail anywhere?
>
> Regarding registerProtocolHandler in general, how was the whitelist of
> allowed schemes determined?  Why is 'ssh' in the list?
>
> The crux of security defense with registerProtocolHandler comes down
> to yet another modal dialog presented to the end user,

This is indeed a serious problem; users usually don't read the questions
in detail, or don't understand them, and just click through, after which
it may be too late.

My understanding is that there are very similar dialogs for when making
an application the default handler for a scheme. It's usually worded as
"Do you want to make FOO-BROWSER your default browser?" or some such. Is
there any data or experience reports on how well that works?

An alternative that should lower the amount of security problems would
be to require that the user actively has to initiate the process. The
Web application would have a page that says something like "If you want
to make FooMail your default mail application, please select
"Menu1->Option2..." from your browser and enter .... (Menu7->Option8 on
BarBrowser).

+web is whitelisting rather than a blacklisting for deciding which
schemes are eligible. Just having a clickthrough dialog for user
approval looks way more like blacklisting, though.

Regards,   Martin.

> a troubling
> scenario given the enumerated list of threats in the spec:
>
> Hijacking all Web usage
> Hijacking defaults
> Registration spamming
> Misleading titles
> Hostile handler metadata
> Leaking Intranet URLs
> Leaking secure URLs
> Leaking credentials
>
> Best regards,
> -Chris
>
>
> On 9/12/2012 9:52 AM, Adam Barth wrote:
>> I should be clear that I'm not advocating "web+" as a good idea.
>> I'm just explaining the security consequences of the various
>> options.
>>
>> Adam
>>
>>
>> On Wed, Sep 12, 2012 at 7:47 AM, Peter Saint-Andre
>> <[hidden email]>  wrote: In the context of whitelisting vs.
>> blacklisting, the concern I have with the prefixing idea is that
>> it implicitly whitelists any URI scheme that starts with the
>> string "web+", yet the proponents of this idea have not specified
>> any criteria for review of such prefixed URI schemes (or even
>> answered the questions raised here and elsewhere about whether
>> additional review is needed for such schemes by the designated
>> experts or the IANA).
>>
>> I agree that blacklisting doesn't scale and isn't secure. I
>> disagree that implicit whitelisting is the answer.
>>
>> Peter
>>
>> On 9/10/12 9:56 AM, Adam Barth wrote:
>>>>> It's just a practical issue.  Many folks have URI schemes
>>>>> registered on their computers that are not safe for web
>>>>> sites to hijack (i.e., register).  It's not practical to
>>>>> create an blacklist that effectively mitigates that risk.  As
>>>>> it happens, we not aware of any folks who have such
>>>>> registrations for URI schemes that begin with "web+".
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>>>>> <[hidden email]>  wrote:
>>>>>> since this affects ietf and w3c, and public-ietf-w3c is
>>>>>> publicly archived, could someone explain why allowing
>>>>>> registering arbitrary web+xxx scheme handlers is any
>>>>>> better than allowing arbitrary (unblacklisted) xxx scheme
>>>>>> handlers?
>>>>>>
>>>>>>
>>>>>> -----Original message-----
>>>>>>
>>>>>> From: Adam Barth<[hidden email]>  To: Larry Masinter
>>>>>> <[hidden email]>  Cc: "[hidden email]"
>>>>>> <[hidden email]>, Tony Hansen<[hidden email]>,
>>>>>> Philippe Le Hegaret<[hidden email]>, Peter Saint-Andre
>>>>>> <[hidden email]>, Adil Allawi<[hidden email]>, Robin
>>>>>> Berjon<[hidden email]>, Ted Hardie
>>>>>> <[hidden email]>, John O'Conner<[hidden email]>,
>>>>>> Pete Resnick<[hidden email]>, "Martin J. Dürst"
>>>>>> <[hidden email]>, Chris Weber<[hidden email]>
>>>>>> Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00 Subject: RE:
>>>>>> 85th IETF - Working Group/BOF/IRTF Scheduling - REMINDER
>>>>>>
>>>>>> We should discuss further on a publicly archived mailing
>>>>>> list.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>> On Sep 9, 2012 12:00 PM, "Larry Masinter"
>>>>>> <[hidden email]>  wrote:
>>>>>>>
>>>>>>> Why doesn't "web+"  introduce all the same problems a
>>>>>>> blacklist approach (where everything is allowed unless
>>>>>>> explicitly disallowed) introduces? That's kind of what
>>>>>>> Chris' tests are showing.
>>>>>>>
>>>>>>> And what's the point, anyway, of a precise specification
>>>>>>> but leaving out the necessary steps to implement the spec
>>>>>>> securely?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message----- From: Adam Barth
>>>>>>> [mailto:[hidden email]] Sent: Sunday, September 09,
>>>>>>> 2012 10:20 AM To: Chris Weber Cc: Larry Masinter;
>>>>>>> "Martin J. Dürst"; Peter Saint-Andre; Philippe Le
>>>>>>> Hegaret; John O'Conner; Tony Hansen; Ted Hardie;
>>>>>>> [hidden email]; Adil Allawi; Pete Resnick; Robin
>>>>>>> Berjon Subject: Re: 85th IETF - Working Group/BOF/IRTF
>>>>>>> Scheduling - REMINDER
>>>>>>>
>>>>>>> Folks can be unhappy with a whitelist all they want.  A
>>>>>>> blacklist isn't secure and we won't implement it.
>>>>>>>
>>>>>>> Adam
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>>>>> <[hidden email]>  wrote:
>>>>>>>> Thanks for the message Martin and Larry.  I will not
>>>>>>>> be in Atlanta unfortunately,  I'm guessing Peter
>>>>>>>> will..? I'd be happy to schedule some design meeting
>>>>>>>> time for next week after the expiring drafts have been
>>>>>>>> re-submitted.
>>>>>>>>
>>>>>>>> As far as web+xxx, I'm still afraid that a user
>>>>>>>> fingerprinting and tracking risk exists - though I
>>>>>>>> didn't test the isProtocolHandlerRegistered() method
>>>>>>>> for exploitability because it didn't exist, I see
>>>>>>>> Safari has implemented it now and Chrome and Firefox
>>>>>>>> have some active bugs for tracking.
>>>>>>>>
>>>>>>>> Also, I notice that some developers are not happy with
>>>>>>>> the whitelist vs blacklist approach:
>>>>>>>> https://github.com/jquery/standards/issues/12
>>>>>>>>
>>>>>>>> -Chris
>>>>>>>>
>>>>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>>>>> I'm planning to go to IETF Atlanta (direct from W3C
>>>>>>>>> TPAC in Lyon)
>>>>>>>>>
>>>>>>>>> I'd like to better coordinate the IETF and W3C specs
>>>>>>>>> on URLs, IRIs, etc. Doing so was my original
>>>>>>>>> motivation for revising these specs in the first
>>>>>>>>> place. I'd like to also see if we can make progress
>>>>>>>>> on "web+xxx" and (if it's still in W3C specs)
>>>>>>>>> "http+aes".
>>>>>>>>>
>>>>>>>>> I see Chris is doing testing. Making progress on open
>>>>>>>>> issues was stymied by lack of testing, so perhaps now
>>>>>>>>> that we have some testing capabilities we can make
>>>>>>>>> more rapid progress.
>>>>>>>>>
>>>>>>>>> Larry
>>
>> <snip/>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Martin J. Dürst
In reply to this post by Peter Saint-Andre-2
On 2012/09/12 23:47, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In the context of whitelisting vs. blacklisting, the concern I have
> with the prefixing idea is that it implicitly whitelists any URI
> scheme that starts with the string "web+",

I'd buy the "implicitly whitelists" argument if there were any schemes
starting with web+ now, or if there were a big chance that such schemes
would be introduced independent of the purpose of "web+" (e.g. "I need a
new scheme, "web+" really looks cool, I want my scheme to have that as a
prefix so that I'm part of the club.").


> yet the proponents of this
> idea have not specified any criteria for review of such prefixed URI
> schemes (or even answered the questions raised here and elsewhere
> about whether additional review is needed for such schemes by the
> designated experts or the IANA).

Having such criteria would indeed be a good thing. But I guess that in
the limit, it's difficult to come up with some. ssh: quite easily
provides an example. [The following is simplified and so I think it's
not too difficult to poke holes in it, but I hope it shows that it's
difficult to come up with any but very basic criteria.]

It's easy to assume that quite a bit of ssh use is security relevant. On
the other hand, it's not impossible to imagine to use ssh out of a
browser. I have to trust my web browser (which I have to do anyway), and
I have to trust the Web application that provides the ssh facilities.
But that's not much different from having to trust the ssh application
that I downloaded. If I entrust a web mail service with all my email
communications, I may as well entrust a trustworthy ssh Web service with
all my ssh communications.


Even for http/https, which is now blacklisted, who says that in the
future we won't see browsers that are written as Web apps inside another
browser? To some extent, that's a crazy idea involving lots of overheads,...

But proxies and things such as Amazon Silk and some of what Opera does
for mobiles already essentially move part of the browsing facilities
away from the client machine. Google Chrome Frame also implemented a
"browser in a browser", although as a plugin.

Who's to say that a "browser in a browser" (implemented as a Web app)
doesn't make sense? It's the browser makers that have blacklisted
http/https, and maybe (just a wild guess) that's just because they think
they are doing a decent-enough job so that nobody needs a "browser in a
browser".


Which brings me to another problem, and what I think is the main
problem, with the "web+" prefix: When email, and mailto:, were created,
who was thinking about Webmail? Of course nobody. So when the next
interesting killer app for the Internet is created, who will think about
doing a Web version? In many if not most cases, it will either be
Web-based from the start (which means it uses http(s) and doesn't need
to think about a new URI/IRI scheme or a prefix), or it will be
standalone because it's way too hard and does not seem appropriate to do
the same thing in a browser. So the creators of this new technology will
just register a scheme without "web+". At a later date, when somebody
comes up with a cool way to do the same thing over the Web, it's already
way too late to add the "web+" prefix.

In other words, I think the problem is not with having (or not) a list
of criteria, it's with being able to judge whether these criteria will
apply somewhen in the future.


Regards,    Martin.

> I agree that blacklisting doesn't scale and isn't secure. I disagree
> that implicit whitelisting is the answer.
>
> Peter
>
> On 9/10/12 9:56 AM, Adam Barth wrote:
>> It's just a practical issue.  Many folks have URI schemes
>> registered on their computers that are not safe for web sites to
>> hijack (i.e., register).  It's not practical to create an blacklist
>> that effectively mitigates that risk.  As it happens, we not aware
>> of any folks who have such registrations for URI schemes that begin
>> with "web+".
>>
>> Adam
>>
>>
>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>> <[hidden email]>  wrote:
>>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>>> archived, could someone explain why allowing registering
>>> arbitrary web+xxx scheme handlers is any better than allowing
>>> arbitrary (unblacklisted) xxx scheme handlers?
>>>
>>>
>>> -----Original message-----
>>>
>>> From: Adam Barth<[hidden email]>  To: Larry Masinter
>>> <[hidden email]>  Cc: "[hidden email]"
>>> <[hidden email]>, Tony Hansen<[hidden email]>, Philippe Le
>>> Hegaret<[hidden email]>, Peter Saint-Andre<[hidden email]>,
>>> Adil Allawi<[hidden email]>, Robin Berjon<[hidden email]>,
>>> Ted Hardie<[hidden email]>, John O'Conner
>>> <[hidden email]>, Pete Resnick<[hidden email]>,
>>> "Martin J. Dürst"<[hidden email]>, Chris Weber
>>> <[hidden email]>  Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
>>> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling -
>>> REMINDER
>>>
>>> We should discuss further on a publicly archived mailing list.
>>>
>>> Adam
>>>
>>> On Sep 9, 2012 12:00 PM, "Larry Masinter"<[hidden email]>
>>> wrote:
>>>>
>>>> Why doesn't "web+"  introduce all the same problems a blacklist
>>>> approach (where everything is allowed unless explicitly
>>>> disallowed) introduces? That's kind of what Chris' tests are
>>>> showing.
>>>>
>>>> And what's the point, anyway, of a precise specification but
>>>> leaving out the necessary steps to implement the spec
>>>> securely?
>>>>
>>>>
>>>>
>>>> -----Original Message----- From: Adam Barth
>>>> [mailto:[hidden email]] Sent: Sunday, September 09, 2012
>>>> 10:20 AM To: Chris Weber Cc: Larry Masinter; "Martin J. Dürst";
>>>> Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony
>>>> Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete
>>>> Resnick; Robin Berjon Subject: Re: 85th IETF - Working
>>>> Group/BOF/IRTF Scheduling - REMINDER
>>>>
>>>> Folks can be unhappy with a whitelist all they want.  A
>>>> blacklist isn't secure and we won't implement it.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>> <[hidden email]>  wrote:
>>>>> Thanks for the message Martin and Larry.  I will not be in
>>>>> Atlanta unfortunately,  I'm guessing Peter will..?  I'd be
>>>>> happy to schedule some design meeting time for next week
>>>>> after the expiring drafts have been re-submitted.
>>>>>
>>>>> As far as web+xxx, I'm still afraid that a user
>>>>> fingerprinting and tracking risk exists - though I didn't
>>>>> test the isProtocolHandlerRegistered() method for
>>>>> exploitability because it didn't exist, I see Safari has
>>>>> implemented it now and Chrome and Firefox have some active
>>>>> bugs for tracking.
>>>>>
>>>>> Also, I notice that some developers are not happy with the
>>>>> whitelist vs blacklist approach:
>>>>> https://github.com/jquery/standards/issues/12
>>>>>
>>>>> -Chris
>>>>>
>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in
>>>>>> Lyon)
>>>>>>
>>>>>> I'd like to better coordinate the IETF and W3C specs on
>>>>>> URLs, IRIs, etc. Doing so was my original motivation for
>>>>>> revising these specs in the first place. I'd like to also
>>>>>> see if we can make progress on "web+xxx" and (if it's still
>>>>>> in W3C specs) "http+aes".
>>>>>>
>>>>>> I see Chris is doing testing. Making progress on open
>>>>>> issues was stymied by lack of testing, so perhaps now that
>>>>>> we have some testing capabilities we can make more rapid
>>>>>> progress.
>>>>>>
>>>>>> Larry
>
> <snip/>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlBQoGQACgkQNL8k5A2w/vxCAgCfXencuCpjpoP1OqvSvgCb2m/B
> OwcAnR7QcQGgy5ZGuuUS60Rcfu1ylNJk
> =T5l0
> -----END PGP SIGNATURE-----
>
>

Reply | Threaded
Open this post in threaded view
|

RE: web+ and registerProtocolHandler

masinter
I think we should be more careful with terminology.
"Whitelist" -- all values are forbidden except ones explicitly in a (fininte, enumerated) "white list", so a whitelist allows a small subset, and disallows everything in an arbitrarily large set.
"blacklist" -- all values are allowed except ones explicitly in a (finite, enumerated) "black list", so a blacklist disallows a small subset, and allows everything else in an arbitrarily large set.

The pros and cons of the two approaches have to do with what is deployed and what is known to be deployed and has been evaluated as "safe to override",
 as well as what we imagine might be useful to allow.

The "web+" convention is hybrid, it's not a "blacklist" and it's not really a "whitelist" either. While it's like a whitelist explicitly allows one small, enumerated, known-in-advance set (which seems pretty arbitrary and without justification), but it also allows another arbitrarily large set.

The notion is that anything using "web+" should be, by definition, safe to override with registerProtocolHandler.

Part of the question is whether anyone defining a web+ scheme will actually register it, or will look at the registry to determine if anyone is using it.
Right now, browsers (Chrome, Safari) define URI schemes and use them without any significant effort to register them. Why is there any expectation that this will change?   So the notion that the registration process can somehow enforce invariants for security reasons is suspect.

Probably the disagreement about the the value of and venue for registration is the more important "elephant in the room".

Larry


-----Original Message-----
From: "Martin J. Dürst" [mailto:[hidden email]]
Sent: Wednesday, September 12, 2012 9:32 PM
To: Peter Saint-Andre
Cc: Adam Barth; Larry Masinter; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; John O'Conner; [hidden email]; [hidden email]; [hidden email]
Subject: Re: web+ and registerProtocolHandler

On 2012/09/12 23:47, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In the context of whitelisting vs. blacklisting, the concern I have
> with the prefixing idea is that it implicitly whitelists any URI
> scheme that starts with the string "web+",

I'd buy the "implicitly whitelists" argument if there were any schemes
starting with web+ now, or if there were a big chance that such schemes
would be introduced independent of the purpose of "web+" (e.g. "I need a
new scheme, "web+" really looks cool, I want my scheme to have that as a
prefix so that I'm part of the club.").


> yet the proponents of this
> idea have not specified any criteria for review of such prefixed URI
> schemes (or even answered the questions raised here and elsewhere
> about whether additional review is needed for such schemes by the
> designated experts or the IANA).

Having such criteria would indeed be a good thing. But I guess that in
the limit, it's difficult to come up with some. ssh: quite easily
provides an example. [The following is simplified and so I think it's
not too difficult to poke holes in it, but I hope it shows that it's
difficult to come up with any but very basic criteria.]

It's easy to assume that quite a bit of ssh use is security relevant. On
the other hand, it's not impossible to imagine to use ssh out of a
browser. I have to trust my web browser (which I have to do anyway), and
I have to trust the Web application that provides the ssh facilities.
But that's not much different from having to trust the ssh application
that I downloaded. If I entrust a web mail service with all my email
communications, I may as well entrust a trustworthy ssh Web service with
all my ssh communications.


Even for http/https, which is now blacklisted, who says that in the
future we won't see browsers that are written as Web apps inside another
browser? To some extent, that's a crazy idea involving lots of overheads,...

But proxies and things such as Amazon Silk and some of what Opera does
for mobiles already essentially move part of the browsing facilities
away from the client machine. Google Chrome Frame also implemented a
"browser in a browser", although as a plugin.

Who's to say that a "browser in a browser" (implemented as a Web app)
doesn't make sense? It's the browser makers that have blacklisted
http/https, and maybe (just a wild guess) that's just because they think
they are doing a decent-enough job so that nobody needs a "browser in a
browser".


Which brings me to another problem, and what I think is the main
problem, with the "web+" prefix: When email, and mailto:, were created,
who was thinking about Webmail? Of course nobody. So when the next
interesting killer app for the Internet is created, who will think about
doing a Web version? In many if not most cases, it will either be
Web-based from the start (which means it uses http(s) and doesn't need
to think about a new URI/IRI scheme or a prefix), or it will be
standalone because it's way too hard and does not seem appropriate to do
the same thing in a browser. So the creators of this new technology will
just register a scheme without "web+". At a later date, when somebody
comes up with a cool way to do the same thing over the Web, it's already
way too late to add the "web+" prefix.

In other words, I think the problem is not with having (or not) a list
of criteria, it's with being able to judge whether these criteria will
apply somewhen in the future.


Regards,    Martin.

> I agree that blacklisting doesn't scale and isn't secure. I disagree
> that implicit whitelisting is the answer.
>
> Peter
>
> On 9/10/12 9:56 AM, Adam Barth wrote:
>> It's just a practical issue.  Many folks have URI schemes
>> registered on their computers that are not safe for web sites to
>> hijack (i.e., register).  It's not practical to create an blacklist
>> that effectively mitigates that risk.  As it happens, we not aware
>> of any folks who have such registrations for URI schemes that begin
>> with "web+".
>>
>> Adam
>>
>>
>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>> <[hidden email]>  wrote:
>>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>>> archived, could someone explain why allowing registering
>>> arbitrary web+xxx scheme handlers is any better than allowing
>>> arbitrary (unblacklisted) xxx scheme handlers?
>>>
>>>
>>> -----Original message-----
>>>
>>> From: Adam Barth<[hidden email]>  To: Larry Masinter
>>> <[hidden email]>  Cc: "[hidden email]"
>>> <[hidden email]>, Tony Hansen<[hidden email]>, Philippe Le
>>> Hegaret<[hidden email]>, Peter Saint-Andre<[hidden email]>,
>>> Adil Allawi<[hidden email]>, Robin Berjon<[hidden email]>,
>>> Ted Hardie<[hidden email]>, John O'Conner
>>> <[hidden email]>, Pete Resnick<[hidden email]>,
>>> "Martin J. Dürst"<[hidden email]>, Chris Weber
>>> <[hidden email]>  Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
>>> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling -
>>> REMINDER
>>>
>>> We should discuss further on a publicly archived mailing list.
>>>
>>> Adam
>>>
>>> On Sep 9, 2012 12:00 PM, "Larry Masinter"<[hidden email]>
>>> wrote:
>>>>
>>>> Why doesn't "web+"  introduce all the same problems a blacklist
>>>> approach (where everything is allowed unless explicitly
>>>> disallowed) introduces? That's kind of what Chris' tests are
>>>> showing.
>>>>
>>>> And what's the point, anyway, of a precise specification but
>>>> leaving out the necessary steps to implement the spec
>>>> securely?
>>>>
>>>>
>>>>
>>>> -----Original Message----- From: Adam Barth
>>>> [mailto:[hidden email]] Sent: Sunday, September 09, 2012
>>>> 10:20 AM To: Chris Weber Cc: Larry Masinter; "Martin J. Dürst";
>>>> Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony
>>>> Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete
>>>> Resnick; Robin Berjon Subject: Re: 85th IETF - Working
>>>> Group/BOF/IRTF Scheduling - REMINDER
>>>>
>>>> Folks can be unhappy with a whitelist all they want.  A
>>>> blacklist isn't secure and we won't implement it.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>> <[hidden email]>  wrote:
>>>>> Thanks for the message Martin and Larry.  I will not be in
>>>>> Atlanta unfortunately,  I'm guessing Peter will..?  I'd be
>>>>> happy to schedule some design meeting time for next week
>>>>> after the expiring drafts have been re-submitted.
>>>>>
>>>>> As far as web+xxx, I'm still afraid that a user
>>>>> fingerprinting and tracking risk exists - though I didn't
>>>>> test the isProtocolHandlerRegistered() method for
>>>>> exploitability because it didn't exist, I see Safari has
>>>>> implemented it now and Chrome and Firefox have some active
>>>>> bugs for tracking.
>>>>>
>>>>> Also, I notice that some developers are not happy with the
>>>>> whitelist vs blacklist approach:
>>>>> https://github.com/jquery/standards/issues/12
>>>>>
>>>>> -Chris
>>>>>
>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in
>>>>>> Lyon)
>>>>>>
>>>>>> I'd like to better coordinate the IETF and W3C specs on
>>>>>> URLs, IRIs, etc. Doing so was my original motivation for
>>>>>> revising these specs in the first place. I'd like to also
>>>>>> see if we can make progress on "web+xxx" and (if it's still
>>>>>> in W3C specs) "http+aes".
>>>>>>
>>>>>> I see Chris is doing testing. Making progress on open
>>>>>> issues was stymied by lack of testing, so perhaps now that
>>>>>> we have some testing capabilities we can make more rapid
>>>>>> progress.
>>>>>>
>>>>>> Larry
>
> <snip/>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlBQoGQACgkQNL8k5A2w/vxCAgCfXencuCpjpoP1OqvSvgCb2m/B
> OwcAnR7QcQGgy5ZGuuUS60Rcfu1ylNJk
> =T5l0
> -----END PGP SIGNATURE-----
>
>
Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Adam Barth-5
Yes.  Registering URI schemes is too hard.  If it were easier, we'd
register a bunch of URI schemes that we use in Chrome.

Adam


On Fri, Sep 14, 2012 at 12:20 PM, Larry Masinter <[hidden email]> wrote:

> I think we should be more careful with terminology.
> "Whitelist" -- all values are forbidden except ones explicitly in a (fininte, enumerated) "white list", so a whitelist allows a small subset, and disallows everything in an arbitrarily large set.
> "blacklist" -- all values are allowed except ones explicitly in a (finite, enumerated) "black list", so a blacklist disallows a small subset, and allows everything else in an arbitrarily large set.
>
> The pros and cons of the two approaches have to do with what is deployed and what is known to be deployed and has been evaluated as "safe to override",
>  as well as what we imagine might be useful to allow.
>
> The "web+" convention is hybrid, it's not a "blacklist" and it's not really a "whitelist" either. While it's like a whitelist explicitly allows one small, enumerated, known-in-advance set (which seems pretty arbitrary and without justification), but it also allows another arbitrarily large set.
>
> The notion is that anything using "web+" should be, by definition, safe to override with registerProtocolHandler.
>
> Part of the question is whether anyone defining a web+ scheme will actually register it, or will look at the registry to determine if anyone is using it.
> Right now, browsers (Chrome, Safari) define URI schemes and use them without any significant effort to register them. Why is there any expectation that this will change?   So the notion that the registration process can somehow enforce invariants for security reasons is suspect.
>
> Probably the disagreement about the the value of and venue for registration is the more important "elephant in the room".
>
> Larry
>
>
> -----Original Message-----
> From: "Martin J. Dürst" [mailto:[hidden email]]
> Sent: Wednesday, September 12, 2012 9:32 PM
> To: Peter Saint-Andre
> Cc: Adam Barth; Larry Masinter; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; John O'Conner; [hidden email]; [hidden email]; [hidden email]
> Subject: Re: web+ and registerProtocolHandler
>
> On 2012/09/12 23:47, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> In the context of whitelisting vs. blacklisting, the concern I have
>> with the prefixing idea is that it implicitly whitelists any URI
>> scheme that starts with the string "web+",
>
> I'd buy the "implicitly whitelists" argument if there were any schemes
> starting with web+ now, or if there were a big chance that such schemes
> would be introduced independent of the purpose of "web+" (e.g. "I need a
> new scheme, "web+" really looks cool, I want my scheme to have that as a
> prefix so that I'm part of the club.").
>
>
>> yet the proponents of this
>> idea have not specified any criteria for review of such prefixed URI
>> schemes (or even answered the questions raised here and elsewhere
>> about whether additional review is needed for such schemes by the
>> designated experts or the IANA).
>
> Having such criteria would indeed be a good thing. But I guess that in
> the limit, it's difficult to come up with some. ssh: quite easily
> provides an example. [The following is simplified and so I think it's
> not too difficult to poke holes in it, but I hope it shows that it's
> difficult to come up with any but very basic criteria.]
>
> It's easy to assume that quite a bit of ssh use is security relevant. On
> the other hand, it's not impossible to imagine to use ssh out of a
> browser. I have to trust my web browser (which I have to do anyway), and
> I have to trust the Web application that provides the ssh facilities.
> But that's not much different from having to trust the ssh application
> that I downloaded. If I entrust a web mail service with all my email
> communications, I may as well entrust a trustworthy ssh Web service with
> all my ssh communications.
>
>
> Even for http/https, which is now blacklisted, who says that in the
> future we won't see browsers that are written as Web apps inside another
> browser? To some extent, that's a crazy idea involving lots of overheads,...
>
> But proxies and things such as Amazon Silk and some of what Opera does
> for mobiles already essentially move part of the browsing facilities
> away from the client machine. Google Chrome Frame also implemented a
> "browser in a browser", although as a plugin.
>
> Who's to say that a "browser in a browser" (implemented as a Web app)
> doesn't make sense? It's the browser makers that have blacklisted
> http/https, and maybe (just a wild guess) that's just because they think
> they are doing a decent-enough job so that nobody needs a "browser in a
> browser".
>
>
> Which brings me to another problem, and what I think is the main
> problem, with the "web+" prefix: When email, and mailto:, were created,
> who was thinking about Webmail? Of course nobody. So when the next
> interesting killer app for the Internet is created, who will think about
> doing a Web version? In many if not most cases, it will either be
> Web-based from the start (which means it uses http(s) and doesn't need
> to think about a new URI/IRI scheme or a prefix), or it will be
> standalone because it's way too hard and does not seem appropriate to do
> the same thing in a browser. So the creators of this new technology will
> just register a scheme without "web+". At a later date, when somebody
> comes up with a cool way to do the same thing over the Web, it's already
> way too late to add the "web+" prefix.
>
> In other words, I think the problem is not with having (or not) a list
> of criteria, it's with being able to judge whether these criteria will
> apply somewhen in the future.
>
>
> Regards,    Martin.
>
>> I agree that blacklisting doesn't scale and isn't secure. I disagree
>> that implicit whitelisting is the answer.
>>
>> Peter
>>
>> On 9/10/12 9:56 AM, Adam Barth wrote:
>>> It's just a practical issue.  Many folks have URI schemes
>>> registered on their computers that are not safe for web sites to
>>> hijack (i.e., register).  It's not practical to create an blacklist
>>> that effectively mitigates that risk.  As it happens, we not aware
>>> of any folks who have such registrations for URI schemes that begin
>>> with "web+".
>>>
>>> Adam
>>>
>>>
>>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>>> <[hidden email]>  wrote:
>>>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>>>> archived, could someone explain why allowing registering
>>>> arbitrary web+xxx scheme handlers is any better than allowing
>>>> arbitrary (unblacklisted) xxx scheme handlers?
>>>>
>>>>
>>>> -----Original message-----
>>>>
>>>> From: Adam Barth<[hidden email]>  To: Larry Masinter
>>>> <[hidden email]>  Cc: "[hidden email]"
>>>> <[hidden email]>, Tony Hansen<[hidden email]>, Philippe Le
>>>> Hegaret<[hidden email]>, Peter Saint-Andre<[hidden email]>,
>>>> Adil Allawi<[hidden email]>, Robin Berjon<[hidden email]>,
>>>> Ted Hardie<[hidden email]>, John O'Conner
>>>> <[hidden email]>, Pete Resnick<[hidden email]>,
>>>> "Martin J. Dürst"<[hidden email]>, Chris Weber
>>>> <[hidden email]>  Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
>>>> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling -
>>>> REMINDER
>>>>
>>>> We should discuss further on a publicly archived mailing list.
>>>>
>>>> Adam
>>>>
>>>> On Sep 9, 2012 12:00 PM, "Larry Masinter"<[hidden email]>
>>>> wrote:
>>>>>
>>>>> Why doesn't "web+"  introduce all the same problems a blacklist
>>>>> approach (where everything is allowed unless explicitly
>>>>> disallowed) introduces? That's kind of what Chris' tests are
>>>>> showing.
>>>>>
>>>>> And what's the point, anyway, of a precise specification but
>>>>> leaving out the necessary steps to implement the spec
>>>>> securely?
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message----- From: Adam Barth
>>>>> [mailto:[hidden email]] Sent: Sunday, September 09, 2012
>>>>> 10:20 AM To: Chris Weber Cc: Larry Masinter; "Martin J. Dürst";
>>>>> Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony
>>>>> Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete
>>>>> Resnick; Robin Berjon Subject: Re: 85th IETF - Working
>>>>> Group/BOF/IRTF Scheduling - REMINDER
>>>>>
>>>>> Folks can be unhappy with a whitelist all they want.  A
>>>>> blacklist isn't secure and we won't implement it.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>>> <[hidden email]>  wrote:
>>>>>> Thanks for the message Martin and Larry.  I will not be in
>>>>>> Atlanta unfortunately,  I'm guessing Peter will..?  I'd be
>>>>>> happy to schedule some design meeting time for next week
>>>>>> after the expiring drafts have been re-submitted.
>>>>>>
>>>>>> As far as web+xxx, I'm still afraid that a user
>>>>>> fingerprinting and tracking risk exists - though I didn't
>>>>>> test the isProtocolHandlerRegistered() method for
>>>>>> exploitability because it didn't exist, I see Safari has
>>>>>> implemented it now and Chrome and Firefox have some active
>>>>>> bugs for tracking.
>>>>>>
>>>>>> Also, I notice that some developers are not happy with the
>>>>>> whitelist vs blacklist approach:
>>>>>> https://github.com/jquery/standards/issues/12
>>>>>>
>>>>>> -Chris
>>>>>>
>>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in
>>>>>>> Lyon)
>>>>>>>
>>>>>>> I'd like to better coordinate the IETF and W3C specs on
>>>>>>> URLs, IRIs, etc. Doing so was my original motivation for
>>>>>>> revising these specs in the first place. I'd like to also
>>>>>>> see if we can make progress on "web+xxx" and (if it's still
>>>>>>> in W3C specs) "http+aes".
>>>>>>>
>>>>>>> I see Chris is doing testing. Making progress on open
>>>>>>> issues was stymied by lack of testing, so perhaps now that
>>>>>>> we have some testing capabilities we can make more rapid
>>>>>>> progress.
>>>>>>>
>>>>>>> Larry
>>
>> <snip/>
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
>> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>>
>> iEYEARECAAYFAlBQoGQACgkQNL8k5A2w/vxCAgCfXencuCpjpoP1OqvSvgCb2m/B
>> OwcAnR7QcQGgy5ZGuuUS60Rcfu1ylNJk
>> =T5l0
>> -----END PGP SIGNATURE-----
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Alexey Melnikov
Hi Adam,

On 14/09/2012 20:44, Adam Barth wrote:
> Yes.  Registering URI schemes is too hard.  If it were easier, we'd
> register a bunch of URI schemes that we use in Chrome.
Have you or one of your co-workers tried to register and got a rejection
from the Expert Reviewer? Have you tried a Permanent or a Provisional
registration?

> Adam
>
>
> On Fri, Sep 14, 2012 at 12:20 PM, Larry Masinter <[hidden email]> wrote:
>> I think we should be more careful with terminology.
>> "Whitelist" -- all values are forbidden except ones explicitly in a (fininte, enumerated) "white list", so a whitelist allows a small subset, and disallows everything in an arbitrarily large set.
>> "blacklist" -- all values are allowed except ones explicitly in a (finite, enumerated) "black list", so a blacklist disallows a small subset, and allows everything else in an arbitrarily large set.
>>
>> The pros and cons of the two approaches have to do with what is deployed and what is known to be deployed and has been evaluated as "safe to override",
>>   as well as what we imagine might be useful to allow.
>>
>> The "web+" convention is hybrid, it's not a "blacklist" and it's not really a "whitelist" either. While it's like a whitelist explicitly allows one small, enumerated, known-in-advance set (which seems pretty arbitrary and without justification), but it also allows another arbitrarily large set.
>>
>> The notion is that anything using "web+" should be, by definition, safe to override with registerProtocolHandler.
>>
>> Part of the question is whether anyone defining a web+ scheme will actually register it, or will look at the registry to determine if anyone is using it.
>> Right now, browsers (Chrome, Safari) define URI schemes and use them without any significant effort to register them. Why is there any expectation that this will change?   So the notion that the registration process can somehow enforce invariants for security reasons is suspect.
>>
>> Probably the disagreement about the the value of and venue for registration is the more important "elephant in the room".
>>
>> Larry


Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Adam Barth-5
On Sat, Sep 15, 2012 at 5:53 AM, Alexey Melnikov
<[hidden email]> wrote:
> On 14/09/2012 20:44, Adam Barth wrote:
>> Yes.  Registering URI schemes is too hard.  If it were easier, we'd
>> register a bunch of URI schemes that we use in Chrome.
>
> Have you or one of your co-workers tried to register and got a rejection
> from the Expert Reviewer? Have you tried a Permanent or a Provisional
> registration?

I'm not sure, but I'll give it a try this week.

Adam


>> On Fri, Sep 14, 2012 at 12:20 PM, Larry Masinter <[hidden email]>
>> wrote:
>>>
>>> I think we should be more careful with terminology.
>>> "Whitelist" -- all values are forbidden except ones explicitly in a
>>> (fininte, enumerated) "white list", so a whitelist allows a small subset,
>>> and disallows everything in an arbitrarily large set.
>>> "blacklist" -- all values are allowed except ones explicitly in a
>>> (finite, enumerated) "black list", so a blacklist disallows a small subset,
>>> and allows everything else in an arbitrarily large set.
>>>
>>> The pros and cons of the two approaches have to do with what is deployed
>>> and what is known to be deployed and has been evaluated as "safe to
>>> override",
>>>   as well as what we imagine might be useful to allow.
>>>
>>> The "web+" convention is hybrid, it's not a "blacklist" and it's not
>>> really a "whitelist" either. While it's like a whitelist explicitly allows
>>> one small, enumerated, known-in-advance set (which seems pretty arbitrary
>>> and without justification), but it also allows another arbitrarily large
>>> set.
>>>
>>> The notion is that anything using "web+" should be, by definition, safe
>>> to override with registerProtocolHandler.
>>>
>>> Part of the question is whether anyone defining a web+ scheme will
>>> actually register it, or will look at the registry to determine if anyone is
>>> using it.
>>> Right now, browsers (Chrome, Safari) define URI schemes and use them
>>> without any significant effort to register them. Why is there any
>>> expectation that this will change?   So the notion that the registration
>>> process can somehow enforce invariants for security reasons is suspect.
>>>
>>> Probably the disagreement about the the value of and venue for
>>> registration is the more important "elephant in the room".
>>>
>>> Larry
>
>

Reply | Threaded
Open this post in threaded view
|

URI registrations from Google (was Re: web+ and registerProtocolHandler)

Alexey Melnikov
On 16/09/2012 16:31, Adam Barth wrote:
> On Sat, Sep 15, 2012 at 5:53 AM, Alexey Melnikov
> <[hidden email]> wrote:
>> On 14/09/2012 20:44, Adam Barth wrote:
>>> Yes.  Registering URI schemes is too hard.  If it were easier, we'd
>>> register a bunch of URI schemes that we use in Chrome.
>> Have you or one of your co-workers tried to register and got a rejection
>> from the Expert Reviewer? Have you tried a Permanent or a Provisional
>> registration?
> I'm not sure, but I'll give it a try this week.
As a side note: Dave Thales already submitted a provisional registration
of chrome: to IANA using the third party registration process. Graham
Klyne (the URI Expert Reviewer) is in the process of reviewing it and
several others unrelated URI schemes.
Google can assert ownership and update the registration template.



Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Stephen Farrell
In reply to this post by masinter

So I've seen a bunch of uniformly negative mail on this
and nothing positive fwiw.

Maybe it'd be good to get an appsarea presentation on it
at an IETF meeting (assuming that's not happened) so the
broader community get to know about it?

I don't really know enough to be against it myself but
it does sound like a bad security idea from the mails I've
seen pass by so count me amongst those concerned about
this.

S.

On 09/14/2012 08:20 PM, Larry Masinter wrote:

> I think we should be more careful with terminology.
> "Whitelist" -- all values are forbidden except ones explicitly in a (fininte, enumerated) "white list", so a whitelist allows a small subset, and disallows everything in an arbitrarily large set.
> "blacklist" -- all values are allowed except ones explicitly in a (finite, enumerated) "black list", so a blacklist disallows a small subset, and allows everything else in an arbitrarily large set.
>
> The pros and cons of the two approaches have to do with what is deployed and what is known to be deployed and has been evaluated as "safe to override",
>  as well as what we imagine might be useful to allow.
>
> The "web+" convention is hybrid, it's not a "blacklist" and it's not really a "whitelist" either. While it's like a whitelist explicitly allows one small, enumerated, known-in-advance set (which seems pretty arbitrary and without justification), but it also allows another arbitrarily large set.
>
> The notion is that anything using "web+" should be, by definition, safe to override with registerProtocolHandler.
>
> Part of the question is whether anyone defining a web+ scheme will actually register it, or will look at the registry to determine if anyone is using it.
> Right now, browsers (Chrome, Safari) define URI schemes and use them without any significant effort to register them. Why is there any expectation that this will change?   So the notion that the registration process can somehow enforce invariants for security reasons is suspect.
>
> Probably the disagreement about the the value of and venue for registration is the more important "elephant in the room".
>
> Larry
>
>
> -----Original Message-----
> From: "Martin J. Dürst" [mailto:[hidden email]]
> Sent: Wednesday, September 12, 2012 9:32 PM
> To: Peter Saint-Andre
> Cc: Adam Barth; Larry Masinter; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; John O'Conner; [hidden email]; [hidden email]; [hidden email]
> Subject: Re: web+ and registerProtocolHandler
>
> On 2012/09/12 23:47, Peter Saint-Andre wrote:
> In the context of whitelisting vs. blacklisting, the concern I have
> with the prefixing idea is that it implicitly whitelists any URI
> scheme that starts with the string "web+",
>
>> I'd buy the "implicitly whitelists" argument if there were any schemes
>> starting with web+ now, or if there were a big chance that such schemes
>> would be introduced independent of the purpose of "web+" (e.g. "I need a
>> new scheme, "web+" really looks cool, I want my scheme to have that as a
>> prefix so that I'm part of the club.").
>
>
> yet the proponents of this
> idea have not specified any criteria for review of such prefixed URI
> schemes (or even answered the questions raised here and elsewhere
> about whether additional review is needed for such schemes by the
> designated experts or the IANA).
>
>> Having such criteria would indeed be a good thing. But I guess that in
>> the limit, it's difficult to come up with some. ssh: quite easily
>> provides an example. [The following is simplified and so I think it's
>> not too difficult to poke holes in it, but I hope it shows that it's
>> difficult to come up with any but very basic criteria.]
>
>> It's easy to assume that quite a bit of ssh use is security relevant. On
>> the other hand, it's not impossible to imagine to use ssh out of a
>> browser. I have to trust my web browser (which I have to do anyway), and
>> I have to trust the Web application that provides the ssh facilities.
>> But that's not much different from having to trust the ssh application
>> that I downloaded. If I entrust a web mail service with all my email
>> communications, I may as well entrust a trustworthy ssh Web service with
>> all my ssh communications.
>
>
>> Even for http/https, which is now blacklisted, who says that in the
>> future we won't see browsers that are written as Web apps inside another
>> browser? To some extent, that's a crazy idea involving lots of overheads,...
>
>> But proxies and things such as Amazon Silk and some of what Opera does
>> for mobiles already essentially move part of the browsing facilities
>> away from the client machine. Google Chrome Frame also implemented a
>> "browser in a browser", although as a plugin.
>
>> Who's to say that a "browser in a browser" (implemented as a Web app)
>> doesn't make sense? It's the browser makers that have blacklisted
>> http/https, and maybe (just a wild guess) that's just because they think
>> they are doing a decent-enough job so that nobody needs a "browser in a
>> browser".
>
>
>> Which brings me to another problem, and what I think is the main
>> problem, with the "web+" prefix: When email, and mailto:, were created,
>> who was thinking about Webmail? Of course nobody. So when the next
>> interesting killer app for the Internet is created, who will think about
>> doing a Web version? In many if not most cases, it will either be
>> Web-based from the start (which means it uses http(s) and doesn't need
>> to think about a new URI/IRI scheme or a prefix), or it will be
>> standalone because it's way too hard and does not seem appropriate to do
>> the same thing in a browser. So the creators of this new technology will
>> just register a scheme without "web+". At a later date, when somebody
>> comes up with a cool way to do the same thing over the Web, it's already
>> way too late to add the "web+" prefix.
>
>> In other words, I think the problem is not with having (or not) a list
>> of criteria, it's with being able to judge whether these criteria will
>> apply somewhen in the future.
>
>
>> Regards,    Martin.
>
> I agree that blacklisting doesn't scale and isn't secure. I disagree
> that implicit whitelisting is the answer.
>
> Peter
>
> On 9/10/12 9:56 AM, Adam Barth wrote:
>>>> It's just a practical issue.  Many folks have URI schemes
>>>> registered on their computers that are not safe for web sites to
>>>> hijack (i.e., register).  It's not practical to create an blacklist
>>>> that effectively mitigates that risk.  As it happens, we not aware
>>>> of any folks who have such registrations for URI schemes that begin
>>>> with "web+".
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>>>> <[hidden email]>  wrote:
>>>>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>>>>> archived, could someone explain why allowing registering
>>>>> arbitrary web+xxx scheme handlers is any better than allowing
>>>>> arbitrary (unblacklisted) xxx scheme handlers?
>>>>>
>>>>>
>>>>> -----Original message-----
>>>>>
>>>>> From: Adam Barth<[hidden email]>  To: Larry Masinter
>>>>> <[hidden email]>  Cc: "[hidden email]"
>>>>> <[hidden email]>, Tony Hansen<[hidden email]>, Philippe Le
>>>>> Hegaret<[hidden email]>, Peter Saint-Andre<[hidden email]>,
>>>>> Adil Allawi<[hidden email]>, Robin Berjon<[hidden email]>,
>>>>> Ted Hardie<[hidden email]>, John O'Conner
>>>>> <[hidden email]>, Pete Resnick<[hidden email]>,
>>>>> "Martin J. Dürst"<[hidden email]>, Chris Weber
>>>>> <[hidden email]>  Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
>>>>> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling -
>>>>> REMINDER
>>>>>
>>>>> We should discuss further on a publicly archived mailing list.
>>>>>
>>>>> Adam
>>>>>
>>>>> On Sep 9, 2012 12:00 PM, "Larry Masinter"<[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>> Why doesn't "web+"  introduce all the same problems a blacklist
>>>>>> approach (where everything is allowed unless explicitly
>>>>>> disallowed) introduces? That's kind of what Chris' tests are
>>>>>> showing.
>>>>>>
>>>>>> And what's the point, anyway, of a precise specification but
>>>>>> leaving out the necessary steps to implement the spec
>>>>>> securely?
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: Adam Barth
>>>>>> [mailto:[hidden email]] Sent: Sunday, September 09, 2012
>>>>>> 10:20 AM To: Chris Weber Cc: Larry Masinter; "Martin J. Dürst";
>>>>>> Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony
>>>>>> Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete
>>>>>> Resnick; Robin Berjon Subject: Re: 85th IETF - Working
>>>>>> Group/BOF/IRTF Scheduling - REMINDER
>>>>>>
>>>>>> Folks can be unhappy with a whitelist all they want.  A
>>>>>> blacklist isn't secure and we won't implement it.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>>>> <[hidden email]>  wrote:
>>>>>>> Thanks for the message Martin and Larry.  I will not be in
>>>>>>> Atlanta unfortunately,  I'm guessing Peter will..?  I'd be
>>>>>>> happy to schedule some design meeting time for next week
>>>>>>> after the expiring drafts have been re-submitted.
>>>>>>>
>>>>>>> As far as web+xxx, I'm still afraid that a user
>>>>>>> fingerprinting and tracking risk exists - though I didn't
>>>>>>> test the isProtocolHandlerRegistered() method for
>>>>>>> exploitability because it didn't exist, I see Safari has
>>>>>>> implemented it now and Chrome and Firefox have some active
>>>>>>> bugs for tracking.
>>>>>>>
>>>>>>> Also, I notice that some developers are not happy with the
>>>>>>> whitelist vs blacklist approach:
>>>>>>> https://github.com/jquery/standards/issues/12
>>>>>>>
>>>>>>> -Chris
>>>>>>>
>>>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>>>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in
>>>>>>>> Lyon)
>>>>>>>>
>>>>>>>> I'd like to better coordinate the IETF and W3C specs on
>>>>>>>> URLs, IRIs, etc. Doing so was my original motivation for
>>>>>>>> revising these specs in the first place. I'd like to also
>>>>>>>> see if we can make progress on "web+xxx" and (if it's still
>>>>>>>> in W3C specs) "http+aes".
>>>>>>>>
>>>>>>>> I see Chris is doing testing. Making progress on open
>>>>>>>> issues was stymied by lack of testing, so perhaps now that
>>>>>>>> we have some testing capabilities we can make more rapid
>>>>>>>> progress.
>>>>>>>>
>>>>>>>> Larry
>
> <snip/>
>
>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Adam Barth-5
On Sun, Sep 16, 2012 at 1:32 PM, Stephen Farrell
<[hidden email]> wrote:
> So I've seen a bunch of uniformly negative mail on this
> and nothing positive fwiw.

That's because the folks who are in favor of doing this aren't
participating in this discussion.

> Maybe it'd be good to get an appsarea presentation on it
> at an IETF meeting (assuming that's not happened) so the
> broader community get to know about it?
>
> I don't really know enough to be against it myself but
> it does sound like a bad security idea from the mails I've
> seen pass by so count me amongst those concerned about
> this.

I'd caution you about forming an opinion after having heard only one
side of the issue.

Adam


> On 09/14/2012 08:20 PM, Larry Masinter wrote:
>> I think we should be more careful with terminology.
>> "Whitelist" -- all values are forbidden except ones explicitly in a (fininte, enumerated) "white list", so a whitelist allows a small subset, and disallows everything in an arbitrarily large set.
>> "blacklist" -- all values are allowed except ones explicitly in a (finite, enumerated) "black list", so a blacklist disallows a small subset, and allows everything else in an arbitrarily large set.
>>
>> The pros and cons of the two approaches have to do with what is deployed and what is known to be deployed and has been evaluated as "safe to override",
>>  as well as what we imagine might be useful to allow.
>>
>> The "web+" convention is hybrid, it's not a "blacklist" and it's not really a "whitelist" either. While it's like a whitelist explicitly allows one small, enumerated, known-in-advance set (which seems pretty arbitrary and without justification), but it also allows another arbitrarily large set.
>>
>> The notion is that anything using "web+" should be, by definition, safe to override with registerProtocolHandler.
>>
>> Part of the question is whether anyone defining a web+ scheme will actually register it, or will look at the registry to determine if anyone is using it.
>> Right now, browsers (Chrome, Safari) define URI schemes and use them without any significant effort to register them. Why is there any expectation that this will change?   So the notion that the registration process can somehow enforce invariants for security reasons is suspect.
>>
>> Probably the disagreement about the the value of and venue for registration is the more important "elephant in the room".
>>
>> Larry
>>
>>
>> -----Original Message-----
>> From: "Martin J. Dürst" [mailto:[hidden email]]
>> Sent: Wednesday, September 12, 2012 9:32 PM
>> To: Peter Saint-Andre
>> Cc: Adam Barth; Larry Masinter; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; [hidden email]; John O'Conner; [hidden email]; [hidden email]; [hidden email]
>> Subject: Re: web+ and registerProtocolHandler
>>
>> On 2012/09/12 23:47, Peter Saint-Andre wrote:
>> In the context of whitelisting vs. blacklisting, the concern I have
>> with the prefixing idea is that it implicitly whitelists any URI
>> scheme that starts with the string "web+",
>>
>>> I'd buy the "implicitly whitelists" argument if there were any schemes
>>> starting with web+ now, or if there were a big chance that such schemes
>>> would be introduced independent of the purpose of "web+" (e.g. "I need a
>>> new scheme, "web+" really looks cool, I want my scheme to have that as a
>>> prefix so that I'm part of the club.").
>>
>>
>> yet the proponents of this
>> idea have not specified any criteria for review of such prefixed URI
>> schemes (or even answered the questions raised here and elsewhere
>> about whether additional review is needed for such schemes by the
>> designated experts or the IANA).
>>
>>> Having such criteria would indeed be a good thing. But I guess that in
>>> the limit, it's difficult to come up with some. ssh: quite easily
>>> provides an example. [The following is simplified and so I think it's
>>> not too difficult to poke holes in it, but I hope it shows that it's
>>> difficult to come up with any but very basic criteria.]
>>
>>> It's easy to assume that quite a bit of ssh use is security relevant. On
>>> the other hand, it's not impossible to imagine to use ssh out of a
>>> browser. I have to trust my web browser (which I have to do anyway), and
>>> I have to trust the Web application that provides the ssh facilities.
>>> But that's not much different from having to trust the ssh application
>>> that I downloaded. If I entrust a web mail service with all my email
>>> communications, I may as well entrust a trustworthy ssh Web service with
>>> all my ssh communications.
>>
>>
>>> Even for http/https, which is now blacklisted, who says that in the
>>> future we won't see browsers that are written as Web apps inside another
>>> browser? To some extent, that's a crazy idea involving lots of overheads,...
>>
>>> But proxies and things such as Amazon Silk and some of what Opera does
>>> for mobiles already essentially move part of the browsing facilities
>>> away from the client machine. Google Chrome Frame also implemented a
>>> "browser in a browser", although as a plugin.
>>
>>> Who's to say that a "browser in a browser" (implemented as a Web app)
>>> doesn't make sense? It's the browser makers that have blacklisted
>>> http/https, and maybe (just a wild guess) that's just because they think
>>> they are doing a decent-enough job so that nobody needs a "browser in a
>>> browser".
>>
>>
>>> Which brings me to another problem, and what I think is the main
>>> problem, with the "web+" prefix: When email, and mailto:, were created,
>>> who was thinking about Webmail? Of course nobody. So when the next
>>> interesting killer app for the Internet is created, who will think about
>>> doing a Web version? In many if not most cases, it will either be
>>> Web-based from the start (which means it uses http(s) and doesn't need
>>> to think about a new URI/IRI scheme or a prefix), or it will be
>>> standalone because it's way too hard and does not seem appropriate to do
>>> the same thing in a browser. So the creators of this new technology will
>>> just register a scheme without "web+". At a later date, when somebody
>>> comes up with a cool way to do the same thing over the Web, it's already
>>> way too late to add the "web+" prefix.
>>
>>> In other words, I think the problem is not with having (or not) a list
>>> of criteria, it's with being able to judge whether these criteria will
>>> apply somewhen in the future.
>>
>>
>>> Regards,    Martin.
>>
>> I agree that blacklisting doesn't scale and isn't secure. I disagree
>> that implicit whitelisting is the answer.
>>
>> Peter
>>
>> On 9/10/12 9:56 AM, Adam Barth wrote:
>>>>> It's just a practical issue.  Many folks have URI schemes
>>>>> registered on their computers that are not safe for web sites to
>>>>> hijack (i.e., register).  It's not practical to create an blacklist
>>>>> that effectively mitigates that risk.  As it happens, we not aware
>>>>> of any folks who have such registrations for URI schemes that begin
>>>>> with "web+".
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>>>>> <[hidden email]>  wrote:
>>>>>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>>>>>> archived, could someone explain why allowing registering
>>>>>> arbitrary web+xxx scheme handlers is any better than allowing
>>>>>> arbitrary (unblacklisted) xxx scheme handlers?
>>>>>>
>>>>>>
>>>>>> -----Original message-----
>>>>>>
>>>>>> From: Adam Barth<[hidden email]>  To: Larry Masinter
>>>>>> <[hidden email]>  Cc: "[hidden email]"
>>>>>> <[hidden email]>, Tony Hansen<[hidden email]>, Philippe Le
>>>>>> Hegaret<[hidden email]>, Peter Saint-Andre<[hidden email]>,
>>>>>> Adil Allawi<[hidden email]>, Robin Berjon<[hidden email]>,
>>>>>> Ted Hardie<[hidden email]>, John O'Conner
>>>>>> <[hidden email]>, Pete Resnick<[hidden email]>,
>>>>>> "Martin J. Dürst"<[hidden email]>, Chris Weber
>>>>>> <[hidden email]>  Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
>>>>>> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling -
>>>>>> REMINDER
>>>>>>
>>>>>> We should discuss further on a publicly archived mailing list.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>> On Sep 9, 2012 12:00 PM, "Larry Masinter"<[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>> Why doesn't "web+"  introduce all the same problems a blacklist
>>>>>>> approach (where everything is allowed unless explicitly
>>>>>>> disallowed) introduces? That's kind of what Chris' tests are
>>>>>>> showing.
>>>>>>>
>>>>>>> And what's the point, anyway, of a precise specification but
>>>>>>> leaving out the necessary steps to implement the spec
>>>>>>> securely?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message----- From: Adam Barth
>>>>>>> [mailto:[hidden email]] Sent: Sunday, September 09, 2012
>>>>>>> 10:20 AM To: Chris Weber Cc: Larry Masinter; "Martin J. Dürst";
>>>>>>> Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony
>>>>>>> Hansen; Ted Hardie; [hidden email]; Adil Allawi; Pete
>>>>>>> Resnick; Robin Berjon Subject: Re: 85th IETF - Working
>>>>>>> Group/BOF/IRTF Scheduling - REMINDER
>>>>>>>
>>>>>>> Folks can be unhappy with a whitelist all they want.  A
>>>>>>> blacklist isn't secure and we won't implement it.
>>>>>>>
>>>>>>> Adam
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>>>>> <[hidden email]>  wrote:
>>>>>>>> Thanks for the message Martin and Larry.  I will not be in
>>>>>>>> Atlanta unfortunately,  I'm guessing Peter will..?  I'd be
>>>>>>>> happy to schedule some design meeting time for next week
>>>>>>>> after the expiring drafts have been re-submitted.
>>>>>>>>
>>>>>>>> As far as web+xxx, I'm still afraid that a user
>>>>>>>> fingerprinting and tracking risk exists - though I didn't
>>>>>>>> test the isProtocolHandlerRegistered() method for
>>>>>>>> exploitability because it didn't exist, I see Safari has
>>>>>>>> implemented it now and Chrome and Firefox have some active
>>>>>>>> bugs for tracking.
>>>>>>>>
>>>>>>>> Also, I notice that some developers are not happy with the
>>>>>>>> whitelist vs blacklist approach:
>>>>>>>> https://github.com/jquery/standards/issues/12
>>>>>>>>
>>>>>>>> -Chris
>>>>>>>>
>>>>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>>>>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in
>>>>>>>>> Lyon)
>>>>>>>>>
>>>>>>>>> I'd like to better coordinate the IETF and W3C specs on
>>>>>>>>> URLs, IRIs, etc. Doing so was my original motivation for
>>>>>>>>> revising these specs in the first place. I'd like to also
>>>>>>>>> see if we can make progress on "web+xxx" and (if it's still
>>>>>>>>> in W3C specs) "http+aes".
>>>>>>>>>
>>>>>>>>> I see Chris is doing testing. Making progress on open
>>>>>>>>> issues was stymied by lack of testing, so perhaps now that
>>>>>>>>> we have some testing capabilities we can make more rapid
>>>>>>>>> progress.
>>>>>>>>>
>>>>>>>>> Larry
>>
>> <snip/>
>>
>>
>>>
>>>

Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Barry Leiba-2
>> So I've seen a bunch of uniformly negative mail on this
>> and nothing positive fwiw.
>
> That's because the folks who are in favor of doing this aren't
> participating in this discussion.

Indeed, so...

>> Maybe it'd be good to get an appsarea presentation on it
>> at an IETF meeting (assuming that's not happened) so the
>> broader community get to know about it?
>>
>> I don't really know enough to be against it myself but
>> it does sound like a bad security idea from the mails I've
>> seen pass by so count me amongst those concerned about
>> this.
>
> I'd caution you about forming an opinion after having heard only one
> side of the issue.

And I don't think Stephen has formed an opinion, so much as that he's
*asking*, specifically, to hear the other side.  I think a
presentation and discussion in the Apps Area meeting in Atlanta
(Monday morning, 5 Nov) would be good.  Can we make this happen?

Barry


Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Stephen Farrell


On 16 Sep 2012, at 22:20, Barry Leiba <[hidden email]> wrote:

> And I don't think Stephen has formed an opinion, so much as that he's
> *asking*, specifically, to hear the other side.  I think a
> presentation and discussion in the Apps Area meeting in Atlanta
> (Monday morning, 5 Nov) would be good.

Right.

S

>  Can we make this happen?



Reply | Threaded
Open this post in threaded view
|

Re: web+ and registerProtocolHandler

Mark Nottingham-2
In reply to this post by Adam Barth-5

On 17/09/2012, at 6:55 AM, Adam Barth <[hidden email]> wrote:

>> I don't really know enough to be against it myself but
>> it does sound like a bad security idea from the mails I've
>> seen pass by so count me amongst those concerned about
>> this.
>
> I'd caution you about forming an opinion after having heard only one
> side of the issue.

So, let's hear the other side; we're listening.

As Chris said a few days ago, it'd be helpful to see an end-to-end use case, to give some context.

--
Mark Nottingham   http://www.mnot.net/




12