To wear these socks...
...you will need to do a re-boot.
4017 publicly visible posts • joined 26 Jul 2007
The company names mentioned do not write Operating systems (not at least to remotely the same degree as Microsoft does).
Each of those names benefits their own business strategy by making their product work with Linux, without there being any conflict of interest.
We know Microsoft's game of old. I would guess that we will see Linux apps being produced by Microsoft, which will initially work atop any flavour of Linux, but then they will become less and less compatible the more and more that they develop their own flavour of Linux, which they will then charge for. And/Or their apps will be developed to only run on Microsoft hardware. I'm thinking Surface here - Microsoft seem to be developing that side of their empire. Now how many times would that prediction have to be spouted annually before it becomes true?
There needs to be a mandatory recall in circumstances such as this. Insurers, for example, should send out letters to their customers telling them that if they have such equipment on their premises then their insurance is null and void: after all, the costs to replace the equipment would be borne by Samsung - BTW, with no strings attached: without time limit or proof of ownership - the machine is as lethal five years down the line as it is today.
...where a senior security adviser in, I think, USA resigned over storing draft messages on a gmail account he shared with a woman. He was "corresponding" with her, not by sending/receiving any messages to/from her, but by leaving communications in draft which were subsequently read by the other party. If this method of communication is suspected (it requires a certain ingenuity and knowledge of the mechanism by which email systems work in order to pull off) then the messages will not necessarily have any domain or recipient information on them. The fact that the two accounts were on the same email system means that sharing of communications through IMAP access of a folder that is nominated as shared is a distinct possibility. Any folder can be configured as such, and taking the principle further, any shared address book could also be pressed into use as a covert message store, The question that arises as a consequence is: if these types of communication are present on the system, are they considered to be "messages" in the legal sense of the word? Judging by the former case mentioned at the top of this post, I think the answer is yes. (This is a purely impartial point I'm raising here).
Well spotted. I was thinking of things from the other way round.
However, have a look at an UBER invoice and it (apparently) shows zero tax. I believe there is a zero rate in Netherlands for entrepreneurs, however it does not apply to the supply of services to a non-registered entity in another EU country. So either way, there is a flaw in their treatment of VAT.
There has been some controversy over the exact position with UBER regarding VAT. Though the parent company is registered in Netherlands and has a Dutch VAT number, it looks as if UBER might have been relying on the notion that you the customer are paying the driver who is their own company, who is therefore unlikely to need to register for VAT (obligatory only on reaching a certain turnover threshold). The driver pays the parent company and consequently there is no VAT in that transaction either.
If it is now ascertained that UBER are the company being paid by the customer then VAT is due. Now the Dutch VAT number on their paperwork implies that that could be used on your VAT return (in a neutral way, the input VAT is zero because it is an EU code, not a UK one). However, the place of supply is the UK and therefore (my understanding is that) VAT needs to be charged at 20% and that (because their turnover would be higher than the registration trigger) UBER need to register for UK VAT.
With this ruling I suspect that HMRC will want some VAT and that will need to be taken into account in UBER's pricing.
Hang on a minute. The thing we should be looking for in this story are the words "has been convicted".
Correct me if I'm wrong, but a lawyer representing the accused could surely claim that the jury's verdict on a future trial would be influenced by tittle tattle spouted on the internet?
Has the accused admitted he did what was said, of his own free volition? For all we know he could be the front for someone who has promised big wonga for acting as the fall guy. Something in this story makes me want to search for it on snopes.
Telling me how much they understand security and how they can help impart their knowledge to my usage of the internet. Pity then about the "Login to Your Account Here" link, the "contact us using this phone number" link and the serialised "Find Out More" link (which incidentally takes one to an unsecured page).
The email does appear genuine, but it is not a good way of educating its target audience.
I think that this highlights the suitability of considering to use the cloud for ephemeral storage and computation, but not for core business functionality such as accounts, stock control and other similar purposes. Just imagine the accountants being told to reduce the number of transactions they post, or enquiries/reports they produce due to a budget ceiling being reached.
CUSTOMER: Can you send me a statement as we want to pay you?
ACCOUNTANT: Sorry we've used up our cloud transaction budget for this month.
1. Having an automatically generated Username/Password is what many manufacturers do right now (routers and access points, for example). However, there have been cases in the past where the algorithm/mapping that generates such combinations has been cracked.
2. Getting ISP's to block dubious traffic: this has been the case with SMTP and file-sharing traffic ports for some time now, but there are many ISP's that don't, and there are good reasons why they should not get embroiled in such matters.
3. CE-marking and US equivalents are good for purchasers to aspire to buying, but faced with a choice between high-price or low-price, with the difference in features being purely a few regulatory stickers affixed to the casing, which one will the purchaser end up buying?
4. I think, and I've said this before, the Anti-malware companies need to target this as a compelling USP, in collaborating with the body that assigns MAC addresses: Build a database of devices, maintain a directory of firmware signatures associated with those devices and use that within the perimeter of LAN's to effectively poison those errant devices. I appreciate MAC addresses can be changed, but as a proportion of total devices, is it going to affect a DDOS attack? Those with the ability to do such things will also have the ability to ensure their IoT device is well-maintained.
Manufacturer-based qualifications tell people how good that person is with that particular manufacturer's tools. But those tools are ephemeral to say the least. If I wanted to collaborate with someone who had knowledge I would want to know how far that knowledge extends back in time, and how committed that person was to what they are promoting right now. How deep-seated that knowledge is, and the experience that goes with that knowledge.
It says nothing about the future. When that list becomes superseded, will those people still be recommending the 2016 product-list to their clients? Will anything on that product list still be available in five or six year's time? Looking at the list, what is the earliest product there? I don't think anything more than about five or six years at most.
Look at history. Take Silverlight for example. Where are all the Silverlight developers now? What are they recommending these days?
MAC addresses are assigned by a central body. Issuing a MAC address should assume a certain responsibility to be associated with it by its usage. As I've mentioned before, make an element of the charge for MAC address issue to be set aside for killing errant devices.
Though corporates throughout the world will lock down their networks and local hardware against unauthorised data exfiltration, how many will lock down users ability to store data in the cloud by virtue of it being part of their paid-for Office 365 subscription?
I heard some while ago that Microsoft set aside a hefty slice of their revenue to offset against future product support costs. Now for server products and for retail products, yes I can understand that.
But what about OEM products where there are zero support costs? Is the reason for the lower cost of these items (apart from a reduction in packaging cost, and the fact that licenses are not transferable) that the difference between the selling price and cost price of OEM items not contributing to that support contingency fund?
(Responsibility for support for OEM products falls upon the Manufacturer of the Original Equiupment where the product is tied to).
My thinking is that this is a mandatory utility bundled into the setup software of the device. It could periodically poll a central repository for updated status info which could help mop up old devices that were built pre-poison.
AV companies should see this as a means of expanding the services they provide.
There will be people around who will reverse-engineer and publish methods of disabling this functionality, but as a percentage of the community using IoT devices as a whole, I would think that it will take the potency out of any DoS that is triggered.
I suppose the downside is that hackers will seek to destroy the functionality, and that is I suppose the reason why building this into AV software is the way forward, as the likes of AVG and Kaspersky have the expertise to ring-fence it.
One way I would think to fight this would be for manufacturers to undertake to file a list of MAC addresses that have been used for their IoT kit, and (ideally) for those manufacturers to pay into a fund which administers a simple piece of software which is installed on pc's and Mac's whose job it is to detect these MAC addresses on the network and disable them in some way if they do not respond correctly to a "what firmware are you running?" command (poisoning techniques being one method).
I think why having a master-list would work is that manufacturers have to keep tabs on MAC addresses they issue in any case. MAC address allocation is chargeable anyway so why not use part of that charge for this purpose? Ok MAC addresses can be changed, but we're talking about catching the low-hanging fruit here. Those that think that restricted publication of such a list is a security risk should remember that this utility would be introduced into a LAN's perimeter from a trusted source.
The issue arguably is not so much to do with buying or renting hardware. It is more about where you store your data. The analogy is that you have a warehouse full of stock. Would you care to have that stock under your own control, in your own warehouse, or would you prefer to rent space from a warehouse space provider?
One reason you might not want to do the latter is what happens if you fall behind with the rent? Who owns your stock, can it be confiscated by the owner of the rented resource in order to offset against your debt? In which case, how will you trade without data? Data has no value to the entity storing it, but then again, there is a big incentive to not lose it.
In this country it may be the case that a liquidator may say you have a right to that data, even if you can't pay for its storage, but if it is stored in a foreign jurisdiction that may not be seen as an enforceable right.
Companies probably don't think about the inability to pay for something as it is an admission that failure is a possibility. However, trade disputes are a much more frequent occurrence, and this is where the provider has you over a barrel.
Yes, I've had some customers at the receiving end of that policy.
When the "signals/telemetry" comes back with GIGO-style results and refuses to allow you to use the software that you as the licensee are entitled to use - this is the reason for healthy dollops of scepticism.
It might be acceptable for encryption of current standards to be applied to data stored in the cloud today. But what of that data in a year's time? It has to be assumed that that data will still be accessible in that kind of timeframe, and longer, even after deletion, during which time such encryption will have become easier to crack. Of course, any hacker who can intermittently access such data will, in the fullness of time, be able to crack it.
There are various reasons why data will still be accessible in the cloud after deletion by you (maybe not accessible by you, but by administrators of the cloud service). One being that it may have got migrated onto backup media somewhere.
You might think it the job of the cloud administrator to strengthen existing data's encryption whilst resident in the cloud, but the only way that can be done (without having the keys to decrypt it, before re-encrypting it) would be to encrypt the encrypted data. Not a good idea.
So even if you secure anything put into the cloud, the longer it stays there, the less secure it becomes.
Maybe not immediately.
But when the people in your address book have all been profiled and identified, there will initially be a missing jigsaw piece (you).
Probably easily filled by "triangulating" the data supplied by these other people which inadvertently identifies you.
Maybe correspondent "A" (in your address book) emailed correspondent "B" (also in your address book) about something you were also involved with, where personal information about you is given.