101–110 of 169 posts
I'm glad they continued the "An Update on X" = "X is getting axed" tradition at google. It's one of the few constants. Maybe they even have a UX guideline about it by now :D PS: I'm not writing this out of spite, btw. It just came to my mind when I saw the title and I was surprised I was right
Earlier quoted context omitted.
I think the concerns/difficulties are: 1) Business contexts. A local network maybe shouldn't be trusted, there, for security purposes. "OK, but they should set that with policies" which, yes, sure, but defaults do matter, so... I dunno, I can see why they'd prefer the safer default. 2) Lying DNS servers on a local-but-actually-public network (think: coffee shop wifi) directing you to a local address to bypass SSL pro…
I agree there are things that would have to be worked out, to prevent opening new exploitable holes. How about we just add some ability to the browser to remember the site (fingerprint it somehow, perhaps) so that the security policy only has to be agreed to once. Kinda sorta similar to SSH remembering known hosts. Once I've told Chrome that my Unifi Dream Router is okay, or my Iotawatt, or Home Assistant, etc ... it…
Such a cryptic lock is even more confusing. I propose a very simple, easy to understand solution: http should simply be RED https should not be indicated at all A curated list, preferably by the gov. should indicate which SSL certificates are allowed to be green.
Earlier quoted context omitted.
> it supports SSL for some unfathomable reason. "neverssl.com now supports ssl, as some browsers and sites automatically use https even when you don't type that in. You get a browser-cacheable page that still helps you get online by forcing a request that ... never uses ssl." -- https://twitter.com/NeverSSL/status/1456310362551164928 They're trying to solve the "how do log into this captive portal" problem, and they…
Wow. Unfathomable indeed; that action and that explanation make no sense to me, and they haven’t even updated the HTML served—it still makes the claim of “never SSL” they’ve reneged on.
Damn straight. Demand your money back!
Reading through this it's making a lot of sense, the lock icon was added to convey that the 'connection is secure', while making the assumption that the user understood it's talking about the transport layer behind the scenes. Of course, most users cannot be expected to know that kind of detail, so they would associate it with the thing in front of their eyes, the website itself. I am sticking to Firefox but as chang…
When we were hosting custom websites for various university departments on the cheap, at this point it was difficult to do HTTPS on a site that shared IPs (which I gather has been corrected). One group insisted on it, despite that their form results, which weren't exactly secret squirrel knowledge, got stuffed into plain ole SMTP emails. I explained this carefully. "But it has a LOCK on it ..." It was impossible to g…
Indeed. In two different directions, even. First, a server can send a certificate with a large number of domain names in a field called "Subject Alternate Name" (SAN). If a server host a small number of static names, that's an easy solution.
Second, the client can use a TLS extension called "Server Name Indication" (SNI) to tell the server what name it's attempting to connect to. This is more recent than the SAN approach, and allows a single host to work for truly ridiculous sets of different names, even changing them dynamically.
I downloaded Chrome Canary to take a look at this "general design refresh" and... sigh.
The new browser UI is now 10 pixels taller than the old one.
I realize 10 pixels isn't a lot. But it's also not noting—it's half the height of the top bar on Hacker News. And this is after Google already made their UI much taller in their last refresh. If you make the UI take up more and more space with each redesign, it adds up.
Yes, I have a bigger monitor today than I once did. But I bought that monitor so I'd have more space for actual content, not the browser UI.
Remember how Google chose the name "Google Chrome" because it was designed to have a minimal UI that gets out of your way and lets you focus on page content?
For my masters thesis, I proposed replacing the security indicator with a risk indicator: "After HTTPS: Indicating Risk Instead of Security" - https://scholarsarchive.byu.edu/etd/7403/ Turns out there are lots of localized, privacy-preserving cues you can observe to determine whether a user may be at some level of risk, that doesn't involve a centralized blocklist or a boolean answer; and users really appreciated the…
Earlier quoted context omitted.
Chrome redirects to https://example.com , so that's no bueno for testing http:// in your URL bar. Edit: I'm running Chrome OS 113 beta. Maybe they changed something recently, to automatically use HTTPS unless prohibited by the server? This also happens in Guest mode with no extensions.
In (50%) of Beta, Chrome attempts HTTPS and silently falls back to HTTP on all HTTP links. We're still poking around with opt-outs, currently if you allow insecure content via Page Info / Site Controls, we stop upgrades.
Earlier quoted context omitted.
https://news.ycombinator.com/item?id=35792149 The primary goal of NeverSSL is to be useful on networks with captive portals that intercept HTTP and block HTTPS (until you have signed in). The JavaScript redirect is at least browser cacheable, whereas a 301 redirect sent via HTTPS would be useless in that scenario as it would fail to load.
Isn't a 301 response cacheable?