Never connect to ProtonMail using Chrome
101–110 of 289 posts
Re: Never connect to ProtonMail using Chrome
#102Chrome is fun, today I learned you cannot turn off auto-complete for a page in chrome. Possibly some really creative hacks can do it but those seem to be "fixed" every so often as well. Which is great when you're building a HIPAA compliant page and would prefer that people's medical information not get cached by chrome (and then uploaded to their cloud storage if you're logged in).
Re: Never connect to ProtonMail using Chrome
#103Chrome is fun, today I learned you cannot turn off auto-complete for a page in chrome. Possibly some really creative hacks can do it but those seem to be "fixed" every so often as well. Which is great when you're building a HIPAA compliant page and would prefer that people's medical information not get cached by chrome (and then uploaded to their cloud storage if you're logged in).
URLs should not contain PII data. That is a very bad design. [Edit] I've got the wrong end of the stick it seems.
Put a value into it a text field and Chrome will helpfully save it for future auto-completion. Then it'll upload it to your account on their cloud if you're logged into an account. How do you think it's able to fill out your name, address, etc. on all those web forms?
Re: Never connect to ProtonMail using Chrome
#104I don't understand how this is related to ProtonMail. It reads more to me like "never use Chrome [if you care about all of your web content being sent to Google]". Sure, ProtonMail is likely to have personal, private stuff in it but so does a bunch of other things, eg. internet banking.
It's related because that translate feature was disabled for those languages, but Google Chrome decided to disregard that specifically on ProtonMail and send the whole thing to Google servers anyways.
Re: Never connect to ProtonMail using Chrome
#105Earlier quoted context omitted.
What frequently happens is that a simplified alternative appears. HTML5 rather than XHTML, Markdown vs. HTML or LaTeX, HTML, originally, vs. SGML or Sun's ... proprietary hypertext system (Vue?). Arguably, replacement of much office suite software with Web technologies. Multics -> Unix.
This is true, but a web browser can't really make those choices without a breaking a lot existing stuff. The big problem is that we keep piling onto HTML, CSS, and JS. For instance if we wanted web apps it would have been better to make something separate. Instead we have taken HTML which was originally just a way of rich text formatting and have made into the beast that it is today.
HTML was originally contemplated as more than a method of rich text formatting. It was created as a way to describe and link arbitrary media and applications. I'd recommend reading the first published proposal for (what later became known as) the World Wide Web written by Tim Berners-Lee [1]. In my reading, I see it as being intended applications as powerful as the kind we build today - at least as far as could be contemplated and described in 1989, and given the degree of abstraction with which the document as written:
> "Hypertext" is a term coined in the 1950s by Ted Nelson [...], which has become popular for these systems, although it is used to embrace two different ideas. One idea[] is the concept: "Hypertext": Human-readable information linked together in an unconstrained way. The other idea [...], is of multimedia documents which include graphics, speech and video. I will not discuss this latter aspect further here, although I will use the word "Hypermedia" to indicate that one is not bound to text.
An example of anticipated usage:
> The data to which a link (or a hot spot) refers may be very static, or it may be temporary. In many cases at CERN information about the state of systems is changing all the time. Hypertext allows documents to be linked into "live" data so that every time the link is followed, the information is retrieved. If one sacrifices portability, it is possible so make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide.
Another category of use-case was web crawling, link-based document search, and other data analysis.
These and other anticipated use-cases envision more than text formatting; the primary purposes of the proposal were, in my opinion, the inter-linking of information and the formal modeling of information, especially for the purpose of combining different programs or facilities into a single user experience.
Re: Never connect to ProtonMail using Chrome
#106Is Google Chrome sending browsing history and webpage content to Google (via Google Translate) even when sync is off? I didn't see anything about that in the settings.
Language detection happens offline using https://github.com/google/cld3
Re: Never connect to ProtonMail using Chrome
#107Earlier quoted context omitted.
No it isn't. It's the difference between "Here's some money, please show this to young Democrats" and "Here's some money, please give me a list of young Democrats." That's a pretty damn big difference.
> That's a pretty damn big difference. There's certainly a difference. I'm not sure it's a very big one though. The latter is an extra problem in a few specific areas: 1. your foremost fear is a bad actor getting your private details (e.g. identity fraud / doxing). These are legitimate fears, but certainly not a primary likelihood in the majority of cases. 2. discrimination based on background checks (jobs/loans/etc.…
The main problem I see is that corporations cannot be trusted to limit their use of personal data to benign purposes, nor can they be trusted to keep that data safe from people who will abuse it. But there's certainly a significant difference between potentially leaking or abusing data and actively selling it.
Re: Never connect to ProtonMail using Chrome
#108Earlier quoted context omitted.
Tinfoil hat off for a second it makes more sense Cloudflare and Google are backing these protocols because they're more efficient which means lower infrastructure costs. They both terminate traffic already so can already see everything regardless of the protocol used.
I am not the person you responded to. However, I would only be considering things that people in general are eager to use not just a few big companies. Most users of HTTP have never been too concerned with it's overhead. Except maybe the way cookies have been design. It definitely has problems, but most peoples problems are not googles or cloud flares.
If anything, smaller sites have more to gain from HTTP/2 and HTTP/3 than the likes of Google. For example:
- Both HTTP/2 and HTTP/3 seek to reduce the number of round trips, mitigating latency between the user and the server. Now, from Google's perspective, the "server" is the nearest load balancer in a globally distributed network, which is probably geographically close to wherever the user is. Thus, users with good Internet connections typically have low enough latency for the improvements not to matter much. But Google still cares about latency because of users with poor internet connections – such as anyone on a cell network in a spotty coverage area. Well, poor connections affect all sites equally. But small sites tend to not be fully distributed; they probably only have a single origin server for application logic, and perhaps a single server period, if they're not using a CDN. That means a fixed geographic location, which will have higher latency to users farther away even if they have a good connection – thus more benefit from latency mitigation.
- QUIC can send stream data in the first packet sent to the server, without having to go through a SYN/ACK handshake first. TCP Fast Open lets plain old TCP do the same thing – but only when connecting to a server you've seen in the recent past (and retrieved an authentication tag from). Thus, QUIC is faster when connecting to a server for the first time – which affects smaller sites a lot more than Google.
Re: Never connect to ProtonMail using Chrome
#109Earlier quoted context omitted.
I have been using Firefox since version 1.0. I don't understand the desire to use google's browser. However, why would even trying view secure data in your web-browser... Not even just Chrome. Things may get cached ect... Although, Mozilla has been doing things that I find annoying at times. Like adding pocket ect... Little Rant Although, I have looked at some of the other forks. What I find more depressing is how fe…
> I don't understand the desire to use google's browser. It was the only browser with a decent Javascript sandbox, at least until recently. Wikipedia claims Firefox got a sandbox this month , but I think I've seen earlier claims: > Until November 2018, Firefox was the last widely used browser not to use a browser sandbox to isolate Web content in each tab from each other and from the rest of the system.[120][121]