I think that could be solved by having a button to mark something as watched, removing it from recommendations and the catalog other than the list of things you watched.
You could hide episodes you've seen or entire seasons up to entire shows. Would fix a lot of the issues I'm having.
This is sorta it. SNI is the only unecrypted part that leaks the server hostname. CN/SAN blocking usually has a middlebox that decrypts the connections so there is nothing to be done here.
If somebody can MitM your encrypted connection to both server and DNS, encrypted SNI stops working to my understanding.
Encrypted SNI is about protecting you from people who aren't in your list of trusted CAs.
If someone is in your trusted CA list, why do you want protection from them? If you want protection from them, remove them from your list of trusted CAs.
If you insist upon talking TLS 1.3 draft 23, which is the last substantive change before the draft went to the RFC queue, google.com is perfectly happy to talk TLS 1.3 draft 23.
TLS 1.3 has downgrade detection, so if a middlebox tries to downgrade you (e.g. to TLS 1.2) without proxying the entire connection the TLS 1.3 implementation in your client will spot that and reject the connection.
Proxying is possible (including with a downgrade) if you trust the proxy. So, don't.
If you have a recent-ish version of Chrome or Firefox you are already using all this.
This is amazing work, can't wait for this to be finished and deployed on the internet. Together with encrypted DNS (DoT and DoH) we finally get fully confidential connections to a server without leaking anything other than Remote IP.
The encrypted DNS proposals only cover securing the route to the recursive resolver. So the recursive resolver (your ISP, google, cloudflare) will still see all the sites you're visiting.
We also need encrypted DNS for the recursive lookup itself so you can run your own resolver somewhere.
The resolver is less of an issue because you have free choices there, ISP is harder to change. Plus you increase the number of parties that need to collude (ISP + RR provider) to spy on your traffic.
Well, then what attacker do you defend against if your laptop asks your router via DoT but then the router does an unencrypted recursive lookup anyway?
I'm actually not sure exactly what the purpose of ESNI is but if you look at the implementation if the server you connecting to is publicly known then ESNI is not private. I might be missing something, but you can just build up a database of ESNI record_digest to server name mappings. The limitation being you can only build this up for servers you know about. Also, I guess it doesn't work for SSL servers that are terminating multiple domains because they are able to use the same key for a bunch of different domains. I guess this is the purpose of ESNI :)
I'm don't completely get it. How does CDN is required for this?
Let's say that I have a Nginx on my server which serves a lot's of websites, and whose web sites can only be accessed through HTTPS with SNI, not HTTP.
Now with Encrypted SNI deployed, requests from my clients can still be dispatched to it's respective virtual hosts, but any sniffers in the middle of the connection should only be able to see that my clients are accessing to my server, but not which virtual host.
Is I'm missed anything? I haven't dig deep in to this currently.
The theory is that if you put your server behind a popular CDN, then a state-level attacker is left with little choice but to block the entire server.
Another benefit is that attacks that can observe but not modify traffic will be less able to track what sites you're visiting.
There are risks though:
* It's unclear how resistant CDNs actually are to state-level attackers.
* It's unclear how resistant CDNs are to regular attackers[1]
* Corporations/Security-savvy users will find it difficult to control what [their] workstations can reach and cannot: Allowing access to a single cloud-based service may inadvertently allow access to a malicious command/control server sharing the CDN.
That’s an accurate summary, but CDNs are important because they terminate huge numbers of sites. In your example censorship is relatively easy since network operators who want to block a site won’t have very much collateral damage by blocking your entire server just to deny access to that single site. CDNs, terminating millions of sites, make that far more challenging.
Shared hosting can provide some “privacy” or to be more exact plausible deniability however it’s not going to be particularly good (when accounting for the actors that this would play at this level) especially when you consider that you can fingerprint the websites quite easily as the encrypted data would still of known size.
So if your website serves a page which is 412KB in size that would be quite easy to fingerprint especially across a pool of websites, beyond that it’s also quite possible to fingerprint things even further by measuring the number, size and order of secondary requests a page load incurs.
So overall there is little privacy that would be provided by this (again when taking into account the threat model and actors) unless you hide behind 1000s and 1000s of websites on the same network and even then it’s mostly not about privacy but about resilience against MITM and state censorship.
I think for the web to hold true to its ideas, there should have been a discussion of whether we want to have fully confidential connections on the internet. Sadly, this doesn't seem to have happened.
I don't think encryption hinders the true ideas of the web, it merely blocks malicious actors, of which there are many in almost all areas and connections.
The entire set of encryption can be easily opened up for inspection and manipulation if all parties agree this is good idea.
If all parties agree, yes. But that likely is not the case - e.g., an app developer would likely want to have maximum freedom in what data they send over the wire, while a user would want to minimize the amount of data transmitted (for simple cost reasons) and also control which personal and/or sensitive information is transmitted.
Encryption where the user does not control either of the endpoints stacks the odds in favor of developers and against users.
I agree however, that the situation for the web (e.g. everything that lives inside a browser) is still pretty good thanks to the ability to add custom root CAs and general user the browser's debugging and inspection tools.
However, if you try to find out what exactly a mobile app, a game console or an IoT device is doing, you soon find yourself out of luck even if you're the owner of those things.
This proposal is generally for sites which are behind an edge network like Cloudflare. In that case your remote IP is the IP of the provider, not your actual server.
This. Currently, the difference between accessing github.com/blattimwind and blattimwind.github.io is that, in the second case, which username you're accessing is visible to all. Encrypted SNI will also protect that part of the URL.
As a responsible parent, you should not be relying on filtering to educate your children. Filters have more holes than Swiss cheese, often block entirely legitimate educational resources, make your children know that you don't trust them to be responsible, and learning about proxies and VPNs is trivial for them (just try googling "proxy servers unblock websites").
If you don't trust your children to use the internet responsibly, don't let them use it. Or let them use it but only under your supervision. If you let them go wild but put up filters, they will find a way around, one way or another, and at that point the princess is in another castle.
I'm all for having discussions, but if you think the dichotomy should be "don't use the Internet at ALL" or "Talk to them about it and hope they're mature enough to avoid getting rick-rolled into rotten.com" then I heartily disagree.
As parent you can install whatever SSL CA you'd like and make full MitM of your own devices. For everyone else it's very important to not leak any private information to ISP or any other party.
It appears to be brighter because LED parts occupy a different spectrum. Sodium lamps only light up in a very narrow orange spectrum of light (you can't even tell colors under sodium lights). This spectrum is great under photopic vision (ie Daytime Vision) but terrible under nighttime vision. (~0.8 relative brightness vs ~0.1 brightness)
LED lights used for street illumination use a part of the spectrum that is much more visible during both day and night vision.
There is of course also a tradeoff because making a lamp more visible and thus allow safer driving, it will disrupt the circadian rhythm much greater.
It is certainly possible that the illumination is exactly the same but the wavelength of light outputted is different and you're much more sensitive to it.
Contractual relationships have limited conditions under which they can be terminated. If you die, your heirs (or in this case parents) can inherit the contract and continue it.
Additionally, not everything the T&C says, up to and including "accounts are not transferable" is not automatically legal.
Witnesses can be raided under german law, there are some reasons for it, esp. when it's suspected the witness is hiding evidence.
However, the raid is still out of bounds in certain other aspects (though I suspect the "take everything" the police pulled is more related to the officers having no idea what a server is vs a desktop computer. It wouldn't be the first time police officers simply don't know so they take it all)
I'm using protonmail via CC, don't see the problem tbh.
Security and privacy aren't binary options, it's a multi-dimensional spectrum where the optimal point depends on your threat model, budget and other factors. For me, it's not relevant if the police finds out if I use protonmail.
You cannot learn to make a secure lock if you don't know how to pick a lock.
Similarly, you can't build a secure system if you don't know how you'd crack a secure system.
Of course, you don't have to really know exactly which tools to use but you'd still have to know the common methods of attack, how they work, what type of tools people might use.
Once you know that, you can take steps to defeat the tools and workarounds.
There is no reason that domain providers will be incapable of providing a contact point and you were always able to put a separate email inbox on WHOIS.
But there is no need for a full postal address of real email addresses that people might use for personal contacts or a real name. That just leads to more abuse.
> There is no reason that domain providers will be incapable of providing a contact point and you were always able to put a separate email inbox on WHOIS.
The registrars have an interest in not delivering requests for sale or even abuse reports, because it's likely that they will result in the domain either being decommissioned or moved to another registrar.
I have no problem with the former but they do have incentive for the later as not delivering the abuse reports will lead to the domain being decommissioned because it's on every spam and blacklist ever.
WHOIS Privacy Services have been doing exactly this for a long time and they are usually paid by the domain registrar.
I think that problem is more imagined since there doesn't seem to be this problem in the real world.
You could hide episodes you've seen or entire seasons up to entire shows. Would fix a lot of the issues I'm having.