Hey, making up a "syndrome", even with cool acronym (btw. why didn't you try to fit it into DISMISS?) may be a start, but your post is just a 3/10 on the logarithmic troll scale.
because it shifts the burden from the user who says "i do not care about dDoSing somebody else" to the producer, who says "i cannot afford angry customers".
Why 52? Before there were some removal steps and later there will come some more until firefox changes its principles with 57, when XUL is deprecated and all extensions not built on top of webextensions api (still unfinished and not so powerful) will be discarded.
Shouldn't only patches (which proved to be stable in the nightlys) be PORTED to beta? Moving a whole release just moves all the experimental features as well...
> VPN reduces this fine tuned envelope information to "when your LAN is passing data, and how much", leaving out the very relevant "...and to whom" part. This is wrong. They see only traffic to the vpn gateway and a properly configured vpn doesn't leak dns queries, either.
This is a half truth. You can get the spoken words from an compressed VoIP stream, just by the traffic pattern how good the compression works on different words. There are a lot of pitfalls, some of them are for example why SSLv3 is now fully deprecated, others only affect certain ciphers. Its very complicated to keep up with which encryption really works. On the other hand most isp probably do not try to crack your vpn connection, yet.
It would be too easy to add a button, which needs to be pressed first. Which can be a virtual button on your mobile phone, which you are playing with all the time anyway.
The whole OAuth scheme is the good idea to give applications a revokable token only. Would you give a thirdparty site your password? And for a thirdparty app you should think about your trust as well. The additional app token prevents other sites from claiming to be your app. Your site has an unique token and an unique user readable app id. Which you can see in some twitter apps below the posts. When i use yourcooltwitterapp, i do not want you to be able to trade the user-secret. But the whole flow has the problem, that some client application needs to have everything which is needed to tweet. And i everything is available in the app, you or somebody else can extract it and still trade user secrets. And this is a problem with such schemes which is hard to solve.
Yes. The concept is broken. But it's also hard to solve, if you do not want a password login (which cannot be revoked as nicely as oauth tokens).
You would need something to do like getting an token from a user encrypted with the twitter pubkey, then signing it with your app key on your server and getting a user secret back encrypted for the user signed by twitter or something similiar... and i guess there is no such standard available, yet.
Yep, but i can read your public timeline with the application secret, but only post to it with the obtained secret. When i hide the app secret in the binary you get, you can request a user secret, which allows the app to use twitter, without sharing the user secret with the developer. And if you get the app secret (which is bad), you still cannot get the secrets of other users without phishing (now YOU request them to login to a site, which uses the app secret, so it gets new user secrets).
Stop shadowbanning and throttling. If you do not have enough reasons to ban (or ban for a certain time) people, do not ban at all. Shadow Bans are a stupid concept, which only confuses people, what happend or if anything happend at all. Your service seems to be dysfunctional and the reaction is to see it as a broken technology. Be clear with your intent, ban people and tell them.
I have one account, which posted updates about a security related site. It is shadow banned. I have no idea why, but i guess it is because the site recommends adblockers as a security tool.
Stop requiring phone numbers for login: A bouncing mail address results in a question to add the mobile number without any option to login with the e-mail address. You can suspend accounts, until they have a working communication connection (mail or sms), but allow the owner to login. Without mandatory phone number. Then allow him to add a working e-mail or phone number (but do not force him to use a phone number.
And stop breaking the web interface for (temporarily) suspended accounts. When you have a suspended account for any reason, you cannot change settings, request your archive or even delete it! You may argument about some things, but the possiblity to DELETE your data is a basic right in the web. When you decide some account should be suspended, the owner should be able to decide he doesn't need the account anyway.
Again it was only a technical reason, when i experienced it. I logged in into an old account just to delete it. The login (from another ip range than the old one) triggered the bot detection and got the account suspended. It thought no big deal, i wanted to delete it anyway. I tried requesting the archive. No, you cannot when the account is suspended. Okay, not that important... so i wanted to just delete it. No, you cannot delete your own account, when its locked. You cannot delete your data (i.e. single tweets) or even just free the name for new people to get the account.
This is actually broken behaviour for a web service. And every developer should know how to handle such things properly.
Specific to developers: Do you really think mandatory mobile numbers on developer accounts will attract more developers? We do not want to give you number to share with your advertisment partners (as said in the ToS). Raise the api limits, give us functions to access ALL twitter functions instead of a limited subset, rate limit but do not limit the age of date which can be retrieved. 200 DMs and that's all? What do you think how people should implement for example an archive function, if you only get the most recent DMs?!
Specific to every user: The app gets worse and worse and so does the webinterface. While twitter spared tweetdeck from the bullshit for a long time, stuff like broken reply function was implemented in tweetdeck very shortly after it was rolled out on the main webinterface. Look how other sites have a working endless scroll and fix it! Reading 4 hours of tweets ago and then retweeting one and the site jumps back to top? W.T.F! And try to grasp the concept of threads. You never ever had a working implementation of displaying threads. Either stop trying and limit it to top-post and replies or get a nice threaded view! Accept, that people want chronological timelines. We do not need or want "while you were away" "you could like..." sections in the timeline. After we DEACTIVATED the checkmark to have an algorithmic timeline!
And finally: Get the concept of consent! The "while you were away" section first had "did you like this yes/no" (clicking no had NO effect), then it were changed to "show me this less often" (where is the fucking NO button? And it isn't shown less often when you click) and now the "show me less often" option is moved into a nicely hidden menu (click the v on the top left), still without having any effect. I guess the "option" will vanish completely soon.
So, when you start loving your users again, the users and developers (who are also users) may love you again. Try not to fuck up, it's not like twitter isn't dying more and more anyway.
I leave it to other people here to complain about some annoying groups dominating twitter trying to force their rules on it.
He's right, i am a native german speaker. For us it is logical to use a comma before relative sentences, to make clear what's the main sentence and what's not. Constructs with a lot of commas aren't uncommon in high german, while many people cannot do it right. So not using this comma is associated with sloppy chat speak and careless people here. But the oxford comma is optional in german, too.
Slashdot Mirror
Hey, making up a "syndrome", even with cool acronym (btw. why didn't you try to fit it into DISMISS?) may be a start, but your post is just a 3/10 on the logarithmic troll scale.
because it shifts the burden from the user who says "i do not care about dDoSing somebody else" to the producer, who says "i cannot afford angry customers".
Why 52? Before there were some removal steps and later there will come some more until firefox changes its principles with 57, when XUL is deprecated and all extensions not built on top of webextensions api (still unfinished and not so powerful) will be discarded.
Shouldn't only patches (which proved to be stable in the nightlys) be PORTED to beta? Moving a whole release just moves all the experimental features as well ...
> VPN reduces this fine tuned envelope information to "when your LAN is passing data, and how much", leaving out the very relevant "...and to whom" part.
This is wrong. They see only traffic to the vpn gateway and a properly configured vpn doesn't leak dns queries, either.
This is a half truth. You can get the spoken words from an compressed VoIP stream, just by the traffic pattern how good the compression works on different words. There are a lot of pitfalls, some of them are for example why SSLv3 is now fully deprecated, others only affect certain ciphers.
Its very complicated to keep up with which encryption really works. On the other hand most isp probably do not try to crack your vpn connection, yet.
Having no VPN is irresponsible for a long time, i had one years ago. Everyone who follows the news a bit knows why.
It would be too easy to add a button, which needs to be pressed first. Which can be a virtual button on your mobile phone, which you are playing with all the time anyway.
Linux does it without thirdparty programs. You can always suggest some alternatives, but we're talking about the standard FM in a system.
Users
So they get roughly what common linux desktops had in 2000.
No
The whole OAuth scheme is the good idea to give applications a revokable token only. Would you give a thirdparty site your password? And for a thirdparty app you should think about your trust as well.
The additional app token prevents other sites from claiming to be your app. Your site has an unique token and an unique user readable app id. Which you can see in some twitter apps below the posts. When i use yourcooltwitterapp, i do not want you to be able to trade the user-secret.
But the whole flow has the problem, that some client application needs to have everything which is needed to tweet. And i everything is available in the app, you or somebody else can extract it and still trade user secrets.
And this is a problem with such schemes which is hard to solve.
a flow without app token. Or username password, but we discussed a scheme, which doesn't expose too much of my account and/or credentials to you.
I answered the question, how somebody could operate a relay server without knowing the client secrets. You're asking another question now.
Yes. The concept is broken. But it's also hard to solve, if you do not want a password login (which cannot be revoked as nicely as oauth tokens).
You would need something to do like getting an token from a user encrypted with the twitter pubkey, then signing it with your app key on your server and getting a user secret back encrypted for the user signed by twitter or something similiar ... and i guess there is no such standard available, yet.
Yep, but i can read your public timeline with the application secret, but only post to it with the obtained secret. When i hide the app secret in the binary you get, you can request a user secret, which allows the app to use twitter, without sharing the user secret with the developer. And if you get the app secret (which is bad), you still cannot get the secrets of other users without phishing (now YOU request them to login to a site, which uses the app secret, so it gets new user secrets).
Use GNU social. Its ready and has a lot of users and it even looks like twitter looked in better times.
Something i have to add:
Get your banning right!
Stop shadowbanning and throttling. If you do not have enough reasons to ban (or ban for a certain time) people, do not ban at all. Shadow Bans are a stupid concept, which only confuses people, what happend or if anything happend at all. Your service seems to be dysfunctional and the reaction is to see it as a broken technology. Be clear with your intent, ban people and tell them.
I have one account, which posted updates about a security related site. It is shadow banned. I have no idea why, but i guess it is because the site recommends adblockers as a security tool.
Stop requiring phone numbers for login:
A bouncing mail address results in a question to add the mobile number without any option to login with the e-mail address. You can suspend accounts, until they have a working communication connection (mail or sms), but allow the owner to login. Without mandatory phone number. Then allow him to add a working e-mail or phone number (but do not force him to use a phone number.
And stop breaking the web interface for (temporarily) suspended accounts.
When you have a suspended account for any reason, you cannot change settings, request your archive or even delete it!
You may argument about some things, but the possiblity to DELETE your data is a basic right in the web. When you decide some account should be suspended, the owner should be able to decide he doesn't need the account anyway.
Again it was only a technical reason, when i experienced it. I logged in into an old account just to delete it. The login (from another ip range than the old one) triggered the bot detection and got the account suspended. It thought no big deal, i wanted to delete it anyway. I tried requesting the archive. No, you cannot when the account is suspended. Okay, not that important ... so i wanted to just delete it. No, you cannot delete your own account, when its locked. You cannot delete your data (i.e. single tweets) or even just free the name for new people to get the account.
This is actually broken behaviour for a web service. And every developer should know how to handle such things properly.
which means loss of control to the user. A local client can keep the user secret local. My service would need to know your secret.
Specific to developers: Do you really think mandatory mobile numbers on developer accounts will attract more developers? We do not want to give you number to share with your advertisment partners (as said in the ToS).
Raise the api limits, give us functions to access ALL twitter functions instead of a limited subset, rate limit but do not limit the age of date which can be retrieved. 200 DMs and that's all? What do you think how people should implement for example an archive function, if you only get the most recent DMs?!
Specific to every user: ..." sections in the timeline. After we DEACTIVATED the checkmark to have an algorithmic timeline!
The app gets worse and worse and so does the webinterface. While twitter spared tweetdeck from the bullshit for a long time, stuff like broken reply function was implemented in tweetdeck very shortly after it was rolled out on the main webinterface.
Look how other sites have a working endless scroll and fix it! Reading 4 hours of tweets ago and then retweeting one and the site jumps back to top? W.T.F!
And try to grasp the concept of threads. You never ever had a working implementation of displaying threads. Either stop trying and limit it to top-post and replies or get a nice threaded view!
Accept, that people want chronological timelines. We do not need or want "while you were away" "you could like
And finally: Get the concept of consent!
The "while you were away" section first had "did you like this yes/no" (clicking no had NO effect), then it were changed to "show me this less often" (where is the fucking NO button? And it isn't shown less often when you click) and now the "show me less often" option is moved into a nicely hidden menu (click the v on the top left), still without having any effect. I guess the "option" will vanish completely soon.
So, when you start loving your users again, the users and developers (who are also users) may love you again. Try not to fuck up, it's not like twitter isn't dying more and more anyway.
I leave it to other people here to complain about some annoying groups dominating twitter trying to force their rules on it.
The question was is C++ greather than C. I do not know a language called ++C.
Microsoft will bringt Windows on phones and then google will learn, what qualiy is ... ... oh wait.
He's right, i am a native german speaker. For us it is logical to use a comma before relative sentences, to make clear what's the main sentence and what's not. Constructs with a lot of commas aren't uncommon in high german, while many people cannot do it right. So not using this comma is associated with sloppy chat speak and careless people here.
... again ;-)
But the oxford comma is optional in german, too.
Sorry for infuriating you
It sorted out people, which cannot read what they click.