241–250 of 279 posts
Earlier quoted context omitted.
What do you mean by this?
"evergreen" means self-updating, with a rapid release cycle. Chrome, Edge, and Firefox follow this model. IE (essentially a legacy browser at this point) and Safari don't.
This works in some instances.
Not so much in others.
Earlier quoted context omitted.
Signed archives of trusted or untrusted fingerprints, distributed by various and independent authorities is one option. Trust is, by definition, an extention of solidity or support. CA is a trust model, which has proved both brittle and unworkable. http://www.etymonline.com/index.php?term=trust&allowed_in_fr... Google and other services presently provide extended trust and validity assessments for websites: pinned ce…
DANE perhaps? http://www.internetsociety.org/deploy360/resources/dane/
I was thinking of something more akin to, say Google's pinned certificates (something which practices such as Let's Encrypt actually makes harder AFAICT):
https://security.stackexchange.com/questions/29988/what-is-c...
Or something that might be a parallel of email reputation services -- SenderBase / IronPort (now Cisco) rating email servers by their spam loads, etc.
Rather than negative reputation, a positive reputation (vouch rather than warn) might be viable. (Negative ratings systems, digital or otherwise, tend to inspire various legal assaults.)
- A protocol for sites to get my public PGP key for server side use - The discontinuation of using SSL certificates for verification of website identities and a move to true fingerprinting ala SSH. - Deprecation of email or rather its insecurity. - Logins on websites with a public / private keypair ala SSH. - A resurgence in sites that let me pick my own anonymous username instead of Facebook, Google or Twitter login…
SSH-style login is still something I'd really fucking love. Much more secure way of logging in, easy protocol for storing multiple passwords, and easy authorization/deauthirzation of passwords/keys.
https://www.sjoerdlangkemper.nl/2017/07/05/prevent-session-h...
Now that adoption of HTTPS has solved all SQL injection holes, we can take steps to further modernize the Web so people can feel secure. Require Facebook login for everything. Just don't serve the content without a Facebook login. Can use DPI at the network layer to help enforce. Add phone-home features to CPUs to make them turn off 6 months after product introduction. Everyone ought to be buying a new computer every…
You had me going for a minute.
Registration forms should be standardized. I want to have my "real" details, and my "fake" details ready to be entered into websites that want yet another registration. Why does every single website implement their own registration form with exactly the same details?! Why does every single web site re-implement the registration page slightly differently?! Ideally, I'd enter the registration page, the browser would li…
I was thinking of writing a spec and implementation on a similar thing a few days ago: Each site would publish a standardized file in a standardized location, and/or add a META tag to the file in each page. The file itself would simply contain the URL to the login page and the parameters that should be passed to it, and the way to pass those parameters. Then, your browser/password manager could simply perform a reque…
The more likely (as in, one could create it today) implementation would be an extension that could do the GET/POST login, but was oblivious as to required parameters. Then people could contribute the formats expected by different domains.
Much less elegant, and only usable by the more technically inclined, but implementable today without explicit support from websites.
First party isolation. Social media buttons and other trackers should not get a global identity for free. Explicit opt-in to store persistent state at all. An exception should be a cryptographic identity that is only revealed when you click a login button. No sound without opt-in. No big data transfers without opt-in. If a site wants to shove 10MB of crap in their article, then they should have to show a page asking…
I like this idea, but because websites have the content, they can simply throw up a button that requests showing your identity to view the content and most people would blindly click it leading to the same situation we have now. The HTTPS push is important and works because the search engines can leverage their importance and the browsers can (effectively) scare people without any user input.
Earlier quoted context omitted.
That’s another one of these half-assed solutions that the world has too many of, just like credit cards or using SSN as auth. No. We’ve solved all these issues before, OpenID was a good solution, and OpenID Connect – a complete rewrite – can be used to replace it, and is used already for Google and Facebook login. Just use OIDC, on every page, and allow users to choose an identity provider. Problem solved.
> OpenID was a good solution Ugh...no. Just no. If you believe that, I'm not sure there's anything I can say that will get through to you...we're just going to have diametrically opposed opinions. But let me tell you that I've implemented it quite a few times on various sites and it's been a nightmare every time, so it's not like my 'half-assed' approach was ignorant of it being an option. It was based on specificall…
And for anyone else OIDC is more than good enough.
Username and Password is in any situation less secure than OIDC.
Earlier quoted context omitted.
That’s another one of these half-assed solutions that the world has too many of, just like credit cards or using SSN as auth. No. We’ve solved all these issues before, OpenID was a good solution, and OpenID Connect – a complete rewrite – can be used to replace it, and is used already for Google and Facebook login. Just use OIDC, on every page, and allow users to choose an identity provider. Problem solved.
I kind of agree, using OIDC with users selecting providers in the form of an email address (i.e. you enter an email address and the provider is selected based on that) seems like ideal UX.
None of that should work. Ads shouldn't be able to inject their own JavaScript into a page. There's a technical solution to that problem.
Let's narrow down the scop of things an ad needs to do (display an image, maybe play sounds and videos (after user clicks on them), and send back a reasonable amount of tracking data, etc). Then let's come up with a sandboxed DSL for ad networks to specify their ads. Web sites could embed those ads inside an tag that sandboxes that content and makes sure only supported functionality is being used.
Then I can turn off my ad blocker and not have to worry about all the security issues that unscrupulous ad providers bring with them today.
I would love package systems and server admins to recognize the inherit danger in allowing the servers to call out to the wild. All internet facing servers should be allowed to only call out to white listed addresses.