On Fri, 16 Feb 2018 08:15:10 -0800
> Given this group focused on Mozilla, it is likely out of scope to
> discuss Chromium design. I do suggest you look at
> https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html
> It seems reasonably clear the marking is per top level page
On Fri, Feb 16, 2018 at 3:34 AM, Kevin Chadwick via
dev-security-policy wrote:
>
> On that subject I think the chromium reported plan to label sites as
> insecure should perhaps be revised to page insecured or something more
> accurate?
Given this group
On Thu, Feb 15, 2018 at 6:34 AM, Kevin Chadwick wrote:
> The cookies etc. should be SSL only. Particular pages enforced, sure.
>
> Enforcing TLS with HSTS sitewide means that users with failed
> bios/laptop batteries have to know to reset their clock or get used to
>
On Thu, 15 Feb 2018 15:55:27 -0600
> I'm not sure this can be worked around. A setup where time is not
> pulled from the network is abnormal now, and most people who have such
> a system soon realize what the issue is.
OpenNTP has a constraint system but considering NTP is a latent,
insecure,
On 15.02.2018 13:34, Kevin Chadwick wrote:
> Enforcing TLS with HSTS sitewide means that users with failed
> bios/laptop batteries have to know to reset their clock or get used to
> bypassing SSL warnings or use out of date browsers to access sites.
Firefox and many other browsers have their own
Clock skew issues are not an overlooked problem. The Chrome team has
published research around this in the past (
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/owc7DJkg098/d8k0LyrgAgAJ)
that led to a plan (
https://www.chromium.org/developers/design-documents/sane-time). I
The cookies etc. should be SSL only. Particular pages enforced, sure.
Enforcing TLS with HSTS sitewide means that users with failed
bios/laptop batteries have to know to reset their clock or get used to
bypassing SSL warnings or use out of date browsers to access sites.
A fairly common problem,
7 matches
Mail list logo