Subject: Re: Few proposal seem to have not attract any attention from the working groups.

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 May 2019 09:28:38 +0100

Hi Wesley,

Generally speaking, if there isn't any response (on the list or elsewhere), it indicates people aren't interested in the proposal, or that they don't believe it's viable. 

If folks do have thoughts about this and just missed it the first time around, please do follow up.

Cheers,

> On 20 May 2019, at 7:50 am, Oliver, Wesley, Vodacom South Africa (External) <[email-masked]> wrote:
> 
> 
> Hi all,
> 
> Hope all is well in the world of the web.
> 
> The following proposals below didn’t seem to seem to attract any attention from the working group.
> 
> Has the process of the working groups changed?
> 
> Is there anyone interested in solving these issues or should be run by google for the chrome browser.
> 
> The other thing we think is highly relevant now days is that all session tokens should have been privately encrypted
> By the server backing store or environment and encryption key rolled aggressively, making token hacking or anything of the sorts a lot more difficult to achieve in hacking the client side session information to gain access  and by assuming the identity of another session.
> 
> Kind Regards,
> 
> Wesley Oliver
> 
> ------------------------
> ---------- Forwarded message ---------
> From: Wesley Oliver <[email-masked]>
> Date: Sun, May 12, 2019 at 7:51 PM
> Subject: Proposal for new header field: SESSION_FORWARD_IDENTITY
> To: [email-masked] Group <[email-masked]>
> 
> 
> Hi all,
> 
> I am sure by now the the EU with there new cookie laws has drive everyone nuts already and annoyed them enough!
> 
> I would like to propose that for session tracker that we implemented a new session_forward_identitiy field header, in which the server will supply the value in the http response and the client browser will then for all further request to the server append the session_forward_dentitiy field header for that domain.
> 
> Similar to cookies, but there is no local storage of anything, its a pure ephemeral value and is basically lost, when one navigates away from the domain, it is lost. 
> 
> Basically like adding the tracking token onto the end of every url request made from your
> website/app, client browser request, which requires each url to be dynamic generated, which in most web apps is not a problem. But for simple reporting type pages that are tobe kept simple, then allowing the browser automatically do this for you in the background simplifiers things.
> 
> Hopefully this would reduce the amount of cookie type EU regulations we need to accept before entering a website, were by they can rather use other alternative forms that are potentially less subject to tracking a user outside the scope of the current domain requirements.
> 
> We might need to typically add another public accessible header variant version for google analytics and similar things, for personal web domains, which is more public to linking session information, but not out of the domain context, this could become difficult for 3rd party scripts that are loading into an application, that may look for this then send back to there server. But they would have to continually send information for each page back to there server, as they would n't be allowed to use any form of local storage, except for maybe single access once off granted access, similar to how mobile permissions handle things, to get long term webapp session key from local storage.
> 
> Just think that there is a simper way to get around all these EU cookies notifications
> and achieves what we require with looking to a future method, that suits 21st century http requirements.
> 
> Kind Regards,
> 
> Wesley Oliver
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: [email-masked]
> 
> 
> -- 
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: [email-masked]
> 
> ------------------
> 
> ---------- Forwarded message ---------
> From: Wesley Oliver <[email-masked]>
> Date: Sun, May 12, 2019 at 7:29 PM
> Subject: Proposal for new header field: SERVER_UTC_TIME
> To: [email-masked] Group <[email-masked]>
> 
> 
> Hi all,
> 
> I would like to potentially propose that we added a new complosurary header to http
> that all servers should in future send with all the response to the client, this is to solve a problem that client system upstream time providers may be incorrectly, which then cause
> browser caching to become unreliable!
> 
> This problem typically is quite prevalent, when it comes to mobile networks, were
> cell phones and devices sync there time to the network, however, at many times
> the providers of the network time information are out of sync.
> 
> This cause many to have extremely bad internet experiences and seeing older shadow copies of content all of sudden when hopping on to a new mobile BS/HS upstream provider,
> that sudden puts on time back.
> 
> I have experience quite a few issues with regards to different real time reflecting situations.
> 
> Given that non one developing something for the client side browser, wants to something so fickle to the upstream provider, which can break on client side browser experience that one has work so hard t perfect and maybe opermize.
> 
> I would like to propose that we include a new http header SERVER_UTC_TIME, in which the client side browser, can then uses some statistics, between all open domains and local clock time, to determine what utc time should be, and then use that website domain.
> Typically is the website domain off, or is the local clock off.. and make a call.
> 
> With every browser request has the ability to determine the correct browser time, to within a request response time for a domain, say typically bring it to with in 1 second of accuracy.
> This would then ensure that the website still functions correctly. 1 second of 4 second worse case for instance, is still better than 5/10 minutes of the local clock being out.
> 
> The same problem with mobile, typically happens with lat/lon provider by the BS sites, they are usually wrong... However, that can't be address via a header.
> 
> Kind Regards,
> 
> Wesley Oliver
> 
> -- 
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: [email-masked]
> 
> 
> -- 
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: [email-masked]
> 
> ————————————————————————
> 
> 
> 
> This e-mail is classified C2 - Vodacom Restricted - Information to be used inside Vodacom but it may be shared with authorised partners. 
> 
> 
> 
> 
> 
> 
> 
> "This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link https://webmail.vodacom.co.za/tc/default.html "

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

---

From: Kari Hurtta <[email-masked]>
Date: Sat, 25 May 2019 09:02:33 +0300 (EEST)

In broad sense that have some similarities with

Sec-Http-State -header field proposal:

  Formalizing the HTTP State Tokens proposal.
  https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0249.html

  https://tools.ietf.org/html/draft-west-http-state-tokens-00

Except that token for Sec-Http-State -header field is generated by browser
so that web site can not store retrievable data, but it is not that 
ephemeral (default max-age is 3600 second (1 hour) and there is some kind
Token Storage). And HTTP State Token is not accessible from scripts.

Yes, when there is no local storage for  session_forward_identity,
cookie laws do not apply (at least if it is ephemeral (up to some hours)).

For Sec-Http-State that was questioned

   https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0006.html

However if it is used for just for login sessions, opt-in is not required.
Also opt-in is not required for similar cookies.

I'm using http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm
here for reference

----------------------------------- start quote ---
 EU legislation on cookies

EUROPA websites must follow the Commission's guidelines on privacy and
data protection and inform users that cookies are not being used to
gather information unnecessarily.

The ePrivacy directive – more specifically Article 5(3) – requires
prior informed consent for storage or for access to information stored
on a user's terminal equipment. In other words, you must ask users if
they agree to most cookies and similar technologies (e.g. web beacons,
Flash cookies, etc.) before the site starts to use them.

For consent to be valid, it must be informed, specific, freely given
and must constitute a real indication of the individual's wishes.

However, some cookies are exempt from this requirement. Consent is not required if the cookie is:

‣    used for the sole purpose of carrying out the transmission of a communication, and

‣    strictly necessary in order for the provider of an information society service explicitly
     required by the user to provide that service.

Cookies clearly exempt from consent according to the EU advisory body on data protection- WP29pdf include:

‣    user‑input cookies (session-id) such as first‑party cookies to keep track of the user's input
     when filling online forms, shopping carts, etc., for the duration of a session or persistent
     cookies limited to a few hours in some cases
‣    authentication cookies, to identify the user once he has logged in, for the duration of a session
‣    user‑centric security cookies, used to detect authentication abuses, for a limited persistent duration
‣    multimedia content player cookies, used to store technical data to play back video or audio
     content, for the duration of a session
‣    load‑balancing cookies, for the duration of session
‣    user‑interface customisation cookies such as language or font preferences, for the duration
     of a session (or slightly longer)
‣    third‑party social plug‑in content‑sharing cookies, for logged‑in members of a social network.
----------------------------------- end quote ---

You mentioned that you implemented session_forward_identity header field.
That is with service workers, I guess ?

Have you intend to register session_forward_identity header field
or what ?

/ Kari Hurtta