T
The Fallen Angel
Guest
I think the general plan is to put up with minor inconveniences for approx 1 month to see what effect the anti hot linking measures are having on keeping bandwidth costs down.
-
Sign up or login, and you'll have full access to opportunities of forum.
Forum glitches
- Thread starter LittleSiss
- Start date
Fliegerbiene
Spectator
Exactly the same with my computer. Using: Edge.
Tavy
Executioner
I find that being unable to log in, comment or view full size pictures and keeping getting 'Connection is not secure' popups is a bit more of a minor inconvenience.
T
The Fallen Angel
Guest
It is indeed much worse for some people than others. What browser are you using?
Tavy
Executioner
I was using Opera. I've just started trying DuckDuckGo which seems to be working so far. Fingers cruxed.
T
The Fallen Angel
Guest
Opera does seem to have big problems.
Loinclothslave
slave to the whip
Yes this looks like being a standard “feature” for us iPhone using crux fans… the in-0post emoticons seem to be unavailable unless one knows their code like roflmao
or the demerit spank 
Annoying but livable. Thank you @ImageMaker for the clarification and I sincerely hope you are keeping well.
Hugin&Munin
Presenter Of Images
I tried a Linux browser called "Internet". With this I can log into our forum with "https" the lock is displayed, but also an error message:
You are connected to "www.cruxforums.com". This website did not properly secure its connection.
Perhaps this information can help solve our connection problems.
Frank Petrexa
Tribune
I have no problems at all, but I always use Firefox on a PC to access the forum. And I always see the https lock.
A socket is something on your computer. The server also has a "connection" when you connect. From what I remember, there are "layers" in any communication. The "transport" layer contains the data and such, and it can be encrypted as discussed below from Wikipedia so even if someone slurped it off the wire they could not read, because only you and the server have the relevant "keys". The outer "layers" (just strings of bits enclosing the transport layer bits) do things like routing--it is worth noting that usually there is NOT a fixed route: even in the same "connection" individual pieces ("packets") can go through a different path (down to Puerto Rico, or over to Kansas, or up to Montreal) to get to the same place in California depending on what the routers along the way perceive is the best (i.e., not so busy) way to get there. Your message can arrive in pieces, and it is up to the target browser or server to put them together in the right order. In the original internet, nobody thought of trying to snoop on other people--it was supposed to be open and free (it was the '60's, after all) and nobody thought about watching movies on machines because they were so slow and klunky, so "layers" had to be added and it got really complex really fast--fortunately machines are fast enough with enough memory to handle it all.
So I am not sure what is happening. There are these bottom lines.
(1) Some servers will just not do https (e.g., http://www.cubs.com). Too much work to generate the keys and all that for someone who just wants to read what's there, and there is high traffic so there are lots of someones (if you buy tickets, they move you to another connection at another server which is secure).
(2) There is supposed to be a "session"--the original internet protocols didn't allow them (they was "stateless" and each packet was just one damned thing after another that didn't depend on the past), so both your machine and the server have to do more work to keep track of what has gone before: embed something in the messages to say that this is somebody who is still logged in, keep local data to track who is doing what. So, maybe that session information is somehow being lost until you refresh. When you refresh, something says "oh, yeah, this is part of your session" on your re-send. But I don't know why that should be. I don't think you have lost your "connection". You have to do a ton of work to program all this if you write code that uses the internet so other people can work in your application as remote users and push buttons in it and wait for results.
(3) You can see why different browsers on different machines might have trouble doing all this properly--there is a lot your machine has to be able to do because the security and session stuff aren't baked into the original internet "protocols" and the server and you have to add a bunch of processing to make them work. There are now protocols so the security is standard, but the users have to program them locally. They aren't supplied by the intermediate hops through the internet. (Having a wire from your home to the server in the Netherlands really isn't practical--for one the sharks tend to bite the cables because they are attracted to the electricity, so there have to be intermediate steps and some have to be able to handle a whole lot of traffic from myriad different people.)
From Wikipedia (note all of this happens on the two machines--none of it is built into the internet itself). Note also there are third parties who have to vouch for the server, say that it isn't an imposter, and your li'l ol' machine has to verify the "certificate" with the third parties. I assume Diffie and Hellman made some money with the math they invented.
Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure (see § TLS handshake).[2] The protocols use a handshake with an asymmetric cipher to establish not only cipher settings but also a session-specific shared key with which further communication is encrypted using a symmetric cipher. During this handshake, the client and server agree on various parameters used to establish the connection's security:
A socket is something on your computer. The server also has a "connection" when you connect. From what I remember, there are "layers" in any communication. The "transport" layer contains the data and such, and it can be encrypted as discussed below from Wikipedia so even if someone slurped it off the wire they could not read, because only you and the server have the relevant "keys". The outer "layers" (just strings of bits enclosing the transport layer bits) do things like routing--it is worth noting that usually there is NOT a fixed route: even in the same "connection" individual pieces ("packets") can go through a different path (down to Puerto Rico, or over to Kansas, or up to Montreal) to get to the same place in California depending on what the routers along the way perceive is the best (i.e., not so busy) way to get there. Your message can arrive in pieces, and it is up to the target browser or server to put them together in the right order. In the original internet, nobody thought of trying to snoop on other people--it was supposed to be open and free (it was the '60's, after all) and nobody thought about watching movies on machines because they were so slow and klunky, so "layers" had to be added and it got really complex really fast--fortunately machines are fast enough with enough memory to handle it all.
So I am not sure what is happening. There are these bottom lines.
(1) Some servers will just not do https (e.g., http://www.cubs.com). Too much work to generate the keys and all that for someone who just wants to read what's there, and there is high traffic so there are lots of someones (if you buy tickets, they move you to another connection at another server which is secure).
(2) There is supposed to be a "session"--the original internet protocols didn't allow them (they was "stateless" and each packet was just one damned thing after another that didn't depend on the past), so both your machine and the server have to do more work to keep track of what has gone before: embed something in the messages to say that this is somebody who is still logged in, keep local data to track who is doing what. So, maybe that session information is somehow being lost until you refresh. When you refresh, something says "oh, yeah, this is part of your session" on your re-send. But I don't know why that should be. I don't think you have lost your "connection". You have to do a ton of work to program all this if you write code that uses the internet so other people can work in your application as remote users and push buttons in it and wait for results.
(3) You can see why different browsers on different machines might have trouble doing all this properly--there is a lot your machine has to be able to do because the security and session stuff aren't baked into the original internet "protocols" and the server and you have to add a bunch of processing to make them work. There are now protocols so the security is standard, but the users have to program them locally. They aren't supplied by the intermediate hops through the internet. (Having a wire from your home to the server in the Netherlands really isn't practical--for one the sharks tend to bite the cables because they are attracted to the electricity, so there have to be intermediate steps and some have to be able to handle a whole lot of traffic from myriad different people.)
From Wikipedia (note all of this happens on the two machines--none of it is built into the internet itself). Note also there are third parties who have to vouch for the server, say that it isn't an imposter, and your li'l ol' machine has to verify the "certificate" with the third parties. I assume Diffie and Hellman made some money with the math they invented.
Once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure (see § TLS handshake).[2] The protocols use a handshake with an asymmetric cipher to establish not only cipher settings but also a session-specific shared key with which further communication is encrypted using a symmetric cipher. During this handshake, the client and server agree on various parameters used to establish the connection's security:
- The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and the client presents a list of supported cipher suites (ciphers and hash functions).
- From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.
- The server usually then provides identification in the form of a digital certificate. The certificate contains the server name, the trusted certificate authority (CA) that vouches for the authenticity of the certificate, and the server's public encryption key.
- The client confirms the validity of the certificate before proceeding.
- To generate the session keys used for the secure connection, the client either:
- encrypts a random number (PreMasterSecret) with the server's public key and sends the result to the server (which only the server should be able to decrypt with its private key); both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session, or
- uses Diffie–Hellman key exchange to securely generate a random and unique session key for encryption and decryption that has the additional property of forward secrecy: if the server's private key is disclosed in future, it cannot be used to decrypt the current session, even if the session is intercepted and recorded by a third party.
poem21045
Tribunus Plebis
Why would we be anti- these?
Oh! You said hot linking! Sorry.
Last edited:
Sometimes when I'm on here lately my interface won't work because I apparently don't have cookies on. But then I go back or load a different page, and it does. I really don't know what's going on...
Edit: For instance, when, a moment after I posted the above, I tried to edit it to fix a spelling error, it didn't work. But when I went back, refreshed the subforum page so the thread appeared, then clicked on it to enter, I was able to edit.
Edit: For instance, when, a moment after I posted the above, I tried to edit it to fix a spelling error, it didn't work. But when I went back, refreshed the subforum page so the thread appeared, then clicked on it to enter, I was able to edit.
M
montycrusto
Guest
Yeah I find I have to click “refresh” before I can like or reply to a post
So do I. And I still haven’t been able to summon up emojis. I am reduced to falling back on emoticons. :-(Yeah I find I have to click “refresh” before I can like or reply to a post
Loinclothslave
slave to the whip
I assume you’ve tried refreshing immediately before replying?
I’m getting most of the functionality (except i can’t produce emojis unless I know their code) but I have to constantly hit refresh. Clearly the device used means particular bugs dominate, I think some lucky members are encountering no issues due to their browser settings and probably hardware influenced as well…
I've alerted IM and tech-minded staff to this (I've noticed your message to me in Another Place
)
Migoz2
Senator
It's also working as normal for me: Windows 10, Firefox in private mode (which sometimes causes problems elsewhere), on a VPN (which also can be problematic). No emojis (which I never use anyway).
As for the 'Not secure' connection: hasn't that always been there and relates to external images?
Brian
Executioner
My Firefox was working fine with cruxforums. I am now getting the same massage İmagemaker gets. Edge works fine. Does anyone know a way to solve this problem?
Tavy
Executioner
I uninstalled opera then reinstalled it and this site works fine now (apart from an alert that connection is not secure).