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

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) <Wesley.Oliver@vcontractor.co.za> 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 <wesley.olis@gmail.com>
> Date: Sun, May 12, 2019 at 7:51 PM
> Subject: Proposal for new header field: SESSION_FORWARD_IDENTITY
> To: ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>
> 
> 
> 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: wesley.olis@gmail.com
> 
> 
> -- 
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com
> 
> ------------------
> 
> ---------- Forwarded message ---------
> From: Wesley Oliver <wesley.olis@gmail.com>
> Date: Sun, May 12, 2019 at 7:29 PM
> Subject: Proposal for new header field: SERVER_UTC_TIME
> To: ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>
> 
> 
> 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: wesley.olis@gmail.com
> 
> 
> -- 
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com
> 
> ————————————————————————
> 
> 
> 
> 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/

Received on Monday, 20 May 2019 08:29:05 UTC