A URL shortener not shortening the URL but makes it look very dodgy
github.com
github.com
Teams just generates mile long URLs that encode more information than some of the meetings themselves in the worst case.
Sadly this is also possible with a 9-letter code.
And we're adjourned. Next month we'll discuss the rules of governance for the committee.
That's two of the total 6 meetings the committee has allocated.
And all the bureaucrats made plenty of show for the "progress we've made".
The only reason why companies don't care about it in the context of mail is because there is no equivalent to safe browsing for mails, so Domains aren't penalized by Google for sending fraudulent messages at small scale. If this was to change, they'd all pivot to using secondary domains for these mails, like GitHub does for GitHub pages.
It would also be a pretty pointless feature as you'd probably complain anyway, as the email would still come from a Paypal owned domain.
On the same topic: if you've got a Gmail address you're also able to send from @googlemail.com
Is this another security issue in your opinion?
Nor does it matter wherever it's a clickable link or text in this context. The only way to "solve" your issue is by removing user generated content, which makes the invoicing feature inherently impossible.
If you're seriously shocked that PayPal isn't decommissioning a highly profitable feature because a random carebear worries about their family... Then you're honestly out of touch with reality.
Most people nowadays know that emails are untrustworthy, and if your family doesn't... Then you should tell them that, as they're bound to get scammed eventually if they click on any links from their inbox.
paypal in a URL pointing to a non-paypal domain, no need to load the webpage to flag that.
> -- all outgoing emails from ACMECORP are virus checked by the newest version of WINDOWS DEFENDER --
1: https://mango.pdf.zone/operation-luigi-how-i-hacked-my-friend-without-her-noticing> Turns out this site is powered by money. We ran out of Google App Engine credit. Fear not, we'll get more within 24 hours.
> In the meantime, you can use www.shadyurl.com for all your dodgy URL needs.
So it might just be that they went down today.
But people keep using them (for a while for Twitter, but maybe mainly for analytics, though they could self-host and accomplish the same thing).
https://www.theguardian.com/technology/2010/oct/08/bitly-lib...
- So that the URL shortener service can see which site you visit (usually bad for the user)
- if you have to type a url by hand
Why is metered cloud hosting a better choice here than a $5/mo. VPS?
- IaaS, static hosting, etc. can maintain security updates on their end. My own VPS will eventually be broken into if I don't maintain security updates.
- Many things are accessed only intermittently. For low access patterns, it's cheaper to pay for what you use.
What I'd really like is something like Heroku, Amazon Lambda, or similar, but with an open, competitive ecosystem, and without vendor lock-in.
If you expect your website to one day go from 100 requests a month to a million a day and expect that traffic to continue from that point on, these services will be a huge benefit for uptime while you rework your code to a more reasonable system. However, a simple $10 VPS with Nginx can handle much more than people seem to expect, assuming you don't use some excessively bloated platform or your content can be cached.
In terms of security updates: a cron job to reboot weekly and unattended-upgrades will keep your server safe without much to look into. Your only risk will be end of life software, your own code, and your dependencies, but those aren't fixed by going with some managed platform either.
There are definitely upsides to these quick deploy tools if you want to iterate quickly with an API that's not accessible from your dev workstation, setting up a multi tenant K8s/Docker/whatever server to deploy to is much harder than giving devs API keys to push to external parties, but I wouldn't consider these services for 99% of the stuff I would deploy.
- Home automation
- Municipal / school / community sites
- Personal web page
- Various internal automation within my organization
... and so on.
These are things which:
1. Require very simple technology (E.g. storing data in a small key-value store is more than good enough)
2. Should work for the next decade or three with no maintenance
3. Expect to be accessed maybe a couple of times a day, if I'm lucky, and probably much less
4. Most will never scale to gigabytes of data, ever
I believe that with the right choices in life, this risk can be minimized.
E.g. tighten your sshd_config and/or lock it behind a VPN, don't expose app servers directly, don't expose insecurely written software.
> For low access patterns, it's cheaper to pay for what you use.
Low-access patterns don't increase the number of $5/mo. VPS'es I run.
> something like Heroku, Amazon Lambda, or similar, but with an open, competitive ecosystem, and without vendor lock-in.
I sense that the economic incentives lean towards vendor lock-in.
Is the amount of lock-in bad? I would have thought that migrating a function is somewhat easy.
Of course when I suggested that we use a huge provider (I think it was probably Hetzner) it was shrugged off as being a bad idea because "they probably run them out of their garage", ignoring the multiple datacenters spread out across Europe where our primary clients are based.
Instead, I believe the reason cloud companies give away free stuff is the same reason Microsoft will give away Windows upgrades to students: if their weird, proprietary API is all you learn, you'll only be able to get started quickly on their platform so the moment you need to pick tech for a small business/your startup, you'll be quicker to choose their service.
There's a reason AWS Lambda (and Azure's competitor) is free but OpenStack/vSphere providers expect you to pay off the bat: if your workload and knowledge transfer (relatively) easily, there's no lock-in with which to trick people into choosing you.
I think you may even get 256 megs of ram for that these days.
For $5.00, you get 1GB of RAM, 1TB of bandwidth, 25GB of storage, and an IPv4 address. Not bad...
Here though, that service could be hosted on a static website (free at github/gitlab/cloudfare/etc), with client-side javascript used to decode data encoded in the url fragment.
> Turns out this site is powered by money. We ran out of Google App Engine credit. Fear not, we'll get more within 24 hours.
Looks like links are not viewable right now.
You answered your question yourself!