Re: Service Workers meeting info

[Léonie Watson]

On 11/08/2016 11:41, Jake Archibald wrote:

Notes were taken in IRC, here's a
log https://gist.github.com/jakearchibald/c65009efa2ed9dbe3ad38f5fef5a4ef1. 
Here's
my run-down of the
headlines https://jakearchibald.com/2016/service-worker-meeting-notes/.


Thanks Jake. Both added to the WP meetings page [1].

Léonie.
[1] https://github.com/w3c/WebPlatformWG/blob/gh-pages/Meetings.md



--
@LeonieWatson tink.uk Carpe diem

Re: Service Workers meeting info

[Jake Archibald]

Notes were taken in IRC, here's a log
https://gist.github.com/jakearchibald/c65009efa2ed9dbe3ad38f5fef5a4ef1. Here's
my run-down of the headlines
https://jakearchibald.com/2016/service-worker-meeting-notes/.

On Tue, 12 Jul 2016 at 11:52 Léonie Watson  wrote:

> Hello WP,
>
> Information for the meeting on 28/29 July is here:
>
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-28-29SW.md
>
>
> If you plan to attend, it would be helpful if you could create a PR to
> add yourself to the attendees list (or let me know and I'll add you).
>
> Thanks.
> Léonie.
>
>
> It looks like the meeting info is complete on this page, except for --
> @LeonieWatson tink.uk Carpe diem
>
>

Service Workers meeting info

[Léonie Watson]

Hello WP,

Information for the meeting on 28/29 July is here:
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-28-29SW.md 



If you plan to attend, it would be helpful if you could create a PR to 
add yourself to the attendees list (or let me know and I'll add you).


Thanks.
Léonie.


It looks like the meeting info is complete on this page, except for --
@LeonieWatson tink.uk Carpe diem

Re: [Service Workers] meeting july/august?

[Ben Kelly]

On Thu, May 26, 2016 at 4:59 PM, Ben Kelly  wrote:

> On Wed, May 25, 2016 at 9:19 PM, Chaals McCathie Nevile <
> cha...@yandex-team.ru> wrote:
>
>> Hi folks,
>>
>> at the last meeting people suggested another meeting in July/August.
>> Should we be trying to schedule one?
>>
>
> We'd actually already been discussing this between the last participants.
> Our current plan is:
>
>   July 28, 29
>   Mozilla office in Toronto
>
> The w3c/webplatformwg page for the meeting should be up soon.
>

FYI, the meeting page is available here:

https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-28-29SW.md

Sorry I forgot to post the link once it went live.

Ben

Re: [Service Workers] meeting july/august?

[Ben Kelly]

On Wed, May 25, 2016 at 9:19 PM, Chaals McCathie Nevile <
cha...@yandex-team.ru> wrote:

> Hi folks,
>
> at the last meeting people suggested another meeting in July/August.
> Should we be trying to schedule one?
>

We'd actually already been discussing this between the last participants.
Our current plan is:

  July 28, 29
  Mozilla office in Toronto

The w3c/webplatformwg page for the meeting should be up soon.

The next meeting after this will likely be at TPAC.

Thanks.

Ben

[Service Workers] meeting july/august?

[Chaals McCathie Nevile]

Hi folks,

at the last meeting people suggested another meeting in July/August.  
Should we be trying to schedule one?


The Editing folks are meeting in California 29 July. Something just before  
that would be very convenient for *me*. Others of course may have  
unaccountably different schedules. But it is generally good to give 8  
weeks notice so if people need to plan travel they can.


A meeting roughly a week after 29 July also works well for me.

Thoughts?

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

[Richard Maher]

I found a very interesting, and inspiring quote today that I'd like to
share with you: -

https://twitter.com/jaffathecake
Googler. "I want the web to do everything native can, and fast."

So  can anyone here explain to me how that precludes device/user tracking?
Or how HTML5 Web Apps can not be available today with the same
functionality as Uber, Domino's, GrindR, FaceBook, tomtom?

What the hell are you waiting for?

Here's a couple more platitudes to get you through to the next F2F plenary
junket: -

https://twitter.com/jaffathecake/status/633621917547778048

"The web should look to increase its advantages while reducing its
disadvantages. Native is doing this too. If the web stops, it dies."

"The web doesn't need to be better than native at everything, it just needs
to be close enough that the gap in certain areas doesn't matter."

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

[Richard Maher]

Look I %100 acknowledge the problem(s) @martinthomson highlights, and the
need to prevent abuse from the black hats. All I’m saying is let’s work the
problem rather than simply rocking in the foetal position, or worse,
concocting artificial and exaggerated speed-humps on the release path of
much needed functionality.



On the plus side: -



1)   User permission must be granted before GPS is accessible.

2)   While GPS is being watched, even in background, the
circles/ripples icon cue is visible to user on the device.

3)   The underlying Service Worker architecture mandates the use of
secure/authenticated httpS communication.

4)   The user can be 100% sure tracking is off by simply closing
the browser on their device.



I personally think the above is enough, but for the sake of argument, does
anyone have thoughts on how access may be further governed?



1)   Only permit background/service-worker GPS access if the Web
App is installed/home-screened?

2)   If a single GPS permission will cover both background and
foreground access, then put a link on the toast to the Faustian details?

3)   Use a new icon, perhaps an eye or a doughnutted version of the
current GPS ripples? Pulse the icon?



Similar conundrums so that Service Worker GPS is not singled out unfairly: -



1)   Firefox currently continues to process watchPosition events in
background

2)   All browsers except IE and Chrome continue to watchPosition
when phone is locked but browser tab in foreground.

3)   The proposed WAKE-LOCK and CPU-LOCK will backdoor user-tracking

4)   The proposed GeoFence API, as it stands, will be another
backdoor to user tracking

5)   Native Apps can do this with impunity

6)   Push Messages must be required to trigger a notification so as
not to be silent/stealthy.

7)   Geofencing is still tracking! Knowing when my next victim
leaves their house each Tuesday is still an intrusive invasion of one’s
privacy if it has not been sanctioned. Surely the degree of “badness” is
not the issue here?



Also, can I list just the proposed restrictions on the GeoFence API that I
know about: -

1)   Maximum number of geofences

2)   Only circular geofences

3)   Maximum area of a geofence

4)   Minimum area of a geofence

5)   (Soon to be?) Cannot create a geofence in a service worker.

6)   Fat Client, heuristically-challenged, localized, geofence
processing

7)   A technology born of a time when Java was king and batteries
were the size of a brick and lasted just 2 hours.



Are these design smells not beginning to make people think twice?



Finally, to address some of Martin’s comments directly: -



> Tracking the user in the background is highly likely to be a case of a
site acting poorly.



Unsubstantiated, conjecture, hearsay, prejudice, and FUD :-(

A plethora of valid business cases and user-requirements have been
portrayed for all who are willing to see. We must find a way to satisfy
these legitimate requirements whilst fire-walling against malicious intent.



> I want to ensure that the user remains in control;



Here we are in violent agreement! See the “plus side”. How more empowered
can the user be?



Look, I enforce my right to privacy more than most, I can assure you! I am
not on FacePlant, LinkedIn, etc. I do not use my real photo on the net. I
pay cash everywhere I can, and wish I could stop my card having Tap-n-Go.
But @MulderAndScully I do not wear a tin-foil hat.



> I don't believe that asking users for permission is sufficient to that
end for some types of features. This is one of them.



Can you please give me examples of one or two other features that you felt
failed your test? How did you get on overturning the SpeechRecognition API
and access to that microphone?



The Service Worker developers must love all their children equally! Just
because the blue-eyed boy of GeoFencing turned out to be the milkman’s
mongrel doesn’t mean that your GeoLocation Cinderella can’t go to the ball.



Let’s get on with it – please.

Re: [ServiceWorker] Expose GeoLocation to workers (#745)

[Richard Maher]

@martinthomson 

I hate to make this a point of jurisdiction, but I think that this is a
discussion that needs to be had in the geolocation working group.

I've been careful to avoid any demarcation issues by always involving the
Service Worker AND GeoLocation communities. My lobbying has centered on: -

Forums:
https://github.com/slightlyoff/ServiceWorker/issues/745

https://github.com/w3c/geofencing-api/issues/25


Mailing Lists:
public-webapps@w3.org
public-geolocat...@w3.org

If there are better forums then please let me know.

Having said that, I am becoming more and more convinced that this is a
Service Worker issue. The following is what I believe is required to make
this work: -

ServiceWorkerRegistration.travelManager (getSubscription(),
permissionState(), subscribe())
The subscribe() method with take options such as (minMsecs/metersl between
position updates, accuracy, etc)

A new ServiceWorker "Travel" event will be created. The UserAgent must be
able to re-instantiate a previously terminated ServiceWorker on the
strength of this event.

One GeoLocation watcher per UserAgent sounds battery-friendly to me!

I'm very nervous when someone saves their hands when it comes to the
privacy story. The web has thus far had a great accountability story and
adding the ability to track someone when they aren't visiting your site is
one capability that could easily undermine all the good work we've done.
I'd want to see a clear plan for how a user is able to remain in control to
be even remotely comfortable that watchPosition could be exposed.

God gave us valium and SSRIs for just such occasions. Either way please
don't FUD a technical forum with tales of "There be dragons".

Users are running a WebApp and NOT "visiting your site". Permissions are
there for just such a requirement. BTW I tested Firefox last night and it
is the only browser that DOES continue to track you when the browser is in
the background.

But can I ask where have you articulated your fears about WAKE-LOCK and
CPU-LOCK back-dooring user-tracking functionality? What about the new
GeoFence API? If I throw a 5m GeoFence around my current location and get a
"leave" event then surely I can just drop that geofence and recreate
another around my new current location. What is that if not user-tracking?

Most importantly, can I stress that this is a user REQUIREMENT and not an
IMPOSITION! Ask all the permission questions you want but this simply has
to happen.

Service Workers meeting, 11-12 April in Seattle

[Chaals McCathie Nevile]

Hi all,

there will be a meeting to work on Service Workers, scheduled for 11-12  
April. Microsoft have kindly agreed to host it in Seattle (or thereabouts).


An initial webpage for the meeting is in our github repo:  
https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/11-12aprSW.md


If you hope or expect to attend, whether in person or remotely, please add  
your name to the page via a Pull Request, or ask us to do so.


cheers

Chaals - on behalf of the chairs

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
 cha...@yandex-team.ru - - - Find more at http://yandex.com

[workers]

[Khamkbounsihalath]

กูนี้หละเจ้าพ่อ Heak ker 

[service-workers] How can one use in-memory global state in Service Workers?

[Ying Le Jia]

Experts on Service Workers:

Per the spec (
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/), global 
states will be discarded in between service worker restarts. This is 
understandable, however, it makes it impossible or too difficult to 
implement some use cases.

Consider applications like e-business client, email client, chat client, 
collaborative document editor, etc. Those applications need to be able to 
support multiple user accounts (one active at a time), each having a 
separate IndexedDB database, and a dedicated secret key for data 
encryption/decryption. When handling requests, Service Workers need to 
know the current user ID and secret key - needless to say, we cannot 
persist the user's ID and secret key on disk for security reasons.

More specifically, what we need to do in the Service Worker:
1. The Service Worker receives a URL request;
2. The Service Worker looks up the requested resource in the IndexedDB 
database identified by the user ID;
3. The Service Worker uses the user's secret key to decrypt the resource;
4. The resource is returned to the client;

With SharedWorker, we can maintain in-memory global state across pages. 
However, there does not seem to be a direct way to access SharedWorker in 
Service Workers. Is there a solution for this? What are the 
recommendations?

Thanks,

Ying Le Jia (贾迎乐)
Senior Software Engineer, IBM Notes and IBM Verse
IBM China Software Development Lab (CSDL), Beijing

Tel: 86-10-82453472
E-mail: jiayi...@cn.ibm.com

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Florian Bösch]

1) Encryption between Alice and Bob by means of an asymmetric
public/private key exchange protocol cannot be secure if both also exchange
the keys and none has a method to verify the keys they got are the correct
ones. Chuck who might control the gateway over which either Alice or Bob
communicate can simply substitute his own public key for either of the two.
The whole point of certificates is that the sought out endpoint can provide
a set of credentials that're signed by a certificate authority, which is in
a chain of trust up to the root authority which is implicitly trusted.

2) You cannot obtain the benefits of UDP (out of order packages as fast as
they come) and yet retain the benefits of asymmetric public/private key
encryption schemes which rely on packages arriving in order. Attempting to
get both will result in detrimental performance or non existent security.

On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte 
wrote:

>
>
> Le 02/12/2015 13:18, Florian Bösch a écrit :
> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte  > > wrote:
> >
> > Then you should follow your rules and apply this policy to WebRTC, ie
> > allow WebRTC to work only with http.
> >
> >
> > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
> > Also WebRTC does P2P, and there's no certificates/authorities there (you
> > could encrypt, but I don't think it does even when using TCP/IP (which
> > it doesn't in case of streaming video over UDP).
>
> See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
> self-signed certifcates + a third party mechanism supposed to secure the
> connection.
>
> As a matter of fact this is almost exactly the same mechanism used by
> the Tor network, where the CERTS cells use the long term ID key of a Tor
> node to make sure that you are discussing with that one.
>
> This does not prevent of course from discussing with a malicious node
> not identified as such with valid long term ID keys, which is not a
> problem for Tor (but is a problem for WebRTC), as long as it behaves as
> expected, and if it does not, this will be detected.
>
> The above mechanism is specific to the Tor network, for other uses of
> the Tor protocol an alternative is explained here:
> https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC
>
> And again, adding a TLS layer on top of all this is of complete no use.
>
> --
> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
> Check the 10 M passwords list: http://peersm.com/findmyass
> Anti-spies and private torrents, dynamic blocklist:
> http://torrent-live.org
> Peersm : http://www.peersm.com
> torrent-live: https://github.com/Ayms/torrent-live
> node-Tor : https://www.github.com/Ayms/node-Tor
> GitHub : https://www.github.com/Ayms
>

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Richard Barnes]

On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch  wrote:

> 1) Encryption between Alice and Bob by means of an asymmetric
> public/private key exchange protocol cannot be secure if both also exchange
> the keys and none has a method to verify the keys they got are the correct
> ones. Chuck who might control the gateway over which either Alice or Bob
> communicate can simply substitute his own public key for either of the two.
> The whole point of certificates is that the sought out endpoint can provide
> a set of credentials that're signed by a certificate authority, which is in
> a chain of trust up to the root authority which is implicitly trusted.
>
> 2) You cannot obtain the benefits of UDP (out of order packages as fast as
> they come) and yet retain the benefits of asymmetric public/private key
> encryption schemes which rely on packages arriving in order. Attempting to
> get both will result in detrimental performance or non existent security.
>

I think that if you read the DTLS spec, you'll see that it handles
reordering just fine.

https://tools.ietf.org/html/rfc6347#section-3.2.2



>
> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte 
> wrote:
>
>>
>>
>> Le 02/12/2015 13:18, Florian Bösch a écrit :
>> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte > > > wrote:
>> >
>> > Then you should follow your rules and apply this policy to WebRTC,
>> ie
>> > allow WebRTC to work only with http.
>> >
>> >
>> > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
>> > Also WebRTC does P2P, and there's no certificates/authorities there (you
>> > could encrypt, but I don't think it does even when using TCP/IP (which
>> > it doesn't in case of streaming video over UDP).
>>
>> See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
>> self-signed certifcates + a third party mechanism supposed to secure the
>> connection.
>>
>> As a matter of fact this is almost exactly the same mechanism used by
>> the Tor network, where the CERTS cells use the long term ID key of a Tor
>> node to make sure that you are discussing with that one.
>>
>> This does not prevent of course from discussing with a malicious node
>> not identified as such with valid long term ID keys, which is not a
>> problem for Tor (but is a problem for WebRTC), as long as it behaves as
>> expected, and if it does not, this will be detected.
>>
>> The above mechanism is specific to the Tor network, for other uses of
>> the Tor protocol an alternative is explained here:
>> https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC
>>
>> And again, adding a TLS layer on top of all this is of complete no use.
>>
>> --
>> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>> Check the 10 M passwords list: http://peersm.com/findmyass
>> Anti-spies and private torrents, dynamic blocklist:
>> http://torrent-live.org
>> Peersm : http://www.peersm.com
>> torrent-live: https://github.com/Ayms/torrent-live
>> node-Tor  :
>> https://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>>
>
>

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Florian Bösch]

>
> In DTLS, each handshake message is assigned a specific sequence
>number within that handshake.  When a peer receives a handshake
>message, it can quickly determine whether that message is the next
>message it expects.  If it is, then it processes it.  If not, it
>queues it for future handling once all previous messages have been
>received.
>
>
The point of receiving UDP packets with fresh unqueued data is performance.
If you queue the packet for future handling, you've thrown that away, and
it begs the question, why don't you just use TCP/IP (which guarantees
ordering)...

On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes  wrote:

>
>
> On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch  wrote:
>
>> 1) Encryption between Alice and Bob by means of an asymmetric
>> public/private key exchange protocol cannot be secure if both also exchange
>> the keys and none has a method to verify the keys they got are the correct
>> ones. Chuck who might control the gateway over which either Alice or Bob
>> communicate can simply substitute his own public key for either of the two.
>> The whole point of certificates is that the sought out endpoint can provide
>> a set of credentials that're signed by a certificate authority, which is in
>> a chain of trust up to the root authority which is implicitly trusted.
>>
>> 2) You cannot obtain the benefits of UDP (out of order packages as fast
>> as they come) and yet retain the benefits of asymmetric public/private key
>> encryption schemes which rely on packages arriving in order. Attempting to
>> get both will result in detrimental performance or non existent security.
>>
>
> I think that if you read the DTLS spec, you'll see that it handles
> reordering just fine.
>
> https://tools.ietf.org/html/rfc6347#section-3.2.2
>
>
>
>>
>> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte 
>> wrote:
>>
>>>
>>>
>>> Le 02/12/2015 13:18, Florian Bösch a écrit :
>>> > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte >> > > wrote:
>>> >
>>> > Then you should follow your rules and apply this policy to WebRTC,
>>> ie
>>> > allow WebRTC to work only with http.
>>> >
>>> >
>>> > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
>>> > Also WebRTC does P2P, and there's no certificates/authorities there
>>> (you
>>> > could encrypt, but I don't think it does even when using TCP/IP (which
>>> > it doesn't in case of streaming video over UDP).
>>>
>>> See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
>>> self-signed certifcates + a third party mechanism supposed to secure the
>>> connection.
>>>
>>> As a matter of fact this is almost exactly the same mechanism used by
>>> the Tor network, where the CERTS cells use the long term ID key of a Tor
>>> node to make sure that you are discussing with that one.
>>>
>>> This does not prevent of course from discussing with a malicious node
>>> not identified as such with valid long term ID keys, which is not a
>>> problem for Tor (but is a problem for WebRTC), as long as it behaves as
>>> expected, and if it does not, this will be detected.
>>>
>>> The above mechanism is specific to the Tor network, for other uses of
>>> the Tor protocol an alternative is explained here:
>>> https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC
>>>
>>> And again, adding a TLS layer on top of all this is of complete no use.
>>>
>>> --
>>> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>>> Check the 10 M passwords list: http://peersm.com/findmyass
>>> Anti-spies and private torrents, dynamic blocklist:
>>> http://torrent-live.org
>>> Peersm : http://www.peersm.com
>>> torrent-live: https://github.com/Ayms/torrent-live
>>> node-Tor  :
>>> https://www.github.com/Ayms/node-Tor
>>> GitHub : https://www.github.com/Ayms
>>>
>>
>>
>

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Richard Barnes]

On Wed, Dec 2, 2015 at 10:01 AM, Florian Bösch  wrote:

> In DTLS, each handshake message is assigned a specific sequence
>>number within that handshake.  When a peer receives a handshake
>>message, it can quickly determine whether that message is the next
>>message it expects.  If it is, then it processes it.  If not, it
>>queues it for future handling once all previous messages have been
>>received.
>>
>>
> The point of receiving UDP packets with fresh unqueued data is
> performance. If you queue the packet for future handling, you've thrown
> that away, and it begs the question, why don't you just use TCP/IP (which
> guarantees ordering)...
>

Because the queuing is only done for handshake messages, which are a tiny
fraction of all the messages sent in a typical DTLS session.  Other
messages can be reordered, dropped, etc.



>
> On Wed, Dec 2, 2015 at 3:54 PM, Richard Barnes 
> wrote:
>
>>
>>
>> On Wed, Dec 2, 2015 at 9:36 AM, Florian Bösch  wrote:
>>
>>> 1) Encryption between Alice and Bob by means of an asymmetric
>>> public/private key exchange protocol cannot be secure if both also exchange
>>> the keys and none has a method to verify the keys they got are the correct
>>> ones. Chuck who might control the gateway over which either Alice or Bob
>>> communicate can simply substitute his own public key for either of the two.
>>> The whole point of certificates is that the sought out endpoint can provide
>>> a set of credentials that're signed by a certificate authority, which is in
>>> a chain of trust up to the root authority which is implicitly trusted.
>>>
>>> 2) You cannot obtain the benefits of UDP (out of order packages as fast
>>> as they come) and yet retain the benefits of asymmetric public/private key
>>> encryption schemes which rely on packages arriving in order. Attempting to
>>> get both will result in detrimental performance or non existent security.
>>>
>>
>> I think that if you read the DTLS spec, you'll see that it handles
>> reordering just fine.
>>
>> https://tools.ietf.org/html/rfc6347#section-3.2.2
>>
>>
>>
>>>
>>> On Wed, Dec 2, 2015 at 2:05 PM, Aymeric Vitte 
>>> wrote:
>>>


 Le 02/12/2015 13:18, Florian Bösch a écrit :
 > On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte <
 vitteayme...@gmail.com
 > > wrote:
 >
 > Then you should follow your rules and apply this policy to
 WebRTC, ie
 > allow WebRTC to work only with http.
 >
 >
 > Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
 > Also WebRTC does P2P, and there's no certificates/authorities there
 (you
 > could encrypt, but I don't think it does even when using TCP/IP (which
 > it doesn't in case of streaming video over UDP).

 See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
 self-signed certifcates + a third party mechanism supposed to secure the
 connection.

 As a matter of fact this is almost exactly the same mechanism used by
 the Tor network, where the CERTS cells use the long term ID key of a Tor
 node to make sure that you are discussing with that one.

 This does not prevent of course from discussing with a malicious node
 not identified as such with valid long term ID keys, which is not a
 problem for Tor (but is a problem for WebRTC), as long as it behaves as
 expected, and if it does not, this will be detected.

 The above mechanism is specific to the Tor network, for other uses of
 the Tor protocol an alternative is explained here:
 https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC

 And again, adding a TLS layer on top of all this is of complete no use.

 --
 Get the torrent dynamic blocklist: http://peersm.com/getblocklist
 Check the 10 M passwords list: http://peersm.com/findmyass
 Anti-spies and private torrents, dynamic blocklist:
 http://torrent-live.org
 Peersm : http://www.peersm.com
 torrent-live: https://github.com/Ayms/torrent-live
 node-Tor  :
 https://www.github.com/Ayms/node-Tor
 GitHub : https://www.github.com/Ayms

>>>
>>>
>>
>

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

Le 01/12/2015 20:41, Brad Hill a écrit :
>> As far as I see it, a "mixed content" has the word "content", which is
> supposed to designate something that can be included in a web page and
> therefore be dangerous.
> 
> "Mixed Content" (and "mixed content blocking") is a term of art that has
> been in use for many years in the browser community.  As such, you are
> correct that it is a bit inadequate in that it's coinage predates the
> widespread use of AJAX-type patterns, but we felt that it was better to
> continue to use and refine a well-known term than to introduce a new
> term. Apologies if this has created any confusion.
> 
> More than just "content", the question boils down to "what does seeing
> the lock promise the user?"  Browsers interpret the lock as a promise to
> the user that the web page / application they are currently interacting
> with is safe according to the threat model of TLS.  That is to say, it
> is protected end-to-end on the network path against attempts to
> impersonate, eavesdrop or modify traffic.  In a modern browser, this
> includes not just fetches of images and script done declaratively in
> HTML, but any kind of potentially insecure network communication.
> 

Then you should follow your rules and apply this policy to WebRTC, ie
allow WebRTC to work only with http.

> In general, we've seen this kind of argument before for building secure
> protocols at layer 7 on top of insecure transports - notably Netflix's
> "Message Security Layer".  Thus far, no browser vendors have been
> convinced that these are good ideas, that there is a way to safely allow
> their use in TLS-protected contexts, or that building these systems with
> existing TLS primitives is not an adequate solution.

Netflix's MSL doc is not clear and just mentions an issue with http (not
ws) inside https, probably they have the very same problem with non
valid certificates.

Browser vendors are convinced that http with ws is better than https
with ws...

Could you please provide an example of serious issue regarding https
with ws?

> 
> In specific, I don't think you'll ever find support for treating Tor
> traffic that is subject to interception and modification after it leaves
> an exit node as equivalent to HTTPS

??? Do you really know the Tor protocol?

And where did you see this in the use cases (something that exits)?

If something has to exit Tor it's obvious that https must be used, the
exit node is by design a potential mitm.

But https inside the Tor protocol.

Using wss to send the Tor traffic does not change anything to this
situation.

This contradiction that you highlight here just shows again that the
current rules are not logical.

, especially since we know there are
> active attacks being mounted against this traffic on a regular basis.
>  (This is why I suggested .onion sites as potentially secure contexts,
> which do not suffer from the same exposure outside of the Tor network.)

Same as above, that's the third or fourth time in this thread that I am
talked about the fb hidden service and its .onion certificate, supposed
to improve some security while it does not (or a very little in case fb
hidden service is not located with the Tor server, but that's more a fb
configuration issue)

That's another proof that https does not improve anything here.

While browsing hidden services could be a use case in the future (once
the "browsing paradox" is solved), I am not talking about this for now,
I am talking about using the Tor protocol or another secure protocole
for multiple services.


> 
> -Brad
> 
> On Tue, Dec 1, 2015 at 5:42 AM Aymeric Vitte  > wrote:
> 
> 
> 
> Le 01/12/2015 05:31, Brad Hill a écrit :
> > Let's keep this discussion civil, please.
> 
> Maybe some wording was a little tough below, apologies for this, the
> logjam attack is difficult to swallow, how something that is supposed to
> protect forward secrecy can do quietly the very contrary without even
> having the keys compromised, it's difficult to understand too why TLS
> did not implement a mechanism to protect the DH client public key.
> 
> >
> > The reasons behind blocking of non-secure WebSocket connections from
> > secure contexts are laid out in the following document:
> >
> > http://www.w3.org/TR/mixed-content/
> >
> > A plaintext ws:// connection does not meet the requirements of
> > authentication, encryption and integrity, so far as the user agent is
> > able to tell, so it cannot allow it.
> 
> The spec just mentions to align the behavior of ws to xhr, fetch and
> eventsource without giving more reasons, or I missed them.
> 
> Let's concentrate on ws here.
> 
> As far as I see it, a "mixed content" has the word "content", which is
> supposed to designate something that can be included in a web page and
> therefore be dangerous.
> 
> WS cannot include anything in a 

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Florian Bösch]

On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte 
wrote:
>
> Then you should follow your rules and apply this policy to WebRTC, ie
> allow WebRTC to work only with http.
>

Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP. Also
WebRTC does P2P, and there's no certificates/authorities there (you could
encrypt, but I don't think it does even when using TCP/IP (which it doesn't
in case of streaming video over UDP).

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

Le 02/12/2015 13:18, Florian Bösch a écrit :
> On Wed, Dec 2, 2015 at 12:50 PM, Aymeric Vitte  > wrote:
> 
> Then you should follow your rules and apply this policy to WebRTC, ie
> allow WebRTC to work only with http.
> 
> 
> Just as a sidenote, WebRTC also does UDP and there's no TLS over UDP.
> Also WebRTC does P2P, and there's no certificates/authorities there (you
> could encrypt, but I don't think it does even when using TCP/IP (which
> it doesn't in case of streaming video over UDP).

See https://github.com/Ayms/node-Tor#security, WebRTC uses DTLS with
self-signed certifcates + a third party mechanism supposed to secure the
connection.

As a matter of fact this is almost exactly the same mechanism used by
the Tor network, where the CERTS cells use the long term ID key of a Tor
node to make sure that you are discussing with that one.

This does not prevent of course from discussing with a malicious node
not identified as such with valid long term ID keys, which is not a
problem for Tor (but is a problem for WebRTC), as long as it behaves as
expected, and if it does not, this will be detected.

The above mechanism is specific to the Tor network, for other uses of
the Tor protocol an alternative is explained here:
https://github.com/Ayms/node-Tor#pieces-and-sliding-window for WebRTC

And again, adding a TLS layer on top of all this is of complete no use.

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Brad Hill]

> As far as I see it, a "mixed content" has the word "content", which is
supposed to designate something that can be included in a web page and
therefore be dangerous.

"Mixed Content" (and "mixed content blocking") is a term of art that has
been in use for many years in the browser community.  As such, you are
correct that it is a bit inadequate in that it's coinage predates the
widespread use of AJAX-type patterns, but we felt that it was better to
continue to use and refine a well-known term than to introduce a new term.
Apologies if this has created any confusion.

More than just "content", the question boils down to "what does seeing the
lock promise the user?"  Browsers interpret the lock as a promise to the
user that the web page / application they are currently interacting with is
safe according to the threat model of TLS.  That is to say, it is protected
end-to-end on the network path against attempts to impersonate, eavesdrop
or modify traffic.  In a modern browser, this includes not just fetches of
images and script done declaratively in HTML, but any kind of potentially
insecure network communication.

In general, we've seen this kind of argument before for building secure
protocols at layer 7 on top of insecure transports - notably Netflix's
"Message Security Layer".  Thus far, no browser vendors have been convinced
that these are good ideas, that there is a way to safely allow their use in
TLS-protected contexts, or that building these systems with existing TLS
primitives is not an adequate solution.

In specific, I don't think you'll ever find support for treating Tor
traffic that is subject to interception and modification after it leaves an
exit node as equivalent to HTTPS, especially since we know there are active
attacks being mounted against this traffic on a regular basis.  (This is
why I suggested .onion sites as potentially secure contexts, which do not
suffer from the same exposure outside of the Tor network.)

-Brad

On Tue, Dec 1, 2015 at 5:42 AM Aymeric Vitte  wrote:

>
>
> Le 01/12/2015 05:31, Brad Hill a écrit :
> > Let's keep this discussion civil, please.
>
> Maybe some wording was a little tough below, apologies for this, the
> logjam attack is difficult to swallow, how something that is supposed to
> protect forward secrecy can do quietly the very contrary without even
> having the keys compromised, it's difficult to understand too why TLS
> did not implement a mechanism to protect the DH client public key.
>
> >
> > The reasons behind blocking of non-secure WebSocket connections from
> > secure contexts are laid out in the following document:
> >
> > http://www.w3.org/TR/mixed-content/
> >
> > A plaintext ws:// connection does not meet the requirements of
> > authentication, encryption and integrity, so far as the user agent is
> > able to tell, so it cannot allow it.
>
> The spec just mentions to align the behavior of ws to xhr, fetch and
> eventsource without giving more reasons, or I missed them.
>
> Let's concentrate on ws here.
>
> As far as I see it, a "mixed content" has the word "content", which is
> supposed to designate something that can be included in a web page and
> therefore be dangerous.
>
> WS cannot include anything in a page by itself, it is designed to
> discuss with external entities, for other purposes than fetching
> resources (images, js, etc) from web servers that are logically tied to
> a domain, in that case you can use xhr or other fetching means instead.
>
> Therefore it is logical to envision that those external entities used
> with WS are not necessarily web servers and might not have valid
> certificates.
>
> WS cannot hurt anything unless the application decides to insert the
> results in the page, which is not something problematic with WS only,
> the application is loaded via https, so is supposed to be secure but if
> it is doing wrong things nothing can save you, even wss.
>
> Unlike usual fetching means, in case of malicious use WS cannot really
> hurt like scaning URLs, this is a specific protocol not talked by anybody.
>
> As a result of the current policy, if we want to establish WS with
> entities that can't have a valid certificate, we must load the code via
> http which is obviously completely insecure.
>
> So forbiding WS with https is just putting the users at risk and prevent
> any current or future uses of ws with entities that can't have a valid
> certificate, therefore reducing the interest and potential of ws to
> something very small.
>
>
> >
> > If there is a plausible mechanism by which browsers could distinguish
> > external communications which meet the necessary security criteria using
> > protocols other than TLS or authentication other than from the Web PKI,
> > there is a reasonable case to be made that such could be considered as
> > potentially secure origins and URLs.  (as has been done to some extent
> > for WebRTC, as you have already noted)
> >
>
> To some extent yes... maybe some 

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

Le 01/12/2015 05:31, Brad Hill a écrit :
> Let's keep this discussion civil, please.  

Maybe some wording was a little tough below, apologies for this, the
logjam attack is difficult to swallow, how something that is supposed to
protect forward secrecy can do quietly the very contrary without even
having the keys compromised, it's difficult to understand too why TLS
did not implement a mechanism to protect the DH client public key.

> 
> The reasons behind blocking of non-secure WebSocket connections from
> secure contexts are laid out in the following document:
> 
> http://www.w3.org/TR/mixed-content/
> 
> A plaintext ws:// connection does not meet the requirements of
> authentication, encryption and integrity, so far as the user agent is
> able to tell, so it cannot allow it.  

The spec just mentions to align the behavior of ws to xhr, fetch and
eventsource without giving more reasons, or I missed them.

Let's concentrate on ws here.

As far as I see it, a "mixed content" has the word "content", which is
supposed to designate something that can be included in a web page and
therefore be dangerous.

WS cannot include anything in a page by itself, it is designed to
discuss with external entities, for other purposes than fetching
resources (images, js, etc) from web servers that are logically tied to
a domain, in that case you can use xhr or other fetching means instead.

Therefore it is logical to envision that those external entities used
with WS are not necessarily web servers and might not have valid
certificates.

WS cannot hurt anything unless the application decides to insert the
results in the page, which is not something problematic with WS only,
the application is loaded via https, so is supposed to be secure but if
it is doing wrong things nothing can save you, even wss.

Unlike usual fetching means, in case of malicious use WS cannot really
hurt like scaning URLs, this is a specific protocol not talked by anybody.

As a result of the current policy, if we want to establish WS with
entities that can't have a valid certificate, we must load the code via
http which is obviously completely insecure.

So forbiding WS with https is just putting the users at risk and prevent
any current or future uses of ws with entities that can't have a valid
certificate, therefore reducing the interest and potential of ws to
something very small.


> 
> If there is a plausible mechanism by which browsers could distinguish
> external communications which meet the necessary security criteria using
> protocols other than TLS or authentication other than from the Web PKI,
> there is a reasonable case to be made that such could be considered as
> potentially secure origins and URLs.  (as has been done to some extent
> for WebRTC, as you have already noted)
> 

To some extent yes... maybe some other solutions could be studied via
something like letsencrypt to get automatically something like temporary
valid certificates (which then might eliminate the main topic of this
discussion if feasible)


> If you want to continue this discussion here, please:
> 
> 1) State your use cases clearly for those on this list who do not
> already know them.  You want to "use the Tor protocol" over websockets? 

Note: I am not affiliated at all to the Tor project

Yes, that's already a reality with projects such as Peersm and Flashproxy.

Peersm has the onion proxy function inside browsers which establishes
Tor circuits with Tor nodes using WS.

Flashproxy connects a censored Tor user to a Tor node and relays the Tor
protocol using WS between both.

> To connect to what?  Why? 

The Tor protocol is just an example, let's see it as another secure
protocol.

If we go further, we can imagine what I described here:
https://mailman.stanford.edu/pipermail/liberationtech/2015-November/015680.html

Which mentions the "browsing paradox" too.

Not usual I believe (last paragraph, the idea is not to proxy only to
URLs as it is today but to proxy to interfaces, such as ws,xhr and
WebRTC), but this will happen one day (maybe I should patent this too...)

Applications are numerous and not restricted to those examples.

 Why is it important to bootstrap an
> application like this over regular http(s) instead of, for example, as
> an extension or modified user-agent like TBB?

The Tor Browser is designed for secure browsing, because for example
solving the "browsing paradox" and having the onion proxy inside
browsers is not enough to insure secure anonymous browsing, Tor
Browser's features will still be required.

Some applications need some modifications of the browser, some others
need extensions but plenty of applications could be installed from the
web sites directly.

The obvious advantages are: no installation, works on any
device/platform, no dev/maintenance of the application for different
platforms with the associated risks (sw integrity) and complexity for
the users (not talking here about the problematic aspect of code loading
for a web 

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

Not sure that you know what you are talking about here, maybe influenced
by fb's onion things, or you misunderstood what I wrote.

I am not talking about the Tor network, neither the Hidden services, I
am talking about the Tor protocol itself, that's different and it is
known to be strong, but this is just an example, let's see it as another
secure protocol to connect browsers to other entities that can not have
valid certificates for obvious reasons.

Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
is resistant to the logjam trivial DH_export quasi undetectable
downgrade attack that nobody anticipated during years, on purpose or
not, I don't know, but that's obvious that the DH client public key for
TLS could have been protected by the public key of the server, like the
Tor protocol is doing, so maybe you should refrain your compliments
about TLS.

And the Tor protocol have TLS on top of it, so below the right sequence
is ws + TLS + Tor protocol.

And it checks that the one you are connected to is the one with whom you
have established the TLS connection (who can be a MITM again, but you
don't care, you just want to be sure with whom you are discussing with,
like what WebRTC is trying to do)

But again, that's not really the subject of the discussion, the subject
is what is really the problem of letting an interface that has access to
nothing (WS) work with https? Knowing that you can use it with another
protocol that you can estimate better, but could be worse, again what
does it hurt?

Or just deprecate ws because if it has to work only with entities that
own valid certificates, then it's of quasi no use for the future.

Le 30/11/2015 21:00, Brad Hill a écrit :
> I don't think there is universal agreement among browser engineers (if
> anyone agrees at all) with your assertion that the Tor protocol or even
> Tor hidden services are "more secure than TLS".  TLS in modern browsers
> requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> key confidentiality and SHA-256 or better integrity.If .onion
> identifiers and the Tor protocol crypto were at this level of strength,
> it would be reasonable to argue that a .onion connection represented a
> "secure context", and proceed from there.  In the meantime, with .onion
> site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> a 1024 bit key, I don't think you'll get much traction in insisting it
> is equivalent to or better than TLS.
> 
> On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte <vitteayme...@gmail.com
> <mailto:vitteayme...@gmail.com>> wrote:
> 
> Redirecting this to WebApps since it's probable that we are facing a
> design mistake that might amplify by deprecating non TLS connections. I
> have submitted the case to all possible lists in the past, never got a
> clear answer and was each time redirected to another list (ccing
> webappsec but as a whole I think that's a webapp matter, so please don't
> state only that "downgrading a secure connection to an insecure one is
> insecure").
> 
> The case described below is simple:
> 
> 1- https page loading the code, the code establishes ws + the Tor
> protocol to "someone" (who can be a MITM or whatever, we don't care as
> explained below)
> 
> 2- http page loading the code, the code establishes ws + the Tor
> protocol
> 
> 3- https page loading the code, the code establishes wss + the Tor
> protocol
> 
> 4- https page loading the code, the code establishes normal wss
> connections
> 
> 3 fails because the WS servers have self-signed certificates.
> 
> What is insecure between 1 and 2? Obviously this is 2, because loading
> the code via http.
> 
> Even more, 1 is more secure than 4, because the Tor protocol is more
> secure than TLS.
> 
> It's already a reality that projects are using something like 1 and will
> continue to build systems on the same principles (one can't argue that
> such systems are unsecure or unlikely to happen, that's not true, see
>     the Flashproxy project too).
> 
> But 1 fails too, because ws is not allowed inside a https page, so we
> must use 2, which is insecure and 2 might not work any longer later.
> 
> Service Workers are doing about the same, https must be used, as far as
> I understand Service Workers can run any browser instance in background
> even if the spec seems to focus more on the offline aspects, so I
> suppose that having 1 inside a (background) Service Worker will fail
> too.
> 
> Now we have the "new" "progressive Web Apps" which surprisingly present
> as a revolution the possibility to have a web app look like a n

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Richard Barnes]

On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte <vitteayme...@gmail.com>
wrote:

> Not sure that you know what you are talking about here, maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
>
> I am not talking about the Tor network, neither the Hidden services, I
> am talking about the Tor protocol itself, that's different and it is
> known to be strong, but this is just an example, let's see it as another
> secure protocol to connect browsers to other entities that can not have
> valid certificates for obvious reasons.
>

HTTPS gives you the following essential properties:
1. Authentication: You know that you're talking to who you think you're
talking to.
2. Confidentiality: Nobody else can see what you're saying
3. Integrity: Nobody else can interfere with your communications

Show me another protocol that achieves those properties, and maybe we'll
have something to talk about.  Tor doesn't.

--Richard


Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on purpose or
> not, I don't know, but that's obvious that the DH client public key for
> TLS could have been protected by the public key of the server, like the
> Tor protocol is doing, so maybe you should refrain your compliments
> about TLS.
>
> And the Tor protocol have TLS on top of it, so below the right sequence
> is ws + TLS + Tor protocol.
>
> And it checks that the one you are connected to is the one with whom you
> have established the TLS connection (who can be a MITM again, but you
> don't care, you just want to be sure with whom you are discussing with,
> like what WebRTC is trying to do)
>
> But again, that's not really the subject of the discussion, the subject
> is what is really the problem of letting an interface that has access to
> nothing (WS) work with https? Knowing that you can use it with another
> protocol that you can estimate better, but could be worse, again what
> does it hurt?
>
> Or just deprecate ws because if it has to work only with entities that
> own valid certificates, then it's of quasi no use for the future.
>
> Le 30/11/2015 21:00, Brad Hill a écrit :
> > I don't think there is universal agreement among browser engineers (if
> > anyone agrees at all) with your assertion that the Tor protocol or even
> > Tor hidden services are "more secure than TLS".  TLS in modern browsers
> > requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> > key confidentiality and SHA-256 or better integrity.If .onion
> > identifiers and the Tor protocol crypto were at this level of strength,
> > it would be reasonable to argue that a .onion connection represented a
> > "secure context", and proceed from there.  In the meantime, with .onion
> > site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> > a 1024 bit key, I don't think you'll get much traction in insisting it
> > is equivalent to or better than TLS.
> >
> > On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte <vitteayme...@gmail.com
> > <mailto:vitteayme...@gmail.com>> wrote:
> >
> > Redirecting this to WebApps since it's probable that we are facing a
> > design mistake that might amplify by deprecating non TLS
> connections. I
> > have submitted the case to all possible lists in the past, never got
> a
> > clear answer and was each time redirected to another list (ccing
> > webappsec but as a whole I think that's a webapp matter, so please
> don't
> > state only that "downgrading a secure connection to an insecure one
> is
> > insecure").
> >
> > The case described below is simple:
> >
> > 1- https page loading the code, the code establishes ws + the Tor
> > protocol to "someone" (who can be a MITM or whatever, we don't care
> as
> > explained below)
> >
> > 2- http page loading the code, the code establishes ws + the Tor
> > protocol
> >
> > 3- https page loading the code, the code establishes wss + the Tor
> > protocol
> >
> > 4- https page loading the code, the code establishes normal wss
> > connections
> >
> > 3 fails because the WS servers have self-signed certificates.
> >
> > What is insecure between 1 and 2? Obviously this is 2, because
> loading
> > the code via http.
> >
> > Even more, 1 is more secure than 4, because the Tor protocol is more
> > secure than TLS.
> >
> >     It's already a reality that projects are using som

WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

Redirecting this to WebApps since it's probable that we are facing a
design mistake that might amplify by deprecating non TLS connections. I
have submitted the case to all possible lists in the past, never got a
clear answer and was each time redirected to another list (ccing
webappsec but as a whole I think that's a webapp matter, so please don't
state only that "downgrading a secure connection to an insecure one is
insecure").

The case described below is simple:

1- https page loading the code, the code establishes ws + the Tor
protocol to "someone" (who can be a MITM or whatever, we don't care as
explained below)

2- http page loading the code, the code establishes ws + the Tor protocol

3- https page loading the code, the code establishes wss + the Tor protocol

4- https page loading the code, the code establishes normal wss connections

3 fails because the WS servers have self-signed certificates.

What is insecure between 1 and 2? Obviously this is 2, because loading
the code via http.

Even more, 1 is more secure than 4, because the Tor protocol is more
secure than TLS.

It's already a reality that projects are using something like 1 and will
continue to build systems on the same principles (one can't argue that
such systems are unsecure or unlikely to happen, that's not true, see
the Flashproxy project too).

But 1 fails too, because ws is not allowed inside a https page, so we
must use 2, which is insecure and 2 might not work any longer later.

Service Workers are doing about the same, https must be used, as far as
I understand Service Workers can run any browser instance in background
even if the spec seems to focus more on the offline aspects, so I
suppose that having 1 inside a (background) Service Worker will fail too.

Now we have the "new" "progressive Web Apps" which surprisingly present
as a revolution the possibility to have a web app look like a native app
while it can be done on iOS since the begining, same thing for some
offline caching features that were possible before, but this indeed
brings new things, hopefully we can have one day something like all the
cordova features inside browsers + background/headless browser instances.

So we are talking about web apps here, not about a web page loading
plenty of http/https stuff, web apps that can be used as
independant/native apps or nodes to relay traffic and therefore discuss
with some entities that can't be tied to a domain and can only use
self-signed certificates (like WebRTC peers, why do we have a security
exception here allowing something for WebRTC and not for this case?).

Then 1 must be possible with WS and Service Workers, because there are
no reasons why it should not be allowed and this will happen in the
future under different forms (see the link below), that's not illogical,
if you use wss then you expect it to work as such (ie fail with
self-signed certificates for example), if you use ws (what terrible
things can happen with ws exactly? ws can't access the DOM or whatever)
then you are on your own and should better know what you are doing,
that's not a reason to force you to use much more insecure 2.

Such apps can be loaded while navigating on a web site, entirely (ie the
web site is the app), or for more wide distribution from different sites
than the original app site via an iframe (very ugly way) or extracted as
a component (cool way, does not seem to be foreseen by anybody) with
user prompt/validation ("do you want to install application X?")
possibly running in background when needed in a sandboxed context with
service workers.

Le 25/11/2015 17:43, Aymeric Vitte a écrit :
> 
> 
> Le 20/11/2015 12:35, Richard Barnes a écrit :
>> On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck <ha...@hboeck.de> wrote:
>>
>>>> It's amazing how the same wrong arguments get repeated again and
>>>> again...
>>>>
>> +1000
>>
>> All of these points have been raised and rebutted several times.  My
>> favorite reference is:
>>
>> https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay
>>
>>
>>
> 
> You might not break the current internet but its future.
> 
> Example: https://bugzilla.mozilla.org/show_bug.cgi?id=917829
> 
> How do you intend to solve this? ie the case of an entity that just
> cannot have valid certificates and/or implements a secure protocol on
> top of an insecure one (ws here for Peersm project, the other party can
> be by design a "MITM" but we completely don't care per the secure
> protocol used, the MITM will not know what happens next)?
> 
> Like WebRTC too, but there is an exception for that one, self-signed
> certificates are (by some luck) accepted.
> 
> It's obvious that browsers will be used for new services involving those
> mechanisms in the future, like P2P systems as sket

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Brad Hill]

I don't think there is universal agreement among browser engineers (if
anyone agrees at all) with your assertion that the Tor protocol or even Tor
hidden services are "more secure than TLS".  TLS in modern browsers
requires RSA 2048-bit or equivalent authentication, 128-bit symmetric key
confidentiality and SHA-256 or better integrity.If .onion identifiers
and the Tor protocol crypto were at this level of strength, it would be
reasonable to argue that a .onion connection represented a "secure
context", and proceed from there.  In the meantime, with .onion site
security (without TLS) at 80-bits of truncation of a SHA-1 hash of a 1024
bit key, I don't think you'll get much traction in insisting it is
equivalent to or better than TLS.

On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte <vitteayme...@gmail.com>
wrote:

> Redirecting this to WebApps since it's probable that we are facing a
> design mistake that might amplify by deprecating non TLS connections. I
> have submitted the case to all possible lists in the past, never got a
> clear answer and was each time redirected to another list (ccing
> webappsec but as a whole I think that's a webapp matter, so please don't
> state only that "downgrading a secure connection to an insecure one is
> insecure").
>
> The case described below is simple:
>
> 1- https page loading the code, the code establishes ws + the Tor
> protocol to "someone" (who can be a MITM or whatever, we don't care as
> explained below)
>
> 2- http page loading the code, the code establishes ws + the Tor protocol
>
> 3- https page loading the code, the code establishes wss + the Tor protocol
>
> 4- https page loading the code, the code establishes normal wss connections
>
> 3 fails because the WS servers have self-signed certificates.
>
> What is insecure between 1 and 2? Obviously this is 2, because loading
> the code via http.
>
> Even more, 1 is more secure than 4, because the Tor protocol is more
> secure than TLS.
>
> It's already a reality that projects are using something like 1 and will
> continue to build systems on the same principles (one can't argue that
> such systems are unsecure or unlikely to happen, that's not true, see
> the Flashproxy project too).
>
> But 1 fails too, because ws is not allowed inside a https page, so we
> must use 2, which is insecure and 2 might not work any longer later.
>
> Service Workers are doing about the same, https must be used, as far as
> I understand Service Workers can run any browser instance in background
> even if the spec seems to focus more on the offline aspects, so I
> suppose that having 1 inside a (background) Service Worker will fail too.
>
> Now we have the "new" "progressive Web Apps" which surprisingly present
> as a revolution the possibility to have a web app look like a native app
> while it can be done on iOS since the begining, same thing for some
> offline caching features that were possible before, but this indeed
> brings new things, hopefully we can have one day something like all the
> cordova features inside browsers + background/headless browser instances.
>
> So we are talking about web apps here, not about a web page loading
> plenty of http/https stuff, web apps that can be used as
> independant/native apps or nodes to relay traffic and therefore discuss
> with some entities that can't be tied to a domain and can only use
> self-signed certificates (like WebRTC peers, why do we have a security
> exception here allowing something for WebRTC and not for this case?).
>
> Then 1 must be possible with WS and Service Workers, because there are
> no reasons why it should not be allowed and this will happen in the
> future under different forms (see the link below), that's not illogical,
> if you use wss then you expect it to work as such (ie fail with
> self-signed certificates for example), if you use ws (what terrible
> things can happen with ws exactly? ws can't access the DOM or whatever)
> then you are on your own and should better know what you are doing,
> that's not a reason to force you to use much more insecure 2.
>
> Such apps can be loaded while navigating on a web site, entirely (ie the
> web site is the app), or for more wide distribution from different sites
> than the original app site via an iframe (very ugly way) or extracted as
> a component (cool way, does not seem to be foreseen by anybody) with
> user prompt/validation ("do you want to install application X?")
> possibly running in background when needed in a sandboxed context with
> service workers.
>
> Le 25/11/2015 17:43, Aymeric Vitte a écrit :
> >
> >
> > Le 20/11/2015 12:35, Richard Barnes a écrit :
> >> On Thu, Nov 19, 2015 at 

RE: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Crispin Cowan]

“Secure against which threats?” is the question. TLS, with its stronger crypto, 
is more secure against an adversary that wants to read the content of your 
messages. ToR is more secure against an adversary that wants to detect that you 
visit a particular site, are associated with particular social media content, 
and get your real IP address to hunt you down. They are dramatically different 
adversaries, and different victim profiles, so comparing which is “more secure” 
is meaningless.

From: Brad Hill [mailto:hillb...@gmail.com]
Sent: Monday, November 30, 2015 12:01 PM
To: Aymeric Vitte <vitteayme...@gmail.com>; Web Applications Working Group WG 
(public-webapps@w3.org) <public-webapps@w3.org>
Cc: public-webapp...@w3.org
Subject: Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just 
fine]

I don't think there is universal agreement among browser engineers (if anyone 
agrees at all) with your assertion that the Tor protocol or even Tor hidden 
services are "more secure than TLS".  TLS in modern browsers requires RSA 
2048-bit or equivalent authentication, 128-bit symmetric key confidentiality 
and SHA-256 or better integrity.If .onion identifiers and the Tor protocol 
crypto were at this level of strength, it would be reasonable to argue that a 
.onion connection represented a "secure context", and proceed from there.  In 
the meantime, with .onion site security (without TLS) at 80-bits of truncation 
of a SHA-1 hash of a 1024 bit key, I don't think you'll get much traction in 
insisting it is equivalent to or better than TLS.

On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte 
<vitteayme...@gmail.com<mailto:vitteayme...@gmail.com>> wrote:
Redirecting this to WebApps since it's probable that we are facing a
design mistake that might amplify by deprecating non TLS connections. I
have submitted the case to all possible lists in the past, never got a
clear answer and was each time redirected to another list (ccing
webappsec but as a whole I think that's a webapp matter, so please don't
state only that "downgrading a secure connection to an insecure one is
insecure").

The case described below is simple:

1- https page loading the code, the code establishes ws + the Tor
protocol to "someone" (who can be a MITM or whatever, we don't care as
explained below)

2- http page loading the code, the code establishes ws + the Tor protocol

3- https page loading the code, the code establishes wss + the Tor protocol

4- https page loading the code, the code establishes normal wss connections

3 fails because the WS servers have self-signed certificates.

What is insecure between 1 and 2? Obviously this is 2, because loading
the code via http.

Even more, 1 is more secure than 4, because the Tor protocol is more
secure than TLS.

It's already a reality that projects are using something like 1 and will
continue to build systems on the same principles (one can't argue that
such systems are unsecure or unlikely to happen, that's not true, see
the Flashproxy project too).

But 1 fails too, because ws is not allowed inside a https page, so we
must use 2, which is insecure and 2 might not work any longer later.

Service Workers are doing about the same, https must be used, as far as
I understand Service Workers can run any browser instance in background
even if the spec seems to focus more on the offline aspects, so I
suppose that having 1 inside a (background) Service Worker will fail too.

Now we have the "new" "progressive Web Apps" which surprisingly present
as a revolution the possibility to have a web app look like a native app
while it can be done on iOS since the begining, same thing for some
offline caching features that were possible before, but this indeed
brings new things, hopefully we can have one day something like all the
cordova features inside browsers + background/headless browser instances.

So we are talking about web apps here, not about a web page loading
plenty of http/https stuff, web apps that can be used as
independant/native apps or nodes to relay traffic and therefore discuss
with some entities that can't be tied to a domain and can only use
self-signed certificates (like WebRTC peers, why do we have a security
exception here allowing something for WebRTC and not for this case?).

Then 1 must be possible with WS and Service Workers, because there are
no reasons why it should not be allowed and this will happen in the
future under different forms (see the link below), that's not illogical,
if you use wss then you expect it to work as such (ie fail with
self-signed certificates for example), if you use ws (what terrible
things can happen with ws exactly? ws can't access the DOM or whatever)
then you are on your own and should better know what you are doing,
that's not a reason to force you to use much more insecure 2.

Such apps can be loaded while navigating on a web site, entirely (ie the
web si

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Richard Barnes]

On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte <vitteayme...@gmail.com>
wrote:

> You must be kidding, the logjam attack showed the complete failure of
> TLS


Sure, protocols have bugs, and bugs get fixed.  The things we require for
HTTPS aren't even design goals of Tor.



> and your 1/2/3 (notwithstanding the useless discussions about CAs &
> co), which does not apply to the Tor protocol that you don't know
> apparently but that fulfills 1/2/3
>

I know Tor plenty well.  It's good for what it's designed for (e.g.,
anonymity), but it's not designed to meet the requirements of HTTPS.

You may be interested in this Tor blog post that points out some advantages
of doing HTTPS over Tor:

https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs



> I am not a Tor advocate, this is just an example illustrating why there
> are no reasons to forbid ws with https, and ws with https with service
> workers, and ws with https with future things, do you think that
> browsers will continue to discuss in the future with good old entities
> tied to a good old domain with a good old certificate?
>
> Then what about WebRTC and DTLS self-signed certificates that the web is
> trying to secure by some strange ways?
>

You seem to be missing the fact that WebRTC has additional security layers
on top of the certificates.  The WebRTC connection process requires the
website to specify the key fingerprint of the remote party, so you're
secure against any attacker besides the website.  And if you don't trust
that site, there's an identity layer that can provide additional
authentication.

https://w3c.github.io/webrtc-pc/#sec.identity-proxy

--Richard




>
> Le 30/11/2015 22:45, Richard Barnes a écrit :
> >
> >
> > On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte <vitteayme...@gmail.com
> > <mailto:vitteayme...@gmail.com>> wrote:
> >
> > Not sure that you know what you are talking about here, maybe
> influenced
> > by fb's onion things, or you misunderstood what I wrote.
> >
> > I am not talking about the Tor network, neither the Hidden services,
> I
> > am talking about the Tor protocol itself, that's different and it is
> > known to be strong, but this is just an example, let's see it as
> another
> > secure protocol to connect browsers to other entities that can not
> have
> > valid certificates for obvious reasons.
> >
> >
> > HTTPS gives you the following essential properties:
> > 1. Authentication: You know that you're talking to who you think you're
> > talking to.
> > 2. Confidentiality: Nobody else can see what you're saying
> > 3. Integrity: Nobody else can interfere with your communications
> >
> > Show me another protocol that achieves those properties, and maybe we'll
> > have something to talk about.  Tor doesn't.
> >
> > --Richard
> >
> >
> > Whatever number of bits are used for RSA/sym crypto/SHA the Tor
> protocol
> > is resistant to the logjam trivial DH_export quasi undetectable
> > downgrade attack that nobody anticipated during years, on purpose or
> > not, I don't know, but that's obvious that the DH client public key
> for
> > TLS could have been protected by the public key of the server, like
> the
> > Tor protocol is doing, so maybe you should refrain your compliments
> > about TLS.
> >
> > And the Tor protocol have TLS on top of it, so below the right
> sequence
> > is ws + TLS + Tor protocol.
> >
> > And it checks that the one you are connected to is the one with whom
> you
> > have established the TLS connection (who can be a MITM again, but you
> > don't care, you just want to be sure with whom you are discussing
> with,
> > like what WebRTC is trying to do)
> >
> > But again, that's not really the subject of the discussion, the
> subject
> > is what is really the problem of letting an interface that has
> access to
> > nothing (WS) work with https? Knowing that you can use it with
> another
> > protocol that you can estimate better, but could be worse, again what
> > does it hurt?
> >
> > Or just deprecate ws because if it has to work only with entities
> that
> > own valid certificates, then it's of quasi no use for the future.
> >
> > Le 30/11/2015 21:00, Brad Hill a écrit :
> > > I don't think there is universal agreement among browser engineers
> (if
> > > anyone agrees at all) with your assertion that the Tor protocol or
> even
> > > Tor hidden services are "more secure than TLS".  TLS in

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

What are you talking about?

The logjam attack just shows that you (spec security experts of major
internet companies) are incompetent, or just knew about it.

You don't know Tor "plenty well", I am not referring at all to hidden
services, the fb case, or the ridiculous related case of a https cert
over a .onion

And for WebRTC which "requires the website to specify the key
fingerprint of the remote party, so you're secure against any attacker
besides the website", this is a really funny (not to say completely
stupid) solution involving a "website"
(https://github.com/Ayms/node-Tor#security), which shows again that you
are completely missing my point, a "website" is not the future and web
apps must be able to work without a "website", so with entities that
cannot have valid certificates.

Maybe some projects like letsencrypt should study the case.

Let's stop talking about Tor, please just explain why ws cannot be used
with https.

Le 01/12/2015 00:08, Richard Barnes a écrit :
> On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte <vitteayme...@gmail.com
> <mailto:vitteayme...@gmail.com>> wrote:
> 
> You must be kidding, the logjam attack showed the complete failure of
> TLS
> 
> 
> Sure, protocols have bugs, and bugs get fixed.  The things we require
> for HTTPS aren't even design goals of Tor.
> 
>  
> 
> and your 1/2/3 (notwithstanding the useless discussions about CAs &
> co), which does not apply to the Tor protocol that you don't know
> apparently but that fulfills 1/2/3
> 
> 
> I know Tor plenty well.  It's good for what it's designed for (e.g.,
> anonymity), but it's not designed to meet the requirements of HTTPS.
> 
> You may be interested in this Tor blog post that points out some
> advantages of doing HTTPS over Tor:
> 
> https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs
> 
>  
> 
> I am not a Tor advocate, this is just an example illustrating why there
> are no reasons to forbid ws with https, and ws with https with service
> workers, and ws with https with future things, do you think that
> browsers will continue to discuss in the future with good old entities
> tied to a good old domain with a good old certificate?
> 
> Then what about WebRTC and DTLS self-signed certificates that the web is
> trying to secure by some strange ways?
> 
> 
> You seem to be missing the fact that WebRTC has additional security
> layers on top of the certificates.  The WebRTC connection process
> requires the website to specify the key fingerprint of the remote party,
> so you're secure against any attacker besides the website.  And if you
> don't trust that site, there's an identity layer that can provide
> additional authentication.
> 
> https://w3c.github.io/webrtc-pc/#sec.identity-proxy
> 
> --Richard
> 
> 
>  
> 
> 
> Le 30/11/2015 22:45, Richard Barnes a écrit :
> >
> >
> > On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte <vitteayme...@gmail.com 
> <mailto:vitteayme...@gmail.com>
> > <mailto:vitteayme...@gmail.com <mailto:vitteayme...@gmail.com>>>
> wrote:
> >
> > Not sure that you know what you are talking about here, maybe
> influenced
> > by fb's onion things, or you misunderstood what I wrote.
> >
> > I am not talking about the Tor network, neither the Hidden
> services, I
> > am talking about the Tor protocol itself, that's different and
> it is
> > known to be strong, but this is just an example, let's see it
> as another
> > secure protocol to connect browsers to other entities that can
> not have
> > valid certificates for obvious reasons.
> >
> >
> > HTTPS gives you the following essential properties:
> > 1. Authentication: You know that you're talking to who you think
> you're
> > talking to.
> > 2. Confidentiality: Nobody else can see what you're saying
> > 3. Integrity: Nobody else can interfere with your communications
> >
> > Show me another protocol that achieves those properties, and maybe
> we'll
> > have something to talk about.  Tor doesn't.
> >
> > --Richard
> >
> >
> > Whatever number of bits are used for RSA/sym crypto/SHA the
> Tor protocol
> > is resistant to the logjam trivial DH_export quasi undetectable
> > downgrade attack that nobody anticipated during years, on
> purpose or
> > not, I don't know, but that's obvious that the DH client
> 

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Florian Bösch]

On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes 
wrote:

> 1. Authentication: You know that you're talking to who you think you're
> talking to.
>

And then Dell installs a their own root authority on machines they ship, or
your CA of choice gets pwn'ed or the NSA uses some undisclosed backdoor in
the EC they managed to smuggle into the constants, or somebody combines a
DNS poison/grab with a non verified (because piss poor CA) double
certificate, or you hit one of the myriad of bugs that've plaqued TLS
implementations (particularly certain large and complex ones that're
basically one big ball of gnud which shall remain unnamed).

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Aymeric Vitte]

You must be kidding, the logjam attack showed the complete failure of
TLS and your 1/2/3 (notwithstanding the useless discussions about CAs &
co), which does not apply to the Tor protocol that you don't know
apparently but that fulfills 1/2/3

I am not a Tor advocate, this is just an example illustrating why there
are no reasons to forbid ws with https, and ws with https with service
workers, and ws with https with future things, do you think that
browsers will continue to discuss in the future with good old entities
tied to a good old domain with a good old certificate?

Then what about WebRTC and DTLS self-signed certificates that the web is
trying to secure by some strange ways?

Le 30/11/2015 22:45, Richard Barnes a écrit :
> 
> 
> On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte <vitteayme...@gmail.com
> <mailto:vitteayme...@gmail.com>> wrote:
> 
> Not sure that you know what you are talking about here, maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
> 
> I am not talking about the Tor network, neither the Hidden services, I
> am talking about the Tor protocol itself, that's different and it is
> known to be strong, but this is just an example, let's see it as another
> secure protocol to connect browsers to other entities that can not have
> valid certificates for obvious reasons.
> 
> 
> HTTPS gives you the following essential properties:
> 1. Authentication: You know that you're talking to who you think you're
> talking to.
> 2. Confidentiality: Nobody else can see what you're saying
> 3. Integrity: Nobody else can interfere with your communications
> 
> Show me another protocol that achieves those properties, and maybe we'll
> have something to talk about.  Tor doesn't.
> 
> --Richard
> 
> 
> Whatever number of bits are used for RSA/sym crypto/SHA the Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on purpose or
> not, I don't know, but that's obvious that the DH client public key for
> TLS could have been protected by the public key of the server, like the
> Tor protocol is doing, so maybe you should refrain your compliments
> about TLS.
> 
> And the Tor protocol have TLS on top of it, so below the right sequence
> is ws + TLS + Tor protocol.
> 
> And it checks that the one you are connected to is the one with whom you
> have established the TLS connection (who can be a MITM again, but you
> don't care, you just want to be sure with whom you are discussing with,
> like what WebRTC is trying to do)
> 
> But again, that's not really the subject of the discussion, the subject
> is what is really the problem of letting an interface that has access to
> nothing (WS) work with https? Knowing that you can use it with another
> protocol that you can estimate better, but could be worse, again what
> does it hurt?
> 
> Or just deprecate ws because if it has to work only with entities that
> own valid certificates, then it's of quasi no use for the future.
> 
> Le 30/11/2015 21:00, Brad Hill a écrit :
> > I don't think there is universal agreement among browser engineers (if
> > anyone agrees at all) with your assertion that the Tor protocol or even
> > Tor hidden services are "more secure than TLS".  TLS in modern browsers
> > requires RSA 2048-bit or equivalent authentication, 128-bit symmetric
> > key confidentiality and SHA-256 or better integrity.If .onion
> > identifiers and the Tor protocol crypto were at this level of strength,
> > it would be reasonable to argue that a .onion connection represented a
> > "secure context", and proceed from there.  In the meantime, with .onion
> > site security (without TLS) at 80-bits of truncation of a SHA-1 hash of
> > a 1024 bit key, I don't think you'll get much traction in insisting it
> > is equivalent to or better than TLS.
> >
> > On Mon, Nov 30, 2015 at 7:52 AM Aymeric Vitte <vitteayme...@gmail.com 
> <mailto:vitteayme...@gmail.com>
> > <mailto:vitteayme...@gmail.com <mailto:vitteayme...@gmail.com>>>
> wrote:
> >
> > Redirecting this to WebApps since it's probable that we are
> facing a
> > design mistake that might amplify by deprecating non TLS
> connections. I
> > have submitted the case to all possible lists in the past,
> never got a
> > clear answer and was each time redirected to another list (ccing
> > webappsec but as a whole I think that's a webapp matte

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Jim Manico]

How about the many of the Tor endpoints being compromised? Does that 
show a complete failure of Tor? I would say no. 
http://www.ibtimes.co.uk/tor-anonymity-network-compromised-following-potential-raid-by-law-enforcement-agencies-1480620


Most folks who really care about this stuff use Tor and use TLS for all 
services. And perhaps write services with secure code. And keep your 
machines free of malware, etc, etc, etc. Depending on any one of these 
technologies is not so helpful in 2015.


Aloha,
Jim


On 12/1/15 1:08 AM, Richard Barnes wrote:
On Mon, Nov 30, 2015 at 5:52 PM, Aymeric Vitte <vitteayme...@gmail.com 
<mailto:vitteayme...@gmail.com>> wrote:


You must be kidding, the logjam attack showed the complete failure of
TLS


Sure, protocols have bugs, and bugs get fixed.  The things we require 
for HTTPS aren't even design goals of Tor.


and your 1/2/3 (notwithstanding the useless discussions about CAs &
co), which does not apply to the Tor protocol that you don't know
apparently but that fulfills 1/2/3


I know Tor plenty well.  It's good for what it's designed for (e.g., 
anonymity), but it's not designed to meet the requirements of HTTPS.


You may be interested in this Tor blog post that points out some 
advantages of doing HTTPS over Tor:


https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs

I am not a Tor advocate, this is just an example illustrating why
there
are no reasons to forbid ws with https, and ws with https with service
workers, and ws with https with future things, do you think that
browsers will continue to discuss in the future with good old entities
tied to a good old domain with a good old certificate?

Then what about WebRTC and DTLS self-signed certificates that the
web is
trying to secure by some strange ways?


You seem to be missing the fact that WebRTC has additional security 
layers on top of the certificates. The WebRTC connection process 
requires the website to specify the key fingerprint of the remote 
party, so you're secure against any attacker besides the website.  And 
if you don't trust that site, there's an identity layer that can 
provide additional authentication.


https://w3c.github.io/webrtc-pc/#sec.identity-proxy

--Richard



Le 30/11/2015 22:45, Richard Barnes a écrit :
>
>
> On Mon, Nov 30, 2015 at 4:39 PM, Aymeric Vitte
<vitteayme...@gmail.com <mailto:vitteayme...@gmail.com>
> <mailto:vitteayme...@gmail.com <mailto:vitteayme...@gmail.com>>>
wrote:
>
> Not sure that you know what you are talking about here,
maybe influenced
> by fb's onion things, or you misunderstood what I wrote.
>
> I am not talking about the Tor network, neither the Hidden
services, I
> am talking about the Tor protocol itself, that's different
and it is
> known to be strong, but this is just an example, let's see
it as another
> secure protocol to connect browsers to other entities that
can not have
> valid certificates for obvious reasons.
>
>
> HTTPS gives you the following essential properties:
> 1. Authentication: You know that you're talking to who you think
you're
> talking to.
> 2. Confidentiality: Nobody else can see what you're saying
> 3. Integrity: Nobody else can interfere with your communications
>
> Show me another protocol that achieves those properties, and
maybe we'll
> have something to talk about.  Tor doesn't.
>
> --Richard
>
>
> Whatever number of bits are used for RSA/sym crypto/SHA the
Tor protocol
> is resistant to the logjam trivial DH_export quasi undetectable
> downgrade attack that nobody anticipated during years, on
purpose or
> not, I don't know, but that's obvious that the DH client
public key for
> TLS could have been protected by the public key of the
server, like the
> Tor protocol is doing, so maybe you should refrain your
compliments
> about TLS.
>
> And the Tor protocol have TLS on top of it, so below the
right sequence
> is ws + TLS + Tor protocol.
>
> And it checks that the one you are connected to is the one
with whom you
> have established the TLS connection (who can be a MITM
again, but you
> don't care, you just want to be sure with whom you are
discussing with,
> like what WebRTC is trying to do)
>
> But again, that's not really the subject of the discussion,
the subject
> is what is really the problem of letting an interface that
has access to
> nothing (WS) work with https? Knowing that you can use it
with anoth

Re: WS/Service Workers, TLS and future apps - [was Re: HTTP is just fine]

[Brad Hill]

Let's keep this discussion civil, please.

The reasons behind blocking of non-secure WebSocket connections from secure
contexts are laid out in the following document:

http://www.w3.org/TR/mixed-content/

A plaintext ws:// connection does not meet the requirements of
authentication, encryption and integrity, so far as the user agent is able
to tell, so it cannot allow it.

If there is a plausible mechanism by which browsers could distinguish
external communications which meet the necessary security criteria using
protocols other than TLS or authentication other than from the Web PKI,
there is a reasonable case to be made that such could be considered as
potentially secure origins and URLs.  (as has been done to some extent for
WebRTC, as you have already noted)

If you want to continue this discussion here, please:

1) State your use cases clearly for those on this list who do not already
know them.  You want to "use the Tor protocol" over websockets?  To connect
to what?  Why?  Why is it important to bootstrap an application like this
over regular http(s) instead of, for example, as an extension or modified
user-agent like TBB?

2) Describe clearly why and how the protocol you propose to use meets the
necessary guarantees a user expects from an https page.

3) Describe clearly how the user agent can determine, before any
degradation in the security state of the context is possible, that only a
protocol meeting these requirements will be used.

Ad-hominem and security nihilism of the forms "TLS / PKI is worthless so
why bother trying to enforce any security guarantees" or "other insecure
configurations like starting with http are allowed, so why not allow this
insecure configuration, too" are not appropriate or a good use of anyone's
time on this list.  Please refrain from continuing down these paths.

thank you,

Brad Hill, as co-chair

On Mon, Nov 30, 2015 at 6:25 PM Florian Bösch  wrote:

> On Mon, Nov 30, 2015 at 10:45 PM, Richard Barnes 
> wrote:
>
>> 1. Authentication: You know that you're talking to who you think you're
>> talking to.
>>
>
> And then Dell installs a their own root authority on machines they ship,
> or your CA of choice gets pwn'ed or the NSA uses some undisclosed backdoor
> in the EC they managed to smuggle into the constants, or somebody combines
> a DNS poison/grab with a non verified (because piss poor CA) double
> certificate, or you hit one of the myriad of bugs that've plaqued TLS
> implementations (particularly certain large and complex ones that're
> basically one big ball of gnud which shall remain unnamed).
>

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Boris Zbarsky]

On 11/30/15 8:31 AM, Xiaoqian Wu wrote:

The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have 
been widely implemented by the major browser vendors.


Compatibly?  Last I checked, for example, Blink doesn't support 
Dedicated Workers inside workers, only inside Window.  I agree that 
there is some subset of dedicated worker support that is widely 
implemented; I'm just not sure what that subset is.


-Boris

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Xiaoqian Wu]

> On 30 Nov 2015, at 10:02 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> 
> On 11/30/15 8:31 AM, Xiaoqian Wu wrote:
>> The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers 
>> have been widely implemented by the major browser vendors.
> 
> Compatibly?  Last I checked, for example, Blink doesn't support Dedicated 
> Workers inside workers, only inside Window.  I agree that there is some 
> subset of dedicated worker support that is widely implemented; I'm just not 
> sure what that subset is.

Right, nested workers are at-risk[1] as well as shared-workers.

--
xiaoqian

[1] 
https://w3c.github.io/test-results/workers/dedicated-less-than-2#test-file-15 
<https://w3c.github.io/test-results/workers/dedicated-less-than-2#test-file-15>
> 
> -Boris
> 

Re: CfC: Is Web Workers Ready for CR? deadline Dec 14

[Ms2ger]

On 11/30/2015 02:31 PM, Xiaoqian Wu wrote:
> This is a call for comments regarding the next step of Web Workers.
> 
> The latest [TEST RESULTS] of Web Workers indicate that Dedicated
> Workers have been widely implemented by the major browser vendors.
> 
> [Diff] between the latest W3C WD and the WHATWG living standard
> suggests substantial changes about the WorkerLocation interface, and
> the test results of the [WorkerLocationTestCases] show that these
> changes have been adapted by more than two major browsers.
> 
> As for Shared workers, [TEST RESULTS] suggest that this feature is
> still poorly supported. Right now both Apple and Microsoft don’t
> intend to implement it, Chrome supports only a small part of it.
> There were issues raised about [Removing-Sharedworkers] on GitHub,
> one suggestion was to pull it out into a separate working note,
> whereas others thought it’s too early to do so.
> 
> Hence our questions to the group: Is the group still interested in
> moving Workers forward? Is it the right time to publish Workers as a
> CR? Should SharedWorkers be removed from this spec?
> 
> Please provide your thoughts on these questions by Dec 14 2015. If
> there’s no interest from the members to continue the work of
> WebWorkers in W3C, we will probably stop publishing new versions of
> this spec.
> 

Let's publish it as a REC; that no longer needs interop anyway (see:
DOM4 is a REC).

HTH
Ms2ger

CfC: Is Web Workers Ready for CR? deadline Dec 14

[Xiaoqian Wu]

This is a call for comments regarding the next step of Web Workers.

The latest [TEST RESULTS] of Web Workers indicate that Dedicated Workers have 
been widely implemented by the major browser vendors.

[Diff] between the latest W3C WD and the WHATWG living standard suggests 
substantial changes about the WorkerLocation interface, and the test results of 
the [WorkerLocationTestCases] show that these changes have been adapted by more 
than two major browsers.

As for Shared workers, [TEST RESULTS] suggest that this feature is still poorly 
supported. Right now both Apple and Microsoft don’t intend to implement it, 
Chrome supports only a small part of it. There were issues raised about 
[Removing-Sharedworkers] on GitHub, one suggestion was to pull it out into a 
separate working note, whereas others thought it’s too early to do so.

Hence our questions to the group: Is the group still interested in moving 
Workers forward? Is it the right time to publish Workers as a CR? Should 
SharedWorkers be removed from this spec?

Please provide your thoughts on these questions by Dec 14 2015. If there’s no 
interest from the members to continue the work of WebWorkers in W3C, we will 
probably stop publishing new versions of this spec.

Thanks.

-xiaoqian

-
[TEST RESULTS]:
dedicatedworkers-all: https://w3c.github.io/test-results/workers/dedicated-all
dedicatedworkers-less-than-2: 
https://w3c.github.io/test-results/workers/dedicated-less-than-2
dedicatedworkers-complete-fails: 
https://w3c.github.io/test-results/workers/dedicated-complete-fails
workers-all: https://w3c.github.io/test-results/workers/all
workers-less-than-2: https://w3c.github.io/test-results/workers/less-than-2
workers-complete-fails: 
https://w3c.github.io/test-results/workers/complete-fails

[Diff]: 
https://www.diffchecker.com/5zbz229w

[WorkerLocationTestCases]: 
http://w3c.github.io/test-results/workers/all.html#test-file-9

[Removing-sharedworkers]: 
https://github.com/whatwg/html/issues/315
https://github.com/w3c/workers/issues/2

RE: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

[Siegman, Tzviya - Hoboken]

Hi Jake,

Thanks for the offer.  The DPUB IG meets on Mondays at 11:00 EDT/15:00 UTC. We 
would be very happy to have you at our 19 October meeting [1] to discuss 
Service Workers in the context of the Portable Web Publications for the Open 
Web Platform [2].

Markus and I will copy you when we send the agenda.

I will speak with some DPUB-ers who especially interested in Service Workers 
about their availability to attend the Web Apps meeting on Monday and I’ll be 
in touch shortly. Thank you for the offer.

[1] 
http://www.timeanddate.com/worldclock/fixedtime.html?msg=DPUB+IG+meeting=20151019T11=43
[2] http://w3c.github.io/dpub-pwp/

Best,
Tzviya

Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsieg...@wiley.com<mailto:tsieg...@wiley.com>

From: Jake Archibald [mailto:jakearchib...@google.com]
Sent: Monday, October 05, 2015 12:37 PM
To: public-digipub...@w3.org; public-webapps; Alex Russell; Jungkee Song
Cc: Siegman, Tzviya - Hoboken
Subject: Re: RfC: Service Workers and "Portable Web Publications for the Open 
Web Platform"

On Mon, 5 Oct 2015 at 13:00 Arthur Barstow 
<art.bars...@gmail.com<mailto:art.bars...@gmail.com>> wrote:
The IG welcomes discussion and feedback during their October 19
conference call (if interested, please contact Tzviya) and/or during
TPAC.

I'm happy to take part in this from a service worker point of view, if 
timezones add up. What time is it?

Although WebApps meets on Monday and Tuesday and the IG meets on
Thursday and Friday, if there is interest in a joint meeting, my
understanding is that some set of IG members can meet during WebApps'
meeting (see agenda at [3] for open slots).

I'm happy to attend either of IG meets, and I intend to be at the the WebApps 
meeting on Monday.

Happy to meet informally too!

Alex, Jake, Jungkee - perhaps you could meet with some of the IG members
during the October 27 Service Worker meeting. WDYT?

I think we're already over subscribed on the 27th, would meeting on the dates 
around that be enough? Happy to make time on evenings if need be.

Re: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

[Ivan Herman]

Jake,

just to note that Tzviya, who organizes the meetings around TPAC, is on 
vacations until Wednesday morning. We will synchronize then; I hope it is all 
right.

And thanks in advance for your help!

Ivan

---
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

(Written on mobile, sorry for brevity and misspellings...)



> On 5 Oct 2015, at 18:37, Jake Archibald  wrote:
> 
>> On Mon, 5 Oct 2015 at 13:00 Arthur Barstow  wrote:
>> The IG welcomes discussion and feedback during their October 19
>> conference call (if interested, please contact Tzviya) and/or during
>> TPAC.
> 
> I'm happy to take part in this from a service worker point of view, if 
> timezones add up. What time is it?
>  
>> Although WebApps meets on Monday and Tuesday and the IG meets on
>> Thursday and Friday, if there is interest in a joint meeting, my
>> understanding is that some set of IG members can meet during WebApps'
>> meeting (see agenda at [3] for open slots).
> 
> I'm happy to attend either of IG meets, and I intend to be at the the WebApps 
> meeting on Monday.
> 
> Happy to meet informally too!
>  
>> Alex, Jake, Jungkee - perhaps you could meet with some of the IG members
>> during the October 27 Service Worker meeting. WDYT?
> 
> I think we're already over subscribed on the 27th, would meeting on the dates 
> around that be enough? Happy to make time on evenings if need be.

RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

[Arthur Barstow]

Hi All,

The Digital Publishing Interest Group [1] is seeking feedback regarding 
the use of Service Workers in their early draft (WIP) of "Portable Web 
Publications for the Open Web Platform", in particular section 5.1 
"General Architecture for Online/Offline Publications":


  <http://w3c.github.io/dpub-pwp/#arch>

Please note Service Workers is new to the group and the above section 
contains "some preliminary discussion (assumptions?) about Service 
Workers" and the IG "want to make sure that we are headed in the right 
direction, and we have not made incorrect assumptions about Service 
Workers".


If you have any comments about their document please send them to the 
IG's public-digipub-ig list (archive [2]).


The IG welcomes discussion and feedback during their October 19 
conference call (if interested, please contact Tzviya) and/or during 
TPAC. Although WebApps meets on Monday and Tuesday and the IG meets on 
Thursday and Friday, if there is interest in a joint meeting, my 
understanding is that some set of IG members can meet during WebApps' 
meeting (see agenda at [3] for open slots).


Alex, Jake, Jungkee - perhaps you could meet with some of the IG members 
during the October 27 Service Worker meeting. WDYT?


-Thanks, AB

[1] <http://www.w3.org/dpub/IG/wiki/Main_Page>
[2] <http://lists.w3.org/Archives/Public/public-digipub-ig/>
[3] <https://www.w3.org/wiki/Webapps/October2015Meeting>

Re: RfC: Service Workers and "Portable Web Publications for the Open Web Platform"

[Jake Archibald]

On Mon, 5 Oct 2015 at 13:00 Arthur Barstow  wrote:

> The IG welcomes discussion and feedback during their October 19
> conference call (if interested, please contact Tzviya) and/or during
> TPAC.


I'm happy to take part in this from a service worker point of view, if
timezones add up. What time is it?


> Although WebApps meets on Monday and Tuesday and the IG meets on
> Thursday and Friday, if there is interest in a joint meeting, my
> understanding is that some set of IG members can meet during WebApps'
> meeting (see agenda at [3] for open slots).
>

I'm happy to attend either of IG meets, and I intend to be at the the
WebApps meeting on Monday.

Happy to meet informally too!


> Alex, Jake, Jungkee - perhaps you could meet with some of the IG members
> during the October 27 Service Worker meeting. WDYT?


I think we're already over subscribed on the 27th, would meeting on the
dates around that be enough? Happy to make time on evenings if need be.

RE: RfC: Service Workers

[Phillips, Addison]

Hello Art,

Could you better define what "soon" means? More specifically, do you have a 
deadline for comments? I don't see any dates in the thread below.

Thanks,

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG)

Internationalization is not a feature.
It is an architecture.

> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@gmail.com]
> Sent: Monday, September 21, 2015 5:27 AM
> To: public-webapps
> Subject: Re: RfC: Service Workers
> 
> Please use the Version 1 branch for this review:
> <https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/>
> 
> On 9/21/15 7:27 AM, Arthur Barstow wrote:
> > [ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG
> > (public-web-mobile), W3C Chairs (chairs),  Review Announce list
> > (public-review-announce), Geolocation WG (public-geolocation) ]
> >
> > The Editors and active contributors of Service Workers intend to
> > publish a Candidate Recommendation soon (details below). Consequently,
> > this is a Request for Comments by the WebApps group to seek wide
> > review of the latest version of the spec:
> >
> > <https://slightlyoff.github.io/ServiceWorker/spec/service_worker/>
> >
> > The open issues for Version 1, and the spec's version history are [1]
> > and [2], respectively.
> >
> > If you have any comments, we prefer you submit them as Github issues
> > [3]; otherwise, please send your comments to the public-webapps list
> > [4] using a Subject: prefix of "[serviceworkers]".
> >
> > -Thanks, AB
> >
> > [1]
> >
> <https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3A
> > issue+milestone%3A%22Version+1%22>
> > [2] <https://github.com/slightlyoff/ServiceWorker/commits/master>
> > [3] <https://github.com/slightlyoff/ServiceWorker/issues/>
> > [4] <https://lists.w3.org/Archives/Public/public-webapps/>
> >
> >
> > On 9/18/15 2:22 AM, Jungkee Song wrote:
> >> Hi all,
> >>
> >> We editors are happy to announce that we make a new branch for
> >> Service Workers 1 today [1].
> >>
> >> Thanks to all the contributions, Service Workers 1 now covers the
> >> fundamental model and the associated APIs to support offline-first
> >> and background processing requirements. The features in this version
> >> include:
> >>   - Register/Update/Unregister of a service worker registration
> >>   - Handle fetch events
> >>   - Fetch and Cache resources
> >>   - Manage service worker clients
> >>   - Communicate between a client and a service worker
> >>   - Define interfaces and algorithms for extensions (Push,
> >> Notification,
> >> etc.)
> >> ([2] is the remaining issues for this version in the github issue
> >> tracker.)
> >>
> >> On top of the above work, the contributors are now ready to continue
> >> with the discussions about new features including foreign fetch [3],
> >> fetch event's request's client, header-based installation,
> >> kill-switch, and so forth. These efforts will be put in Service
> >> Workers Nightly [4] which is just a new name for the original ED
> >> branch.
> >>
> >> We are planning to publish a CR based on Service Workers 1 soon
> >> during which we would like to focus on stabilizing the features (bug
> >> fix) and resolving compatibility issues among multiple
> >> implementations.
> >>
> >> For editors,
> >> Jungkee
> >>
> >>
> >> [1]
> >> https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
> >> [2]
> >>
> https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3A
> >> issue+m
> >>
> >> ilestone%3A%22Version+1%22
> >> [3] https://github.com/slightlyoff/ServiceWorker/issues/684
> >> [4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/
> >>
> >>
> >> --
> >> Jungkee Song
> >> Samsung Electronics
> >
> 

Re: RfC: Service Workers

[Arthur Barstow]

On 9/23/15 1:46 PM, Phillips, Addison wrote:

Could you better define what "soon" means? More specifically, do you have a 
deadline for comments? I don't see any dates in the thread below.


I think four weeks is the `normal` expectation for `wide reviews`. 
However, the Editors and some active participants are having a related 
meeting during the TPAC 2015 meeting week so I think you should consider 
October 25 as the target comment date. If that date won't work for you, 
please let me know.


-Thanks, AB

Re: RfC: Service Workers

[Arthur Barstow]

Please use the Version 1 branch for this review: 
<https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/>


On 9/21/15 7:27 AM, Arthur Barstow wrote:
[ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG 
(public-web-mobile), W3C Chairs (chairs),  Review Announce list 
(public-review-announce), Geolocation WG (public-geolocation) ]


The Editors and active contributors of Service Workers intend to 
publish a Candidate Recommendation soon (details below). Consequently, 
this is a Request for Comments by the WebApps group to seek wide 
review of the latest version of the spec:


<https://slightlyoff.github.io/ServiceWorker/spec/service_worker/>

The open issues for Version 1, and the spec's version history are [1] 
and [2], respectively.


If you have any comments, we prefer you submit them as Github issues 
[3]; otherwise, please send your comments to the public-webapps list 
[4] using a Subject: prefix of "[serviceworkers]".


-Thanks, AB

[1] 
<https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Version+1%22>

[2] <https://github.com/slightlyoff/ServiceWorker/commits/master>
[3] <https://github.com/slightlyoff/ServiceWorker/issues/>
[4] <https://lists.w3.org/Archives/Public/public-webapps/>


On 9/18/15 2:22 AM, Jungkee Song wrote:

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1].

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version 
include:

  - Register/Update/Unregister of a service worker registration
  - Handle fetch events
  - Fetch and Cache resources
  - Manage service worker clients
  - Communicate between a client and a service worker
  - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue 
tracker.)


On top of the above work, the contributors are now ready to continue 
with

the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon 
during which
we would like to focus on stabilizing the features (bug fix) and 
resolving

compatibility issues among multiple implementations.

For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m 


ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/


--
Jungkee Song
Samsung Electronics

Re: Normative references to Workers.

[Arthur Barstow]

On 9/21/15 5:54 AM, Ms2ger wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2015 11:05 AM, Xiaoqian Wu wrote:

If it helps, I’d like to prepare a Workers draft to revise the
previous CR, and schedule the publication ASAP (hopefully 22 Sep).
The goal is to synchronise with the upstream, to document the
changes since the previous CR and to identify the "at risk”
features.


OK, thanks (and please let me know when a draft CR is ready and then 
I'll start a CfC to publish it).



Why?


I think the rationale was mentioned in 
<https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0367.html>.


-AB

Re: Normative references to Workers.

[Anne van Kesteren]

On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow <art.bars...@gmail.com> wrote:
> On 9/21/15 5:54 AM, Ms2ger wrote:
>> Why?
>
> I think the rationale was mentioned in
> <https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0367.html>.

Ms2ger made a valid point. Workers is actively being updated (I
submitted two PRs the other day, more to come). If you don't want to
get out-of-sync you won't get to REC in the foreseeable future. It
therefore is likely a waste of time for someone to volunteer to
copy-and-paste text that is unstable.


-- 
https://annevankesteren.nl/

RfC: Service Workers

[Arthur Barstow]

[ Bcc: TAG (www-tag), WebAppSec WG (public-webapsec), Mobile IG 
(public-web-mobile), W3C Chairs (chairs),  Review Announce list 
(public-review-announce), Geolocation WG (public-geolocation) ]


The Editors and active contributors of Service Workers intend to publish 
a Candidate Recommendation soon (details below). Consequently, this is a 
Request for Comments by the WebApps group to seek wide review of the 
latest version of the spec:


<https://slightlyoff.github.io/ServiceWorker/spec/service_worker/>

The open issues for Version 1, and the spec's version history are [1] 
and [2], respectively.


If you have any comments, we prefer you submit them as Github issues 
[3]; otherwise, please send your comments to the public-webapps list [4] 
using a Subject: prefix of "[serviceworkers]".


-Thanks, AB

[1] 
<https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Version+1%22>

[2] <https://github.com/slightlyoff/ServiceWorker/commits/master>
[3] <https://github.com/slightlyoff/ServiceWorker/issues/>
[4] <https://lists.w3.org/Archives/Public/public-webapps/>


On 9/18/15 2:22 AM, Jungkee Song wrote:

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1].

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version include:
  - Register/Update/Unregister of a service worker registration
  - Handle fetch events
  - Fetch and Cache resources
  - Manage service worker clients
  - Communicate between a client and a service worker
  - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue tracker.)

On top of the above work, the contributors are now ready to continue with
the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon during which
we would like to focus on stabilizing the features (bug fix) and resolving
compatibility issues among multiple implementations.

For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m
ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/


--
Jungkee Song
Samsung Electronics

Re: Normative references to Workers.

[Ms2ger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/21/2015 11:05 AM, Xiaoqian Wu wrote:
> If it helps, I’d like to prepare a Workers draft to revise the 
> previous CR, and schedule the publication ASAP (hopefully 22 Sep). 
> The goal is to synchronise with the upstream, to document the
> changes since the previous CR and to identify the "at risk”
> features.
> 

Why? What are you trying to achieve that makes doing that a good use
of your time (and the time of everyone else in that toolchain)?

Thanks
Ms2ger

-BEGIN PGP SIGNATURE-

iQEcBAEBAgAGBQJV/9PeAAoJEOXgvIL+s8n2AokIAJH7kcGJmSrNKn/SyKBeNGPH
INFwRIw8vReupG7g5rrIc9fErpV/4r/15dcpz87Z7IRx1S+Ne/6IrGWLnJMx+Boc
x7mvGW7rPm2Jqnq9S6s8W2n+QpFa4Z+2haznH+p9divt79Y7fYIhtwrcNEYc6z6c
Hs7wcfWGrCd7DbpjjMS2RdKls0YEHOkfu6VIi9wqn+DpFLXOYVgSg8CbiDtaRJiy
Pnjh3GuAl8hizW30tCUFF+YlELxQmRL6ojWnSb6AcD//VB+dFS3Jtf8QFEeL934i
kDQjyR1TUFlz7t3Xa409D48qpyG7/5s580KX5gRq0mFU8IhtzP2BNKMLgfgqvyw=
=X2q+
-END PGP SIGNATURE-

Re: Normative references to Workers.

[Xiaoqian Wu]

> On 22 Sep, 2015, at 1:35 am, Anne van Kesteren <ann...@annevk.nl> wrote:
> 
> On Mon, Sep 21, 2015 at 6:03 PM, Arthur Barstow <art.bars...@gmail.com> wrote:
>> On 9/21/15 5:54 AM, Ms2ger wrote:
>>> Why?
>> 
>> I think the rationale was mentioned in
>> <https://lists.w3.org/Archives/Public/public-webapps/2015JulSep/0367.html>.
> 
> Ms2ger made a valid point. Workers is actively being updated (I
> submitted two PRs the other day, more to come). If you don't want to
> get out-of-sync you won't get to REC in the foreseeable future. It
> therefore is likely a waste of time for someone to volunteer to
> copy-and-paste text that is unstable.
> 

Thanks for explaining the situation :)

If the spec is still changing frequently, indeed it isn't a good idea to 
publish another CR… but the WebApps WG needs to clearly tell the community that 
the 2012 CR should be considered obsolete. 

I’d suggest that we publish a WD for Workers, which adapts to the current 
changes and revise the 2012 CR. The community is encouraged to refer to either 
the WHATWG version or the new WD. 

—
xiaoqian

> 
> -- 
> https://annevankesteren.nl/
> 

RE: Normative references to Workers.

[Domenic Denicola]

From: Xiaoqian Wu [mailto:xiaoq...@w3.org] 

> If the spec is still changing frequently, indeed it isn't a good idea to 
> publish another CR… but the WebApps WG needs to clearly tell the community 
> that the 2012 CR should be considered obsolete. 
>
> I’d suggest that we publish a WD for Workers, which adapts to the current 
> changes and revise the 2012 CR. The community is encouraged to refer to 
> either the WHATWG version or the new WD. 

The best way to accomplish this may be to do the same as has been done with 
other specs, and either redirect to the original source document (e.g. as has 
been done with Fullscreen) or replace the WD and CR with NOTEs directing 
visitors to the source document.

Re: Normative references to Workers.

[Xiaoqian Wu]

> On 16 Sep, 2015, at 8:17 pm, Arthur Barstow <art.bars...@gmail.com> wrote:
> 
> On 9/16/15 4:47 AM, Mike West wrote:
>> Note that this is an issue that's going to come up for a number of WebAppSec 
>> specs (see 
>> https://w3c.github.io/webappsec/specs/powerfulfeatures/#issue-a30f61b8 
>> <https://w3c.github.io/webappsec/specs/powerfulfeatures/#issue-a30f61b8>, 
>> for instance (and that spec also needs a few things that are missing from 
>> W3C's HTML, but are present in WHATWG's)). What I hear so far on this thread 
>> is that we should simply reference the WHATWG version of those specs, which 
>> seems like a reasonable thing to do.
> 
> Yes, for the scenario you mention, I agree with you.
> 
> The grey area is when a feature is defined by both a W3C WG and WHATWG. 
> Because of the consortium's Patent Policy, I suspect consensus among 
> consortium members is to use the W3C spec for normative references. However, 
> if the W3C spec is no longer actively maintained by a WG, then normatively 
> referencing a WHATWG spec would (IMHO) be appropriate and I think the 
> Normative Reference Policy [NRP] supports such a scenario.
> 
> In this specific case, I don't believe anyone has committed to actively 
> maintain W3C Web Workers. As such, WebApps - do we have a volunteer? Please 
> let us know (or send me private e-mail if you prefer).

If it helps, I’d like to prepare a Workers draft to revise the previous CR, and 
schedule the publication ASAP (hopefully 22 Sep). The goal is to synchronise 
with the upstream, to document the changes since the previous CR and to 
identify the "at risk” features. 

Thanks.

--
xiaoqian

> 
> -Thanks, AB
> 
> [NRP] <http://www.w3.org/2013/09/normative-references>
> 
> 
>> 
>> -mike
>> 
>> --
>> Mike West <mk...@google.com <mailto:mk...@google.com>>, @mikewest
>> 
>> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, 
>> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: 
>> Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
>> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>> 
>> On Tue, Sep 15, 2015 at 7:31 PM, Mike West <mk...@google.com 
>> <mailto:mk...@google.com>> wrote:
>> 
>>The "Upgrade Insecure Requests" specification[1] references the
>>WHATWG HTML spec for the
>>"set up a worker environment settings object" algorithm[2], as the
>>Web Workers Candidate Recommendation from May 2012[3]
>>substantially predates the entire concept of a "settings object",
>>and because the WHATWG is the group where work on Workers seems to
>>be being done.
>> 
>>This referential choice was flagged during a discussion of
>>transitioning the Upgrade spec to CR, where it was noted that the
>>Web Workers editor's draft from May 2014 does contain the
>>referenced concept[4].
>> 
>>It seems appropriate, then, to bring the question to this group:
>>does WebApps intend to update the Workers draft in TR? If so, is
>>there a path forward to aligning the Workers document with the
>>work that's happened over the last year and a half in WHATWG?
>>Alternatively, does WebApps intend to drop work on Workers in
>>favor of the WHATWG's document?
>> 
>>It would be helpful if we could get some clarity here. :)
>> 
>>Thanks!
>> 
>>[1]: https://w3c.github.io/webappsec/specs/upgrade/
>>[2]:
>>
>> https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object
>>[3]: http://www.w3.org/TR/workers/
>>[4]: https://w3c.github.io/workers/
>> 
>>--
>>Mike West <mk...@google.com <mailto:mk...@google.com>>, @mikewest
>> 
>>Google Germany GmbH, Dienerstrasse 12, 80331 München,
>>Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
>>Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
>>Elizabeth Flores
>>(Sorry; I'm legally required to add this exciting detail to
>>emails. Bleh.)
>> 
>> 
> 
> 

Service Workers 1 and Nightly

[Jungkee Song]

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1]. 

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version include:
 - Register/Update/Unregister of a service worker registration
 - Handle fetch events
 - Fetch and Cache resources
 - Manage service worker clients
 - Communicate between a client and a service worker
 - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue tracker.)

On top of the above work, the contributors are now ready to continue with
the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon during which
we would like to focus on stabilizing the features (bug fix) and resolving
compatibility issues among multiple implementations.

For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m
ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/


--
Jungkee Song
Samsung Electronics

Re: Service Workers 1 and Nightly

[Arthur Barstow]

On 9/18/15 2:22 AM, Jungkee Song wrote:

Hi all,

We editors are happy to announce that we make a new branch for Service
Workers 1 today [1].

Thanks to all the contributions, Service Workers 1 now covers the
fundamental model and the associated APIs to support offline-first and
background processing requirements. The features in this version include:
  - Register/Update/Unregister of a service worker registration
  - Handle fetch events
  - Fetch and Cache resources
  - Manage service worker clients
  - Communicate between a client and a service worker
  - Define interfaces and algorithms for extensions (Push, Notification,
etc.)
([2] is the remaining issues for this version in the github issue tracker.)

On top of the above work, the contributors are now ready to continue with
the discussions about new features including foreign fetch [3], fetch
event's request's client, header-based installation, kill-switch, and so
forth. These efforts will be put in Service Workers Nightly [4] which is
just a new name for the original ED branch.

We are planning to publish a CR based on Service Workers 1 soon during which
we would like to focus on stabilizing the features (bug fix) and resolving
compatibility issues among multiple implementations.


Hi Jungkee, All,

Thanks for this update!

Regarding the publishing plan above, the latest process document 
includes an expectation that before a CR is published the spec "has 
already received wide review" [1]. Although the group is free to 
determine the wide review "requirements" (see [2]), it can be useful to 
publish a new WD and use that WD as the basis of the wide review. It 
would also be possible to use an ED (perhaps a static snapshot) as the 
basis for the review. There is also a question about which group(s) we 
explicitly want to ask to review the spec.


What are your thoughts on the document (WD vs. ED snapshot) to use as 
the review?


Which groups do we ask to review? I presume at least TAG and Web Mobile 
IG. Are there others?


-Thanks, AB

[1] <http://www.w3.org/2015/Process-20150901/#maturity-levels>
[2] <http://www.w3.org/2015/Process-20150901/#wide-review>



For editors,
Jungkee


[1] https://slightlyoff.github.io/ServiceWorker/spec/service_worker_1/
[2]
https://github.com/slightlyoff/ServiceWorker/issues?q=is%3Aopen+is%3Aissue+m
ilestone%3A%22Version+1%22
[3] https://github.com/slightlyoff/ServiceWorker/issues/684
[4] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/

Re: Service Workers 1 and Nightly

[Jungkee Song]

On Fri, Sep 18, 2015 at 7:56 PM, Arthur Barstow 
wrote:

>
> Regarding the publishing plan above, the latest process document includes
> an expectation that before a CR is published the spec "has already received
> wide review" [1]. Although the group is free to determine the wide review
> "requirements" (see [2]), it can be useful to publish a new WD and use that
> WD as the basis of the wide review. It would also be possible to use an ED
> (perhaps a static snapshot) as the basis for the review. There is also a
> question about which group(s) we explicitly want to ask to review the spec.
>
> What are your thoughts on the document (WD vs. ED snapshot) to use as the
> review?
>

If there's no particular problem, an ED snapshot would be great to avoid
redundant publication preparations. In that case, I'll try to get it well
prepared before we request it.


>
> Which groups do we ask to review? I presume at least TAG and Web Mobile
> IG. Are there others?
>

I presume TAG, Web Mobile IG, WebAppSec (Security standpoint), Geolocation
WG (Geofencing uses SW) would be good. Any other suggestions?


Thanks,
Jungkee


>
> -Thanks, AB
>
> [1] 
> [2] 
>
>

-- 

Jungkee Song

Re: Normative references to Workers.

[Arthur Barstow]

On 9/16/15 4:47 AM, Mike West wrote:
Note that this is an issue that's going to come up for a number of 
WebAppSec specs 
(see https://w3c.github.io/webappsec/specs/powerfulfeatures/#issue-a30f61b8 
<https://w3c.github.io/webappsec/specs/powerfulfeatures/#issue-a30f61b8>, 
for instance (and that spec also needs a few things that are missing 
from W3C's HTML, but are present in WHATWG's)). What I hear so far on 
this thread is that we should simply reference the WHATWG version of 
those specs, which seems like a reasonable thing to do.


Yes, for the scenario you mention, I agree with you.

The grey area is when a feature is defined by both a W3C WG and WHATWG. 
Because of the consortium's Patent Policy, I suspect consensus among 
consortium members is to use the W3C spec for normative references. 
However, if the W3C spec is no longer actively maintained by a WG, then 
normatively referencing a WHATWG spec would (IMHO) be appropriate and I 
think the Normative Reference Policy [NRP] supports such a scenario.


In this specific case, I don't believe anyone has committed to actively 
maintain W3C Web Workers. As such, WebApps - do we have a volunteer? 
Please let us know (or send me private e-mail if you prefer).


-Thanks, AB

[NRP] <http://www.w3.org/2013/09/normative-references>




-mike

--
Mike West <mk...@google.com <mailto:mk...@google.com>>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, 
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der 
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine 
Elizabeth Flores

(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Tue, Sep 15, 2015 at 7:31 PM, Mike West <mk...@google.com 
<mailto:mk...@google.com>> wrote:


The "Upgrade Insecure Requests" specification[1] references the
WHATWG HTML spec for the
"set up a worker environment settings object" algorithm[2], as the
Web Workers Candidate Recommendation from May 2012[3]
substantially predates the entire concept of a "settings object",
and because the WHATWG is the group where work on Workers seems to
be being done.

This referential choice was flagged during a discussion of
transitioning the Upgrade spec to CR, where it was noted that the
Web Workers editor's draft from May 2014 does contain the
referenced concept[4].

It seems appropriate, then, to bring the question to this group:
does WebApps intend to update the Workers draft in TR? If so, is
there a path forward to aligning the Workers document with the
work that's happened over the last year and a half in WHATWG?
Alternatively, does WebApps intend to drop work on Workers in
favor of the WHATWG's document?

It would be helpful if we could get some clarity here. :)

Thanks!

[1]: https://w3c.github.io/webappsec/specs/upgrade/
[2]:

https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object
[3]: http://www.w3.org/TR/workers/
[4]: https://w3c.github.io/workers/

--
Mike West <mk...@google.com <mailto:mk...@google.com>>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine
Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to
emails. Bleh.)

Re: Normative references to Workers.

[Tab Atkins Jr.]

On Tue, Sep 15, 2015 at 10:31 AM, Mike West <mk...@google.com> wrote:
> The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML
> spec for the
> "set up a worker environment settings object" algorithm[2], as the Web
> Workers Candidate Recommendation from May 2012[3] substantially predates the
> entire concept of a "settings object", and because the WHATWG is the group
> where work on Workers seems to be being done.
>
> This referential choice was flagged during a discussion of transitioning the
> Upgrade spec to CR, where it was noted that the Web Workers editor's draft
> from May 2014 does contain the referenced concept[4].
>
> It seems appropriate, then, to bring the question to this group: does
> WebApps intend to update the Workers draft in TR? If so, is there a path
> forward to aligning the Workers document with the work that's happened over
> the last year and a half in WHATWG? Alternatively, does WebApps intend to
> drop work on Workers in favor of the WHATWG's document?

Agreed with Hixie; the WHATWG spec is the most recent normative
version of that section, and should be referenced instead.  Remember,
there's nothing wrong with reffing WHATWG specs.  It will not delay or
hamper your publication or Rec-track advancement, despite the
occasional misinformed complaint from someone not aware of the
policies.

~TJ

Normative references to Workers.

[Mike West]

The "Upgrade Insecure Requests" specification[1] references the WHATWG HTML
spec for the
"set up a worker environment settings object" algorithm[2], as the Web
Workers Candidate Recommendation from May 2012[3] substantially predates
the entire concept of a "settings object", and because the WHATWG is the
group where work on Workers seems to be being done.

This referential choice was flagged during a discussion of transitioning
the Upgrade spec to CR, where it was noted that the Web Workers editor's
draft from May 2014 does contain the referenced concept[4].

It seems appropriate, then, to bring the question to this group: does
WebApps intend to update the Workers draft in TR? If so, is there a path
forward to aligning the Workers document with the work that's happened over
the last year and a half in WHATWG? Alternatively, does WebApps intend to
drop work on Workers in favor of the WHATWG's document?

It would be helpful if we could get some clarity here. :)

Thanks!

[1]: https://w3c.github.io/webappsec/specs/upgrade/
[2]:
https://html.spec.whatwg.org/multipage/workers.html#set-up-a-worker-environment-settings-object
[3]: http://www.w3.org/TR/workers/
[4]: https://w3c.github.io/workers/

--
Mike West <mk...@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Re: Normative references to Workers.

[Ian Hickson]

On Tue, 15 Sep 2015, Mike West wrote:
> 
> It seems appropriate, then, to bring the question to this group: does
> WebApps intend to update the Workers draft in TR?

FWIW, I think the W3C should get out of the business of republishing 
WHATWG specifications. It's just adding confusion, especially since the 
W3C drafts are invariably out of date. IMHO the "Upgrade Insecure 
Requests" specification should just reference the WHATWG spec.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Normative references to Workers.

[Daniel Veditz]

On Tue, Sep 15, 2015 at 11:25 AM, Tab Atkins Jr. 
wrote:

> ​there's nothing wrong with reffing WHATWG specs.  It will not delay
> ​ or hamper​
>
> publication or Rec-track advancement, despite the
> ​ occasional misinformed​
>
> complaint from someone not aware of the
> ​ ​
> policies.
>

​When the complaint comes from the office of the Director we have to assume
it's going to hamper us whether or not they are misinformed.

-Dan Veditz​

Re: Normative references to Workers.

[Philippe Le Hegaret]

On 09/15/2015 03:26 PM, Daniel Veditz wrote:

On Tue, Sep 15, 2015 at 11:25 AM, Tab Atkins Jr. <jackalm...@gmail.com
<mailto:jackalm...@gmail.com>> wrote:

​there's nothing wrong with reffing WHATWG specs.  It will not delay
​ or hamper​

publication or Rec-track advancement, despite the
​ occasional misinformed​

complaint from someone not aware of the
​ ​
policies.


​When the complaint comes from the office of the Director we have to
assume it's going to hamper us whether or not they are misinformed.


To be clear here: the point made was that the Web Application Security 
group never asked for a review from the Web Applications working group 
prior to asking for transition to CR. As a consequence, the WebApps 
group did not get an opportunity to review the Upgrade Insecure 
Resources specification [1], including the reference related to Web Workers.
As a reminder, there is an expectation that the specification has 
received wide review prior to the publication of a Candidate Recommendation.


Philippe

[1] http://www.w3.org/TR/upgrade-insecure-requests/

RE: PSA: publishing new WD of Service Workers on June 25

[Jungkee Song]

Thanks for comments. I'll address them in the ED.

I didn't get through them all yet, but

 * in parallel isn't defined, but it sounds like you mean in parallel to the 
 main sequence not in parallel to themselves, I'd strongly encourage a 
 definition.

in parallel is defined here: 
https://html.spec.whatwg.org/multipage/infrastructure.html#in-parallel. Will 
add the links.


Jungkee

 -Original Message-
 From: timeless [mailto:timel...@gmail.com]
 Sent: Wednesday, July 01, 2015 1:23 PM
 To: public-webapps
 Subject: Re: PSA: publishing new WD of Service Workers on June 25
 
 http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-
 service-workers-20150625/
 
  Invoke Run Service Worker algorithm with serviceWorker as the
 arguement [sic].
  Fetch invokes Handle Fetch with request. As a result of performing
 Handle Fetch, the Service Woker [sic] returns a response to Fetch.
 If the client request is under the scope of a service worker
 registration, appplication [sic] cache is completely bypassed regardless
 of whether the client request uses the service worker registration.
 
  Events that correspond to network requests are dispatched to the worker
 and the responses generated by the worker may over-ride* default network
 stack behavior.
 
 override
 
 en-us:
 Let the origin attribute of e be initialized to the Unicode
 serialisation* of the origin specified by the incumbent settings object.
  Service workers define the following behaviours* for install event and
 activate event:
 
 
  When a service worker client is controlled by an active worker, it is
 considered the service worker client is using the active worker's
 containing service worker registration.
 
 
 this is awkward, you might add `that` after `it is`
 
 
  This is conceptually the same operation that UA does maximum once per
 every 24 hours.
 
 this is awkward, you might add `the` before `UA`, `a` after `does` and
 `of` before `once`.
 
  Run the following substeps in parallel:
  1. CheckRegistration: If the result of running Match Service Worker
 Registration algorithm, or its equivalent, with clientURL as its argument
 is not null, then:
  1.1. Set registration to the result value.
  2. Else:
 
 Else seems odd for `run...in parallel`
 
  2.1. Wait until scope to registration map has a new entry.
  2.2. Jump to the step labeled CheckRegistration.
 
 cat spec|grep 'in parallel' | perl -pne 's/\s*,.*,\s*/ ...
 /;s/.*( run)/$1/;s/(the ).*( handler)/$1...$2/;s/^\s*/ /'|sort|uniq -
 c|sort
 -n|perl -pne 's/(?:\s*)(\d*)\s*(.*)\n/$2 [$1]\n/'
  Return the ... handler ... performs the following substeps in
  parallel: [1] Return the ... handler that performs the following
  substeps in parallel: [1] Run the following in parallel: [1] Set p to
  the ... handler that ... performs the following substeps in parallel:
  [1] run the following substeps in parallel: [1] Return the ... handler
  that ... performs the following substeps in parallel: [4] run the
  following substeps in parallel. [4] Run these steps in parallel: [7]
  Run the following substeps in parallel: [10]
 
 * you use steps|substeps interchangeably afaict; you sometimes don't use
 *steps...
 * you use .|: interchangeably
 * various other inconsistent stylistic elements can be seen from the above
 list...
 * in parallel isn't defined, but it sounds like you mean in parallel to
 the main sequence not in parallel to themselves, I'd strongly encourage
 a definition.
 
  The following are the event handlers (and its corresponding event
  handler event types) that must be supported,
 
 pattern:
 event handlers [plural!] (and its ...)
 its = their
 
  The service worker registration's installing worker changes. (See step 8
 of the Install algorithm).
  A WindowClient object has an associated focus state, which is either
 true or false. (Initially false).
 
 pattern:
 misplaced `.`
 
  When event.respondWith(r) method is invoked, the argument, r, must
 resolve with a Response, else a network error is returned to Fetch.
 
 `must .. else` is an odd construct. normally `or` is appropriate...
 
  The Cache objects do not expire unless authors delete the entries.
 
 `objects ... the entries` is odd
 
 the entries = them | objects = object entries ??
 
  This implies that authors should version their caches by name and make
 sure to **use the caches only from the version of the service worker that
 can safely operate on**.
 
 ... = to only use caches that can be safely operated by the current
 version of the service worker.
 
  Cache objects are always enumerable via self.caches in insertion order
  (per ECMAScript 6 Map objects.) Resolve p with the result of running
  the algorithm specified in match(request, options) method of Cache
  interface with request and options as the arguments (providing
  entry.[[value]] as thisArgument to the [[Call]] internal method of
  match(request, options).)
 
 pattern:
 misplaced `.` (the other way...)
 
 
  If r's method

Re: PSA: publishing new WD of Service Workers on June 25

[timeless]

http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150625/

 Invoke Run Service Worker algorithm with serviceWorker as the arguement 
 [sic].
 Fetch invokes Handle Fetch with request. As a result of performing Handle 
 Fetch, the Service Woker [sic] returns a response to Fetch.
If the client request is under the scope of a service worker registration, 
 appplication [sic] cache is completely bypassed regardless of whether the 
 client request uses the service worker registration.

 Events that correspond to network requests are dispatched to the worker and 
 the responses generated by the worker may over-ride* default network stack 
 behavior.

override

en-us:
Let the origin attribute of e be initialized to the Unicode 
 serialisation* of the origin specified by the incumbent settings object.
 Service workers define the following behaviours* for install event and 
 activate event:


 When a service worker client is controlled by an active worker, it is 
 considered the service worker client is using the active worker's containing 
 service worker registration.


this is awkward, you might add `that` after `it is`


 This is conceptually the same operation that UA does maximum once per every 
 24 hours.

this is awkward, you might add `the` before `UA`, `a` after `does` and
`of` before `once`.

 Run the following substeps in parallel:
 1. CheckRegistration: If the result of running Match Service Worker 
 Registration algorithm, or its equivalent, with clientURL as its argument is 
 not null, then:
 1.1. Set registration to the result value.
 2. Else:

Else seems odd for `run...in parallel`

 2.1. Wait until scope to registration map has a new entry.
 2.2. Jump to the step labeled CheckRegistration.

cat spec|grep 'in parallel' | perl -pne 's/\s*,.*,\s*/ ... /;s/.*(
run)/$1/;s/(the ).*( handler)/$1...$2/;s/^\s*/ /'|sort|uniq -c|sort
-n|perl -pne 's/(?:\s*)(\d*)\s*(.*)\n/$2 [$1]\n/'
 Return the ... handler ... performs the following substeps in parallel: [1]
 Return the ... handler that performs the following substeps in parallel: [1]
 Run the following in parallel: [1]
 Set p to the ... handler that ... performs the following substeps in 
 parallel: [1]
 run the following substeps in parallel: [1]
 Return the ... handler that ... performs the following substeps in parallel: 
 [4]
 run the following substeps in parallel. [4]
 Run these steps in parallel: [7]
 Run the following substeps in parallel: [10]

* you use steps|substeps interchangeably afaict; you sometimes don't
use *steps...
* you use .|: interchangeably
* various other inconsistent stylistic elements can be seen from the
above list...
* in parallel isn't defined, but it sounds like you mean in parallel
to the main sequence not in parallel to themselves, I'd strongly
encourage a definition.

 The following are the event handlers (and its corresponding event handler 
 event types) that must be supported,

pattern:
event handlers [plural!] (and its ...)
its = their

 The service worker registration's installing worker changes. (See step 8 of 
 the Install algorithm).
 A WindowClient object has an associated focus state, which is either true or 
 false. (Initially false).

pattern:
misplaced `.`

 When event.respondWith(r) method is invoked, the argument, r, must resolve 
 with a Response, else a network error is returned to Fetch.

`must .. else` is an odd construct. normally `or` is appropriate...

 The Cache objects do not expire unless authors delete the entries.

`objects ... the entries` is odd

the entries = them | objects = object entries ??

 This implies that authors should version their caches by name and make sure 
 to **use the caches only from the version of the service worker that can 
 safely operate on**.

... = to only use caches that can be safely operated by the current
version of the service worker.

 Cache objects are always enumerable via self.caches in insertion order (per 
 ECMAScript 6 Map objects.)
 Resolve p with the result of running the algorithm specified in 
 match(request, options) method of Cache interface with request and options as 
 the arguments (providing entry.[[value]] as thisArgument to the [[Call]] 
 internal method of match(request, options).)

pattern:
misplaced `.` (the other way...)


 If r's method is neither `GET` nor `HEAD` and options.ignoreMethod is false, 
 resolve promise with an empty array.
 If options.ignoreMethod is false and request.method is neither GET nor 
 HEAD, then:

you usually use ``s instead of s around GET/HEAD, which I found
weird, but here you didn't do that, which I find even weirder...

PSA: publishing new WD of Service Workers on June 25

[Arthur Barstow]

This is an announcement of the intent to publish a new Working Draft of 
Service Workers on June 25 using the following document as the basis:


http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150625/

If anyone has any major concerns with this proposal, please speak up 
immediately; otherwise the WD will be published as proposed.


For some implementation data for this spec, see 
http://caniuse.com/#feat=serviceworkers.


-Thanks, ArtB

PSA: publishing new WD of Service Workers on February 5

[Arthur Barstow]

The Service Workers editors - which now includes Jake Archibald (thanks 
Jake!) - would like to publish a new WD of Service Workers and the 
proposed publication date is February 5:


https://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20150205/

If anyone has any major concerns with this, please speak up immediately; 
otherwise the WD will be published as proposed.


-Thanks, ArtB

Re: Clarification of CSP sandbox and workers

[Anne van Kesteren]

On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan de...@cs.stanford.edu wrote:
 I am implementing CSP for Workers in Firefox, but like to get a
 clarification on workers and the sandbox flag. Currently, a Worker can
 inherit or be accompanied by a CSP header. As written, the implications
 of the sandbox directive on the Worker context is not clear.

 [Following up on https://github.com/w3c/webappsec/issues/69]

 Arguably most of the sandbox flags don't make sense for Workers, but the
 empty directive (i.e., just sandbox) and sandbox allow-same-origin can
 have reasonable semantics.  So, if a Worker inherits the CSP from the
 owner document (or parent worker in later specs) or is accompanied by a
 CSP header which has the 'sandbox' directive, should the worker script's
 origin be set to a unique origin?  Or should we just ignore (and
 appropriately warn about) the sandbox flag for Workers and address the
 need for sandboxed Workers separately?

This would affect what a worker can fetch, what storage it has access
to, and which permissions it has (e.g. can it display a notification).
Might be an interesting way to run untrusted code.

But if we are going to do something like this Ian would have to define
how the sandbox directives affect a worker environment.


-- 
https://annevankesteren.nl/

Re: Clarification of CSP sandbox and workers

[Mike West]

The CSP spec should just delegate to HTML here. If/when HTML defines
sandboxing with regard to Workers, CSP will just start using those hooks.

I'd agree, for example, that it does appear that sandboxing a worker into a
unique origin could be interesting. It's not clear to me whether any of the
other flags would be useful, though.

Ian, WDYT?

-mike

--
Mike West mk...@google.com
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Wed, Nov 12, 2014 at 9:45 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan de...@cs.stanford.edu
 wrote:
  I am implementing CSP for Workers in Firefox, but like to get a
  clarification on workers and the sandbox flag. Currently, a Worker can
  inherit or be accompanied by a CSP header. As written, the implications
  of the sandbox directive on the Worker context is not clear.
 
  [Following up on https://github.com/w3c/webappsec/issues/69]
 
  Arguably most of the sandbox flags don't make sense for Workers, but the
  empty directive (i.e., just sandbox) and sandbox allow-same-origin can
  have reasonable semantics.  So, if a Worker inherits the CSP from the
  owner document (or parent worker in later specs) or is accompanied by a
  CSP header which has the 'sandbox' directive, should the worker script's
  origin be set to a unique origin?  Or should we just ignore (and
  appropriately warn about) the sandbox flag for Workers and address the
  need for sandboxed Workers separately?

 This would affect what a worker can fetch, what storage it has access
 to, and which permissions it has (e.g. can it display a notification).
 Might be an interesting way to run untrusted code.

 But if we are going to do something like this Ian would have to define
 how the sandbox directives affect a worker environment.


 --
 https://annevankesteren.nl/

Re: Clarification of CSP sandbox and workers

[Deian Stefan]

+1

Mike West mk...@google.com writes:

 The CSP spec should just delegate to HTML here. If/when HTML defines
 sandboxing with regard to Workers, CSP will just start using those hooks.

Reasonable, the issue also appears outside CSP: if I create a worker in
a sandboxed iframe, what should its origin be? (Or should I not be able
to create a worker in this case?)
 
 I'd agree, for example, that it does appear that sandboxing a worker into a
 unique origin could be interesting. It's not clear to me whether any of the
 other flags would be useful, though.

Right, none of the other flags really make sense. (Though some of the
flags similarly don't make sense when the sandbox directive is applied
to a top-level page.) I do think it's reasonable to wait on the more
general sandboxed worker idea, since some of the proposals in WebAppSec
are thinking about this already.

Thanks,
Deian

Re: Clarification of CSP sandbox and workers

[Ian Hickson]

On Wed, 12 Nov 2014, Mike West wrote:

 The CSP spec should just delegate to HTML here. If/when HTML defines 
 sandboxing with regard to Workers, CSP will just start using those 
 hooks.
 
 I'd agree, for example, that it does appear that sandboxing a worker 
 into a unique origin could be interesting. It's not clear to me whether 
 any of the other flags would be useful, though.
 
 Ian, WDYT?

Happy to add features if browsers are going to implement them. Just file a 
bug describing what the feature is. :-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

PSA: publishing new WD of Service Workers on November 13

[Arthur Barstow]

Jungkee and Alex created a new Working Draft of Service Workers for 
publication as a Technical Report on November 13:


  
http://slightlyoff.github.io/ServiceWorker/publish/service_worker/WD-service-workers-20141113/


If anyone has any major concerns this proposal, please speak up as soon 
as possible.


-Thanks, AB

Clarification of CSP sandbox and workers

[Deian Stefan]

Hey guys,

I am implementing CSP for Workers in Firefox, but like to get a
clarification on workers and the sandbox flag. Currently, a Worker can
inherit or be accompanied by a CSP header. As written, the implications
of the sandbox directive on the Worker context is not clear.

[Following up on https://github.com/w3c/webappsec/issues/69]

Arguably most of the sandbox flags don't make sense for Workers, but the
empty directive (i.e., just sandbox) and sandbox allow-same-origin can
have reasonable semantics.  So, if a Worker inherits the CSP from the
owner document (or parent worker in later specs) or is accompanied by a
CSP header which has the 'sandbox' directive, should the worker script's
origin be set to a unique origin?  Or should we just ignore (and
appropriately warn about) the sandbox flag for Workers and address the
need for sandboxed Workers separately?

Thanks,
Deian


signature.asc
Description: PGP signature

WebApps-ACTION-745: Followup with simon re running the web workers tests

[Web Applications Working Group Issue Tracker]

WebApps-ACTION-745: Followup with simon re running the web workers tests

http://www.w3.org/2008/webapps/track/actions/745

Assigned to: Arthur Barstow

Re: Push API and Service Workers

[Arthur Barstow]

On 10/22/14 1:21 AM, Shijun Sun wrote:

On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote:

If we want to take advantage of this opportunity, perhaps you
should first flesh out specific issue(s) to discuss, and then try to agree on a 
time
+ day slot in advance of the meeting.

Thanks Arthur for the suggestion.

I think we can take a half hour timeslot to discuss the E2E flow for the RTC 
scenarios using push messages.  The goal is to make sure we understand the 
steps and options in the whole E2E story.  If this is a right topic and there 
is enough interest in the group, I can set up a Doodle to help us pick the 
timeslot.


Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27:

https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27

If people want to attend remotely, see:

https://www.w3.org/wiki/Webapps/November2014Meeting#Meeting_Logistics

-Thanks, AB

RE: Push API and Service Workers

[Shijun Sun]

On October 24, 2014 4:30 AM, Arthur Barstow wrote: 

 On 10/22/14 1:21 AM, Shijun Sun wrote:
 I think we can take a half hour timeslot to discuss the E2E flow for the RTC 
 scenarios using push messages.  The goal is to make sure we understand the 
 steps and options in the whole E2E story.  

 Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27:

Thanks Arthur!  

Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be 
more productive for folks having hands-on experience with Service Workers to 
participate. 

Best, Shijun

[1] https://github.com/w3c/push-api/issues/84
[2] https://github.com/w3c/push-api/issues/85 

Re: Push API and Service Workers

[Arthur Barstow]

On 10/24/14 11:36 AM, Shijun Sun wrote:

On October 24, 2014 4:30 AM, Arthur Barstow wrote:

On 10/22/14 1:21 AM, Shijun Sun wrote:

I think we can take a half hour timeslot to discuss the E2E flow for the RTC 
scenarios using push messages.  The goal is to make sure we understand the 
steps and options in the whole E2E story.

Shijun - I just added a 13:00-13:30 Push API slot on Monday October 27:

Thanks Arthur!

Since we could touch the Service Workers topics (e.g. [1][2]), I expect it'd be 
more productive for folks having hands-on experience with Service Workers to 
participate.


Good point. Since Jungkee is attending the meeting (and I'll chase after 
Alex to see if he can join), I created a 13:00-14:00 Push API and 
Service Workers block on Monday and added links to the 2 issues below.


https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27

-Art


Best, Shijun

[1] https://github.com/w3c/push-api/issues/84
[2] https://github.com/w3c/push-api/issues/85

Re: Push API and Service Workers

[Tab Atkins Jr.]

On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote:
 * Push doesn't actually need SW's ability to intercept network
 communications on behalf of a web page.
 * You can imagine a push-handling SW that does all sorts of
 complicated processing of notifications, downloading things to a local
 database, but does not cache/intercept a web page.
 * This ties into the discussion of whether it should be possible to
 register a SW without giving it a network-intercept namespace

As was discussed over in
https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60304515
earlier today, you need a scope for all uses of SW, because you need
to *request permission* on a *page*, not within a SW (so the user has
appropriate context on whether to grant the permission or not), and
the scope maps the page to the SW that the registration is for.

(The permission grant is actually per-origin, not per-scope/SW, but
the registration itself is per-scope/SW, and it has to be done from
within a page context because there *might* be a permission grant
needed.)

~TJ

Re: Push API and Service Workers

[Jonas Sicking]

On Thu, Oct 23, 2014 at 2:27 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Tue, Oct 21, 2014 at 7:25 AM, Erik Corry erikco...@google.com wrote:
 * Push doesn't actually need SW's ability to intercept network
 communications on behalf of a web page.
 * You can imagine a push-handling SW that does all sorts of
 complicated processing of notifications, downloading things to a local
 database, but does not cache/intercept a web page.
 * This ties into the discussion of whether it should be possible to
 register a SW without giving it a network-intercept namespace

 As was discussed over in
 https://github.com/slightlyoff/ServiceWorker/issues/445#issuecomment-60304515
 earlier today, you need a scope for all uses of SW, because you need
 to *request permission* on a *page*, not within a SW (so the user has
 appropriate context on whether to grant the permission or not), and
 the scope maps the page to the SW that the registration is for.

 (The permission grant is actually per-origin, not per-scope/SW, but
 the registration itself is per-scope/SW, and it has to be done from
 within a page context because there *might* be a permission grant
 needed.)

Yes, you need to ask for permission within a page. But that page
doesn't have to have any particular relation to the scope of the SW
that it's asking for. It just needs to be same-origin with that SW.

As the API is structured, any page on a website can grab any SW
registration, and call registerPush or registerGeoFence on that SW
registration.

So I don't see how the scope of the SW matters.

/ Jonas

RE: Push API and Service Workers

[Jake Archibald]

On 21 Oct 2014 16:53, Shijun Sun shij...@microsoft.com wrote:

 On Monday, October 20, 2014 9:42 AM, Jake Archibald wrote:
 Things I guess you'd do as a result of a push message:

 One of the most typical scenarios is
 * show a toast notification (e.g. for a new email)
 * user chooses to dismiss the notification, so not to read the email
right away

 That is it.  From the power efficiency perspective, the browser itself
doesn't have to always wake up to process the push message.  It should be a
decision by web developers whether the message should be handled explicitly
by the service worker every time it arrives.

To reiterate from my previous message:

Updating caches should be common, and it's something most native apps get
very wrong. Take Twitter for example, I can tap a notification that shows a
partial tweet, but I have poor/no connectivity so the full tweet doesn't
load. The notification is now gone, so I'm left with less information than
I had before I tapped the notification. Twitter should download and cache
the full tweet before showing the notification.

Taking the email example specifically, the gmail app does the right thing.
Not only do you get a notification, but the email is also cached for
offline viewing so tapping the notification works regardless of
connectivity at moment of tapping.

This is exactly the wrong time to guess what high-level things developers
want to do and build APIs to do those imagined things.

Re: Push API and Service Workers

[Arthur Barstow]

On 10/16/14 5:52 PM, Shijun Sun wrote:

On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote

If the push message is being used to deliver a call notification, that sort of 
delay will definitely be noticed.  And I'm assuming that you've tested on a 
high end Nexus or something like that.  Add the latencies involved in waking an 
idle device and that turns into a very long post-dial delay.  People abandon 
calls for that sort of delay.

Not saying that you are doing it wrong or anything, but just trying to set the 
right expectations.

The RTC scenario is listed explicitly as one of the use cases in the Push API 
wiki [1].  I expect there is enough interest in the group.  Should we allocate 
some cycles in TPAC to figure out details of the E2E flow?


Re scheduling time at TPAC with non group members and remote 
participants ...


We can accommodate remote participants via the W3C phone conference 
bridge and we will use the W3C's #webapps IRC channel (see [1]). If we 
want to take advantage of this opportunity, perhaps you should first 
flesh out specific issue(s) to discuss, and then try to agree on a time 
+ day slot in advance of the meeting. (Currently, there are quite a few 
open slots on Oct 27 and 28 [2].)


-AB

[1] https://www.w3.org/wiki/Webapps/November2014Meeting#Meeting_Logistics
[2] 
https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27

RE: Push API and Service Workers

[Shijun Sun]

On Tuesday, October 21, 2014 2:27 PM, Arthur Barstow wrote:
 If we want to take advantage of this opportunity, perhaps you 
 should first flesh out specific issue(s) to discuss, and then try to agree on 
 a time 
 + day slot in advance of the meeting. 

Thanks Arthur for the suggestion.

I think we can take a half hour timeslot to discuss the E2E flow for the RTC 
scenarios using push messages.  The goal is to make sure we understand the 
steps and options in the whole E2E story.  If this is a right topic and there 
is enough interest in the group, I can set up a Doodle to help us pick the 
timeslot. 

Re: Push API and Service Workers

[Martin Thomson]

On 19 October 2014 19:18, Shijun Sun shij...@microsoft.com wrote:
 It'd be great if the Push API spec allows the web developers to have 
 flexibility to leverage the generic actions, or rely on a service worker, or 
 maybe doing both.

I imagine that we will permit the use of whatever a service worker has
access to.  Some of that is going to require prior arrangement (i.e.,
consent prompts might be required to enable a full screen alert,
though maybe toasts).

RE: Push API and Service Workers

[Shijun Sun]

On Monday, October 20, 2014 5:41 AM, Martin Thomson wrote:
 I imagine that we will permit the use of whatever a service worker has access 
 to.  Some of that is going to require prior arrangement (i.e., consent 
 prompts might be required to enable a full screen alert, though maybe toasts).

Fully agree that we should follow the same user consent requirement.  

BTW, I have opened a spec bug to track the topic 
(https://www.w3.org/Bugs/Public/show_bug.cgi?id=27108). 

Thanks, Shijun 

Re: Push API and Service Workers

[Jake Archibald]

On 20 October 2014 03:18, Shijun Sun shij...@microsoft.com wrote:

 What I'd like to get across is when the push client can handle generic
 actions already, such as posting a toast notifications, waking up the
 browser (or a subset of it) and let service workers to display each
 notification might not be the best practice from performance perspective,


Things I guess you'd do as a result of a push message:

* Update caches
* Show a notification
* Focus a tab  tell it to do something

Updating caches should be common, and it's something most native apps get
very wrong. Take Twitter for example, I can tap a notification that shows a
partial tweet, but I have poor/no connectivity so the full tweet doesn't
load. The notification is now gone, so I'm left with less information than
I had before I tapped the notification. Twitter should download and cache
the full tweet before showing the notification.

On top of that, there are conditions that could mean I don't want to show a
notification, or hide an existing one:

* User already has relevant content focused  visible
* User reads the content elsewhere (a push message would trigger the hiding
of the current notification)

Also, if the user dismisses the notification, I may wish to send that info
back to the server, and push a message that hides the notification on other
devices. When you multiply that all together, we've got a large API, and
we've probably done the appcache thing and forgotten about particular
use-cases.

In terms of RTC, let's imagine we receive a Jeff's calling push message.
At this point I'd want to:

* If there isn't a tab open to the calling app, open one
* Else use the existing one
* Focus it (forcing it over any lock screen - we don't have a way to do
this yet)
* postMessage the page telling it who's calling
* If a call is already in progress, show a small overlay indicating the new
call, with handling options
* Else show a full screen Jeff's calling message with handling options,
play ringtone until handled

If the call is answered on a particular device, you'll want to push to
other devices to stop ringing.

That's a rough design for what I think should happen, other people may have
better ideas. I don't think now's the time to give a particular design a
high-level API. I'd rather follow the extensible web model and expose the
primitives, then build higher level bits based on common patterns that are
observed.

Re: Push API and Service Workers

[Jonas Sicking]

On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@microsoft.com wrote:
 My understanding here is that we want to leverage the push client in the 
 OS.  That will provide new capabilities without dependency on a direct 
 connection between the app and the app server.

Yes, this is how the spec is defined. The spec leaves it up to the
implementation how to transport the information from the push server
to the device. This part is entirely transparent to the webapp, even
once we specify the server side of the push feature, and so is up to
the implementation to do through whatever means it wants.

/ Jonas

RE: Push API and Service Workers

[Shijun Sun]

On Sunday, October 19, 2014 6:43 PM, Jonas Sicking wrote:
On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@microsoft.com wrote:
 My understanding here is that we want to leverage the push client in the 
 OS.  That will provide new capabilities without dependency on a direct 
 connection between the app and the app server.

Yes, this is how the spec is defined. The spec leaves it up to the 
implementation how to transport the information from the push server to the 
device. This part is entirely transparent to the webapp, even once we specify 
the server side of the push feature, and so is up to the implementation to do 
through whatever means it wants.

Yes, I understand the spec is independent from how push server communicates to 
the device.  

What I'd like to get across is when the push client can handle generic 
actions already, such as posting a toast notifications, waking up the browser 
(or a subset of it) and let service workers to display each notification might 
not be the best practice from performance perspective, especially when the user 
does not want to pick up each incoming video call or read each incoming emails 
right away.  It'd be great if the Push API spec allows the web developers to 
have flexibility to leverage the generic actions, or rely on a service worker, 
or maybe doing both.

To folks who are interested, here is a link [1] to how the push client and push 
server operate on current Windows devices.  As we indicated there, 
power-efficient is quite important to the scenarios. 

[1] http://msdn.microsoft.com/en-us/library/windows/apps/hh913756.aspx 

Thanks, Shijun 

Re: Push API and Service Workers

[Nikhil Marathe]

On Wed, Oct 15, 2014 at 3:07 PM, Shijun Sun shij...@microsoft.com wrote:

 My understanding here is that we want to leverage the push client in the
 OS.  That will provide new capabilities without dependency on a direct
 connection between the app and the app server.


You are correct about leveraging the underlying platform's push system, but
without a serviceworker you still require the webapp itself to have an open
window to handle the request, otherwise you risk launching an app with a UI
when the user is not expecting it.

Now the same thing can be accomplished by a push specific system where the
app author declares a tiny JS file to be used as the push handler. In this
case the 'tiny JS file' is the serviceworker since we are already building
the infrastructure in.

Nikhil

Re: Push API and Service Workers

[Anne van Kesteren]

On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@microsoft.com wrote:
 This is very helpful.  I assume the browser running the service worker can 
 be a very light-weight version (or a subset of the full browser) since we 
 don't need to render an actual webpage.  Is that the right expectation?

If you can split that somehow it might be somewhat lighter weight,
yes, but I wouldn't expect that to be easy.


 I agree we don't want to display a notification for each push message.  
 Meanwhile, for certain type of messages (e.g. realtime communications), we 
 don't want to miss them or delay them, e.g. an incoming video call.  I'm 
 trying to figure out which of the following should be the right flow for the 
 scenario.  Please let me know if you see other options.

I started an exploratory thread on letting the service worker open up
some kind of window that could help with this, but I suspect it's
still too early.


   (1) the Push Client displays a notification right away, the user chooses to 
 pick up the call or dismiss, the browser launch with the app based on user 
 decision.
   (2) The Push Client wakes up the browser, which start the service worker, 
 which pushes a notification, then the user can decide whether to answer the 
 call, the app launches based on user decision or browser goes back to sleep.

 Re #2, I'm still fuzzy about the schedule of the service worker, so ask the 
 question again, would there be a delay if the service worker is not scheduled 
 to run when the message comes in?

(1) will also likely involve a service worker or an even slower
network fetch to get to the application, as I pointed out.


-- 
https://annevankesteren.nl/

RE: Push API and Service Workers

[Shijun Sun]

On Thursday, October 16, 2014 8:29 AM, Anne van Kesteren wrote

On Thu, Oct 16, 2014 at 5:22 PM, Shijun Sun shij...@microsoft.com wrote:
   (1) the Push Client displays a notification right away, the user chooses 
 to pick up the call or dismiss, the browser launch with the app based on 
 user decision.
   (2) The Push Client wakes up the browser, which start the service worker, 
 which pushes a notification, then the user can decide whether to answer the 
 call, the app launches based on user decision or browser goes back to sleep.

 Re #2, I'm still fuzzy about the schedule of the service worker, so ask the 
 question again, would there be a delay if the service worker is not 
 scheduled to run when the message comes in?

(1) will also likely involve a service worker or an even slower network fetch 
to get to the application, as I pointed out.

Re#1, most devices have native push client already which can connect to its 
notification servers in the cloud.  I expect simple/generic actions can be 
defined without involving any script engine (or service worker).  RE the 
slower network fetch, it might not be the best user experience on mobile 
devices if we open up websockets and prefetch the app page before the user 
consent (i.e. to pick up the call).  Of course, it can be a developer decision 
if the spec (and web platforms) provide the options.

Re #2, it'd be great if some folks could comment on the scheduling and latency 
question.  

Thanks, Shijun

Re: Push API and Service Workers

[Martin Thomson]

On 16 October 2014 08:55, Shijun Sun shij...@microsoft.com wrote:
 Re #2, it'd be great if some folks could comment on the scheduling and 
 latency question.

There are number of variations on how this all works out.  And
multiple sources of latency.

A mobile device in a low power state follows a process that is approximately:
 1. network pages the device
 2. device establishes a network context (considerable delay in some
cases here...I've heard 2s isn't unusual...gah!)
 3. network delivers the push message
 4. OS delivers to push service on device
 (some services may initiate a user notification at this point
based on the message contents, but it isn't a default mode)
 5. OS awakens a push handler (a subset of the application)
 6. push handler runs code to determine what to do, which may be

Steps 5 and 6 are entirely analogous to the service worker case.  The
problem that Anne highlighted is the risk that the service worker
requires download and installation when the event arrives.

I think that we should be recommending that push messages are run from
a previously installed (and cached) service worker.  Latency really
matters here.  We could, of course, get fancy and require update of
the SW if it has expired from cache, or maybe allow update for
messages that are marked low priority, but I'd consider that to be a
second-order optimization.

Re: Push API and Service Workers

[John Mellor]

On 16 October 2014 16:22, Shijun Sun shij...@microsoft.com wrote:

 On Thursday, October 16, 2014 12:42 AM, Anne van Kesteren wrote:
  You need a browser to run a service worker. The browser is pinged and it
 might then decide to start running a service worker to process the incoming
 message, or maybe decide to hold onto it for a bit. If the browser is not
 running it might be booted, depends a bit on the implementation details.
 That will likely evolve over time.

 This is very helpful.  I assume the browser running the service worker
 can be a very light-weight version (or a subset of the full browser) since
 we don't need to render an actual webpage.  Is that the right expectation?


Yes, the subset required by Service Workers consists of things like a
JavaScript engine, network stack, local storage, and an implementation of
the APIs exposed to Service Workers. But you don't need a DOM tree,
rendering/graphics, UI etc. So the battery cost and RAM usage can both be
reduced somewhat, depending on how modular your browser architecture is.

Without service workers that application might not load fast enough over
 the network to take that call. Also, it seems undesirable to always get a
 notification for each incoming push message. It should just be a new
 communication channel for the application.

 I agree we don't want to display a notification for each push message.
 Meanwhile, for certain type of messages (e.g. realtime communications), we
 don't want to miss them or delay them, e.g. an incoming video call.  I'm
 trying to figure out which of the following should be the right flow for
 the scenario.  Please let me know if you see other options.

   (1) the Push Client displays a notification right away, the user chooses
 to pick up the call or dismiss, the browser launch with the app based on
 user decision.
   (2) The Push Client wakes up the browser, which start the service
 worker, which pushes a notification, then the user can decide whether to
 answer the call, the app launches based on user decision or browser goes
 back to sleep.

 Re #2, I'm still fuzzy about the schedule of the service worker, so ask
 the question again, would there be a delay if the service worker is not
 scheduled to run when the message comes in?


I'm not sure what you mean by 'scheduled', but no. A key benefit of Service
Workers is that the browser can start and stop them whenever it feels like.
Thus Service Workers are usually stopped, and get woken up on demand to
handle events like incoming push messages.

In our prototype on Android, it takes less than a second (not yet
optimized) to wake up Chrome from a cold start and handle the event in a
Service Worker (the demo writes to IndexedDB and shows a notification),
versus less than 100ms to handle the event when Chrome and the SW are
already running. Since push messages aren't usually triggered by a user
action (like a button click), but instead by some external event, these
latencies are already likely to be imperceptible to users.

(If you're interested in scheduling SWs to run periodically in the
background, there's been a proposed Background Sync
https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md API
that might permit that; but that's independent from the Push API).

Hope that helps,
John

Best, Shijun

Re: Push API and Service Workers

[Martin Thomson]

On 16 October 2014 11:17, John Mellor joh...@google.com wrote:

 In our prototype on Android, it takes less than a second (not yet optimized)
 to wake up Chrome from a cold start and handle the event in a Service Worker
 (the demo writes to IndexedDB and shows a notification), versus less than
 100ms to handle the event when Chrome and the SW are already running. Since
 push messages aren't usually triggered by a user action (like a button
 click), but instead by some external event, these latencies are already
 likely to be imperceptible to users.

If the push message is being used to deliver a call notification, that
sort of delay will definitely be noticed.  And I'm assuming that
you've tested on a high end Nexus or something like that.  Add the
latencies involved in waking an idle device and that turns into a very
long post-dial delay.  People abandon calls for that sort of delay.

Not saying that you are doing it wrong or anything, but just trying to
set the right expectations.

RE: Push API and Service Workers

[Shijun Sun]

On Thursday, October 16, 2014 11:46 AM, Martin Thomson wrote
 If the push message is being used to deliver a call notification, that sort 
 of delay will definitely be noticed.  And I'm assuming that you've tested on 
 a high end Nexus or something like that.  Add the latencies involved in 
 waking an idle device and that turns into a very long post-dial delay.  
 People abandon calls for that sort of delay.
 
 Not saying that you are doing it wrong or anything, but just trying to set 
 the right expectations.

The RTC scenario is listed explicitly as one of the use cases in the Push API 
wiki [1].  I expect there is enough interest in the group.  Should we allocate 
some cycles in TPAC to figure out details of the E2E flow?

[1] http://www.w3.org/2008/webapps/wiki/Push_API

Push API and Service Workers

[Shijun Sun]

Hi,

I'm with the IE Platform team at Microsoft.  I joined the WebApps WG very 
recently.  I am looking into the Push API spec, and got some questions.  Hope 
to get help from experts in the WG.

The current API definition is based on an extension of the Service Workers.  
I'd like to understand whether the Service Workers is a must-have dependency 
for all scenarios.  It seems some basic scenarios can be enabled without the 
Service Worker if the website can directly create a PushRegistrationManager.  
I'm looking at Fig. 1 in the spec.  If the user agent can be the broker between 
the Push client and the webpage, it seems some generic actions can be defined 
without the Service Workers - for example immediately display a toast 
notification with the push message.

It is very likely I have missed some basic design principle behind the current 
API design.  It'd be great if someone could share insights on the scenarios and 
the normative dependency on the Service Workers.

All the Best, Shijun

RE: Push API and Service Workers

[Domenic Denicola]

I'm not an expert either, but it seems to me that push without service workers 
(or some other means of background processing) is basically just server-sent 
events. That is, you could send push notifications to an active webpage over 
a server-sent events channel (or web socket, or long-polling...), which would 
allow it to display a toast notification with the push message.

So from my perspective, implementing the push API without service workers would 
be pretty pointless, as it would give no new capabilities.

RE: Push API and Service Workers

[Shijun Sun]

My understanding here is that we want to leverage the push client in the OS.  
That will provide new capabilities without dependency on a direct connection 
between the app and the app server.

-Original Message-
From: Domenic Denicola [mailto:dome...@domenicdenicola.com] 
Sent: Wednesday, October 15, 2014 2:59 PM
To: Shijun Sun; public-webapps
Subject: RE: Push API and Service Workers

I'm not an expert either, but it seems to me that push without service workers 
(or some other means of background processing) is basically just server-sent 
events. That is, you could send push notifications to an active webpage over 
a server-sent events channel (or web socket, or long-polling...), which would 
allow it to display a toast notification with the push message.

So from my perspective, implementing the push API without service workers would 
be pretty pointless, as it would give no new capabilities.

Re: Push API and Service Workers

[Jonas Sicking]

The hard question is: What do you do if there's an incoming push
message for a given website, but the user doesn't have the website
currently open.

Service Workers provide the primitive needed to enable launching a
website in the background to handle the incoming push message.

Another solution would be to always open up a browser tab with the
website in it. But that's only correct behavior for some types of push
messages. I.e. some push messages should be handled without any UI
being opened. Others should be opened by launching a attention
window which is rendered even though the phone is locked. Others
simply want to create a toast notification.

We could add lots of different types of push messages. But that's a
lot of extra complexity. And we'd have to add similar types of
geofencing registrations, and types of alarm clock registrations,
etc.

The current design separates the trigger from what to do when the
trigger fires. Which both makes for a smaller API, and for a more
flexible design.

/ Jonas



On Wed, Oct 15, 2014 at 2:42 PM, Shijun Sun shij...@microsoft.com wrote:
 Hi,



 I'm with the IE Platform team at Microsoft.  I joined the WebApps WG very
 recently.  I am looking into the Push API spec, and got some questions.
 Hope to get help from experts in the WG.



 The current API definition is based on an extension of the Service Workers.
 I'd like to understand whether the Service Workers is a must-have dependency
 for all scenarios.  It seems some basic scenarios can be enabled without the
 Service Worker if the website can directly create a PushRegistrationManager.
 I'm looking at Fig. 1 in the spec.  If the user agent can be the broker
 between the Push client and the webpage, it seems some generic actions can
 be defined without the Service Workers - for example immediately display a
 toast notification with the push message.



 It is very likely I have missed some basic design principle behind the
 current API design.  It'd be great if someone could share insights on the
 scenarios and the normative dependency on the Service Workers.



 All the Best, Shijun

Re: Push API and Service Workers

[John Mellor]

On 15 October 2014 23:07, Shijun Sun shij...@microsoft.com wrote:

 My understanding here is that we want to leverage the push client in the
 OS.  That will provide new capabilities without dependency on a direct
 connection between the app and the app server.


The Push API doesn't use a direct connection between the app and the app
server: instead it assumes that there is a direct connection between the UA
and a push server of the UA's choice. Then the app server can send messages
to the push server, which relays them to the UA, which delivers them to the
Service Worker.

For example Android devices already maintain a persistent connection to
Google Cloud Messaging (GCM) servers, so in our current prototype in Chrome
for Android, we set GCM as the endpoint
https://w3c.github.io/push-api/#widl-PushRegistration-endpoint to which
the app server sends messages, and GCM relays the messages to the Android
device, which wakes up Chrome, which launches a Service Worker, and then
app JS handles the message.

--John

Re: Push API and Service Workers

[Martin Thomson]

On 15 October 2014 14:58, Domenic Denicola dome...@domenicdenicola.com wrote:
 So from my perspective, implementing the push API without service workers 
 would be pretty pointless, as it would give no new capabilities.

That's not strictly true.  If I sit (as I do) with a tab open to gmail
for a very long time, then it is of some advantage to me (and my
network usage) to use something like push rather than websockets (or
even server sent events).  Besides, server sent events might be
roughly equivalent, but they are horribly kludgy and suffer from
robustness issues.

RE: Push API and Service Workers

[Shijun Sun]

Thanks folks for the quick responses to the questions! 

RE: [Martin Thomson] If I sit (as I do) with a tab open to gmail for a very 
long time, then it is of some advantage to me (and my network usage) to use 
something like push rather than websockets (or even server sent events).  
Besides, server sent events might be roughly equivalent, but they are horribly 
kludgy and suffer from robustness issues.

I think Martin made a very good point.  For mobile devices, it is certainly 
undesirable to keep the websockets for a long time.

RE: [Jonas Sicking] The current design separates the trigger from what to do 
when the trigger fires. Which both makes for a smaller API, and for a more 
flexible design.

That is a valid argument.  To be clear, my question right now is not whether we 
need Service Workers in the spec.  I'd like to understand how that works in 
typical scenarios and whether we need it in all scenarios.

RE: [John Mellor] For example Android devices already maintain a persistent 
connection to Google Cloud Messaging (GCM) servers, so in our current prototype 
in Chrome for Android, we set GCM as the endpoint to which the app server sends 
messages, and GCM relays the messages to the Android device, which wakes up 
Chrome, which launches a Service Worker, and then app JS handles the message.

My expectation would be the device (i.e. the push client) will pass the message 
to the Service Worker (when it is active), and then the Service Worker will 
wake up the browser.  Anyway, my excuse to be new to the area ;-)

Let's take the GCM example from another angle.  Assuming we have a WebRTC app, 
which has registered for a push notification at GCM.  Now there is an incoming 
video call, while the browser is still inactive.  The notification from the web 
server will go to the GCM, which relays it to the device push client, which 
displays a toast notification *right away*, when user clicks, the browser is 
launched with the webapp to take the call.

Is this a reasonable expectation for the E2E scenario?  Would there be extra 
latency if we want to wait for the Service Worker to be ready (based on its 
schedule), which then pushes a web notification for user to take the call (or 
dismiss the call)?  

Best, Shijun

[Bug 24691] Allow shared Web workers to persist across page loads from same origin

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24691

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 26957] Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26957

Ms2ger ms2...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ms2...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #4 from Ms2ger ms2...@gmail.com ---
Closing for all the same reasons as before.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 26957] New: Allow sending DOM objects to Workers and expose a DOM (or DOM-like) interface to workers

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26957

Bug ID: 26957
   Summary: Allow sending DOM objects to Workers and expose a DOM
(or DOM-like) interface to workers
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Web Workers (editor: Ian Hickson)
  Assignee: i...@hixie.ch
  Reporter: brunoa...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

I'd like to revive this bug and ask for a minor alternative that might be
possible and OK to go for.

The idea is to allow passing document fragments to worker threads (document
fragments only).

The main idea is that, sometimes, a large amount of changes or analysis are
required to be made to the DOM.

By allowing sending a fragment to a worker thread, the overhead required to
translate all the DOM send into an analyzable format.
You may even require
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode
Or some work adapting the content to the worker. As long as that is made in the
other thread, there's no issue on my end.


The main use case here is:
Extensive work is required to be made on a subtree of a page's DOM.
Here's an example generic use-case.

1. The main thread splits the DOM tree into parts and then it sends those parts
to the worker threads.
2. The worker threads do the DOM changes.
3. The worker threads send the changed DOM to the original thread.
4. The original thread integrates the changed DOM nodes from the workers into
it's own DOM.


The requirements for my use-case are:

 --- Worker having a nearly complete document DOM --- 
This document is not connected to any interface. In other words, it acts the
same way as a documentFragment towards everything (actually, it can even be an
actual documentFragment, if possible).
Any changes to it only changes that DOM tree inside the worker thread.

 --- You can pass DOM objects ---
A passed DOM object is read-only on the destination until
http://www.w3.org/TR/DOM-Level-2-Core/core.html#Core-Document-importNode
(or equivalent) is called. This one may be harder to do because there's no
synchronization and implementing a copy-on-write may just be too much.
OR
Passing a DOM is made by cloning it to the document that resides in the worker
thread. The result of that clone is equivalent of passing it through the
importNode() method. This one should be the easiest to implement. It may be
slower, but then it should only affect performance for the first send
(considering that there are multiple workers).

There can be optimizations here such as for documentFragment. If transfering a
documentFragment it could behave just like a Transferable such as ArrayBuffer
(once transfered, it cannot be accessed from the source thread). As far as I
know, there's no way for a change in a documentFragment to be reflected in the
interface's document and vice-versa but there can be internal code requirements
that make this optimization impossible.


If this is enabled, when the parsing work on the js side is more complicated,
it may be sent to the worker thread to deal with the specifics and still have
tree-like operations with Nodes that look like the interface's DOM.


Just to keep it clear:
- This is still not memory sharing, just memory transfer or memory ownership
transfer.
- All changes inside the worker do not reflect on any other thread. I.E.
changes on a specific thread's DOM documents do not reflect on any other
thread's DOM documents.

-- 
You are receiving this mail because:
You are on the CC list for the bug.