Ask HN: What feature would you want the web to “force” next, after HTTPS?
Browsers have arguably led this drive by notifying users that the pages they are viewing are "NOT SECURE", through the use of pad-lock icons in the URL bar or even notifications under textboxes (e.g. Firefox) [0]. Chrome, too, is driving this trend. And with users fearful of sending data over a "non secure connection", they'll be vocal enough to push website owners to fix this issue.
---
So, if you could decide: what feature or measure would you want to see adopted as quickly as the push to make all sites use HTTPS?
[EDIT: kudos if you describe how your new standard could be "forced", e.g. through a URL-bar icon, notifying users somehow, etc. How would you convince other developers and maintainers of large code-bases, websites, browser vendors, etc. that they should throw their support behind your initiative?]
Think ambitiously too -- imagine your proposed feature would have the same backing and urgency as we have with HTTPS, with browsers (for better or for worse) authoritatively "dictating" the new way of doing things.
---
[0] http://cdn.ghacks.net/wp-content/uploads/2017/03/firefox-52.0-warning-insecure-login.png
[1] https://www.troyhunt.com/life-is-about-to-get-harder-for-websites-without-https/
278 comments
[ 2.1 ms ] story [ 295 ms ] threadBut I could entirely see a little privacy "eye" icon in the URL bar of Firefox, similar to the padlock icon we have now for HTTPS/certificates.
The eye could turn red and display text for the site you are visiting based on analytics, beacons, web bugs, and so on.
Or how about major social media sites have their icons placed in the URL bar if they have trackers / social media widgets on the current page. This way, it is made explicitly clear to the user that "{Insert social platform here} is tracking you on this page, even while you are logged out, don't have an account, ..."
The difficulty with having the browsers force the standard is getting Google Chrome on board, since they have so many users.
This is true, but with a reasonable cache design, it shouldn't be too bad.
Although this may be a nice driving factor to get eCommerce sites to stop putting 50 tracking pixels on every page.
https://www.reddit.com/r/unitedkingdom/comments/5ei5dz/list_...
IIRC there are some ways SNI will be encrypted with TLS 1.3 so it's not a problem to begin with.
Effectively if put into practice, ISPs would run name servers that effectively mirror the whole DNS system via blockchain. And if you really wanted to have ultimate privacy you could run it locally on your machine and there would be no way for anyone to know what domains you've looked up.
https://dnscurve.org/
And, I mean, there are accommodations and assistive technology built into the standards. It's just nowhere near as widespread as it should be, in terms of usage, and it's always an afterthought (if it is thought of at all) in frameworks and HTML templates and such. And, because most of the time an inaccessible site or app is so inaccessible as to prevent anyone who would notice from getting far enough in to complain. So, we need good tools for knowing when our stuff is broken from an accessibility standpoint.
I think what I'm getting at is that it should be easy to see errors in accessibility, and maybe search engines should favor sites that at least make an effort.
Search engines giving more accessible sites a "buff" as Google now does for HTTPS sites is a good idea. They already do in a small way in that having things like proper headings are good for SEO but they could go much further.
Google has their own Accessibility Developer Tools [0] add-on, they could make it a default part of Chrome Dev Tools and make it more prominent.
https://chrome.google.com/webstore/detail/accessibility-deve...
NVDA and Windows's Narrator are already probably good enough but JAWS is better. VoiceOver is built into macOS and iOS and is beyond good enough.
Browsers can do a better job of exposing semantics through accessibility APIs to assistive technology [0]. Browsers could also intelligently make up for the failings of web sites; e.g. when a site uses a div with a click event instead of a button element, present it as a button through the accessibility API based on heuristics. Browser rendering engines already do a lot to visually compensate for errors in HTML, they could do the same for some semantic errors.
[0] http://www.html5accessibility.com
This would have a meaningful impact on the lives of many in an underserved community.
<script vers="3.1"> </script>
<script vers="4.2"> </script>
IKE and ISAKMP was the problem, that stuff is an absolute nightmare. Maybe now with IKE2 it might get better...
Could you elaborate?
http://www.mail-archive.com/cryptography@metzdowd.com/msg123...
https://www.schneier.com/academic/paperfiles/paper-ipsec.pdf
- 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 logins and email addresses as UIDs.
- Blocking of any and all forms of popups, including javascript popups, overlays, cookie banners, browser notifications.
The web is rapidly becoming a place I don't want to visit anymore.
We would need something to replace it with, there is really nothing right now.
[0] https://news.ycombinator.com/item?id=14708783 [1] https://magmadaemon.org/
This doesn't solve the problem of mail being encrypted in transit. As far as I can tell the server operator can still read the user's mail. What we need is end-to-end encryption, lack of support in MUAs (iphone mail app, thunderbird etc.) is the problem here, it has really nothing to do with the server.
Thunderbird supports S/MIME out of the box and PGP through an addon, so I'm not sure what other kinds of end-to-end encryption you'd want to see. Not sure about the iPhone mail app.
Take keybase (or its conceptual basis) and distribute it. Each domain can host its own key server. You can post proofs on other domains to link domain identities or logins. So now my phone has a key that's attached to the identity jtsummers at legoflambda.org. You have a service. I register the identity jtsummers at legoflambda.org with your service. I can log in using the key from my phone. My laptop has its own key. My yubikey stores a third key for access while I'm traveling without my laptop. Each of those I've connected via some proof mechanism to my key server so I can log into your service using any one of those keys.
Google and others can also host a key server so my user at gmail.com identity can also be used or my facebook.com identity, again with multiple keys associated with them from my various devices. And possession of the private key can also be used to access the same services (perhaps paired with something like a TOTP or other shared secret if you want an extra layer of authentication).
Now you want to send a message to me, you can have a service similar to what keybase offers. You send a message to any one of my public identities or keys, it gets made available to all of them. You know me here on HN, you send it to that identity. You know me by some other forum handle or by my gmail account you use those. And since my public keys are all available, you can send an encrypted message that will be available to any one of my devices (which I can re-encrypt as I add and remove devices).
This also handles a lot of the problem with spam. Spammers now have to take the time to individually encrypt messages for every user. They have to publically post identities and keys so that users can authenticate them. And users can block spammers by blocking the keys associated with them and block an entire identity by blocking all the keys associated with the spamming key. You want to ensure that that email from your bank is legitimate? Your bank should have a publically visible key server that all communications from them make use of. Whether they send the message in the clear with only a signature or if they send an encrypted message to you (preferred for privacy and security anyways).
This also helps with applications like signal/whatsapp which are presently tied to a single client instance. Now, I can associate my whatsapp key with multiple other keys (each on different devices, presumably). So you want to send me a whatsapp message, it can now be sent to all my devices. My phone number can still be an identity used by those services, but it's no longer the only one.
This was a particularly annoying case for me as I travel internationally with a separate phone than my US phone since it's locked, I had to enable WhatsApp on my travel phone using my primary cell number for ease of friends communicating with me (I don't have to get my secondary number to all of them and remind them to switch back once I'm done). If I could have connected my secondary device to my primary one then all messages sent to my main number would have been received by both, and messages sent from either would all appear to the recipient as belonging to the same identity.
====
This is not a well structured presentation, sorry. It's more the random thoughts that have been hopping around in my head for the last couple months between other more pressing concerns.
Do you know if PGP public/private key pairs can be used for ephemeral keys? I'd hate to rely on the same secret to store everything throughout time.
You do realize that's trust-on-first-connect aka self signed certigicates, right? Especially with LE, thats worse in every way to the CA model.
>Logins on websites with a public / private keypair ala SSH.
Pretty much client certificates minus PKI.
I don't see how the option to trust websites is worse than having a bunch of certificate authorities choose who I'll trust for me.
For example, if users were responsible for knowing which fingerprints to trust for a given website, they would most likely just click "ok, trust it" for everything. Then, you're overall security goes way down because now people are conditioned to click "accept" to everything, regardless of the impact.
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 certificates, malware scans, and the like. A limited number of such reliable schemes would scale reasonably well, and should prove useful.
I'm not saying "perfect", I'm saying "useful".
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.)
Would HPKP (https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key...) cover that for you?
The thing is, if it is a massive pain for average users, then that is an own-goal. Look at SSH: there is no certification chain there. All you do is generate a keypair and then (here's the awkward bit) magic the pubkey over to the server.
It would be easy enough for a website to make pubkey installation a seamless part of the sign-on workflow.
So while browsers do support client certs, there has been very little effort to make them easy to install due to a chicken-egg situation. They're hard to use, so no one uses them, but no one (random sites on the Internet, that is) uses them for client auth because they're hard to use.
https://www.sjoerdlangkemper.nl/2017/07/05/prevent-session-h...
Let me ask it a different way - do you have any reasonable expectation that your proposal will ever be accepted? That browser manufacturers will implement things to limit or block the functionality of js? Where would the line be drawn (and who would draw it) between the so-called web apps and everything else that isn't worthy?
There already are some mechanisms in place to decentivize misbehaving websites such as the google rankings. But thats a far cry from a browser not supporting or displaying some warning when viewing one of those sites.
Maybe im missing something - that there are these required sites that are misbehaving and we need some regulatory power to rein them in.
Again, arent you capable of choosing the websites you use? Are there websites you are required to spend extended amounts of time with that you want the browsers to step in and force them to use less javascript?
There are hundreds of pie in the sky suggestions being floated here, and the one about javascript is the one you choose to attack with this argument?
JavaScript has unequivocally made the web worse for everyone but advertisers and perhaps the people that run CDNs.
Why, of all the proposals here, are you trying to shit on this one on particular?
Honest question.
Do you really think this is defensible? That the web would be as popular or useful as it is today without the ability to run code in the browser? I'm curious if you think there is a majority of people that agree with this?
> Why, of all the proposals here, are you trying to shit on this one on particular?
I am not shitting on anyone - im trying to have an honest discussion about why you and the OP feel that javascript is such a scourge that it needs to be regulated. Not one person has addressed even one of my questions, you included. I'm sorry you're taking my challenge as hostility - its not intended that way.
I submit that its possible I am missing something - perhaps there is situations out there that I don't have to deal with. I'm asking for an honest view point that I can try to understand.
> ... pie in the sky ...
Theres a difference between "here's something thats easily accepted is a good idea but might be difficult to implement" and this. I'm asking for an explanation of the premise itself.
The only thing that I can think of that absolutely requires JavaScript is advertising and tracking.
Anything else better serves the user as a desktop or native app.
This works in some instances.
Not so much in others.
Amazon.com worked fine from 1995 to 2016 with HTTP (only the login page was HTTPS).
If you have a crappy ISP like Verizon or whatever, it's your own personal problem - 99% of the web user don't care about your problem. Maybe use a VPN to somewhere to an ISP you can trust.
I stopped using Firefox because they turned mad. Chromium with some custom patches seems like a far better solution nowadays. Yet I see Google is too trying to destroy the open web with their PWA/AMP monoculture that is favored and listed on top of search results.
We need the EFF and other "good" foundations to lobby for the end user - too many shady and corporate entities lobby against the end user, unfortunately.
I've been looking for a site I can run this on over TOR at random times for reading news but I haven't found one.
The nice thing about doing it like this is that the file persists on disk so viewing a page is decoupled from fetching it (which is nice for a lot of reasons.)
https://ello.co/dredmorbius/post/naya9wqdemiovuvwvoyquq
Why browsers don't dump to disk in a format that makes for easy rendering ... I don't know.
- Standardize on some sort of biometric identification that actually works. I HATE two-factor :(
2. Is biometric really necessary? U2F tokens already exist and are standardized (maybe not officially, I'm not sure). Chrome and Opera already support it, Mozilla's support must be coming soon (meanwhile you can use an add-on).
U2F dongles aren't much better.
Also, a quick glance at that link seems to indicate attacker needs some sort of MITM access? Is it anything more than a replay attack?
I don't know how this could be implemented though
Each user can specify a maximum payment and can opt to view with ads if payment requested is too much.