Even so, the website is just static content basically (except the globe at the top that you can rotate) so requiring webgl for the entire website (or even JS) feels a bit too much. Could just have hidden the globe if webgl/js is not enabled.
I mean to be fair all of those appear to be cheap junk. You would probably find better results with something from a reputable brand or that has undergone some kind of third party testing.
They're basically all exactly this though, no matter what you're paying this is generally what is underneath. Competent encryption in hardware is difficult, so everybody is doing it in software, and then why id the software hardware specific to begin with?
This isn't for personal use, so no calls. The data rate is probably around 2-5c/MB for Canada (though its not on the pricing list, that seems to be average), which puts it above even Rogers consumer plans. Google Fi is intended for consumer use and is 1c/MB in Canada (up to a cap, and then unlimited).
Very little of Twilio is for "personal use" but you can still deploy it as such and there is another class of Twilio SIM product (programmable SIM) that you can do anything (voice, sms, etc.) you want with.
I have built my own little personal telco out of twilio and couldn't be happier ...
Well, except for an <email> verb in twiml - that would make me much happier ...
It's hard to tell if this is similar to their programmable SIM offering or not...
I have programmable SIM deployed in my iOS test phones and use it to place calls and texts from the phones (no contract is nice). I also pay about 12.5$/GB because I have the higher commit turned off
This is for Internet of Thing usage, the customer is a company who is making Internet Widgets with some need to be able to communicate no matter where their Internet Widget is operating, without necessarily having to configure or prepare for the destination.
I've been wondering for a while what the purpose of all the NB band LTE stuff is even for. The going rate is often around 40c/MB in most countries (lower on Twilio by the looks of it, but the same order of magnitude), which seems like there's some very specific high value-per-byte application intended. Some of the technologies people are touting for very long battery life have transmission latencies of 10+ seconds as a trade off, which makes the applications for it even more restricted.
It feels like the result is going to be that literally every device you can purchase will have a always connected LTE lojack attached. Imagine trying to firewall or restrict the network in your business when literally everything has its own backbone, it'll be a complete nightmare.
What’s interesting is a lot of new IoT devices operate or can fallback to a mesh or gateway mode configuration, for example, a group of common sensors that work together. So you’d potentially need to block Bluetooth, ZigBee, WiFi, LTE/GSM, GPS (messaging over GPS) and others to account for different radio technologies.
Shielding by enough to throw any common network off is certainly feasible. Metallized non-opening windows (reflect IR from the sun to save on HVAC), metal plates or thin meshes on the outer walls and either rotating doors or a combination of rf-absorbing walls and a convoluted path to the inside that prevent radio waves from getting in through the door.
I'd assume you can feasibly add 60 dB shielding to a building with that. More is obviously possible, there are conference rooms with advanced shielding of >100dB against industrial espionage. They use fiber optic communication lines to the outside because you want all electrical connections to be very heavily filtered to prevent conducting radio waves through them.
If you have physical access to the device, it's probably cheaper/easier to modify it, replacing the antenna with a load to ground. And if you're going to do that, you could probably negotiate with the provider to sell you a cheaper one with no LTE radios.
I'm probably thinking of larger B2B though, individuals/SB probably won't have the expertise/influence
This is an explicit tool in adwords, believe it or not.
The feature is intended so that you can have a link "to" http://trackersRus.com/ which forwards to http://ebay.com/, without the user seeing that bit of ugly.
It's been used in campaigns for years, I've reported probably hundreds of these distributing malware.
It appears here that the redirection to the ebay.com destination url is not happening and that the user ends up on a different domain.
That kind of situation is usually detected when ads are entered into the Google Ads* platform for review, with ads then rejected for "destination url mismatch". One thing checked is that the final destination url after all redirects matches what is specified in the ad's final url field.
I suspect the scammers here are somehow faking the destination url for Google's bot checker to pass the Google checks and then serving different destination urls to users who they believe are not Google bots.
* Google Ads is now the correct branded name. No longer called AdWords as in the title.
Google's approach here seems totally wrong. The destination URL should be, exactly, the link as shown. If someone wants to track clicks using a third-party tracker, Google should offer an API for that which does not give the third-party tracker any ability to control the destination -- they have plenty of market power to impose this and, heck, they could even charge a small premium.
Most browsers support a lovely feature where the a tag has a ping attribute, which is intended for more or less this use case.
Google already works like this in browsers that support it (most modern ones). The ad is linked to the destination URL with no redirects through any advertiser-controlled domain. A third-party tracking URL can be specified, and it will be pinged in the background using the browser's sendBeacon() function. Any redirects in response to the ping don't affect what webpage the browser displays, so they can't be used to hijack the click.
That’s not the point of the tool - the point of the tool is to turn example.com/cms/category/subcategory/product into the easier to read example.com/product
>That’s not the point of the tool - the point of the tool is to turn example.com/cms/category/subcategory/product into the easier to read example.com/product
Then set up an explicit 301 or 302 on example.com to make this happen, don't hide it in the ad-serving layer.
This is called "cloaking", and it's a cat and mouse game between ad networks and bad actors. You're describing the simplest thing that can be done to cloak a website from an automated checker, but there's far more advanced techniques as well.
> Have the page redirect until ad is approved, profit?
Wouldn't work - they do periodic checks after approval. Something more sophisticated appears to be going on here.
>Google needs to abolish this link policy, I don't see how it's enforceable
Link analytics and link trackers are perfectly legitimate. There are many situations in which it is necessary or desirable to go via intermediate urls before the final destination. Throwing out the baby with the bathwater definitely isn't the answer here.
> Wouldn't work - they do periodic checks after approval. Something more sophisticated appears to be going on here.
What if you randomly redirect, say, 95% of clicks to eBay and take the remaining 5% to your phishing site? Each of Google's periodic checks would only have a 5% chance of catching you, but if you can get enough impressions over eBay's legitimate ads (which is an entirely separate facet to all of this), you'd still get a ton of bites, because so many people get to eBay the way Aunt Sue does.
Better yet, your redirect service could look at the client IP address and only redirect to the phishing site if it matches a known range for, say, Comcast or Charter. Or use it to drill down even farther and set up multiple spear phishing campaigns.
It seems like there's no shortage of ways to abuse this, and for Google to allow redirects without some sort of robust verification that the advertiser owns the destination domain (such as @gnud's certificate-based suggestion in a sibling comment) seems downright negligent, if that is indeed how they operate.
There's other ways to signal ad impressions that aren't a huge security risk. Maybe not quite as convenient, but I doubt banning redirects would have a measurable effect as long as Google gave a deprecation warning.
You can achieve the same thing without redirects using URL parameters or the referer field. Google should ban any destination that doesn't match the sites domain. It's an unfixable security risk that's being actively exploited
I've had this problem on Facebook.
I've reported some ads for various (relatively benign) scams for herbals and the like, that use a famous newspaper as 'their url', when they have nothing to do with it.
Facebook closed my report as 'not against ad policy'.
Anyway, this is actually easily fixed without losing tracking/campaign flexibility, by requiring ad orders to be signed by a certificate valid for the target domain, if the URL is different from the displayed one.
Wouldn’t a simple solution to this problem be to prove ownership of the domain you want displayed? Why is this not done yet, this is almost standard practice nowadays for many types of services.
I wonder why Google doesn’t follow the redirect, and ensure the followed link matches the displayed link?
I get that there’s workarounds like changing the redirect after Google checks it, but there’s solutions to this too (like running checks every so often to ensure the link redirects to the same domain).
Online ad campaigns depend on redirects to reconcile clicks and analytics. It is dumb, but if you want to get customers/make money in the ad space, you have to support this.
Sure, but you could make them add a meta tag or upload a validation file to prove they are actually working on behalf of the final URL, just like they do to validate that you're in control of the URL for the webmaster console. If the malicious ad buyer has access to ebay.com's server all bets are off, but I feel like that happens a lot less often than this.
Browser updates can also change default preferences, and change a lot of other things too. How is this a backdoor any more than auto-updating of the browser is a backdoor? The one issue I can think of is that if you turn off browser auto-updates, this should probably be turned off too.
I personally don't see the point in them at all, in implementation and reality you get basically zero use out of the things.
Services that support them either have them locked down so hard that if you lose a single Yubikey (there's often no backup second key option), you're very screwed. Others go the other option, and have too easy to reset systems, SMS fallbacks, or other total bypasses of the security tokens.
For SSH and GPG, authentication keys are generally the least of your concern. The content you're controlling are much more valuable than the authentication itself. Can an attacker just wait until you SSH somewhere, and leverage that access? Can they wait until you'd press the button for another benign purpose and use that authentication in a malicious way? The answer is almost always yes, which reduces the value of these sort of devices substantially. They don't protect against local compromise, in which case a keyfile sitting on your local host is just as secure and a lot more convenient.
Well their main use is to mitigate remote compromise. But I suppose if for some reason someone compromises a private key remotely (???), they don't have your physical 2nd key to complete auth. Or if you want encryption at rest with something stronger than a passphrase. For weird cases like "disk backup was compromised" it also helps, because most people don't encrypt backups at the client. But in general, actual protection seems vanishingly small past remote attacks.
So I think in general private keys aren't improved with a token, since a compromised private key is supposed to be a local compromise.
A regular keylogger won't no longer work with a hardware token for example. Yes, having your PC compromised is bad but it would be even worse if the keys can be stolen and used elsewhere, it just rises the bar significantly for getting persistent access (re-establishment without the token is really hard) in my opinion.
I think they can be pretty beneficial in corporate environments where you can exert some control over the IDP and turning it on/off isn't super difficult (like visiting a physical help desk)
In addition, these places tend to have less technical users and "plug it in and press during login" isn't terribly difficult
I agree, I bought a yubi key ages ago and have tried to set it up for ssh, windows auth and various online services but I find it either just doesnt work, or works poorly enough that I don't use it and instead rely on classic TOTP instead.
