Re: "FTP is an insecure protocol and there are no reasons to prefer it over HTTPS"
>You can't just slap some TLS on the existing ftp protocol to implement it
301 publicly visible posts • joined 21 Feb 2008
Any optimisation, either caching or prediction based on past behaviour (which is just a form of caching), is a potentially exploitable side-channel as it introduces an observable variable timing effect based on potentially privileged data. This is true for hardware or software. The only way to not leak information is for all operations to complete in a deterministic time that does not vary based on the data. This does leave a lot of clever speed up tricks on the table.
Can Microsoft not revoke the signature for the driver, or would that invalidate all Gigabyte drivers?
Loadable kernel modules were always a security exploit waiting to happen. Why bother with enforcing process memory protection if you can load arbitrary code into ring 0 that can modify arbitrary memory. Sure you have to jump through a few hoops to get there, but in the end you are no more secure than MS-DOS.
Hardware vendors can't be trusted to write secure drivers, and can't be relied upon to update them when exploits are discovered.
Yes, true in this case. I was speaking more generally. Invoking the shell is the only reliable way to parse command lines exactly how the shell would parse them, since there is not a standard library function to do this. This mda_command appears to be plucked from smtpd.conf:
> deliver to mda program [ as user]
> Mail is piped to the specified program, which is run with the privileges of the specified user or the user the message is destined to. This parameter may use conversion specifiers that are expanded before use (see .B Format Specifiers .)
I guess someone decided they would like to put arbitrary shell syntax here, to allow for variable expansion and such, and correct interpretation of quoted strings.
Unfortunately, Unix does not provide a way to call another program, or send a message to another program, in a type-checked way. (If it did, command-line syntax parsing could be automatically generated instead of hand-written). In other words, the OS level API is too low-level, burdening every program with the task of correctly serialising and parsing data which crosses a process barrier, a hairy and difficult task even for the experienced developer.
App stores are the perfect distribution method for malware. You don't have to lure users to your dodgy website and convince them to download and run your program. Instead the user can find your app through a centralised, legitimate platform and all they have to do is click Install. You can even steal the reputation of a legitimate application by copying their name and icon and Google probably won't notice or give a damn. Malware checking? "Curation"? Mostly automated systems that are easily gamed, or underpaid/overworked subcontracted employees in Bangalore that need to approve 100s of apps a day (speculation). By the time your ruse is discovered, thousands or millions of people have already installed and run your malware obliviously.
I think the problem is most people don't think of it as being public - they are sharing photos with their friends and family, and don't expect them to be automatically scraped and added to a database for ulterior purposes. They fact that this is technically possible, most people are unware of. Social media is a very new thing and people have yet to really adjust to the technology or understand its deep implications. Suddenly millions (billions?) of people are as public as politicians and celebrities, but they don't really have the tools, power or ability to manage this level of mass exposure.
The majority just want to be cool and fit in, issues that the technical minority care about are irrelevant. For an example, 3.5mm headphone jacks; this is obviously better for various reasons which I won't bother to repeat. To the majority, the trend-setters Apple now say it's cool to have funny white sticks coming out of your ears, so they loss of this jack is a non-issue. What kind of nerd would want to plug in headphones?
If we stuck to CRT tellies none of this would have happened. LCDs created the need for a soundbar because they were too thin to have a decent speaker in them, then some bright spark thought it was a good idea to use Bluetooth instead of a wire to connect it. That requires a CPU and complex software to implement the Bluetooth network stack which created the need for firmware updates. One problem leads to a solution which leads to another problem...
IoT will never reach its potential while it relies on proprietary embedded software, proprietary protocols and proprietary 'apps'. These need to be standardised so the devices and users are not in any way dependent on any particular vendor to release software updates, keep cloud services operational and develop the end-user software to manage and operate the IoT devices.
Centralised app stores just make it easier for malware to be distributed and trusted unthinkingly by users. I would argue it would be more secure to distrubute apps on random websites, on average, since the malware authors would have to put in more effort to get punters to their dodgy website. It's clear Google does very little, if any, checking of apps, and the system is gamed very easily. Apps stores are really about extracting maximum revenue and user data from a platform.
All menus should be removed and replaced by toolbars with icons but no labels or tooltips. On the plus side, all applications will be fully internationalised by default, assuming no culture-specific icons or icon colours are used, reducing the burden of translation. We can remove font rendering from the operating system to save space and reduce complexity.
shutdown -h nowfor a second time: Mag editor fires parting shot at proprietary software
Modern GPUs are very complex beasts which require huge drivers which cannot be effectively audited. Running all that code in kernel mode is asking for trouble (security & stability). Windows since Vista switched to back to mainly user-mode GPU drivers (with a small portion inside the kernel). I've had the NVIDIA driver crash before, the screen goes blank for a second and then a pop-up notification appears telling you the driver crashed.
It doesn't specify which STM32 they used in the paper, and the RAM available varies by quite a lot depending on the model. The highest end model have 1MB, and go as low as 16KB. The image format could have been 8-bit or even 1-bit since it's only character recognition, and the data could have been streamed so the whole image wouldn't have to fit in memory to work. Also some STM32 have a DRAM controller which would allow them to access several megabytes of memory.